X

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

Recent Posts

The OpenJDK Community TCK License Agreement (OCTLA)

After launching the OpenJDK Community as the place to collaborate on open source implementations of the Java SE Platform back in 2006, the next logical step was to make the Java SE TCK (JCK) available to those working in and contributing to OpenJDK.  Sun Microsystems did this via the “OpenJDK Community TCK License Agreement” (OCTLA), made available in 2007 with certified builds appearing in 2008.  Oracle continued and expanded on this program by releasing an OCTLA for Java SE 7, another for Java SE 8 and, given the new release cadence, a single agreement for Java SE 9 and later.  There have been dozens of signatories across these Java SE versions.  The initial OCTLA FAQ is still available here.  Oracle has continued to apply the traditions and intent of the OCTLA program as it was originally conceived.  That is, the OCTLA is for individuals and organizations who are working in and contributing to the OpenJDK Community, with OCTLA tested implementations from such individuals and organizations distributed only under the GPL license of the OpenJDK code.  As noted in the FAQ, the OCTLA is not for “independent implementations of Java technology standards.”  For independent implementations Oracle offers commercial JCK options, which helps to fund the overall development of Java.  Indeed, many of the OCTLA signatories who participate in the OpenJDK Community also have commercial JCK agreements for their independent implementation (non-OpenJDK) based products and services.  Some examples of independent implementations of Java technology standards over time include BEA JRockit and IBM J9.  Oracle has consistently enforced the spirit and intent of this longstanding program for the benefit of the OpenJDK Community, and plans to continue the program as it has since the acquisition of Sun.

After launching the OpenJDK Community as the place to collaborate on open source implementations of the Java SE Platform back in 2006, the next logical step was to make the Java SE TCK (JCK) available...

Building JDK 11 Together

With the recent release of Java 11, it’s time to look back at the development of the second feature release in the new semi-annual release cadence. Let’s celebrate the many contributions in the OpenJDK Community from many individuals and organizations — we all built JDK 11, together! JDK 11 Fix Ratio The overall rate of change in the JDK over time has remained essentially constant for many years, but under the new cadence the rate at which changes are made available has increased dramatically. Instead of making tens of thousands of fixes and around one hundred JEPS available in a humongous release every few years, changes are made available in smaller releases on a more manageable, predictable schedule. These changes can range from large features to small enhancements to routine maintenance, bug fixes, and documentation improvements. Each such change is represented in a single commit for a single issue in the JDK Bug System. Of the 2,468 JIRA issues marked as fixed in JDK 11, 1,963 were completed by people working for Oracle while 505 were contributed by individual developers and developers working for other organizations. Going through the issues and collating the organization data from assignees results in the following chart of organizations sponsoring the development of fixes in JDK 11: While developers employed by Oracle resolved 80% of the JIRA issues during the development of JDK 11, 20% were fixed by developers working for other organizations. Developers working for the five next largest contributing organizations, SAP (7%), Red Hat (5%), Google (3%), BellSoft (1%) and IBM (1%), collectively fixed 17% of those issues. Independent developers contributed 2% of the fixes in JDK 11. Last but not least, the remaining one percent of the fixes was collectively contributed by developers from a wide range of organizations including Alibaba, Amazon, ARM, Azul, Intel, JetBrains, Linaro and Qualcomm Datacenter Technologies. But wait, there’s more A lot more work goes into a JDK release in addition to the individual commits. There are JEPs, code reviews, bug reports and mailing list discussions, both in the JDK Project and the various OpenJDK Projects where features and fixes destined for JDK 11 originated. These include Project Valhalla and Project Amber, both led by Brian Goetz from Oracle, the AArch64 Port, led by Andrew Haley from Red Hat, and the ZGC Project, led by Per Lidén from Oracle. With JDK 11 out of the door, the work on the first Oracle-led JDK 11 update in the JDK Updates Project’s repository has started, as well. Thank you for JDK 11, everyone! Finally, it’s time to say thank you to all developers who contributed code to JDK 11, and to their sponsoring organizations. Special thanks also to the many experienced developers who reviewed proposed changes, the early adopters who tried out early access builds and reported issues, and the patient professionals who provided feedback on the OpenJDK mailing lists.

With the recent release of Java 11, it’s time to look back at the development of the second feature release in the new semi-annual release cadence. Let’s celebrate the many contributions in the...

Java Platform Group, Product Management

Introducing Java SE 11

DOWNLOAD JAVA 11 How time flies!  Over the last several months, Oracle announced changes to evolve the Java platform ensuring it continues forward with a vibrant future for users.  Those advances included: Increasing the pace and predictability of delivery Since the release of Java 9, the Java platform has shifted to a six-month release cadence allowing developers more rapid access to continued enhancements. Releases now occur in March and September of every year, which means no more trying to consume hundreds of changes every couple years all at once – instead, change is delivered on a more measured and predictable pace. Making Java even more open To improve developer productivity, Oracle has taken commercial features previously attainable only with a paid license and open sourced them.  Doing so creates greater alignment and interchangeability between the Oracle JDK and Oracle OpenJDK releases.  Previous commercial features now available in OpenJDK include Application Class Data Sharing, Project ZGC, Java Flight Recorder (JFR), and Java Mission Control (JMC).  And more recently, Oracle announced plans to make JMC technology available as a separate download to serve both OpenJDK and Oracle JDK users. Introducing the Java SE Subscription Oracle announced the Java SE Subscription over the summer, a new model that covers all Java SE licensing and support needs to further support for the millions of worldwide businesses running Java in production. The subscription complements the long-standing free Oracle OpenJDK offering, which enables developers and organizations that do not need commercial support. Java 11 is now available With six months now gone by since Java 10 (the first feature release as part of the six-month release cadence) Oracle now offers Java 11.  Oracle provides the JDK not only under the Oracle OpenJDK release using the open source GNU General Public License v2, with the Classpath Exception (GPLv2+CPE), but also under a commercial license for those using the Oracle JDK as part of an Oracle product or service, or who do not wish to use open source software.  These replace the historical “BCL” license, which had a combination of free and paid commercial terms. This means users can get the Java 11 fitting their needs: Java 11 is a long-term support (LTS) release.  This means users who are conservative with platform adoption and require long-term support can license the Oracle JDK binaries through the Java SE Subscription offering. It allows users to get updates on the Java 11 LTS release for at least eight years.  The subscription provides access to tested and certified performance, stability, and security updates for Java SE, directly from Oracle.  It also includes access to My Oracle Support (MOS) 24x7, support in 27 languages, Java SE 8 Desktop management, monitoring, and deployment features, among other benefits. Users who instead prefer rapid access to new enhancements can continue using the Oracle OpenJDK release.  As was the case with Java 9 and Java 10, users of this release get thoroughly tested, open source OpenJDK builds provided by Oracle. Seventeen enhancements are delivered in Java 11 including most notably: JEP 321 - HTTP Client (Standard): This JEP standardizes the incubated HTTP Client API introduced in JDK 9, via JEP 110, and updated in JDK 10. JEP 332 - Transport Layer Security (TLS) 1.3: TLS 1.3 is a major overhaul of the TLS protocol and provides significant security and performance improvements over previous versions. JEP 328 - Java Flight Recorder (JFR): JFR provides a high-performance flight recording engine and low-overhead data collection framework for troubleshooting mission-critical Java applications. JEP 333 - Project ZGC: ZGC is an experimental but predictable low-latency garbage collector (GC) that can handle heaps ranging from relatively-small (a few hundreds of megabytes) to very large (many terabytes) in size. JEP 330 – Launch Single-File Source-Code Programs: This enhancement simplifies the “on-ramp” or new Java users by enhancing the java launcher to run a program supplied as a single file of Java source code, including usage from within a script and/or related techniques. Now that Java 11 is generally available, development has shifted to the next six-month feature release in the form of Java 12 (scheduled for delivery in March 2019), currently with two targeted enhancements and more to be added as work is completed. With 12 million developers worldwide running Java, Java continues to be the #1 programming language of choice by software programmers.  And as Java 11 demonstrates, through continued thoughtful planning and ecosystem involvement, the Java platform is well-positioned for modern development and growth in the cloud.

DOWNLOAD JAVA 11 How time flies!  Over the last several months, Oracle announced changes to evolve the Java platform ensuring it continues forward with a vibrant future for users.  Those...

End of Public Updates is a Process, not an Event

And so, from hour to hour, we ripe and ripe. And then, from hour to hour, we rot and rot; And thereby hangs a tale. Shakespeare Successful software platforms and their surrounding ecosystems have a symbiotic relationship, with both positive and negative feedback cycles. As developers use a platform to build successful products that solve problems that could not as easily be solved before, the platform evolves over time to offer new features that make it a stronger fit for even newer use cases. At the same time, successful platforms adapt to changes in the technological environment around them, by deprecating and removing less-used legacy features. This process is always in motion. As new versions of a platform are released, older ones are gradually ramped down so that platform providers can focus their efforts on the future, rather than on the past.  The Java ecosystem has been going through this process successfully for decades, through ten major platform revisions. Strong backward compatibility over long periods protects investments made across the ecosystem. At the same time, some amount of adaptation is inevitable over time. The continued success of the platform, therefore, requires the bulk of the ecosystem to move on to the latest release, while protecting existing investments. Sun Microsystems established the strategy of balancing these two goals by, on one hand, providing free public updates for a period of time while, on the other hand, offering commercial long-term support for users with different needs.  This strategy enables the bulk of the ecosystem to keep up with the release cadence for free, while providing additional security, performance and other updates under commercial terms to users who want to migrate from one platform release to the next on their own schedule, or not at all. Every new beginning comes from some other beginning’s end Java SE 8 was released on March 18th in 2014. By the time Oracle Java SE 8 reaches the end of public updates for  commercial users in January 2019, Oracle will have provided almost five years of continuous, free public updates. With an Oracle Java SE Subscription, commercial users can continue to benefit from support and regular updates to Oracle Java SE 8, including enhancements and critical patches, for an even longer period of time. For example, the Java Web Start technology will continue to be commercially supported in Oracle Java SE 8 until at least March 2025. Not all users of Oracle Java SE 8 use it commercially. Some use it to play games, or to run consumer productivity applications. Oracle will continue to provide free public updates of Oracle Java SE 8 for personal users until at least December 2020. During that time, personal users should contact their application providers and encourage them to migrate their applications to the latest version of Java, or else switch to alternative applications. Upgrade to JDK 10 The shortest upgrade path from Oracle Java SE 8 leads to JDK 10. Instructions for application developers are available in the Oracle JDK 10 Migration Guide. Instructions for users migrating from Oracle JRockit are also available. The latest Java release available as a download from Oracle at the time of writing is JDK 10.0.2. It’s at the security baseline, i.e., it contains fixes for security vulnerabilities described in the latest Oracle Critical Patch Update. Upgrade to JDK 11 JDK 10 will reach its end of life in late September 2018. The next upgrade path from Oracle Java SE 8 leads to JDK 11. Oracle Java SE 11 is the next planned Long-Term Support (LTS) release and the first such release that’s part of the six-month cadence. Oracle Customers will, therefore, receive Oracle Premier Support and periodic update releases even after Java SE 12 is released. That makes Oracle Java SE 11 an attractive migration target for ISVs and other commercial users. Since JDK 11 has not been released yet, the recommended course of action for developers targeting JDK 11 is to start working on the migration from Java SE 8 by making their applications run successfully on JDK 10. Due to the faster, semi-annual release cadence the number of changes between JDK 10 and JDK 11 is much smaller than between JDK 8 and JDK 10. Once an application runs well on JDK 10, developers should test it with the JDK 11 Release Candidate builds in order to be ready to migrate to JDK 11 when it’s released later this month. Upgrade to JDK 12 Developers who want to migrate an application straight from Oracle Java SE 8 to JDK 12 should follow the same migration model — begin with a larger migration effort to the latest release at the security baseline, i.e., JDK 10.0.2 at this time, and then, once the application works well, continue with an incremental migration to the latest available release of JDK 11. Once the application works well on JDK 11, developers should begin testing it with JDK 12 Early Access builds. Oracle regularly publishes JDK 12 Early Access builds under the GNU General Public License, version 2, with the Classpath Exception. These builds allow developers to evaluate new JDK 12 features and test the impact of changes to existing features on their own applications. Staying with OpenJDK 8 after January 2019 At this point, Oracle engineers have been leading and performing the majority of the maintenance work on OpenJDK 8 Updates in the OpenJDK Community for more than four and a half years. We’ll continue to do so until at least January 2019. After January 2019, the contributors from Oracle will likely refocus their efforts in the OpenJDK Community from OpenJDK 8 Updates onto other, current JDK releases, as we have in the past with OpenJDK 6, and OpenJDK 7 Updates. As in the past, when a suitable party steps forward to continue to maintain OpenJDK 8 Updates after January 2019, we will discuss how to best enable such a transition in the OpenJDK Community. Users interested in continuing to use OpenJDK 8 after Oracle engineers move on should therefore subscribe to the project’s mailing list by January 2019 and discuss their expectations and plans with the remaining contributors to better understand the scope of support available for OpenJDK 8 at that time.  

And so, from hour to hour, we ripe and ripe.And then, from hour to hour, we rot and rot; And thereby hangs a tale. Shakespeare Successful software platforms and their surrounding ecosystems have a...

Oracle JDK Releases for Java 11 and Later

Exec Summary Starting with Java 11, Oracle will provide JDK releases under the open source GNU General Public License v2, with the Classpath Exception (GPLv2+CPE), and under a commercial license for those using the Oracle JDK as part of an Oracle product or service, or who do not wish to use open source software.  This combination of using an open source license and a commercial license replaces the historical “BCL” license, which had a combination of free and paid commercial terms. Different builds will be provided for each license, but these builds are functionally identical aside from some cosmetic and packaging differences, described in detail below. From the BCL to the GPL The Binary Code License for Oracle Java SE technologies (“BCL”) has been the primary license for Oracle Java SE technologies for well over a decade. The BCL permits use without license fees under certain conditions.  To simplify things going forward, Oracle started providing open source licensed OpenJDK builds as of Java 9, using the same license model as the Linux platform. If you are used to getting Oracle Java SE binaries for free, you can simply continue doing so with Oracle’s OpenJDK builds available at jdk.java.net.  If you are used to getting Oracle Java SE binaries as part of a commercial product or service from Oracle, then you can continue to get Oracle JDK releases through My Oracle Support (MOS), and other locations. Functionally identical and interchangeable... Oracle’s BCL-licensed JDK historically contained “commercial features” that were not available in OpenJDK builds. As promised, however, over the past year Oracle has contributed these features to the OpenJDK Community, including: Java Flight Recorder, Java Mission Control, Application Class-Data Sharing, and ZGC. From Java 11 forward, therefore, Oracle JDK builds and OpenJDK builds will be essentially identical. ...yet with some cosmetic and packaging differences There do remain a small number of differences, some intentional and cosmetic, and some simply because more time to discuss with OpenJDK contributors is warranted. Oracle JDK 11 emits a warning when using the -XX:+UnlockCommercialFeatures option, whereas in OpenJDK builds this option results in an error. This option was never part of OpenJDK and it would not make sense to add it now, since there are no commercial features in OpenJDK. This difference remains in order to make it easier for users of Oracle JDK 10 and earlier releases to migrate to Oracle JDK 11 and later.  Oracle JDK 11 can be configured to provide usage log data to the “Advanced Management Console” tool, which is a separate commercial Oracle product.  We will work with other OpenJDK contributors to discuss how such usage data may be useful in OpenJDK in future releases, if at all.   This difference remains primarily to provide a consistent experience to Oracle customers until such decisions are made. The javac --release command behaves differently for the Java 9 and Java 10 targets, since in those releases the Oracle JDK contained some additional modules that were not part of corresponding OpenJDK releases: javafx.base javafx.controls javafx.fxml javafx.graphics javafx.media javafx.web java.jnlp jdk.jfr jdk.management.cmm jdk.management.jfr jdk.management.resource jdk.packager.services jdk.snmp This difference remains in order to provide a consistent experience for specific kinds of legacy use. These modules are either now available separately as part of OpenJFX, are now in both OpenJDK and the Oracle JDK because they were commercial features which Oracle contributed to OpenJDK (e.g., Flight Recorder), or were removed from Oracle JDK 11 (e.g., JNLP). The output of the java --version and java -fullversion commands will distinguish Oracle JDK builds from OpenJDK builds, so that support teams can diagnose any issues that may exist.  Specifically, running java --version with an Oracle JDK 11 build results in: java 11 2018-09-25 Java(TM) SE Runtime Environment 18.9 (build 11+28) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) And for an OpenJDK 11 build: openjdk version "11" 2018-09-25 OpenJDK Runtime Environment 18.9 (build 11+28) OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) The Oracle JDK has always required third party cryptographic providers to be signed by a known certificate.  The cryptography framework in OpenJDK has an open cryptographic interface, meaning it does not restrict which providers can be used.  Oracle JDK 11 will continue to require a valid signature, and Oracle OpenJDK builds will continue to allow the use of either a valid signature or unsigned third party crypto provider.  Oracle JDK 11 will continue to include installers, branding and JRE packaging for an experience consistent with legacy desktop uses.  Oracle OpenJDK builds are currently available as zip and tar.gz files, while alternative distribution formats are being considered. What should we call them? Ideally, we would simply refer to all Oracle JDK builds as the “Oracle JDK,” either under the GPL or the commercial license depending on your situation.  However, for historical reasons while the small remaining differences exist, we will refer to them separately as Oracle’s OpenJDK builds, and the Oracle JDK.

Exec Summary Starting with Java 11, Oracle will provide JDK releases under the open source GNU General Public License v2, with the Classpath Exception (GPLv2+CPE), and under a commercial license for...

Fast Forward To 11

With Java 11 around the corner, and release candidate builds available at http://jdk.java.net/11 , it’s time to look back at the effect the new release cadence has had on adoption of new releases. Changing the Pace of Change New Java releases used to take quite a while to get adopted by developers. For example, Java SE 5.0 introduced major changes such as annotations and generics to the Java programming language in 2004. It subsequently took two years, until 2006, for an Eclipse IDE release that was tested and validated on Java SE 5.0. Only then were developers using Eclipse able to begin adopting Java SE 5.0 in earnest as their primary platform. A lot has changed in the Java ecosystem in the decade since 2004. Java SE 8 was released in 2014, introducing another major change to the Java programming language, namely lambda expressions. Yet within days new releases of the Eclipse, InteliJ IDEA, and NetBeans IDEs, tested and validated on JDK 8, were available to developers. Developers could thus begin adopting Java SE 8 almost immediately after its release. And many did, making Java SE 8 the most rapidly adopted release at that time.  The number of JDK 8 downloads increased by more than 30% in comparison to JDK 7 during the same initial launch period. In addition, JDK 8 established the pattern of roughly semi-annual, large update releases. The 8u20, 8u40 and 8u60 releases each delivered hundreds of bug fixes and other changes along with multiple new features. Prior to JDK 8, both JDK 6 and JDK 7 updates have included large individual update releases with hundreds of bug fixes and other changes, as well. Forward to 9 With the new semi-annual Java SE release cadence since Java SE 9, we’ve seen the same pattern of rapid support for new Java platform releases by the major IDEs. In addition, Oracle engineers continue to work together with the developers of more than 100 popular open source Java libraries and tools across the ecosystem to remove potential barriers to adoption of new releases. View image on Twitter Alberto Salazar@betoSalazar     @JavaOneConf a lot APIs works on jdk9 #WorksFineOnJDK9 12:46 AM - Oct 3, 2017     See Alberto Salazar's other Tweets Twitter Ads info and privacy     Accordingly, many popular libraries and tools were ready for Java 9 by the time it was released, or shortly thereafter. That included popular tools such as Apache Ant, Apache Maven, Gradle, libraries such as ByteBuddy, JUnit, jaCoCo, Apache Lucene and frameworks such as Akka, Spring Framework and WildFly. Consequently, the number of JDK 9 downloads in the launch of Java SE 9 release was more than 10% higher than for the JDK 8 launch. Fast Forward to 10 We saw a similar pattern among developers with JDK 10. The Java SE 10 saw 20% more JDK downloads than for JDK 8 in the same timeframe during the Java SE 8 launch. As with JDK 9, popular IDEs, tools, libraries and frameworks rapidly announced their support for the new Java release. This shows how a major aspect of the new release cadence is working out amazingly well — it really is getting new Java features, such as local variable type inference in Java SE 10, into the hands of more Java developers much faster than before. Onward to 11 In the past, each new Java platform release would take several years to develop, and in the process accumulate thousands of large and small enhancements, changes and bug fixes. It would take long to build and then it would take long to get familiar with, due to the very large scope of each release. Under the new release cadence, each Java feature release is delivered in a fraction of time that it took in the past, and accordingly each release is much smaller in scope. As a consequence, the time it takes to get familiar with it is much shorter, as there are far fewer changes to digest. In practice this means that many of the popular tools, libraries and frameworks that were ready for Java SE 9 and Java SE 10 have already been able to get ready for Java SE 11. In other words, from Spring Boot and Spring Framework, via Mockito and ByteBuddy, to Apache Cassandra, IntelliJ IDEA, Jenkins, Eclipse IDE, and Atlassian, large parts of the Java ecosystem have announced that they are ready for Java SE 11, or that they are already working to support it. Given that’s the case, it should come as no surprise that a recent survey by the Java Community Process Executive Committee found that more than the half of respondents are considering using Java SE 11 for deployment in the near future. For users that need to adopt new releases more conservatively, Oracle has recently introduced Java SE Subscription: a simple, low-cost monthly subscription that includes Java SE Licensing and Support for use on Desktops, Servers or Cloud deployments.  The subscription provides access to tested and certified performance, stability, and security updates for Java SE, directly from Oracle.  It also includes access to My Oracle Support (MOS) 24x7, support in 27 languages, Java SE 8 Desktop management, monitoring, and deployment features, among other benefits. Oracle’s Java SE 11 product is a long-term support (LTS) release. Java SE Subscription allows such users to get updates on LTS releases and remain in a given LTS release version for at least eight years.   Organizations can easily add-on to their subscriptions at any time as they move workloads from development to production. Users that don’t need to adopt new platform releases conservatively, on the other hand, can continue to enjoy the benefits of a fast Java release cadence, as was the case with JDK 9, and JDK 10, using the thoroughly tested, open source OpenJDK builds provided by Oracle, as we continue to move the Java platform forward, faster, with the OpenJDK Community.

With Java 11 around the corner, and release candidate builds available at http://jdk.java.net/11 , it’s time to look back at the effect the new release cadence has had on adoption of new releases. Chan...

Java Platform Group, Product Management

Fast Forward To 11

Fast Forward To 11 With Java 11 around the corner, and release candidate builds available at http://jdk.java.net/11 , it’s time to look back at the effect the new release cadence has had on adoption of new releases. Changing the Pace of Change New Java releases used to take quite a while to get adopted by developers. For example, Java SE 5.0 introduced major changes such as annotations and generics to the Java programming language in 2004. It subsequently took two years, until 2006, for an Eclipse IDE release that was tested and validated on Java SE 5.0. Only then were developers using Eclipse able to begin adopting Java SE 5.0 in earnest as their primary platform. A lot has changed in the Java ecosystem in the decade since 2004. Java SE 8 was released in 2014, introducing another major change to the Java programming language, namely lambda expressions. Yet within days new releases of the Eclipse, InteliJ IDEA, and NetBeans IDEs, tested and validated on JDK 8, were available to developers. Developers could thus begin adopting Java SE 8 almost immediately after its release. And many did, making Java SE 8 the most rapidly adopted release at that time.  The number of JDK 8 downloads increased by more than 30% in comparison to JDK 7 during the same initial launch period. In addition, JDK 8 established the pattern of roughly semi-annual, large update releases. The 8u20, 8u40 and 8u60 releases each delivered hundreds of bug fixes and other changes along with multiple new features. Prior to JDK 8, both JDK 6 and JDK 7 updates have included large individual update releases with hundreds of bug fixes and other changes, as well. Forward to 9 With the new semi-annual Java SE release cadence since Java SE 9, we’ve seen the same pattern of rapid support for new Java platform releases by the major IDEs. In addition, Oracle engineers continue to work together with the developers of more than 100 popular open source Java libraries and tools across the ecosystem to remove potential barriers to adoption of new releases. @JavaOneConf a lot APIs works on jdk9 #WorksFineOnJDK9 pic.twitter.com/o3Mih4QHbt — Alberto Salazar (@betoSalazar) October 2, 2017 Accordingly, many popular libraries and tools were ready for Java 9 by the time it was released, or shortly thereafter. That included popular tools such as Apache Ant, Apache Maven, Gradle, libraries such as ByteBuddy, JUnit, jaCoCo, Apache Lucene and frameworks such as Akka, Spring Framework and WildFly. Consequently, the number of JDK 9 downloads in the launch of Java SE 9 release was more than 10% higher than for the JDK 8 launch. Fast Forward to 10 We saw a similar pattern among developers with JDK 10. The Java SE 10 saw 20% more JDK downloads than for JDK 8 in the same timeframe during the Java SE 8 launch. As with JDK 9, popular IDEs, tools, libraries and frameworks rapidly announced their support for the new Java release. This shows how a major aspect of the new release cadence is working out amazingly well — it really is getting new Java features, such as local variable type inference in Java SE 10, into the hands of more Java developers much faster than before. Onward to 11 In the past, each new Java platform release would take several years to develop, and in the process accumulate thousands of large and small enhancements, changes and bug fixes. It would take long to build and then it would take long to get familiar with, due to the very large scope of each release. Under the new release cadence, each Java feature release is delivered in a fraction of time that it took in the past, and accordingly each release is much smaller in scope. As a consequence, the time it takes to get familiar with it is much shorter, as there are far fewer changes to digest. In practice this means that many of the popular tools, libraries and frameworks that were ready for Java SE 9 and Java SE 10 have already been able to get ready for Java SE 11. In other words, from Spring Boot and Spring Framework, via Mockito and ByteBuddy, to Apache Cassandra, IntelliJ IDEA, Jenkins, Eclipse IDE, and Atlassian, large parts of the Java ecosystem have announced that they are ready for Java SE 11, or that they are already working to support it. Given that’s the case, it should come as no surprise that a recent survey by the Java Community Process Executive Committee found that more than the half of respondents are considering using Java SE 11 for deployment in the near future. For users that need to adopt new releases more conservatively, Oracle has recently introduced Java SE Subscription: a simple, low-cost monthly subscription that includes Java SE Licensing and Support for use on Desktops, Servers or Cloud deployments.  The subscription provides access to tested and certified performance, stability, and security updates for Java SE, directly from Oracle.  It also includes access to My Oracle Support (MOS) 24x7, support in 27 languages, Java SE 8 Desktop management, monitoring, and deployment features, among other benefits. Oracle’s Java SE 11 product is a long-term support (LTS) release. Java SE Subscription allows such users to get updates on LTS releases and remain in a given LTS release version for at least eight years.   Organizations can easily add-on to their subscriptions at any time as they move workloads from development to production. Users that don’t need to adopt new platform releases conservatively, on the other hand, can continue to enjoy the benefits of a fast Java release cadence, as was the case with JDK 9, and JDK 10, using the thoroughly tested, open source OpenJDK builds provided by Oracle, as we continue to move the Java platform forward, faster, with the OpenJDK Community.

Fast Forward To 11 With Java 11 around the corner, and release candidate builds available at http://jdk.java.net/11 , it’s time to look back at the effect the new release cadence has had on adoption of...

Java Platform Group, Product Management

Java Mission Control - Now serving OpenJDK binaries too!

Oracle plans to make the open source JDK Mission Control (JMC) technology available as a separate download to serve both OpenJDK and Oracle JDK users. Here are some of the reasons why: To make it available to all Java users Java Flight Recorder (JFR) is open source now. JFR will be included in both OpenJDK and Oracle JDK binaries starting with Java SE 11. Having a single, separate JMC download for Oracle JDK and OpenJDK keeps it simple.   To allow for independent updates of JMC As a separate download JMC can be updated independently of Java SE releases.  This lets us offer new monitoring and diagnostics capabilities across several Java SE versions at the same time. Features can be added to JMC in the middle of a Java SE release cycle.   It is now possible to efficiently bundle a stand-alone JMC Taking advantage of the modularity features introduced with JDK 9, Oracle can create an optimized, tailored runtime for JMC. It can include everything needed for that JMC version, such as JavaFX components, while removing everything not required by JMC, making the application runtime size considerably smaller. Because JMC works with many JDK and OpenJDK versions Newer versions of JMC can interact with older versions of the JDK (from JDK 7u40 and above). It is common to use a single version of JMC to interact with current and older releases of the JDK. This is made more clear if JMC is a separate download. To avoid duplication and confusion It's a common scenario for a single developer to need multiple instances of the JDK in the same system. Having each one of those JDKs include its own, duplicate copy of JMC, when a single version can handle them all, wastes space. It may also lead to confusion as different versions of the JDK may include different versions of JMC, all with (sometimes subtle) differences in functionality. Oracle plans to publish the core parts of JMC (used for parsing, processing and doing automated analysis of JFR recordings) on Maven Central, so that maven dependencies can be used in projects that would like to parse JFR recordings of any JDK version (7u40 and above).

