Modular Applications - Regression

Mon Jan 14 21:11:02 UTC 2019

Well, I think that (jaxb) is a different (but related) issue.

I was just addressing the „generate smaller runtime Image with jimage for classpath usage“ part. And that works. You can either do it on the command line or introduce an empty module with the needed Imports. In both cases jlink can produce a minimized Image (and still have a classpath used).

Given the uncertainity involved in static scanning I would not want jlink to do jdeps work automatically, so there is not much else you can do besided providing the modules list yourself, or what would be your idea to make this work?

(Actually when aiming for small Images, I would even specify the modules in a mp path scenario, only because a third party module Imports a JDK module does not mean it needs it at runtime for the specific case)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Scott Palmer
Gesendet: Montag, 14. Januar 2019 21:21
An: Bernd Eckenfels
Cc: core-libs-dev
Betreff: Re: Modular Applications - Regression

Aren’t you just saying that jlink works when you don’t use the stuff that broke?

Can you use jlink with JAXB or JAX-WS that does not rely on the .jmod files from JDK 9 or 10?

Is there a way to use JAXB or JAX-WS on the module path like there was with JDK 9 & 10?

>From what I can tell, if one of the modules you need is JAXB or JAX-WS and you already had this working with Java 9 or 10, you have to make a lot of changes.  You can’t build a JRE image with jlink that contains the new replacements for JAXB or JAX-WS.  You can include JAXB or JAX-WS on the classpath, but you can’t go back to how it worked with JDK 9 & 10.  

Applications based on a JRE image that includes the java.xml.bind, java.xml.ws, or java.activation modules can’t be made to work anymore without resorting to hacks like running jlink to pull the .jmod files for those modules from JDK 10 and the rest of the  runtime from JDK 11.

Scott

> On Jan 14, 2019, at 2:37 PM, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
> 
> JLink works fine with applications on the classpath, all you have to do is to list the modules needed manually (and JDeps helps with that).
> 
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> ________________________________
> Von: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> im Auftrag von Scott Palmer <swpalmer at gmail.com>
> Gesendet: Montag, Januar 14, 2019 8:16 PM
> An: Alan Bateman
> Cc: core-libs-dev
> Betreff: Re: Modular Applications - Regression
> 
> 
> 
>> 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
> 