JDK 7 Adoption Guide

With the release of JDK 7, the Java Language continues to evolve. New language features make it possible to write tighter, more robust code. Functionality that was previously difficult to implement is now made easier. This guide shows, in some detail, why you should consider migrating from JDK 6 to JDK 7.

In addition to this guide, there are two documents that you should be aware of when migrating to the JDK 7 release.

These pages are available through the JDK 7 Release Notes. For the most part, the information in those documents is not duplicated here.

This document covers the following areas:

Java Language Enhancements

Most of the Java Language Enhancements introduced in JDK 7 were a result of JSR 334, supported by OpenJDK Project Coin. The primary goal of this effort was to introduce language changes that support writing cleaner, more robust code.

If you use an IDE to develop your applications, it can help migrate existing code. The NetBeans, Eclipse, and IntelliJ IDEs are all shipping versions that support the Coin features.

The following list details the specific enhancements.

Performing a switch statement on a string

Prior to JDK 7, it was not possible to perform a switch on a String object. To achieve this functionality, you had to use if-then-else statements. The ability to switch on a string is now supported and produces more efficient bytecode than an if-then-else statement. For more information, see The switch Statement (Java Tutorial) and Strings in switch Statements (JDK 7 Guides).

Writing code with less potential for leaks

Before JDK 7, any resources that were opened in a try statement (also called a try-catch-finally statement) had to be manually closed, usually in a finally block. As of JDK 7, the try-with-resources statement ensures that any resources declared in the try statement will be closed automatically. If multiple resource variables are declared in the try statement, they are closed in the reverse order that they are declared. For more information, see The try-with-resources Statement (JDK 7 Guides) and The try-with-resources Statement (Java Tutorial).

Catching multiple exceptions

Historically, catching multiple exceptions results in a catch block for each exception, with each block containing a variable with the type of that particular exception. In many cases, these catch blocks contained identical code that referenced the specified exception variable. It was difficult to write a common method to handle this duplicated code because the exception variables had different types.

try {
    Path fp = path.toRealPath(true);
} catch (NoSuchFileException x) {
    System.err.format("%s: no such file or directory%n", path);
    ...
} catch (IOException x) {
    System.err.format("%s%n", x);
    ...
}

As of JDK 7, you can catch multiple exceptions in the same catch block using the | symbol.

try {
    Path fp = path.toRealPath(true);
} catch (NoSuchFileException | IOException x) {
    System.err.format("%s: no such file or directory%n", path);
    ...
}

For more information, see Handling More Than One Type of Exception (JDK 7 Guides) and The catch Blocks (Java Tutorial).

More precise re-throw of an exception

