Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 196556 - NPE from ClassReader.findMethod inside NbBundleProcessor
NPE from ClassReader.findMethod inside NbBundleProcessor
Product: platform
Classification: Unclassified
Component: -- Other --
All All
: P2 (vote)
: 7.0
Assigned To: Jesse Glick
Depends on:
Blocks: 196104
  Show dependency treegraph
Reported: 2011-03-10 17:13 UTC by Jesse Glick
Modified: 2011-03-31 08:49 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2011-03-10 17:13:44 UTC
See bug #196104 comment #7. I still need to produce a small test case to file for the javac team. In the meantime some workaround is needed in the processor since halting the build for this is pretty annoying. Just catching the NPE and proceeding does not seem to suffice; it can result in incomplete output under some circumstances.
Comment 1 Jesse Glick 2011-03-10 18:29:56 UTC
Checking for previously used top-level classes in and examining them using ElementUtils.getTypeElement does not help as a fallback from the NPE, either: if the class was not already in RoundEnvironment.rootElements, its subelements annotated with @Messages will return null from getAnnotation(Messages.class) and an empty list from getAnnotationMirrors(). This is true even if no attempt was made to call PackageElement.getEnclosedElements... whereas examining elements not in the roundEnv normally (when PE.gEE succeeded) works, which is odd. Seems like when the bug precondition - something relating to nested inner classes - occurs, all sorts of parser state not in the roundEnv is just missing.

The only workaround I can think of is to catch the NPE and then fall back to the pre-679b6685185f behavior of appending to rather than regenerating it from sources.
Comment 2 Jesse Glick 2011-03-10 18:54:57 UTC
Using the abovementioned workaround in core-main #72fc5f310d23. I have tried incremental builds of various modules, and it seems to work:

1. Build succeeds. Warning is printed with offending line in javac.

2. Bundle.class in result contains all keys from the package, even for classes not passed to the javac command. In this case an additional note is added listing the identifiers read from the old Does not usually happen, but can be reproduced e.g. by

ant -f projectui/build.xml
ant -f projectuiapi/build.xml clean netbeans
ant -f projectui/build.xml
Comment 3 Quality Engineering 2011-03-11 09:41:43 UTC
Integrated into 'main-golden', will be available in build *201103110400* on (upload may still be in progress)
User: Jesse Glick <>
Log: #196556: working around javac bug.
Comment 4 Jesse Glick 2011-03-11 16:04:02 UTC
Need QE verification before sending to I guess? Not sure how to get that.
Comment 5 Jesse Glick 2011-03-15 16:29:35 UTC
This is 70_HR_FIX_CANDIDATE, am I supposed to get QE approval before submitting for review?
Comment 6 Marian Mirilovic 2011-03-15 18:07:11 UTC
(In reply to comment #5)
> This is 70_HR_FIX_CANDIDATE, am I supposed to get QE approval before submitting
> for review?

Ok, I agree with integration into release70 (you already tested it by your own Jesse, didn't you ?)
Comment 7 Jesse Glick 2011-03-15 22:59:32 UTC
Petr I think ran into this bug on some Hudson job because NBMs were built as a separate step after the regular build; some module JAR was apparently incorrectly recreated during the NBM build; thus when running the nbm target on a downstream module, the <depend> checker deleted some of the module's seemingly out-of-date classes, producing the precondition for this bug. Would be helpful to get a confirmation that this fix helps.
Comment 8 Tomas Zezula 2011-03-16 08:20:51 UTC
Seems fine to me.
Comment 9 Jesse Glick 2011-03-16 14:19:28 UTC
releases #9aea2746e2d6
Comment 10 Jesse Glick 2011-03-30 20:42:55 UTC
There are two problems turned up by investigation of the javac bug.

1. Under some conditions, <depend> leaves behind a nested class file such as OpenProjectList$4$1.class even when its enclosing OpenProjectList.class and OpenProjectList$4.class have been deleted. This has to be worked around in the build harness until <depend> can be fixed, since it breaks ClassReader. I filed for this. Also, JDK 7 will now be throwing BadClassFile rather than NullPointerException in this circumstance, so that needs to be caught as well.

2. Using PackageElement.getEnclosedElements() to scan neighboring top-level classes not in the round environment may work fine inside the IDE's parser, but it does not work from the command line when those classes are up to date in build/classes since @Messages has source retention and javac's ClassReader claims the annotation is missing, explaining the puzzle in comment #1. The effect is that Bundle.class is generated but with missing keys (producing NoSuchMethodError's at runtime). Not noticed before in unit test since it was not prepending dest dir to CP as actual build tools do. Fix is to use technique as in 72fc5f310d23 but all the time, even if no exception was thrown from javac.

Fixing these in core-main #8bcee3956dcc and will backport to releases if no problems turn up in continuous build.
Comment 11 Jesse Glick 2011-03-30 21:25:03 UTC
releases #757c24b3d78a
Comment 12 Quality Engineering 2011-03-31 08:49:24 UTC
Integrated into 'main-golden', will be available in build *201103310400* on (upload may still be in progress)
User: Jesse Glick <>
Log: #196556 (NbBundleProcessor problems in incremental builds) continued.
- work around Ant bug 51000 in <depend>
- catch BadClassFile
- deal with source retention of @Messages when *.class is newer than *.java

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo