Disallowing the dynamic loading of agents by default

[Seán Coffey]

Oracle has early access builds of jdk8u released at :

https://jdk8.java.net/download.html

JDK-8022291 is fixed in this ea release.

Regards,
Sean.

On 03/04/17 20:11, Alasdair Nottingham wrote:
> Yes that is really good. I was really happy to see that. I can’t wait for a Java 8 release that contains the fix (u121 on the mac does not). The reason I brought it up is because that long standing weird error message is resolved using the attach api to add the agent. I’m sure I’m not the only person to have realized this.
>
> Alasdair
>
>> On Apr 3, 2017, at 2:41 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>> On 03/04/2017 18:52, Alasdair Nottingham wrote:
>>
>>> Hi,
>>>
>>> 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.
>> Thanks for the mail on your usage. On the spurious message then this was this was  JDK-8022291 and has been fixed since jdk-9+127. The change has also been back-ported to jdk8u-dev.
>>
>> -Alan