Do people actually use jlink? (split from JNI discussion)

[Mantas Gridinas]

I second the hassle point about requiring entire project to be modular.
Sure it's neat when you're doing something from 0 but painful to figure out
what is missing. Might be an out of place question, but is there a flag to
dump all the loaded modules in the runtime to help jlink to capture them
even as unnamed or automatically named counterparts?

Another issue I encountered (and subsequently had SO question about) was
runtime's compatibility with host's  libc, but that can be chalked to my
own unawareness that there's more than glibc (ex. Alpine docker images
running muslc).


On Wed, Sep 6, 2023, 14:10 Stephen Colebourne <scolebourne at joda.org> wrote:

> On Wed, 6 Sept 2023 at 10:22, Ron Pressler <ron.pressler at oracle.com>
> wrote:
> > So we’ve worked for years on that and delivered a feature that allows
> any Java application to pick a runtime and configure it as it wishes
> (jlink). These days, if an application has difficulty choosing or
> configuring its runtime, it’s by choice. If lack of control over the
> runtime poses a problem for your application, why are you choosing not to
> control the runtime?
>
> I think it is important to ask how widespread usage of jlink actually
> is? Is this something the Oracle team has data on?
>
> The messaging I see around jlink is that it is only useful if every
> part of your application is modular. While this isn't accurate, it is
> true that it is more hassle when not everything is modular. Given that
> most people depend on open source libraries, and a lot of those
> (probably most) are not modular, my assumption is that most people
> don't use jlink? Trying to manually convert jars to be modular just to
> satisfy jlink seems like a fools errand / mad book-keeping exercise.
> Using a tool to convert jars seems to be injecting a step in the build
> pipeline that alters code, so that what you run isn't what you tested.
>
> (Most open source libraries are not modular as modules bring pain with
> no benefits to an open source library)
>
> When the Oracle team removed the JRE, my take is that most people just
> switched to deploying the JDK instead rather than adding jlink as a
> complication. But perhaps I'm wrong? Depending on a shared Java
> runtime still seems like a pretty normal model to me. Even if the
> shared runtime is in Docker.
>
> FWIW, I suspect deploying the JDK instead of the JRE is actually worse
> for security, which is ironic given all the discussion around the
> "threat" of native code.
>
> My concern here is that the Oracle team is making assumptions about
> how Java is deployed which aren't actually realistic.
>
> Stephen
> PS. IMO it is a design flaw that jlink can't handle non-modular jar files
> PPS: IMO it is a design flaw that there was a split between the
> classpath and modulepath
>
>
>
> > > On 5 Sep 2023, at 15:48, Peter Tribble <peter.tribble at gmail.com>
> wrote:
> > >
> > >
> > > That would be a pretty normal scenario.
> > >
> > > A new version of the Java runtime could be pushed to a user by:
> > >
> > > * The OS vendor, in a patch or update
> > > * If in an organization, by the organization's IT department
> > > * Ditto by an organization's security team
> > > * Installation of a different application that updates Java as a
> side-effect
> >
> > Sorry, I don’t understand. How *exactly* is your application launched so
> that it would use a different Java runtime when one was installed?
> >
> > By the way, we also speculate about how different users do different
> things. When it comes to feedback it’s, therefore, best to limit things to
> what you yourself experience. One concrete example of something you
> experience is much more valuable to us than four examples of things you
> think others may experience.
> >
> > >
> > > And probably a number of others. The point is that virtually none of
> us live in a
> > > perfect idealized world; we generally have to work under the
> assumption that our
> > > code could be used in a variety of different environments, including
> different java
> > > versions, and that we have no control whatsoever.
> > >
> >
> > True, and that is why people wanted — and rightly so — to allow
> applications to better pick a Java runtime and control it. So we’ve worked
> for years on that and delivered a feature that allows any Java application
> to pick a runtime and configure it as it wishes (jlink). These days, if an
> application has difficulty choosing or configuring its runtime, it’s by
> choice. If lack of control over the runtime poses a problem for your
> application, why are you choosing not to control the runtime?
> >
> > — Ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230906/bffd4b11/attachment.htm>