Oracle plans to make the open source JDK Mission Control (JMC) technology available as a separate download to serve both OpenJDK and Oracle JDK users. Here are some of the reasons why: To make it...

A Quick Summary on the new Java SE Subscription

Earlier today, Oracle announced the introduction of the Oracle Java SE Subscription.  Simply put, you can now buy access to Java SE updates – including support from Oracle just as you would buy Linux updates and support from any distro provider.  Pricing is low and simple.  We are working to make it possible to subscribe online very soon, making it even simpler. This new offering does not change how developers will get and use Java SE from Oracle.  As announced last year, Oracle now provides OpenJDK builds under the GPL+CPE license with plans to make them functionally interchangeable with the Oracle JDK by the Java SE 11 launch in September, 2018.  Going forward, we expect most developers and organizations to be using our builds as we complete the effort of making Oracle JDK and our OpenJDK builds equivalent.  No more “BCL” license, use the JDK under the same license as Linux, with the “Classpath” exception to afford even more flexibility. The Java SE Subscription offering adds to all of that by offering a commercial license for Java SE combined with technical support and access to updates on legacy versions so you can upgrade to later releases on your own schedule.  It also buys time for organizations that may want another year or two to transition any use of Oracle Java SE desktop deployment technologies to other solutions.  No need to buy an expensive perpetual license, just buy desktop user subscriptions on an as-needed basis. For more information, please see: Java SE Subscription FAQ  Java SE Subscription Data Sheet Java SE Subscription Oracle.Com Page    

Earlier today, Oracle announced the introduction of the Oracle Java SE Subscription.  Simply put, you can now buy access to Java SE updates – including support from Oracle just as you would buy Linux...

Update and FAQ on the Java SE Release Cadence

As work on Java SE 9 was winding down in early 2017, some contributors in the OpenJDK Community started wondering if there was a way to evolve the Java SE Platform and the JDK at a more rapid pace, so that new features could be delivered in timelier manner.  A JCP working group was established to consider how the Java Community Process could accommodate such a change. After further discussion amongst key contributors a plan was proposed and, in parallel, Oracle announced plans for its commercial Java SE products [1]. In the few short months since then the OpenJDK Community has, with Oracle’s leadership, delivered Java SE 9, Java SE 10, Early Access builds of Java SE 11 as well as multiple coordinated scheduled security updates.  The OpenJDK Vulnerability Group was formed.  A small new language feature was added in Java SE 10 which shows the new cadence works not only for implementation, but also for specification work in the JCP. That being said, the new cadence introduces new idioms and semantics to terms and processes we’ve been accustomed to for many years.  Clearly, the benefits of a predictable release schedule of easily digestible new features are worth the effort to some of the largest projects in the ecosystem.  We’ve seen this trend happening with other parts of the Java SE Ecosystem as well.  For example, Eclipse, has long had an annual “release train,” and Wildfly is moving to a quarterly release model. This blog entry will address some of the common questions that have been asked over the last several months. Q1: Surely you can’t expect everyone to adopt major releases every six months?! There are no “major releases” per se any more; that is now a legacy term. Instead there is a steady stream of “feature releases.”  This is consistent with how many releases have been done in the past, except with a new take on versioning.  For example, Java 8 launched in March 2014.  8u20, a feature release, was released almost six months later in August.  8u40, the next feature release, was released almost six months after that. So yes, we expect an uptake of “feature releases” every six months, just as before. Going from Java 9->10->11 is closer to going from 8->8u20->8u40 than from 7->8->9.  It’s scary to see at first when you’re used to major releases about every three years and have a mental model of the huge impact of those major changes.  The six-month cadence is not that.  Later in the FAQ we’ll provide more specific proof of this. Q2: If the new releases are basically the long standing six-month cadence, why rev the major release number each time?  Why not just call it 9u20, 9u40, etc.? By having streamlined some JCP processes, it’s now possible to introduce new class library, JVM and language features such as Local-Variable Type Inference in just six months, instead of having to wait years for a “major release.”  Rather than releasing dozens of large changes to the specifications every couple of years, they can be more pragmatically introduced in a steady stream as soon as they are ready for adoption. Q3: Spec changes sound dangerous and they’ll inhibit tools ecosystem from updating, right? While some tools have struggled to move from 8->9, it’s been fantastic to see those who made that transition be able to go from 9->10 almost overnight. When Java 10 was released, all the major IDEs had Java 10 support, including the new local-variable type inference feature within days.   Popular projects such as Gradle and Lucene quickly added official support. Some popular Linux distributions such as Ubuntu and SUSE Linux Enterprise Server proactively adjusted to make the latest OpenJDK releases the default JRE/JDK on their platforms.  Elasticsearch is planning to be compatible with both LTS and non-LTS releases as soon as possible to benefit from new features. These are just some of the examples of other projects and products keeping up with the six-month cadence. The new cadence makes it more manageable and predictable for tools vendors, who will now have a steady stream of smaller updates. In addition, forward looking developers can explore new features in development such as minimal value types from OpenJDK Project Valhalla or the Z Garbage Collector from the OpenJDK Project ZGC using early access builds available under a familiar open source license.   Q4: Why would anyone update to version X when a new release X+1 is only six-months away? The latest Oracle JDK builds and Oracle's OpenJDK builds are downloaded millions of times per month by developers.  We have seen consistent growth of JDK downloads with each feature release, including 9 and 10.  The latest releases of Java 10 are being downloaded at a much higher rate than those of Java 7 and Java 8 were.  For example, JDK 10 downloads as of this writing exceed those of JDK 8 updates by a factor of five.  The strong uptake of the new release cadence is impressive. It is very encouraging to see popular IDEs and other tool vendors adopt and make Java 10 support available quickly. Q5: I’m still not convinced.  Java 9 was a challenge to adopt, so that means 10 and 11 will be, too. Many Java SE developers and user have historically waited for a couple of updates before adopting a new “major version.”  This could be expected when there were dozens of major new spec-changing features in a “major” release, but won’t be the case going forward with six-month releases.  This has not been the case since Java SE 9. For example, the Java SE 9 release incorporated approximately 19,000 source code changes on top of Java SE 8.  There were only 2,700 such changes between Java 9 and Java 10 – approximately the same as between Java 8 and Java 8u40.  So while Java SE 9 was a “major” upgrade compared to Java SE 8, we have already seen that Java SE 10 is a simple feature update to Java SE 9. Q6: How can I be confident that the X+1 release transition will be smooth?  How much time is there to transition? EA Builds are even easier than before to download and try, including Oracle’s own OpenJDK builds.  We encourage developers to use Oracle’s OpenJDK EA builds in their build-test systems so any issues can be caught early. There are three months from the final update of a feature release and the security update of the next feature release.  We strongly recommend transitioning during this time.  There is approximately one month from a new feature release and the next scheduled security update.  For example, Java 9.0.4 was released in January 2018, Java 10.0.0 in March 2018 and 10.0.1 in April 2018.  After the Java 10.0.1 release, we do not recommend using Java 9.0.4 or Java 10.0.0.  You don’t have to wait for one month, or even three months to start testing, though - Early Access builds of JDK 10 have been published regularly starting in November 2017, more than six months before the 10.0.1 update release. This is consistent with historical feature releases where there have been 4-6 weeks between feature releases and a subsequent security update.  For example, 8u40 was released in early March, 2015 and the subsequent scheduled security update 8u45 was released on April 14th 2014.  Q7: Ok, but I don’t want new features.  I have a system in production and just want stability, performance and security updates only.  What do I do? At Oracle, our intent is to designate releases every three years as “Long Term Support” (LTS) releases starting with Java SE 11 in September 2018.  So while Java SE 9 has reached its End of Life with the release of Java 10, and Java 10 will do the same with the release of Java 11, Java 11 will have commercial support from Oracle available for at least eight additional years.  As has happened for almost a decade with Java 6 and Java 7 (and likely Java 8 in 2019), once Oracle stops contributing our source code changes to a particular release series in OpenJDK, so that we can focus on the needs of our customers, other qualified contributors in the OpenJDK Community may step in to continue to maintain the release series.  They do so in accordance with OpenJDK Community standards for as long as they choose, backporting the relevant changes from later releases still maintained by Oracle and others.  For example, for JDK 6, Sun established the project in 2008, and Oracle continued to maintain it until 2013.  Other maintainers then continued working on the project by backporting updates from later releases. Oracle supports such transitions in the OpenJDK Community by providing an established process for them to take place within the JDK Updates Project, as well as assistance to new maintainers to settle in their new roles, and last but not least, the Vulnerability Group. Q8: What’s happening with Java SE 8? Java SE 8 is the end of the legacy versioning and release cadence model; Java 9 was the new beginning. For the Oracle JDK, Java 8 is going through the exact same transition processes as with Java 7 and Java 6, with a few exceptions.  First, to give additional time to get accustomed to the new release model, Oracle extended the public updates of its Oracle JDK to January 2019 for commercial production use, and at least the end of 2020 for individual desktop use.  Second, we announced our efforts to make the Oracle JDK interchangeable with Oracle’s OpenJDK builds for those who want to move up to the next releases, as they did for Java 6->7 and Java 7->8.  If you haven’t already done so, we’d suggest moving to 10 and getting on the new release train. Finally, Oracle has posted more information on the roadmap for the Java Client (including Applets and Web Start). On the OpenJDK front, Oracle plans to continue to lead and contribute to the JDK 8 Updates project until January 2019, before which a call for new maintainers will be made (as has been practice for over a decade, see previous Q for more details). Q9: I’m an Oracle Customer, how am I affected? You’re covered for your use of Java SE within an Oracle product having a Java SE dependency.  Find out more details via this My Oracle Support note. Edited May 4th, 2018 .  Added numbers to questions and added reference to roadmap for Java Applets and Web Start in Q8. Footnotes: [1] - ;tldr for the plan that Oracle has announced for its binaries and builds – (a) move all previously closed source bits from the Oracle JDK into OpenJDK (b) publish OpenJDK binaries under the GPLv2+CPE and (c) ensure a smooth transition such that Oracle JDK and OpenJDK binaries are interchangeable.

As work on Java SE 9 was winding down in early 2017, some contributors in the OpenJDK Community started wondering if there was a way to evolve the Java SE Platform and the JDK at a more rapid pace, so...

Introducing Java SE 10

Download Now Over the past 22 years, Java has grown into a vibrant community that has reached a scale without equal.  Java continues to bring value to developers and to enterprises worldwide.  Thoughtful planning and ecosystem involvement has helped grow Java into one of the most used programming languages on the planet. With more than 12 million developers worldwide running Java, Java continues to be the #1 programming language of choice by software programmers.  Moving forward Oracle wants to ensure Java is well-positioned for modern development and growth in the cloud. In 2017, Oracle and the Java community announced its intentions to shift to a new six-month cadence for Java meant to reduce the latency between major releases.  At the same time Oracle announced it's plans to build and ship OpenJDK binaries as well. This release model takes inspiration from the release models used by other platforms and by various operating-system distributions addressing the modern application development landscape.  The pace of innovation is happening at an ever-increasing rate and this new release model will allow developers to leverage new features in production as soon as possible.  Modern application development expects simple open licensing and a predictable time-based cadence, and the new release model delivers on both. With that said, Oracle is pleased to announce the general availability of Java 10, the first time-bound release as part of the new six-month release cycle.  This release is more than a simple stability and performance fix over Java SE 9, rather it introduces twelve new enhancements defined through the JDK Enhancement Proposals (JEPS) that developers can immediate pick up and start using: (JEP 286) Local-Variable Type Inference: Enhances the Java Language to extend type inference to declarations of local variables with initializers. It introduces var to Java, something that is common in other languages. (JEP 296) Consolidate the JDK Forest into a Single Repository: Combine the numerous repositories of the JDK forest into a single repository in order to simplify and streamline development. (JEP 204) Garbage Collector Interface: Improves the source code isolation of different garbage collectors by introducing a clean garbage collector (GC) interface. (JEP 307) Parallel Full GC for G1: Improves G1 worst-case latencies by making the full GC parallel. (JEP 301) Application Data-Class Sharing: To improve startup and footprint, this JEP extends the existing Class-Data Sharing ("CDS") feature to allow application classes to be placed in the shared archive. (JEP 312) Thread-Local Handshakes: Introduce a way to execute a callback on threads without performing a global VM safepoint. Makes it both possible and cheap to stop individual threads and not just all threads or none. (JEP 313) Remove the Native-Header Generator Tool: Remove the javah tool from the JDK since it has been superseded by superior functionality in javac. (JEP 314) Additional Unicode Language-Tag Extensions: Enhances java.util.Locale and related APIs to implement additional Unicode extensions of BCP 47 language tags. (JEP 316) Heap Allocation on Alternative Memory Devices: Enables the HotSpot VM to allocate the Java object heap on an alternative memory device, such as an NV-DIMM, specified by the user. (JEP 317) Experimental Java-Based JIT Compiler: Enables the Java-based JIT compiler, Graal, to be used as an experimental JIT compiler on the Linux/x64 platform. (JEP 319) Root Certificates: Provides a default set of root Certification Authority (CA) certificates in the JDK. (JEP 322) Time-Based Release Versioning: Revises the version-string scheme of the Java SE Platform and the JDK, and related versioning information, for present and future time-based release models. The Java ecosystem continues to be a diverse collection of developers and we welcome their ongoing participation in helping to shape the future of Java.  Please join the OpenJDK project to help move Java forward faster.  

Download Now Over the past 22 years, Java has grown into a vibrant community that has reached a scale without equal.  Java continues to bring value to developers and to enterprises worldwide. ...

The Future of JavaFX and Other Java Client Roadmap Updates

Starting with JDK 11, Oracle is making JavaFX easier to adopt by making the technology available as a separate download, decoupled from the JDK. These changes clear the way for new contributors to engage in the open source OpenJFX community. Meanwhile, Oracle customers can benefit from continued commercial support for JavaFX in the Oracle JDK 8 through at least 2022. JavaFX was publicly unveiled at JavaOne 2007. It was immediately compared with Adobe Flex and Microsoft Silverlight for its scripting and cross platform hardware-accelerated UI abilities.  The technology was fully open-sourced in 2011, and became part of the Oracle JDK download a year later. Under Oracle’s stewardship, it continued evolving in the OpenJDK community, attracting a passionate following of its own as a cross-platform desktop application toolkit. JavaFX has found an audience among developers and ISVs producing unique desktop applications and solutions for specific markets blending together multimedia, web and visualization technologies. There are a number of open source libraries, frameworks and tools available to developers. With the Java Platform Module System in place since Java SE 9, it now more viable to decouple JavaFX from the JDK, in order to make it available as a separate download.  This will make it easier for developers using JavaFX to have more freedom and flexibility with the framework.  Moreover, with our focus on increasing the release cadence of OpenJDK, JavaFX needs to be able to move forward at a pace driven by the contributions from Oracle and others in the OpenJFX community. Oracle plans to implement this decoupling starting with Java 11 (18.9 LTS).  A few weeks ago, Oracle announced the extension of Java 8 public updates through at least January 2019 and through 2020 for personal (non-corporate) use.   More details are now available in this white paper.  The white paper also provides additional information on Applets and Web Start support on Java SE 8 as they will not be included in Java 11 (18.9 LTS).  Finally, there is more information about the road map for JavaFX Including Oracle’s plans to ship and support JavaFX in Oracle JDK 8 at least through 2022. Developers interested in OpenJFX can subscribe to the mailing list.  

Starting with JDK 11, Oracle is making JavaFX easier to adopt by making the technology available as a separate download, decoupled from the JDK. These changes clear the way for new contributors...

Convergence Of Oracle Java SE Embedded With Oracle JDK

Over the past years, Oracle has been working in the OpenJDK Community and the JCP to enable Java SE in general, and Oracle JDK in particular, to scale down to smaller devices. A first step was to introduce Compact Profiles to Java SE 8. This feature is available in Oracle Java SE 8 Embedded.  The next step was to introduce a module system to Java SE 9 through project Jigsaw.  Using the new jlink tool, a set of user-supplied modules and their runtime dependencies can be assembled and optimized into a custom run-time image, containing just the JDK 9 modules required by the application to run. This feature offers even more fine-grained control over an application's runtime footprint than Compact Profiles. Interested developers can try this and many other JDK 9 features and contribute to their development through the OpenJDK Community. JDK 9 also introduces a new experimental static “Ahead of Time – AOT” (JEP 295) enhancement to the Java platform. This new compilation tool will facilitate (over time) the creation of compact and statically linked images that will demand much less dynamic JVM infrastructure.  AOT will enable significant reduction of runtime footprint requirements for Java applications as well as drastically improving startup performance. Oracle has contributed this new AOT compiler to the OpenJDK Community. In the past year Oracle has also contributed a unified port of HotSpot for 32-bit and 64-bit ARM platforms for JDK 9 to the OpenJDK Community.  This contribution was done through and with the assistance of the existing 32-bit AArch32 Port Project in OpenJDK, which complements the OpenJDK 64-bit AArch64 Port Project. Last but not least, Oracle created the OpenJDK Mobile Project to focus on porting the JDK to popular mobile platforms such as iOS, Android, and Windows. Having opened up the relevant Oracle Java SE Embedded ports, the open source Java SE Embedded community can now continue to innovate and collaborate on JDK 9 as part of a vibrant open source community. Accordingly, starting with JDK 9, Oracle doesn't plan to offer a separate "Oracle Java SE Embedded" download.  In other words, Oracle Java SE 8 Embedded is the final release series of the "Oracle Java SE Embedded" product.  New features in JDK 9 obviate the need for it to be a separate product.

Over the past years, Oracle has been working in the OpenJDK Community and the JCP to enable Java SE in general, and Oracle JDK in particular, to scale down to smaller devices.A first step was to...

Faster and Easier Use and Redistribution of Java SE

Exec Summary: Oracle is proposing to increase the release cadence of Java SE to every six months Oracle will simplify how developers, customers, and consumers use Java SE Starting with JDK 9 GA Oracle plans to ship OpenJDK builds under the GPL Oracle has proposed a time-driven release model for Java SE instead of the historical feature-driven model Oracle JDK will contribute previously commercial features such as Java Flight Recorder to OpenJDK Oracle will work with other OpenJDK contributors to make the community infrastructure complete, modern and accessible The Oracle JDK will continue as a commercial long term support offering The Oracle JDK will primarily be for commercial and support customers once OpenJDK binaries are interchangeable with the Oracle JDK (target late 2018) Oracle will continue to enhance the packaging and distributing of complete ready-to-run applications Introduction The cloud has changed how modern applications are being developed, deployed and consumed. On the client side, ready-to-run mobile-first native applications and HTML5/JS web interfaces are increasingly prevalent.  On the cloud side, “applications” are transitioning to container-based, modular microservices and even functions.  Developers expect more frequent release cycles and flexible licensing. Java continues to be one of the most popular development and application platforms in the world.  The build, release, licensing and distribution model for Java SE is well over a decade old, and will be refreshed to support the changing needs driven by the cloud for the future. To this end we are proposing a number of changes to how Java SE is produced and distributed. Introducing OpenJDK builds under the GPL from Oracle Oracle plans to ship OpenJDK builds to make it easier for developers to deploy Java applications to cloud environments.  We will initially offer Linux x64 binaries and add macOS and Windows later.  These will be licensed under the GPLv2 with the “Classpath Exception”, allowing developers to easily and freely distribute them with their frameworks and applications. Oracle will also open source commercial features such as Java Flight Recorder previously only available in the Oracle JDK.  We plan to open source a number of additional internal development projects after proposing and discussing with OpenJDK contributors.  While we know there will initially be differences, our intent is that within a few releases there should be no technical differences between OpenJDK builds and Oracle JDK binaries.  To achieve this, Oracle will work with other OpenJDK contributors on an open build-and-test infrastructure with the potential to support additional ports. Ongoing Oracle JDK Support Oracle will continue to build and ship the Oracle JDK.  Oracle JDK 8 will continue to receive public updates for at least the next year, and commercial support will be available through 2025.  As OpenJDK binaries become the primary channel for developers to access the latest innovation in the Java SE platform, the Oracle JDK will remain as a long term support (LTS) offering for Oracle’s commercial and support customers. Commercial Features packaged separately from the Oracle JDK, such as the Advanced Management Console, will continue to be provided separately through Oracle’s “Java SE Advanced” commercial offering. As client application development continues to shift from the old “plugin” world to modern deployment, the need for a standalone Java Runtime Environment (JRE) that is installed centrally, separately from Java applications has diminished.  Using the ‘jlink’ tool introduced with JDK 9 will make it even easier for application developers to package and deploy dedicated runtimes rather than relying on a pre-installed system JRE.  Oracle will begin transitioning from the standalone architecture later next year in what will be a multi-year effort.  

Exec Summary: Oracle is proposing to increase the release cadence of Java SE to every six months Oracle will simplify how developers, customers, and consumers use Java SE Starting with JDK 9 GA Oracle...

Understanding the Server JRE

The Java SE download Page offers downloads of the Java Runtime Environment (JRE), the Server JRE, and the Java Development Kit (JDK). The JRE is used to run a broad variety of Java programs including Java applications on desktops.  The JDK is for Java developers. It contains a complete JRE as described above and tools required to create Java programs, sign code, generate documentation, etc. The JDK also ships several tools meant to monitor and debug programs. So where does the Server JRE fit in?  From the perspective of common server-side applications, the JRE is missing monitoring tools and, in the case of applications that compile Java source code at run-time, javac. On the other hand, the JDK includes additional functionality that system administrators may not need on their production systems like the Java Plugin for web browsers, auto update agents, and development tools like javadoc. Enter the Server JRE: The Server JRE was designed for server-side applications by including just the commonly required features from the JRE and JDK. The Server JRE does not have a dedicated installer: It is simply a compressed directory for easier use. Will the Server JRE work for all server applications? No. If an application requires functionality outside of what is provided in the Server JRE, such as additional development tools or JavaFX, then the Server JRE would not be an adequate choice for that application. If the JDK is a super-set of the Server JRE, why not simply use that? Removing unused components decreases the potential attack surface, and the smaller size makes storage and deployment faster and easier.  On a Linux x64 system, the Server JRE 8 is around 40% of the size of the full JDK 8. My software vendor claims their applications needs the JDK, but can I use the Server JRE instead? Please contact your software vendor and ask them if you may use the Server JRE instead of the full JDK.  If you have the ability to experiment – you should try it.  The Server JRE is always recommended where possible over the JDK for running applications. Can I suggest changes for what is included in the Server JRE? Yes. The goal of the Server JRE is to provide the tools needed by most, but admittedly not all, server applications. We are constantly re-evaluating which components are included. Please send us your feedback through the usual Oracle Community channels.  

The Java SE download Page offers downloads of the Java Runtime Environment (JRE), the Server JRE, and the Java Development Kit (JDK). The JRE is used to run a broad variety of Java programs including...

Java Platform Group, Product Management

Java Advanced Management Console 2.7

Java Platform Group is pleased to announce the release of Java Advanced Management Console 2.7 (AMC) on 18th July 2017. AMC, part of Oracle Java SE Advanced product offering, offers system administrators greater and easier control in managing Java installations across enterprises. Some of the most important features of AMC are: Java Usage Tracking: AMC leverages Java’s usage tracking feature to get complete insight into the use of Java applications in an enterprise and the Java Runtime Environment (JRE) used for running those applications. AMC has agents for Microsoft Windows and macOS systems. The agent will discover all available JREs and will automatically enable usage tracking on them. Supported JRE versions are 1.4.2_35 or later, 5u33 or later, 6u25 or later, and any version of 7 and 8. AMC agents running on each managed desktop collect the information on available JREs. This information is used by the AMC server to report on JREs below security baseline, total number/ versions of JREs available and the deployment ruleset details available in each desktop (details). Deployment Rule Set Management: Deployment Rule Set allows organizations to manage Java Applets and Webstart applications by centrally defining and managing the version of JRE used to run those applications. AMC can also be used to create, configure and distribute Deployment Rule Sets (DRS) across desktops. Administrators can use this to maintain a blacklist/ whitelist of applications by configuring specific Java versions to be used only for known & safe programs (details). Java Installer Customization: AMC enables administrators to set up installer packages (MSI for Microsoft Windows and PKG for macOS) for the JRE. These customized installers enable system administrators to manage an automated, consistent installation of the JRE across all desktops in the enterprise. AMC helps administrators to create configuration files and custom installers by defining custom post-install/ pre-install scripts, default install location etc. JRE Management: With the JRE version information available from the AMC agents, an administrator can remotely uninstall outdated JREs and may also push installation of custom MSI/ PKG to selected target desktops. AMC 2.7 includes a number of enhancements and fixes to better monitor and manage Java in enterprises. Some of them are as listed below: Non-enterprise Java installer support to help install non-customizable JREs on desktops, (EXE installers on Microsoft Windows and DMG installers on macOS). Dynamically modified desktop groups will be now automatically updated. In addition, AMC 2.7 also allows desktop groups to be created based on IP ranges rather than based on individual IPs. AMC 2.7 agents can now detect Java SE 9 installations on managed desktops. Users can search for Java SE 9 installations on managed desktops and can also search for applications that run on Java SE 9 in the console. (Please note that AMC can’t be deployed on Oracle WebLogic server running Java SE 9). Container-based user authentication allows customers to configure user authentication in the Oracle WebLogic server and leverage it in AMC. Improved administrative features to choose which JRE types to track on managed desktops (web-enabled JREs/ all standalone JREs/ all JREs, including private JREs) turn off automatic agent updates so that administrators can choose how they want to update their agents on managed desktops turn off Java auto update so that administrators can control the install/ uninstall of JRE on managed desktops export to file option for failed JUT records For more details on new features, limitations and known issues, please refer to the AMC 2.7 release notes.

Java Platform Group is pleased to announce the release of Java Advanced Management Console 2.7 (AMC) on 18th July 2017. AMC, part of Oracle Java SE Advanced product offering, offers...

Java SE support for Docker CPU and memory limits

Special thanks to Charlie Hunt, contributor to multiple OpenJDK projects for providing much of the content of this blog. As a follow-up to our blog announcing OpenJDK Project Portola, a project to provide a port of the JDK to Alpine Linux, there are several enhancements coming to Java SE that also fit with Docker and Alpine Linux’s slogan, "Small, Simple. Secure." Two worth mentioning are: Support of Docker CPU and memory limits. Project Jigsaw’s jlink, which offers the ability to produce a minimal JRE based the modules the application uses or requires (we'll cover jlink in a downstream blog). Docker image for Oracle Server JRE is now available on Docker Store Java SE support for Docker CPU and memory limits For those who have been using Docker’s CPU and memory limits with Java applications may have experienced some challenges. In particular CPU limits since the JVM internally and transparently sets the number of GC threads, and JIT compiler threads. These can be explicitly set via command line options, -XX:ParallelGCThreads and -XX:CICompilerCount. For memory limits, the maximum Java heap size can also be set explicitly via JVM command line option, -Xmx. However, in cases where none of the aforementioned JVM command line options are specified, when a Java application using Java SE 8u121 and earlier, when run in a Docker container, the JVM will use the underlying host configuration of CPUs and memory when transparently determining the number of GC threads, JIT compiler threads and maximum Java heap to use. As of Java SE 8u131, and in JDK 9, the JVM is Docker-aware with respect to Docker CPU limits transparently. That means if -XX:ParalllelGCThreads, or -XX:CICompilerCount are not specified as command line options, the JVM will apply the Docker CPU limit as the number of CPUs the JVM sees on the system. The JVM will then adjust the number of GC threads and JIT compiler threads just like it would as if it were running on a bare metal system with number of CPUs set as the Docker CPU limit. If -XX:ParallelGCThreads or -XX:CICompilerCount are specified as JVM command line options, and Docker CPU limit are specified, the JVM will use the -XX:ParallelGCThreads and -XX:CICompilerCount values. For Docker memory limits, there is a little more work for the transparent setting of a maximum Java heap. To tell the JVM to be aware of Docker memory limits in the absence of setting a maximum Java heap via -Xmx, there are two JVM command line options required, -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap. The -XX:+UnlockExperimentalVMOptions is required because in a future release transparent identification of Docker memory limits is the goal. When these two JVM command line options are used, and -Xmx is not specified, the JVM will look at the Linux cgroup configuration, which is what Docker containers use for setting memory limits, to transparently size a maximum Java heap size. FYI, Docker containers also use cgroups configuration for CPU limits too. These two modifications in Java SE 8u131 and JDK 9 are expected to improve the Java running in Docker experience. The work for both of these enhancements have been tracked in OpenJDK as follows: Docker CPU limits Experimental support for Docker memory limits Docker memory limits

Special thanks to Charlie Hunt, contributor to multiple OpenJDK projects for providing much of the content of this blog. As a follow-up to our blog announcing OpenJDK Project Portola, a project to...

Even Further Updates to 'Moving to a Plugin Free Web'

Several months ago we published Further Updates to Moving to a Plugin Free Web.  Since then, Firefox 52 was released in March 2017) dropping support for NPAPI, impacting plugins for Java, Silverlight, and other similar NPAPI based plugins. If you have problems accessing Java applications using Firefox, Oracle recommends using Internet Explorer (Windows) or Safari (Mac OS X) instead. But even then, developers and system administrators should be quickly migrating away from Applets,using Web Start applications as a stop gap. There is, however, a final interim step that can be used for organizations relying on Firefox via the Firefox 52 ESR 32-bit release.  Mozilla offers an Extended Support Release (ESR) version of Firefox specifically for use by organizations who need extended support for mass deployments. Only Mozilla Firefox 52 ESR 32-bit release will continue offering support for the standards-based plugin support technology required to launch Java Applets. To see if you are using an ESR release, check the Firefox menu item (Help -> About) and looking for the "ESR" identifier. Mozilla maintains Firefox ESR Releases for approximately one year. Developers and users still relying on the Java plugin technology in the 32-bit Mozilla Firefox web browser should consider migrating to a different solution ASAP.

Several months ago we published Further Updates to Moving to a Plugin Free Web.  Since then, Firefox 52 was released in March 2017) dropping support for NPAPI, impacting plugins for Java,...

Further Updates to 'Moving to a Plugin-Free Web'

About a year ago we wrote a post announcing plans to deprecate the Java browser plugin in JDK 9 due to browser vendors moving away from the standards-based NPAPI plugin support technology required to launch Java Applets. Since then, the Oracle development team has published a JDK Enhancement Proposal (JEP 289: Deprecate the Applet API) with technical details about the planned deprecation step in JDK 9. In addition, updated timelines for removal of standards-based plugin support from their browsers, eliminating the possibility to embed Java and other plugin based technologies, have been announced by the developers of Apple's Safari and Mozilla's Firefox. In accordance with their timeline, starting with Mozilla Firefox 52, due to release in March 2017, the 32-bit version of Mozilla Firefox will no longer provide the requisite APIs for standards based plugin support. The 64-bit version of Mozilla Firefox for Microsoft Windows launched without support for most NPAPI-based plugins including Java.  Mozilla offers an Extended Support Release (ESR) version of Firefox specifically for use by organizations who need extended support for mass deployments. Only the Mozilla Firefox 52 ESR 32-bit release will continue offering support for the standards-based plugin support technology required to launch Java Applets. Note that there is no way, on the server side, to distinguish between the general version and the ESR version of Firefox.  Affected users may need further instructions on how to tell if they are using an ESR release (via "Help Menu -> About"  and looking for the "ESR" identifier in Firefox 52) rather than developers implementing a server-side check for this. Mozilla maintains Firefox ESR Releases for approximately one year. Developers and users still relying on the Java plugin technology in the 32-bit Mozilla Firefox web browser should consider migrating to a different solution. More background and information about different migration options can be found in this short whitepaper from Oracle.

About a year ago we wrote a post announcing plans to deprecate the Java browser plugin in JDK 9 due to browser vendors moving away from the standards-based NPAPI plugin support technology required to...

Java SE Offerings

The Javaecosystem is incredibly diverse.  Itpowers billions of devices and servers. It is key to cloud infrastructure worldwide. Even just the Java Platform, Standard Edition, “Java SE”,which is the core Java platform for general computing, is itself diverse. We on theJava Platform Group at Oracle think of our work on “Java SE” in four mainareas, described below. 1) OpenJDK. OpenJDK isthe place we collaborate on an open-source implementation of the Java Platform,Standard Edition, and related projects.  Our commitment to OpenJDK remainsas strong as ever and we even recently kicked off the JDK 10 project there.OpenJDK enjoys broad participation across the ecosystem. It has consistentlygrown in activity since Oracle acquired Sun. For example, most major Linux distributors and other parties such as Red Hat,Canonical and SUSE produce and ship binaries based on this opensourcecode.  The source code is available under the popular GNU General PublicLicense v2, i.e. it's completely gratis. Commercial source licenses arealso available for companies that would like to license the source code for amultitude of purposes, and dozens have, such as HP, SAP, IBM and others whoproduce their own commercial Hardware/OS products for which they'd like to havea commercial grade Java SE port available. 2) Oracle's Java SE implementation, aka"Oracle JDK" and "Oracle JRE".  The Oracle JRE/JDKis Oracle's implementation of Java SE.  Just as many other companies (likeSAP, Red Hat, IBM, HP, etc) provide their implementations of Java SE to theircustomers, so does Oracle.  We have two main channels for our binarydistributions -- java.com is for consumers who may want to run the Java RuntimeEnvironment (JRE) on their home computers for applications like Minecraft or other Java based consumer software, and the Java Development Kit(JDK) on OTN which is targeted to developers and enterprises.  These binaries aregratis for the vast majority of use cases as noted in java.com/license.  3) Oracle Java SE Advanced, JavaSE Advanced Desktop, Java SE Suite.  In addition to Oracle's core Java SEimplementation, Oracle also provides additional advanced tools and features that targetenterprise users. These features include the tools to help monitor, manage and deploy Java withinan enterprise, advanced runtime diagnostics and monitoring, as well as accessto support and updates to legacy versions of Java SE such as Java SE 6, andJava SE 7. These commercial features areprovided as separate downloads available via “My Oracle Support” or OTN, and tothe degree they need to interact with the Oracle JRE, they are turned off bydefault in that product, and can be enabled using the "-XX:+UnlockCommercialFeatures"flag at runtime in your JVM, for example. More information on specific commercial features can be found in Table1-1 here.  4) Java SE embedded.  Asnoted in (2), the Oracle JRE/JDK is gratis for most use cases, where it isrunning on a General Purpose desktop or server.  If a customer would liketo embed the Oracle JDK/JRE in a device of some kind (eg, a cash register) thenthe gratis BCL license does not apply. In such cases a commercial Java SEembedded license needs to be negotiated. Java SE embedded also provides additional binary options for resourceconstrained devices and more embedded oriented chip sets.

The Java ecosystem is incredibly diverse.  It powers billions of devices and servers. It is key to cloud infrastructure worldwide. Even just the Java Platform, Standard Edition, “Java SE”,which is the...

Oracle JRE will no longer trust MD5-signed code by default

Update notice When this blog post was originally posted the change was scheduled to occur with the January 2017 Critical Patch Update. In response to requests for additional time to prepare for this change Oracle now plans to deliver this change with the April 2017 Critical Patch Update. The post has been updated accordingly.   Beginning with the April 2017 Critical Patch Update, JAR files signed using MD5 will no longer be considered as signed by the Oracle JRE. Affected MD5-signed JAR files will no longer be considered trusted and as a result will not be able to run by default, such as in the case of Java applets, or Java Web Start applications. This change in the JRE behavior is required because MD5 is no longer considered secure and is widely considered unsuitable for security use.  In fact, the MD5 with RSA algorithm stopped being the default JAR signing option with Java SE 6 released back in 2006.  It is critical that weak hashing algorithms (such as MD5) be deprecated when they are known to be weak so as to maintain the trust in the verification mechanism they provide.   This change affecting MD5-signed JARS will be enabled by default no sooner than with Oracle Java SE 8u131 which will be released with the April 2017 Critical Patch Update, as well as in the corresponding releases of Oracle Java SE 7, Oracle Java SE 6 and Oracle JRockit R28, which will be available to qualified customers through My Oracle Support. In order to prepare for this upcoming change, developers need to verify that their JAR files have not been signed using MD5.  You can do this with your own JARs by verifying your build process signs JARs using Java 6 or later without having deliberately chosen MD5.  If you are using JARS you did not sign or build yourself, you need to contact your vendor for more information.  If it can no longer be established if a JAR you are using has been signed with MD5, the recommended practice is to re-sign affected JAR files using a more modern algorithm.  Be sure to remove any existing MD5 signatures first before re-signing using the zip utility as follows: zip -d test.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA' More technical information can be found in the October 2016 Critical Patch Update Release Notes for Java SE. Oracle has already informed a number of software vendors, including source licensees, of the upcoming changes.  Users concerned about the effect of this change on third party applications should contact their respective vendor. Cryptography is a dynamic field.  In order to keep users and developers informed about upcoming changes in this area, Oracle has recently published a new web page at java.com/cryptoroadmap.  This page provides information about upcoming cryptographic changes in Oracle JRE and Oracle JDK, and related technical instructions.

Update notice When this blog post was originally posted the change was scheduled to occur with the January 2017 Critical Patch Update. In response to requests for additional time to prepare for this...

JavaOne 2016 Call for Proposals

JavaOne 2016 has opened its Call for Proposals to speak at the conference. This year, security topics take place in the Core Java Platform track. Speaker Proposals must be submitted by May 9th. The conference itself takes place from September 18-22 in San Francisco. Accepted speakers will receive a gratis pass to attend. Before each JavaOne conference, we receive a number of great submissions from Java community members around the globe, about different security topics. Our review committee also tries to call attention to help solicit interesting proposals and guide speakers. If you are familiar with running or coding Java and want to speak at JavaOne, consider applying your expertise to the following areas: Architecture & Analysis – how should security architects and developers build/integrate applications to evaluate and verify security? How does this change for green-field versus inherited applications? How should you build and maintain a threat model of an application and its environment? (bonus for breaking a threat model down into JDK 9 jigsaw modules) What is the importance of library code, and how/when/why should it be updated? What are strategies to test compatibility? When micro-services are connected, how does that impact trust boundaries? Development – how can developers evaluate and test their own applications? Code analysis (both for what you write and use) Penetration testing or scanning of Java applications There are many different secure development standards frameworks. What are they and how can they be used to test applications? Operations – when running Java, what are the proper strategies for configuring, managing, and upgrading JVMs? What are strategies between minor versions (e.g. 8uA to 8uB) and major versions (e.g. from JDK 8 to JDK 9)? How is the compatibility guide used? What are monitoring strategies to analyze JVM security events? What are connections between current logging frameworks and/or the planned Unified Logging API for JDK 9? How should a JVM or Java web server be tuned to achieve an A+ rating on SSL Labs? What about TLS for non-HTTPS uses, such as JDBC?For helpful tools, see Diagnosing TLS, SSL, and HTTPS as well as Deep Violet. Other ideas – there are many great ideas in the Java ecosystem, so please submit yours!

JavaOne 2016 has opened its Call for Proposals to speak at the conference. This year, security topics take place in the Core Java Platform track. Speaker Proposals must be submitted by May 9th. The...

G1: from garbage collector to waste management consultant

Java’s garbage collection capabilities make it easier for developers to write software and focus on the task at hand, without focusing on freeing up unused memory. In JDK 9, the G1 garbage collector will likely become the default collector and can do more than simply freeing memory. Instead of a simple garbage collector to free up memory, G1 takes the role of a waste management consultant: freeing unused memory and identifying ways to reduce the overall amount of garbage. String Deduplication may decrease heap usage by about 10% String objects are among the most commonly used object by almost all applications. Applications often store the same String multiple times for a variety of reasons, either within one class or across many classes. By analyzing these Strings, the JDK can decrease the overall memory needed to store them.String Deduplication may decrease heap usage by about 10% String deduplication was first introduced in JDK 8 update 20 and operates as a background task. As the G1 garbage collector walks through memory references to clean up, it analyzes Strings to find duplicates and create memory-saving links between them. Similar to other garbage collection tasks, developers do not need to modify any code in order for it to work. An analysis by Fabian Lange from Codecentric found that String deduplication “adds no runtime overhead as it is performed asynchronously and concurrent during garbage collection.” The following flags are needed to enable String Deduplication on JDK 8: -XX:+UseG1GC Enables the G1 garbage collector. -XX:+UseStringDeduplication Enables the String Deduplication feature within G1. -XX:+PrintStringDeduplicationStatistics Optional flag to analyze what is happening through the command-line. -XX:StringDeduplicationAgeThreshold=3 Optional flag to change when Strings become eligible for deduplication. Example: Decreasing memory used by the Eclipse IDE Eclipse is a popular Integrated Development Environment, helping developers read, write, and construct source code. The G1 garbage collector will typically perform better for long-running applications focused on throughput (e.g. servlet containers), but it can also function well for client applications. The following example was run on JDK 8u72 with Eclipse Mars. I am also turning on a Java Flight Recording to see the impact on garbage collection, object allocation, and overall memory consumption. I ran the same operations twice: once without –XX:+UseStringDeduplication and the filename of before.jfr, so that I could do somewhat of a comparison. The following lines can go inside your eclipse.ini at the end:The following lines can go inside your eclipse.ini at the end: -XX:+UseG1GC-XX:+UseStringDeduplication#The lines below are not necessary for G1, I am including them to benchmark the difference-XX:+UnlockCommercialFeatures-XX:+FlightRecorder-XX:StartFlightRecording=filename=after.jfr,dumponexit=true,maxage=5m,settings=c:/Users/ecostlow /desktop/Everything-Costlow.jfc-XX:FlightRecorderOptions=dumponexit=true,disk=true,maxage=10m As a background task, String deduplication was taking about 0.0000908 seconds during my brief usage. It probably took longer to print statistics. Although my laptop is not a controlled environment and I manually did the same actions, the overall heap usage went down about 9% from 233MB to 213MB during my five minutes of usage. Here are the details from the final output of the String Deduplication Statistics (using -XX:+PrintStringDeduplicationStatistics) with some cumulative numbers: [GC concurrent-string-deduplication, 14.5K->6120.0B(8744.0B), avg 38.6%, 0.0000908 secs]   [Last Exec: 0.0000908 secs, Idle: 0.8590383 secs, Blocked: 0/0.0000000 secs]      [Inspected:             142]         [Skipped:              0(  0.0%)]         [Hashed:              89( 62.7%)]         [Known:               21( 14.8%)]         [New:                121( 85.2%)     14.5K]      [Deduplicated:           96( 79.3%)   8744.0B( 58.8%)]         [Young:                0(  0.0%)      0.0B(  0.0%)]         [Old:                 96(100.0%)   8744.0B(100.0%)]   [Total Exec: 52/0.1772395 secs, Idle: 52/103.0713572 secs, Blocked: 2/0.1476086 secs]      [Inspected:          322160]         [Skipped:              0(  0.0%)]         [Hashed:          164740( 51.1%)]         [Known:            61960( 19.2%)]         [New:             260200( 80.8%)     20.3M]      [Deduplicated:       144975( 55.7%)   8037.4K( 38.6%)]         [Young:                2(  0.0%)     72.0B(  0.0%)]         [Old:             144973(100.0%)   8037.3K(100.0%)]   [Table]      [Memory Usage: 4213.1K]      [Size: 131072, Min: 1024, Max: 16777216]      [Entries: 132446, Load: 101.0%, Cached: 3622, Added: 170306, Removed: 37860]      [Resize Count: 7, Shrink Threshold: 87381(66.7%), Grow Threshold: 262144(200.0%)]      [Rehash Count: 0, Rehash Threshold: 120, Hash Seed: 0x0]      [Age Threshold: 3]   [Queue]      [Dropped: 0]

Java’s garbage collection capabilities make it easier for developers to write software and focus on the task at hand, without focusing on freeing up unused memory. In JDK 9, the G1 garbage collector...

Java Advanced Management Console 2.2

Today, the Java Platform team is pleased to release Java Advanced Management Console version 2.2.  Available for production use with appropriately licensed Java SE Advanced products, the Advanced Management Console helps system administrators track and manage Java across their organization. Its usage tracking capabilities help system administrators create a Java application inventory to know which Java versions are used for which applications, and by whom. Administrators can then manage exposure of the browser plugin: allowing known-safe applications to run against older Java versions based on compatibility, and potentially blocking unknown applications altogether. This newest version of Advanced Management Console makes a number of improvements designed to streamline Java usage across client endpoints across a large organization: This version supports zero-configuration endpoints to better handle cases of multi-user systems and walk-up terminals. In previous versions, each agent installation needed a post-install configuration to identify the user. In AMC 2.2, this step is optional and the system offers more visibility on the hostname.Another streamlining capability helps simplify the certificates used by endpoints to verify the Deployment Rule Set. When installed, the DeploymentRuleSet.jar file must be signed by a trusted certificate. A number of organizations use self-signed certificates or act as their own internal certificate authority. As clients download updated Deployment Rule Set files from a trusted Advanced Management Console server, clients will apply transitive trust and import the Deployment Rule Set’s certificate. As a result of this change, systems will see fewer cases of "DeploymentRuleSet.jar is not valid."If your organization is looking to manage the security and compatibility of many different Java versions, please download an evaluation copy of the Advanced Management Console.

Today, the Java Platform team is pleased to release Java Advanced Management Console version 2.2.  Available for production use with appropriately licensed Java SE Advanced products, the Advanced...

A New JDK 9 Version String Scheme

One of the smaller, but rather important planned changes for JDK 9 is an updated JDK version string scheme. It is described in detail in JEP 223. The new version string scheme makes it easier to distinguish major, minor and critical patch update (CPU) releases, by encoding each property into a separate numerical component as part of a JDK version string. Following the new MAJOR.MINOR.SECURITY convention, JDK 9 version strings would start with ‘9’ for the MAJOR release component. For example, if the JDK 9 GA release (with the version string: ‘9’) were to be followed by a CPU, then that CPU would carry the version string ‘9.0.1’. If that CPU were to be followed by a minor release with additional changes on top of those already found in the ‘9.0.1’ release, than the new release would carry the version string ‘9.1.1’. If in turn, that minor release were to be followed by another CPU, the new CPU would be designated as ‘9.1.2’, leading to the following hypothetical sequence of release versions:  9  GA  9.0.1  CPU: 9 + critical changes  9.1.1  Minor release: 9.0.1 + other changes  9.1.2  CPU: 9.1.1 + critical changes  9.2.2  Minor release: 9.1.2 + other changes  9.2.3  CPU: 9.2.2 + critical changes  9.2.4  CPU: 9.2.3 + critical changes  9.3.4  Minor release: 9.2.4 + other changes The individual components of the version string would start at 0 and then increase based on the type of a release, making it easy to check whether a local installation meets a given security baseline by looking at the third, i.e. SECURITY, component of the JDK 9 version string. Due to the changes in the version string scheme, code that parses JDK version strings could need to be adjusted - for example if it assumes that the first element of a JDK version string always has the value of ‘1’ (as in ‘1.9.0_ea-b19’), and therefore always skips to the second element when comparing releases. Details on the adjustments can be found in the JEP text. In addition, the JEP text describes other types of information that can be encoded in a JDK 9 version string, like build numbers, as in ‘9.0.1+63’. Developers, who would like to test the planned changes, can do so by downloading a JDK 9 Early Access Build at jdk9.java.net. Feedback on the planned version string scheme changes should be directed to the verona-dev mailing list.

One of the smaller, but rather important planned changes for JDK 9 is an updated JDK version string scheme. It is described in detail in JEP 223. The new version string scheme makes it easier to...

Strengthening Signatures part 2

The scheduled Critical Patch Update of Oracle Java SE on January 19 2016 is planned to disable X.509 certificates signed with MD5. Plans are also being developed to disable X.509 certificates signed with SHA-1 and further details will be announced in a future post.Specifically, this change will treat certificate chains containing a certificate with an MD5-based signature to be invalid and blocked by default. This affects Java clients and servers using TLS (via the JSSE API), signed applets and Web Start applications, and any application using the PKIX implementation of the CertPath API to validate certificate chains.This was previously covered in a post, Strengthening Signatures, and is similar to announcements from other platform providers like Microsoft, which deprecated MD5 in June 2014 and is focusing on SHA-1 efforts for 2016.System Administrators wanting to test their systems can update their JAVA_HOME/lib/security/java.security file and add MD5 into jdk.certpath.disabledAlgorithms.Change "jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024" to "jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024"After this change, the MD5 algorithm will still be available for other non-certificate uses. For example applications that use MessageDigest.getInstance("MD5") for alternate reasons will continue to function.For System Administrators that must re-enable the weaker MD5 algorithmIn cases where a system authenticates itself through MD5 signatures, system administrators are encouraged to generate newer certificates that use SHA-256 or higher.Users are encouraged to accept the default security settings and not re-enable MD5 in X.509 certificates. However, if necessary, MD5 can be re-enabled in either of the following ways: Option A (preferred if weak MD5 is needed), by using a startup flag that will only impact specific applications.Create a file that copies the jdk.certpath.disabledAlgorithms line from JAVA_HOME/lib/security/java.securityRemove MD5 from that lineIn your startup command, add -Djava.security.properties=FILEPlan your migration away from weak algorithms and undoing this change. Option B, editing a configuration file that will affect all applications used by a JRE:Open JAVA_HOME/lib/security/java.securityRemove MD5 from the line jdk.certpath.disabledAlgorithmsPlan your migration away from weak algorithms and undoing this change.SHA-1 plansWe are also working with industry groups on a plan to migrate away from certificates signed with SHA-1. The Certificate Authority Browser Forum previously set guidance to avoid issuing new SHA-1 certificates after January 2016. This guidance assists in our planning, as well as that of peer programs such as Microsoft, Mozilla, and Google. 

The scheduled Critical Patch Update of Oracle Java SE on January 19 2016 is planned to disable X.509 certificates signed with MD5. Plans are also being developed to disable X.509 certificates signed...

When is the next Java update?

"Java update available -- a new version of Java is ready to be installed..."This occurs four times a year: January, April, July, and October.Oracle Java SE is updated on the Oracle Critical Patch Update schedule. The date for these updates is published a year in advance. This schedule helps system administrators manage software across a fleet of systems. Combined with another feature, the security baseline, client systems can detect newer security updates and adjust their behavior by offering an update and decreasing the client’s attack surface. System Administrators can use Deployment Rule Sets to control compatibility if they need a version below the security baseline. The Security Baseline The security baseline received new behavior in Java 7 update 10 (December 2012), combining it with the JRE expiration date. Prior to this, it has identified which Java versions contain the latest security patches since JDK 1.4. There is a different baseline version for each major Java version: Java 6, Java 7, and Java 8. The JRE will identify that it should be updated in two main ways: The JRE will periodically check the security baseline to see if a new version is available. If it detects that it is below the security baseline, it will consider itself to require an update to a version that meets the security baseline requirement.The schedule for this periodic check can be controlled by system administrators. If clients cannot obtain the security baseline for any reason, they will eventually reach their built-in expiration date. This expiration date is published in every release note, but it is typically a month after the next scheduled critical patch update.This expiration date is built in and cannot be controlled. For example at time of writing (November 2015), the current security baseline for Java 8 is 1.8.0_65. The next scheduled Critical Patch Update is January 19th. The expiration date for Java 1.8.0_65 is February 19th. In addition to Critical Patch Updates, there is another release type called a Patch Set Update(PSU), which contains additional non-critical changes. Although a PSU version is numerically “above” the security baseline, the PSU contains the exact same critical patches as the corresponding CPU at the security baseline. Example: At time of writing, the security baseline is 1.8.0_65. A different patch set update, 1.8.0_66, is available with additional changes. Users that only want critical patches do not have to deal with these changes yet, and can test them separately. In the next scheduled Critical Patch Update, we will include those changes from 1.8.0_66. What happens when the security baseline changes or the expiration date passes When clients detect that it is below the current security baseline, they will typically do two things: prompt end-users to install the newer update, and decrease the potential attack surface of the installed JRE. These changes are described in the Rich Internet Application Deployment Process under the question, “Is the JRE expired or below the security baseline.” Desktop administrators that need to control prompts and/or use Java versions below the security baseline may do so through Deployment Rule Sets, under the question, “Does a rule exist for this RIA.” The attack surface reduction applies to Rich Internet Applications (through browsers). Planning for updates With the dates of Critical Patch Updates published a year in advance, system administrators should plan ahead to roll out Java updates onto client systems. Deployment Rule Sets should be used with applications that cannot use the latest Java Runtime Environment for one reason or another, to whitelist which known-safe application can use specific older JREs. Critical Patch Updates are available to Java 6 and Java 7 through the commercial Java SE Advanced, along with other management tools. Administrators needing to deploy Java across thousands of managed systems every quarter may consider the commercial Java SE Advanced, which offers tools to better manage Java at scale. Examples of these commercial features include:  An enterprise MSI installer to support easier customization and deployment. Critical Patch Updates for older versions of Java beyond public support (e.g. Java 6 and Java 7). The Advanced Management Console, to help build an application inventory of Java applications and create a Deployment Rule Set from tracked usage. Java Flight Recorder and Mission Control, for deep performance analysis. Support from an experienced team that can monitor and track Java bugs. Additional Resources Introducing Deployment Rule Sets Deployment Rule Sets by Example Advanced Management Console Video Walkthrough Managing Multiple Java Versions

"Java update available -- a new version of Java is ready to be installed..." This occurs four times a year: January, April, July, and October. Oracle Java SE is updated on the Oracle Critical Patch...

NPAPI Plugin Perspectives and the Oracle JRE

Java’s rapid rise tofame 20 years ago began with a tumbling duke applet running in the HotJava browser. Applets allowed richer developmentfunctionality at a time when browser capabilities were very limited, andprovided centralized distribution of applications without requiring users to installor update applications locally. HotJava’s support forapplets was picked up by Netscape. In 1995 Netscape Navigator 2.0 and plugins became more popular to expand thekind of content that could be displayed. Navigator’s plugin interface (NPAPI)was adopted by other browsers and supported since 2004. Support for Javaapplets across several different browsers was implemented relying on the commonNPAPI plugin interface to provide cross-browser compatibility of Javaapplications running on the web. As Java evolved tobecome one of the leading mainstream development platforms, so did the applet’shosts – the web browsers.  The rise of web usage on mobile devicebrowsers, typically without support for plugins, increasingly led browser makers towant to restrict and remove plugin support from their products, as they triedto unify the set of features available across desktop and mobile versions.Coincidental with the rise of mobile was the emergence of the “app store” modelrather than “plugin based” models for application delivery. The “appstore” model grew for reasons related to simplicity, security, and centralizedavailability. Given these evolutions in mobile, delivery, and capabilities, theset of browsers that continue to support standards based plugins has shrunkover time. The announcement from Mozillaprovides a timeline for developers and users who rely on Mozilla Firefox forapplets to evaluate and migrate to alternatives. You should consider usingplugin-free technologies, like Java Web Start, or move to other supportedbrowsers, before NPAPI functionality is removed from Firefox in their regularand/or Firefox Extended Support Releases. As with other browsers,the Oracle JRE can only support applets on Firefox for as long as Mozillaprovides the requisite NPAPI support. Having been in regular contact with theMozilla engineering team over the past years, we have worked together to ensurethat our common users benefit from improvements made in Firefox and the OracleJRE.  We'll continue to collaborate on enabling a smooth transition toplugin-free technologies like Java Web Start. Meanwhile, we don’t planto provide additional browser-specific plugins, as such plugins would requireapplication developers to write browser-specific applets for each browser they wishto support. Moreover, we would only be able to offer a subset of the requiredfunctionality, different from one browser to the next, impacting bothapplication developers and users. As with previous transitions, any additional information specific to Oracleproducts will be provided by the corresponding product teams. Internet Explorerand Safari browsers are not impacted by this change. System administratorswho want to prepare for the transition and learn more about applets (and otherkinds of Java applications) running inside their organization should evaluatethe Java Advanced Management Console. 

Java’s rapid rise to fame 20 years ago began with a tumbling duke applet running in the HotJava browser. Applets allowed richer developmentfunctionality at a time when browser capabilities were...

Launching Web Start applications

