Quick view from the inside

Eclipse Oxygen: This is what Eclipse Foundation officials say about it

Dominik Mohilo
Eclipse Oxygen

© Shutterstock / assistant

Today is the big day — Eclipse Oxygen is here. We’re excited to see the new features and changes that are happening in the Eclipse ecosystem, so we talked to Wayne Beaton and Mikaël Barbero about the 12th official simultaneous release.

This year’s Eclipse Oxygen is the 12th official simultaneous release. According to the project description, “it includes the hard work of 83 open source projects, comprising approximately two million net new lines of code.The output of this process is a composite repository of open source software and a new release of the Eclipse IDE. The Eclipse Oxygen release includes many improvements in functionality and performance, includes new tools for Java™ code coverage analysis, and can be extended to support Java 9 development via an early access preview.”

We’re all excited to give Eclipse Oxygen a warm welcome but we’re not the only ones eager to see how the public receives it. Read on to find what Wayne Beaton, Director of Open Source Projects and Mikaël Barbero, Senior Platform Developer think of the 12th official simultaneous release.



Wayne Beaton works for the Eclipse Foundation where he fills the dual roles of Director of Open Source Projects and Evangelist.

Mikaël Barbero is a Senior Platform Developer at the Eclipse Foundation.

JAXenter: The newest Simultaneous Release, Eclipse Oxygen, is hitting General Availability. Every release is special in its own way but what makes Eclipse Oxygen stand out?

Wayne Beaton: It’s a challenge for me to pick any one new feature. The Eclipse Oxygen release will certainly contain some useful goodies for Java developers, including support for JUnit 5. Plus, the Eclipse EclEmma Project which recently moved to the Eclipse Foundation, adds Java code coverage analysis “out of the box”.

