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

[Jochen Theodorou]

On 17.05.23 21:34, Gregg Wonderly wrote:
>
>
>> 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.

don't forget about  webstart. Now deprecated as well... but you mention
it later.

But frankly for me it was always shell scripts or something like that
starting the Java process. Some "magic" that had to be done here and
there. And if it is only supplying an exe with icon, or a special
certificate, that is only valid inside the company....

> 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.

Many seem to believe that the time for application servers is over and
you will now have probably microservices, each in its own native
compiled image. In one of my upcoming projects where I could use
something like this Java was not the primary candidate. We actually had
to defend that. Python and Go was what they wanted instead.

In the end I am speculating and - that goes really completely to Ross
here - I really would like to know what is the new development model and
the new deployment model that has been talked about so often here
already. And also for whom are those?

>> 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.

For me writing an application that requires my users to use the command
line means a loss of users. So then it would probably work like this...
I implement a mechanism by which a plugin for my application can tell me
what command line options it needs and I change a "starter" that will
then supply them. All automatic, the user will not see anything and
security is just as bad as ever

Applications just seem not to be a viable target anymore

bye Jochen