> On May 16, 2023, at 12:22 PM, Ron Pressler <ron.press...@oracle.com> wrote:
>
> At the core of your arguments is the claim — that we’ve heard told
> second-hand but rarely if ever reported first-hand — that the inability to
> control the command line is common. This claim is very important because its
> implications go well beyond the relatively niche issue of dynamically loaded
> agents, so I think it merits further discussion4. Certainly since the
> discontinuation of the centralised JRE deployment model in JDK 11, it’s been
> a deep assumption of Java’s design that deploying a Java application requires
> control of the command line. If you cannot control the command line, there
> are things you simply cannot do, including much more basic things than
> loading agents. If your application needs APM, surely it also needs control
> over the heap and GC with potentially new options.
The first thrust of Java deployment was Applets which used no “command line”
and automatically deployed and “secured” the Java environment. Next was the
automatic recognition of .jar files on the Windows environment (file type
mapping to invocation already existed) to just run “java -jar file.jar” for the
user, without explicit need to use the command line. Linux added a file type
handling in the kernel to make exec(2) able to launch jar files with “java -jar
file.jar” without explicit command line use.
Java “server” deployment still seems like the focus of these conversations with
little to no focus on all the other environmental details of how Java was
deployed and is still deployed using so many other available mechanisms.
> Those who restrict access to the command line will need to explain their
> constraints because that approach is already not viable. Deploying a Java
> application, certainly one that supports super-advanced uses such as the
> dynamic loading of agents for code manipulation, without control of the
> command line is not a model that the platform has supported for a while.
> Java’s deployment model changed some years ago, and policies that applied to
> the retired model do not apply for the new one and have to change (again,
> nothing to do with agents).
Running a jar file with a double click using a “default” model has been used
“forever.” I don’t know which “retired model” you are referring to. Perhaps
“applet” and “webstart” and some other mechanisms?
It really is possible to start a Java application without any command line use
still today.
> Since we’re talking about changes that only take place in new releases
> anyway, I find the notion that adding a command line flag is harder than
> adopting a new runtime version to be somewhat suspect, but if there’s a good
> reason for that, someone will need to present it.
I think the supposition that a piece of software may never be “finished” or
“complete” is incorrect. Especially with a URL class loader, it’s possible to
“update” and/or “evolve” an application without ever changing the “jar” file
that a user might have at hand, and be double clicking on to start.
> A service vendor that wishes to allow a Java program to use a new runtime and
> to create a child process that injects a native library into the parent
> process will need to explain why they cannot also allow that program to set
> command line flags. If you want to support JDK 11 and upward to enjoy new
> features and performance enhancements, you need to also support the changes
> to the deployment model that accompany these new developments.
I put my JNI shared libraries, for all OSes I support, in the jar file. When
the application is launched by a double click of the jar file, I use a
temporary file to copy the appropriate library into, and then load that JNI
code and use it. This is the mechanism that solves problems for USB connected
devices such as serial port dongles and other ways that I need to talk to the
OS code to make use of things that Java doesn’t do for us.
Gregg Wonderly
