Disallowing the dynamic loading of agents by default

[mark.reinhold at oracle.com]

2017/4/3 10:52:02 -0700, alasdair.nottingham at gmail.com:
> I’m the lead for WebSphere Liberty at IBM. Liberty uses a java agent,
> and this proposal will affect us. Our Java Agent is used to update the
> bytecode of our classes to add in instrumentation for debug logging
> and performance monitoring. In general it is attached via -javaagent,
> which wont be affected by this proposal. However there is one case
> where we do a dynamic attach of this agent. There is an industry trend
> towards running the application server as an uber-jar using java -jar
> <jar.name>. To support this in Liberty (in common with other
> application servers) our main method extracts the app server to disk
> at startup before bootstrapping the server from extracted jar
> files. One of the jar files extracted in this way is our Java agent,
> so we use the attach API to attach it so we get monitoring and debug
> logging. I had been thinking of expanding this to use the attach api
> in preference to -javaagent because that gets rid of this spurious
> error message from the mac JVM:
> 
> objc[56755]: Class JavaLaunchHelper is implemented in both
> /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/bin/java
> (0x10f4464c0) and
> /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/libinstrument.dylib
> (0x110dbb4e0). One of the two will be used. Which one is undefined.

Is getting rid of this spurious message (which, as Alan observed, has
been removed) your only motivation to load the agent dynamically?

> ...
> 
> I’d like to add my support to Andrew’s points. I think they are well
> made and cover my concerns with the proposals well. I’d like to add my
> thoughts as well though.

Thanks.  I think my reply to Andrew of a few minutes ago covers most of
your points too, so I won't repeat myself here.

> ...
> 
> Mark did ask for alternative proposals, so other than the defer to a
> future release option, what about allowing a developer to put
> something in the manifest.mf to enable dynamic attachment from the
> same JVM? If there is a concern over all or nothing being too broad
> the manifest entry could list a hash of the agent jar so the developer
> has to know about the agent a-priori.

I don't see how this would address the scenario of a dynamically-loaded
agent (for, say, performance monitoring) that's unknown to the original
library or application developer.  This seems to be an important use
case.

- Mark