Oracle Killed Java

Oracle&#x27;s got nothing to do with the failure of the Java applet sandbox. The problem with the applet sandbox is simple: it was designed before anybody really understood modern secure C programming --- integer handling, memory lifecycle, concurrency.<p>The major browser projects all host a very similar attack surface --- a programming language with content&#x2F;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 <i>doubling</i> the browser attack surface creates problems?<p>It&#x27;s long past time we put Java applets out to pasture.

I tend to agree if we&#x27;re talking about client-side Java served up through a browser. But client-side Java has been going downhill for years. Server-side Java on the other-hand is alive and well.

Yet another link-bait title...<p>It should be &#x27;Oracle killed Java APPLETS&#x27;

Java applets were dead before Oracle acquired Sun. Too heavy, too slow, and by the time they stopped being too slow it was too late.

I&#x27;ve never used python for anything serious. I&#x27;m shocked to learn about this python functionality that duplicates webstart or applets. Being able to hand out a link that will download an interpreter and then run my script in a secure way (with self signed code no less) is a really slick feature.<p>That or the author is playing a dirty rhetorical trick.

<i>&quot;While this is great in theory, for java its pointless. The contents of a jar can be extracted just the same as any zip format, signatures removed and resigned all without any issue.</i>&quot;<p>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.

Applets were invented at a time when there was competition between language-level sandboxing (Java) versus code signing (Active X).<p>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&#x27;s not really enough.<p>Most of us have moved on, but I think Oracle deserves some credit for doing <i>something</i> to protect the people who still must rely on applets for some reason (probably legacy apps).

Can&#x27;t believe the author mistook &#x27;effected&#x27; with &#x27;affected&#x27;. Never had seen that happening in the wild.

Orcale does not care about the desktop - and Sun never managed to make it user-friendly (e.g. annoying Java Updater popups on every start, trying to install the ask toolbar, etc). However, Java will stay significant on servers and on Android (as Dalvik).

Would it be a possibility of having a 3rd party Java app registrar which isn&#x27;t Oracle, using OpenJDK?<p>Because $300 a year is a little steep, the open source community could do this much more efficiently.

Java in the browser has been dead for years, or should&#x27;ve been. Sure, lots of people are still stuck with it for legacy apps, but no one likes having to use it. Good riddance.

I thought applets were buried almost half a decade back.

When the author claims self-signed applets run in a sandbox, I believe that&#x27;s incorrect. Even the warning shows the sandbox becomes disabled.

Shame on you for writing applets. Personally I&#x27;m glad this cr*p is being killed off. Java belongs on a server.