On 27/11/2023 11:44, Mark Raynsford wrote:
I'm not entirely convinced that discussion on this list doesn't get
lost in the endless sea of "RFR: " messages. :)
It was originally sent to jigsaw-dev, then Alan Synder sent it here.
As you know, automatic modules are to support migration without waiting
for everything you transitively depend on to migrate first. In addition
to allowing you to write "requires xxx" before xxx becomes an explicit
module, they also support bridging to the class path so you can leave
second and third level dependences on the class path. The intention was
for automatic modules to be used when early in the migration journey.
The jlink tool, on the other hand, is the other end of the journey where
everything is an explicit module. As jlink produces a run-time image
then it can't be in the business of having dangling references to
classes on the class path that may or may not exist. It's unfortunate
that some of the libraries you are using are slow or resistant to being
linking into a run-time image.
As you've found, jpackage supports applications where everything is an
explicit module on the module path or applications where everything is
on the class path. I don't know if it has been explored so support a
hybrid configuration when it runs jlink to create a run-time image for a
closed subset of the modules and produces an application image that has
the rest of the modules in a directory. One thing that would help the
discussion is to prototype your idea, see what it means for an
application image and work through the additional complexity of the
command line options. The possible command line options to jpackage is
already very length and complications so one concern is that another
mode would put it over the edge when it comes to usability.
-Alan
