bility and need to attach a
> serviceability agent for deep troubleshooting beyond what’s possible
> without dynamically loaded agents (especially with no access to the
> sources), but if they do then surely they’re also able to add the
> -XX:+EnableDynamicAgentLoading flag.
>
> — Ron
&
The JDK *allows* bundling a JVM since 9 and makes it *possible* since about
15 (jpackage), but still doesn't make it *easy* like throwing a JAR around
was easy. Although you discuss market demand here, the market isn't really
united on what it wants in this case.
Eliminating deployment complexity
> we’ve begun to explore means other than the flag to allow a tool to load an
> agent at runtime
How about restricting access to the jcmd socket. For in-VM code it can
be blocked at the filesystem implementation level, and for
sub-processes by using the operating system APIs to determine if the
o
Why, well, you get more features, it's easier for the end user, and
not any harder for the developer. Those are pretty concrete reasons
why people would want to do it that way. I'd suggest trying Conveyor
out yourself before worrying about rigging or customization, because
straightforward Java apps
Hi Gregg,
Distributing little apps as JARs indeed doesn't work well anymore out
of the box, but it doesn't have to be the end of the line for them.
I've spent a couple of years writing a tool designed explicitly to
solve all these problems [1]. You give Conveyor your JARs (or a
Maven/Gradle build)
