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.
Hi,
Indeed, there are much higher versions available, I have deliberately pinned it to version 8 to reduce variations and issues. I have had some issues with other java versions, but mostly on that the packages have had different configurations of file locations which has affected some paths. I cannot see that there should be anything that isn’t solvable in moving to version 17*, just some messing about to get it to work. I would in that case pin it to v17 to avoid trying with different versions which is known to have been an issue.
Great question. I’m a bit late to the party, but I would like to chime in as well.
+1 for staying binary and source compatible with Java 8 until it is no longer supported.
-1 for using a newer Java version if it means Orekit will not longer run on Java 8.
+1 that dropping support for Java 8 requires a major version release.
As Vincent mentioned Oracle plans to support Java 8 through 2030 and Java 8 is the most commonly used version of Java in the Java ecosystem. We’d be leaving behind a lot of people if we moved away from Java 8 in the near term. Since Orekit is a low level library maintaining compatibility with older versions of Java becomes important to keep the user base large.
Also according to Vincent’s links Java 17 is End Of Life (EOL) before Java 8. So moving to Java 17 will actually shorten the longevity of support that Orekit can provide to it’s users.
Currently it appears that Java 8 is the lingua franca of the Java ecosystem. While that is still the case I think would be detrimental to the Orekit community to move away from Java 8.
Thanks for the link Evan! Looking there, I found openJDK8 was available for Debian using the unstable (sid) repository, despite it was not available anymore in either the stable (bookworm) or testing (trixie) repositories. I had a lot of troubles recently with my computer and lost the very old copy of openjdk8 I have been using for years and that introduced many packages conflicts. I thought it was not possible anymore to install openJDK8 on the trixie Debian install I use.
When upgrading maven plugins into Orekit, I noticed that Mockito 4.11.0 is the last supported version with java 8. Last Mockito release is 5.6.0.
Mockito is the second plugin, after checkstyle, that we can’t upgrade due to Orekit Java version.
That’s another point to upgrade Java version in Orekit to 17
Since we’re talking about this again, I think there’s an interesting feature available since 1.9, it’s private methods in Interface. A problem we have for maintenance and testing in Hipparchus and Orekit is “duplication” between standard code and their Field equivalent. I believe introducing Interfaces with common stuff (not public when applicable) would be beneficial on that point.
Could we actually set up a poll on the forum to see who’s using Java 1.8 versus who’s using a more recent version?