Java applications can be distributed to clients through download capabilities like Applet and Web Start. These applications are delivered to users through web browsers, allowing for convenient access on client systems. Web Start applications can be launched from any web browser by opening the application’s JNLP file. Once opened, these applications no longer rely on browser plugins or integrations. Instructions for launching JNLP files can be located in "What is Java Web Start and how is it launched" on Java.com. In short, this involves associating the .jnlp file association with Java’s javaws command. Desktop Administrators can control Web Start dialogs/prompts by using Deployment Rule Sets (DRS). This DRS feature enabled administrators to create an application whitelist that can control execution of known-safe applications as well as manage compatibility between different versions of Java on the same system. System Administrators can use the Java Advanced Management Console to track Java usage within their organization, identifying Applet, Web Start, and other Java application types. This usage tracking enables them to identify which versions of Java are used by which applications, and create Deployment Rule Sets to manage compatibility between versions.

Java applications can be distributed to clients through download capabilities like Applet and Web Start. These applications are delivered to users through web browsers, allowing for convenient access...

Strengthening Signatures

Later this year, the Oracle JDK team plans to restricting the use of MD5 signatures within X.509 certificates used by SSL/TLS and code-signing. This will take place in the public versions of JDK 9 (early access) and JDK 8, as well as the commercially supported JDK 7. The IETF has recommended a move away from MD5 since 2011.Most Certificate Authorities followed this guidance by requiring stronger signatures (typically in the SHA family). Although the default JDK options switched away from MD5 in the past, additional time was necessary for organizations to phase out their use of MD5 and reissue certificates with stronger hash algorithms. System Administrators that still actively use certificates with MD5 hashes should consider revoking and/or re-issuing those certificates with stronger signatures. Developers that have previously signed artifacts with MD5 signatures should consider re-signing and timestamping these artifacts.This change will only affect MD5 usage in regards to certificates. This will not affect other uses, such as MD5 hashing of files to generate checksums or perform simple checks. System Administrators can control algorithm availability by adjusting their JRE configuration. For example, some organizations may still rely on internal systems that require MD5. Users of these systems will likely see a message "constraints check failed: MD5withRSA" in their application logs. This configuration change takes place within the jre/lib/security/java.security file. The specific property is jdk.certpath.disabledAlgorithms.

Later this year, the Oracle JDK team plans to restricting the use of MD5 signatures within X.509 certificates used by SSL/TLS and code-signing. This will take place in the public versions of JDK...

The 2015 Leap Second’s impact on the Oracle JDK

On June 30, the official Universal Coordinated Time will experience a leap second. Many technical news sites have written about this upcoming leap second’s impact on various technical systems. System Administrators concerned about leap seconds should focus on it as a standard maintenance problem of updating Java’s time zone information and using operating system time tools like NTP. Update Time Zone Information Time Zone updates were covered in a previous post, Understanding Time Zone Updater 2.0. System Administrators looking to update their systems can simply use the tzupdater tool to update JDK installations. Alternately, each JDK release always contains the latest time zone information for users that upgrade. Check the Operating System Java relies on the operating system clock for time. Each operating system has its own method of handling date changes such as leap seconds. Consult your operating system information for details on handling the leap second. Linux users may consult the Wired interview with Linus Torvalds, "Linux’s creator wants us all to chill out about the leap second." Details for Windows can be found in KB-909614 How the Windows Time service treats a leap second. Hosting providers like Amazon and Google will be doing a time skew over the course of a day. Some applications may still require restarts Although the Java API defines a second as a number between 0 and 61 to accommodate leap seconds, some applications may have taken short-cuts to assume that there are 60 seconds in a minute or 86400 seconds in a day. Systems that perform synchronized time-based transactions with other systems may run into issues if one system updates and another does not. The 2015 leap second takes place at exactly 23:59:60 UTC on June 30, 2015. I advise system administrators to monitor processes during this time and pay extra attention to systems for a short while.

On June 30, the official Universal Coordinated Time will experience a leap second. Many technical news sites have written about this upcoming leap second’s impact on various technical systems. System...

Understanding Time Zone Updater 2.0

Different places in the world are in different time zones so Java needs to keep track of time zone information. Such information gets complicated when one considers rules for Daylight Saving Time across regions.  There are some places where Daylight Saving Time changes occur multiple times per year. In Morocco, for example, changes occur in March, and October as well as around Ramadan.  The rules can vary from country to country and in some cases within a country.   These rules are updated from time to time.  In the United States they were last updated in 2007. In order to allow applications to accurately convert dates and times from one place to the equivalent time at another location Java needs to track all such known changes. Although there is no international regulatory agency that governs time zone changes, there is a collaborative compilation of time zone data known as the TZ Database or IANA Time Zone Database.  This database not only contains past rules but –where available- rules for future changes.  IANA updates their database several times a year, as time zone information changes. Since 2002 the JRE relies on this database for the accuracy of its time conversion routines. The vast majority of Java users get updates to their JRE’s time-zone information as part of the regular Java updates.  There are two cases however, when this is not possible: Although most governments announce changes in their time zone rules with enough warning to avoid disruptions, sometimes changes to the time zone rules are not announced in time for a new version of the IANA database to be included in an update of the JRE before the change takes effect. In some cases it is preferable to update just the time-zone information, without changing the JRE. For both of these cases Oracle provides a tool called TZUpdater.  Starting with TZUpdater 2.0 the tool contacts the IANA servers directly and downloads the most up-to-date time zone information.   With this new functionality administrators can use the same tool for all JRE time zone information updates. To ensure that the Time Zone Database downloaded has not been damaged in transit the tool compares it against a known checksum. The readme contains instructions on how to use the tool by downloading the IANA time zone database to a local directory for cases on which the computer that needs to be updated cannot reach the IANA servers directly. This tool updates only the time zone information in the JRE.   Most modern operating systems will update their own time-zone information as part of their regular updates.  On what JRE/JDK versions does this tool work?TZUpdater 2.0 works with Oracle’s JRE/JDK versions 5.0 (1.5) and above.   For Java versions provided by other vendors please contact the vendor. My country/city/region is about to go through a change in the daylight saving rules.  When can you have a new version of the tool with the new rules available?Please visit http://www.iana.org/time-zones and follow their instructions under Submission/Discussions to request updates to the Time Zone Database.Once an update to the IANA Database becomes available you can use TZUpdater 2.0 to apply the changes. Which time zone database is on JRE version <xyz>?You can find which version of the IANA database was originally included in a particular JRE in this page: http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html Will you continue posting new versions of TZUpdater?TZUpdater 2.0 tool can download updates directly from IANA.  Updates may  still be provided as part of regular software maintenance. To learn more: Timezones, Daylight Savings, and the TZupdater for the Java Runtime Environment (JRE)http://www.oracle.com/technetwork/java/javase/timezones-137583.html

Different places in the world are in different time zones so Java needs to keep track of time zone information. Such information gets complicated when one considers rules for Daylight Saving Time across...

JavaOne 2015 Call For Proposals Is Open

The call for proposals is now open for JavaOne 2015. If you are interested in speaking, please submit your abstract to the site. Key Information JavaOne 2015 will run from October 25th to the 29th in San Francisco. The call for proposals ends on April 29 at midnight PDT. Submit your talk by then. Accepted speakers receive complimentary passes to attend the conference. Choose the best track for your topic JavaOne features several different tracks based on different roles and interest. These tracks include core platform, security, JVM languages, DevOps/Cloud, Internet of Things (embedded), Server-Side development, Clients, and Tools & Agile methodologies. The 2015 tracks page provides a complete listing and description of each track. Videos and materials from the 2014 conference are available for on-demand replay and access through both ActiveEvents and Parleys. Security Track This is the third year for a dedicated Security track at JavaOne, and I am honored to be on the review committee. Last year’s security track featured many great presentations. Among them, Frank Kim was recognized as a JavaOne Rock Star presentation for his talk on "Five Keys for Securing Java Web Apps." Typical talks on this track were about methodologies, analysis techniques to find threats/vulnerabilities, and advanced tool usage. For those submitting talks, a few good topics would be: Explain the relation between new Java 8 features and security. For example Java 8 introduced type annotations and their ability to annotate data such as local variables. By storing this information in bytecode, how can tool authors and library writers support each-other to make it easier to write secure code? What opportunities are present for things like the checker-framework’s tainting checker? Designing code for security analysis, or designing security analyzers. As developers write code and as users run applications, how can we detect or prevent security issues before code gets released? How does the Java platform facilitate this detection both for Java as well as other languages featured on the JVM Language track? Tools, libraries, and techniques. How does your team or organization make security decisions? If you have mastered usage of certain techniques or tools, share guidance and experience with your peers.

The call for proposals is now open for JavaOne 2015. If you are interested in speaking, please submit your abstract to the site. Key Information JavaOne 2015 will run from October 25th to the 29th in...

Future updates of Java 7 and Java 6

The upcoming release of Java 7 update 80 (April 2015) marks the last public release in Orale’s JDK 7 family. Java users should upgrade to the publicly supported JDK 8 or obtain a commercial support contract of Java SE Advanced for continued updates of JDK 7 and JDK 6. Additional details can be found in the video, "Java SE 7 End of Public Updates" by Tomas Nilsson. Support dates for the publicly supported JDK versions are as follows: Oracle Java SE Public Updates(copied as of March 26, 2015) Major Release GA Date End of public updates Commercial support timeline JDK 5 May 2004 Oct 2009 Available through Java SE Advanced. See linked Oracle Java SE Support Roadmap. JDK 6 Dec 2006 Feb 2013 JDK 7 Jul 2011 Apr 2015 JDK 8 Mar 2014 See roadmap Companies that require older Java versions after the end of public updates may benefit from the fixes in these older versions, such as security enhancements. The last public release of JDK 6 was Java 6 update 41 in February 2013. I recommend that users without commercial support contracts of Java SE Advanced use a publicly supported JDK, such as JDK 8. Oracle commercial customers whose applications depend on JDK 6 may download Java 6 update 91, released January 2015. This commercial release contains almost three years of bug fixes and security improvements. Java 7 will follow a similar path. The last public release of Java 7 will be Java 7 update 80 in April 2015. After that time, I recommend that users without commercial support contracts upgrade to JDK 8. Oracle commercial customers whose applications depend on JDK 7 will still be able to download critical patches of JDK 7 in July and later, as identified by the Critical Patch Update schedule. Versions of Java 8 are available to all, with or without commercial support, on Java.com and the Java SE Downloads page of the Oracle Technology Network. Benefits of Java SE Advanced In addition to support and patches, the commercial Java SE Advanced provides the following features: Java Mission Control and Flight Recorder provide developers and system administrators with a way to monitor applications in production using a low-overhead profiler that captures runtime information. Flight Recorder can operate in a continuous loop and create recordings based on events – the loop enables developers to see what lead up to the event and not what happened after. The Advanced Management Console offers system administrators with a way to track and understand Java usage across managed systems. By using the console, system administrators can manage a situation where different users need different versions of Java for different applications. By using usage tracking to create an application inventory, the system administrator can create a guided Deployment Rule Set to specify which applications need which versions of Java. The result is that older Java versions are available for compatible known-safe applications but cannot be used by modern-day internet threats. The MSI Installer (through My Oracle Support) offers a simplified way for system administrators to customize and install Java onto many systems. Additional technical features are available through runtime flags, such as Application Class Data Sharing to reduce startup times.

The upcoming release of Java 7 update 80 (April 2015) marks the last public release in Orale’s JDK 7 family. Java users should upgrade to the publicly supported JDK 8 or obtain a commercial support...

Planning safe removal of under-used “endorsed extension” directories

As the Java platform moves forward, we look for ways to reduce and eliminate technical debt. One example is the planned removal of deprecated Garbage Collection combinations, as outlined in JEP 214. As another example, in Java 8 update 40, as part of JEP 220, we will be deprecating two rarely-used extension capabilities, with the intent to remove them in JDK 9, providing suitable replacements as necessary. Most developers do not use these features, and system administrators can quickly tell if any legacy systems will be affected. What is changing: Removals of the endorsed-standard override mechanism and the extension mechanism Previous versions of Java SE have allowed developers to place JAR files into two directories within the JRE, making anything in those JAR files available to all launched applications. The original Endorsed Standards Override Mechanism enabled Java to quickly take advantage from new versions of external standards that were developed outside of the JCP, such as CORBA and XML Processing. As different libraries and build systems became available, developers have taken a preference of including such libraries directly within their applications rather than deploying these endorsed standards directories within the JRE. The Extension Mechanism enabled developers to do similar activities by placing JAR files into a jre/lib/ext directory. Details about this planned change for JDK 9 can be found in JEP 220. The associated ticket, JDK-8065702 discusses the deprecation of the extension mechanism in JDK 8. As called out in the ticket, there will be a new JVM flag in JDK 8u40 that people can use to see if this change will cause any problems: -XX:+CheckEndorsedAndExtDirs. When is this change taking place? A preliminary feature is being introduced in Java 8 update 40, that will allow developers to more easily identify if they will be affected by this change. No actual changes are being made; rather this is a tool to help identify potential future problems. The actual change to remove this under-used functionality will take place alongside the release of Java 9. By providing detection tools in advance, we intend to help applications that plan to adjust. Developers: Why most applications are unaffected The majority of applications in use today do not use either of those features and will be unaffected by this change. Instead, most applications bundle third party JAR files. By bundling their own dependencies, applications could be moved between systems without requiring pre-requisite files to be installed inside the JRE. It has also made upgrades easier, where system administrators can upgrade the JRE without worrying about these internal directories. If you are building or maintaining an application that requires third party JAR files to be present in the JRE, please consider providing those JAR files as part of your application. System Administrators: How to tell if your applications are affected System Administrators managing deployments may want to verify that their applications will be unaffected by this change. Use a Java startup flag (recommended) The easiest way to identify usage of endorsed standards is to ask the JVM to detect their usage. When launching Java applications and servers, add -XX:+CheckEndorsedAndExtDirs to your invocation. This will cause the system to print a message about any unexpected items in the endorsed standards or extensions directory. Check your jre/lib/ext directory One way to identify if this change will affect anything is to look at your JRE’s jre/lib/ext directory and see if there is anything present there that is not included by default. The following is a sample list from my system to identify a normal installation. If your folders look like this, then you are not using the extension mechanism. Java 8 update 25 jre/lib/ext Java 7 update 60 jre/lib/ext Thirteen (13) files: access-bridge-64.jar cldrdata.jar dnsns.jar jaccess.jar jfxrt.jar localedata.jar meta-index nashorn.jar sunec.jar sunjce_provider.jar sunmscapi.jar sunpkcs11.jar zipfs.jar Nine (9) files: access-bridge-64.jar dnsns.jar jaccess.jar localedata.jar meta-index sunec.jar sunjce_provider.jar sunmscapi.jar zipfs.jar The presence of anything listed above is normal and expected. Other files are not. What to do if you are affectedAlthough most applications do not use the endorsed standards or extension mechanism, some applications do. If you are a developer, please consider providing dependencies as part of your application rather than requiring external system configurations. If you are not the developer, please contact the individual software vendor for support.

As the Java platform moves forward, we look for ways to reduce and eliminate technical debt. One example is the planned removal of deprecated Garbage Collection combinations, as outlined in JEP 214....

Java Web Start in or out of the browser

The Java Runtime Environment offers a number of ways to run applications. On client systems, one common method is Java Web Start. It allows applications to be launched through browsers or directly via the Java Network Launching Protocol (JNLP). This capability was introduced back in 2001 and has been used by many applications throughout the years. It is quite common in enterprises and certain countries. As browsers evolve, many users still need to continue to run these applications. Since Java Web Start applications can be launched independently of a browser, as they don’t rely on a browser plugin, in many cases they can provide a migration path from Java Applets.The business owners of these applications may have additional questions about how the support lifetime of Java Web Start affects their applications. JDK Support Timelines At present, Oracle offers two publicly available, supported versions: Java SE 7 and Java SE 8 (most current). Both are available through the Java.com website and Oracle Technology Network (OTN). I encourage users and developers to upgrade to Java SE 8. Oracle’s support timeline is described on the SE Roadmap web page. Companies or ISVs that require support and/or updates after the end of public availability can obtain a commercial solution. This timeline extends well beyond the end of public updates and includes patches/updates to the Deployment Technology for Applets and Web Start applications as described. Commercial support customers (including ISVs) may continue to use JDK 7 and JDK 6 for years beyond its end-of-public-updates and receive regular updates. This includes the ability to file support tickets with Oracle. Other users should upgrade to Java SE 8. Running Web Start Applications Users that need to run Web Start application may launch that application through a web browser such as Internet Explorer, Mozilla Firefox, Apple Safari, or Pale Moon. Chrome users may consult "How do I use Java with the Google Chrome browser." Most users should obtain Java directly from the Java.com website. Advanced users may download via the Oracle Technology Network and should choose the correct 32 and/or 64 bit version. Controlling prompts and dialogs Java prompts and dialogs about execution can be controlled through Deployment Rule Sets or the Exception Site List. Deployment Rule Sets work well for enterprises that need to run different Java applications with different Java versions. The Exception Site List works well for an end-user that wants a specific Java RIA to run. Additional details can be found at: Introducing Deployment Rule Sets Upcoming Exception Site List Managing Multiple Java Versions Companies that need to create Deployment Rule Sets may consider using the Advanced Management Console. JDK 8u20 Improves Performance, Security, and Manageability New Management Console in Java SE Advanced 8u20 Managing Multiple Java Versions Many browsers have their own dialogs and control mechanisms. For example Internet Explorer has a post about their dialogs with the phrase, "Can this feature be disabled if my enterprise requires an older version of the Java runtime?" Running Web Start applications outside of a browser Web Start applications can be launched directly with a JNLP file. Application developers may consider providing a direct link for users to download their JNLP files. Example instructions on Windows: Right-click any JNLP file that you have downloaded. Select Properties. Next to “Opens With,” click the Change button. Locate your Java version and choose javaws.The recommended program is “Java(TM) Web Start Launcher.”Example path: C:\Program Files\Java\jre1.8.0_40\bin\javaws.exe Additional Deployment Options With changes in web browser plugins, application developers may consider alternative distribution methods. Several options are available: Native Windows/Mac/Linux packages The javapackager command allows developers to create standalone native install bundles that do not require a separate JRE installation. The native options include: installer, image, exe, msi, dmg, rpm, and deb. This is ideal for desktop applications, where the user may not have their own JRE installed and just wants the program to run.  It may not be appropriate for server-based applications where an administrator would want full control over the environment. Inverted browser control JavaFX contains a feature called WebView, which enables applications to use an embedded version of WebKit to render HTML5 content. As a result, developers can create applications that use this browser to access remote applications. For example, a developer could create a miniature web browser that makes it easier for their users to launch remote applications. WebFX is a prototype example of this behavior.

The Java Runtime Environment offers a number of ways to run applications. On client systems, one common method is Java Web Start. It allows applications to be launched through browsers or directly via...

Node.js and io.js on Java

The Nashorn JavaScript engine is one of many improvements in JDK 8. Nashorn (German for Rhino) is a faster replacement for the previous JavaScript engine known as Rhino. There is also another noteworthy feature: the ability to run many Node.js and io.js applications in the JVM. These applications can then call back and forth between optimized Java libraries and automatically receive monitoring capabilities through JMX. In the upcoming JDK 8 update 40, it is planned to improve Nashorn / JavaScript performance even further through optimistic typing. Java Virtual Machine - More than just Java The Java Platform offers a way to run different types of applications, even if those applications are not written in the Java programming language. As a result, developers can take advantage of optimizations and stability of the JVM, while system administrators can better control and monitor deployments. Examples of other languages on the JVM include: JavaScript (Nashorn), Ruby (JRuby), Python (Jython), Scala, Groovy, and many others. Project Avatar – A JavaScript services layer on the JVM Avatar.js is a project to bring the node programming model, APIs and module ecosystem to the Java platform. Although written in JavaScript, these applications can take advantage of the Java platform's scalability, manageability, tools, and extensive collection of Java libraries and middleware. After downloading the Avatar.js binaries, developers can then execute their applications. For example, Tim Caswell’s article "Hello Node!" contains basic examples for hello-console.js and hello-http.js that can be used as a basic way for testing Avatar. Nashorn, The Hidden Weapon of JDK 8 was presented at the Silicon Valley Java User Group meeting in December 2014. The available slides describe the use of Nashorn and Avatar at Netflix and provide additional Nashorn demos. Avoid rewrites and re-use libraries One major benefit of running serverside JavaScript applications within the JVM is access to Java libraries. Developers do not have to rewrite major libraries or functionality like SQL or NoSQL drivers, Hadoop clients, encoding libraries, etc. Additional examples are available in a previous post, Nashorn: the rhino in the room, but they are not specific to Node.js. Niko Köbler has a two-part article about Avatar 2.0 and its Model Store API. By using this model store API, developers can more easily interact with SQL and No-SQL and benefit from many existing optimizations. Part 1 explains the architecture and threading model. Part 2 covers the technology behind the Model Store API. Monitoring Applications on the JVM All Java processes can be monitored through a mechanism called JMX. System Administrators can enable remote authenticated JMX connections and see inside these running applications, rather than monitoring from the outside coming in. Additional details about JMX monitoring (both local and remote) can be found in a previous post, Deep Monitoring with JMX. Monitoring applications with Mission Control / Flight Recorder Java Flight Recorder is an effective way of monitoring JVM applications in production. Unlike standard development profilers (like the NetBeans profiler), Flight Recorder has negligible performance impact. The dashboard view in Mission Control provides basic information about CPU and memory resources. Developers may use the Threads tab to better understand system throughput, or if the application is blocking around any particular resources. To open Mission Control, run the jmc command and connect to your Avatar application. The screenshot below shows Mission Control monitoring a Node.js application identified as com.oracle.avatar.Server. Although the Node.js applications are written in JavaScript, Flight Recorder can also perform trigger-based recordings on events, such as a CPU spike. System Administrators and Developers can look back at the recording to see what lead up to the event. Additional details are available on the Mission Control home page and user guide. Additional ways of running Node.js on the JVM Avatar is one of several ways to run Node.js applications on the JVM. RedHat’s Nodyn project runs Node.js applications on the JVM and offers direct integration with the Vert.x framework. Apigee provides a Trireme and enables developers to embed a NodeEnvironment within their applications , which can then execute NodeScript objects. When run on Oracle Java, both projects can be monitored by Flight Recorder / Mission Control as described above. Because this monitoring is provided directly by the Oracle JVM itself, there is no need to make any code changes or apply additional monitoring packages.

The Nashorn JavaScript engine is one of many improvements in JDK 8. Nashorn (German for Rhino) is a faster replacement for the previous JavaScript engine known as Rhino. There is also...

Upgrading major Java versions - technical

Many users have already upgraded from Java 7 to Java 8, to benefit from improvements in speed, brevity of code, and lower memory usage. Other users have asked for more prescriptive guidance of the upgrade: when to make the change, what to expect, and how to do it in a controlled manner. Relation to a previous post A previous post, Upgrading Major Java Versions, provides details for certain stakeholders: support timelines, compatibility guides, lists of changes, and different supporting material. This post is intended to provide more prescriptive guidance of upgrading your Java SE version: how to test components and features designed to control behavior and upgrade part of your environment in stages. The decision to upgrade is not only for companies that develop software; it also applies to users running software built by others. In many cases, users can see significant speed improvements without recompiling, simply by upgrading the runtime. Planning upgrade in stages The previous post explains when to upgrade in relation to platform support. When upgrading infrastructure, it is important to segment the architecture. Rather than upgrading everything at the same time, separate it into different environments so that you can test each one on its own. Typical environments, in my preferred order of when to upgrade: Developer workstations, where developers write and test code. This is most likely where you would run IDEs like NetBeans, Eclipse, or IntelliJ. Central build servers, where code is combined, built, and unit tested through automation. Common software is Hudson or other continuous integration software. Some organizations do not have central build servers. Test or QA servers. This environment may run your application in order to find any issues before release into production. Production servers. The final environment that should be upgraded last, these servers run your application for users. High level upgrade plan: Upgrade the build and test environments but keep things targeted for production. Once you are ready, upgrade the production environment and begin taking advantage of new features. Backwards Compatibility The JDK is backwards compatible, meaning that JDK 8 can run binaries produced by JDK 7 and JDK 6. The javac compiler can also produce binaries targeting earlier versions of the JDK. In planning to upgrade, we will use this capability. Upgrading Developer Workstations and/or Central Build Servers The important similarity between developer workstations and central build servers is that they are used to compile the application from source code into binary artifacts, such as JAR and WAR. Upgrading a workstation or build server involves upgrading its JDK installation. The same system may run multiple versions of the JDK side-by-side, making it your choice if you want to uninstall the older one. Environment Variables for installation If you choose to run multiple versions, just be mindful of two environment variables: PATH – identifies which actual java executable your system will use when you call java. You can circumvent this by explicitly calling the executable via /opt/jdk8/bin/java or /opt/jdk7/bin/java commands. Just call the one you want to use at the time. If you use scripts that rely on environment variables, consider isolating your terminals if you change the environment. JAVA_HOME – some applications use this variable to identify where Java is. Test your upgrade the following commands: java -version This should reply back with 1.8 or 1.7 depending on which you want. Just make sure it is right echo $JAVA_HOME On Linux, that will identify the JAVA_HOME variable that some applications may use. Check that it is the installation you intend to use. On Windows, use: echo %JAVA_HOME% You can also check the entire process with: Linux: $JAVA_HOME/bin/java -version Windows: %JAVA_HOME%\bin\java -version Personal Tip: On my Windows 7 laptop, I regularly switch Java version to test things. To counter forgetfulness, I set my JAVA_HOME variable first, and then my PATH uses that JAVA_HOME. By doing this, I only need to change one thing. My PATH starts with: %JAVA_HOME%\bin; Cross-compiling to meet your runtime’s compatibility By using your upgraded installation to cross-compile, you will produce artifacts that run in your not-yet-upgraded test and production environments. The javac compiler provides three options to control compatibility: -bootclasspath -source and -target. Without the -source flag, the compiler won’t warn you about using language features that may not be available on your earlier target JDK platform.  Without the -target flag, the compiler won’t produce binaries that can run on your earlier target JDK. Finally, without the -bootclasspath flag, the compiler won’t be able to find the correct version of the core class libraries from the earlier JDK. A simple example of using all flags correctly can be found in the javac documentation’s Examples section. Configure the build to specify the -source and -target of your runtime. Regular javac: -source 1.X -target 1.XIf you have the older JDK: javac: -source 1.X -target 1.X –bootclasspath JDK1.6/lib/rt.jar Maven: Modern versions of maven have a <maven.compiler.source>1.X</maven.compiler.source> attribute that can be set in properties. Alternately, use the maven-compiler-plugin attributes like <source/> and <target/> Ant: The <javac source="1.X" target="1.X" /> task, or you can use a separate ant.build.javac.source property. Etc. consult your build system’s documentation. Monitor compiler errors and warnings Building your application with the latest JDK will identify any potentially problematic areas. Investigate compiler errors, if any. Although compiler warnings do not cause build failures, they indicate areas of interest. Looking into them provides a safeguard of something that may affect compatibility or legibility of code. In JDK 8, we added special indicators to point where incompatibilities may occur in the future. com/example/App.java:[32,24] SOMETHING is internal proprietary API and may be removed in a future release In this example, my code has made use of a JDK internal API on line 32 of App.java. If you see this message, your code will likely still work for now but you should consider moving towards the known-compatible replacement for that API. Use jdeps or other compatibility analyzers OpenJDK 8 features a new dependency analysis tool, jdeps, designed to identify where applications or their dependencies make use of internal JDK APIs. Usage of these APIs does not currently indicate incompatibility, rather they point out where you use non-public and unsupported internal APIs. If jdeps identifies usage in your code, consider switching to the public replacement APIs. If jdeps identifies usage in third party code, you may still be impacted in the future. Consider upgrading those identified dependencies, patching them, or identifying an alternative. We have previously limited access to some internal APIs in some situations. The publicly supported APIs are still available, unaffected, and fine to use. Consider additional tools for analysis as well: The Forbidden APIs project also helps identify cases where certain APIs either should not be used or should be used differently. In addition to identifying internal APIs, this finds potential locale and encoding issues. The Modernizer Maven Plugin also locates legacy APIs. While jdeps is focused solely on internal JDK APIs, this finds them in other projects. That may be useful if you are upgrading those other projects as well. Running an application in test or production Upgrading the test and production environments will allow you to evaluate an application and see how it interacts with other systems. The JDK is designed to be backwards compatible. Upon upgrading the test environment, it is your choice if you want to run the same cross-compiled binary. When testing your application, it is important not to change too many things at once. For example if you test the upgrade while simultaneously testing a complete rewrite of major components at the same time, it will be hard to tell which issue came from which cause. Given time available for testing, is may not be feasible to test the upgrade alone, without any other changes. Isolate changes as best you can and do not pre-assign a root cause to any issue before investigation. Once you have successfully upgraded your environment(s), there is no more reason to cross-compile your binaries. Consider going back to your build environment and removing the -bootclasspath, -source, and -target flags. Environmental changes The previous post, Upgrading Major Java Versions, provideslinks to detailed information and compatibility guides about what changedbetween different versions. In the interest of brevity, I will list a few noteworthy differences that I have seen: JDK 8 uses TLS 1.2 as its default transport protocol for connections like https. JDK 7 made TLS 1.2 available but did not use it as the default. JDK 6 did not offer this protocol. For details, see JDK 8 Will use TLS 1.2 as its default and Diagnosing TLS, SSL and HTTPS. JDK 8 no longer has a type of memory called PermGen, as it was replaced by Metaspace. This should not affect most people, but older startup scripts may have used -XX:MaxPermSize options. This should not cause problems, as tuning PermGen will no longer do anything. Please consider removing unnecessary startup options as a good measure. Startup switches that begin with -XX: should be validated to see if they still apply. The java command documentation identifies these as advanced options not recommended for casual use. They are subject to change. If you experience unexpected behavior or slower performance, your flags may be working around a problem that no longer exists. Applications using a ScriptEngine like JavaScript will use the newer/faster Nashorn in place of the previous Rhino interpreter. If your application made extensive use of Rhino and you find errors after upgrading, please consult the Rhino Migration Guide. Uptake of Java SE 8 Many applications are able to leverage a smooth upgrade path from JDK 7 to JDK 8, in order to benefit from improvements like speed and more concise code. Examples of teams that have successfully migrated include: Vaadin, "No need to wait – Java 8, it’s great." Scala 2.12 will only support Java 8. Spring 4 enhances support for Java 8, Java EE 7, REST, and HTML5. Etc. I will continue monitoring different areas and will try to follow up in the future with different strategies for upgrading.

