The major browser projects all host a very similar attack surface --- a programming language with content/attacker- controlled code hooked up to a whole bunch of crazy bells and whistles. The browsers barely, just barely, have a handle on that attack surface. And the modern browsers have all rearchitected in the last 5 years specifically to address the problem, which is something the Java applet maintainers have not done. Who in the world is surprised that doubling the browser attack surface creates problems?
It's long past time we put Java applets out to pasture.
It should be 'Oracle killed Java APPLETS'
No, the title's totally fine. Oracle sucks balls and killed Java. I'm still having it installed (interested in Clojure, for example), but I actively make sure that people around me Do Not Use It.
Java as a platform on the desktop was killed by the company that is
a) unable to advance the language and platform, to make it 'state of the art' again (right now, it's ... old-fashioned and limited, if you're looking at competing platforms)
b) actively trying to get malware on your machine because .. why not, you're already installing stuff from those clever people, maybe another browser toolbar would be totally fine?
Both Java applets and Java desktop apps are completely irrelevant to Java on the server-side.
A case could be made that Java is also an amazing success in countless devices, from Java smartcards to smartphones / tablets (with, for example, use Java source code compiled to bytecode run on something looking very much like a JVM on Android devices).
Java is an amazing success and neither Java applets nor Java desktop have anything to do with it: on the contrary, these two Java technologies hardly did anything besides giving the Java brand bad reputation.
Both Java applets and Java desktop apps could disappear overnight and the millions (!) of Java devs out there would still have a job. Granted, they'd still need one Java desktop app: the IDE they're using to develop Java apps).
Note that I'm not saying that Oracle is playing nice when, apparently, they're using spammy techniques when you install desktop Java...
All I'm saying is:
"Java applets + Java desktop apps" != Java
[1] http://www.quora.com/Java-programming-language/Why-does-Java...
There's also OpenJDK as an option, though for some reason there's no official Windows builds for it.
I have a few applications that suddenly started popping up warnings that they may stop working in a future Java release, because of a missing property in the JAR manifest (no joke, the warning actually included technical language something like this).
Certainly, though, server-side Java is hale & hearty as ever.
That or the author is playing a dirty rhetorical trick.
Completely false? Resigning a jar with authenticated signature will turn it into a self-signed jar and will then display the nasty warning as it should. This security measure works very well: if you want to run stuff in the browser, use js+HTML5 (or GWT). If you have legacy java code that you must run in the browser, get it signed properly and it will run. This is universally an incredibly good thing given how flakey java applets are.
Today we understand that you need language-level sandboxing, OS-level sandboxing, permissions enforcement, code signing, and a way to revoke bad apps. (Android store, for example.) And it's not really enough.
Most of us have moved on, but I think Oracle deserves some credit for doing something to protect the people who still must rely on applets for some reason (probably legacy apps).
Because $300 a year is a little steep, the open source community could do this much more efficiently.
I got a code-signing cert (for the applets at eMusicTheory.com) for $75 plus the annoyance of proving my company was legitimate. Here's the guide I used as a starting point: http://srcbin.blogspot.fr/2010/04/tucowscomodo-code-signing-...
People who want to make a point about the awfulness of an option they're not taking don't usually search very hard to find the best price.
UNsigned applets by default run in the sandbox; signed applets (including self-signed) run with full permissions unless you specify otherwise in the HTML and in the JAR manifest (where you can explicitly request sandbox-only execution).
