jlink /Jigsaw for and with migrated legacy code

[Alex Buckley]

// Redirecting to jigsaw-dev

Hi Hannes,

On 11/15/2018 1:41 PM, Hannes H. wrote:
> I am new to this list and I apologize in advance if this is not the right
> place to bring this in the discussion.

No problem -- jdk-dev is for discussion of how the JDK is developed, 
though you wouldn't guess that from browsing 
http://mail.openjdk.java.net/mailman/listinfo. For issues and queries 
about how _your_ code may be developed in a modular fashion, jigsaw-dev 
is the right place.

> One of the reasons to migrate the code base was the idea to benefit from
> project Jigsaw by being able to bundle a runtime with the application. I do
> understand that a trimmed runtime will be only possible if the code base
> and all external dependencies are as well properly modularized. This is not
> the case, however, I still want to bundle a runtime with the distribution
> of the application even if it is the whole JDK.
>
> The last few days I read a lot about Jigsaw and jlink but the more I read
> the more I got the impression that the only possible way would be to run
> jdeps for each and every external dependency, create a module-info.java for
> them and then put the module-info.java into the JAR.
>
> That leads to my two main questions:
>
> (1) Is my assumption right that there is no other way to bundle legacy
> (=not yet modularized) code with a runtime?

Yes. Note that we never recommend creating module-info.java files for 
someone else's JAR -- neither you nor jdeps can be expected to fully 
understand its dependencies.

> (2) If (1) is true, why has this - very common - case not be targeted yet?

A goal of Jigsaw was "reliable dependencies". Things wouldn't be very 
reliable if a runtime built with jlink had "dangling references" to code 
that is not in the runtime and whose JARs you have to remember to put on 
the classpath of the runtime.

That's also why you can't jlink automatic modules into a runtime -- they 
might depend on the right JARs being put on the classpath.

You can jlink a runtime consisting of the JDK modules that are needed by 
your application + its dependencies -- that's usually in the realm of 
what jdeps can figure out -- and then run your application on the new 
runtime exactly as if you were running on a newly-downloaded JDK. As 
your dependencies release modular JARs (i.e., containing 
module-info.class, not just Automatic-Module-Name in the manifest), you 
can jlink them into the runtime too.

Alex