Iterating all the time
Java 8 support in Eclipse
In this interview (originally published in German in Eclipse Magazine), Martin Lippert, Principal Software Engineer at Pivotal Inc talks about the latest Java release, and the ups, downs, and aspirations of Eclipse IDE development.
JAX: What are the highlights of Java 8 for you?
Lippert: The special highlight for me in Java 8 is certainly the lambda expressions. With them, code can be written simpler and clearer and many of the troublesome Inner classes are finally gone. Especially in connection with the Streams API and the associated extensions to the collections, the lambda expressions look really elegant.
A lot of the hype around Java’s new language features has been directed at lambda expressions. IntelliJ IDEA recognized this early on, and promptly offered initial rudimentary support. Eclipse limped slightly behind – why was this?
I think there are multiple reasons. First, the Java tooling used in Eclipse: it has its own compiler implementation that has nothing to do with the javac compiler. This compiler is a very central part of the Java tooling. It produces not only the class files, but also example abstract syntax trees, which are used by the rest of the tooling to implement the many useful features that we all love so much. Things like content-assist, auto-completion, refactoring, quick- fixes, and many more.
In addition, the Eclipse Java compiler is extremely fast, can compile incrementally, even generate from syntactically not correct codes usable Class files, and performs a very extensive amount of on static code analysis, on the means of Errors and Warnings various may indicate programming errors. It is superior to the standard javac compiler in many areas. The flip side of this coin, however, is that all changes to the language affect the compiler and must be locked into the Eclipse Java compiler. This takes time.
In the case of Java 8, the fact is that the specification for each of these features was for a long time unclear and incomplete. Even quite recently, many details important for the compiler have changed. This is of course not the best basis to implement a compiler. The team has therefore, I think, waited for a good foundation on many areas by the specification, before they could really start working .
Other IDEs on the other hand are at somewhat at an advantage, because they usually implement not their own compiler, but use the existing compiler of the JDK.
So, instead of implementing a full compiler, they only had to build a parser to realize the IDE features. This is of course much faster, and you can much earlier support for new language versions - up to early beta versions, as did IntelliJ for Java 8 .
In the case of Java Tooling, Eclipse has also joined by personnel challenges in the course of time, in addition to the technical challenges, as the JDT Core team has experienced big changes. It had to incorporate new people into the existing compiler implementation - which should not be underestimated.
Lastly, you should remember that the Java-8 support of Eclipse will probably be available on time for the official JDK8 release. think the Eclipse JDT team has, once again, done a really great job.
Does it make sense in the future for Eclipse to release its own compiler?
I think, yes. The compiler of Eclipse is an extremely good and very fast Java compiler that is unequaled by anything else. It enjoys a great reputation in the community and used not only within Eclipse, but also in a whole range of other products and projects as a Java compiler.
For example, Tomcat uses the Eclipse compiler to translate generated code (for example, JSPs). So it would already be a significant loss if this compiler would not be developed further. In addition, it offers significantly more features than the standard compiler. And these are features that I do not want to miss out on. The myriad static code analyses performed by the compiler are especially useful. Other compilers cannot compete.
I also believe that it’s useful from the perspective of Java language development, to have another compiler implementation that is completely independent. Gaps and /or ambiguities in the specification are detected quickly and can be discussed and resolved. Thereby errors can be found in the original javac compiler.
Not least, it would of course be a significant effort to convert existing Java Tooling in Eclipse to an external standard Java compiler such as javac (if it were at all possible ) - and makes little sense considering that, in going through the conversion, you would lose very useful features - instead of getting new ones.
What is the current state of development ?
The compiler implementation is as good as finished. In this area, bugs are still mainly fixes and minor additions are added. Thus, the IDE is able to understand Java 8 source code and compile, including the already self-evident features, ranging from syntax highlighting up to the Reconciling and error reporting. You can edit without problems any Java -8 -based source code with the IDE, compile and run – which, for lambda expressions, are not such an easy task as one might think .
In addition, a lot has happened in the UI area just lately, so now also content-assist and auto-completion work almost everywhere. And even lambdas, specific refactorings already work, above all the refactoring, with which you can convert Anonymous Inner Classes in lambda expressions (and vice versa). As a clean-up operation it’s a huge relief.
In addition to the lambda expressions, the new type annotations are interesting, and are already supported by the JDT. Types can be annotated much more flexible than previously. The standard case for this is the @ NonNull annotation that can be attached, for example, the type of the list elements of a collection now (as an example of a pluggable type system).
While only the actual mechanism is implemented in the standard JDK, Eclipse is already being implemented with ready annotations (for example @ NonNull ), which are reviewed by the Eclipse compiler. This feature was already in Eclipse Java 8, but has now become much more flexible with the Type annotation. By substituting these annotations consistently, you can save yourself a lot of null checks in code and rely instead on the compiler. A very useful compiler feature.
You are employed by Pivotal and SpringSource respectively . Where are exactly the benefits, for Spring in inserting Eclipse Tooling?
Our goal is to make the development of next-generation applications as simple and efficient as possible. Therefore we work ourselves alongside the Spring Framework in a whole range of other frameworks and libraries that make modern application development only really possible, such as Spring XD, Gemfire, RabbitMQ, Redis, and of course Cloud Foundry (to name but a few).
Besides the actual frameworks, libraries and runtime environments, there are also tools like IDEs which support the daily application development. Who wants to miss out on content assistance, refactoring support or JUnit integration today? And the more the IDE knows about the programming model and /or framework you use, the better support they can offer. The choice of IDE is often a matter of taste. Some developers swear by IntelliJ IDEA, while others prefer Eclipse. In both cases, they should get the best possible support for working with Spring.
While Jetbrains and Spring support IntelliJ and Oracle take care of the Spring support in Netbeans we are focusing our work on the Eclipse IDE - eventually the most widely used IDE in the Java-sphere should offer excellent support for Spring too ( laughs). That way, the users of various Eclipse distributions can benefit from the Spring tooling too.
Moreover, we benefit from the collaboration of different companies within the Eclipse community. The Eclipse IDE provides an excellent platform on which to base different firms may implement different components, which are then joined into a comprehensive IDE. While we implement the Spring tooling, other groups, for example, work on the Maven integration in Eclipse and WTP. Finally, everyone benefits: both the user who receives an extensive IDE in the hands, as well as the developers of the IDE who also mutually benefit.