Oracle announces delays in the release schedule for JDK 8

Discussions

News: Oracle announces delays in the release schedule for JDK 8

  1. Mark Reinhold, the chief architect of Oracle's Java Platform Group, recently posted a new schedule for the release of JDK 8. Reinhold also blogged his thoughts on the schedule change and whether or not Jigsaw and lambda expressions will find their way into this release.

    Basically, Reinhold's statement is that the Oracle team shifted focus away from features to fix some security vulnerabilities and to get the features back on track they're going to let the schedule drag on just a little bit so they can get lambda expressions done and done right in JDK 8. Project Jigsaw probably won't be ready until 2016. Reinhold lays out the reasons why he thinks this is the right approach in his blog, as well as covering some alternatives that probably wouldn't go so well.

    Al Hilwa agrees. Hilwa said via email that it makes sense for Java to run along a feature-driven release schedule, rather than releasing whatever happens to be ready on time. "JDK8 is in many ways the Lambda release at this point," said Hilwa, "It is always a concern when release dates slip, but under the circumstances the team is prioritizing the right work, namely a deeper security review."

    What do you think? Is Reinhold taking the right tact here? Is there some way the Java Platform Group could have done better?

    Thanks to Al Hilwa (@alhilwa) of IDC for bringing this to our attention.

    Threaded Messages (19)

  2. a long and winding road![ Go to top ]

    As one of the groups inside Oracle depending on (and waiting for) specific projects from the Java SE team, I can attest to their almost singular focus over the past year on eliminating the "security backlog" in Java. In addition to targeting a complete elimination of all known security vulnerabilities (including unpublished vulnerabilities that were discovered internally), the Java team has also invested heavily in both manual and automated discovery of _unknown_ vulnerabilities, to prevent future problems. This has been an incredibly expensive process in terms of the level of investment, but security is a critical aspect for a trusted platform. It will be a great relief to eliminate the last of the known vulnerabilities, and to have a process in place that will reduce the chance of future vulnerabilities. Peace, Cameron Purdy | Oracle The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.
  3. Cameron, I keep hearing from you how the recent batch of security problems are "legacy" problems that existed for years before. I would like to hear some details about this phenomena and how these problems were created but then lay dormant for so long. I'd especially like to hear James Goslings take on these legacy issues. There may be something in this phenomena of latent security flaws that the entire field of software engineering needs to learn about. Aeronautical engineers didn't understand metal fatigue until the wings snapped off of a plane (I think during the late 1950s). This may be software's equivalent of discovering metal fatigue. There may be systemic issues that all large software projects need to learn about. I hope this isn't a case of one group of people blaming their predecessors. That's a popular thing to do today, but it's not productive.
  4. What can we learn?[ Go to top ]

    Hi Dean -

    I keep hearing from you how the recent batch of security problems are "legacy" problems that existed for years before. I would like to hear some details about this phenomena and how these problems were created but then lay dormant for so long.


    I think we'll be in a better position to disclose more information once the bug backlog (including the internally discovered ones that are not publicly disclosed) is at zero -- probably by the August security update. This topic would make for a very interesting JavaOne presentation :-)

    I hope this isn't a case of one group of people blaming their predecessors. That's a popular thing to do today, but it's not productive.

    Not at all. Many of the same people who were involved then are still involved, and now they are diligently working to close down that backlog. It's just a matter of whether those issues were considered important enough back then to stop other important work in order to close down those issues. No company, product team, or project team has limitless resources, and there are always important things that are not getting done because other things are getting the attention. Particularly in the last few years at Sun, for reasons related to the declining health of the company, the teams were spread thin to the point of not having any coverage in many important areas. We're trying to pay off that "technical debt", but it is taking longer than we expected it to.

    On that note, the Java team is still hiring, and they're always on the look-out for some great developers who want to help "Make the future Java" (the JavaOne theme from last year).

    Peace,

    Cameron Purdy | Oracle
    The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.
  5. Give up on client Java[ Go to top ]

    At this point in time, Oracle should probably give up on Java browser plugin. It's dead. Swing, JavaFX, everything client-related has been on life-support since early 2000-s. Just pull the plug and let them die in peace.
  6. RE: Give up on client Java[ Go to top ]

    Not true, Swing has been generified recently, for example. Why should they let Swing go? There are occasional uses, and those security flaws aren't related to it. Browser plugins, ok... or could some fix just let users enable it for those few apps that need it? Swing, even if more rarely used than before, is not the problem, anyway.
  7. Plug-In still too popular[ Go to top ]

    Alex -

    At this point in time, Oracle should probably give up on Java browser plugin. It's dead.


    If only that were true. The Java plug-in is still shockingly popular, especially with online games. (When I heard the statistics from the Java team in terms of number of users of these games, I was shocked.)

    The fundamental problem is that the Java plug-in didn't make the default security level higher. Had this been done (and fully implemented -- which it will be soon), only signed applets (with a trusted CA) could have been loaded, and then if someone had created malware, there would have been two outcomes: (1) It would be apparent who created the malware (or at least which certificate it was signed with), and (2) that certificate could have been revoked so that other users would not inadvertently load that same malware.

    Peace,

    Cameron Purdy | Oracle
    The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.
  8. Re: Plug-In still too popular[ Go to top ]

    Cameron, only loading signed applets is a complete cop-out. Imagine if only signed JavaScript loaded in the browser. This is essentially Oracle saying they've given up on getting Java's security sandbox secure.
  9. Re: Plug-In still too popular[ Go to top ]

    Jess, care to explain your theory? Of the top of my head, JS is only secure because the browser limits it pretty much just the browser because... it (the code) cannot be secured by signing. One reason that people use Java and the plugin because it can do so much more AND be signed at the code level. That is why it has to be the route that Oracle is taking.
  10. Re: Plug-In still too popular[ Go to top ]

    One big promise of the Java Plug-In has been that you can rely upon its security sandbox without having to deal with signing applets, i.e. that *it* could be trusted even if the applet author could not be. By stepping towards requiring signed applets, Oracle is essentially reneging on this promise, crying uncle and stating that they can't make the sandbox reliably secure and that those producing and consuming applets have to work around this through signing applets.
  11. Sandboxing[ Go to top ]

    Jess -

    only loading signed applets is a complete cop-out. Imagine if only signed JavaScript loaded in the browser. This is essentially Oracle saying they've given up on getting Java's security sandbox secure.


    As a default setting, only loading signed applets seems reasonable to me. Think of signing as analogous to HTTPS -- it requires the web site to use a trusted certificate otherwise the browser can warn you that "it isn't who you think it is".

    Regarding sand-boxing, the security fixes that have gone into Java have closed the known exploits. I don't think it's about "giving up on the sandbox" as much as it is building a logically-consistent security model that includes the sandbox. Keep in mind that an applet can request (and be granted) permissions that allow it to have access to your computer; doesn't it make sense that you'd be able to verify whose code that is that is asking?

    Lastly, I don't expect that you'll agree with what I'm saying, so I am curious what you would suggest as an alternative. Knowing how widely Java is installed, and that it has been targeted severely over the past year, how would you modify Java to make it as safe as is practical for Internet users?

    Peace,

    Cameron Purdy | Oracle
    The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.
  12. Nope[ Go to top ]

    Currently the cheapest code signing certificate costs about $300 a year. Cheapest SSL certificate costs $0.

    That's because they are used for different things - SSL certificates simply ensure that the content is not eavesdropped/altered during the transmission. SSL has nothing at all to do with the safety of information transmitted using it, browser still has to make sure that JS is properly contained.

    Signed applets, however, start to rely on certificates to prove that they should be trusted.
  13. Sandboxing[ Go to top ]

    My biggest issue with the current approach to signed applets is that the user experience is pretty harsh if you have a site or product with lots of unsigned applets. [There are substantial roadblocks to signing in this case that I won't elaborate.] An ability to trust a *site* (or otherwise tell the Java Plug-In not to bother you any more about unsigned applets there) would go a huge way to alleviating this issue. As it is now, having to tell the Java Plug-In this for each and every applet. I can't recall if it remembers this decision indefinitely or forgets this the next time you log out of the OS -- like it unfortunately does with user credentials that you ask it to remember for you. [There should be an option for it to remember credentials indefinitely.]
  14. Thanks for the details[ Go to top ]

    Jess -

    There is work going on in this area under the project known as "local security policy", and it's expected to be delivered within this calendar year (2013) as an update for Java 7. Unfortunately, I'm not permitted by policy to provide a date more specific than that, but I can say that it is not planned to be released before the other work related to signing and security defaults that I described.

    Peace,

    Cameron Purdy | Oracle
    Insert disclaimer from above here.
  15. Signed Applets and Apps[ Go to top ]

    Working with apps (internal and extranet users ) at financial institutions , I welcome the decision at Oracle to require signed applets / apps with a valid code signer certificate. Granted this is not 100% protection, but then some form of identity is better than none. Sometimes our users visit external web sites where such websites have integrated content pulled in from other third party sites, where such site may have been compromised. Rarely have we (again in our use case) have to Accept and allow more than a couple of Java Applets to run (certificate permissions dialog). The fee for a code signer certificate is minimal at best ($200/300 per year). The proxy servers / content filters at our financial institution and partner institutions will block unsigned java applets / apps passing through. Java applets are used to overcome some of the limitations of HTTP which is checksumming file uploads / downloads or automatic resumption of file uploads / downloads from the point of failure (if you've worked overseas where networks can be dodgy, you will relate to the need for something like Java applet to move files around) Anyways, hope Oracle does not get to easy with Java security . My only gripe is that I wish we could run Java Applets from our web applications for moving files around on Android or Blackberry.
  16. Regarding multiple applets on a page[ Go to top ]

    A number of sites use multiple applets on a single web page, as of 7u21 users should only get one prompt for all of the applets on that page, as long as all applets are served from the same domain, have the same privilege level (all-permissions or sandbox) and are signed with the same certificate (or all unsigned). Also, the prompt before running any applet includes a "remember this decision" check box, which will prevent users from being re-prompted in the future unless something happens to invalidate that decision -- like the applet being re-deployed with a different privilege level or a change from unsigned to signed. Self-signed and unsigned applications are a higher risk and for general use are strongly discouraged.
  17. IMO, an SSL certificate for an HTTP website and a code signer certificate for signed code should not be co-mingled. If a website chooses to serve up multiple applets, that website owner could go through the process of obtaining a valid coded signer certificate and sign the applets to be served to the users. That way only a single code signer certificate and only one prompt /security dialog presented to users. The choice of limiting the number of security dialog presented to the user is really dependent on the design of the website, not an issue for the Java security model to address. If the website owner does not wish to take on the responsibility and legal liability of signing code or lacks the technical resources to do so, then ..... you can draw your own conclusions.
  18. re: Sandboxing[ Go to top ]

    If a site or product has "lots of little applets" it sounds like the problem is elsewhere.
  19. Plugin should be dropped[ Go to top ]

    "The fundamental problem is that the Java plug-in didn't make the default security level higher. " Oracle should do the entire world a favor and kill the plugin. Everyone should be moving to HTML 5 and away from proprietary browser plugins. For the laggards out there, they can still use java 7 indefinitely. But dropping the plugin would be a signal from oracle to modernize to HTML. Oracle spends too much time worshiping at the altar of backwards compatibility. This has held java back time and again. Sometimes it's time to move on. Other platforms have had breaking changes and survived. Why is Oracle hell bent on backwards compatibility above all else? Java 7 isn't going anywhere....
  20. Let's hope...[ Go to top ]

    ...other security issues will be discovered into JDK 8, so that Oracle would announce other delays in the release schedule for JDK 8, and then, we could get Jigsaw into JDK 8. I am just kidding ;-) PS: this being said, for pushing back Java on the client-side, as another answer than applets and the problem they are facing (ex: plugin stuff), why not thinking about the problem from the opposite point of view ? Applets face the cold start pb while the browser is (already) hot. Let's reverse the situation. Why not starting the JVM and running a browser inside ? It would be like an Adobe AIR-like, but in Java. See http://www.jroller.com/dmdevito/entry/javafx_may_be_the_next