Move batch compiler to Java 17, drop Java 11 runtime support

[iloveeclipse]

In context of #883 org.eclipse.jdt.core bundle will be moved to Java 17, it is unavoidable.

Note: Eclipse 4.28 already stopped supporting Java 11, see eclipse-platform/eclipse.platform.releng#200.

Because of the separation of batch compiler from jdt core we could in theory continue to support Java 11 in org.eclipse.jdt.core.compiler.batch project, so it could be still used in a standalone environment with Java 11.

However I do not see any reason to do so.

The reasons for switch to Java 17 runtime are:

• there are no tests running on Java 11 anymore. So we could have already broken ecj because of some runtime issue we don't see on Java 17 / 19.
• use latest Java language features that simplify our life: records, instanceof pattern, etc in compiler code itself
• use latest available JDK libraries, example: this one line using Java 17 was a complex method with 40 lines in Java 8!
• simplify our life maintaining compiler source code configuration, build, test etc - all the jenkins/maven/github/ whatever configurations where we should simply reuse solutions we would have with default platform improvements we see every day.
• basically: save our time.
• Our development work would only benefit from Java 17.

So I propose to update org.eclipse.jdt.core.compiler.batch project settings for 4.28 M1 and require Java 17 for running batch compiler as a result.

Notes:

• Consumers that need ecj running on Java 11 can use older versions.
• Compilation targets will not affected by that, ecj will still support compilation down to Java 8 JLS.

If anyone has any reasonable objection, please comment.

Please cast your vote here: #888

[trancexpress]

Should this be also an e-mail to jdt-dev@eclipse.org?

[iloveeclipse]

Should this be also an e-mail to jdt-dev@eclipse.org?

Yep, I did that.

[jarthana]

Because of the separation of batch compiler from jdt core we could in theory continue to support Java 11 in org.eclipse.jdt.core.compiler.batch project, so it could be still used in a standalone environment with Java 11.

However I do not see any reason to do so.

* Consumers that need ecj running on Java 11 can use older versions.

What if consumers (for e.g Apache Tomcat) want ECJ to be run with JDK 11 but still able to code in Java 20 and above?

[iloveeclipse]

What if consumers (for e.g Apache Tomcat) want ECJ to be run with JDK 11 but still able to code in Java 20 and above?

Well, as before: anyone who wants support for latest Java version syntax running on oldest Java runtime has an option to patch & embed JDT (ecj) code, now (with 4.27) it is easily possible because the compiler code is cleanly separated from the rest of JDT.

The problem is not of a technical nature, it is a problem of resources allocation and investment decisions, so it is all about money at the end.

If someone has "extra" requirements for JDT (ecj) this someone can decide to spent time by contributing to JDT or spend time by patching JDT in a private fork. This choice is and was always there, and (I guess) many companies take the latter road, which is not nice, but that's life and we can't change that, because it's not our money.

I personally have no interest wasting my and my team time (and my company money) supporting older Java runtimes if a higher LTS Java version is already available since two years.

[jarthana]

What if consumers (for e.g Apache Tomcat) want ECJ to be run with JDK 11 but still able to code in Java 20 and above?

Well, as before: anyone who wants support for latest Java version syntax running on oldest Java runtime has an option to patch & embed JDT (ecj) code, now (with 4.27) it is easily possible because the compiler code is cleanly separated from the rest of JDT.

My question was about moving the compiler.batch to Java 17. I see no compelling reason to do that yet. As long as the limitation doesn't come from JDT itself, we should keep the batch compiler at 11.

[trancexpress]

My question was about moving the compiler.batch to Java 17. I see no compelling reason to do that yet. As long as the limitation doesn't come from JDT itself, we should keep the batch compiler at 11.

Why was it moved to 11 from 8 then?

[jarthana]

My question was about moving the compiler.batch to Java 17. I see no compelling reason to do that yet. As long as the limitation doesn't come from JDT itself, we should keep the batch compiler at 11.

Why was it moved to 11 from 8 then?

There were years of difference and lot of language features between Java 8 and Java 11. But I don't see that between Java 11 and 17. And JDK 11 is still under support from Oracle.
Besides, I find it hard to believe that everyone would have already moved to 17. Going by my same old example, I don't see Tomcat moving to Java 17 any time soon.

[trancexpress]

And JDK 11 is still under support from Oracle.

Doesn't JDK 11 support end in September? And after that only security fixes will be made available.

[jarthana]

And JDK 11 is still under support from Oracle.

Doesn't JDK 11 support end in September? And after that only security fixes will be made available.

Right. So, I fail to understand the logic. Why should Eclipse stop supporting an active Java version?

[trancexpress]

Right. So, I fail to understand the logic. Why should Eclipse stop supporting an active Java version?

I don't understand this logic. Java 8 support ends in 2030, maybe it will be extended even after that. Why can't I run ecj on Java 8? It would not surprise me at all if most of Java users have not moved beyond Java 8 yet.

[iloveeclipse]

So, I fail to understand the logic. Why should Eclipse stop supporting an active Java version?

Note: Eclipse 4.28 already stopped supporting Java 11, see eclipse-platform/eclipse.platform.releng#200

I see no compelling reason to do that yet. As long as the limitation doesn't come from JDT itself, we should keep the batch compiler at 11.

The reasons are:

• there are no tests running on Java 11 anymore. So we could have already have broken ecj because of some runtime issue we don't see on Java 17 / 19.
• use latest Java language features that simplify our life: records, instanceof pattern, etc in compiler code itself
• use latest available JDK libraries, example: this one line using Java 17 was a complex method with 40 lines in Java 8!
• simplify our life maintaining compiler source code configuration, build, test etc - all the jenkins/maven/github/ whatever configurations where we should simply reuse solutions we would have with default platform improvements we see every day.
• basically: save our time.

I strongly believe that JDT suffers from very limited resources of qualified contributors. saving our time by the points above we can invest in better support for Java 17/18/19/20/21 etc.

Besides, I find it hard to believe that everyone would have already moved to 17.

I find it is hard to believe everyone will need compilation for Java 20 JLS staying at Java 11 runtime. That is really not a mainstream case.

Going by my same old example, I don't see Tomcat moving to Java 17 any time soon.

That's fine. Tomcat can stay at Java 11 as long as they like, and if there will be a request for Tomcat to support Java 20 compilation on top of Java 11 runtime, this can be done by Tomcat or by the company which requires that "feature".

Also look: the Tomcat will argue same way: look, JDT is still supporting Java 11, why should we move to 17? With that, both projects will stay on java 11 forever? Surely not.

[iloveeclipse]

One more argument: there are no tests running on Java 11 anymore. So we could have already have broken ecj because of some runtime issue we don't see on Java 17 / 19.

[jarthana]

Right. So, I fail to understand the logic. Why should Eclipse stop supporting an active Java version?

I don't understand this logic. Java 8 support ends in 2030, maybe it will be extended even after that. Why can't I run ecj on Java 8? It would not surprise me at all if most of Java users have not moved beyond Java 8 yet.

I thought you made it clear that security support was not good enough?

The reasons are:

* use latest Java language features that simplify our life: records, instanceof pattern, etc in compiler code itself

* use latest available JDK libraries, example: [this one line](https://github.com/eclipse-pde/eclipse.pde/blob/8893c7e677e8fb4848e2e75c38e2e259810652e0/ui/org.eclipse.pde.ui.tests/src/org/eclipse/pde/ui/tests/project/ProjectCreationTests.java#L1486) **using Java 17**  was a [complex method with 40 lines](https://github.com/eclipse-pde/eclipse.pde/blob/eaf462c977ca3a1f2e1ef4226f0ba17ec9c8cdab/ui/org.eclipse.pde.ui.tests/src/org/eclipse/pde/ui/tests/project/ProjectCreationTests.java#L1486) in Java 8!

* simplify our life maintaining compiler source code configuration, build, test etc - all the jenkins/maven/github/ whatever configurations where we should simply **reuse** solutions we would have with default platform improvements we see every day.

* basically: **save our time**.

Those are good reasons, but as developers of tools used by lot of people, I would rather put my users above my own needs.

One more argument: there are no tests running on Java 11 anymore. So we could have already have broken ecj because of some runtime issue we don't see on Java 17 / 19.

Probably the most forcing factor, but that's only because we didn't care enough about older platform more.

[trancexpress]

I thought you made it clear that security support was not good enough?

Sorry I misremembered Java 8 active support getting extended until 2030.

[jarthana]

Note: Something I tried in the past but didn't bother to complete was to move all test bundles up and start using all the language features in the test bundles. This is something we can do without affecting the consumers of batch compiler.

[akurtakov]

As there are 2 PLs disagreeing please follow the procedure as described at https://github.com/eclipse-platform/.github/wiki/PMC-project-guidelines#committer-disagreement-resolution - ask for PMC resolution/decision is the next step. Alternatively, you may decide to have a vote between JDT committers.

[iloveeclipse]

I would rather put my users above my own needs.

Sure, this is noble.

But what about majority of our users that suffer from gazillions of existing compiler bugs we already have, for all possible Java releases / JLS specifications we support? Shouldn't we spend our time to support them too?

Probably the most forcing factor, but that's only because we didn't care enough about older platform more.

So please answer to a simple question: why don't we care enough about older platform?

• Surely not because we don't care about users.
• Also not because we can't do this technically.
• Also not because we are all lazy or too stupid to do the "right" thing.

So what else is the problem?

Isn't our time limiting factor here?

If I would have a team of 10 capable people that are familiar with JDT code, wouldn't I spend time to setup and maintain couple of build jobs, monitor that on regular base, create reports, fix issues etc? Sure would I! But I don't have a team of 10 capable people that are familiar with JDT code.

Where are all the people that monitor JDT bug tracker for incoming bugs, monitor test failures on all supported platforms, fix all the build issues we have, review incoming PR's, adopt build files, create build jobs on jenkins, migrate wiki documentation, implementing latest JLS specs etc?

That must be for sure a huge team working on all that in JDT? Surely over 10 people, at least 20 I guess?
In reality we have about 4 active committers, and from my team we don't have anyone doing this full time anyway.

The times where we could allow us the luxury of supporting every corner case in JDT are gone!

The more important question today if and for how long JDT will stay maintainable at all, not if we can support some older XYZ Java runtime.

[vogella]

In reality we have about 4 active committers, and from my team we don't have anyone doing this full time anyway.

Also IIRC Redhat is thinking about forking JDT if development in JDT is slowed down.

[jarthana]

So, are we saying that moving the compiler to Java 17 will solve all the problems that are being discussed? Of course, not. In my opinion, moving to Java 11 itself was big step for JDT. Did it really make things better for anyone? I would probably compare this with "moving to github" was being touted as "the thing" that will bring us tons of contributors. And I am still waiting to see it happen.

There is no ideal solution here. We need to strike a balance. . But keep moving super aggressive at the cost of our consumers is something we must avoid at any cost.

[kriegaex]

AspectJ uses a regularly refreshed fork of JDT Core and was forced to not so long ago require Java 11 as a compile-time minimum for its users, many of which enjoyed the fact that they could still run both their legacy and current builds on older JDKs.

Now, the same sort of ripple effect would affect AspectJ users again. They cannot just use an older ECJ, if they want to use an up-to-date AspectJ compiler.

Of course, the JDT Core team can just shrug and decide to bump the Java version anyway, because AspectJ's problems are not their own ones. But you asked for feedback, and our projects are siblings (in the sense that both are Eclipse projects). We have a dependency on JDT Core and want to make it transparent to you. Our development team is even smaller (basically just me at the moment, doing 95% of the commits, plus project lead @aclement for doing the really tricky stuff in urgent cases). Maybe you can understand my reluctance towards the version bump. But alas, I know I cannot stop you and would migrate too, if forced to.

[ericwill]

In reality we have about 4 active committers, and from my team we don't have anyone doing this full time anyway.

Also IIRC Redhat is thinking about forking JDT if development in JDT is slowed down.

This is not true and does not match what I have communicated publicly [1] [2]. Our strategy is centered around JDT and Java tooling, and we are looking to make improvements in JDT to create a better development experience to the benefit of adopters and other consumers of JDT. This proposed change is one of those improvements, by the way. Other examples of improvements would be things like investigating a javac based parser, and things like the JDT-LS client for Eclipse.

It's unfortunate that we are wasting so much time discussing this change here when there is an established process to resolve this, as Alex has mentioned.

[iloveeclipse]

It's unfortunate that we are wasting so much time discussing this change here when there is an established process to resolve this, as Alex has mentioned.

I've sent a mail to PMC (and CC to JDT dev).
So now PMC can start wasting time :-)