Mikaël Barbero: From my perspective, it is the first release in last few ones where the Java tooling actually significantly improves. There is now code coverage tools integrated into the tooling (thanks to EclEmma The Java debugger has seen useful new features being added (tracepoint, trigger breakpoint, last method call return value in variable view…). This is good news for everyone out there who use Eclipse for Java development.

JAXenter: From your perspective, what was the most challenging thing about this summer’s Release Train?

Wayne Beaton: I’ll admit that David Williams retiring from his role as the Eclipse Planning Council chair has been pretty stressful. David used to take care of both the management and release engineering aspects of the simultaneous release. We split those roles, with the Eclipse Foundation’s Fred Gurr taking on the release engineering role, and me taking on the management aspects. Fred’s done a great job with the transition, and I’m getting a lot of great help from the community.

This is the first release in last few ones where the Java tooling actually significantly improves.

Mikaël Barbero: Surely it is the departure of our David Williams, the former planning council head and release train manager. He has been responsible for the release train for almost as long as it exists. This has forced the community to take more responsibility and not only rely on David’s diligence. The Eclipse Foundation also is now more actively participating in the actual simultaneous release build in the person of Frederic Gurr, who has taken part of David’s responsibility in term of release engineering and project coordination.

JAXenter: Java EE 8 —and later on Java 9— is fast approaching. What does this mean from the Eclipse perspective and especially from the perspective of the JDT?

Wayne Beaton: We really wanted to make Java 9 support available in the Eclipse IDE at the very same moment that Java 9 was itself released.

Licensing restricts how implementations based on draft versions of the specification can be distributed. From a legal point of view, we’re not allowed to include our beta builds of the JDT Java 9 support in the Eclipse Oxygen builds and, by extension, the products based on that repository. This limits our ability to test the implementation and drive the feedback loop that exists for the rest of the functionality from the simultaneous release. As it stands, only those users who specifically install the Java 9 Support (BETA) for Oxygen from the Eclipse Marketplace are able to test and provide feedback.

SEE ALSO: Eclipse Oxygen: A better workflow for editing in Sirius [Interview with Mélanie Bats]

The Eclipse Planning Council had discussed possibly moving our own release date to align with the anticipated Java 9 release date, but this was rejected. The biggest concern was the testing problem, but there was concern over whether or not the Java 9 team will meet their deadline —which didn’t happen. For what it’s worth, maintaining the discipline of releasing on time in June every year was only a very minor factor in the decision.

Mikaël Barbero: First you have to distinguish what you mean by Java 9 support: the fact that Eclipse runs on a Java 9 JRE and the development tooling to let you create applications using specificities of Java 9 (e.g., the Java Platform Module System). Regarding the former, Eclipse Oxygen already runs perfectly well on Java 9. Projects have been doing testing with Java 9 for quite some time. 

The Eclipse Oxygen release will certainly contain some useful goodies for Java developers, including support for JUnit 5.

The Java 9 support by the Java Tooling work has started for a long time now. Unfortunately, we can’t release it at the same time as Oxygen. The Java 9 specification is not released yet and it is not allowed (by license restriction) to release an implementation before the specification is final. JDT being an implementation of this specification (through its compiler Eclipse Compiler for Java – ECJ), it makes the whole thing tricky. The current discussions within the community are in favor of keeping the Oxygen release end of June and to provide an update with Java 9 support on day 1.

JAXenter: Again, over 80 projects are included in the SR. Which one is the most promising?

Wayne Beaton: Multiple participating projects are doing work with the Language Server Protocol. The obvious ones are the Eclipse LSP4J and Eclipse LSP4E projects which provide frameworks for building language server implementations in Java and in the Eclipse IDE specifically. I’m not sure what specific functionality is going to be offered in the Eclipse Oxygen release, but the Xtext and PHP Development Tools projects are also doing some language server work.

We also have a new project that’s not officially part of this year’s simultaneous release, the JDT Language Server project that provides a language server implementation of the Java programming language based on the JDT.

At this point, we’re planning a special extra release that includes updates from participating projects that are specifically concerned with Java 9 support.

JAXenter: The succeeder of Oxygen will be Eclipse Photon. What would you like to see in the next release?

Wayne Beaton: The groundwork that our project teams are laying out with their various language server implementations should provide the foundation that we need to include direct support for more programming languages.

It’ll be interesting to see the sorts of tools that get built to support Java 9 development. At this point, the JDT team is providing fundamental support; it will be interesting to see what tools are developed based on needs discovered when developers start doing real work with it.

Mikaël Barbero: One of the great trends that the community is embracing is the Language Server Protocol. Its support in Eclipse will be implemented in Oxygen and I am looking forward to seeing it being leveraged by several language servers. It will help Eclipse become much more polyglot with hopefully support for Typescript, Rust, Go and so on.

JAXenter: Thanks to the Eclipse Photon name, the 2018 Simultaneous Release has a catchy nickname once again. Does this mean that changing the name of Eclipse releases to something like “Eclipse 2018.1” is off the table?

Wayne Beaton: The Eclipse Committer Community is divided on whether or not we should drop the catchy nickname in favor of adopting a date or number-based naming scheme. In the absence of consensus on the matter, the Eclipse Planning Council has opted to maintain the status quo. I’m confident that our strategy isn’t going to change for the Photon release, but am certain that the discussions will continue.

Mikaël Barbero: The discussions are still happening within the community and no decision has been made yet. There are pro and cons on both sides. What is sure is that even if we decide to switch to something like “2018.1”, Photon codename will still be used internally to talk about the next-after-Oxygen simultaneous release.

SEE ALSO: Eclipse Two: “I want to use Electron as a vehicle to rethink the IDE experience” [Interview with Doug Schaefer]

JAXenter: Doug Schaefer is working on a new kind of Development Environment, “Two“. It is based on web technologies, something he says the Eclipse IDE lacks. Do you agree with him?

Wayne Beaton: Doug has lots of great ideas and I’ve learned not to argue with him.

JAXenter: Doug also plans to propose this development environment as an Eclipse project. What are the odds of Eclipse Two actually happening?

Wayne Beaton: Whether or not Doug’s efforts end up being an open source project at the Eclipse Foundation is really up to Doug and his ability to grow a community around his efforts.

Thank you very much!

Dominik Mohilo
Dominik Mohilo studied German and sociology at the Frankfurt University, and works at S&S Media since 2015.

Inline Feedbacks
View all comments