Java SE 8 is available for download

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 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.


Hi !

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

Thanks !

Posted by Robert on March 25, 2014 at 01:04 PM PDT #

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

Posted by costlow on March 25, 2014 at 04:06 PM PDT #

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.

Posted by Tom on April 16, 2014 at 10:14 AM PDT #

Hi Tom.
JDK 8 is a different major version and also isn't the default on 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."

Posted by costlow on April 17, 2014 at 10:29 AM PDT #

> 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.

Posted by Brian D on April 17, 2014 at 10:38 AM PDT #


> 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.

Posted by Brian D on April 17, 2014 at 10:40 AM PDT #

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 -- 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 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

Posted by costlow on April 17, 2014 at 12:44 PM PDT #

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?

Posted by Jon on April 17, 2014 at 12:47 PM PDT #

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.

Posted by costlow on April 17, 2014 at 12:56 PM PDT #

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?

Posted by Tom on April 17, 2014 at 01:09 PM PDT #

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?

Posted by Brian D on April 17, 2014 at 01:13 PM PDT #

The difference between the JAR file attributes described on 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.

Posted by costlow on April 18, 2014 at 09:05 AM PDT #

Post a Comment:
Comments are closed for this entry.

Science Duke
This blog contains topics related to Java SE, Java Security and Usability. The target audience is developers, sysadmins and architects that build, deploy and manage Java applications. Contributions come from the Java SE Product Management team.


« July 2016