JMOD, native libraries and the packaging of JavaFX

[Gregg Wonderly]

Yes, I, like many others have carried around various JNI code in jar files (javax.comm and my own as well), and then copied these out of the jar, into “temp” space, and then used load() to load and bind them in class wrappers.  This works quite well, but it is highly customized in how it’s implemented, but the effect is the same.  Having the module system support modules with JNI resources would be extremely beneficial given the staleness and complete lack of work on bring more native functionality into the JVM to support things like JavaFX and even JMF which has died on the vine due to the complexity of users tasks to get JMF for use of such based applications.

It’s clear that the desktop and non-web server JEE or such servers is not interesting to Oracle, but it’s quite actively pursued on the platform and ignoring that fact will just continue to erode the use of Java for portable solutions that it once was trumpeted at being the key to.

Gregg

> On Apr 23, 2018, at 12:21 PM, Mike Hearn <mike at plan99.net> wrote:
> 
> Hello,
> 
> The JMOD format is not documented directly, but is essentially a JAR-like
> format which can also contain native libraries, license texts, man pages
> and config files. However, JMODs are not just JARs with extra features.
> They are incompatible, because class files go under a classes/ directory.
> 
> JEP 261 says:
> 
> JMOD files can be used at compile time and link time, but not at run time.
> To support them at run time would require, in general, that we be prepared
> to extract and link native-code libraries on-the-fly. This is feasible on
> most platforms, though it can be very tricky, and we have not seen many use
> cases that require this capability, so for simplicity we have chosen to
> limit the utility of JMOD files in this release.
> 
> 
> I was a bit surprised when I first read this because JARs that contain
> native libraries, along with hacky custom code to extract and load them,
> are actually quite common. One example is Conscrypt but there are others.
> An extended JAR format in which the JVM took care of loading the right
> native library would be a very helpful thing to have. Whilst the task can
> be tricky if you want to do it as efficiently as possible e.g. not save the
> DLL / DSO to disk, a "good enough" approach can't be that hard because the
> community has implemented it many times.
> 
> I'm thinking about this issue now because I quite like JavaFX and its
> future is clearly as a regular Java library, albeit a big one, distributed
> either via (not ideal) an SDK or (better) a set of regular libraries
> published to a Maven repository.
> 
> Publishing JavaFX as a set of modules that developers can depend on with
> Maven or Gradle will require either that JavaFX include the sort of hacky
> extract-to-a-temp-dir-and-load code that is standard today, or that it's
> not published as ordinary JARs at all, or that the JPMS is extended in time
> for Java 11 to provide a uniform solution.
> 
> As far as I can see the JMOD format is probably not going to gain adoption.
> Whilst it can be used by developers in theory:
> 
>   - There's no support in Maven or Gradle.
>   - The format isn't documented.
>   - Using it requires jlinking, which isn't a part of the regular
>   developer workflow.
>   - jlink doesn't do much for the vast majority of apps that can't be
>   fully modularised yet.
>   - It's not clear why it's better than an extended JAR format.
>   - It behaves in puzzling ways, for example the "jar" tool can print the
>   file listing of a jmod but not extract it.
> 
> The bulk of the JMOD feature set could be delivered with two small
> extensions to the JAR format:
> 
>   1. A common directory structure for storing native libraries. That would
>   allow native library extraction and loading to be provided via a small
>   library, if not provided by the JVM itself.
>   2. A common directory structure for including license files (this just
>   has to be announced, as nothing needs to load them).
>   3. Metadata linking command line program names to main class names and
>   JVM parameters.
> 
> For example the jdk.javadoc.jmod contains a program bin/javadoc which is a
> native binary specific to the host platform of the JDK. But all it does is
> run the JavaDoc program itself, which is written in Java. This sort of
> startup program could be easily generated on the fly given startup
> parameters in the same way the javapackager tool does it.
> 
> If the JAR format was extended in this way, it would become possible to
> write a tool that given a Maven coordinate would resolve and then install
> into a bin/ directory on the path a starter program with the suggested
> name. This would be a nice feature to have (I am writing such a tool
> already, but it'd be good to standardise the way to express a desired
> 'short name').
> 
> I realise there isn't much time left until the Java 11 ship sails. But for
> JavaFX users at least, it'd be convenient to have this small extension.
> Even if the JVM isn't extended to support it in 11, a common format would
> allow it to take over responsibility later.
> 
> thanks,
> -mike