Java 8 delayed to tighten up security

[Bear Bibeault]

From Mark Reinhold’s Blog

I applaud this move. No one benefits from taking the cake out of the oven before it's done baking.

[Jay Orsaw]

Bear Bibeault wrote:From Mark Reinhold’s Blog

I applaud this move. No one benefits from taking the cake out of the oven before it's done baking.

When the blogs came out about this people showed heavy concern about losing Lambda(including myself), or them trying to take bits and pieces out. Extending it is all we can do, and enjoy the beta builds while we wait .

I rather have a stable JDK and JRE than to have it thrown out faster just to make some people happy.....

[Ulf Dittmer]

I'm all for tightening security. Personally, I don't think Project Lambda (or much else in Java 8) is going to make a big difference for the long-term future of the language, just like I don't think much of Java 7 will do.

[Paul Clapham]

I'm all for tightening security too, but based on the events of the last several months I'm not convinced that Oracle has the resources to do that. Several times they have released a new version to improve security and it has been broken within days. But perhaps they are hiring the people who were doing the code-breaking to help them out? I suppose we aren't going to know about that because the first corporate rule of security is to not say anything about anything.

[Diksha Neel Arora]

Any idea as to what upgrade is to be made and when is it going to go live? Also any headfirst version on it?

[Pat Farrell]

Ulf Dittmer wrote:I don't think Project Lambda (or much else in Java 8) is going to make a big difference for the long-term future of the language, just like I don't think much of Java 7 will do.

Care to elaborate on this? I have that reaction to 7, but 8, well, really lambda, have the potential to make a huge difference in the language. Of course, I'm predicting a big change, but can't predict the direction. IMHO, lambda has been hacked onto the language in a way that is not consistent with the historical Java, so I don't see it being accepted in the short term (1 to 3 years). My crystal ball doesn't go out farther than that.

[Luke Leber]

Rather sad to see Oracle (effectively for the end-user) break all unsigned code in one fell swoop with their plans to force all code to go through verified signers ($$$).

[Richard Tookey]

Luke Leber wrote:with their plans to force all code to go through verified signers.

Could you provide a link for this?

[Luke Leber]

Richard Tookey wrote:

Luke Leber wrote:with their plans to force all code to go through verified signers.

Could you provide a link for this?

Start up any JWS application or applet with jdk 1.7.0_40 and you will see a bold warning that running applications from unverified publishers will be blocked in a future release. I'll look up the page that I read it on now and link you.

[Luke Leber]

I can't seem to find an edit button...anyhow, here's the page:

http://www.java.com/en/download/help/appsecuritydialogs.xml#selfsigned

[Rob Spoor]

That's all related to Java applets. Applets are evil and should not be used. I don't mind this at all.

OK, now a bit more seriously (about the evil part; I really don't mind at all. I have disabled applets in all my browsers). Java has gotten a lot of grief over security problems related to applets, because it was possible for someone to put a malicious applet on a website and compromise a user's system just because that user visited a URL in a browser (even though applets are supposed to run in a sandbox, but the bugs kind of made this point moot). There was often already the requirement to have applets signed which showed similar warnings. This just goes a bit further.

This doesn't mean that you can't run "regular" Java applications. I use Java 7u40 and I have never seen such a popup, even for the programs I've written myself. That's because the user is still in control over what he/she is running.

[Pat Farrell]

Rob Spoor wrote:That's all related to Java applets. Applets are evil and should not be used.

I completely agree. I have argued both here and at the university where I teach that we should not teach them. They were an at best OK idea back in 1995, and were evil back then.

There is no reason to use Java applets.
Ever.

I wish we would have a sticking the the applet forum here on Java Ranch that says "even though you are doing this for homework, you should never use applets"

[Bear Bibeault]

I say, it's about time. Anything that discourages people from writing or using applets is a good thing.

[Luke Leber]

JWS applications are also affected. Think of how many distribution systems will be broken. Also, regardless of how "evil" applets are, is it really a good idea to break every applet or JWS application ever written (that isn't published for $200 - $600 / year)? How can Oracle justify breaking backward compatibility like this?

[Pat Farrell]

Luke Leber wrote: How can Oracle justify breaking backward compatibility like this?

Its simple. The current implementation is evil and broken. You can't fix it and maintain backward evil compatibility. So you fix it and let old crocks break.

[Luke Leber]

Pat Farrell wrote:

Luke Leber wrote: How can Oracle justify breaking backward compatibility like this?

Its simple. The current implementation is evil and broken. You can't fix it and maintain backward evil compatibility. So you fix it and let old crocks break.

In that case, can't we slip a fix for type erasure into java 8 pleaaaaaaaase.

* and by the way, they're not fixing it. They're just putting a(nother) bandaid on the security fiasco.

[Cay Horstmann]

Clearly, for applets and Java Web Start (which Oracle collectively calls "rich internet applications", the writing is on the wall. Don't write new ones. And sign the legacy ones you have. The sandbox is dead.

It's too bad, but I think Oracle cut their losses because, in the grand scheme of things, Java-based "rich internet applications" no longer run everywhere. On Chromebooks, iPads, and Android devices, there is no JVM. These days, the universal VM on end-user devices is the JavaScript VM.

Cheers,

Cay

[Jeanne Boyarsky]

What about JavaFX? It seems like they are trying to do something with RIA?

[Cay Horstmann]

Security-wise, the situation for JavaFX is no different from anything else. If you want to deploy a JavaFX app over the Internet, you need to sign it. And Oracle will tell you that's probably not what you should be doing for new apps.

If you want to develop a new GUI in an embedded system (say, for example, for a kiosk application or in an industrial control environment), then JavaFX is a good choice. On a business desktop, not so much. The problem is that JavaFX was designed as a competitor to Flash, not to Swing. It's good for flashy things, but not so much for boring business apps with buttons and text fields and sliders and checkboxes and graphs, where Swing excelled. What's wrong with Swing? It works poorly on machines with a weak processor and a fast GPU (think Raspberry Pi). And it has a lot of unfixed bugs. I think that it would have been possible to provide a Swing-compatible layer over the GPU-friendly guts of JavaFX, but nobody bothered to do it. And now it's too late. Except for a few desktop apps for IDEs and stock trading and controlling nuclear reactors, everything is done in JavaScript in the browser. So those specialty apps will either continue in legacy Swing (or SWT in the case of Eclipse), or maybe they will be written in JavaFX. But that's a really small part of the overall GUI market. For the rest of us, there is JavaScript.

Coincidentally, to be effective with a modern JavaScript framework, you need to understand lambdas.

Cheers,

Cay