BREE 17 -> 21

[jukzi]

Update all plugins that are currently BREE 17 to 21.

syso("Hello java/util/SequencedMap")
syso("Bye bye java.lang.Compiler") // just random examples of breaking changes

Objections? I don't have any special usecase, but probably it is more a question of when.

[merks]

What great new features of Java 21 will we generally want to use in lots of places?

[tjwatson]

I second Ed's question. I have never be for blanket updates in dependencies for no immediate reason.

[laeubi]

Great or not. for me such mass changes are not really "OSGi like" if nothing is used, so I simply would discuss/change that once there is a feature I want to use from java 21, that's much easier as one the can see the benefit, and maybe think about alternatives.

[Bananeweizen]

We just updated an internal 500 kloc application to 21, because we are heavy users of the visitor pattern and want to use switch expressions and pattern matching with instanceof instead. If you don't need that, there are far less new features than when going from 11 to 17. I'd therefore vote for compatibility, not developer happiness, in this case.

[mickaelistria]

I agree that bumping a requirement without code requirement is probably not the best thing (unless there are major improvement in the generated bytecode performance). Usually, a better approach is to find pieces of code that get better using Java 21, and submit PRs to use the new constructs/API and bump BREE by the way.

[ruspl-afed]

Not all the current SimRel participants have enough resources to rework implementation if something is no longer available in Java 21. This means that at some (very late) point we can have surprising runtime failures with no good way to solve them.
Before switching Platform to Java 21 (that effectively means switching the majority of SimRel participants) there should be a period of Java 21 evaluation in the scope of SimRel for "leaf" contributions.

[laeubi]

Java 21 is the next LTS so it will come sooner or later, if there is any API incompatibility this will mean an application won't run anymore on Java 21 and as and as mentioned in the mailinglist post EPP will ship Java 21 JustJ right after 2024-03 release!

We should just face the fact that Java is evolving and no one will wait for Eclipse, so either adapt (this is not really a migration) or leave, there is not much in between!

[ruspl-afed]

and no one will wait for Eclipse, so either adapt (this is not really a migration) or leave, there is not much in between!

Thank you for supporting my claim that this is a survival game. I understand that hiding from Java evolution is not a vital strategy.

My question is: should we figure out how to help small passengers of SimRel to adapt or should we just let them leave the train, since there is not much in between?

[laeubi]

The SimRel is all about adaption and integration platform can for sure help here in giving guidance on this, maybe even lead in this regards while I have the feeling that last time we moved from 11 > 17 it wasn't any issue and "just worked"... so if there are any technical challenges we can evaluate them here and then others might follow this but in general one should be aware that:

1. "Platform" is also mostly driven by a small amount of enthusiasts and some working partly on it and even less that really work fulltime (if any).
2. Any technical concerns / problems can be discussed and analyzed, vague things like "oh no please don't change anything" are likely hard to address.
3. As a last consequence a project might leave the train, it is not a perquisite for other projects to only use code in the train especially in platform we use more and more code from even not eclipse projects.
4. So this is still not the end of the world and if small projects better invest their time elsewhere and do less frequent releases that's maybe an better option that trying hard and not be able to focus on their key values

So if in doubt, I would just right now change the build jvm of my project to Java 21, see what happens and decide from that and keep in mind that the next Java LTS (Java 25?) is just around the corner :-)

[ruspl-afed]

Thank you for such a detailed answer.
Please don't get me wrong, my question was not aimed to get psychological help, but to find if we can make our life easier.

I would just right now change the build jvm of my project to Java 21

Do you think we can have an automation here supported? May be (auto)forking a job on JIPP side and trying to do an (auto) build with new JVM[/Maven]?
I understand it may be not trivial for some cases, and Job may need to be adapted to be used in this way. But it's better to strain yourself once and tune automation than constantly suffer from endless changes.

[laeubi]

It depend on the Job config, but for example take this repository https://github.com/eclipse-platform/eclipse.platform one would create a new branch (e.g. name it java-21) and then on that branch edit the Jenkinsfile and replace

tools {
	maven 'apache-maven-latest'
	jdk 'openjdk-jdk17-latest'
}