[akurtakov]

It's unfortunate that we are wasting so much time discussing this change here when there is an established process to resolve this, as Alex has mentioned.

I've sent a mail to PMC (and CC to JDT dev). So now PMC can start wasting time :-)

The goal when this procedure was written down was to exactly reduce the time spend on "philosophical" discussions which I know are fruitless as no one ever managed to convince someone else on such topics in my experience. Thus it's best to just call a vote, some opinion wins by majority vote and we move on.

[iloveeclipse]

So, are we saying that moving the compiler to Java 17 will solve all the problems that are being discussed? Of course, not.

Sure not. Look, I spent now lot of time trying to understand eclipse-jdt/eclipse.jdt.ui#484. One of possible solutions was to just move everything related in JDT to Java 17 and be happy. I could avoid spending my time investigating that as possible root cause if we would be already on Java 17 and the actual reason would be some stupid ant bug or whatever else.

In my opinion, moving to Java 11 itself was big step for JDT. Did it really make things better for anyone?

For users, for sure, because we could at least say that we have tested on Java 11 and we are confident it will run on Java 11, which we couldn't do anymore for Java 8.

I would probably compare this with "moving to github"

Well, the move to github was forced because Eclipse foundation doesn't see any sense spending resources for maintaining old bugzilla server. Doesn't it sound familiar?

was being touted as "the thing" that will bring us tons of contributors. And I am still waiting to see it happen.

Me too, but as honest as I am I haven't put the point with new contributors to the list here, all what I want to achieve here is to save time for still existing contributors :-)

Thus it's best to just call a vote, some opinion wins by majority vote and we move on.

I will try to create a poll using "Discussions" github feature we have now.

[vogella]

This is not true and does not match what I have communicated publicly [1] [2].

I think the point I was referring too, was:

It will also help guide our decisions about what projects to invest in, which areas will be a pain-point for our team, and whether better opportunities should be pursued.

Sorry for misremembering this. But "better opportunities should be pursued" would still be very bad for Eclipse/JDT, maybe even worse than a fork which could at some point re-integrated.

[iloveeclipse]

I've created #888

[iloveeclipse]

Current state 😃

[vogella]

was being touted as "the thing" that will bring us tons of contributors. And I am still waiting to see it happen.

Me too, but as honest as I am I haven't put the point with new contributors to the list here, all what I want to achieve here is to save time for still existing contributors :-)

If JDT really wants to have new people they should check who is contributing and nominate them as committer. It personally makes me sad to see that we have active people providing more than 50 or 100 patches to JDT and not getting nominated as committers AND hearing that you complain about not enough people joining the project.

