--- /dev/null
+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.
+
+
git://source.jalview.org / jalview.git / blobdiff