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.

Bug 177536

Summary: "Uncompilable source code - cannot find symbol" thrown unnecessarily from <clinit>
Product: java Reporter: Jesse Glick <jglick>
Component: CompilerAssignee: Dusan Balek <dbalek>
Status: NEW ---    
Severity: normal    
Priority: P3    
Version: 8.2   
Hardware: HP   
OS: Windows 10 x64   
Issue Type: DEFECT Exception Reporter: java.lang.RuntimeException: Uncompilable source code - cannot find symbol
Bug Depends on:    
Bug Blocks: 177537    

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.