[brychcy]

Consumers that need ecj running on Java 11 can use older versions.

What about users that just need a bug fix?
Simply running a maven build with a newer major java version has never worked for me for non-trivial projects.
Do you intend to start making bug-fix releases for older ecj-versions?

(Just thinking about how this might look for users - I've never used ecj in a maven build)

[iloveeclipse]

Consumers that need ecj running on Java 11 can use older versions.

What about users that just need a bug fix?

Checkout whatever old branch you want, fix your bug & build.

Simply running a maven build with a newer major java version has never worked for me for non-trivial projects. Do you intend to start making bug-fix releases for older ecj-versions?

Not sure how that is related to the proposed change, but as said above: checkout old version with a bug, patch and build.

Note: Eclipse (and so JDT) stopped to provide maintenance builds many years ago.

[brychcy]

So are you saying: users that use ecj in a maven build and need a new ecj version because of a bugfix and can't simply update the build to run with java 17, should instead themselves backport the ecj fix and build and use their own version of ecj? Hmmm

[iloveeclipse]

Till, same applies to:

• users that use ecj in a maven build and need a new ecj version because of a bugfix and can't simply update the build to run with java 11
• users that use ecj in a maven build and need a new ecj version because of a bugfix and can't simply update the build to run with java 8
• and so on.

Why don't we support them all?

Java 17 is LTS since two years, Java 21 will be LTS in this year. At some point in time one have to stop supporting ancient Java versions. Anyone who complains about that, is welcome to contribute to JDT/Eclipse maintenance. Unfortunately there are only a handful of people doing so.

[brychcy]

Well there is a clear difference:

I think everybody assumes Java 11 LTS is still in (normal) support at least until September 2023 because that is what Oracle announced, when it was released - see also https://www.oracle.com/java/technologies/java-se-support-roadmap.html

And actually Java 17 LTS is not two years old yet, it was released 14 Sep 2021, see https://www.oracle.com/news/announcement/oracle-releases-java-17-2021-09-14/ .

[trancexpress]

@iloveeclipse , can you link the main motivation for the JLS 17 move? If anyone wants to look into fixing the issue without moving ecj to JLS 17, that would work too from my POV? Then we can delay the move to e.g. September. When Java 11 LTS expires.

[iloveeclipse]

@trancexpress : there is no one issue that requires transition to Java 17, there is a constant stream of issues in the platform that require our time and one has to prioritize which one to fix. Since there are not many people spending time on such boring work like bug triage, test and build maintenance, the only approach that can work is to reduce the effort. Switching every project that contributes to SDK to Java 17 reduces the platform maintenance effort.

Current example of such boring work is eclipse-jdt/eclipse.jdt.ui#484.
TL;DR : all recent SDK 4.28 builds are coming with broken Help. One idea was that the help build problem was caused by partial SDK project move to Java 17. So I've updated JDT UI to Java 17 via thisPR and we see that most of errors disappeared. I've spent lot of time trying to reverse engineer platform help build process - and this is exact the time I can't spend on reviews in JDT core.

That's the trade off and a problem I see every single day.

Those who don't see this problem most likely are only interested in ECJ or some custom application bug fixes, but they forget that without running tests and stable platform JDT will be not maintainable anymore pretty soon.

Anyway, I don't think ECJ move will fix the help build issue above, but it is possible because no one could explain yet how the move of JDT UI to Java 17 "fixed" few thousands of javadoc errors.

And now to something completely different.

PMC also discussed this issue and we have a "go" to move ECJ to Java 17, see https://www.eclipse.org/lists/eclipse-pmc/msg04129.html

The voting on project discussulions also shows 2/3 majority for the move.

=> I plan first to move JDT debug to Java 17 and then start with ecj.

[vogella]

=> I plan first to eclipse-jdt/eclipse.jdt.debug#218 and then start with ecj.

Looks like debug is done.