[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-debug-dev] Problems with Eclipse JDI impl. on MacOS X
|
Andre,
This makes sense, however, we should also look into why the standard
library is being loaded.
jkca
|---------+------------------------------->
| | Andre Weinand |
| | <weinand@xxxxxxx> |
| | Sent by: |
| | jdt-debug-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 08/20/2002 04:03 PM |
| | Please respond to |
| | jdt-debug-dev |
| | |
|---------+------------------------------->
>---------------------------------------------------------------------------------------------------------------------|
| |
| To: jdt-debug-dev@xxxxxxxxxxx |
| cc: |
| Subject: [jdt-debug-dev] Problems with Eclipse JDI impl. on MacOS X |
>---------------------------------------------------------------------------------------------------------------------|
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
_______________________________________________
jdt-debug-dev mailing list
jdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev
