As a project deeply integrated with Eclipse JDT, Xtext has sometimes also to use internal API. This is, for example, necessary to leverage best performance of accessing Java elements. We try to avoid this whenever possible sometimes even by duplicating the code, and we never faced a problem for several years in this regard.
This October Eclipse released Oxygen.1a, which added Java 9 and JUnit 5 support to the recently released Oxygen.1 release. Java 9 support was a major effort for the JDT team and the fast availability to Eclipse users right after release of Java 9 last month proves the vibrant nature of Eclipse projects and the enthusiasm developers put into their projects. And naturally this feature required some major changes to JDT’s internals.
One of these refactorings lead to a signature change in one of JDT’s internal methods that Xtext makes use of. This is a small change, but crucial for Xtext users. All current productive versions of Xtext including Xtext 2.12, which participates in the Eclipse Oxygen release train, are compiled against this method and Xtext plugins would fail when running on JDT when this method would not be available in the specific signature.
At itemis we care about quality of the Eclipse projects we are involved in. A very valuable source information for us is the Eclipse Automatic Error Reporting System (AERI). We actively scan reports there, since these are real issues real users have out there. Without AERI, the hurdle to report problems was rather high: You need an Eclipse Bugzilla account, find the right category and describe manually your problem. Many issues were not reported then. Now it is just one click to automatically submit a report. And the more users report the same issue, the more prominent this is shown to us developers.
On Monday before the final release candidate there was suddenly a report on a linking problem, which showed the following excerpt in its stack trace:
java.lang.NoSuchMethodError:
org.eclipse.jdt.internal.core.JavaProject.computePackageFragmentRoots
(Lorg/eclipse/jdt/core/IClasspathEntry;Lorg/eclipse/jdt/internal/compiler/util/ObjectVector;Ljava/
util/HashSet;Lorg/eclipse/jdt/core/IClasspathEntry;ZLjava/util/Map;)V
at org.eclipse.xtext.common.types.access.jdt.JdtTypeProvider.collectSourcePackageFragmentRoots
(JdtTypeProvider.java:539)
From time to time there are similar reports, which usually indicate faulty configurations like a version mixture of Xtext bundles. AERI reports contain some information on the available bundles and their versions in the execution environment, which help identifying the context of the problem. Now this one was strange: It showed the version 3.1.50 of bundle org.eclipse.jdt.core installed. This version was unknown to us – Eclipse Oxygen.1 was delivered with version 3.1.0.
As we detected this problem it was my itemis colleague Christian Dietrich who immediately got into contact with the JDT team to discuss this issue and raised Bug#525462. Stephan Herrmann from the JDT team, also an active Xtext user, and Dani Megert worked with us to address this issue. Finally, it was decided together that the missing method would be added again. The release of Oxygen.1a was already in progress, and developers were informed through the cross-project mailing list about this important issue.
Fortunately the Eclipse Platform team agreed to respin the whole Oxygen.1a simultaneous release. There were two other issues with the JDT and Maven tooling, and these problems are solved with the Oxygen.1a release before all users are affected.
We from the Xtext team will now carefully review and reduce internal API usage and work together with the JDT team to find proper replacements or evolve suitable public API where it is missing. Thanks to Christian the issue was immediately resolved in Xtext’s source, so that upcoming Xtext 2.13 already does not use this specific internal API anymore.
Since Xtext is used in many different release versions out there it will take time until the internal API is not used by external users anymore even though the code base will be clean soon. Further we will discuss internally and across teams at EclipseCon how we can detect such situations even earlier. In the past we had builds running against several Eclipse versions, but you can imagine that maintaining this costs a lot of resources both from developers and build servers. If we want to make sure we're meeting our high support requirements there may not be another way, though.
At the time when the problem was detected there were 15 reports of this problem in AERI. While this may sound like much it is actually not a high number by comparison. Let's assume the case that Oxygen.1a went live without detecting this. Every single Xtext user would have been affected. It is thanks to people like Christian, Stephan and Dani that a major disaster was avoided. This again shows the great collaboration at Eclipse across projects and across companies.
Speaking of Xtext 2.13, the Xtext team itself is in its final release phase and we’ll release on October 20th, just in time for EclipseCon Europe in Ludwigsburg! If you are attending EclipseCon and have questions on the new release, the future of Xtext or just want to drink a beer with us, come to the itemis booth (booth 13) or later to the bar at Nestor hotel. We can be bribed with a beer to share valuable internal insights and tips for you... :)
After this EclipseCon and Xtext release we are not going to rest a moment and will continue to make Xtext even better and improve its usability, stability and performance. Note that our Xtext team at itemis offers Professional Support Services for Xtext. Don't hesitate to reach out to us for your project, as I'm certain that together we can make your project even more successful!