Build with Java 17

[wimjongman]

The nls1 requires java 17 but the compile uses Java 11. This updates the compile to Java 17. Alternatively, the nls bundle may be downgraded to Java 11

[jantje]

Thanks wim.
Do you advice to go for java 17 or java 11?

[wimjongman]

That is a choice. Sloeber can be installed in older Eclipse versions if we keep Java 11. If we do not require any Java 17 function at the moment, I would say stick to Java 11. Let me make another PR for that.

[jantje]

This whole java thing is very confusing to me.
There are a zillion places where you need to define it and it is unknown to me what each place means.
FYI I have added java17 to the sloeber target to get things to work.
<targetJRE path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-17"/>

[jantje]

One confusing thing for me is this pull request.
If we go to java 17 we must accept this pull request.
If we use java 11 can we or can we not accept this pull request?

[wimjongman]

This pull request will change the build to run with J17. It means you have no check on J11 backward compatibility. Since you have already upgraded all plugins (except 1) to use J17, you can accept this and be happy.

If you do care about backward compatibility, ignore this PR and accept the other one.

Either way is fine with me.

[jantje]

I care about backward compatibility
So lets keep this waiting untill it is time to go to java 17

[jantje]

@wimjongman
Houston we have a problem
On my system the sloeber build broke
It seems CDT needs java version 17 from this month onwards
So I think we will have to move to java 17 as well

https://github.com/eclipse-cdt/cdt/blob/main/NewAndNoteworthy/CDT-11.0.md#java-17

[wimjongman]

We don't need to move to Java 17. We just need it as a runtime. Let me take a look.

[jantje]

I thought the plugin target could solve some building problems but it looks like it creates more then it solves 😞
It may be I'm doing it wrong to but I don't find any documentation to help me out.
Or maybe this is all related to a new eclipse release that moved things around and the target using "latest"

[jantje]

Thinking about this I wonder.
As we need java17 as a runtime. What benefit do we have to not "move to Java 17"?
I mean: we need java17 on our systems to build sloeber and the sloeber user needs java17 to run sloeber.
What does " backward compatibility" with java11 brings us?

[jantje]

about the target thing:
I changed <repository location="https://download.eclipse.org/releases/latest"/> to
<repository location="https://download.eclipse.org/releases/2022-09"/>
And now Sloeber builds again on my system
So the problems are related to the eclipse release.
I see many id's have a version number
<unit id="org.eclipse.cdt.autotools.feature.group" version="10.7.1.202208160035"/>
I'll try to remove these version numbers and try again with latest to see what is happening.

[jantje]

Much to my surprise changing the versions to 0.0.0 makes things work with latest.
I'm not sure whether to be happy it works or sad that this is buggy.

[wimjongman]

Much to my surprise changing the versions to 0.0.0 makes things work with latest. I'm not sure whether to be happy it works or sad that this is buggy.

It is working as expected. When you use 'latest' in combination with a qualified version number, then this will bomb when 'latest' gets updated. If you use 0.0.0, you basically telling 'whatever version is in the repository'. This is a relatively new feature.

Not buggy but works as designed.

[jantje]

Not buggy but works as designed.

unfortunately the editor put the version in there (without me telling it to) and you have to edit the text file to remove the version as the ui doesn't let you.
So at least the editor doesn't support the full functionality (which is an eclipse constant) and probably would be better of not to add the version number by default.

[jantje]

And thanks for the help 👍 It really is deeply appreciated.