Many users have already upgraded from Java 7 to Java 8, to benefit from improvements in speed, brevity of code, and lower memory usage. Other users have asked for more prescriptive guidance of the...

That's so SecureRandom

Random numbers are an important part of software systems, especially those that deal with security or encryption. The Java platform offers different types of randomness based on intent, and static typing can further guide that choice for library developers. This post is intended to explain how the Oracle JDK provides random numbers, to guide their usage: Developers building Java software, to use the right randomness in the right place. Companies buying or running Java software to understand how to evaluate or control that software. System Administrators tuning the security and performance of those systems, understanding why/where/how to make adjustments. Randomness in the JDK Java SE provides three mechanisms for generating random numbers based on their usage: A fast Random number designed for basic tasks where true randomness is not the main goal. This is useful for things like which shade of color to use, preventing overlap in force-directed layouts, or which picture to show from a list after evaluating demographic information. High-concurrency programs may also use ThreadLocalRandom if they value speed over true randomness. This is the same as above but will likely give better performance if simultaneous threads generate pseudo-random numbers at the same time. A slower but more random SecureRandom designed for important tasks where the inability to predict numbers is crucial to success. Examples include cases like gambling, scientific sampling, or any cryptographic operations. Although slower than the other two random number generators, its better randomness in many applications. Having these choices allows developers to make the appropriate decision based on their application. The Java Platform also allows software operators to override and control this behavior. For example improving true-ness of the Random generator or improving speed of SecureRandom with dedicated hardware. Security through static typing Java’s static typing can also enforce that program authors and library users apply the proper Random implementation. The random classes are designed with inheritance, allowing full interoperability across implementations. Both SecureRandom and ThreadLocalRandom inherit from Random, which means that implementations can be swapped or specified: Random pseudoRandom = new Random();Random pseudoRandomConcurrent = ThreadLocalRandom.current();Random secureRandom = new SecureRandom(); For API design, developers can choose to only accept the appropriate version based on their use case. Given that true randomness is crucial to the success of cryptographic operations, it is critical that cryptographic APIs only accept SecureRandom arguments and never the super-class of Random. One example of this is KeyPairGenerator, which helps generate public/private keys that are used by many cryptographic systems. Users can only seed this with true-random values and not pseudo-random values. KeyPairGenerator.initialize(int keysize, SecureRandom random); Developers can only call this method by using statically-typed SecureRandom values. The super-type Random PRNG, which might make predictable keys, cannot work. Calling the overloaded KeyPairGenerator.initialize(int keysize) will also use a SecureRandom and is fine, the point here is that static typing prevents other types of Random from being used. Using the previous example, one could call: kpg.initialize(4096, (SecureRandom) secureRandom); Or by specific static typing: SecureRandom staticEnforcement = new SecureRandom();kpg.initialize(4096, staticEnforcement); API designers building secure systems should follow this example of statically typing SecureRandom in method signatures. When vetting secure software, look for usage of Random where a SecureRandom might be more appropriate. The US CERT Java coding guidelines offer additional guidance on evaluating the use of random numbers. Simon Kitching also has a good write-up about Using the SecureRandom Class. Sources of Randomness The sources for randomness are listed in the JDK’s security Standard Names documentation, identifying which are blocking or non-blocking. Although some sources rely on entropy pools, SecureRandoms like SHA1PRNG are quite fast once seeded and do not need additional entropy. Blocking is especially important on Linux systems, where some calls to /dev/random may pause while the system generates a new true-random number. There is a trade-off /dev/urandom device that is non-blocking but somewhat less random. Within a Java installation, the administrator can adjust various settings through the "JRE/lib/security/java.security" configuration file. That file contains documentation about configuring securerandom.source and securerandom.strongAlgorithms. On Linux systems, the administrator may set their securerandom.source to  /dev/random or /dev/urandom accordingly. Each operating system contains its recommended default value. System Administrators may edit that value, for example if their system has different RNGs or if they have a separate specialized hardware RNG. JavaMex has a page describing the sources of entropy that Java uses on different operating systems. Additional information is available in the SecureRandom javadoc.

Random numbers are an important part of software systems, especially those that deal with security or encryption. The Java platform offers different types of randomness based on intent, and static...

Upgrading major Java versions

With the release of Java 8 back in March 2014, many users have already upgraded. They can take advantage of new features such as: Significant and noteworthy speed improvements (Fork/Join and Lambda). Shorter code that is easier to read and write (Lambda and the Streams API). Language support to prevent bugs, especially when different teams write different parts (Type Annotations like the Checker-Framework). Lower memory usage (String deduplication). There are many write-ups and tutorials that cover what’s new in Java 8. The Oracle Java 8 launch videos gathered knowledge together from many people directly involved in creating Java SE 8. Rather than covering specific features, I would like to gather details that many software teams should understand as they work on projects. What are the support lifetimes of each version of the Oracle JDK? Where do we find the list of changes across the major version, such as from Java SE 7 to SE 8? Noteworthy Points Oracle Java SE major releases are updated for the public with bug fixes, security fixes, and minor updates for a period of at least 3 years before the release reaches end-of-public-updates (EoPU). Oracle Java SE commercial product releases are supported for an even longer period of time from initial release date, enabling IT managers and ISVs to plan their upgrades according to their individual business practices. The release notes of major releases contain a compatibility guide about migration. Please consult the guide in addition to testing your program. Upgrades can be controlled and done in pieces, rather than upgrading all environments at once. Start with developer systems, then test environments, then production systems. Backward Compatibility Java versions are expected to be binary backwards-compatible. For example, JDK 8 can run code compiled by JDK 7 or JDK 6. It is common to see applications leverage this backwards compatibility by using components built by different Java version. A Compatibility Guide (explained later) exists for each major release to provide special mention when something is not backwards compatible. Oracle Java SE Support Timelines Oracle provides thoroughly tested binaries across a number of platforms along with additional tools for management and monitoring. The Oracle Java SE Support Roadmap identifies periods during which Oracle offers free (gratis) updates for a Java version. Oracle Java SE Version General Availability End of public updates notification End of public updates This copy only lists dates before its publication. See support roadmap for all current information. 8 March 2014 (see roadmap) (see roadmap) 7 July 2011 March 2014 (see roadmap) 6 Dec 2006 Feb 2011 Feb 2013 (maintenance releases through Java SE Advanced) 5 May 2004 Apr 2008 Oct 2009 Users can purchase Oracle’s commercial Java SE offerings, which provide support and updates beyond the end of public updates. There are some general rules to deal with these timeframes: Users may evaluate and provide feedback on Early Access Releases before the general availability of a specific major version. For example, eager developers can already test JDK 9 as it is being developed. Users may consider upgrading to a major release any time after it becomes generally available. Once the end of public updates notification goes out, users of this version should begin to plan to upgrade to the next major release. User who chose to avoid upgrading to the next major release can obtain a commercial support contract for Java SE in order to keep receiving updates. Identifying the list of changes between major versions Many application owners and developers begin their upgrade planning shortly after general availability of a major Java SE release. General availability is a time when changes and benchmarks stabilize a little, offering a more concrete understanding of, after upgrading, what will happen in production environments. The first general availability release contains a special piece in its release notes: the Compatibility Guide. This compatibility guide provides information about what one might encounter when upgrading an application from a previous version, such as from JDK 6 to JDK 7 or from JDK 7 to JDK 8. Those skipping a version from JDK 6 straight to JDK 8 may want to consult the guide for JDK 7 in-between. JDK 8 release notes for all versions and updates. Compatibility Guide for JDK 8. JDK 8 Adoption Guide. JDK 7 release notes for all versions and updates. Java SE 7 and JDK 7 Compatibility. JDK 7 Adoption Guide. Release notes for previous Java SE versions. If reading the release notes causes an analysis paralysis, consider using your application in a test environment. Then go back to check the notes and you may have a better understanding of what to look for while reading. In addition to the release notes, there are a large number of "What’s New" write-ups that showcase changes from a user perspective. For Java SE 8, here are a few good articles that both describe and teach new features: The Java Tutorials Blog about "Learn more about new features in Java SE 8." InfoQ eMag: Java 8. A Java 8 Tutorial by Benjamin Winterberg. 10 examples of Lambda expressions in Java 8 by Javin Paul’s Java Revisited blog. List of JDK 8 Features in OpenJDK. Presentations specific to upgrading the major Java version: Two other presentations explicitly cover upgrading across major Java versions: Smart Migration to JDK 8 by Geertjan Wielenga provides guidance on new features and how to update applications. Java 7 State of the Enterprise by Markus Eisele contains good information about upgrading from JDK 6 to JDK 7. The strategic guidance on upgrades is beneficial, but it was written in 2011 when Java SE 7 was still new. Uptake of Java SE 8 At present, both Java SE 7 and Java SE 8 are publicly updated per the Oracle Java SE Support Roadmap. The period of overlap allows thorough testing of both versions, with updates addressing issues that were identified. The current plan to debut Java 8 as the default on Java.com before the end of 2014 comes as a result of good testing: the Fedora project is switching their default, new versions of Scala will only run on Java 8, etc. I encourage you to consider upgrading systems to use Java SE 8 and take advantage of speed, shorter code, and the other benefits that it provides.

With the release of Java 8 back in March 2014, many users have already upgraded. They can take advantage of new features such as: Significant and noteworthy speed improvements (Fork/Join and Lambda). Sho...

Choosing 64 and/or 32 bit Java

The Java Platform was designed to allow applications to run on different hardware stacks and operating systems without changes. Java is available on Microsoft Windows in 64 and 32 bit versions, allowing users to get the appropriate version for their system. Users can even run both side-by-side for 64 bit operating systems. Getting the right version End-users should visit Java.com and click the Free Java Download link. The site will auto-detect the web browser and serve the appropriate download. For an explanation of how the website makes that determination, please see "Which Java download should I choose for my 64-bit Windows operating system.” Java with 64 and/or 32 bit web browsers Users that run Applets and Web Start applications through web browsers should choose the version of Java that matches their web browser. Generally speaking, 64 bit browsers run only 64 bit plugins and 32 bit browsers run only 32 bit plugins. As of mid-September 2014: Internet Explorer provides both a 32 and 64 bit executable. Users should match Java to the version they use, or use both Java versions. Most Mac applications are 64 bit, in particular the Safari and Firefox browsers. Chrome on Windows is currently 32 bit with plans to use 64 bit. Users should use 32 bit Java and plan to use 64 bit Java later. Mozilla Firefox on Windows is 32 bit, showing 64 bit as a Tier-3 platform. Users should use the 32 bit Java to run inside Firefox. Linux is similar to Mac in that most browsers are already 64 bit. In most cases, users of 64 bit Linux should use 64 bit Java. When you have a choice, there are many benefits to choosing 64 bit. Running 64 and 32 bit side by side Most users in managed environments should choose which browsers and runtimes to use – managing one installation is easier than two. If you cannot choose or do not know which you should choose, you can run both the 64 bit and 32 bit Java on the same computer. The relevant plugins will be available for both browser types, and system-wide configurations like Deployment Rule Sets will automatically apply to both When running both 64 and 32 bit versions on a Windows client, there will be two installations: C:\Program Files\Java\jre8 – The 64 bit version, available for local processes and 64 bit browsers like Internet Explorer (64 bit). C:\Program Files (x86)\Java\jre8 – The 32 bit version, used currently by browsers like Firefox and Chrome. Any configuration changes made to the runtime itself (e.g. inside the JRE folder) must be made to both Java installations: “Program Files” as well as “Program Files (x86).” Advanced Windows users that run local Java programs may want to check the following attributes as well: The PATH environment variable, to ensure that the preferred Java path is listed first. On my system, I use my 64 bit installation. The JAVA_HOME environment variable, if set, should point to the preferred Java. On my system, I use my 64 bit installation. The file associations for .jar and .jnlp files. On my system, I open them with my 64 bit Java. In the above examples on my system, I have chosen 64 bit each time. To do that, I also changed my browsers around to use the 64 bit version as the default and installed a separate 32 bit Java specifically for my Firefox client. Upgrades and Patches The 64 and 32 bit Java installations are separate from each-other. If you choose to use both, please plan to upgrade both at each scheduled Critical Patch Update or as prompted. If you decide to customize a JRE installation, such as disabling third party sponsor offers or changing Certificate Authority roots, you need to do that customization on both installations.

The Java Platform was designed to allow applications to run on different hardware stacks and operating systems without changes. Java is available on Microsoft Windows in 64 and 32 bit...

New Management Console in Java SE Advanced 8u20

Java SE 8 update 20 is a new feature release designed to provide desktop administrators with better control of their managed systems. The release notes for 8u20 are available from the public JDK release notes page. This release is not a Critical Patch Update (CPU). I would like to call attention to two noteworthy features of Oracle Java SE Advanced, the commercially supported version of Java SE for enterprises that require both support and specialized tools. The new Advanced Management Console provides a way to monitor and understand client systems at scale. It allows organizations to track usage and more easily create and manage client configuration like Deployment Rule Sets (DRS). DRS can control execution of tracked applications as well as specify compatibility of which application should use which Java SE installation. The new MSI Installer integrates into various desktop management tools, making it easier to customize and roll out different Java SE versions. Advanced Management Console (product page) The Advanced Management Console is part of Java SE Advanced designed for desktop administrators, whose users need to run many different Java applications. It provides usage tracking for those Applet & Web Start applications to help identify them for guided DRS creation. DRS can then be verified against the tracked data, to ensure that end-users can run their application against the appropriate Java version with no prompts. Usage tracking also has a different definition for Java SE than it does for most software applications. Unlike most applications where usage can be determined by a simple run-count, Java is a platform used for launching other applications. This means that usage tracking must answer both "how often is this Java SE version used" and "what applications are launched by it." Usage Tracking One piece of Java SE Advanced is a centralized usage tracker. Simply placing a properties file on the client informs systems to report information to this usage tracker, so that the desktop administrator can better understand usage. Information is sent via UDP to prevent any delay on the client. The usage tracking server resides at a central location on the intranet to collect information from those clients. The information is stored in a normalized database for performance, meaning that a single usage tracker can handle a large number of clients. Guided Deployment Rule Sets Deployment Rule Sets were introduced in Java 7 update 40 (September 2013) in order to help administrators control security prompts and guide compatibility. A previous post, Deployment Rule Sets by Example, explains how to configure a rule set so that most applications run against the most secure version but a specific applet may run against the Java version that was current several years ago. There are a different set of questions that can be asked by a desktop administrator in a large or distributed firm: Where are the Java RIAs that our users need? Which RIA needs which Java version? Which users need which Java versions? How do I verify these answers once I have them? The guided deployment rule set creation uses usage tracker data to identify applications both by certificate hash and location. After creating the rules, a comparison tool exists to verify them against the tracked data: If you intend to run an RIA, is it green? If something specific should be blocked, is it red? This makes user-testing easier. MSI Installer The Windows Installer format (MSI) provides a number of benefits for desktop administrators that customize or manage software at scale. Unlike the basic installer that most users obtain from Java.com or OTN, this installer is built around customization and integration with various desktop management products like SCCM. Desktop administrators using the MSI installer can use every feature provided by the format, such as silent installs/upgrades, low-privileged installations, or self-repair capabilities Customers looking for Java SE Advanced can download the MSI installer through their My Oracle Support (MOS) account. Java SE Advanced The new features in Java SE Advanced make it easier for desktop administrators to identify and control client installations at scale. Administrators at organizations that want either the tools or associated commercial support should consider Java SE Advanced.

Java SE 8 update 20 is a new feature release designed to provide desktop administrators with better control of their managed systems. The release notes for 8u20 are available from the public JDK...

Keeping users on Internet Explorer up-to-date and secure

Oracle actively works with many vendors on Java security and an important goal is finding ways to remove old and unsecure Java versions from circulation.   Oracle recommends that Java users keep their JRE installations up to date with the latest security baseline through the Java Auto Update feature. Microsoft Windows users have long been able to  improve the security of their computer by checking for old versions of Java and removing them using the Java Uninstall Tool. On August 6th, Fred Pullen and Jasika Bawa from Microsoft announced, on the Internet Explorer Team Blog, that Internet Explorer will soon block out-of-date ActiveX controls.  On August 10th, Microsoft updated their their blog with more technical information, timelines and pointers to more resources for developers and sysadmins. This Internet Explorer feature will provide Internet Explorer users with notifications when web pages try to load out-of-date Active X controls, like Java ActiveX controls provided by a JRE below the security baseline [1].  Additional documentation and information and how to configure and manage this new Internet Explorer feature are provided by Microsoft. At Oracle, maintaining the security-worthiness of Java is our priority.  As in this case with Microsoft, we continue to work together with our partners to keep Java users up-to-date and secure across different browsers and operating systems.  Enterprises that need to keep an older JRE around for legacy applications should still use a current JRE installed along the older JRE and leverage the Deployment Rule Set Functionality to limit access to the older JRE to well-known applications.   - Don 

Oracle actively works with many vendors on Java security and an important goal is finding ways to remove old and unsecure Java versions from circulation.   Oracle recommends that Java users keeptheir...

Java 7 update 67 patch release

The recent Java 7 update 65 contained an issue that prevents some Applet and Web Start applications from launching. As a result, we have released Java 7 update 67 to restore the functionality for affected users.This issue only affects some Rich Internet Applications and does not impact client or server-side applications. Java 7 update 67 is a functionality release: it is not a security fix or Critical Patch.End Users Download the latest release from java.com.The functionality issue in the previous release does not affect all applications, but having the latest release removes the question of which applications are or are not affected.Support ProfessionalsIf your users reported being unable to launch Rich Internet Applications after installing 7u65, please guide them to upgrade to 7u67.Release notes for 7u67 explain issue JDK-8050875, which can manifest itself with RIAs launched using a java_arguments parameter such as <param name="java_arguments" value="-Xmx192m"> but the client’s deployment.properties file does not contain a matching "deployment.javaws.jre.X.args=" entry.Please guide users to download and install Java 7 update 67.If your users are unable to upgrade, you may guide users to perform the following steps as a workaround:Open the Java control panel. Select the Java tab. Click ViewIn the "Runtime Parameters" area, enter the number 7 and then backspace over it. Click OK.

The recent Java 7 update 65 contained an issue that prevents some Applet and Web Start applications from launching. As a result, we have released Java 7 update 67 to restore the functionality...

Deep monitoring with JMX

The Java Platform is designed as a modular system, where each item in the conceptual diagram provides specific functionality. One commonly requested feature of software platforms is the ability to monitor an application for CPU, memory and resource usage, and other statistics. The Java Platform Standard Edition (Java SE) has provided the Java Management eXtension (JMX) since Java SE 5.0 (2004). There are several benefits to having this type of monitoring as part of the platform:Unlike operating system tools (e.g. htop or Task Manager), the details are specific to the application. Instead of just overall CPU and memory usage, it is possible to see what part of the application is consuming those resources. Applications can surface their own business-related Management Bean to the JMX rather than building a new monitoring user interface. The monitoring agent is already available inside the runtime. There is no need to embed additional items in your application. JMX connections take place at the JVM level rather than inside the application. Monitoring information is available either locally or remotely. By using different firewall rules for JMX than your application, you can scope monitoring to a smaller audience. System administrators can institute direct connections rather than periodic polling, for faster alerts or reaction time. This entry will cover the role of JMX and the ways in which it is designed to help developers and system administrators.JMX Basics: an agent and a viewerJMX capabilities are split into two parts:The JMX agent that serves information is available within the runtime. This runs alongside your application. A JMX viewer, like jConsole or Java Mission Control. These viewers use a local or remote connection to read information from the running agent. Other third party viewers will be covered later. By default, jConsole shows information about memory usage, CPU usage, thread usage, and class information. Unlike standard operating system tools like htop or Task Manager, the information is at a deeper level inside the JVM and can also seen on authenticated remote systems. By default JMX allows local connections to the process owner -- instead of username/password, you are authenticated by NTFS permissions (on Windows).In this screenshot of one small Java application I was running, you can clearly see the periodic small garbage collections. The minor incremental collection has significantly improved since the late 1990s.The separate MBeans tab provides ways to show additional diagnostics as well as additional information. When using third party Java applications, I often launch them through small scripts and do not know the complete invocation information. The com.sun.managementDiagnosticCommand lets me click a "vmCommandLine" button and see what the launch script actually did.In many situations, such as application servers, the application may be running on an entirely different host.Authenticated remote monitoring for System AdministratorsAny remote monitoring system must come with proper access controls built in. The remote monitoring capabilities in JMX allow for clients to monitor information happening on servers or other devices without having any user interface on those systems. Applications typically turn on remote JMX capabilities either through launch scripts setting:-Dcom.sun.management.jmxremote.port=portNum-Djava.rmi.server.hostname=OptionalHostnameConnectionRestrictionWhen specifying the port number above, it is an important distinction that JMX information is served separately from the application. For example a web application might serve requests on ports 80 and 443 yet allow JMX connections on a separate port with more restrictive firewall rules. Normal users would be unable to even attempt JMX access.After configuring a firewall rule, it is critical to authenticate users against one of the three main methods:File-based passwords are probably the simplest to set up but require a shared secret and are sometimes harder to change. Your JRE already has an example configured file at JRE/lib/management/ jmxremote.password.template. LDAP for enterprises. The benefit of LDAP integration is group authentication, as well as automatic integration with joiner/leavers processes. SSL certificates for password-less connections. This allows client authentication based on public keys in a way that no passwords are ever exchanged. The JMX Agent user guide contains details on all other JMX configuration parameters. These capabilities can also integrate JMX with SNMP tools. For other protocols, consider using JMXMP through OpenDMK.Do not turn security offWithin the JMX documentation, there are options listed for turning security off so that no authentication and authorization is performed on connections. Do not use that configuration unless you are temporarily testing a different tool and just wondering if authentication is causing a problem. Once you ascertain yes or no, you should stop turning authentication off.Third party monitoring example: NagiosJMX provides a level of application introspection that provides system administrators with a way to look inside the application and provide some level of diagnostics that are beneficial to the development teams. It can also be integrated into systems like Nagios’ JMX monitor and extends alert and monitoring capabilities to act on the extra details.Exposing custom metrics to JMX for DevelopersItems within the Java platform are designed for extensibility. While all applications look for details about resource usage, other information can be beneficial. The Java tutorial on JMX provides details on how to create new MBeans that would expose custom information to jConsole.There are a variety of cases where a developer may want to create a new MBean. For example: A batch file processing task may count the number of files it has processed. Instead of printing to a lengthy console, the developer could monitor progress and leave the console for important information. An application may count the number of successful logins per day, failed logins, or a ratio between the two. They could then monitor the system for odd behavior such as unexpected high or low usage. For various use cases, the application could track how many times that use case has happened. This is similar to the login tracking above, but for different features. This would be a simple way of tracking popularity of use cases in relation to each-other. Any other information that is beneficial for tracking, charting, or alerting. API documentation is available within the java.lang.management package.Sample code for creating MBeans and interacting with JMX within the Java SE Downloads. Download the "Demos and Samples" project and open the sample/jmx folder.Open-Source Example: Apache QPidApache QPid is a message broker for reliable inter-application communication. During operation, QPid uses JMX to expose a helpful information and statistics about the runtime. A system administrator can analyze throughput, message queue statistics, or other things that would be unavailable to other monitoring tools.The JMX Management section of the online QPid Message Broker book explains how their system can be monitored. For developers looking to create MBeans, that chapter also links directly to their open-source code for more examples.JMX on Embedded DevicesJava SE Embedded provides JMX within its Compact 3 profile. The functionality is the same as what you would encounter on non-embedded devices.For additional details on Compact Profiles in the embedded space, see "Compact Profiles: Space and Security" or the jrecreate command.Advanced MonitoringThe standard jConsole system is beneficial for monitoring, but many organizations have different needs. There are different application servers, clusters, different types of systems, embedded devices, and many other cases. The Java Platform’s open standards have provided a stable foundation for a number of advanced monitoring systems. Some monitoring systems use JMX, others use the JVM TI.Oracle provides a commercial monitoring system named Mission Control and Flight Recorder that is able to surface an application’s statistics and take automatic action. Flight Recorder has been available in all JREs since Java 7 update 2 (April 2012).Unlike many monitoring systems that begin recording on a trigger, flight recorder is a minimal-overhead black-box that continually records. When your trigger event occurs, it can provide details about what went on before that event happened. As a result, developers can track down bugs that cannot be replicated outside of a production environment. Marcus Hirt has done a video introduction to Java Mission Control that explains many details and features, such as creating recordings, setting triggers, and controlling remote operations. The video covers the current version of Mission Control (5.3) that took place after HotSpot and JRockit were merged into a single VM.JMX UsageThe built-in monitoring capabilities of the Java platform provide developers and system administrators with ways to understand their applications without building a new interface. Developers are able to create custom MBeans that expose application-level information to any JMX browser such as jConsole or Mission Control. Many monitoring systems use JMX as a way of understanding internal application health.For a more complete description on the role of JMX and examples of how to configure it, react to events, or build new MBeans, please see the Java Management Extensions (JMX) Technology Tutorial or Monitoring and Management for the Java Platform.

The Java Platform is designed as a modular system, where each item in the conceptual diagram provides specific functionality. One commonly requested feature of software platforms is the ability to...

Diagnosing TLS, SSL, and HTTPS