with

tools {
	maven 'apache-maven-latest'
	jdk 'openjdk-jdk21-latest'
}

then once in a while in the github Ui you can simply choose "update branch" and it will get merged your changes from main/master, thats not fully automated but an easy way to just see what happens.

[vogella]

As simrel moves to Java 21, I vote for allowing platform also to move to Java 21. This would align our development environment with the user environment.

[vogella]

Another reason why we should allow a BREE of Java 21 is that this would allow use to "eat JDT 21 dogfood". JDT Features that have not been used by us were relatively buggy in the past, for example the clean-up actions only got stable / usable after we started to apply them ourselves and bugs were identified and fixed.

[tjwatson]

The lack of proper JDT tests to cover the dogfooding is not a good reason to place a Java 21 min to run the IDE because we decided to update a few of the components to mandate Java 21+

[tjwatson]

Supporting Java 21+ at runtime vs. requiring Java 21+ at runtime are two different things entirely. I only mention that because this discussion confuses me with exactly what is being discussed.

It is obvious that Eclipse must support running on Java 21+ so I naturally thought this complete discussion was only about should we require, as a minimum, running on Java 21+. To that my answer is only if there is really a feature required by the platform that is only in Java 21+. Blanket moves to requiring Java 21+ do not make sense to me with no real use of anything that is only in Java 21.

[merks]

That question was answered in that thread, but you asserted that the answer provided only a workaround . Or it's just a bug that should not happen in the first place, making the question moot.

[laeubi]

The EE directly maps by PDE to some project settings of JDT that setup the source and target options and these directly instruct the compiler to compile for a given target release and it must be compatible with that, if that do not work it is a bug of JDT.

One such bug is for example this one:

• StringConcatFactory can not be resolved eclipse-jdt/eclipse.jdt.core#1842

The target release is 8 but it seem JDT is still using StringConcatFactory what is a java 9 feature, but this is nothing to blame on Java or an EE :-)

[jukzi]

Or it's just a bug that should not happen in the first place, making the question moot.

I can't say for sure if it is either way, but until such problems are solved in any direction i just don't feel confident that we can support multiple JDK versions in good conscience.

[laeubi]

Or it's just a bug that should not happen in the first place, making the question moot.

I can't say for sure if it is either way, but until such problems are solved in any direction i just don't feel confident that we can support multiple JDK versions in good conscience.

We already do so (e.g. equinox has some at JDK 1.8) ...

[merks]

If one wants to ease one's conscience, one could set up the SDK IDE to install JustJ 21 (or use your own JDK 21) using the installer and then you will be testing most everything all day everyday with Java 21.

[ruspl-afed]

We walk in circles in this discussion, let me try to formulate the preliminary results:

1. Java 21 support is important, but does not require to shift minimum BREE for all the Platform bundle to Java 21
2. The upgrade to a higher Java should only be performed for those Platform bundles where it is needed and when it is needed, and currently this set is empty
3. The reasons for the suggested bulk upgrade are rather "nice to have" than "must have"
4. Despite the fact that such a bulk upgrade can be a relatively simple task for the Platform project, for downstream projects the only benefit of this change is additional stress, that may be painful because a lot of them are understaffed.

What did I miss?

[jukzi]

What did I miss?

Those plugins that use BREE 17 are not guaranteed to run on 21 - which is important (1.).
I am already testing all my usecases every day on 21 but i am sure there will be code that is not tested on 21 and may fail.
On the other hand: if some project tests only 21 there will be no guaranty it still runs on 17.

Sooner or later all plugins need to run on 21 anyway, i see no big overhead to upgrade sooner. It might only save something if we skip some version (but we do already skip non-LTS). It is even easier to upgrade all plugins at once (single search&replace) instead of having many different BREEs around. It was already not easy to update all to 17, because there where so many different. So i suggest to have the same BREE on all plugins just to save(!) work.

As soon as any of our plugins requires 21 all the tests have to run on 21, so i suggest to switch I-Build tests to 21 on front.
But as soon as we test on 21, we would disable tests on 17. I would not say we support 17 if we don't test it. If we don't support 17 we do not need to stick with BREE 17.

