Java technology, IBM style: A new era in Java technology

Highlights of the Oracle spec and IBM value-adds for performance, reliability, and serviceability

The eagerly awaited final release of Java™ SE 7 is expected to include enhancements to all the major aspects of the language and the virtual machine. Both Oracle and IBM have released Early Access downloads of their respective implementations for review and feedback. In this article, Chris Bailey, architect of the Java service strategy at the IBM Java Technology Center, introduces some of the changes in store, from both the Oracle specification and the value-add that IBM provides.


Chris Bailey, Java Support Architect, IBM

Chris BaileyChris Bailey is a member of the IBM Java Technology Center team at the Hursley Park Development Lab in the United Kingdom. As the technical architect for the IBM Java service and support organization, he is responsible for enabling users of the IBM SDK for Java to deliver successful application deployments. Chris is also involved in gathering and assessing new requirements, delivering new debugging capabilities and tools, making improvements in documentation, and improving the quality of the IBM SDK for Java.

20 April 2010

Also available in Chinese Japanese

Expected for final release this fall, the latest update to the Java platform is significant and eagerly anticipated. Although the Java 7 platform Java Specification Request (JSR) has not yet been officially created through the Java Community Process (JCP), and the final feature set is still under wraps, the Early Access downloads (see Resources) from Oracle and the public statements of the Oracle team provide a good understanding of the features we expect to be delivered in Java SE 7.

The expected features are grouped into four major categories:

  • Non-Java language support
  • Ease-of-development updates
  • Modularity support
  • Scalability updates

Non-Java language support and JSR 292

Java 7 will provide improvements that allow implementers of compilers for dynamically typed languages to produce implementations for the Java runtime more easily, and for those implementations to run at much greater performance. JSR 292 is the impetus for the change. It introduces both a new bytecode and a number of new Java classes.

For the most part, the Java language is strongly typed, which requires the types of parameters passed to or returned from methods to be specified. However, at the bytecode level, Java is more loosely typed: variables on the operand stack are typed only in terms of which primitive type they are, or that they are generically an object reference. The loose typing at the bytecode level is true in almost all cases. The exception is method invocation, in which strong typing is enforced — that is, the method being invoked is done so with its full signature, which includes the parameter and return types. In this case, the invocation needs to be against a Java method using known Java types. This causes a problem for dynamic languages such as Ruby, Python, and Groovy, because they are dynamically typed (the type is known only at run time).

Mechanisms, usually reflection-based or using generated invokers, exist for avoiding these problems and allowing dynamic languages to be run on a JVM, but they exact a substantial performance hit. The introduction of JSR 292 sought to resolve these issues with the addition of a new Java bytecode, invokedynamic, for invoking dynamic methods, paired with a Java language linkage mechanism that uses a method handle construct that allows rewiring what that method is at run time.

Ease-of-development features

As with previous releases of the Java platform, a number of new language features are aimed at simplifying the syntax required for commonly used constructs.

Project Coin