When building inter-connected applications, developers frequently interact with TLS-enabled protocols like HTTPS. With recent emphasis on encrypted communications, I will cover the way in which the JDK evolves regarding protocols, algorithms, and changes, as well as some advanced diagnostics to better understand TLS connections like HTTPS. Most developers will not have to do this level of diagnosis in the process of writing or running applications. In the event that you do, the following information should provide enough information to understand what's happening within secure connections. Stability: The evolution of protocols and algorithms For the last 15 years (since 1998), the Java platform has evolved through the Java Community Process where companies, organizations, and dedicated individuals develop and vote on specifications to determine what makes up the Java Platform. Much of the efforts are centered on compatibility, like the TCK, ensuring that different implementations are compatible with each-other and that developers can predict how their applications will run. We are not changing critical default options (like TLS protocol) within minor versions. The following chart depicts the protocols and algorithms supported in each JDK version: JDK 8(March 2014 to present) JDK 7(July 2011 to present) JDK 6(2006 to end of public updates 2013) TLS Protocols TLSv1.2 (default)TLSv1.1TLSv1SSLv3 TLSv1.2TLSv1.1TLSv1 (default)SSLv3 TLS v1.1 (JDK 6 update 111 and above)TLSv1 (default)SSLv3 JSSE Ciphers: Ciphers in JDK 8 Ciphers in JDK 7 Ciphers in JDK 6 Reference: JDK 8 JSSE JDK 7 JSSE JDK 6 JSSE Java Cryptography Extension, Unlimited Strength (explained later) JCE for JDK 8 JCE for JDK 7 JCE for JDK 6 Sample Java code for making an HTTPS connection Making an HTTPS connection in Java is relatively straight-forward. I will post the code here with the intent focused on tuning and understanding the underlying capabilities. Sample back-end code for making an SSL connection: final URL url = new URL("https://example.com");try(final InputStream in = url.openStream()){  //…} Or the connection can be tuned through a cast: final HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();//operate on connconn.connect();try(final InputStream in = conn.getInputStream()){  //…} Example: Qualys SSL Labs' "View My Client" Page Qualys SSL Labs maintains a collection of tools that are helpful in understanding SSL/TLS connections. One in particular is a View My Client page, which will display information about the client connection. By integrating with that page, I was able to control the implementation as I used different Java tuning parameters. To test parameter tuning, I implemented a small JavaFX application in JavaScript. It displays that page in a WebView, showing information about the underlying Java SSL/TLS client connection. You can find the code in the appendix. JSSE Tuning Parameters When diagnosing TLS-related issues, there are a number of helpful system properties. They are generally covered in their relevant sections of JSSE but this single collection may help anyone looking to understand the flexibility of Java’s implementation or diagnose connection details. javax.net.debug  Prints debugging details for connections made.Example: -Djavax.net.debug=all or -Djavax.net.debug=ssl:handshake:verbose https.protocols Controls the protocol version used by Java clients which obtain https connections through use of the HttpsURLConnection class or via URL.openStream() operations. For older versions, this can update the default in case your Java 7 client wants to use TLS 1.2 as its default.Example: -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 For non-HTTP protocols, this can be controlled through the SocketFactory's SSLContext. jdk.tls.client.protocols Controls the underlying platform TLS implementation . Additional information is available in the JSSE Reference Guide.Example: -Djdk.tls.client.protocols=TLSv1.1,TLSv1.2Available in all JDK 8 releases, or after Java 7 update 95 (January 2016) and Java 6 update 121 (July 2016). http.agent When initiating connections, Java will apply this as its user-agent string. Modifying this will handle cases where the receiving party responds differently based on the user-agent.Example: -Dhttp.agent="known agent" java.net.useSystemProxies java.net.useSystemProxiesUse proxy details from the operating system itself.Example: -Djava.net.useSystemProxies=true http.proxyHosthttp.proxyPort The proxy connection to use for HTTP connections.Example: -Dhttp.proxyHost=proxy.example.com -Dhttp.proxyPort=8080 https.proxyHosthttps.proxyPort The same as above, except that configuration is separate between HTTP and HTTPS. http.proxyUserhttp.proxyPasswordhttps.proxyUserhttps.proxyPassword Password-based credentials for the above proxies. Many other protocols and properties can be found within the following areas: Java Networking and Proxies. Java Networking core documentation. Java Secure Socket Extension (JSSE) Reference Guide. Example of diagnosing a problem When making an HTTPS connection, let’s assume that the client threw the following exception due to a failed handshake with the server: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure SSLHandshakeException is a subclass of the IOException, so you do not need to catch is explicitly. Most developers will not need an explicit catch, but it may help you more easily diagnose the cause of any IOException. When applying the -Djavax.net.debug=all property from above, the failure associated with this SSLHandshakeException would appear immediately after algorithm negotiation in the logs.  JDK 7 (fails on unsupported algorithm) JDK 8 (works fine) Cipher Suites: […Long list of ciphers…]Compression Methods:  { 0 }Extension elliptic_curves, curve names: {…}Extension ec_point_formats, formats: [uncompressed]Extension server_name, server_name: [host_name: HOST]***main, WRITE: TLSv1 Handshake, length = 168main, READ: TLSv1 Alert, length = 2main, RECV TLSv1 ALERT:  fatal, handshake_failuremain, called closeSocket()main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure Cipher Suites: […Long list of ciphers…]Compression Methods:  { 0 }Extension elliptic_curves, curve names: {…}Extension ec_point_formats, formats: [uncompressed]Extension signature_algorithms, signature_algorithms: …Extension server_name, server_name: [type=host_name (0), value=HOST]***main, WRITE: TLSv1.2 Handshake, length = 226main, READ: TLSv1.2 Handshake, length = 89*** ServerHello, TLSv1.2RandomCookie:  GMT: -1809079139 bytes = { …}Session ID:  {…}Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256Compression Method: 0Extension renegotiation_info, renegotiated_connection: <empty>Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]***%% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]** TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256main, READ: TLSv1.2 Handshake, length = 2308 In the case above, the failure occurred during the handshake. The most likely cause for that is algorithm support. The JDK provides a separate package called JCE Unlimited Strength, designed to add stronger algorithm support than what’s available by default. Qualys SSL Labs provides a different server SSL test that will enumerate which algorithms a server supports. Many TLS error messages are covered in a few pieces of documentation: The JSSE Reference Guide’s Debugging Utilities contains many commands, sample code, and error message diagnostics. Debugging SSL/TLS Connections provides details on how to read the output from using the javax.net.debug options. How SSL Works inside the JSSE provides an explanation of the underlying protocols, explaining which messages may occur when something goes wrong. A third party book, Bulletproof SSL, contains a chapter on TLS in Java. Adding stronger algorithms: JCE Unlimited Strength In a high security environment, one way of strengthening algorithms in the JDK is through the JCE Unlimited Strength policy files. In this particular case, replacing those policy files within JDK 7 allows it to use the stronger variants of existing algorithms and connect successfully. JCE Unlimited Strength downloads: JDK 8, JDK 7, or JDK 6. Appendix The following code will open Qualys SSL Labs’ View My Client page within a Java client. To test configurations, run this like: jjs -fx viewmyclient.jsjjs -fx -Dhttps.protocols=TLSv1 viewmyclient.js var Scene = javafx.scene.Scene;var WebView = javafx.scene.web.WebView;var browser = new WebView();browser.getEngine().load("https://ssllabs.com/ssltest/viewMyClient.html");$STAGE.scene = new Scene(browser);$STAGE.show();

When building inter-connected applications, developers frequently interact with TLS-enabled protocols like HTTPS. With recent emphasis on encrypted communications, I will cover the way in which the...

Nashorn, the rhino in the room

Nashorn is a new runtime within JDK 8 that allows developers to run code written in JavaScript and call back and forth with Java. One advantage to the Nashorn scripting engine is that is allows for quick prototyping of functionality or basic shell scripts that use Java libraries. The previous JavaScript runtime, named Rhino, was introduced in JDK 6 (released 2006, end of public updates Feb 2013). Keeping tradition amongst the global developer community, "Nashorn" is the German word for rhino. The Java platform and runtime is an intentional home to many languages beyond the Java language itself. OpenJDK’s Da Vinci Machine helps coordinate work amongst language developers and tool designers and has helped different languages by introducing the Invoke Dynamic instruction in Java 7 (2011), which resulted in two major benefits: speeding up execution of dynamic code, and providing the groundwork for Java 8’s lambda executions. Many of these improvements are discussed at the JVM Language Summit, where language and tool designers get together to discuss experiences and issues related to building these complex components. There are a number of benefits to running JavaScript applications on JDK 8’s Nashorn technology beyond writing scripts quickly: Interoperability with Java and JavaScript libraries. Scripts do not need to be compiled. Fast execution and multi-threading of JavaScript running in Java’s JRE. The ability to remotely debug applications using an IDE like NetBeans, Eclipse, or IntelliJ (instructions on the Nashorn blog). Automatic integration with Java monitoring tools, such as performance, health, and SIEM. In the remainder of this blog post, I will explain how to use Nashorn and the benefit from those features. Nashorn execution environment The Nashorn scripting engine is included in all versions of Java SE 8, both the JDK and the JRE. Unlike Java code, scripts written in nashorn are interpreted and do not need to be compiled before execution. Developers and users can access it in two ways: Users running JavaScript applications can call the binary directly:jre8/bin/jjs This mechanism can also be used in shell scripts by specifying a shebang like #!/usr/bin/jjs Developers can use the API and obtain a ScriptEngine through:ScriptEngine engine = new ScriptEngineManager().getEngineByName("nashorn"); When using a ScriptEngine, please understand that they execute code. Avoid running untrusted scripts or passing in untrusted/unvalidated inputs. During compilation, consider isolating access to the ScriptEngine and using Type Annotations to only allow @Untainted String arguments. One noteworthy difference between JavaScript executed in or outside of a web browser is that certain objects will not be available. For example when run outside a browser, there is no access to a document object or DOM tree. Other than that, all syntax, semantics, and capabilities are present. Examples of Java and JavaScript The Nashorn script engine allows developers of all experience levels the ability to write and run code that takes advantage of both languages. The specific dialect is ECMAScript 5.1 as identified by the User Guide and its standards definition through ECMA international. In addition to the example below, Benjamin Winterberg has a very well written Java 8 Nashorn Tutorial that provides a large number of code samples in both languages. Basic Operations A basic Hello World application written to run on Nashorn would look like this: #!/usr/bin/jjsprint("Hello World"); The first line is a standard script indication, so that Linux or Unix systems can run the script through Nashorn. On Windows where scripts are not as common, you would run the script like: jjs helloWorld.js. Receiving Arguments In order to receive program arguments your jjs invocation needs to use the -scripting flag and a double-dash to separate which arguments are for jjs and which are for the script itself:jjs -scripting print.js -- "This will print" #!/usr/bin/jjsvar whatYouSaid = $ARG.length==0 ? "You did not say anything" : $ARG[0]print(whatYouSaid); Interoperability with Java libraries (including 3rd party dependencies) Another goal of Nashorn was to allow for quick scriptable prototypes, allowing access into Java types and any libraries. Resources operate in the context of the script (either in-line with the script or as separate threads) so if you open network sockets and your script terminates, those sockets will be released and available for your next run. Your code can access Java types the same as regular Java classes. The “import statements” are written somewhat differently to accommodate for language. There is a choice of two styles: For standard classes, just name the class: var ServerSocket = java.net.ServerSocket For arrays or other items, use Java.type: var ByteArray = Java.type("byte[]")You could technically do this for all. The same technique will allow your script to use Java types from any library or 3rd party component and quickly prototype items. Building a user interface One major difference between JavaScript inside and outside of a web browser is the availability of a DOM object for rendering views. When run outside of the browser, JavaScript has full control to construct the entire user interface with pre-fabricated UI controls, charts, or components. The example below is a variation from the Nashorn and JavaFX guide to show how items work together. Nashorn has a -fx flag to make the user interface components available. With the example script below, just specify: jjs -fx -scripting fx.js -- "My title" #!/usr/bin/jjs -fxvar Button = javafx.scene.control.Button;var StackPane = javafx.scene.layout.StackPane;var Scene = javafx.scene.Scene; var clickCounter=0;$STAGE.title = $ARG.length>0 ? $ARG[0] : "You didn't provide a title";var button = new Button();button.text = "Say 'Hello World'";button.onAction = myFunctionForButtonClicking;var root = new StackPane();root.children.add(button);$STAGE.scene = new Scene(root, 300, 250);$STAGE.show(); function myFunctionForButtonClicking(){  var text = "Click Counter: " + clickCounter;  button.setText(text);  clickCounter++;  print(text);} For a more advanced post on using Nashorn to build a high-performing UI, see JavaFX with Nashorn Canvas example. Interoperable with frameworks like Node, Backbone, or Facebook React The major benefit of any language is the interoperability gained by people and systems that can read, write, and use it for interactions. Because Nashorn is built for the ECMAScript specification, developers familiar with JavaScript frameworks can write their code and then have system administrators deploy and monitor the applications the same as any other Java application. A number of projects are also running Node applications on Nashorn through Project Avatar and the supported modules. In addition to the previously mentioned Nashorn tutorial, Benjamin has also written a post about Using Backbone.js with Nashorn. To show the multi-language power of the Java Runtime, there is another interesting example that unites Facebook React and Clojure on JDK 8’s Nashorn. Summary Nashorn provides a simple and fast way of executing JavaScript applications and bridging between the best of each language. By making the full range of Java libraries to JavaScript applications, and the quick prototyping style of JavaScript to Java applications, developers are free to work as they see fit. Software Architects and System Administrators can take advantage of one runtime and leverage any work that they have done to tune, monitor, and certify their systems. Additional information is available within: The Nashorn Users’ Guide Java Magazine’s article "Next Generation JavaScript Engine for the JVM." The Nashorn team’s primary blog or a very helpful collection of Nashorn links.

Nashorn is a new runtime within JDK 8 that allows developers to run code written in JavaScript and call back and forth with Java. One advantage to the Nashorn scripting engine is that is allows...

Compact Profiles: Space and Security

Compact Profiles provide a way for developers and device manufacturers to package and update Java SE on space-constrained devices. Teams building software for those devices can trim the size of the embedded JRE by choosing a Compact Profile without items that are not used by their application. Additional details are present in Java Magazine’s March Issue, as well as the Java SE 8 launch videos “Developing Embedded Applications with Java SE 8 Compact Profiles.” By shrinking the size of the JRE, we enable developers to use their existing Java skills in new areas and take advantage of hardware like the Raspberry Pi, the BeagleBoard, and many others. This post will cover a few aspects of Compact Profiles: Comparisons between complete JRE and each profile Threat modeling of a Compact Profile Identifying and creating your compact JRE Configuring, installing, and updating your compact JRE Summary of compact profiles Comparisons between the complete JRE and each profile To see the various areas that Java runs in, here is a chart of sizes:  Version Approx. Size Installed Used for JDK 8Most developers use this. 431MB Developers building Java applications and/or profiling them with Mission Control. JRE 8Most client systems use this. 163MB Clients running Java applications on their Windows/Max/Linux desktop. Server JRE 8 136MB Server systems, for running back-end processes or application servers. This JRE can run servlet containers and compile JSPs. It is smaller than the regular JDK because it does not contain the browser plug-in, Java Mission Control, or VisualVM. Java SE Embedded 8 Embedded devices like the Raspberry Pi, BeagleBoard, etc. Java SE Embedded compact 3 21MB Embedded devices requiring Kerberos or remote monitoring like JMX, but not APIs like Swing, CORBA, and Java Sound. Java SE Embedded compact 2 15MB Embedded devices making use of SQL connectivity or XML processing, but not any functionality from compact3. Java SE Embedded compact 1 11MB Embedded devices requiring a minimal version of Java SE, but not any functionality from compact2. Java ME Embedded Varies based on highly constrained device. Highly constrained embedded devices. If you are working on an embedded device and wondering which profile you should use, please see the video “Choosing a Compact Profile for your Deployment.” It is also possible to mix-and-match certain items in different profiles through extensions. Complete details for each profile, including API listing, are located on the Compact Profiles page and within JEP 161. Threat modeling of a Compact Profile Compact profiles also contain a different threat model than the typical JDK Conceptual Diagram. Although the runtime is similar from the application’s point of view, the profiles are defined by items that are NOT present. For example any risk or potential misuse associated with Java2D would be mitigated in the compact3 profile, which does not include that component. The Server JRE is a similar example: by not even having the deployment components of RIAs and browser plugins, the risk is eliminated (servers typically do not use that functionality). It is possible to reduce and mitigate other threats as well given the control that the device manufacturer or operator has over installation/updates of the JRE. For example after creating a compact profile, one could decrease the threat model’s scope of Spoofing and likely Information Disclosure by updating the default keystore to remove everything except known-needed roots and then requiring encryption. Identifying and creating a Compact Profile JDK 8 provides a new tool called JDeps that can look at a collection of JAR and CLASS files and report on which compact profiles are used. When using JDeps to evaluate profiles, the report is transitive: if all your code fits in compact1 but you require something else that needs the larger compact2, then you must either use compact2 or remove the offending component. Example usage of this is:jdeps -profile filename.jar filename.jar -> C:\Program Files\Java\jdk1.8.0\jre\lib\jce.jar (compact1) filename.jar -> C:\Program Files\Java\jdk1.8.0\jre\lib\rt.jar (Full JRE) filename.jar -> AnotherPackage.jar    your.package (filename.jar)       -> com.sun.deploy.config   JDK internal API (deploy.jar)       -> java.io                 compact1       -> java.lang               compact1       -> java.lang.invoke        compact1       -> java.math               compact1 Additional details can be found in Jim Connors’ blog, Compact Profiles Demonstrated. JDeps can also be used to identify reliance of non-spec internal JDK APIs that are subject to removal, so that you can move to the appropriate public replacement. Creating, configuring, and updating your Compact Profile Once you have identified the appropriate profile, you can create a compact profile that will run on the target device. Download the version of Java SE Embedded for your target platform. Unzip the version that you downloaded into its usual ejdk folder. Use the included bin/jrecreate command to create the profile.This step requires a JAVA_HOME variable, which should point to your system’s java installation and not anything related to the target device. For non-embedded OpenJDK, the profiles must be built separately on Linux. Examples: To create the bare minimum compact1 profile: jrecreate -d ~/compact1 -profile compact1 To create the bare minimum compact1 profile that also has the sun elliptical curve extension: jrecreate -d ~/compact1WithEC -profile compact1 -x sunec Once created, simply copy the newly created folder to your device and run it like any other application. Configuring your Compact Profile Once the compact profile has been created, it contains several noteworthy items beyond the JRE itself. One file in particular, called bom, lists the bill of materials for this compact JRE. By having that file, you and any subsequent users will be able to see precisely what went into this profile, when it was created, and other useful piece of information. You may then customize the information as you would any other JRE. All configuration files are present, such as such as network configuration and proxy information, timezone data, etc. Updating your Compact Profile Any compact profile that you create is outside the scope of typical package management systems like RPM. For a device manufacturer, there are many commercial systems which exist to handle this. It is recommended to have a mechanism for patching devices, should the need arise. Although devices may perform minimal operations, it is reasonable to plan ahead for software updates of your applications, the compact Java profile, as well as any underlying operating system and its libraries. Summary Compact profiles provide a way to trim down the Java runtime in order to fit on embedded devices, either as a system component or part of an application. Not only can compact profiles shrink the size of a Java runtime down to 11MB, it also decreases the potential attack surface.

Compact Profiles provide a way for developers and device manufacturers to package and update Java SE on space-constrained devices. Teams building software for those devices can trim the size of the...

Deployment Rule Set by Example

Recently I encountered a situation whereby a System Administrator needed to adjust thieir systems to run a specific RIA on an older version of Java. By using Deployment Rule Sets, we were able to achieve the desired outcome. The specific RIA ran using the older version of Java with no prompts to the end users, while all other RIA applications used the latest, most secure version of Java. This post is intended for System Administrators managing a white list within an organization. Assessing the environment In this particular case, the RIA itself was designed to run on Java 6 update 31 (released in February 2012, but public updates for Java SE 6 ended in February 2013). That also means that it does not adhere to the security requirements introduced in a recent Java SE 7 Critical Patch Update. Because this RIA was known to be safe and necessary for business operations, the goal was to be able to execute it with no prompts. Installing multiple versions of Java When delegating RIAs to use older Java versions, it is necessary to have at least two installations available: The latest Java version, which will be used by default except in cases where you configure it to delegate to the older version. We installed this as the default patch-in-place. The specific older versions needed by the RIA, which will only be accessible through your Deployment Rule Set. We installed this as a static installation to prevent any interference in case that a different Java SE 6 version had to be installed for something else. Although older versions are not updated with the latest security patches and not recommended for use in production, the Deployment Rule Set mitigates the definition of "in production" because the older JRE is only accessible from explicitly whitelisted areas. Information about these installation types can be found within a previous post, Managing Multiple Java Versions. Comprehensive documentation is provided by Oracle about silent installation switches for package management as well as disabling third-party sponsors. Once items were installed, we had two noteworthy locations on the Windows desktops (others may be available as well, but these are the important ones): C:\Program Files\Java\jre7 C:\Program Files\Java\jre1.6.0_31 Creating the Deployment Rule Set Instructions on creating a Deployment Rule Set are available in the post Introducing Deployment Rule Sets or in the complete Deployment Rule Set documentation. The actual deployment rule set used looks like: <!-- Example Deployment Rule Set that allow a desktop administrator to control end-user's execution of browser applets.  See http://docs.oracle.com/javase/8/docs/technotes/guides/jweb/security/deployment_rules.html --><ruleset version="1.0+">    <rule>        <id location="https://java.com/" />        <action permission="run" version="SECURE" />    </rule>    <rule>        <id location="http://internal.example.com/" />        <action permission="run" version="1.6.0_31" />    </rule></ruleset> In this example, we were able to identify and test each item. For example, the first rule checks that users could run the normal Java.com detection applet without any prompts. That demonstrated the correct setup of the DRS. Once successfully set up, the second rule allowed us to target their application. Ensure the DeploymentRuleSet.jar is signed correctly for each Java installation Most certificates from Certificate Authorities should work out of the box. The certificate used to sign your Deployment Rule Set must be trusted by each Java installation. After your Deployment Rule Set is in place (in the documented area), the easiest way to check is to look at the control panel. Instructions for checking this are in the previous post, Introducing Deployment Rule Sets, under the “Verify usage of your rule set on a client desktop.” Importing certificates into the older Java version Although most administrators do not need this step, sometimes the older JRE does not contain the newer root certificate. In that case, it is necessary to locate the CA’s root certificate and explicitly import it: "C:\Program Files\Java\jre1.6.0_31\bin\keytool" -importcert -keystore "C:\Program Files\Java\jre1.6.0_31\lib\security\cacerts" -alias AuthNameNoSpaces -file TheRootTheyProvided.cer Once we had the root’s certificate inside both keystores, the RIA launched correctly on the older Java 6. Verifying "is this working right" Testing your Rule Set involves opening the RIA and verifying execution. Other system tools will help check and verify any assumptions. In addition to launching RIAs like the Java.com detection applet, the regular Task Manager will help understand which versions are getting launched. Within the basic Task Manager, the Processes tab can show a command line column. In the case that you are launching a different version, you can show the Command Line column. In this screenshot, I’ve shrunk the view but it’s easy to see what I am running. There are other tools available to view a process chain as well, where you will see a chain that looks like: iexplorer.exe jp2launcher.exe java.exe (from the default JRE installation area) java.exe (from your targeted JRE usage area) Automating Package Installation Once the item was identified as working, we were able to integrate the previous silent installation switches to roll the installations out onto different computers. Most users or members of staff can run basic installers or scripts as needed. Large enterprises with desktop management systems often combine silent installation switches and customization commands (like the keytool import) with MSI creators, and then roll a single file out for installation. I will refrain from discussing package creation and roll-out in detail. Use the right mechanism that works within your organization. Reminder about external distribution The Deployment Rule Set feature is intended for organizations to manage their own configurations. It is not meant as a way to simply "whitelist everything just so warning dialogs go away," "force everyone to never update," or "external users please download this file onto your system to use this application." By default, specifying the version="SECURE" attribute is best unless you know specific reasons restricting compatibility to a specific JRE version. Publicly distributed Deployment Rule Sets found to contain insecure "whitelist everything" configurations may have their signing certificate blacklisted from future use of Deployment Rule Sets. Additional Helpful Information Appendix: Debugging if things to not work as expected System Administrators new to Java may find the Java console useful to understand what is happening. Most users neither turn on nor see this console. By turning the console on in the Java control panel, we were able to see execution. The first line in that file indicates the current version in use: JRE 1.8.0-b132. This is clearly not 1.6.0_31, meaning that it matches the first rule. When we began using the Deployment Rule Set that delegated to Java 6 update 31, two major things happened: In the Task Manager process tree, two Java processes appeared. The first was the latest Java, the second was the older version connected to this process. Because we had the Java console turned on, two consoles appeared: one for each version. If you press ‘5’ on that console, it will output a significant amount of log information. I won’t paste a sample log here because they can get long, but the really interesting parts look like:  Sample from log What it tells us  Using JRE version 1.8.0-b132 Java HotSpot(TM) 64-Bit Server VM  At the top, this tells us which version is currently in use.  Lines beginning with “ruleset:”ruleset: RuleSetParser.parse() returning 2 rules:  These tell what is happening with the DRS, isolated from other information.  Lines that talk about “ruleset” and “location”ruleset: finding Deployment Rule Set for         title: Java Uninstall Applet        location: https://java.com/applet/JavaRemovalTool/launch.jnlp        jar location: https://java.com/applet/JavaRemovalTool/JavaRemovalTool.jar        jar version: null        isArtifact: true  The location information helps me understand if I told the ruleset to whitelist the right place.Sometimes, though not often, the browser URL and actual application URL are different.In the example to the left, both are on https://java.comAlthough my browser visits an area, /en/download/installed.jsp the actual files are hosted in /applet.That means copying from my browser’s address bar would not have worked. Appendix: Identifying applications by Certificate Hash or Location The two primary ways of creating a deployment rule are by location or certificate hash. Certificate hashes help identify a publisher. For example I could automatically run Oracle RIAs by creating a rule to run RIAs whose certificate hash is 794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6.This rule would take effect regardless of where the RIA was hosted. Location identifies where the RIA (specifically its JAR files) is hosted. This is sometimes easier to copy from a browser’s address bar and can be used in cases where the RIA publisher did not actually sign the RIA. If the RIA uses LiveConnect (javascript integration), you must create a Location rule to whitelist the hosting domain and accept the LiveConnect calls. Within the Java Console, there are also ways to locate both of those identifiers. security: SHA-256Certificate finger print: Long certificate hash basic: Plugin2ClassLoader.addURL parent called for http://url.example.com/path/someFile.jar Those will help identify the items that the RIA plugin is seeing, so then you can look for one of the following messages: ruleset: Rule hash matches certificate hash (or a similar message about location) ruleset: no rule applies, returning Default Rule

Recently I encountered a situation whereby a System Administrator needed to adjust thieir systems to run a specific RIA on an older version of Java. By using Deployment Rule Sets, we were able to...

Secure Coding Guidelines for Java SE

With so much happening around the Java platform, it’s understandable if you missed the recent improvements we made to the Secure Coding Guidelines for Java SE.  In January 2014 the Java Platform Group released a significant update, Java 7 Update 51 establishing code-signing as the default for Applets and Web Start applications.  Following in March 2014, we hit another major milestone with the long anticipated release of Java SE 8. There are a number of improvements to the Secure Coding Guidelines for Java SE.  On the surface, the larger domains of the coding guidelines like Fundamentals and Denial of Service are the same but content has been improved throughout each domain based upon changes to Java’s threat landscape.  Likewise, small but noteworthy improvements to content navigation were made to the domains in table of contents facilitating quick navigation for readers. Beyond content improvements, code examples were refreshed to highlight new Java 8 features like Lambda.  While our coding guidelines are updated for Java SE 8, most guidance is relevant to older versions like Java SE 7.  Please keep in mind secure application coding and design is only one component in a secure solution.  Building secure solutions requires OS security hardening, application and infrastructure hardening, patching all components on a timely schedule, etc.  More information about Java security is available in the Security Resource Center for Java.

With so much happening around the Java platform, it’s understandable if you missed the recent improvements we made to the Secure Coding Guidelines for Java SE.  In January 2014 the Java Platform Group...

JavaOne 2014 Security Track Early Acceptance Sessions

JavaOne 2014 is Oracle's flagship software developers conference event for Java.  Security has been a focus at the conference for many years but last year Oracle brought security to the forefront by including it as a track.  If you have ideals for interesting Java security sessions we would be delighted to review them.  The JavaOne CFP is open until April 14, 2014.  Back to the security track, each year the tracks highlight their early acceptance sessions to build momentum for the conference.  This year I would like to highlight the following early acceptance sessions for the security track and show a little of what we are planning.   CON2120 Anatomy of Another Java Zero-Day Exploit Presenter:  David Svoboda, Software Security Engineer, Carnegie Mellon Abstract:  Java was recently hit by several major exploits. These exploits were written in pure Java and relied on several obscure components of the Java library. Understanding how exploits undermine Java security is a fundamental step in understanding and improving Java security and producing secure Java code. Consequently, this session demonstrates and examines a public exploit. It dissects the code of the exploit and illustrates how the exploit managed to attack an unpatched Java Virtual Machine, focusing on the techniques the exploit used, with references to relevant guidelines from the CERT Oracle Secure Coding Standard for Java. The session concludes with an explanation of how Java was patched to defeat the exploit. CON1713 Leveraging Open Source for Secure Java Website Construction Presenter:  Jim Manico, Secure Coding Instructor, Manicode Security (JavaOne Rock Star) Abstract:  The need to master the skills required to build secure Java web and webservice applications gets stronger every day. There is help for you in the world of opens source! Do not build your own web application security controls from scratch! This presentation describes the use of several Oracle, OWASP, Apache and Google open source Java projects that are essential tools for constructing a secure web application. In addition to community speakers, we will have Oracle experts from the Java security team to discuss new security features and improvements like the recent release of Java SE 8.  See you at JavaOne!

