Iterating all the time

Java 8 support in Eclipse

Diana Kupfer
8-e

Martin Lippert talks about the latest Java release and the ups, downs, and aspirations of Eclipse IDE development.

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.


 

 


Author
Diana Kupfer
Working at S&S Media since 2011, Diana Kupfer is an editor at Eclipse Magazine, Java Magazin and JAXenter.de.
Comments
comments powered by Disqus