Before JDK 7, re-throwing an exception in a catch block did not indicate the actual exceptions possible from the try block. Also, you could not change the type of exception thrown in the catch block without changing the method signature. As of JDK 7, the semantics for catching and throwing exceptions has been refined. If you catch an exception of some type, and do not assign to the exception variable, the compiler will copy over the checked exception type that can be thrown from the try block. It is as if you are re-throwing all the exceptions possible from the try block (provided that you don't re-assign the exception variable). For example, the following code is legal in JDK 7:

JarFile retrieve(URL url) throws IOException {
    Path temp = Files.createTempFile("jar_cache", null);
    try (InputStream in = url.openStream()) {
        Files.copy(in, temp, REPLACE_EXISTING);
        return new JarFile(temp.toFile());
    } catch (Throwable t) {
        Files.delete(temp);
        throw t;
    }
}

In this case, the compiler knows that the only possible exception type is an IOException because that is what Files.copy can throw. For more information, see Rethrowing Exceptions with More Inclusive Type Checking (JDK 7 Guides).

Diamond syntax for more concise new expressions

Historically, you had to specify type arguments for a generic class in a new expression. As of JDK 7, you can replace the type arguments with the diamond notation, (<>), to take advantage of automatic type inference. The resulting code is functionally identical, but more concise and easier to read. For more information, see Type Inference and Instantiation of Generic Classes (Java Tutorial), and Type Inference for Generic Instance Creation (JDK 7 Guides).

Class Loaders

Multithreaded class loading

Prior to JDK 7, certain types of custom class loaders were prone to deadlock. In JDK 7, the locking mechanism has been modified to avoid deadlock. For more information, see Multithreaded Custom Class Loaders in Java SE 7 (JDK 7 Guides).

Concurrency

More scalable code using fork/join framework on multiple processors

Introduced in the JDK 7 release, the fork/join framework uses the ExecutorService interface and allows you to recursively break down work to better utilize multiple processors. For more information, see Fork/Join (Java Tutorial). Also, the <Java_home>/sample/forkjoin directory in the JDK download bundle contains samples that demonstrate the fork/join framework.

Convenience class for generating random numbers from multiple threads

The java.util.concurrent.ThreadLocalRandom class has been added to make it easy to generate random numbers in applications that require random numbers from multiple threads, or from the fork/join mechanism.

The use of existing random number generator classes often ends up unwittingly being the source of contention between threads, biasing benchmark results. This new mechanism results in less contention and better performance. For more information, see Concurrent Random Numbers (Java Tutorial).

Security

The JDK 7 release incorporates many new security enhancements. The following list shows some of these new features.

Elliptic Curve Cryptography (ECC)

A new native provider has been added to the JDK 7 release that provides several ECC-based algorithms (ECDSA/ECDH). Having an ECC provider also enables ECC-based JSSE ciphersuites on all platforms. Previously, only platforms with a native PKCS11 ECC implementation (e.g. Solaris) could use ECC-based ciphersuites out of the box. For more information, see SunEC Provider's Supported Algorithms in the Java Cryptography Architecture Oracle Providers Documentation (JDK 7 Guides).

CertPath and TLS algorithm disabling

Weak cryptographic algorithms can now be disabled. The JDK 7 release provides a mechanism for denying the use of specific algorithms in certification path processing and TLS handshaking. For example, the MD2 digest algorithm is no longer considered secure. For more information, see Appendix D: Disabling Cryptographic Algorithms.

Support for TLS 1.1

The SunJSSE provider now supports TLS 1.1 as described in RFC 4346. The most important update is protection against cipher block chaining (CBC) attacks.

Support for TLS 1.2

The SunJSSE provider now supports TLS 1.2 as described in RFC 5246. Among other things, it specifies different internal hashing algorithms, adds new cipher suites, and contains improved flexibility, particularly for negotiation of cryptographic algorithms.

TLS renegotiation

As of JDK 7, Java SE supports RFC 5746, which fixes a renegotiation issue in the TLS protocol. For more information, see Transport Layer Security (TLS) Renegotiation Issue (JDK 7 Guides).

Connection-sensitive trust management

Both trust managers and key managers now have the ability to examine parameters of the TLS connection, specifically the SSLSession under construction, during the handshake. For example, a trust manager might restrict the types of certificates used based on the list of valid signature algorithms.

Tighter checking of EncryptedPreMasterSecret version numbers

The JDK 7 release tightens version number checking during TLS 1.1 and TLS 1.2 handshaking. For more information, see the JSSE Reference Guide (JDK 7 Guides).

Server name indication (SNI) for JSSE client

The JDK 7 release supports the Server Name Indication (SNI) extension in the JSSE client. SNI, described in RFC 4366 enables TLS clients to connect to virtual servers.

SSLv2Hello disabled by default on clients

As of the JDK 7 release, SSLv2Hello is removed from the default-enabled client protocol list.

NTLM is supported

The NTLM authentication protocol is now supported as a SASL mechanism on both the client and server side. Only the authentication layer is implemented, and there is no privacy or integration protection in communication.

Use of keytab file

Java now reads a keytab file whenever that keytab file changes. The file can be empty or non-existent when the application that uses the file is started.

JGSS default configuration file

A default configuration file is now provided for JGSS with default krb5.conf settings for Windows and *nix systems. This makes deploying a JGSS/krb5 program very easy, especially for deploying Java applets.

IO and NIO

The file I/O mechanism was completely reworked in the JDK 7 release. The previous mechanism, built around the java.io.File class, is still available, but the new mechanism, built around the java.nio.Path and java.nio.Files classes, offers more robust file I/O and much greater functionality.

For those unable to migrate to the NIO.2 file I/O at this time, JDK 7 offers a bridge from the older API so that the new API can be used. For more information on the Files.toPath method and other legacy considerations, see Legacy File I/O Code (Java Tutorial).

The following list highlights the improved functionality offered by the java.nio package.

More comprehensive support for file metadata

Part of the new file I/O mechanism is the java.nio.file.attribute package – this package provides powerful support for file metadata. This package includes support for accessing file permissions, the file's owner, and security attributes. Accessing a file's metadata is implemented in an efficient manner. If you want to define your own metadata, you can use the UserDefinedFileAttributeView interface. For more information, see Managing Metadata (File and File Store Attributes (Java Tutorial).

Support for symbolic links

In the past, there was no real support for symbolic links. For example, it was not previously possible to write reliable code to recursively walk a file tree and respond appropriately when the file system contained circular symbolic links. As of JDK 7, symbolic link support is build in - the Path and Files classes are "link aware." You determine how you want to handle symbolic links, and how to handle those error cases where circular links exist. For more information, see Links, Symbolic or Otherwise (Java Tutorial).

Scalable file I/O support

Many of the java.io.file methods did not scale. Requesting a large directory listing over a server could result in a hang. Large directories could also cause memory resource problems, resulting in a denial of service. The new file I/O package is implemented so that it works regardless of the file system's size.

Behavior is now consistent across platforms

Historically, some methods did not work the same across platforms. For example, the java.io.File.renameTo method behaved differently on different platforms. This type of inconsistency has been eliminated in the new java.nio.Files file I/O APIs.

Support for walking the file tree

The new FileVisitor API provides easy-to-implement support for recursively walking the file tree. This functionality allows you to examine, modify, or delete files or directories in the file system. For more information, see Walking the File Tree (Java Tutorial).

Searching the file system

The PathMatcher API provides programmatic support for finding files on the file system. You can use the provided "glob" syntax, regular expressions, or define your own matching code. For more information, see Finding Files (Java Tutorial).

Watching a directory for changes

The Watch Service api allows you to register a directory for file change notifications. An application can register for creation, deletion, or modification events. This feature can be implemented using the FileVisitor API to recursively watch an entire file tree for changes. For more information, see Watching a Directory for Changes (Java Tutorial).

Networking

Supporting updated implementations of libraries from a JAR file

Prior to the JDK 7 release, if a jar file was updated, it was difficult to ensure that the latest was being used by an application. New in JDK 7, the URLClassLoader.close() method eliminates the problem of supporting an updated implementation of classes and resources loaded from JAR files. For more information, see Closing a URLClassLoader (JDK 7 Guides).

Infiniband support

The new Sockets Direct Protocol (sdp) supports high throughput, streamed connections over Infiniband fabric. SDP is supported only on Solaris and Linux. For more information, see Understanding the Sockets Direct Protocol (Java Tutorial).

Internationalization

Ability to use Unicode 6.0.0

The JDK 7 release supports the Unicode 6.0.0 standard, which added support for over 10,000 additional characters, as well as support for properties and data files. The Java Tutorial has a new section that discusses Unicode.

Extensible support for ISO 4217 currency codes

Currencies are identified by their ISO 4217 codes. The JDK 7 release makes it possible to accommodate new currencies without requiring a new release of the JDK. For more information, see Extensible Support for ISO 4217 Currency Codes (JDK 7 Guides).

Category locale support

The default locale can be independently set for two types of uses: the format setting is used for formatting resources, and the display setting is used in menus and dialogs. Programmatic support so that these locale types can be set independently. On Windows, these default values are initialized according to the "Standards and Formats" and "Display Language" settins in the control panel. For more information, see Category Locale Support (JDK 7 Guides).

Updated Locale support

The Locale class has been updated. There is new support for industry standards, such as IETF BCP 47 (Tags for Identifying Languages) and UTS#35 (Unicode Locale Data Markup Language). A Locale.Builder convenience class has been added to make it easier to create a Locale object. The ability to add user-defined extensions to a locale, for example to specify the linux platform, or a particular release. For information on other updates, see Creating a Locale and BCP 47 Extensions lessons in the Java Tutorial.

New support for shaping numeric characters

The NumericShaper class, used to convert Latin-1 digits to other Unicode decimal digits, has been enhanced to make it easier to shape digits. For more information, see Converting Latin Digits to Other Unicode Digits (Java Tutorial).

Unicode 6.0 support in the regular expression API

In the JDK 7 release, the regular expression pattern matching functionality has been expanded to support Unicode 6.0. For more information, see Unicode Support (Java Tutorial).

Swing & Java 2D Enhancements

Ability to change how components are drawn and how they respond to events

The new JLayer class provides a powerful framework so that you can change the look of a component and how it behaves. For example, you can use JLayer (and related) classes to create an animated wait indicator over a panel. You can use it to visually indicate when a text field contains valid data. You can make a panel ignore, temporarily, all mouse clicks outside of its borders. For more information, see How to Decorate Components with JLayer (Java Tutorial) and Using JLayer in Swing Applications (YouTube video).

Updating the Swing look and feel

A new look and feel for Swing, called Nimbus, has moved from com.sun.java.swing to the standard API namespace, javax.swing. The Nimbus look and feel is not enabled by default. For more information, see Nimbus Look and Feel (Java Tutorial).

Mixing heavyweight and lightweight components

Prior to JDK 7, mixing heavyweight (AWT) and lightweight (Swing) components in the same container has been problematic. As of JDK 7, this can be easily accomplished. For more information, see Mixing Heavyweight and Lightweight Components (OTN article).

Creating shaped and translucent windows

The JDK 7 release supports creating windows with transparency (both uniform and per-pixel transparency) and also non-rectangular windows. For more information, see How to Create Translucent and Shaped Windows (Java Tutorial).

Improved 2D rendering

Introduced in JDK 7, a new XRender-based Java 2D rendering pipeline is provided for modern X11-based desktops. This pipeline, which offers improved graphics performance, is disabled by default, but may be enabled via the command line property -Dsun.java2d.xrender=true. Older X11 configurations may not be able to support XRender. For more information, see System Properties for Java 2D Technology (JDK 7 Guides).

Support for OpenType/CFF fonts

As of JDK 7, installed OpenType/CFF fonts are enumerated and displayed through methods such as GraphicsEnvironment.getAvailableFontFamilyNames. These fonts are also recognized by the Font.createFont method.

Support for Tibetan script

New in JDK 7 is text rendering support of the Tibetan script.

Support for Linux and Solaris 11 fonts

Historically, the logical fonts for the JDK were statically specified in a fontconfig.properties file. However, on the various implementations of Linux, there is no consistency in the presence of fonts. So, without custom files, Asian (CJK) text, etc, would not be rendered. In JDK 7, on Linux, and for Solaris 11, in the absence of a customized fontconfig.properties file for the OS version, the default behavior is to use the system libfontconfig to select fonts to use for the logical fonts. In this case, the logical fonts will reflect the fonts used by the Gnome/KDE desktop applications which use the same platform library. For more information, see Fontconfig on freedesktop.org.

Providing HSL color selection

An HSV tab has been added to the JColorChooser class. This feature allows users to select colors using the Hue-Saturation-Luminance (HSL) color model and is available automatically in JDK 7.

JDBC Enhancements

JDBC 4.1 clarifies the behavior of old methods and introduces new methods on the java.sql and javax.sql interfaces. For more information on the JDBC 4.1 updates, see JDBC 4.1 (JDK 7 Guides).

RowSet 1.1

The JDK 7 release introduces the RowSetFactory interface and the RowSetProvider class, which enables you to create all types of row sets supported by your JDBC driver. For more information, see Using JdbcRowSet Objects (Java Tutorial).

Use of try-with-resources

The updated JDBC package enables use of the JDK 7 try-with-resources statement. Resources of type Connection, ResultSet, and Statement are now automatically closed when used in conjunction with this statement. For more information on try-with-resources, see The try-with-resources Statement (Java Tutorial).

Java DB Enhancements

The version of Java DB bundled with JDK 7 introduces many improvements over the version bundled with JDK 6. New features include:

Definer's rights

Procedures and functions can now run with their creators' privileges, rather than with the current user's permissions.

BOOLEAN data type

BOOLEAN is now a legal data type for columns, routine arguments, and function return values.

Table truncation

A new TRUNCATE TABLE command drops all rows in a table quickly.

Query plan browsing

A new PlanExporter tool helps developers visualize query plans better.

Unicode database names

Remote clients can now use database names which include Unicode characters outside of the ASCII codeset.

Automatic calculation of index statistics

Java DB automatically refreshes statistics to help it pick better query plans.

Improved interrupt handling

Interrupting connection threads no longer crashes the Java DB engine.

MAX optimization

On indexed tables, MAX queries run faster in more cases.

XML operator portability

The xmlparse and xmlserialize operators work out-of-the-box on more platforms.

Java XML Technology Enhancements

As of the JDK 7 release, several XML technologies were folded into the Java SE platform and the supported versions of those technologies updated.

Java API for XML Processing (JAXP)

The JDK 7 release now supports JAXP 1.4.5. There have been many bug fixes and some improvements over the previous version of JAXP, particularly in the areas of conformance, security, and performance. The specification is still JAXP 1.4, however StAX has been upgraded to StAX 1.2 in accordance with the JSR 173 Maintenance Review 3. For more information, see JAXP 1.4.5 Release Notes and the JAXP 1.4.5 Change log.

Java Architecture for XML Binding (JAXB)

JDK 7 now supports JAXB 2.2.3. For more information, see the JAXB Change log for JAXB RI 2.2 and above.

Java API for XML Web Services (JAX-WS)

JDK 7 now supports JAX-WS 2.2.4. For more information, see the JAX-WS Change log for JAX-WS RI 2.2 and above.

Deployment Enhancements

Ability to load applet in a single network request

To load a web page containing an applet, the JNLP file and the jar file (at a minimum) has to be loaded. Introduced in the JDK 7 release, a copy of the JNLP file can be cached in the HTML page. This reduces the minimum number of network requests that are needed to start the applet and the applet is quicker to launch. For more information, see Embedding JNLP File in Applet Tag (Java Tutorial).

Attempt to access applet from JavaScript may block if applet is not yet initialized

Most browsers use single-threaded JavaScript engines so, when the applet is accessed before the applet's init method has completed, it appears that the host page, and the browser, are frozen. Prior to JDK 7, there was no easy way to check if the applet was ready to be accessed. Introduced in JDK 7 is an applet status property. You can check the applet's status anytime to determine whether it is ready to accept requests. Alternatively, you can use callback functions to receive notification when an applet is ready. This feature mitigates the blocking behavior of the isActive() api and does not rely on waiting for the applet's init method to complete before providing a status. This feature is enabled by setting the java_status_events parameter to true. For more information, see Handling Initialization Status With Event Handlers (Java Tutorial).

Codebase in webstart JNLP file can be optional with Deployment toolkit

Prior to JDK 7, moving a JNLP application to another location required editing the codebase value in the JNLP file. This was especially complicated for signed JNLP files that are embedded into jar files. As of JDK 7, if you deploy a JNLP webstart application via the Deployment toolkit APIs, it is possible to omit specifying the codebase in the JNLP file. Therefore, if you move the JNLP file to a new location, you no longer have to edit the file to embed that new location. For more information, see Deploying Without Codebase (Java Tutorial).

Ability to partially sign a JNLP file

A signed JNLP file is used to ensure than an application launch descriptor can not be modified externally. Before JDK 7, a signed JNLP file had to match the external bootstrap copy exactly. That made it difficult to redistribute an application or tune its deployment without rebuilding it. Now the developer can use a template to define what parts of an external JNLP file may differ from one embedded into a jar file.

Targeting resources to a particular version of the OS

Prior to JDK 7, it was possible to target a resource to a particular "family" of operating systems, such as os="linux". This feature is now more finely grained, so that a particular version of the OS can be specified. For example, os="Windows\ Vista Windows\ 7". For more information, see the os attribute for the information and resources elements in JNLP File Syntax (JDK 7 Guides).

Defining the install preferences of an application

In the JDK 7 release, an install attribute for the shortcut element has been added. You can use this optional attribute to specify the application's preference for being considered "installed." On Windows, this determines if the application appears in the Add or Remove Programs panel. For more information, see JNLP File Syntax (JDK 7 Guides).

Better control over applet decoration settings

Before the JDK 7 release, an applet launched from a desktop shortcut was always decorated, but the same applet, when dragged out of the browser, was always undecorated. As of JDK 7, this behavior can be specified in the JNLP file and the same settings will be used both for drag out and a shortcut launch. The default behavior does not change. For more information, see Requesting and Customizing Applet Decoration (Java Tutorial).

Java Virtual Machine (JVM)

Java virtual machine support for non-Java languages

The JDK 7 release introduces a new JVM instruction that simplifies the implementation of dynamically-typed programming languages on the JVM. For more information, see Java Virtual Machine Support for Non-Java Languages (JDK 7 Guides) and New JDK 7 Feature: Support for Dynamically Typed Languages in the Java Virtual Machine (OTN article).

Garbage-first collector

The Garbage-first collector is a server-style garbage collector that, in JDK 7, replaces the Concurrent Mark-Sweep Collector (CMS). For more information, see Garbage-First Collector (JDK 7 Guides).

Java HotSpot virtual machine performance enhancements

The JDK 7 release includes many Java HotSpot performance enhancements, such as tiered compilation, compressed Oops, and escape analysis. For more information, see Java HotSpot Virtual Machine Performance Enhancements (JDK 7 Guides).

Copyright © 1993, 2014, Oracle and/or its affiliates. All rights reserved. | | Ad Choices.