Presently the Java 11 build of Jalview treats all libraries as libraries on the classpath, and does not use them as modules. The Java 11 JRE prepped for future release is a standard AdoptOpenJDK release (possibly repackaged for getdown/install4j to use).
-At time of writing, the JRE cannot be updated over the air on macOS platform due to a limitation of getdown's unpackaging system only using jars and hence cannot work with symbolic links. There is a symbolic link that is essential (as a symbolic link) in the macOS distribution (Contents/MacOS/libjli.dylib -> ../Home/lib/jli/libjli.dylib). Without this, the install4j launcher will not work. Some work has started on incorporating tar capabilities in getdown using the apache-commons-compress library, though this is not complete.
-
Future releases might incorporate Java 11 modules into a bespoke Java 11 JRE that can be updated over the air via getdown.This could reduce the size of the distribution but will absolutely need the bespoke JRE. This would mean Jalview being restricted to platforms that we (can) support, or distributing the modules as libraries in a second distribution (the shadowJar distribution).
build.gradle is written to support compilation of either Java 1.8 or Java 11 compatible bytecode. Please note that the compilation (and therefore build) process REQUIRES a Java 11 (or above) JDK. This is because there is Java 11 specific code in some Jalview classes (devolved into separate classes which fail "gracefully" when read by a Java 1.8 JRE).
git://source.jalview.org / jalview.git / blobdiff