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 <e...@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-boun...@openjdk.java.net> im Auftrag von > Scott Palmer <swpal...@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.bate...@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 >
