> On 17 May 2023, at 20:34, Gregg Wonderly <gregg...@cox.net> wrote: > > 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.
Because we must balance users’ *conflicting* requirements (which make it impossible to fully satisfy all users all the time), we must prioritise requirements based on the current (and expected future) landscape of the environment, which changes over time. As big as Java is, its ability to shape the software ecosystem’s fashions is limited, and Java must adapt to them. We sometimes need to meet the software market's demands rather than try to dictate them. Still, even when we change things, we try to give users time to adapt. > >> 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. Sure, but technically *simple* Java applications that, for example, can’t set their GC configuration or even select their runtime version. These are not applications that commonly require injecting agents into them at runtime. > >> 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. I’m not sure I see the relevance of that to this JEP, but the need to control Java’s dynamism (in the sense that the application must opt into unrestricted dynamism) is one of those shifts in focus that have occurred over the past few years. The informational JEP explains how things that mattered less in the past matter more now and vice versa due to changes in the environment: https://openjdk.org/jeps/8305968#Why-Now? > >> 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. > What I was referring to here wasn’t JNI, but injecting a native JVM TI agent into an already-running Java program by means of a child process. JNI is unaffected by this JEP. More generally, we often provide alternatives to command-line options as manifest attributes on *executable* JARs: we’ve done that in the case of agents (the Launcher-Agent-Class attribute can replace the -javaagent flag), we’ve done that in the case of exports (the Add-Exports attribute can replace the --add-exports flag), we’ve done that in the case of opens (the Add-Opens attribute can replace the --add-opens flag), and we may do it when we require a flag to use JNI (not in this JEP), so even when we do require a flag to use JNI or its preferred alternative, FFM (again — not in this JEP), we may be able to accommodate your use case, too. But keep in mind that since Java has shifted away from the JRE model, self-contained Java applications are encouraged to use jlink to embed their own runtime and pick their arbitrary command-line options rather than rely on executable JARs and require the user to have a pre-installed Java runtime. — Ron
