Check for Java version

[tobiasdiez]

Lately, we get a lot of issue reports that can be fixed with a simple update to a newer Java version. I propose that we add a check at the start that informs the user that his java version is outdated. (Maybe helpful https://stackoverflow.com/questions/2591083/getting-java-version-at-runtime or https://stackoverflow.com/questions/4638994/how-to-know-jdk-version-from-within-java-code).

Moreover, if I remember correctly then the installer (on Windows) also installs the JRE. Is it possible to configure the installer to also update it, when an older version is already installed?

Finally, we should also display a warning message that JabRef does not support Java 9 at the moment.

[lenhard]

I fully support this! It should be a must for the 4.1 release.

[LinusDietz]

refs #3073

[halirutan]

@tobiasdiez Can you comment on

• Where should the information about min and max supported version number go? Preferences, Globals, build-settings.properties?
• What would be a good thing to track? Min-version, Max-version?
• I've seen issues where the Java FX version might be older than Java itself. I guess I read it on SO, but don't remember exactly. In the light of this, should we test this as well?
• How do we decide which versions are acceptable?

[halirutan]

Some more info since java version numbers might not have a consistent scheme throughout different major versions and different vendors:

01:32 < halirutan> Hey. System.getProperty("java.version") gives me "1.8.0_144". Is this naming convention
used on all systems and all java version? Is there a comparator available in the standard
library for these version strings?
01:32 < Maldivia> halirutan: nope :D
01:33 < Maldivia> halirutan: it was changed in java 9 :D
01:33 < halirutan> Maldivia: Ahh.. so 10min of googling didn't failed me.
01:33 < Maldivia> halirutan: also, it's slightly different for IBM JDK
01:35 < halirutan> We kind of need to ensure not only that users have say 1.8 but even what patch they use.
01:35 < Maldivia> halirutan: why?
01:36 < halirutan> Maldivia: We ran into problems with JabRef if users has e.g. 1.8.0_74 and not say 1.8.0_144.
01:36 < halirutan> I didn't want to hack something myself to compare versions. That's why I asked.
01:37 < Maldivia> well, across all openjdk jvms, you should be able to use java.version
01:37 < halirutan> Slightly simpler question: is there a list of all java version numbers? :)
01:37 < Maldivia> no
01:37 < halirutan> Not my lucky day I guess.
01:37 < halirutan> Thanks anyway!
01:38 < Maldivia> Oracle and openjdk, you either have the 1.8.0_xxx format, or for java 9 9.something
01:38 < halirutan> Maldivia: Yeah, that's why a list would be handy. So I could at least write a unit test.
01:40 < Maldivia> well, for all OpenJDK or Oracle JVM, for java version 8, you have: 1.8.0_#
01:40 < Maldivia> where # is the build number
01:40 < halirutan> OK, that's at least a start.
01:41 < Maldivia> currently, that would be
[5,11,20,25,31,40,45,51,60,65,66,71,72,73,74,77,91,92,101,102,111,112,121,131,141,144]
01:43 < Maldivia> now, if you are running IBM JVM then java.version will just say "1.8.0"
01:43 < halirutan> Maldivia: And you got that list from where?
01:44 < Maldivia> those are the public build numbers at the moment... that being said, openjdk installations
might have others, if what ever distro opted to take somehting out a different time
01:44 < halirutan> OK, but at leat they might have the same regex and I can extract numbers.
01:45 < Maldivia> yeah, meaning your only problem will be if they are using a different vendor
01:46 < halirutan> Yes.
01:46 < halirutan> Thank you very much!
01:46 < Maldivia> which is not that common :D

Beside the simple java.version property, we have the class org.apache.commons.lang3.SystemUtils already available. This comes with some handy properties:

SystemUtils.JAVA_SPECIFICATION_VERSION = "1.8"
SystemUtils.JAVA_RUNTIME_VERSION = "1.8.0_144-b01"
SystemUtils.JAVA_RUNTIME_NAME = "Java(TM) SE Runtime Environment"
SystemUtils.JAVA_SPECIFICATION_VERSION_AS_ENUM = {JavaVersion@4906} "1.8"
SystemUtils.JAVA_VERSION = "1.8.0_144"

The JavaVersion objects can easily be compared and one could at least ensure that the major version matches. For the release numbers however, there is probably no other way than extracting it from the string itself.

[tobiasdiez]

Thanks @halirutan for having a look at this issue! Concerning your questions,

Where should the information about min and max supported version number go? Preferences, Globals, build-settings.properties?

I would say it is ok to hard-code those checks. You can try to be fancy and include it in the build settings file but I don't think that is worth the overhead.

What would be a good thing to track? Min-version, Max-version?

Minimal version is the most important right now; and a check if Java 9 is used

I've seen issues where the Java FX version might be older than Java itself. I guess I read it on SO, but don't remember exactly. In the light of this, should we test this as well?

Yes, some warning messages are displayed if you run FXML files with a different version than they were created with (there is a "version" string stored somewhere in the FXML code). But I have never seen problems with that since the FXML parser is relatively stable. So I would leave this out.

How do we decide which versions are acceptable?

Good question 😄 Probably by having a look at the recent issue reports that were solved by updating Java and taking a higher version as the minimal requirement.

[tobiasdiez]

This is now implemented.