JavaOne 2014 is Oracle's flagship software developers conference event for Java.  Security has been a focus at the conference for many years but last year Oracle brought security to the forefront by...

Java 8's new Type Annotations

Java 8 introduces two important changes to Annotations designed to help developers produce better code and improve the accuracy of automated code analysis to verify that quality. Quick Annotations Webinar There is a great video explaining the new improvements in the Java 8 Launch Webinars called “Enhanced Metadata - Annotations and Access to Parameter Names” by Alex Buckley and Michael Ernst. Annotation Improvements Type Annotations allow developers to write annotations in more places than before. The compiler can then verify these annotations, for example identifying uses of null values, accidental value modifications, and cases where data crosses a trust boundary without proper validation. By moving some annotatable information from the Javadoc (understood only by people) and into the code (understood by both people and analyzers), it is easier to understand intent and verify the absence of certain errors. Repeating Annotations make it easier for authors of these annotations because there is less need for wrapper annotations. The Checker Framework provides a few Type Annotations that could benefit both library and application developers, such as: @NonNull – The compiler can determine cases where a code path might receive a null value, without ever having to debug a NullPointerException. @ReadOnly – The compiler will flag any attempt to change the object.  This is similar to Collections.unmodifiableList, but more general and verified at compile time. @Regex – Provides compile-time verification that a String intended to be used as a regular expression is a properly formatted regular expression. @Tainted and @Untainted – Identity types of data that should not be used together, such as remote user input being used in system commands, or sensitive information in log streams. @m – Units of measure ensures that numbers used for measuring objects are used and compared correctly, or have undergone the proper unit conversion. Putting Type Annotations on your code Java SE 8 allows type annotations anywhere that a type is used. Previously, annotations were only allowed on definitions. Some examples of this are: Annotation Example Meaning @NonNull List<String> A non-null list of Strings. List<@NonNull String> A list of non-null Strings. @Regex String validation = "(Java|JDK) [7,8]" Check at compile time that this String is a valid regular expression. private String getInput(String parameterName){ final String retval = @Tainted request.getParameter(parameterName);  return retval;} The object assigned to retval is tainted and not for use in sensitive operations. private void runCommand(@Untainted String… commands){ ProcessBuilder processBuilder = new ProcessBuilder(command);  Process process = processBuilder.start();} Each command must be untainted. For example, the previously tainted String must be validated before being passed in here. For reading annotations, the way to look at them is that they annotate the next item after that isn’t also an annotation. Automating issue detection When working on software, it helps to uncover potential problems early. A problem caught early is easier to fix than one caught later, and a potential problem caught right away is easier still. Some annotations allow problems to be caught immediately. The @Override annotation allows the compiler (or a static analysis tool) to immediately determine if a developer wrote the wrong method signature. Other annotations, like @NonNull and @Readonly can be used by analyzers like the Checker Framework, FindBugs, Eclipse, NetBeans, IntelliJ, or a commercial analyzer. Those analyzers can then be run at compile time, through IDE background compilation, Ant/Maven, or continuous integration. Type Annotations tell those analyzers what to look for. Without the Type Annotations in place, these analyzers would still be able to locate null-usage and write-modifications but would not know that they are wrong. The result would then be false negatives (no issue reported) or false positives (incorrect issues reported). Teamwork Type Annotations can greatly benefit teams that are geographically distributed or contain many members. By placing Type Annotations inside the code and running automated checks before commits or during integration builds, team members can identify situations where one change inadvertently affects another. Optional Type Annotations are not a substitute for runtime validation Before Type Annotations, the primary location for describing things like nullability or ranges was in the javadoc. With Type annotations, this communication comes into the bytecode in a way for compile-time verification. Your code should still perform runtime validation. Annotation validation versus Business Validation Type Annotations are best used with common forms of validation that relate to computer science. There are certain types of business validation that are not applicable. Well-suited for Type Annotations Likely not well-suited for Type Annotations Null value checks. Numeric range checks. Basic type checks, such as regular expressions. Assignments and updates (e.g. read-only) Dataflow validation detection (e.g. have the incoming function arguments gone through the right validation functions) This function cannot be executed outside certain hours or on government holidays. Access to a feature requires a certain account-type. Appendix Annotations in core Java There is no set of default type annotations available out of the box in the Java SE 8 platform. All previous examples in this post used the Checker Framework. The Type Annotations in Java SE 8 focused on the ability to put annotations in the right areas to describe a program. A separate, currently inactive JSR-305 (not part of Java 8) exists for identifying what those annotations should be. The Checker Framework currently uses Java Annotation Index Files to gain comparable support for the core Java runtime and targeted libraries, or previous Java versions like Java SE 7 or 6. Removal of APT JDK 8 also removes a legacy annotation processing tool, named apt. Few users should be affected by this change. This was done as part of JEP 117 because everything required for annotation processing appears in either javax.annotation.processing or javax.lang.model.

Java 8 introduces two important changes to Annotations designed to help developers produce better code and improve the accuracy of automated code analysis to verify that quality. Quick Annotations...

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. 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: NetBeans 8 – Download or view the release notes. Eclipse 4.4 and 4.3.2 – Download (4.4, 4.3.2) or see the mailing list or Blog. IntelliJ IDEA 13.1 – Download or see the Blog announcement. 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.

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

Managing multiple Java versions

The Java Platform provides various options for System Administrators to manage updates on client systems and maintain compatibility with specific applications This post is intended to guide System Administrators whose clients make use of Rich Internet Applications (Applet & Web Start). Most of this does not apply to System Administrators of server-side applications or locally installed applications using the JRE. The primary strategies for controlling RIA compatibility are: Identify known RIAs. Install Java versions through patch-in-place or static installation mode. Deploy the latest version of Java. Delegate certain RIAs to use specific Java versions. Quick Example: A company has a back-office application for managing contractor timesheets. The application is known to require Java 6. The System Administrator should install the latest Java 7. After installation, the system administrator should statically-install the desired Java 6. The System Administrator should then create a Deployment Rule Set to indicate that a specific RIA requires Java 6. Identify known RIAs In order to whitelist RIAs and delegate certain RIAs to specific Java versions, the first step is to identify where those applications are. The two primary ways of doing this: Location, the https:// or http:// or other protocol URL where the RIA is hosted and accessed by users. You will be able to wildcard these later. This is easiest when you control or host the destination, such as inside a company. Code signing hash, an identifier of a vendor based on their public signing certificate. This can be easier when you have a number of RIAs from a particular vendor. The way of identifying RIAs will vary between organizations. One important consideration is to provide a way that users can contact you with adjustments, for example reporting an RIA that you may have missed. Install Java versions through patch-in-place or static installation mode The JRE installation mechanism provides two types of installation: Patch-in-Place and Static Installation. The default mechanism is Patch-in-Place because it leaves a smaller footprint. It also intentionally does not leave older versions behind. Static Installation intentionally leaves behind the older version so that it can be used to execute specific RIAs. Patch-In-Place Static Installation Default: Yes No Installation area: C:\Program Files\Java\jre7Newer versions update this directory. C:\Program Files\Java\jre1.7.0_##Newer versions get their own directory. Leaves older versions: No Yes RIA Deployment Flow defaults to: The only version installed. The highest version installed. Used for: Most cases Large environments where known applications require a specific older version of Java. System Administrators can specify their preference when automating installation of the JRE. In general, Patch-In-Place is the best default and you should use static installations only on systems known to require a specific version. Deploy the latest version of Java Users should always run the latest secure baseline. The latest version of Java always provides the best security defense and enterprise management features. For example, users needing to execute an RIA with Java 6 (end of public updates was in February 2013) should use the latest Java 7 version and let it delegate to Java 6 for the specific RIA. Java installations contain two features to stay up to date: a security baseline and an expiration date. The security baseline represents the latest Critical Patch Update, whose schedule is published a year in advance. A separate "expiration date" is built-in for clients that cannot dynamically check this security baseline. The "expiration date" set at about a month after the scheduled critical patch and is documented at Java.com for the latest version as well as the Oracle Technology Network release notes for specific versions. Once a JRE detects that it is below the security baseline, it changes its behavior as described in the RIA Deployment Flow Guide. The Deployment Flow process (including expiration date) can be controlled by delegating certain RIAs to use specific Java versions. Delegate certain RIAs to use specific Java versions The majority RIAs are compatible with the latest Java release within major versions. For example, an RIA that runs with JDK 1.7.0_01 is expected to be binary compatible with higher updates like JDK 1.7.0_51. For specific applications where compatibility issues have been verified, System Administrators can use Deployment Rule Sets as a way of associating a specific RIA with a statically-installed Java version. When specifying a version for your DRS, it is easiest to go in order of: SECURE (no version), then SECURE-1.X (major version only), and only use specific versions like 1.7.0_51 for a verified compatibility issue. Because rules are specified explicitly by a system administrator, their results are applied before other checks that would affect program execution. If you create any rules that DENY an RIA from running, it is a good idea to provide a way for users to contact you. Deployment Rule Sets must be cryptographically signed. Commercial code-signing certificates are recommended but if you prefer to self-sign your Deployment Rule Set, you must distribute your public key to clients before they can recognize your signature. The Deployment Rule Set files are installed to an area outside the Java installation directory and will remain active as clients update their Java installations. For additional information, please see the complete Deployment Rule Set documentation. Deployment Rule Set Version request When specifying the version in a Deployment Rule Set, it is best to choose a version equal to or higher than the one requested by the launching JNLP file. If you specify a Java version below what the application says it needs then it is unlikely to run correctly.  Inside the JNLP file, there is a section that will look like <j2se version="1.X+" /> If the JNLP requests a version and you specify something below, then the application will be blocked. If the JNLP requests a version and you specify something at or above, then it will run with what you have specified. Specifying a version in your Deployment Rule Set that looks like SECURE or SECURE-1.X is often the simplest choice.

The Java Platform provides various options for System Administrators to manage updates on client systems and maintain compatibility with specific applications This post is intended to guide System...

JDK 8 will use TLS 1.2 as default

Transport Level Security (TLS) is designed to encrypt conversations between two parties and ensure that others can neither read nor modify the conversation. When combined with Certificate Authorities, a proper level of trust is established: we know who is on the other end of the conversation and that conversation is protected from eavesdropping/modification. Support for TLS 1.2 first appeared in JDK 7 (2011). For compatibility reasons, it is enabled by default on server sockets but disabled on clients. Since that time, the industry has made considerable improvements to address interoperability and backwards compatibility. We are setting JDK 8 to use TLS 1.2 as the default for two reasons: TLS is backwards-compatible. After upgrading the default to 1.2, systems using 1.1 and 1.0 will continue to function*. * Unless configured to use an algorithm that was removed for security reasons. Few systems are affected by this. For a complete description of TLS 1.2, please see RFC 5246. A quick summary of TLS/SSL differences is available from yaSSL. It strengthens the protection of internet communications against eavesdropping. For those testing JDK 8 early access, this first occurred in build 122. TLS is transparent to most users and developers. For those that would like more details, we will cover: Threats and the role of encryption Compatibility with the JDK and other systems Understanding your TLS implementation Other considerations for TLS Threats and the role of encryption With a new well-motivated IETF working group for encryption as well as wide industry support for TLS 1.2, the time is right to update system defaults. Qualys SSL Labs has done great research in depicting a threat model for TLS. Their best practices in dealing with the TLS threat model (specifically "2.2 use secure protocols") support this move. Compatibility with the JDK and other systemsTLS 1.2 is designed to be backwards-compatible as described in the RFC Appendix E (above). If a 1.2 client connects to a server running a lower version, the client will adjust. If a lower client connects to a server running 1.2, the server will adjust. Because of backwards-compatibility, clients supporting TLS 1.2 will receive improved communications and older clients will continue to function. We added support for TLS 1.2 in JDK 7 (July 2011) although it was not the default. JDK 8 (March 2014) will use TLS 1.2 as the default. OpenSSL added support for TLS 1.2 in version 1.0.1 (March 2012). Most Linux distributions and scripting languages use OpenSSL. Microsoft supported TLS 1.2 in Windows 7. Internet Explorer and .NET follow accordingly. TLS 1.2 was first enabled by default in Internet Explorer 11 (October 2013). Firefox turned TLS 1.2 on by default in version 27 (February 2014). Chrome supported TLS 1.2 in version 29 (August 2013). Etc. Adoption statistics from the Trustworthy Internet's SSL Pulse show a sufficient number of internet-facing systems using TLS 1.2 and compatible ciphers. Understanding your TLS implementation Developers or System Administrators can test servers and clients through the Qualys SSL Labs (server or client) or a different How’s My SSL website. System Administrators can view their system’s TLS implementation to monitor clients or disable specific TLS versions. For example some system administrators in highly sensitive businesses may want to disable older TLS versions from ever being used. View your client’s version through a GUI Open the Java Control Panel Navigate to the Advanced tab. At the bottom, there is an “Advanced Security Settings.” Check or uncheck the "Use TLS X.Y" box. On a server or without a GUI To set this for everything: Open the deployment.properties file, either user-level or system-level. Set the appropriate propertydeployment.security.TLSvX.Y=false To set for a specific application or script: Use the startup flag -Ddeployment.security.TLSvX.Y=false Other Considerations for TLS The InfoQ article, Keeping Your Secrets, covers additional information for developers looking to understand more about transport security and encryption. Outside the role of TLS protocol version, that article covers good techniques to safeguard information: For System Administrators (or some Developers): Perfect Forward Secrecy can be used in Java TLS connections. Using Perfect Forward Secrecy protects past conversations: in the event that if keys are lost in the future, someone cannot decrypt past conversations. As is common with TLS implementations, Perfect Forward Secrecy is not enabled by default. Those that do want to use it can update their https.cipherSuites property. Common values for this property are: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA Anything on the Algorithm Standard Name list that start with TLS (Transport Level Security) followed by a type of DHE (Diffie-Hellman Exchange).

Transport Level Security (TLS) is designed to encrypt conversations between two parties and ensure that others can neither read nor modify the conversation. When combined with Certificate Authorities,...

Closing the closed APIs

Earlier this year, Wired published an article stating that, “Oracle has actually opened up Java even more — getting rid of some of the closed-door machinations that used to be part of the Java standards-making process.” This openness comes through OpenJDK and the Java Community Process, where different companies and developers all work together to guide the future of the Java Platform. Part of opening Java involves dealing with the evolution of internal APIs in the JDK outside the actual Java Language specification and APIs. While developers should not be using internal APIs like sun.* packages, over the course of Java’s 18 year history, various applications have at times used these APIs for different reasons. Use of these implementation-specific, internal APIs poses challenges when they change and may decrease an application’s portability between different Java implementations . Given the ease of obtaining component libraries, we are looking at ways of identifying and mitigating usage of internal APIs in favor of APIs intended for public use. I will cover several topics in dealing with these internal APIs: Approach in identifying internal APIs Current target: CORBA and Applets/SecurityManager JDeps in Detail Approach in identifying internal APIs The definition of “internal API” is any package or class provided by a Java implementation that is not in the public API set. Gearing up for JDK8, OpenJDK contains a new tool called JDeps that is able to locate use of internal APIs within an application’s JAR files or bytecode. By running this tool, you can see which components use internal APIs and which internal APIs they use. We have run JDeps against a number of applications to figure out popularity of internal APIs and understand any impact. CORBA and Applets/SecurityManager Starting in Java 7 update 51 (January 2014), we will move the internal undocumented com.sun.corba.se APIs into a restricted API list. This will affect applications only if they do all of three things: If your application uses restricted permissions (i.e. sandboxed RIA or runs with a SecurityManager) AND uses CORBA AND uses undocumented internal Sun APIs (com.sun.corba.se.*) to do it. The first attempt at moving internal com.sun.corba.se APIs into a restricted API list came back in June of this year on the OpenJDK mailing list. After more reviews, a better patch was created in October. Beginning with Java 7 update 51, the internal CORBA APIs are entering into a restricted API list. This means that if you have an RIA using this internal API, your application will need the manifest entry "Permissions: all-permissions" and cannot use the sandbox. If your application specifies fine-grained permissions through the SecurityManager, then you will need the "accessClassInPackage.com.sun.corba.se" permission. To see if your code or components use these internal CORBAP APIs, use JDeps and search the output for "com.sun.corba.se" If the above JDeps output says that you are using the undocumented internal APIs, you have two options: Recommended: Update the code to use javax.rmi.CORBA or org.omg.* APIs instead of the otherwise undocumented internal APIs. Bide time by either using “Permissions: all-permissions” manifest entry in your applet or obtaining the "accessClassInPackage.com.sun.corba.se" permission from your SecurityManager. Please use any time gained to work on Option A, above. JDeps in detail OpenJDK 8 introduces a utility called JDeps that looks through JAR files and identifies which JAR files use internal APIs and then lists those APIs. This answers the questions, “am I using these internal classes” and “if so, which ones.” To use JDeps and check your applications, just download a preview release of JDK8. You do not need to actually test or run your application on JDK8, this just happens to be where the JDeps utility is. You can then run JDeps on an application even if you do not have the source code. To run JDeps against an application, the command looks like: jdk8/bin/jdeps -P -jdkinternals *.jar > your-application.jdeps.txt The output inside your-application.jdeps.txt will look like: your.package (Filename.jar)     -> com.sun.corba.se            JDK internal API (rt.jar)

Earlier this year, Wired published an article stating that, “Oracle has actually opened up Java even more — getting rid of some of the closed-door machinations that used to be part of the...

Upcoming Exception Site List in 7u51

Over the last year, many new security related features have been implemented. Many of those features have been related to browser plugins for applets and web start applications (RIAs). A number of end users and software vendors have asked for more ways to configure their environment and use of applications.  The Exception Site List is a way for end-users to control their own application whitelist and continue using RIAs that could not be timely updated to follow previously announced security requirements. The Exception Site List provides a way to continue using a RIA but is not intended as a way to remove all warnings for the user. End-users will still see important prompts, but those prompts will no longer block. Comparison to Deployment Rule Set The introduction of the Exception Site List creates a second way for whitelisting RIAs and decreases requirements for system administrators.  Exception Site List Deployment Rule Set  Introduced  Java 7 update 51 (January 2014) Java 7 update 40 (September 2013)  Intended for  End-user System Administrator  Formatted as  Plain-text Signed JAR file  If the two conflict with each-other  Loses Wins  For standard policy enforcement, some system administrators may lock down usage of the Exception Site List as they would with any other control panel setting. Getting Early Access to the Exception Site List Developers looking to test their applications in advance of 7u51 and use the Exception Site List can download early access of Java 7 update 60 over at the JDK 7 website. That website is the easiest way for developers to get early access of releases. Adding a site to the Exception Site List End-users can access the Exception Site List from the Java control panel. Use your browser to access the RIA that you normally use. Copy the URL from the address bar.Only choose directory paths ending in a / and not a filename. Right: https://www.example.com/someApplication/ Wrong: https://www.example.com/someApplication/filename.html Open the Java control panel. Windows/Mac - Open your system control panel or System Preferences and choose Java. Linux/Solaris - Run the jcontrol command. Choose the Security tab. Click the "Manage Site List" button near the bottom. A new window will open. Click the Add button. Right: https://www.example.com/someApplication/ Wrong: https://www.example.com/someApplication/filename.html Click OK. The window will close. You may see an additional prompt if you use an unencrypted protocol such as http or file. Choosing encrypted protocols defends against potential man-in-the-middle attacks. Back on the control panel, click OK to close it. Reload the web page on your browser to launch the RIA. Files behind the Exception Site List Update Jan 22: The Exception Site List is intended for end-users to create their own whitelist. If you are a System Administrator managing this across many machines, you will find the Deployment Rule Set much easier. Group Policy efforts are better used behind distributing a Deployment Rule Set. You can self-sign a DRS.The Exception Site List is aimed towards end-users controlling their own Exception Site List. The file controlling the Exception Site List is stored in the user’s deployment location as described in the deployment configuration. On my Windows 7 laptop, this location is C:\Users\ecostlow\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites The format is one site per line. Sample customer support note As changes are introduced, technical support representatives are usually asked for details. We will be creating a technical support note that can be downloaded and tweaked to help communicate this change to your customers. It is essentially a trimmed down version of this blog post with a stronger How-To message. Update on Jan 14 2014: Here are the end-user instructions for using the Exception Site List. Otherwise if you need something more customizable, here is a sample Exception Site List support note. This is a docx file but it may appear as a zip.

Over the last year, many new security related features have been implemented. Many of those features have been related to browser plugins for applets and web start applications (RIAs). A number of...

Self-signed certificates for a known community

Recently announced changes scheduled for Java 7 update 51 (January 2014) have established that the default security slider will require code signatures and the Permissions Manifest attribute. Code signatures are a common practice recommended in the industry because they help determine that the code your computer will run is the same code that the publisher created. This post is written to help users that need to use self-signed certificates without involving a public Certificate Authority. The role of self-signed certificates within a known community You may still use self-signed certificates within a known community. The difference between self-signed and purchased-from-CA is that your users must import your self-signed certificate to indicate that it is valid, whereas Certificate Authorities are already trusted by default. This works for known communities where people will trust that my certificate is mine, but does not scale widely where I cannot actually contact or know the systems that will need to trust my certificate. Public Certificate Authorities are widely trusted already because they abide by many different requirements and frequent checks. An example would be students in a university class sharing their public certificates on a mailing list or web page, employees publishing on the intranet, or a system administrator rolling certificates out to end-users. Managed machines help this because you can automate the rollout, but they are not required -- the major point simply that people will trust and import your certificate. How to distribute self-signed certificates for a known community There are several steps required to distribute a self-signed certificate to users so that they will properly trust it. These steps are: Creating a public/private key pair for signing. Exporting your public certificate for others Importing your certificate onto machines that should trust you Verify work on a different machine Creating a public/private key pair for signing Having a public/private key pair will give you the ability both to sign items yourself and issue a Certificate Signing Request (CSR) to a certificate authority. Create your public/private key pair by following the instructions for creating key pairs.Every Certificate Authority that I looked at provided similar instructions, but for the sake of cohesiveness I will include the commands that I used here: Generate the key pair.keytool -genkeypair -alias erikcostlow -keyalg EC -keysize 571 -validity 730 -keystore javakeystore_keepsecret.jks Provide a good password for this file. The alias "erikcostlow" is my name and therefore easy to remember. Substitute your name of something like "mykey." The sigalg of EC (Elliptical Curve) and keysize of 571 will give your key a good strong lifetime. All keys are set to expire. Two years or 730 days is a reasonable compromise between not-long-enough and too-long. Most public Certificate Authorities will sign something for one to five years. You will be placing your keys in javakeystore_keepsecret.jks -- this file will contain private keys and therefore should not be shared. If someone else gets these private keys, they can impersonate your signature. Please be cautious about automated cloud backup systems and private key stores. Answer all the questions. It is important to provide good answers because you will stick with them for the "-validity" days that you specified above.What is your first and last name?  [Unknown]:  First LastWhat is the name of your organizational unit?  [Unknown]:  Line of BusinessWhat is the name of your organization?  [Unknown]:  MyCompanyWhat is the name of your City or Locality?  [Unknown]:  City NameWhat is the name of your State or Province?  [Unknown]:  CAWhat is the two-letter country code for this unit?  [Unknown]:  USIs CN=First Last, OU=Line of Business, O=MyCompany, L=City, ST=CA, C=US correct?  [no]:  yesEnter key password for <erikcostlow>        (RETURN if same as keystore password): Verify your work:keytool -list -keystore javakeystore_keepsecret.jksYou should see your new key pair. Exporting your public certificate for others Public Key Infrastructure relies on two simple concepts: the public key may be made public and the private key must be private. By exporting your public certificate, you are able to share it with others who can then import the certificate to trust you. keytool -exportcert -keystore javakeystore_keepsecret.jks -alias erikcostlow -file erikcostlow.cer To verify this, you can open the .cer file by double-clicking it on most operating systems. It should show the information that you entered during the creation prompts. This is the file that you will share with others. They will use this certificate to prove that artifacts signed by this certificate came from you. If you do not manage machines directly, place the certificate file on an area that people within the known community should trust, such as an intranet page. Import the certificate onto machines that should trust you In order to trust the certificate, people within your known network must import your certificate into their keystores. The first step is to verify that the certificate is actually yours, which can be done through any band: email, phone, in-person, etc. Known networks can usually do this Determine the right keystore: For an individual user looking to trust another, the correct file is within that user’s directory.e.g. USER_HOME\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certsThe default password for trusted.certs is an empty string. For system-wide installations, Java’s Certificate Authorities are in JAVA_HOMEe.g. C:\Program Files\Java\jre8\lib\security\cacertsThe default password for cacerts is "changeit" as described in the keytool documentation. File paths for Mac and Linux are included in the link above. Follow the instructions to import the certificate into the keystore. keytool -importcert -keystore THEKEYSTOREFROMABOVE -alias erikcostlow -file erikcostlow.cer In this case, I am still using my name for the alias because it’s easy for me to remember. You may also use an alias of your company name. Scaling distribution of the import The easiest way to apply your certificate across many machines is to just push the .certs or cacerts file onto them. When doing this, watch out for any changes that people would have made to this file on their machines. Trusted.certs: When publishing into user directories, your file will overwrite any keys that the user has added since last update. CACerts: It is best to re-run the import command with each installation rather than just overwriting the file. If you just keep the same cacerts file between upgrades, you will overwrite any CAs that have been added or removed. By re-importing, you stay up to date with changes. There is a -storepass argument for specifying the password on the command-line. On secure systems, admins typically hide passwords through redirection operators but that's outside the scope of this post. Verify work on a different machine Verification is a way of checking on the client machine to ensure that it properly trusts signed artifacts after you have added your signing certificate. Many people have started using deployment rule sets. You can validate the deployment rule set by: Create and sign the deployment rule set on the computer that holds the private key. Copy the deployment rule set on to the different machine where you have imported the signing certificate. Verify that the Java Control Panel’s security tab shows your deployment rule set. Verifying an individual JAR file or multiple JAR files You can test a certificate chain by using the jarsigner command. jarsigner -verify filename.jar If the output does not say "jar verified" then run the following command to see why: jarsigner -verify -verbose -certs filename.jar Check the output for the term “CertPath not validated.”

Recently announced changes scheduled for Java 7 update 51 (January 2014) have established that the default security slider will require code signatures and the Permissions Manifest attribute. Code...

7u45 Caller-Allowable-Codebase and Trusted-Library

Java 7 update 45 (October 2013) changed the interactions between JavaScript and Java Applets made through LiveConnect. The 7u45 update is a critical patch update that has also raised the security baseline and users are strongly recommended to upgrade. Versions below the security baseline used to apply the Trusted-Library Manifest attribute to call between sandboxed code and higher-privileged code. The Trusted-Library value was a Boolean true or false. Security changes for the current security baseline (7u45) introduced a different Caller-Allowable-Codebase that indicates precisely where these LiveConnect calls can originate. For example, LiveConnect calls should not necessarily originate from 3rd party components of a web page or other DOM-based browser manipulations (pdf). Additional information about these can be located at “JAR File Manifest Attributes for Security.” The workaround for end-user dialogs is described on the 7u45 release notes, which explains removing the Trusted-Library attribute for LiveConnect calls in favor of Caller-Allowable-Codebase. This provides necessary protections (without warnings) for all users at or above the security baseline. Client installations automatically detect updates to the secure baseline and prompt users to upgrade. Warning dialogs above or below Both of these attributes should work together to support the various versions of client installations. We are aware of the issue that modifying the Manifest to use the newer Caller-Allowable-Codebase causes warnings for users below the security baseline and that not doing it displays a warning for users above. Manifest Attribute 7u45 7u40 and below Only Caller-Allowable-Codebase No dialog Displays prompt Only Trusted-Library Displays prompt No dialogBoth Displays prompt (*) No dialog This will be fixed in a future release so that both attributes can co-exist. The current work-around would be to favor using Caller-Allowable-Codebase over the old Trusted-Library call. For users who need to stay below the security baseline System Administrators that schedule software deployments across managed computers may consider applying a Deployment Rule Set as described in Option 1 of “What to do if your applet is blocked or warns of mixed code.” System Administrators may also sign up for email notifications of Critical Patch Updates.

Java 7 update 45 (October 2013) changed the interactions between JavaScript and Java Applets made through LiveConnect. The 7u45 update is a critical patch update that has also raised the security...

Updated Security Baseline (7u45) impacts Java 7u40 and before with High Security settings

