Automatic modules and jpackage

[Mark Raynsford]

On Mon, 2023-11-27 at 14:42 +0000, Alan Bateman wrote:
> 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.

Yep. :)

> 
> 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.

Unfortunately, for some projects, they seem to have become the end of
the migration journey. "We've added an Automatic-Module-Name, we're
done!".

> It's unfortunate
> that some of the libraries you are using are slow or resistant to
> being 
> linking into a run-time image.

Sometimes it's just that their transitive dependencies haven't been
modularized and so they don't see the benefit in doing it themselves.
Others are also paranoid about keeping builds working on Java 8, even
though modern JDKs build Java 8 code better than JDK 8 ever did. :)

> 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.

That might be something I can take on! I'm taking a look at what my
schedule is like for 2024.

What I had in mind was something simpler than your description implied:
I'd actually aim for jlink to do no analysis whatsoever and simply
leave all of the JDK modules as they were. I'm not sure if jlink
or jpackage is responsible for branding the resulting executable
(adding a nice icon, and all that), but it might be that the resulting
app image is just a branded runtime with all of the normal JDK modules
untouched, and the extra application modules included in a directory.

As I mentioned in the blog, I feel like almost all of the functionality
might already be there (minus a way to get the runtime to use -p
instead of -cp internally), it's just that there doesn't appear to be a
way to get jpackage to skip one of the steps that causes the failure.

-- 
Mark Raynsford | https://www.io7m.com