Re: jlink /Jigsaw for and with migrated legacy code

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: 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 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 for
> them and then put the 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 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.