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

[Stephen Colebourne]

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