New candidate JEP: 451: Prepare to Disallow the Dynamic Loading of Agents

[Gregg Wonderly]

> On May 16, 2023, at 12:22 PM, Ron Pressler <ron.pressler at 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