Modular Applications - Regression

[Scott Palmer]

> On Jan 14, 2019, at 10:33 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 14/01/2019 15:03, Scott Palmer wrote:
>> :
>> 
>> Does this not require ALL dependencies - down the entire dependency chain, including every transitive dependency, to be 100% modular?
> Look for "automatic modules", this is how the module system facilitates top-down migration where you can migrate to modules without waiting everything you depend on to migrate first. Automatic modules also support bridging to the class path so you can migrate without moving everything from the class path to module name.

Sorry, I’m asking this in the context of building a modular app that I can then run jlink or jpackage on. (I *think* I understand automatic modules.)  However, a workflow that will run perfectly fine with JDK 9 & 10 can’t easily be ported to JDK 11 because jlink can't work with automatic modules and java.activation is no-longer available as an explicit module (until the issue you cited is fixed, but note that the module name has changed, thus requiring a stub module for modules that are expecting a module named java.activation).  

> 
>> 
>> I don’t know of many applications outside of those included in the JDK (where dependencies are not an option) that this restriction actually applies to.  In fact since Java 11 there is a regression where applications that could be built as modular with JDK 9 & 10 no longer can be, because the java.activation module was removed and no modular replacement is available.  Many dependency chains lead to java.activation.
> The JavaBeans Activation Framework (JAF) was always maintained as a project in Java EE, never here. In any case, you can download JAF from Maven and deploy it on the module path, it should just work. The only issue with link time where it needs to be migrated to an explicit module before it can be linked into a run-time image. There is an issue in its Eclipse project to migrate it to an explicit module [1].

This issue breaks many cases where jlink used to work.  This is why I refer to the current state of things as a regression.  It’s more than a simple matter of obtaining the replacement module for the modules that were removed from the JDK - because no such modules currently exist.

Even if you modularize your library or application - you can’t run jlink on it if the dependency chain ever leads to an automatic module.  Therefore jpackage and jlink tools can’t work on projects that they previously could work on due to the changes in the JDK being made without a suitable replacement ready for java.activation.  Somehow java.activation became un-modularized in the process of removing it from the JDK.

So more to the point - very few application modules are suitable for jlink input.  The only practical case seems to be to run jlink by explicitly including only modules that have no automatic module transitive dependencies (e.g. JavaFX).  Even that can’t be done to include JAXB or JAX-WS into a Java 11 JRE image, to make a JRE compatible with Java 9 & 10, because of java.activation 

Is that correct?

Scott

> 
> -Alan
> 
> [1] https://github.com/eclipse-ee4j/jaf/issues/13