This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
|Summary:||"Uncompilable source code - cannot find symbol" thrown unnecessarily from <clinit>|
|Product:||java||Reporter:||Jesse Glick <jglick>|
|Component:||Compiler||Assignee:||Dusan Balek <dbalek>|
|OS:||Windows 10 x64|
|Issue Type:||DEFECT||Exception Reporter:||java.lang.RuntimeException: Uncompilable source code - cannot find symbol|
|Bug Depends on:|
Description Jesse Glick 2009-11-24 10:25:31 UTC
Running hudson/trunk/main/test/src/test/java/hudson/slaves/NodeProvisionerTest.java using CoS with IDE on JDK 5 (continue even though sources "have errors"), the test passes but there are various errors such as java.lang.RuntimeException: Uncompilable source code - cannot find symbol symbol: class LockInfo location: package java.lang.management at hudson.Functions.<clinit>(Functions.java:91) The line in question is merely an import statement, not really code. In fact LockInfo is only used inside one method (dumpThreadInfo) which would not have been called at all, so there is no reason to interrupt the test run. Please do not generate exceptions in a dummy static initializer just because of unknown imports.
Comment 1 Jesse Glick 2009-11-24 10:30:27 UTC
Workaround: use FQNs in the method body rather than imports for the JDK 6-only classes.
Comment 2 Jan Lahoda 2009-11-27 05:06:34 UTC
Well, the compiler is obliged to generate the executable code in such a way, that it throws an exception before the execution arrives at the point of the compile-time error (or not to generate the executable code at all for code with compile-time error). For un-resolvable imports, it may be non-trivial to throw the exception at some other point than in clinit (esp. for unused imports).
Comment 3 Jesse Glick 2009-11-27 09:35:23 UTC
For unused imports, do not generate anything; there is no executable code to fail. For used imports, I agree this could be trickier to implement, but at least the correct behavior is pretty clear: throw a NoClassDefFoundError immediately before the line that would have used that import.