[merks]

Perhaps there is room, as @tjwatson, @ruspl-afed, and I have suggested, to also see and to consider the big overhead (disruption) on downstream consumers. I'm not suggesting that should this should be the most important consideration, nor that we should forever put on the brakes for that reason, but I am taken aback when appears that this is completely dismissed as seemingly irrelevant.

[tjwatson]

There is a huge disconnect and a failure of all things Java if we are promoting the idea that to support Java 21 one must compile their bytecode to Java 21. I will never accept that as a reason that all must update BREE's to Java 21.

[HannesWell]

For PDE API-Tools there would be a use-case for pattern matching in switch available with Java-21 as described here:
eclipse-pde/eclipse.pde#592

Furthermore the SequencedCollection can also make things simpler, it would have been the most suitable type for the new API introduced in eclipse-jdt/eclipse.jdt.debug#294 (comment).

Since PDE is a leaf of the tree of Eclipse-SDK/top-level projects I guess it would be less concerning to move only PDE?

[akurtakov]

The Tycho story will be the same no matter when its decided to do the switch, right? Unless Tycho 5.x will be given release timeframe now and will be known to require Java 21, but I haven't seen such conversation. FWIW, projects that require Java 21 build just fine with Tycho 4.x running on Java 21.

[laeubi]

The Tycho story will be the same no matter when its decided to do the switch, right?

Correct, I just wanted to mention it that PDE is used in platform builds, you can use Tycho 4.x with (theoretical) PDE requiring Java 21 but then the build needs to run with Java 21 (as already done with Github actions).

Unless Tycho 5.x will be given release timeframe now and will be known to require Java 21, but I haven't seen such conversation.

Given that we not know a date yet and it likley sooner or later will happen that something requires Java 21 and Maven 4 is around the corner I would just assume that at the time we have a release redy Java 21 and Maven 4 are likely dependencies we can't circumvent.

FWIW, projects that require Java 21 build just fine with Tycho 4.x running on Java 21.

You can build anything that ECJ (or javac if used) can compile. Tycho 4.x even should run at any java version > 17 as long as maven supports that.

[vogella]

and Maven 4 is around the corner

That would be nice, I think I hear this since a few years. Would be nice to finally have a new major Maven version (AFAIK they plan to support incremental builds in case an error happened, you can re-run from the failing bit).

[Bananeweizen]

AFAIK they plan to support incremental builds in case an error happened, you can re-run from the failing bit

You probably mean the --resume option. However, already with Maven 3 you can use --resume-from to manually specify where to restart. See https://maven.apache.org/guides/mini/guide-multiple-modules-4.html (be aware that page is maven 4 specific)

[laeubi]

Please note that many Maven4 features are very "maven specific" that mean it will work with classic maven projects and core maven plugins but as soon as it comes to extensions (e.g. Tycho) there is a major effort to support Maven 4 and even if I would like to work on this there is currently no ETA because there is neither a demand nor any funding available for working on this.

[jukzi]

I want to use java.lang.String.splitWithDelimiters(String, int) (@since 21) to make quick-search faster. Therefore i plan to move platform to 21. objections?

[jukzi]

someone we have to move anyway. 14sec->10sec

[merks]

To split hairs, we’d have to move when Java 17 is EOL. Anyway, I’m just pointing out that not everyone will be positively impacted by such a decision and you did ask.

[jukzi]

To split atoms: We have to move as soon as any used deprecated for removal is removed in a supported jdk, or make big workarounds.

[laeubi]

someone we have to move anyway.

Maybe someone eager to move might want to start helping adjusting the I Builds and test pipelines, I already did it for Github Actions and at least everything run + compile.

14sec->10sec

What Quicksearch we are talking about? This one?

It takes < 1 second for me when I type there at least nothing noticeable "slow" where I could see any benefit in making it "faster".

I tried to find some reference to speed improvements but people there are talking about splitting gigabytes of data ...

[akurtakov]

It should be fine to move the bundles where you will use this new API. Moving everything in one go is not welcome.