The Java Security Baseline has been increased from 7u25 to 7u45.  For versions of Java below 7u45, this means unsigned Java applets or Java applets that depend on Javascript LiveConnect calls will be blocked when using the High Security setting in the Java Control Panel. This issue only affects Applets and Web Start applications. It does not affect other types of Java applications. The Short Answer Users upgrading to Java 7 update 45 will automatically fix this and is strongly recommended. The More Detailed Answer There are two items involved as described on the deployment flowchart: The Security Baseline – a dynamically updated attribute that checks to see which Java version contains the most recent security patches. The Security Slider – the user-controlled setting of when to prompt/run/block applets. The Security Baseline Java clients periodically check in to understand what version contains the most recent security patches. Versions are released in-between that contain bug fixes. For example: 7u25 (July 2013) was the previous secure baseline. 7u40 contained bug fixes. Because this did not contain security patches, users were not required to upgrade and were welcome to remain on 7u25. When 7u45 was released (October, 2013), this critical patch update contained security patches and raised the secure baseline. Users are required to upgrade from earlier versions. For users that are not regularly connected to the internet, there is a built in Expiration Date. Because of the pre-established quarterly critical patch updates, we are able to determine an approximate date of the next version. A critical patch released in July will have its successor released, at latest, in July + 3 months: October. The Security Slider The security slider is located within the Java control panel and determines which Applets & Web Start applications will prompt, which will run, and which will be blocked. One of the questions used to determine prompt/run/block is, “At or Above the Security Baseline.” The Combination JavaScript calls made from LiveConnect do not reside within signed JAR files, so they are considered to be unsigned code. This is correct within networked systems even if the domain uses HTTPS because signed JAR files represent signed "data at rest" whereas TLS (often called SSL) literally stands for "Transport Level Security" and secures the communication channel, not the contents/code within the channel. The resulting flow of users who click "update later" is: Is the browser plug-in registered and allowed to run? Yes. Does a rule exist for this RIA? No rules apply. Does the RIA have a valid signature? Yes and not revoked. Which security prompt is needed? JRE is below the baseline. This is because 7u45 is the baseline and the user, clicked "upgrade later." Under the default High setting, Unsigned code is set to "Don’t Run" so users see: Additional Notes End Users can control their own security slider within the control panel. System Administrators can customize the security slider during automated installations. As a reminder, in the future, Java 7u51 (January 2014) will block unsigned and self-signed Applets & Web Start applications by default.

The Java Security Baseline has been increased from 7u25 to 7u45.  For versions of Java below 7u45, this means unsigned Java applets or Java applets that depend on Javascript LiveConnect calls will be...

What to do if your applet is blocked or warns of “mixed code”?

Recent security changes, including the October 7u45 critical patch update, for RIAs (Applets & Web Start applications) have affected several audiences in different ways. Other types of applications (such as back-end server applications, web applications, middleware, client-installed applications, and others) are unaffected by these changes. Two notable changes are: Java 7 update 45 (October 2013) introduced changes to the LiveConnect model of JavaScript calling Java RIAs whereby additional warnings are raised in certain situations. In the future, Java 7 update 51 (January 2014) will introduce a code-signing requirement for RIAs. Affected RIAs should be patched and updated immediately by their developers. Sometimes this is not feasible, such as cases of an application purchased from a vendor, an RIA is burned into device firmware, or the RIA has been in use for years and nobody knows the maintainer.  In those situations, System Administrators can take steps to adapt to these changes if they prefer not to be notified. Option 1 System Administrators can follow the instructions for creating a Deployment Rule Set and create appropriate rules to whitelist the RIA and javascript domains: First, identify the location of JavaScript where your web pages will be calling in to Java. For example, by whitelisting your own domains and thereby disallowing alternate sources. <rule>    <id location="https://www.example.com/program" />    <action permission="run" version="SECURE" /></rule>This is an important step because web pages are often made of many components, such as analytics, image hosts, and other pieces. Whitelisting your domain prohibits others from calling in to your Java application. If the RIA is hosted at a different location, such as a content delivery network, you can whitelist it separately with the hash of its certificate. <rule>    <id>        <certificate algorithm="SHA-256"            hash="794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6" /><!-- Oracle's public certificate hash. Having this will allow things like the Java.com secure version check applet. -->    </id>    <action permission="run" /></rule> Option 2 System Administrators or Developers can overwrite the application’s signature and add the appropriate Manifest entries. While it does not involve code changes, modifying a JAR file will break the digital signature and requires generating a new one. If you take someone else’s signed document and make changes – your changes invalidate the document they signed, so you need to white-out their signature and apply your own. There is an existing tutorial for updating JAR files and Modifying a Manifest file. The subset of steps needed for updating to the latest requirements are: Identify the appropriate JAR file by looking at the JNLP deployment descriptor file. There is a JAR resource specification inside that looks like: <jar href="JavaDetection.jar" /> Extract the MANIFEST.MF file: jar -xf JavaDetection.jar META-INF/MANIFEST.MF Open META-INF/MANIFEST.MF in a text editor. Modify the entries that you need, following the Security Manifest Properties documentation: Permissions – either sandbox or all-permissions. Sandbox is recommended unless the RIA needs further permissions.e.g. Permissions: sandbox Codebase – the original developer often does not have enough information to supply this optional attribute because they do not know where it will be deployed. Provide your hosting location and domain.e.g. Codebase: https://www.example.com Caller-Allowable-Codebase – If your RIA requires a calling web page to make LiveConnect calls into the RIA, providing this optional attribute will allow those calls without additional user prompts. The original developer may not have this information because they might not know where it will be deployed. For LiveConnect, this must be provided even if it is the same as the Codebase.e.g. Caller-Allowable-Codebase: https://www.example.com https://customers.example.net Place your MANIFEST.MF file back into the JAR file: jar -ufm JavaDetection.jar META-INF\MANIFEST.MF The final step is to sign the JAR file using your own certificate. Optional: If you want to verify that these modifications invalidated the previous signature : jarsigner -verify JavaDetection.jar Apply your own signature to the file:jarsigner -verbose -keystore "c:\Users\ecostlow \javakeystore_keepsecret.jks" -signedjar JavaDetection.jar -tsa http://timestamp.verisign.com your-certificiate-alias After updating the MANIFEST.MF file, you can publish the new JAR files for users to access. 

Recent security changes, including the October 7u45 critical patch update, for RIAs (Applets & Web Start applications) have affected several audiences in different ways. Other types of applications...

LiveConnect changes in 7u45

Java 7 update 45 (October 2013) introduces a new warning to users of LiveConnect applications. LiveConnect is a technology for Rich Internet Applications that allows JavaScript on a web page to make calls into an RIA, allowing the two to work together and load content. RIAs that do not use LiveConnect are unaffected by this change. What changed: Users are prompted to confirm a domain when it makes its first LiveConnect call.How is this different: Previously, LiveConnect calls were allowed by default. For the first LiveConnect call (per-site), the Java plugin will ask the user if they want to allow interactions from [this domain] to interact with the currently running RIA. This allows the user to confirm known sources (such as the hosting site) and block alternate sources, such as on-page advertising networks or browser plugins. Prompts will displayed when that a web page performs a LiveConnect call. Prompts about LiveConnect cannot be made beforehand because the caller does not exist. The LiveConnect warning looks like this: Developers looking to avoid this warning within their applications may use the optional Caller-Allowable-Codebase attribute within their JAR file’s Manifest.  The Caller-Allowable-Codebase attribute provides a list of domains that can make LiveConnect calls in to the application. This is different than the optional Codebase attribute, which describes the domains from which JAR files may be loaded, although both use similar syntax. META-INF/MANIFEST.MF Manifest-Version: 1.0Created-By: 1.7.0_45…Caller-Allowable-Codebase: example.com *.example.net RIA developers looking to understand which messages will appear as a result of the end-user’s security slider may consult the Rich Internet Deployment Process flowchart. This chart depicts the checks that will be performed on a user’s system, from version-update checks through checking the signature and appropriate Manifest Permissions. The checks are split into two categories: Before your RIA and With your RIA. Before your RIA: Is Java registered in the browser? Does a rule exist on the user’s system to whitelist this RIA? (e.g. a Deployment Rule Set) Is the user’s Java version at or above the security baseline? With your RIA: Does the RIA have a valid code signature? Does the RIA meet requirements of the user’s security slider? Are LiveConnect calls from [this domain] allowed?

Java 7 update 45 (October 2013) introduces a new warning to users of LiveConnect applications. LiveConnect is a technology for Rich Internet Applications that allows JavaScript on a web page to make...

Signing code for the long-haul

With recent code-signature requirements for Rich Internet Applications, I have received a few good questions from different types of developers What is the role of code signing? How do I prevent my signature from expiring?  What is the role of code signing? Code signatures allow people who will receive and use your code to determine that you are, in fact, the publisher and that no one else has intentionally or accidentally modified your deliverable. Code signatures protect against these modifications within your supply chain, when moving across a network, or when appearing through 3rd party distribution channels. Code signatures offer a level of repudiation: even though an imposter tries to look like your app, both you and your customers can prove that it isn’t. There are two concepts for this level of trust: Identity, the application providing a claim as to who wrote it. Authentication, the JRE automatically validating this claim against a set of known trust stores. The way that this information is provided and checked is through industry standard Certificates, which tie together information about the signers (their identity) with the ability to mathematically verify it (through a key). For a description on why code signatures are taking a more prominent role within the Java Platform, please see our previous entry, Code Signing – Understanding Who and When. How do I prevent my signature from expiring? Trusted Timestamping, introduced in Java 5 (2004), allows your customers to validate your signature even after the certificate has expired. When you sign a JAR file, the Timestamp Authority uses their clock to act as a notary and cryptographically write the date and time into your file. Without this timestamp, users would only be able to validate your signature based on their current date and time. This could be problematic for long-running or embedded systems because the standard X.509 Certificates contain a NotAfter date that typically ranges from one to four years. You interact with timestamp authorities when signing code with jarsigner’s TSA argument: jarsigner -tsa http://tsa.starfieldtech.com … When your signed file provides a timestamp, Java is able to use that information within the PKIXParameters and determine: Do I trust this timestamp authority to act as a notary? Is the signature date before the certificate’s time of expiration? Based on Certificate Revocation Lists, was this certificate valid on or before the signature date? If the answer to all questions is yes, then the signature is deemed valid even if the certificate has expired. Therefore, signed code on embedded devices will continue to operate beyond the Certificate’s lifetime.Certificate revocation may affect the ability to trust a timestamped artifact even if the timestamp occurred before the revocation. Some Certificate Authorities do not currently allow back-dating of revocations, which call to question which happened first: the revocation or the timestamp. Java systems may ignore the timestamp when they identify that the code-signing certificate has been revoked. Several trusted timestamp authorities are listed in the previous post, “Code signing: Understanding who and when.” A note about Certificate Authorities and revocation lists Part of the acceptance criteria for being included in Java’s root certificate authority program is allowing back-dating of certificate revocation in the event that a private key is lost or stolen and continuing to publish revocation information even after a Certificate’s public expiration.

With recent code-signature requirements for Rich Internet Applications, I have received a few good questions from different types of developers What is the role of code signing? How do I prevent my...

Signing applet code does not grant all-permissions (since 7u25)

There are two levels of authorization for Java applets and web start applications: sandboxed, where the application is limited in terms of actions it can take on users' computers, and all-permissions, where applications operate as though they were native, with full access to the system and its resources. In the old days of Java 6 and early days of Java 7, the rule was that only applications that required all-permissions needed to be signed. Since Java 7 update 21 (April 2013), you are able to (and encouraged) to sign all types of applications: sandbox and all-permissions. The intent of this is that code signatures from trusted certificate authorities provide a means of authentication for end users, so that they can know who actually wrote the application. Java 7 update 25 also introduced two new attributes within a jar's Manifest file aimed at Preventing RIAs from Being Repurposed. By having these attributes within the signed jar, attackers cannot make any adjustments to the permissions level without invalidating the signature. An example of the META-INF/MANIFEST.MF file with these attributes would be: Manifest-Version: 1.0Created-By: 1.7.0_25Permissions: sandboxCodebase: https://example.comName: Clazz.classSHA1-Digest: HASHSTUFF= Beginning January 2014, code signatures and use of the Permissions attribute will be mandatory for all Applets and Web Start applications. The Codebase attribute will remain optional, as ISVs may not know this information beforehand. These changes create a separation between three areas of trust: Identification: provided by the application, stating its publisher. Authentication: automatic by the JRE, the code signatures within JARs is verified against public certificate authorities and dynamically updated revocation lists. Authorization: once authentication has occurred, allow the application to ask the user for a specific set of permissions. For additional information about the role of code signatures, sandboxed or not, see our previous blog entry, Code signing: Understanding who and when.

There are two levels of authorization for Java applets and web start applications: sandboxed, where the application is limited in terms of actions it can take on users' computers, and all-permissions,...

New security requirements for RIAs in 7u51 (January 2014)

Java 7 update 51 (January, 2014) intends to include two security changes designed to enhance authentication and authorization for Rich Internet Applications (Applets and Web Start). The default security slider is being updated in a way that will block RIAs that do not adhere to these requirements.  Note: this only applies to RIAs, and not to Java on server or desktop applications run outside of a browser. Summary: You are required to sign all RIAs (Applets and Web Start applications). You are required to set the "Permissions" attribute within the Manifest. Your application will be affected if it uses Java started through a web browser. Your application will not be affected if it runs anywhere outside of a web browser. Complete information can be found within the Java 7 update 51 release notes (here once 7u51 is released in January 2014). Developers:  As of 7u51, (January 14, 2014), your RIAs must be updated. The updates required are on the packaging and distribution; no API code changes should be required. The impetus for these changes relates to potential re-purposing of sandboxed applications, whereby placing permissions within a signed JAR prevents modification of your specified permission level.RIAs must contain two things: Code signatures from a trusted authority. All code for Applets and Web Start applications must be signed, regardless of its Permissions attributes. Manifest Attributes Permissions – Introduced in 7u25, and required as of 7u51. Indicates if the RIA should run within the sandbox or require full-permissions. Codebase – Introduced in 7u25 and optional/encouraged as of 7u51. Points to the known location of the hosted code (e.g. intranet.example.com). Sample META-INF/MANIFEST.MF file: Manifest-Version: 1.0Created-By: 1.7.0_51Permissions: sandboxCodebase: www.java.com java.com This manifest file is created when the JAR is packaged, either through the default jar command, your build tool, or your IDE. Sample JNLP for launching a web start application: <?xml version="1.0" encoding="UTF-8"?><jnlp href="JavaDetection_applet.jnlp">    <information>        <title>Java Detection</title>        <vendor>Oracle Inc.</vendor>    </information>    <resources>        <jar href="JavaDetection.jar" />    </resources>    <applet-desc          name="Java Detection Applet"         main-class="JavaDetection"         width="1"         height="1">     </applet-desc>     <update check="background"/></jnlp> Some developers may notice that the <security /> element is missing from the above JNLP. By providing it within the cryptographically signed JAR file, it is no longer necessary within the JNLP for Java 7 update 51 (January 2014). See the Development and Deployment Of Rich Internet Applications for full details of JNLPs and the deployment toolkit. For instructions on signing code, see the tutorial Lesson: Signing Code and Granting It Permissions. Desktop Administrators If you are a desktop administrator managing Java installations across a series of computers, consider using Deployment Rule Sets to whitelist your internal applications. Deployment Rule Sets allow you to certify that an application is known to be trusted and safe, even if you cannot update the application to adhere to these requirements.

Java 7 update 51 (January, 2014) intends to include two security changes designed to enhance authentication and authorization for Rich Internet Applications (Applets and Web Start). The default...

Code signing: Understanding who and when

Code signatures have become more commonplace for applications in recent years and especially so in Java 7 update 21 (April 16, 2013). The security notifications for Java help provide your users with an understanding of who wrote the application so that they can decide whether to run it or not. Through the default settings of the Java security slider, end-users are blocked from running unsigned or self-signed applets and prompted for running signed applets. These cryptographic signatures are designed to provide a means of authentication, proving to users that they are indeed running the same application that you wrote and that it has not been modified in any way. Within information security threat modeling terms, this is a means of repudiation. Developers must sign any browser applet or Web Start application that they produce. Signatures on other application types (such as back-end server applications) are optional. System Administrators may be impacted and have a choice for what to do: For managed users, the system administrator can add a Deployment Rule Set to client systems and indicate which applets may run. For unmanaged or bring-your-own-device users, the system administrator may sign jars with their own certificate. Several steps are involved to sign code: Determine who in your organization is responsible for code signing Purchase a signing certificate from a public Certificate Authority. System Administrators: sign a jar using normal commands Developers: integrate code signing into your build chain Determine who in your organization is responsible for code signing In corporate enterprises, there is often a technology group responsible for these signatures. This group is usually separate from most system administrators in order to keep the private key a secret. The goal is to decrease the number of people with access to the private key. If you are in a corporate enterprise, please look internally for a code signing group and ask them for their signing process instead. Purchase a signing certificate If you or your group is identified as responsible for code signing, then the next step is to obtain a code signing certificate. If a different group provides signatures (as in many large organizations), follow their process instead. All users (system administrators and developers) that intend to sign code must purchase a signing certificate from a known authority. Certificate authorities help manage trust across millions of systems and prevent identity spoofing, or cases where someone else generates their own certificate pretending to be you. Signing certificates are available from companies like GoDaddy, Symantec, or others. Each certificate authority provides instructions for generating a certificate signing request with the keytool command. Code signing certificates are different from domain certificates normally used for HTTPS websites. Signing certificates must be purchased from a Certificate Authority -- Oracle is not a Certificate Authority. System Administrators: sign a jar using normal commands After receiving the signing certificate, system administrators can sign files using the following jarsigner command: jarsigner -verbose -keystore "c:\Users\ecostlow\javakeystore_keepsecret.jks" -tsa http://timestamp.verisign.com -signedjar FILENAME.jar FILENAME.jar your-certificate-nameEnter Passphrase for keystore: updating: META-INF/MANIFEST.MF   adding: META-INF/COSTLOW.SF   adding: META-INF/COSTLOW.RSA  signing: ruleset.xml Developers: integrate code signing into your build chain In an ideal environment, members of the development team would not have access to the private key and its password. The fewer people that have this private key, the better. For build automation, you can create stubs that allow other members of the team to substitute the real private key and password, without exposing this sensitive information. Please note that Oracle only maintains the default jarsigner command (described above for System Administrators) and does not manage or control build tools. Ant The ant build system provides a SignJar task to mimic the jarsigner command. When using this task, just be sure to call the ant sign target. <property file="devAndBuildHaveDifferentValues.properties" /><target name="sign"><signjaralias="${sign.alias}" keystore="${sign.keystore}"storepass="${sign.storepass}" tsaurl="http://timestamp.verisign.com"> <path><fileset dir="dist" includes="**/*.jar" /> </path></signjar></target> Then, both the development team and build team would have different entries for devAndBuildHaveDifferentValues.properties  Dev would have this for testing Build (continuous integration) would have this, keeping it secret sign.alias=mykeysign.keystore=testcerts.jkssign.storepass=changeit sign.alias=mykeysign.keystore=/build/keepSecretFromEveryone.jkssign.storepass=N0bodyE1se5houldKnowThis By taking these actions, developers can automate their build to sign jar files without exposing the private key to the entire development team. Maven Maven provides a maven-jarsigner plugin to mimic the jarsigner command. <build><plugins>...<plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-jarsigner-plugin</artifactId><version>1.2</version><executions><execution><id>sign</id><goals><goal>sign</goal></goals></execution></executions><configuration><keystore>${sign.keystore}</keystore><alias>${sign.alias}</alias><storepass>${sign.storepass}</storepass></configuration></plugin>...</plugins></build> Maven uses the idea of Profiles to externalize properties. Dev would have this for testing Build (continuous integration) would have this, keeping it secret sign.alias=mykeysign.keystore=testcerts.jkssign.storepass=changeit sign.alias=mykeysign.keystore=c:/build/keepSecretFromEveryone.jkssign.storepass=N0bodyE1se5houldKnowThis By taking these actions, developers can automate their build to sign jar files without exposing the private key to the entire development team. Other build system If your development team is using an alternate build system, please review its documentation for the appropriate call. Most build systems should have this, but the default jarsigner command will always work if you need. Leveraging internal code signing authorities Many large organizations have an internal code signing group. The benefit of these groups is that they help keep the private keys secret in a way that neither developers nor build integrators have access. Separation also allows this group to dedicate more time towards best practices, like keeping keys on tamper-proof hardware/smart-cards. If your organization has this group, the usual practice is to automate sending code artifacts to this team’s service and retrieving the resulting signed artifacts. Reference documentation for using separate hardware key components is available in the PKCS#11 Reference Guide. A word on timestamps The optional timestamping provides a notary-like capability of identifying when the signature was applied. If a certificate passes its natural expiration date without revocation, trust is extended for the length of the timestamp.Timestamps are not considered for certificates that have been revoked, as the actual date of compromise could have been before the timestamp occurred. Although not required, it is a good practice to timestamp anything that you sign. Popular timestamping authority URLs include: http://timestamp.verisign.com http://tsa.starfieldtech.com https://timestamp.geotrust.com/tsa

Code signatures have become more commonplace for applications in recent years and especially so in Java 7 update 21 (April 16, 2013). The security notifications for Java help provide your users with...

Introducing Deployment Rule Sets

As the Java security model has hardened for browser-based applets, desktop administrators have asked for ways to manage version compatibility and security updates for their end-users. A new feature is being introduced in Java 7 update 40 called “Deployment Rule Set,” designed to address the issue of security and compatibility in browser applets without affecting normal back-end Java programs like Eclipse, Freemind, or Tomcat. Specifically this deployment rule set addresses two major points: The desktop administrator’s ability to control Java version compatibility, and default choices on the end-user’s desktop. For example your users may use most recent security updates for most browser applets but still use an old Java 1.6 for that one legacy application that is no longer maintained. The end-user’s awareness of who created the application and their default interaction (ask, run, or block). By seeing the actual company or signer, the user is protected from running code by someone that they do not know. For example, I would trust “My University” or “Erik Costlow” but not “Unknown publisher” or someone else claiming to be me. This feature is geared towards two types of users: Desktop Administrators, who manage a number of users and need to control version compatibility and default dialogs to specific company applets. Desktop Administrators should learn how to control Java across these user systems. For example, “automatically run browser applets signed by our company” or “run all our browser applets with the latest secure version, except for this one internal system that we know needs Java 1.6.” Developers, who create Java applets and Web Start applications should be aware of the role that deployment rule sets play on their end-user’s desktop. How to create a deployment rule set By creating a deployment rule set, desktop administrators can control execution and dialog prompts for desktop users and allow them to run known Java applets, either created by the company or used in critical systems. Creating a deployment rule set involves a set of steps done once that can then scale out to any number of users and continue working in their future Java updates: Identify critical applets and web start applications, either by location (e.g. http://payroll.example.com), name (e.g. Solitaire), or code-sign hash. Create a file called ruleset.xml Package your ruleset.xml into a signed DeploymentRuleSet.jar Deploy your DeploymentRuleSet.jar to user desktops Verify usage of your rule set on a client desktop Identify critical Applets and Web Start applications Find locations of known applets that your users interact with as part of their normal work. There are many means for gathering this information, from asking/monitoring users to speaking with your director of engineering if their team is creating applets. Ultimately, they can be listed through three means: Location This is a pattern matcher for URLs. You can identify applets through a simple combination of wildcards and automatic directories. The benefit of location is that it is easy to collect the right information. Examples: https://payroll.example.com *.example.com/panelThis will implicitly cover anything located beneath the panel folder Certificate Hash If you are following the security practice of signing your code so that users know your applets, you can provide a SHA-256 hash of your public certificate. The benefit of a certificate hash is that it recognizes a publisher, irrespective of location. The downside is that you must find the appropriate certificate. Examples of SHA-256 hashes look like 63 characters of hexadecimal: 794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6 To get these hashes, download a signed jar file or obtain one from the developers and run: keytool -printcert -jarfile MyProgram.jar > cert.txt Open cert.txt and find the earliest relevant signature. For example, I chose ours:Owner: CN="Oracle America, Inc.", OU=Software Engineering, OU=Digital ID Class 3 - Java Object Signing, O="Oracle America, Inc.", L=Redwood Shores, ST=California, C=USand then copied the hash line appearing a little later:SHA256: 79:4F:53:C7:46:E2:AA:77:D8:4B:84:3B:E9:42:CA:B4:30:9F:25:8F:D9:46:D6:2A:6C:4C:CE:AB:8E:1D:B2:C6 Remove the : separator characters. Title Look at the JNLP launcher to identify the title of the application. Title must occur only with another attribute, like location or certificate. Title may not be used alone since it exists outside signed jars and deployed locations. For the time being, just create a list of these. Create a file called ruleset.xml Once you have a list of critical applets, the next step is to create a single file called rulset.xml that will look like this: <!-- Example Deployment Rule Set that allow a desktop administrator to control end-user's execution of browser applets. See http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html --><ruleset version="1.0+"><rule><id location="http://payroll.example.org" /><action permission="run" /></rule><rule><id location="http://knownvendor.example.com/program" /><action permission="run" version="SECURE-1.6" /><!-- For example if an application is known not to work on Java 1.7 --></rule><rule><id location="http://localhost" /><action permission="run" /></rule><rule><id><certificate algorithm="SHA-256"hash="794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6" /><!-- Oracle's public certificate hash. Having this will allow things like the Java.com secure version check applet. --></id><action permission="run" /></rule><rule><id location="http://*.example.com"><certificate algorithm="SHA-256"hash="..." /></id><action permission="default" version="SECURE" /></rule><rule><id /><!-- Because this is both blank and shown last, it will be the default policy. --><action permission="block"><message>Blocked by corporate. Contact myemail@mycompany.com if you need to run this app.</message><message locale="fr">Bloqué par l'entreprise. Contacter myemail@mycompany.com si vous avez besoin d'exécuter cette application.</message></action></rule></ruleset> Complete details for creating this file can be found in the Deployment Rule Set documentation, but the gist is to specify the default action of which should run (with no interaction from the user), which should perform the default behavior (prompting the user), and which should be automatically blocked (explaining why). Package your ruleset.xml into DeploymentRuleSet.jar Packaging your ruleset allows the desktop administrator to apply cryptographic signatures and prevent users from overriding your policy. This requires usage of a trusted signing certificate. The easiest route to get a signature is to buy one from a certificate authority like Symantec/Verisign, Comodo, GoDaddy, or any other; but in this case I have instructed my JVM to use a custom costlow-ca certificate authority (which only works on my machine). The default certificate authority list contains about 80 authorities from which you may purchase a signing certificate. C:\Users\ecostlow\DeploymentRuleSet>jar -cvf DeploymentRuleSet.jar ruleset.xmladded manifestadding: ruleset.xml(in = 1492) (out= 612)(deflated 58%)C:\Users\ecostlow\DeploymentRuleSet>jarsigner -verbose -keystore "c:\Users\ecostlow \javakeystore_keepsecret.jks" -signedjar DeploymentRuleSet.jar DeploymentRuleSet.jar costlow-caEnter Passphrase for keystore: updating: META-INF/MANIFEST.MF   adding: META-INF/COSTLOW-CA.SF   adding: META-INF/COSTLOW-CA.RSA  signing: ruleset.xml Deploy your DeploymentRuleSet.jar to user desktops After creating the signed jar, desktop administrators should copy the DeploymentRuleSet.jar to the documented area for their platform so that rules are enforced for all users, across Java updates. Verify usage of your rule set on a client desktop For end-users, simply have them visit a website like http://java.com/en/download/installed.jsp and verify their Java version (this site uses an applet, so see if it runs). For desktop administrators, test your Deployment Rule Set by opening the Java Control Panel and navigating to the Security tab: Clicking the “View the active Deployment Rule Set” should show you your same ruleset.xml file. End Result After performing the steps above, desktop administrators can now better control usage of the Java dialogs and prompts for managed users that will function across Java updates. To make changes in the future, simply roll out a new distribution of the DeploymentRuleSet.jar. Notes and what Deployment Rule Set is not: The Deployment Rule Set features is intended for mostly enterprise users to manage their own configurations. It is not meant as a way to simply "whitelist everything just so warning dialogs go away," "force everyone to never update," or "external users please download this file onto your system to use this application." By default, specifying the version="SECURE" attribute is best unless you know specific reasons indicating compatibility with a specific JRE version. Publicly distributed Deployment Rule Sets found to contain insecure "whitelist everything" configurations may have their signing certificate blacklisted from future use of Deployment Rule Sets.

As the Java security model has hardened for browser-based applets, desktop administrators have asked for ways to manage version compatibility and security updates for their end-users. A new feature is...

Oracle

Integrated Cloud Applications & Platform Services