JDT Embraces Java 8

For almost 10 years, the Java programming language has been stable; the small language enhancements added in Java 7 did not require much learning. It has been said that a new programming language is only relevant if it changes the way you think about software. For some of us, Java 8 will fit this description; to embrace Java 8 means to shed some old habits and approach some problems of day-to-day programming in an entirely new way.

The new version of Java may look nice on paper and slides, but for developers to become productive writing programs in Java 8, an IDE is needed. In Eclipse this IDE is provided by the Java Development Tools Project (JDT). The JDT team has worked hard for close to 2 years; we are well on schedule to deliver a full-featured IDE for Java 8 right when Java 8 is released in March.

So what support for Java 8 may Eclipse users expect from JDT?

Tooling for Java 8

The first tool needed for working with Java is a compiler. As many readers will know, at JDT we maintain our own Eclipse Compiler for Java™ (ECJ). We are occasionally asked, why we do so, rather than just using javac.

I have three answers:

1. ECJ supports incremental compilation where the IDE can trigger compilation of only those files that have changed or are transitively affected by a change.
2. ECJ is used behind the scenes for all IDE features that require structured knowledge about Java programs (vs. just operating on flat text files).
3. Competition between different compiler teams is actually healthy for the community.

Evolving the compiler for Java 8

Extending ECJ for Java 8 was by far the biggest effort for the JDT team. While the team is still very busy wrapping up the various tasks, we are confident that in March we will ship a full-fledged Java 8 compiler.

As with any evolution task, you never know up-front, whether the existing architecture will actually support the new requirements. In particular, the parser generator jikespg, used for creating the JDT parser, strongly disliked the new syntax rules. During an early stage it was not clear at all, whether it would be technically possible to tweak the new grammar rules so that they would be accepted by the parser generator. If the answer had been negative, we would have had to implement an entirely new parser. Given that the parser is the very bottom of a tall tool stack, exchanging the parser would have endangered the entire development schedule. Luckily, some new interaction between scanner and parser could be invented, that allowed us to bypass the limitations of the parser generator. The existing architecture can thus be maintained.

Another challenge was in coping with updates of the Java Language Specification trickling in until late in the game. Development of a central new component, the new type inference engine, could only be seriously started as late as fall 2013.

Empower the IDE to handle Java 8

On top of the updated compiler, all IDE functionality can cope with the new language features. This includes all code browsing functionality, like hyperlinking, text hovers and search. Also formatting, code assist, quick assists, quick fixes, refactoring and debugging; all understand the new constructs and should work in Java 8 programs exactly as you are accustomed to. Much of this is due to a major update of the DOM AST API, which also allows third-party plugins to inspect and manipulate Java 8 programs.

JDT even offers a new quick assist that lets you convert an anonymous class into a lambda expression (if possible).

Leverage type annotations for null analysis

The existing support for annotation-based null analysis has been lifted to use type annotations (JSR 308). What may sound like a small change is actually a major step towards statically detecting all potential null pointer exceptions. To understand the significance consider a variable "@NonNull List<Person> persons" . In previous versions we had no chance to tell if an expression like "persons.get(i).getName()" is safe, because we wouldn't know whether "get(i)" could possibly return null or not. With type annotations we can now extend the declaration to saying "@NonNull List<@NonNull Person> persons" , which will effectively protect the list against insertion of a null value. This establishes the guarantee that "get()" on this particular list will never return null! Conversely, a "List<@Nullable Person>" will require a null-check each time we extract and use an element from the list.

Migrating to the new scheme requires a few adjustments for programs already using null annotations; in particular annotations on qualified type names and annotations on arrays or varargs need to be updated to the new syntax. A migration guide will be provided in time for the release.

The team behind the tool

In the initial several months of the effort, the core JDT team at IBM saw some staffing challenges due to experienced committers leaving the team for other projects, higher studies, or to start up on their own. Fortunately, the team received excellent commitment with follow through from the broader community.

During this period, JDT/Core could welcome two additional non-IBM committers: Jesper Møller and Andy Clement. It shouldn't come as a surprise that Andy, just like myself, came to JDT from the background of having worked on other language IDEs on top of JDT. In Andy's case it's for AspectJ and Groovy, in my case for Object Teams. Speaking for myself, I can report that working on Java 8 support in JDT was a big enabler for integrating the new Java features also in Object Teams; the plan is indeed, to publish a Java-8-enabled version of the Object Teams Development Tooling on the same day as JDT for Java 8. Jesper, finally, is what project lead Srikanth enthusiastically calls a “plug and play" team member – providing high quality contributions across several different subsystems of JDT.

If JDT will see continued help from its three non-IBM committers even after the Java 8 story has been completed, we are looking forward to splendid times.

In addition, we have received a great lot of excellent bug reports. Provided test programs, precisely pin-pointing a defect in the compiler, have been of great help in improving the implementation. We have also received more code contributions and proposed patches than in “normal” times. Thanks to all!

For the last mile towards the release we are extending our request for testing our early access builds. For January 31 we plan our next “early access release”, starting a 45 day beta program before GA in March. Please see the following link for installation details, try it and report any bugs you might find:

http://wiki.eclipse.org/JDT/Eclipse_Java_8_Support_(BETA)

If you happen to attend EclipseCon North America in March, be sure to look for our presentations, titled “JDT embraces type annotations” and the main talk at “JDT embraces lambda expressions”.