Project Coin covers a number of small changes ("coins") that are designed to reduce the complexity of programming simple tasks and improve the readability of the resulting code.

  • Strings in switch statements
    In pre-Java 7 releases, you cannot use Strings or Objects in switch statements. This means that the only way to perform a switch-style operation on a String was either to use a series of if-then-else statements or to convert the String into a primitive or an enum. The introduction of String usage in switch statements means the following simple construct is now legal:

    switch (myString) {
                   case "one": <do something>; break;
                   case "red": <do something else>; break;
                   Default: <do something generic>;
  • Improved type inference for generic instance creation
    Java 5 introduced generics, which male it possible to apply parameterized types to generic collection classes when they are instantiated, which in turn allows compile-time safety checking to occur. However, the implementation was such that the type parameters were duplicated unnecessarily, for example:

    Map<String, List<String>> anagrams = new HashMap<String,

    The improved typing change allows the second <> construct to be inferred:
    Map<String, List<String>> anagrams = new HashMap<();
  • Simplified varargs method invocation
    Currently, when invoking a method that accepts variable-length arguments, the calling code receives a compile-time warning that an unsafe operation is being made. With this new feature, that warning is moved to the declaration of the method that accepts variable-length arguments, reducing the number of unavoidable warnings in the calling code.
  • Language support for Collections
    The syntax for initialising arrays allows the specification of the values that will be in the array using the following syntax:

    int[] array = new int[] {0,1,2,3,4,5}

    This syntax is now being applied to Collections, for example:

    List<String> numbers = ["one", "two", "three", "four",
  • Automatic resource management
    This enhancement provides a new form of the try statement that declares one or more resources that must be closed manually; for example, InputStream or OutputStream. The new try syntax means that once the statement is complete, the declared resources are automatically closed:

    static String readFromFile (String file) throws IOException {
                try (BufferedReader reader = new BufferedReader(new FileReader(file)) {
                               return reader.readLine();
                } // resources are automatically closed here

The closures debate

Closures have sparked quite a controversy in the Java community. Include them or not? And how, exactly, is best? Back in 2007, Brian Goetz provided a look at the then-current closures discussion, which has ebbed and flowed over the years. Neal Gafter has been a vocal proponent of adding closures to the Java language. His Closures for Java page provides a wealth of information on the subject.

Closures (non-Coin)

A number of programming languages, including Scheme, Ruby, and SmallTalk allow the use of closures or lambda functions. An implementation of closures is expected to be included in the final Java 7 specification; however, the details of said implementation are not yet clear as there are multiple competing proposals.

Modularity support

With each new version of the Java platform, the SDK has grown larger — an unfortunate side effect of increased capabilities available over a wide range of environments. Whilst the large number of capabilities is definitely an asset, the unduly large size and complexity that necessarily results affects some key performance metrics: download size, startup time, and memory footprint.

Project Jigsaw

Learn more about Project Jigsaw and its place among Java modularity solutions in the developerWorks roundtable on the current state of Java technology, culture, and industry.

In order to address these issues, Java 7 intends to deliver a modular JDK runtime, called Project Jigsaw, which will allow users to download and load just the components required to run an application. In addition, users will be able to apply modularity to libraries and applications. The exact implementation is still to be determined.

Scalability updates

As multicore systems are becoming more prevalent, and the number of cores present in those systems are growing over time, it is important that the Java language also evolve to be more scalable. By extension, this means that developers need access to scalable collections, data structures, and algorithms. The improvements in scalability of the Java language have been continued in the version 7 with two main features: New I/O 2 and Concurrency and Collections updates.

New I/O 2

A set of New I/O (NIO) APIs for the Java platform, introduced into the 1.4 release under JSR 51, aimed at allowing the development of highly scalable I/O without the need to develop native code. JSR 51 focused largely on buffers and channels, and it provided nonblocking multiplexed I/O. In version 7 we have the arrival of (new) New I/O APIs (NIO.2) under JSR 203, which extends the work started in back in 1.4.

The NIO.2 APIs cover three major areas of improvements: asynchronous I/O, updated SocketChannel functionality, and a much-improved file system interface. Each of these updates continues the theme of providing the ability to produce highly scalable I/O infrastructure.

  • Asynchronous I/O
    The Java platform, version 7 introduces asynchronous I/O for both sockets and files by providing a new set of AsynchronousChannels, allowing threads to continue to do work whilst I/O continues and then to be notified that the I/O is complete. Version 7 provides two notification mechanisms: in the first, the asynchronous I/O call returns a java.util.concurrent.Future object representing the resulting object that provides APIs to wait for the I/O to complete, or poll its current status; the second is by specifying a java.nio.channels.CompletionHandler, which is invoked in a call back when the I/O completes.
  • Updated SocketChannel APIs
    Prior to the updated SocketChannel API present in NIO.2, the network channels implementation was not a complete abstraction of a network socket: you were forced to use both socket and channel APIs in order to create a network channel. The update resolves this problem by causing each of the network-oriented channels to implement a new NetworkChannel interface that defines bind(), getLocalAddress(), getOption(), and setOption() methods. In addition, multcast support has been added through a new MulticastChannel interface.
  • Improved file system API
    The improved file system API fixes some fundamental problems with the standard Java File I/O API (for example, the lack of I/O exceptions during operations such as file deletion or renaming) and provides new support for commonly performed tasks that had to be carried previously out using custom coding on top of the provided API. These include support for copying and moving files, symbolic links, and file permissions, as well as providing a file change notification and watch API.

Concurrency and Collections updates

The java.util.concurrent package was introduced in Java 5 under JSR 166 and was further extended in Java 6 with JSR 166x. Concurrency gets yet another update in Java 7 through JSR 166y with a new fork-join framework described by Doug Lea, the JSR lead, as a "multicore-friendly lightweight parallel framework." Other enhancements include TransferQueues and Phasers.

Stick a fork in it

Proof that Java 7 has been long in coming is this popular two-part series on the fork-join framework from Brian Goetz was written almost two years ago. Part 1 introduces the mechanism for decomposing many algorithms to exploit hardware parallelism effectively, and Part 2 details the ParallelArray classes, which simplify parallel sorting and searching operations on in-memory data structures.

  • Fork-join framework
    The fork-join framework is aimed at providing support for high-performance computation of tasks that can be broken into multiple parallel tasks, allowing efficient exploitation of the presence of multiple processors and cores.

    The typical example given to illustrate an operation that can be split into many parallel tasks is the merge-sort algorithm. Here the data to be sorted is broken into fragments that are sorted individually as subtasks, with those subtasks potentially being recursively broken unto further subtasks. Once the subtasks are complete the results are then combined (merged). The process is carried out by having a given task fork a number of subtasks and then wait to join the completed tasks. The fork-join framework added to Java 7 provides infrastructure for carrying out fork-join processing, including pooling and work stealing to reduce the reduce the effects of waiting on other subtasks to complete.
  • TransferQueue
    The TransferQueue class is a form of BlockingQueue but differs in that it provides a recorded delivery service. Whereas a thread that is inserting an object into a BlockingQueue returns once the object has been successfully added to the queue, a thread inserting an object into a TransferQueue will return only after the object has been removed from queue by another thread.
  • Phaser
    The Phaser class provides a new flexible synchronisation barrier that is similar to the existing CyclicBarrier introduced in Java 5, but with some additional features. In particular is the ability to change the number of registered parties dynamically.

Value-add features from IBM

In addition to the mandated feature updates that occur with each new release of the Java platform that are due to updates in the JVM specification and the Java Class Libraries API, each Java vendor is permitted to deliver its own value-add improvements to its Java deliverables. For IBM's Java deliverables, these value-add enhancements are typically in three focus areas: performance, reliability, and serviceability.

Runtime performance

The performance of the Java runtime is a direct factor in the return on investment for deploying an application. For this reason, various standard benchmarks have been created to mimic particular deployment scenarios or workload types to give an idea of the return on investment. Whilst the majority of benchmarks focus on runtime performance —the speed at which the application can be executed — IBM is also interested in the initial startup time for the application.

Learn more about IBM's implementation of Java SE 7

Trent Gray-Donald, IBM's Java SE 7 lead architect, offers his take on the Oracle Java 7 specification, IBM's value-adds, and the state of Java technology today in this podcast.

Startup performance
The startup performance of Java applications a key concern for the IBM team, both because of the impact of long startup times on usability of client-side applications and because of the potential impact of startup times on recycle and fail-over scenarios for server-side applications.

In the IBM SDK for Java 5, IBM provided a major feature for reducing the start and restart times of Java applications in the form of class sharing. This approach enabled all system and application classes to be stored in a persistent dynamic class cache that is present in shared memory, an in a state that (crucially) already has undergone verification of the class data. As a result, when a Java application is loading classes, the vast majority of which occurs at startup, it can do so from shared memory without incurring the overhead of verifying the bytecodes.

In the IBM SDK for Java 6, the work on startup performance continued with the inclusion of moderately optimized Just-in-time (JIT) compiled code in the shared classes cache. This meant that another major overhead of startup could be removed: the compilation of frequently used methods that are involved in the application's startup.

The IBM SDK for Java 7 will further improve startup performance, focusing on areas like storing more data in the shared cache and carrying out typically single-threaded startup activities on multiple threads.

Runtime performance
The performance of Java applications is an ongoing focus area of most if not all Java vendors. As such, this is also a priority area for the IBM runtimes for Java technology. Each of the releases of the IBM runtimes has sought to add incremental performance improvements to the previous release.

Table 1 shows the performance improvement between the IBM SDK for Java versions 5 and 6 using the IBM 32-bit Java runtime on AIX:

Table 1. Table of IBM SDK for Java performance
IBM SDK for JavaResult (bops/JVM) 4 coresResult (bops/JVM) 8 coresResult (bops/JVM) 16 cores
Percentage improvement17.3%16.2%15.4%

Note: Data taken from the SPEC JBB2005 benchmark data published on, using the IBM Java Runtime for AIX on IBM System p 570, 4.7 GHz.

Again, for the IBM SDK for Java 7, runtime performance is still critical. The Open beta program page will detail new features as they become available.


The reliability of the Java runtime is of paramount importance, particularly when running business-critical applications where 24x7 uptime is expected. In order to produce a highly reliable runtime, the IBM team adopts a number of quality processes during development and uses a code base structure-and-test strategy that maximizes the testing coverage and scenarios.

Common code for all platforms
Since the release of the IBM SDK for Java 5, all the underlying components of IBM implementations of the Java runtime are built from a common code base with very little platform or architecture specific code. IBM delivered 14 releases of IBM SDK for Java 6, covering 31-, 32- and 64-bit on platforms ranging from Windows to z/OS on mainframes. This vast range of hardware and operating system configurations allows for testing to ensure reliability for a large number of scenarios. By extension, finding and fixing bugs on one configuration results in improved code on all configurations. This breadth of test scenarios greatly increases the potential to identify difficult-to-find timing and synchronisation style bugs.

Help shape the IBM SDK for Java 7

The open beta program provides licensed access to the latest IBM SDK for Java 7 beta. It provides a preview of possible new technology and features, and enables you to give feedback through an open beta program forum.

Product portfolio
Most of the IBM Software Group product portfolio uses Java code. This means not only that IBM has a vested interest in producing a high quality, reliable Java runtime, but also that a huge volume of testing is carried out on the IBM software product line. Test scenarios that apply to the vanilla Java runtime (including the testing of open source products) are combined with the testing of a wide range of deployment and load scenarios typical for those IBM software products. This large breadth and depth of testing helps to ensure the quality and reliability of the IBM runtime for Java technology. In addition to the IBM Software Group product portfolio, a number of ISV partners also test their various software scenarios against the IBM runtimes, again expanding the use-case coverage.


Like all vendors, IBM strives to make application deployments bug-free, but it's an accepted fact of software development that defects with unexpected consequences will arise. In an effort to understand the cause of problems and resolve them, IBM provides monitoring and diagnostic capabilities and tools to help troubleshoot problems in either the deployed Java application, or in the Java runtime itself.

Debugging capabilities

  • Dump engine enhancements
    The dump engine provides the ability to generate a number of different types of data, ranging from non-destructive system dumps to thread dumps, or alternatively to execute a given command line, and to do so on a wider range of events.

    With the IBM SDK for Java 7 you can now generate new dump types, including the "stack" type, which generates a single stack trace for the thread causing the event, and to do so on more events, including the "allocation" event, which occurs when an object is allocated.
  • Trace engine enhancements
    The trace engine makes is possible to do instrumentation-free tracing of what is occurring inside the Java runtime, or inside any Java code that is running on it, including core class libraries, middleware code, or your own application code. Not only does the engine trace code execution, but it also allows triggering. At the most basic level, you can use triggering to turn trace on and off in order to reduce the volume of trace data generated and also to generate dumps, including a new jstracktrace dump, which provides the stack trace of the calling code and a "sleep" option that you can use to insert arbitrary delays into running code.
  • Java dump enhancements
    The javadump file, which contains a status summary of the executing runtime including the stack trace for all of the threads in the application, has also been updated. The changes take the form of the operating system ulimits and environment variables, as well as the native (C) stack traces for each of the threads, providing a better insight into what the Java runtime is doing on behalf of the Java code, or what is occurring in any Java Native Interface (JNI) code.
  • Diagnostics collector
    When a problem event such as a general protection fault or an OutOfMemoryError occurs, the IBM runtime for Java technology generates a number of diagnostic files that contain useful information about the causes of the problem. The Diagnostics Collector is a tool that runs just after the diagnostic files have been created, searching for system dumps, Java dumps, heap dumps, Java trace dumps, and the verbose GC log that match the time stamp for the problem event.The Diagnostics Collector then produces a single compressed .zip file containing all the diagnostics for the problem event reducing the amount of disk space occupied and removing the need to search manually for files that may or may not exist.

IBM Monitoring and Diagnostic Tools

  • Garbage Collection and Memory Visualizer (GCMV)
    GCMV provides analysis and views of an application's verbose:gc output or the operating system memory monitoring data and displays it in both graphical and tabulated form. It also provides a clear summary and interprets the information to produce a series of tuning recommendations and to detect Java memory leaks. This interpretation allows you to understand the memory usage profile of your application and to tune to improve the performance of the garbage collector.
  • Dump Analyzer
    Dump Analyzer is a tool that helps you determine the cause of a Java application failures using an operating system level dump. It provides individual analyzers that produce specific data in answer to specific questions. It links combinations of these analyzers together to produce a report of any problem causes and the application status.
  • Health Center
    Health Center is a low-overhead live monitoring solution that enables you to assess the current status of a running Java application. Health Center gives clear and easy-to-understand information about performance, memory usage and management, optimization, and profiling. Health Center in particular provides method profiling information, showing how often methods are called as well as the calling stack trace, information on the performance of synchronised code in the application, and data on memory usage of both the Java heap and the overall process.
  • Memory Analyzer
    Memory Analyzer brings the diagnostic capabilities of the Eclipse Memory Analyzer Tool (MAT) to the IBM runtimes for Java technology by extending Eclipse MAT using the Diagnostic Tool Framework for Java (DTFJ). This extension enables Java heap analysis using operating system level dumps and IBM Portable Heap Dumps (PHD), which in turn enables you to diagnose the cause of memory leaks, analyse the footprint of your application, look at the size and efficiency of Java Collections, and to understand the state of an application at a given point in time.


Work on the Java 7 SDK is clearly well under way at both Oracle and IBM. Whilst the specification and content of the releases is constantly changing, the information in this article should give you a better insight into the current status. You can also track the ongoing development via the Early Access programs (see Resources), which are your opportunity to be involved in the development process and give feedback on the features and functions that are important to you.



  • IBM's Java SE 7 lead architect speaks out: In this podcast, Trent Gray-Donald talks about the Java SE 7 specification, IBM's ideas for enhancing the platform, and his thoughts on the Java technology today.
  • Pure Danger Tech: Java 7: Alex Miller's exhaustive listing of proposed features for Java 7 and information about them.
  • IBM SDK for Java 7 open beta program: Get licensed access to the latest IBM SDK for Java 7 beta. Learn about new technology and features, and give feedback through an open beta program forum.
  • OpenJDK 7: An open-source implementation of the next major revision of the Java SE platform, available under the GPL2 license.
  • Apache Harmony: Another open-source implemenation of the Java SE platform, available under the Apache license.
  • "Java roundtable, Spring 2010": Get an inside view on what the future of the Java platform really looks like, as nine Java community leaders sound off on some of the big (and sometimes hard) questions facing the Java industry today.
  • Java diagnostics, IBM style (developerWorks, 2007-2009): Explore new tooling from IBM that can help resolve problems with Java applications and improve their performance. You can expect to come away from every article with new knowledge that you can put to use immediately.
  • Browse the technology bookstore for books on these and other technical topics.
  • developerWorks Java technology zone: Find hundreds of articles about every aspect of Java programming.

Get products and technologies


  • IBM SDK for Java 7 open beta forum: Help shape the direction of the IBM SDK for Java 7.
  • IBM Java Runtimes and SDKs discussion forum: Technical architect for the IBM Java service and support organisation, Chris Bailey, and other members of the IBM JTC team invite you to this discussion forum to share knowledge and ask questions about your experiences of using the various IBM runtimes and kits.


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Java technology on developerWorks

Zone=Java technology
ArticleTitle=Java technology, IBM style: A new era in Java technology