Monday Oct 13, 2014

Upcoming Oracle Java SE 7u72 PSU

On October 14th, Oracle plans to release the regularly scheduled Critical Patch Update (CPU) release for Oracle Java SE.  

For Oracle Java SE 8, that is version 8u25.  We now encourage all Java users to download and use the latest Java SE 8 update release.  With this release, Java SE 8 is ready to debut as the default on, and as we've previously noted we will begin auto updating users to Java SE 8 in early 2015. 

For Oracle Java SE 7, there will be two releases targeting different audiences:

  • Oracle Java SE 7u71 is the regular CPU containing only security fixes.  This is the intended upgrade for most users
  • A separate Oracle Java SE 7u72 is available for developers and users requiring additional non-security improvements or for testing updated features.  You should use 7u72 if you are facing any of the specific issues as noted in its release notes, and also as part of your quality assurance cycles.  These improvements and features are planned to appear as part of the next scheduled CPU in January 2015.

For more details, please see the OTN Article "Java CPU and PSU Releases Explained". 

 - Don


Monday Oct 06, 2014

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:

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

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:

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

Friday Sep 19, 2014

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

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:

  1. C:\Program Files\Java\jre8 – The 64 bit version, available for local processes and 64 bit browsers like Internet Explorer (64 bit).
  2. 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.

Tuesday Aug 19, 2014

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.

Check if the rule is right

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

Monday Aug 11, 2014

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

New features announced by Microsoft give Internet Explorers users, developers and sysadmins more tools to keep users of Java up to date and secure.[Read More]

Monday Aug 04, 2014

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

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 Professionals

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

  1. Open the Java control panel.
  2. Select the Java tab.
  3. Click View
    • In the "Runtime Parameters" area, enter the number 7 and then backspace over it.
  4. Click OK.

Wednesday Jul 30, 2014

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:

  1. 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.
  2. Applications can surface their own business-related Management Bean to the JMX rather than building a new monitoring user interface.
  3. The monitoring agent is already available inside the runtime. There is no need to embed additional items in your application.
  4. 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.
  5. 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 viewer

JMX capabilities are split into two parts:

  1. The JMX agent that serves information is available within the runtime. This runs alongside your application.
  2. 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).

screenshot of jconsole

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.

screenshot of jconsole

In many situations, such as application servers, the application may be running on an entirely different host.

Authenticated remote monitoring for System Administrators

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

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

  1. 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.
  2. LDAP for enterprises. The benefit of LDAP integration is group authentication, as well as automatic integration with joiner/leavers processes.
  3. 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 off

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

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

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

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

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

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

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

Wednesday Jul 02, 2014

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:

(March 2014 to present)
(July 2011 to present)
(2006 to end of public updates 2013)
TLS Protocols
TLSv1.2 (default)
TLSv1 (default)

TLSv1 (default)
JSSE Ciphers:
Ciphers in JDK 8
Ciphers in JDK 7
Ciphers in JDK 6
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("");
try(final InputStream in = url.openStream()){

Or the connection can be tuned through a cast:

final HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
//operate on conn
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.
 Prints debugging details for connections made.
Example: or

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 Introduced in JDK 8, this controls the underlying platform TLS implementation. Additional information is available in the JSSE Reference Guide.
Example: -Djdk.tls.client.protocols=TLSv1.1,TLSv1.2
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" proxy details from the operating system itself.
The proxy connection to use for HTTP connections.
Example: -Dhttp.proxyPort=8080
The same as above, except that configuration is separate between HTTP and HTTPS.
Password-based credentials for the above proxies.

Many other protocols and properties can be found within the following areas:

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: 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 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 = 168
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT:  fatal, handshake_failure
main, called closeSocket()
main, handling exception: 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 = 226
main, READ: TLSv1.2 Handshake, length = 89
*** ServerHello, TLSv1.2
RandomCookie:  GMT: -1809079139 bytes = { …}
Session ID:  {…}
Compression Method: 0
Extension 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]
main, 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:

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.


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.js
jjs -fx -Dhttps.protocols=TLSv1 viewmyclient.js

var Scene = javafx.scene.Scene;
var WebView = javafx.scene.web.WebView;
var browser = new WebView();
$STAGE.scene = new Scene(browser);

Wednesday Jun 11, 2014

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:

  1. Interoperability with Java and JavaScript libraries.
  2. Scripts do not need to be compiled.
  3. Fast execution and multi-threading of JavaScript running in Java’s JRE.
  4. The ability to remotely debug applications using an IDE like NetBeans, Eclipse, or IntelliJ (instructions on the Nashorn blog).
  5. 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:
    • 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:

print("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"

var whatYouSaid = $ARG.length==0 ? "You did not say anything" : $ARG[0]

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:

  1. For standard classes, just name the class: var ServerSocket =
  2. 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 -fx
var 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();
$STAGE.scene = new Scene(root, 300, 250);
function myFunctionForButtonClicking(){
  var text = "Click Counter: " + clickCounter;

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.


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:

Tuesday May 20, 2014

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
Most developers use this.
Developers building Java applications and/or profiling them with Mission Control.
Most client systems use this.
Clients running Java applications on their Windows/Max/Linux desktop.
Server JRE 8
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
Embedded devices requiring Kerberos or remote monitoring like JMX, but not APIs like Swing, CORBA, and Java Sound.
Java SE Embedded compact 2
Embedded devices making use of SQL connectivity or XML processing, but not any functionality from compact3.
Java SE Embedded compact 1
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)
      ->                 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.

  1. Download the version of Java SE Embedded for your target platform.
  2. Unzip the version that you downloaded into its usual ejdk folder.
  3. 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.


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


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.

Thursday May 01, 2014

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:

  1. 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.
  2. 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.
    1. 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):

  1. C:\Program Files\Java\jre7
  2. 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 -->
<ruleset version="1.0+">
        <id location="" />
        <action permission="run" version="SECURE" />
        <id location="" />
        <action permission="run" version="1.6.0_31" />

In this example, we were able to identify and test each item. For example, the first rule checks that users could run the normal 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 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.

Screenshot of command-line in Win7 task manager

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.

Screenshot of java console

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:

  1. 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.
  2. 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
        jar location:
        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
Although 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

Those will help identify the items that the RIA plugin is seeing, so then you can look for one of the following messages:

  1. ruleset: Rule hash matches certificate hash (or a similar message about location)
  2. ruleset: no rule applies, returning Default Rule

Thursday Apr 17, 2014

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.

Monday Apr 07, 2014

JavaOne 2014 Security Track Early Acceptance Sessions

J1 LogoJavaOne 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!

Tuesday Apr 01, 2014

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


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.


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.

Wednesday Mar 19, 2014

Java SE 8 is available for download

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

Java 8 - Create the future

Please also join the main launch webinar on March 25.

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

Coordinated Releases

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

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

Auto-Updates and the Security Baseline

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

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


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