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 - "Uncompilable source code - cannot find symbol" thrown unnecessarily from <clinit>
Summary: "Uncompilable source code - cannot find symbol" thrown unnecessarily from <cl...
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Compiler (show other bugs)
Version: 8.2
Hardware: HP Windows 10 x64
: P3 normal (vote)
Assignee: Dusan Balek
Depends on:
Blocks: 177537
  Show dependency tree
Reported: 2009-11-24 10:25 UTC by Jesse Glick
Modified: 2018-11-30 22:28 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter: java.lang.RuntimeException: Uncompilable source code - cannot find symbol


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2009-11-24 10:25:31 UTC
Running hudson/trunk/main/test/src/test/java/hudson/slaves/ 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
        at hudson.Functions.<clinit>(

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.