Both the Orekit and Hipparchus libraries are currently compatible with the venerable version 8 of the Java language.
This version has been superseded numerous times ; as of writing, the latest official Java version is Java 20. The latest Long Term Support version is Java 17, which was released two years ago and is available in many systems. Next Long Term Support version will be Java 21, scheduled in a few days.
Some of these versions brought features that could be useful for developing the libraries themselves (I think modules, pattern matching in instanceof and switches, switch expressions) and also to library users. Maintaining the compatiblity with Java 8 becomes more and more difficult each day. Some development tools and plugins are not compatible with Java 8 anymore, and the OS distributions make it difficult to install an old JDK.
Some work has been done recently so that both Orekit and Hipparchus can be compiled seamlessly with recent JDK (I tried Java 17 and Java 21 on a Linux computer).
What would users think about upgrading the minimum Java version for both Orekit and Hipparchus to a more recent one? I would suggest Java 17 because it is an already established Long Term Support version.
I know that many operational systems are limited in the versions they can use, so maybe this upgrade is not possible for everyone, but I would like to know what the community thinks about this.
I would agree with Luc that Java 17 is a good target because users of OREKIT will also have dependencies on other libraries.
However, if you plan to start requiring a new Java version (rather than simply being compatible with it), that is, removing current compatibility, it would be preferable IMO to state a plan with over 6 months advance notice to allow users of your libraries to manage deprecation through their system maintenance procedures.
FWIW We use Orekit and Hipparchus with Java 17 already and as you note, it works fine. We did identify changes in floating point computation that resulted in accumulated differences that exceeded our test thresholds, though that might say more about our test thresholds.
it’s ineluctable that we’ll have to switch to a more recent Java at some point. I’m sure many users have already upgraded.
Now, in my opinion doing it for Orekit 12.0 is not suitable, as in order to make the most of the new language version, we’d need to modify the code a lot. But a new major release is long overdue, I don’t think we should postpone it any further. Maybe 12.1 could be the one, assuming we don’t break any public API? And users would thus be warned in advance.
And a big question also is how would that affect the Python’s wrapper building? We don’t want to make Petrus’ job harder than it is. The changes already present on the develop branch must make him sweat bullets
First of all some numbers, as of 2022, 46.45% of projects are still using jdk 8 according to this report.
In addition, the LTS of JDK 8 has been extended up to 2030 (reference here)
So all in all, it should be done at some point in the future but i agree that i should not be done for the 12.0. Users should be warned several months beforehand as @PeaDubYa said.
+1 for switching to Java 17. Upgrading to latest versions is always a good idea.
However, @Serrof’s and @Vincent’s remarks are interesting.
Currently 97% of 12.0 version issues are fixed. On the Hipparchus side, it looks like there is no issues identified 3.0. So, I suppose that 100.0% of the 3.0 version issues are fixed. In other words, it means that we are very close to release both libraries. Therefore, we are at the point that we are converging to stability. Introducing Java 17 now in the 12.0 program will, I think, break this stability convergence.
I’m not sure we can include it in a 12.1 version because as highlighted by @PeaDubYa switching to Java 17 can change floating point computation and therefore change test thresholds. In a result, users will maybe have to change their tests thresholds. In my opinion, this is not a minor change.
Next version is 12.0 but the next after can be 13.0 for which the only change is the Java version.
I agree with this. I think this should be done on a major release. Not 12.0 obviously, so 13.0 should be the target.
That is indeed a big question! JCC seems to work with Java 17 and Anaconda has open-jdk 17 packages. But we’ll need to confirm this with @petrus.hyvonen before switching to a new version.
