Minor thoughts (Re: [External] : Re: JEP draft: Prepare to Restrict The Use of JNI

[Glavo]

>
> Why? You can now easily pick whichever runtime you want (a minimal one is
> only 40MB!) and not require the end user to install Java or even know that
> your application is written in Java. Also, the proposed change would have
> no impact on anyone using a client JRE (8 is the *highest* version for
> which a JRE is available).
>

At least for us, 40M is very large.

We have an application, and we carefully ensure that the application size
is within 5MB.
An increase in program size means a multifold increase in server network
expenditures.
Not all parts of the world have the same cheap internet access, nor are
free CDNs available everywhere.

Also, jimage is not suitable for all scenarios.
We provide support for Windows (x86, x86-64, ARM64), Linux
(x86, x86-64, ARM32, ARM64, MIPS64EL, LoongArch64, RISC-V 64), macOS
(x86-64, ARM64) equally.
We only need to distribute a jar file of less than 5MB to work on these
platforms.
jlink? Do you mean we have to distribute a dozen huge programs at a time?

However, this JEP will not have any impact on us, because we are using the
shadow jar plugin, so we only need to modify the MANIFEST.MF.
But we are looking forward to a better alternative than shadow jar.
I think it is an unfortunate fact that the module path and classpath must
be specified, and many people want to get rid of it,
which is why the shadow jar plugin is so popular.
So I don't think "the Java program already needs a lot of options" is a
reason to keep adding more options that have to be used.
Why can't we integrate this information inside the program?
When we have to use startup scripts, we sacrifice some cross-platform
capabilities, and make it harder for users to configure the JVM in a
standard way.
They have to use the one provided by the script, or the JAVA_TOOL_OPTIONS
environment variable.
Before that, they need to distinguish between "necessary options for the
program" and "unnecessary tuning options" provided by default by scripts
mixed together,
carefully avoid their options conflicting with the default options.
In addition, since the startup script and the program bytecode are not
bundled in the same file, users may mistakenly update only part of the
program,
resulting in a mismatch between the startup script and the program, causing
the program to crash during runtime.

jlink and jpackage are suitable for some scenarios, but they are not
suitable for many scenarios.
Many times, a single file that does not require complex configuration, is
not bundled with JRE, and can be directly cross-platform is more popular.
We are looking forward to an official replacement for the shadow jar so
that we can use JPMS more.

Glavo







On Wed, Sep 6, 2023 at 7:37 PM Ron Pressler <ron.pressler at oracle.com> wrote:

>
>
> > 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/e494edff/attachment-0001.htm>