I ran into another tool that is broken with this proposal (someone can update
https://docs.google.com/document/d/19H1iGUnyI4Y40U5sNVAmH0uLxcpNfYSjPIW3s0Rv5Ss/edit?usp=sharing
again).
Mockito is now broken again. It's sad because they recently fixed the 2.x
version to run cleanly on JDK 9 and I had just upgraded for that reason.
The proposed use of java -jar or the command line property don't work because
mockito doesn't own either of these. It's buried deep in gradle calls junit
calls mockit. This particular set of tests is doing a fork per test.
The start a new process per occurrence is ugly if it works at all and we don't
really want every tool in my JVM to be doing this for performance and memory
reasons.
While a huge amount of JDK9 breakage is based on the one line sentence not to
use sun.* classes, this breakage doesn't fit. This is a documented feature
that was in fact enhanced to add this API in JDK 6.
Apparently a lot of products are using it to do self-attach and there is no
restriction on that for JDK 6-8.
This is admittedly a short term fix since there isn't time to do a correct fix
in JDK9 and it should wait until JDK 10 to be done correctly.
Caused by: java.io.IOException: Can not attach to current VM
at
jdk.attach/sun.tools.attach.HotSpotVirtualMachine.<init>(HotSpotVirtualMachine.java:75)
at
jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:56)
at
jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
at
jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
at
mockit.internal.startup.AgentLoader.attachToRunningVM(AgentLoader.java:146)
-----Original Message-----
From: Alan Bateman
Sent: Tuesday, April 11, 2017 3:01 AM
To: Stephen Felts; jigsaw-dev@openjdk.java.net
Subject: Re: Disallowing the dynamic loading of agents by default (revised)
On 11/04/2017 05:31, Stephen Felts wrote:
> The description below leaves out the " ancestor of the current process".
> Which way is it - do we need to start two processes or one to work around
> this?
>
The thread moved one from the original proposal. The only requirement now is
that the tool and target VMs are different.
-Alan
