Re: jlink /Jigsaw for and with migrated legacy code
// Redirecting to jigsaw-dev
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.