Insights and updates on Java SE and OpenJDK from the Java Platform Group Product Management Team

  • March 19, 2014

Java SE 8 is available for download

Guest Author

Developers and system administrators can now download the first official release of Java SE 8. This is the first major release since Java 7 (July 2011) and features significant improvements in speed, stability, and security. Complete details about Java SE 8 and launch events can be found at The Java Source and Mark’s blog.

Java 8 - Create the future

Please also join the main launch webinar on March 25.

New developers learning Java 8 may also view the Java Tutorials or focus on Java FX 8.

Coordinated Releases

The launch of Java SE 8 was a well-coordinated event across many lines of the Java community. Simultaneous support is available in all IDEs:

Many open source projects have also taken part in the quality outreach campaign. This work involved application compatibility testing as well as using the new JDeps utility to identify reliance on internal JDK APIs.

Auto-Updates and the Security Baseline

System Administrators or end-users looking at compatibility testing must explicitly download Java SE 8 from the Oracle Technology Network. End-users will not be auto-updated to Java SE 8, nor will it be available from Java.com until a future (currently undetermined) date.

The Security Baseline represents the latest critical patch update within its own family and is always documented within the latest release notes -- this baseline is separate for 8, 7, and 6.

Join the discussion

Comments ( 12 )
  • Robert Tuesday, March 25, 2014

    Hi !

    Do you have a general idea about when on Java.com, Java 8 will be by default ? We use Java on many programs, so that change may have a major impact on us.

    Thanks !

  • costlow Tuesday, March 25, 2014

    Hi Robert. That won't happen for a while. Even after that happens, both will still be available for download for your users.

    Then when that switch does take place, if you'd prefer to use both, you can control compatibility as described in https://blogs.oracle.com/java-platform-group/entry/managing_multiple_java_versions

  • Tom Wednesday, April 16, 2014

    JRE 8: sandboxed applets are no longer allowed to open socket connections back to their originating server, something that's been allowed since day one. So I have to update the Manifest to request all permissions and rebuild.

    JRE 8 U5: Caller-Allowable-Codebase with value of "*" no longer avoids warnings.

    Is there a road map for these planned security changes? These constant changes in required manifest settings are making a mockery of Java's "write once run anywhere" motto, I would like to know what the longer-term plan is for these security requirements so I can code to that plan now and not keep having to rebuild and re-sign the .jar.

  • costlow Thursday, April 17, 2014

    Hi Tom.

    JDK 8 is a different major version and also isn't the default on Java.com for normal end-user download. Pre-release information like the socket change was posted on OTN in the areas with the early access releases. Now that JDK 8 is generally available, I don't have those links on hand.

    The Caller-Allowable-Codebase change was actually introduced specifically to decrease the dialogs because it has a checkbox "don't show this again."


  • Brian D Thursday, April 17, 2014

    > JRE 8 U5: Caller-Allowable-Codebase with value of "*"

    > no longer avoids warnings.

    Same is true of JRE 7 U55. The Java Plugin really needs to provide a mechanism for an applet to send/accept JavaScript calls to/from the same site as itself without security prompts. Not all applets are deployed with a priori knowledge of the domain from which they will be served -- and the plugin needs to do a better job there. Deployment Rule Sets and Exception Site Lists can help -- but they are not perfect (require allowing even unsigned applets from a domain in order to allow LiveConnect calls) and force action on the part of the end user that should not be necessary.

    I wholeheartedly echo the frustration in general -- the moving target is really difficult to track and the downstream impact on end users seems to be wholly underestimated by Oracle.

  • Brian D Thursday, April 17, 2014


    > The Caller-Allowable-Codebase change was actually introduced

    > specifically to decrease the dialogs because it has a checkbox

    > "don't show this again."

    In 7u51, 'Caller-Allowable-Codebase: *' allowed the LiveConnect calls to the applet with NO security prompts. Now at least one is presented to the user.

  • costlow Thursday, April 17, 2014

    Right, many developers and companies don't know the intended destination of the RIAs because they're moved around on different equipment and what-not.

    The gist is that this relates to RIA Repurposing described at http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/no_redeploy.html -- if there were a same-domain type mechanism and someone repurposed the RIA by downloading it and moving it to a different domain, then the new (wrong) domain would be allowed.

    The workflow on http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_flow.html for Caller-Allowable-Codebase is essentially:

    If you don't put anything in, the the LiveConnect calls are unexpected.

    If you know the domain ahead of time and use it, then it's ok per the rest of that flowchart.

    If you can't know the domain and use a * then the clients check to see if the current domain is ok. For the right domain the answer is "yes please don't prompt me again" but if it's coming from somewhere else (whether wrong or different than what they previously allowed) then that answer should be no.

    Some other good info on http://blog.trendmicro.com/trendlabs-security-intelligence/the-reality-of-browser-based-botnets/

  • Jon Thursday, April 17, 2014

    Regarding the Caller-Allowable-Codebase change in 7u55 and 8u5, I understand this change from a security standpoint, but the warning is a change in behavior from 7u51, which becomes a major hassle for our customers.

    Although it's a one-time dialog and a checkbox, our customers have thousands of users who will not understand the meaning of the dialog, and they get the impression that something that was working before is now broken.

    With this change to Caller-Allowable-Codebase, there does not appear to be any corrective action that we as RIA developers can take to make our jar files work at all customer sites. Options like Deployment Rules Sets or having customers re-sign jars are either not feasible or are undesirable at many organizations.

    Can Oracle provide any recommendations on how to explain these changes to our customers, who are often taken by surprise with each new JRE?

  • costlow Thursday, April 17, 2014

    Also to clarify one other thing: When we create a post, the comments are open for a period of time. If the comments section here closes, it's because that window has passed, not because of any intervention, and you are welcome to comment on a different post.

  • Tom Thursday, April 17, 2014

    The alert does have a "don't show me this" checkbox, but it also has a default setting of Disallow. So if the user just hits Enter, as some users would, the application breaks. Besides, adding alerts to the system which are primarily intelligible to developers, and not end users, is undesirable.

    What I'm looking for is: if I build an applet based on Oracle's documentation, then Oracle will not break that applet the next time there's a quarterly update. I'm not hearing that.

    So - based on J7U55/J8U5 I remove LiveConnect, doing polling from the applet instead. Am I done, or is there another feature restriction coming along in July, and if so how do I find out about that feature restriction now?

  • Brian D Thursday, April 17, 2014

    Well, the manifest attribute "Codebase" may legitimately be "*" -- thus allowing the RIA to be run from any site, so why would a same-domain policy for JavaScript access to such an RIA be any less secure?

    Perhaps there needs to be some way of securely marking which APIs in the applet are safe for calling in such a scenario -- and the plugin allows such invocations without warning.

    The bottom line is that there needs to be a way for RIA developers to deliver a final product that meets all security requirements without manual intervention from end users. These warnings cause great consternation and confusion for the average user -- made even worse in this case because "More Information" on the dialog recommends that the access NOT be allowed. Could we at least get that dialog changed to reflect the fact the signed manifest recommends allowing the call?

  • costlow Friday, April 18, 2014

    The difference between the JAR file attributes described on http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html is:

    Codebase - identifies where the signed RIA will go. Even if someone moves the RIA, the signature protects the internal code against modification. Thusly * is a valid option.

    Caler-Allowable-Codebase - identifies the location(s) from which a web page can make LiveConnect calls. If someone moved the RIA, these unsigned calls may be the same or they may be different. So * is an option to say that calls are expected, but the first time, it will prompt the user to see if [location] is an ok substitution for * (yes, please don't ask me again).

    As for sending information to clients, I've used a strategy beforehand: when users load your hosting page, check an external feed for information and render something. If the request has their current version number, it's helpful to serve content. You could show information, product tips, or proactive support notes. I used to use this for items like "there is a new data bundle for you," "here is a common recent ticket question," or "here are strategy/usage tips from your peers."

    Regarding dialogs, the More Information tab is for more technical audience. I will take a look at this particular dialog, but if you have a suggestion that hits both the security and usability angles, I am open to it.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.