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