Monday Nov 16, 2015

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

In 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.
  1. Create a file that copies the jdk.certpath.disabledAlgorithms line from JAVA_HOME/lib/security/
  2. Remove MD5 from that line
  3. In your startup command, add
  4. Plan 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:
  1. Open JAVA_HOME/lib/security/
  2. Remove MD5 from the line jdk.certpath.disabledAlgorithms
  3. Plan your migration away from weak algorithms and undoing this change.

SHA-1 plans

We 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


Thursday Nov 12, 2015

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.

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:

Additional Resources

Thursday Oct 08, 2015

NPAPI Plugin Perspectives and the Oracle JRE

Java’s rapid rise to fame 20 years ago began with a tumbling duke applet running in the HotJava browser. Applets allowed richer development functionality at a time when browser capabilities were very limited, and provided centralized distribution of applications without requiring users to install or update applications locally.

HotJava’s support for applets was picked up by Netscape. In 1995 Netscape Navigator 2.0 and plugins became more popular to expand the kind of content that could be displayed. Navigator’s plugin interface (NPAPI) was adopted by other browsers and supported since 2004. Support for Java applets across several different browsers was implemented relying on the common NPAPI plugin interface to provide cross-browser compatibility of Java applications running on the web.

As Java evolved to become one of the leading mainstream development platforms, so did the applet’s hosts – the web browsers.  The rise of web usage on mobile device browsers, typically without support for plugins, increasingly led browser makers to want to restrict and remove plugin support from their products, as they tried to unify the set of features available across desktop and mobile versions. Coincidental with the rise of mobile was the emergence of the “app store” model rather than “plugin based” models for application delivery. The “app store” model grew for reasons related to simplicity, security, and centralized availability. Given these evolutions in mobile, delivery, and capabilities, the set of browsers that continue to support standards based plugins has shrunk over time.

The announcement from Mozilla provides a timeline for developers and users who rely on Mozilla Firefox for applets to evaluate and migrate to alternatives. You should consider using plugin-free technologies, like Java Web Start, or move to other supported browsers, before NPAPI functionality is removed from Firefox in their regular and/or Firefox Extended Support Releases.

As with other browsers, the Oracle JRE can only support applets on Firefox for as long as Mozilla provides the requisite NPAPI support. Having been in regular contact with the Mozilla engineering team over the past years, we have worked together to ensure that our common users benefit from improvements made in Firefox and the Oracle JRE.  We'll continue to collaborate on enabling a smooth transition to plugin-free technologies like Java Web Start.

Meanwhile, we don’t plan to provide additional browser-specific plugins, as such plugins would require application developers to write browser-specific applets for each browser they wish to support. Moreover, we would only be able to offer a subset of the required functionality, different from one browser to the next, impacting both application developers and users.

As with previous transitions, any additional information specific to Oracle products will be provided by the corresponding product teams. Internet Explorer and Safari browsers are not impacted by this change.

System administrators who want to prepare for the transition and learn more about applets (and other kinds of Java applications) running inside their organization should evaluate the Java Advanced Management Console

Monday Aug 31, 2015

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

Wednesday Aug 05, 2015

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/ file. The specific property is jdk.certpath.disabledAlgorithms.

Wednesday Jun 24, 2015

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.

Monday Jun 15, 2015

Deferring to Derby in JDK 9

Java DB is simply a re-branded distribution of the Apache Derby open source database. It contains the same binaries as Apache Derby.

As of JDK 9, it is no longer being planned to include it in the 'db' directory of Oracle JDK downloads.

Developers looking ahead to JDK 9 should plan to get and bundle Apache Derby independently for the same purpose.

 - Don 

Tuesday Apr 21, 2015

Understanding Time Zone Updater 2.0

The JRE uses the IANA Time Zone Database for its time zone calculations. To keep this information up to date users must keep their JRE versions up to date or use a utility called TZUpdater available from Oracle. Until recently a new version of TZUpdater was needed for each Time Zone Database update. An enhancement to the tool lets users get the latest information directly from IANA allowing users to rely on the same tool for all future update. [Read More]

Tuesday Mar 31, 2015

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.

Thursday Mar 26, 2015

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
May 2004
Oct 2009
Available through Java SE Advanced. See linked Oracle Java SE Support Roadmap.
Dec 2006
Feb 2013
Jul 2011
Apr 2015
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 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.

Tuesday Feb 17, 2015

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 affected

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

Monday Jan 05, 2015

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

Companies that need to create Deployment Rule Sets may consider using the Advanced Management Console.

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.

Thursday Dec 18, 2014

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.

  1. Part 1 explains the architecture and threading model.
  2. 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

Monitoring Node.js on Java

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.

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.

Monday Dec 15, 2014

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:

  1. Developer workstations, where developers write and test code. This is most likely where you would run IDEs like NetBeans, Eclipse, or IntelliJ.
  2. 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.
  3. Test or QA servers. This environment may run your application in order to find any issues before release into production.
  4. 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.X
    If 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 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/[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 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, provides links to detailed information and compatibility guides about what changed between 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:

I will continue monitoring different areas and will try to follow up in the future with different strategies for upgrading.

Thursday Dec 11, 2014

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:

  1. 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.
  2. 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.
  3. 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/" 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.


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


« November 2015