bnd
bnd copied to clipboard
bndtools
Move target Java level to Java 17 at end of 2022 (Bnd version 7.0)
Java 17 is now released (Sep 2021). Java 11 was released in Sep 2018 while Java 8 (our current target Java level) was released in Mar 2014.
I propose we raise the raise the target Java level from its current Java 8 to Java 11. We could consider raising the target Java level to Java 17, but perhaps that is a bit too far at the moment.
Most developers will have access to Java 11 and Java 17 JDKs for their development and build environments. The Eclipse IDE itself now requires Java 11 as the base Java level. Maven and Gradle support Java 11 and Java 17.
We would have access to the various new language and library features of Java 11. Nothing earth shattering (Java 17 has more interesting new language features).
There is nothing requiring we move today. Java 8 has an extra ordinarily long service life ahead. Perhaps we will all be retired before Java 8's end-of-life :-)
I think this would be a reasonable move and eclipse would be a problem. As there are still a lot of Java8 projects out there, this might give users of our libs another poke to move on. On the other hand: Would we still be able to build java8 projects with e.g. gradle? I usually have just one JAVA_HOME set which is used by gradle and for compiling.
I once accidentally build bnd with a JDK 11 and even with java.target 1.8 we became incompatible. Not sure who the culprit was, but in one of our basic Classes like IO it caused a method not found exception afterwards. The method we use there comes in java8 from the parent of whatever it was. In Java11 this method is now overwritten.
I'd have a problem with this. Java 8 is still prevalent in the embedded world and especially aQute.libg is used in runtimes. And of course the launcher is running there.
So no, unless there is a really compelling reason.
I once accidentally build bnd with a JDK 11 and even with java.target 1.8 we became incompatible. Not sure who the culprit was, but in one of our basic Classes like
IOit caused a method not found exception afterwards. The method we use there comes in java8 from the parent of whatever it was. In Java11 this method is now overwritten.
The current release (and the released 6.1.0) are built with Java 17 using target Java 8. So this works fine. The CI builds test this by building with Java 17 using target Java 8 and then testing the built code on Java 8. See https://github.com/bndtools/bnd/blob/36260374e414ceb0cff3983d59f74a3c50792d39/.github/workflows/rebuild.yml.
Java 8 is still prevalent in the embedded world and especially aQute.libg is used in runtimes. And of course the launcher is running there.
These projects could remain at Java 8 while the non-launcher-side projects move to Java 11. We had a split like this in the past as we moved to Java 8 as the target level.
Well, why not wait? There are not crucial language features that are desperately needed? I see just no gain, and only potential complexity and disruptions. Java 8 was such a big step that I think it was worth the pain but Java 8 has the features we need and works perfectly on later VMs.
So who benefits from this move?
The current release (and the released 6.1.0) are built with Java 17 using target Java 8. So this works fine. The CI builds test this by building with Java 17 using target Java 8 and then testing the built code on Java 8. See https://github.com/bndtools/bnd/blob/36260374e414ceb0cff3983d59f74a3c50792d39/.github/workflows/rebuild.yml.
I'll try to reproduce it and will open a Bug with detailed steps to reproduce it. I has been a while since I had the issue and the test you pointed to should cover such a case. I'll get back to you.
Well, why not wait?
Ok, but when is the wait over? When will it be time to move to Java 11? Or Java 17?
Ok, but when is the wait over? When will it be time to move to Java 11? Or Java 17?
Well, I answered that question: when there is a language feature that we could really leverage. I only see the 'var' keyword but after struggling with Kotlin I am not sure that is such a wonderful idea anyway.
Most advantages seem to be in the runtime and we're not denying anybody sthose benefits. I am just puzzled why we want to make bnd harder to use while not getting any benefit? What problem are we trying to solve here?
For what it's worth, I think I'm leaning ever so slightly to @pkriens side of this discussion. The big changes from 1.8 to 11 were modules and removing some of the bloat from core JDK into 3rd party packages. These are not massively useful to Bnd as it stands. There are a few extra utility methods here and there but not huge advantages. Most of the features I thought might be useful did not come until later versions (multiline string literals, project Loom, sealed classes). If there's no feature in 11 we can leverage, then there's no compelling reason to change.
Well, I answered that question: when there is a language feature that we could really leverage.
That is a very open-ended answer. There are many library features we can leverage in Java 11 (and 17). The new HttpClient for example.
Most advantages seem to be in the runtime and we're not denying anybody sthose benefits.
We deny ourselves those benefits.
I am just puzzled why we want to make bnd harder to use while not getting any benefit?
I don't see that this makes Bnd harder to use. It just means that a later Java version is needed to run the Bnd tooling. Eclipse already requires Java 11. Gradle will probably one day also move past Java 8. Maven 4 may also.
What problem are we trying to solve here?
Part of this is buying down technical debt by moving to the future in discrete steps instead of much harder giant leaps.
We update the base Eclipse version for Bndtools from time-to-time. And also for Maven and Gradle. I am suggesting we do the same for Java rather than wait until 2026 when Java 8 goes out-of-support. At that time, we will not have a (safe and supported) Java 8 to use in our builds.
I accept there are scenarios (embedded runtime) where we need to support Java 8 for longer. But in the other parts of Bnd there is no requirement to remain on Java 8 for tooling use.
But I think we need to recognize that, like our other dependencies (Eclipse, Maven, Gradle), we need to prepare for and update our Java dependencies from time to time. Given the support plans for Java LTS versions, I think an LTS-1 plan is supportable. So Java 11 now, Java 17 when Java 21 ships (Sep 2023), etc.
Well, I answered that question: when there is a language feature that we could really leverage.
That is a very open-ended answer. There are many library features we can leverage in Java 11 (and 17). The new HttpClient for example.
Specific examples of features that could be leveraged helps make the case. I had forgotten about HttpClient. If this is something we could leverage, it's an argument for moving forward.
Most advantages seem to be in the runtime and we're not denying anybody sthose benefits.
We deny ourselves those benefits.
I am just puzzled why we want to make bnd harder to use while not getting any benefit?
I don't see that this makes Bnd harder to use. It just means that a later Java version is needed to run the Bnd tooling. Eclipse already requires Java 11. Gradle will probably one day also move past Java 8. Maven 4 may also.
What problem are we trying to solve here?
Part of this is buying down technical debt by moving to the future in discrete steps instead of much harder giant leaps.
We update the base Eclipse version for Bndtools from time-to-time. And also for Maven and Gradle. I am suggesting we do the same for Java rather than wait until 2026 when Java 8 goes out-of-support. At that time, we will not have a (safe and supported) Java 8 to use in our builds.
2026 is still further away than 2018. I'm all for planning for end of life, but Java 8 still has life left. I don't find this part of the argument compelling.
I accept there are scenarios (embedded runtime) where we need to support Java 8 for longer. But in the other parts of Bnd there is no requirement to remain on Java 8 for tooling use.
Perhaps it would further the discussion if we could outline which bundles really ought to stay on Java 8 and those where it doesn't matter. All the Bndtools bundles could go to Java 11 once the baseline Eclipse version requires it.
All the Bndtools bundles could go to Java 11 once the baseline Eclipse version requires it.
Am I missing something? I do not think this will ever happen?
Am I missing something? I do not think this will ever happen?
Eclipse IDE already requires Java 11 since 2020-09. Look in your eclipse.ini file:
-Dosgi.requiredJavaVersion=11
Yes, but that is not for the bundles running on it?
Well if Eclipse IDE requires Java 11, then the runtime is Java 11+. Eclipse now ships with Java 17 runtime. Some IDE bundles don't require Java 11, I suppose they could only require Java 1.4 :-) My point was not to assert that all Eclipse bundles must use Java 11 but that the base Java version has risen to 11 since some parts of the IDE now require Java 11.
So why is this relevant for us?
Eclipse will run Java 8 bundles long after I am dead. The fact that they support java 17 bundles today is exactly how it should be for a platform. By going to Java 17 they expand the range of compatible bundles they can accept. In stark contrast, if we go to Java 17 we shrink the range of compatible platforms we can run on. These are opposite parties in the game of compatibility. I am a bit surprised you mix them up :-)
I am a bit surprised you mix them up :-)
I don't mix them up, at all.
Eclipse will run Java 8 bundles long after I am dead. The fact that they support java 17 bundles today is exactly how it should be for a platform.
Eclipse does not "support" or "run" Java 17 bundles. Eclipse is a set of bundles and their bundles run on Java just like all possible bundles. Eclipse has a base Java requirement of 11 which is the highest requirement of their set of bundles. I don't mention Eclipse requiring Java 11 or providing a Java 17 runtime as a requirement for Bnd to move to Java 11. Just as evidence that other parties in our tooling ecosystems are advancing their Java base requirements and Java runtimes.
So why is this relevant for us?
Because it means that (for the bundles that only run in Eclipse - ie, the bndtools.* and org.bndtools.* bundles), we know that we can safely move them to Java 11 without shrinking the range of compatible platforms we can run on.
Eclipse will run Java 8 bundles long after I am dead. The fact that they support java 17 bundles today is exactly how it should be for a platform. By going to Java 17 they expand the range of compatible bundles they can accept. In stark contrast, if we go to Java 17 we shrink the range of compatible platforms we can run on. These are opposite parties in the game of compatibility. I am a bit surprised you mix them up :-)
This is true. It comes down to: what is the maximum version of Java that we can target without overly-limiting our compatibility? In the embedded world, as you point out, that may still be Java 8 for some time. But for Eclipse, we know that as of 2020-09 the minimum platform is guaranteed to be Java 11. In this context it doesn't make sense to restrict ourselves to anything less than Java 11.
I think this discussion is best had on a project-by-project basis, as @bjhargrave suggested.
Which bundles are likely to be required in an embedded environment? libg, launcher and tester bundles. These should remain on 1.8.
Other bundles should be free to move to Java 11. Bnd itself is going to run on the dev machine, not on the embedded target device. In particular, the bndtools bundles. (I feel if we're going to do that though it makes sense to bump the base version of Eclipse to 2020-09 or later.)
Thoughts? Anything that @pkriens suggests runs in an embedded environment and needs to remain on Java 1.8?
I think this discussion is best had on a project-by-project basis, as @bjhargrave suggested.
In my experience that adds complexity that at times it goes wrong and then we're screwed. And in my further experience, at the worst possible time. If we move, we should move it all to keep simplicity.
We have been going back and forth and maybe I am daft but I fail to see why this would be worth the effort to even change the build files. By going to a later Java, we reduce compatibility for no concrete gain.
Just really puzzled. Why not revisit this when someone has a feature they absolutely want to use? I am not against upgrading one day but then I'd like to see some benefit for the inherent issues that will occur. Don't change something that works well and nobody has a problem with.
I had an interesting issue on another repository.
(1) I have Kubuntu 20.04 installed and OpenJDK 11 installed. If I try to execute Alloy with OpenJDK 11 Runtime, Duke icon flashes on task manager and nothing happens, but if I try to execute it through command line, I get "Unable to start graphical environment" error. How do I solve this? I need a solution ASAP. EDIT: I also have OpenJDK 17 installed on my system.
(2) Did you fix your problem? I had fixed mine I had fixed mine by installing more java related packages. The fedora java package was stripped without the graphical stuff and I had to runn dnf install java-latest-openjdk.
(3) I just installed Java 8.
I talked to some of my customers. None has any need for later Java's and one is actually facing a difficult transition on one its device types because it is uses a not very well supported processor. However, they are aware that they can't stay on 1.8 forever.
I guess we should just set a date, I would prefer December 2022 this year, and make the move to 17. I'd expect little extra value in going to 11 at that time.
I guess we should just set a date, I would prefer December 2022 this year, and make the move to 17. I'd expect little extra value in going to 11 at that time.
OK, That makes sense. So will hang tight for now. We should probably announce this intention in the discourse group.
Announcement: https://bnd.discourse.group/t/long-term-plan-to-move-to-java-17/206