Proposed new schedule for JDK 8(mail.openjdk.java.net)
mail.openjdk.java.net
Proposed new schedule for JDK 8
http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-April/002336.html
31 comments
My proposed security fix: kill the Java Browser Plugin.
I agree. All the bad rep Java gets is from the Applet 0-day hacks.
Java 8 to deprecate the Browser Plugin, Applets and all related stuff to it, and for those who need this technology can use Java 7 and other previous releases.
Java 8 to deprecate the Browser Plugin, Applets and all related stuff to it, and for those who need this technology can use Java 7 and other previous releases.
Then you're going to have all kind of apps stuck on older Java versions forever. While I'd love to see it happen, it would be Oracle shooting themselves in the foot with their enterprise customers, which - let's face it - is who they actually care about.
Although I don't have numbers, I'm not aware of very many enterprises with extensive fleets of java applets. Java in the enterprise tends to be either stand alone programs (i.e. Swing), or EJB driven middleware with JSP on the front end.
Big chunks of dealing with the government (taxes, etc.) in Portugal are in the form of Java applets. I think this is repeated across Europe.
Most of the apps are little more than forms - there's a lot of logic in the way the different fields are filled out and the validation and business logic is probably quite complex. Since everything must be checked on the server anyway there's nothing stopping it from being migrated to pure HTML.
Most of the apps are little more than forms - there's a lot of logic in the way the different fields are filled out and the validation and business logic is probably quite complex. Since everything must be checked on the server anyway there's nothing stopping it from being migrated to pure HTML.
There is nothing stopping any web app from not using applets.
As an example, Sungard HE's Banner (built on Oracle) is used extensively as the ERP system at many universities in the United States. It is used for billing, payroll, recruitment, grades, student and employee contact data, etc. It is non-functional without the Java browser plugin.
Is there a reason that Sungard HE can't handle the browser portion using JS or similar instead of JPI? No. But it would be a very slow migration process and, basically, all employees at many major universities would be stuck with older Java versions.
This is just one example that I'm (unfortunately) intimately familiar with. I'm sure there are many others that the typical HN crowd (small shops, latest technology, devops, etc) would never see.
Is there a reason that Sungard HE can't handle the browser portion using JS or similar instead of JPI? No. But it would be a very slow migration process and, basically, all employees at many major universities would be stuck with older Java versions.
This is just one example that I'm (unfortunately) intimately familiar with. I'm sure there are many others that the typical HN crowd (small shops, latest technology, devops, etc) would never see.
> Then you're going to have all kind of apps stuck on older Java versions forever.
Actually, that's already the reality of the Java ecosystem. Many libraries are tested to offer compatibility with 1.4, or even 1.3, and several flagship open source projects are not compatible yet with 1.7. With closed source and internally developed systems, the situation is even worse.
If I decide to use lambdas, I'll probably use Jython or Scala. I honestly don't expect to use Java 8 in the next 5 years.
Actually, that's already the reality of the Java ecosystem. Many libraries are tested to offer compatibility with 1.4, or even 1.3, and several flagship open source projects are not compatible yet with 1.7. With closed source and internally developed systems, the situation is even worse.
If I decide to use lambdas, I'll probably use Jython or Scala. I honestly don't expect to use Java 8 in the next 5 years.
They can use Java 7. Oracle can provide security updates for it. And all those enterprise customers can use that one. It's not a problem to have multiple JVMs installed.
The point is, if a Java developer starts working on a new product/project, it is very likely that he won't use Applets.
And one more thing, I know companies, that use Java based tools/apps, where they are not moving from Java 5 or 6. It's too expensive (installing newer JVMs, testing the environment and everything...) and they don't feel the need to do that.
The point is, if a Java developer starts working on a new product/project, it is very likely that he won't use Applets.
And one more thing, I know companies, that use Java based tools/apps, where they are not moving from Java 5 or 6. It's too expensive (installing newer JVMs, testing the environment and everything...) and they don't feel the need to do that.
We decided to switch to Java 7 simply because Java 6 has reach its end of life. There will be no more security patches for it (IIRC). I think Oracle still offers paid support for the older versions, but I don't know how much it is.
You are right, the final update was 3 days ago: http://en.wikipedia.org/wiki/Java_version_history#cite_ref-6...
Why should Oracle really care if a bunch of enterprise customers have old JREs installed on their desktops? That would be a problem for those enterprise customers for sure, but how would that actually be bad for Oracle?
The enterprise is where Oracle make their money. They could care less about enthusiasts (as if there were any of their technology) and they don't really care for startups and small shops.
Their main target is huge enterprise customers where Applets are still used today.
Their main target is huge enterprise customers where Applets are still used today.
Just because enterprise customers are keeping old versions around on their desktops to run applets doesn't mean that they aren't using newer versions on their servers, or even also on those same desktops.
I'm really not seeing why they should care.
I'm really not seeing why they should care.
That's a bit harsh. Just offer it as a separate download or don't include it in a default install.
Does anyone have any ideas about why the browser plugin for applets has so many security zero-days?
If competing products like Flash, JavaScript, or HTML 5 have fewer security issues, what are the engineering reasons they're better, and how can those lessons be ported to Java?
Alternatively, maybe Java applets are actually comparable to other technologies in this space in terms of security zero-days. Its bad reputation might be merely due to the fact that relatively few people actually use it, so a recommendation to get rid of it won't break nearly as much of the Web as removing Flash or disabling JS. Is this explanation plausible?
If competing products like Flash, JavaScript, or HTML 5 have fewer security issues, what are the engineering reasons they're better, and how can those lessons be ported to Java?
Alternatively, maybe Java applets are actually comparable to other technologies in this space in terms of security zero-days. Its bad reputation might be merely due to the fact that relatively few people actually use it, so a recommendation to get rid of it won't break nearly as much of the Web as removing Flash or disabling JS. Is this explanation plausible?
Because Java allows signed applets to ask to run native binaries, it will always be hopelessly dangerous.
It's still used in commercial and industrial applications. (Obviously, it never caught on in userland.) You could make it disabled by default, but getting rid of it would be an outrageous mistake.
Why not just come up with a separate installer for the browser plugin. The runtime isn't as bad security-wise. Or is it?
Kill the Java browser plugin. Also, delay by another year and use the opportunity to bring in Jigsaw. Lambdas are nice, but in the big picture, Jigsaw is huge.
what does jigsaw bring to the table? what does its existence imply?
Read about it and ask more specific questions: http://openjdk.java.net/projects/jigsaw/
I had no idea this existed. This would be nice. I used to like Java's packaging, until I was introduced to better methods of packaging, like Ruby, Python, etc... Glad to see that this is on the table.
Seems pretty likely that Jigsaw will take > 1 year to complete.
We can wait till 03/2014 for JDK 8. I don't want to jump on buggy code. Good idea by Oracle not to scope creep by delaying but fixing security bugs and making the code base more stable.
I am happy about the renewed focus on security. As far as I remember, people were pretty skeptical and didn't think Oracle would fix the JRE once the exploits started getting discovered so frequently.
Versioned jarballs with versioned dependencies PLEASE. Seriously, Ruby is laughing at you.
Jarballs? I don't know why Ruby would be laughing. Maven and Gradle are doing their job fine of handling project dependencies.
Build dependencies, yes.
Runtime dependencies for upgrade in situ, not so much.
Runtime dependencies for upgrade in situ, not so much.