Java 11 module replacements As Java 11 no longer ships with Java EE libraries, which were standard in Java 8, and available (modularised, through the --add-modules CLI mechanism) in Java 9 and 10, third party replacement libraries for these libraries/modules have to be found. Ideally, these jar files would be packaged as modules (i.e. would contains a module-info.class with the relevant provision and requirements information for that module package). However, as at time of writing (end Nov 2018) the available packages are not fully mature. There also seems to be no single place to look when trying to obtain modules jar files. A couple of good places to start: https://javaee.github.io/ (see Metro, Glassfish etc) https://search.maven.org/ (search for e.g. a:javax.activation) https://mvnrepository.com/ (if the other two fail!) Unfortunately there seems to be multiple projects providing the same modules, with little indication of which is "best". Here's an example of what to do with search.maven.org, looking for, say, the java.activation module Firstly, remember this might be called javax.activation (in fact it is), so searching for a:javax.activation shows 3 possible candidates. The "Updated" date gives a clue if a library might be up-to-date or still being maintained, and of the three listed, com.sun.activation version 1.2.0 was updated in Sep 2017, and is the only one updated in the last 5 years, so it looks like a good candidate. Click on the arrow in the Download column which gives various download options. Choose "jar" and this should download straight away. If you have a peek inside the jar file: $ jar -tvf ~/Downloads/javax.activation-1.2.0.jar 0 Wed Sep 06 16:13:08 BST 2017 META-INF/ 1307 Wed Sep 06 16:13:06 BST 2017 META-INF/MANIFEST.MF 0 Wed Sep 06 14:23:50 BST 2017 javax/ 0 Wed Sep 06 14:23:50 BST 2017 javax/activation/ 0 Wed Sep 06 14:23:50 BST 2017 com/ 0 Wed Sep 06 14:23:50 BST 2017 com/sun/ 0 Wed Sep 06 14:23:50 BST 2017 com/sun/activation/ ... 2238 Wed Sep 06 14:23:50 BST 2017 com/sun/activation/registries/LineTokenizer.class 39394 Wed Sep 06 16:13:06 BST 2017 META-INF/LICENSE.txt 581 Wed Sep 06 16:13:06 BST 2017 META-INF/mimetypes.default 292 Wed Sep 06 16:13:06 BST 2017 META-INF/mailcap.default 0 Wed Sep 06 16:13:08 BST 2017 META-INF/maven/ 0 Wed Sep 06 16:13:08 BST 2017 META-INF/maven/com.sun.activation/ 0 Wed Sep 06 16:13:08 BST 2017 META-INF/maven/com.sun.activation/javax.activation/ 6515 Fri Sep 01 16:13:04 BST 2017 META-INF/maven/com.sun.activation/javax.activation/pom.xml 119 Wed Sep 06 14:23:52 BST 2017 META-INF/maven/com.sun.activation/javax.activation/pom.properties you can see that it doesn't have a module-info.class file, meaning it can only be used as an "automatic" module. This will probably mean it can't be used with jlink when creating a JRE. HAVE NO FEAR! We can semi-manually (urgh!) create a module-info.class for this library and turn it into a module. This really should be scripted. I might just do it. So, assuming we downloaded that jar to ~/Downloads/javax.activation-1.2.0.jar, and JAVA_HOME is set to a java distribution, we can do: mkdir tmp cd tmp jar -xvf ~/Downloads/javax.activation-1.2.0.jar jdeps --generate-module-info . ~/Downloads/javax.activation-1.2.0.jar # --generate-module-info creates the module-info.java file we are looking for! but for some reason insists on sticking it in a java.activation subdir (even though we ask for '.') mv java.activation/module-info.java . rmdir java.activation javac -d . module-info.java # we could clean up (rm) module-info.java, but I think it'll be more useful to keep a hold of it in the jar, it's not causing a problem or taking up space cd .. jar -cvf javax.activation-1.2.0-MODULE.jar -C ./tmp . /bin/rm -rf ./tmp and voila, you have a modulified version of the library in the jar file ./javax.activation-1.2.0-MODULE.jar. This can be used with jlink. [ timeout: I scripted this as utils/modulify.sh Usage: modulify.sh /path/to/jarfile.jar ... creates /path/to/jarfile-MODULE.jar ] Once we have enough modulified jar files (note, we kind of keep downloading a new file or files until jalview starts without Exceptions, jdeps could probably provide a better way(!), and jaxws-rt provides quite a few of the needed jar files, hopefully in a coherent way). A list of module dependencies can be found with (note module-path doesn't need jar files, just the dirs to look in, unlike class-path) jdeps --class-path="lib/*:j11lib/*" --module-path="$JAVA_HOME/jmods:j11lib" --list-deps dist/jalview.jar libs/*.jar will end with a list of modules required in the JRE, these need to be comma-separated-listed for jlink. We /ought/ to be able to do this by using "--print-module-deps" like this jdeps --class-path="lib/*:j11lib/*" --module-path="$JAVA_HOME/jmods:j11lib" --print-module-deps dist/jalview.jar libs/*.jar but that ends with an Exception. Perhaps should look into that... Anyway, with the list of modules required (in the file "modules") you can do jlink --module-path $JAVA_HOME/jmods:j11lib --compress=2 --add-modules `cat modules` --no-header-files --no-man-pages --bind-services --output j11jre/openjdk11_platform To create a Java 11 JRE in j11jre/openjdk11_platform (or whatever you wish to call it). You can point JAVA_HOME at the JDK11 of a different platform, so long as the jlink in your path is to the jlink for the platform you're running on.