Following this poll (please keep voting btw), I think it’s time to draw some preliminary conclusions.
First I was expecting a bit more participation, but hey, we did our best to promote it. As of today with 29 voters, it turns out that about half users have Java 21, whilst there are still a few irreducibles stuck with 8. The rest uses 17 basically.
This would be my suggestion for the next steps (please reply and give your own opinion):
Orekit 13.X should be the last series in Java 8
Next year, we should upgrade to Java 17 or 21. To decide which one I believe we should hold another poll in between.
I wonder if we should (or even could) make a distinction between the runtime version and the compilation version.
For example, could we have source code and binary version remain compatible with 1.8 for users benefits while requiring a more recent Java for building, so we can use updated maven plugins?
We could also do the following to give a bit more time to users:
Orekit 13.x in Java 8
Orekit 14.0 in Java 8 immediately followed by Orekit 15.0 in Java 17 or 21. The downside being that bug fixes for 14.x would have to be done in parallel for some time…
It is possible to keep the language level to 1.8 while using higher version for building but we would not be able to benefit from features and optimization of higher Java version.
Sorry I’m only reacting to this now.
Unfortunately, I don’t think it’s just a matter of not being able to have more recent versions of plugins or test dependencies. It’s also about all the modern Java features we’re missing out on. I mean, think about the Record type. It’s immutable by design and has built-in getters. It would simplify all our pure data container classes. Being now used to Java 21, I’m more reluctant to contribute to Orekit knowing that I will have to switch back to the old ways, which has become a pain. And I think sticking to 8 for too long will potentially deter new contributors, especially the youngest ones that are used to more modern programming.
I don’t know anything about Java, but I have developed a lot of software in other languages, so I will take the liberty of giving an opinion.
I understand that space projects take a long time, sometimes several decades, and that this means that the software integrated into ground systems has to be maintained over a long period. I understand that in order to minimize updates and the inherent risks, people want to freeze the version of the compiler and libraries.
But on the other hand, not updating the code and the tools means accumulating technical debt and frustration among contributors. In the long term, this is not good for the project or for its community.
How can we reconcile the two? Orekit is not the first project to encounter this problem, and the solution is now well known: create a “Long Term Support (LTS)” version.
While this LTS version will only receive bug fixes and security patches for sereral years, using a frozen development environment (including versions of Java, Maven and Hipparchus), we could free ourselves from this antediluvian environment and switch to newer technologies for subsequent versions, taking advantage of all the advances in language and tools.
The right solution to take into account the needs of everyone and not lose anyone could therefore be to:
declare version 13 of Orekit as the LTS version, maintained for ??? years;
immediately create a version 14 in which the development environment and the source code would be modernized.
Setting up Long Term Support is a good idea.
I would say we should maintain it up to december 2030 (or march 2031) in order to match end of support for Java 8 according to the table in Java version history.
I would also say we set up an LTS only when needed, as I fear it would be a chore to maintain several versions in parallel.
Sounds promising.
Are we saying that Orekit 14.0 will be the 1st (and so far only) LTS next year then, immediately followed by the release of 15.0 in Java (17 or 21, TBD)?
I’m guessing the PMC shall get involved at some point to make things official though. How do we organize?
Same thing: we should say Hipparchus 4.0 is an LTS and start working on 5.0. Perhaps I could finally get rid of the infamous design of russian-dolls optimizers and marker interface OptimizationData, and hopefully follow Evan’s design on least squares builder.
Is it okay though to have very short notice like that?
If you look at Java versions for instances the LTS are announced well in advance so that programmers can plan ahead and decide wether or not to upgrade.
Personally I’d be fine with moving forward now, but that’s my contributor perspective. Also, LTS or not, I think we should follow a bit more the motto “release early, release often” and target the next minor version for end of June early July.
I may be wrong, but it seems to me that with regard to planning and managing the obsolescence of the software base, the key information is not the release date of an LTS, but its end of life. The PMC should be clear about the LTS end of life.
As Orekit has never offered an LTS until now, I don’t see how the fact that 13 is an LTS could lead users not to adopt it or to regret having done so. Could you explain your concerns to me in more detail?
A team is using Orekit and for some reason still develops on top of it in Java 8.
If we do the LTS now and switch to say JDK 17, this team won’t have much time to (assuming they decided to do so) upgrade their system to be able to benefit from the next minor release in a few months, so they’ll miss out on new features. On the other hand, if we say the LTS is for January 2026, they’ll have more time. That’s all.
Another thing I just thought about. Standards like CCSDS have updates from time to time. Would this mean that the LTS will never support the newer versions then? That might in the end make the LTS unusable by some users.
Yes, if they want to stick with Java 8, then they have to stick with the features in 13.0. If they want new features (or new CCSDS or IGS standards), then they will need to upgrade. You cannot have your cake and eat it. We may decide to backport some features if really needed, though, but this would be on a case-by-case basis.
In terms of technical environment: language (Java 8), tools (Maven 3.9) and dependencies (JUnit 5.11, Hipparchus 4.0).
In terms of functional scope: no additions to be expected in the TLS version, this version will only receive security patch and bug fixes (as long as fixing these bugs does not require redesigning and modifying the API).
If a user wishes to benefit from any kind of improvement, he should consider upgrading to the last stable version of Orekit.
I agree with the fact of having Orekit 13.0 and Hipparchus 4.0 as the first LTS versions. And I also like the idea of LTS because it could help a lot our users and prepare them to major updates without imposing these changes.
If we introduce the LTS mechanism, this shall be documented somewhere in a .md file, including the “expiration” epoch (2-3 years for instance).
I also like the idea of having Orekit 14 and Hipparchus 5.0 in Java 21. The new “record” type, supported since Java 17, is very useful.
In my opinion, these versions could be the next ones and could be done as soon as possible. Only, Java upgrades should be in the release program since it is a major change.
