Java Standard Edition (SE)
Oracle has stated that its high-level Java strategy is to enhance and extend the reach of Java to new and emerging software development paradigms; simplify, optimize, and integrate the Java platform into new deployment architectures; and invest in the Java developer community allowing for increased participation.
In fact, says Thomas Kurian, Oracle's executive VP for product development, Oracle will drive Java to be the most widely used, most productive, and the most pervasive programming platform in the world. Specific statements have been made that Oracle will drive Java to be used in more embedded solutions as well. Kurian has also stated that the Java Community Process (JCP) would remain as the process for Java evolution going forward. I suspect that Oracle will refine the JCP process, which has had issues in recent years where uncooperative participants can stall Java Specification Requests (JSRs).
Kurian has also confirmed that Oracle will continue support for all leading operating systems, as well as the popular Java for Business support program, which provides long-term support for current and out-of-date versions of the Java VM. For corporations that need to maintain legacy Java applications on older Java versions, obtaining security patches and other support is critical.
Arguably, the most interesting statements Kurian has made revolves around the release of Java SE 7, and the merging of Oracle's JRockit virtual machine with Sun's HotSpot. Oracle plans to release Java SE 7 with the following key new features:
- Modularization of the VM. The goal is to break the VM and the libraries into smaller pieces that can be targeted by applications, and pulled down over the Internet as needed. The result is much faster Java application startup times, and shorter download times when the VM is not present on the target machine.
- Additional Language support. The Java platform supports applications written in a variety of languages. The community has received this well, and as a result, support for additional languages will be added. However, this also includes support for dynamic languages based on the work done with the Da Vinci Machine, also known as the Multi Language Virtual Machine or JSR-292.
In particular, this feature adds support to the JVM for dynamically typed languages, making it easier to add support for more languages going forward. Prior to this enhancement, and due to the static requirement of the Java language, the Java compiler would add extra bytecode for all of the contexts a method call might execute within. This led to additional JIT compilation time, and a larger-than-usual consumption of memory in Java's permanent generation (permgen) that in turn can increase garbage collection times as well.
With this enhancement in Java SE 7, existing class bytecode can be modified at runtime and thereby consume less permgen space, impact GC execution times less, and allow for more optimized JIT-compiled code.
- Enhanced Multicore Support. Tools, libraries, and built-in facilities are needed to help new and existing Java applications take advantage of multicore hardware more efficiently. Java's threading model makes it easy to create threads to perform tasks in parallel, but how do you break a single task into multiple pieces to be executed in parallel?
There are third-party software packages available to help with this, such as Pervasive's DataRush product, but having support in the Java platform itself is also helpful. For instance, Doug Lea has been working on the Java Fork/Join Framework to add this capability to Java. The proposal is to add the framework to the java.util.concurrent package, and it works by recursively breaking down a task into subtasks that are executed in parallel. The framework handles the threading, coordination, and the composition of the results when all subtasks terminate.
Other improvements include continued performance improvements, and various language enhancements. Proposals include the addition of closures, support for Strings in switch statements, and multi-catch exceptions blocks. Closures is a controversial feature that is otherwise emulated through the use of anonymous Java inner classes, but it appears a commitment has been made to include it.