- All Implemented Interfaces:
Due to the lazy class linking performed by many VMs, it is possible for a field or variable to be visible in a program before the associated class is loaded. Until the class is loaded all that is available is a signature string. If an attempt is made to set the value of such a field or variable from JDI, the appropriate type checking cannot be done because the destination class has not been loaded. The same is true for the element class of array elements.
It is not advisable to solve this problem by attempting a class load on the fly in this case. There are two problems in having the debugger load a class instead of waiting for it to load over the normal course of events.
- There can be no guarantee that running the appropriate class loader won't cause a deadlock in loading the class. Class loaders can consist of arbitrary Java programming language code and the class loading methods are usually synchronized. Most of the work done by a debugger happens when threads are suspended. If another application thread is suspended within the same class loader, a deadlock is very possible.
- Changing the order in which classes are normally loaded may either mask or reveal bugs in the application. An unintrusive debugger should strive to leave unchanged the behavior of the application being debugged.
Note that this exception will be thrown until the class in question is visible to the class loader of enclosing class. (That is, the class loader of the enclosing class must be an initiating class loader for the class in question.) See The Java Virtual Machine Specification for more details.
- See Also: