[jdt-debug-dev] Problems with Eclipse JDI impl. on MacOS X

[Andre Weinand <weinand@xxxxxxx>]

Hi,

I'm porting Eclipse to MacOS X and I'm running into a problem with 
Eclipse's dependency on a non-standard JDI library that implements a 
1.4.x method even if running on 1.3.1:

Whenever I debug from within Eclipse on MacOS X I get the following stacktrace:

java.lang.NoSuchMethodError
    at 
org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.supportsJDKHotCodeReplace(JDIDebugTarget.java:560)
    at 
org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.supportsHotCodeReplace(JDIDebugTarget.java:533)
    ...

The method that cannot be found is VirtualMachine.canRedefineClasses().
It is a 1.4.x method that is implemented in Eclipse's implementation 
of the JDI library and it is assumed that
this library hides any standard 1.3.1 JDI library available on the platform.

On MacOS X however, the standard library is loaded very early in the 
startup process from the boot classpath (I'm not really sure why, but 
I cannot prevent it). So the Eclipse classloader has no chance to 
hide the standard library with the Eclipse version. Because the 
standard library conforms to the 1.3.1 specs and does not define the 
VirtualMachine.canRedefineClasses() method the error occurs.

The workaround is to prepend Eclipse's implementation of the JDI 
library (jdi.jar) to the bootclasspath via the -Xbootclasspath/p: 
commmand line option. But this does not seem to be a robust solution.

Wouldn't it be possible to use reflection to find out whether hot 
code replacement is available? The debugger seems to depend only on a 
single non-standard method. So the additional reflection code to 
protect this call seems to be fairly small. The benefit would be to 
eliminate any dependencies on a non-standard library and to make the 
debugger less brittle.

Does this make sense?
If yes, I would file a bug report.

--andre