BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
At the JavaOne show, Georges Saab, vice president of Java SE development at Oracle, gave an update on important trends in Java SE, particularly around the transition to 8. He noted the following:
Transition to Java 8
Adoption of Java SE 8 has been strong. It is being adopted in popular IDEs including Eclipse, IntelliJ and NetBeans out of the gate. In addition, a lot of frameworks and open source products from ISBs have been working to make sure that when Java 8 came out, developers could pick it up and use it quickly. Throughout the life of the development of JDK 8, early downloaders gave the Java 8 team time to fix issues before it went into general availability.
One thing that has been contributing to this has been development happening in the open JDK community. Rather than the results being delivered behind closed doors, people could subscribe to mailing lists and see discussions happening, and watch the design unfold. This made it easier for people to follow the future and understand it than in the past.
Many of the updates were created by people outside of Oracle. For example, the date and time API and Type Annotation were contributed by outsiders. There was also work on supporting type 2 AIX led by SAP and IBM.
The main features in Java 8 include Lambda and Streams. Other things include updates to JavaFX and the Nashorn engine. Lambda is something that people have been thinking of as synonymous with Java 8. It represents a larger step forward for Java programmers. Not just a new feature, it introduces a new way of programming for Java developers. They can adopt a functional style that feels natural and not like a departure from their normal development environment. For example Goldman Sachs, with about 3,500 Java developers, had developed frameworks for anonymous inter-classes internally. They were able to use Lambda to replace these internally.
In terms of performance, there was a rush of people publishing new benchmark results on Java 8 and often on new hardware. Overall they reported some nice performance improvements there. Underneath the covers, there were a lot of improvements to Fork/Join and other concurrency-related elements. Even though many Java developers are not using these directly, they may be leveraging code in the JDK library that uses these elements internally. For example, Streaming uses Fork/Join under the covers.
Security has been an ongoing effort for the Java 8 implementations. There have been regular quarterly updates fixing vulnerabilities. There has also been work on APIs in the JDK for cryptography and supporting standards like TLS. Security enhancements have been added to the deployment model used with applets. Early on, there weren't a lot of great models for implementing these. In some cases, it is more of a challenge for developers to do things like getting a certificate to sign code from a trusted CA. This is more work, but necessary to keep people safe. There has been some work done to improve the usability of these security functions.
The next step is to provide an advanced management console to bring enterprise scale to those kinds of capabilities. This is important for enterprises with lots of desktops running Java. They need help rolling out newer software versions to manage what they have and how they are being used.
There was some scuttlebutt in the development community about compatibility issues in the early release of Java 8. But these were more related to a few bugs found using tools like Groovy. But in general, these problems have been found and addressed early. There was a broader and greater degree of effort by Oracle and the Java community to find those kinds of issues so they could be fixed. In general, the migration to Java SE 8 has been smooth, in part because a lot of developers did testing with the early builds before they became issues in the GA release.
In general, developers can be assured that Java 8 was crafted to have the same specifics with the classes and methods as tested by the technology compatibility kits (TCKs). These TCKs are very large and growing day by day. There are also things outside of that, which is one of the reasons that reference implementations have been created so that vendors can look at the behavior to see if a specific implementation is doing the right thing. This is something that Oracle is hoping to solve going forward with Project Jigsaw and the modularization of Java. It is important that things with the Java brand are guaranteed compatibility. One of the reasons the Java community is eager to have these components in a modular systems is to make it clear what the boundaries are.