Bug 196556

Checking for previously used top-level classes in Bundle.java 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 Bundle.java rather than regenerating it from sources.

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 Bundle.java. 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

Integrated into 'main-golden', will be available in build *201103110400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/72fc5f310d23
User: Jesse Glick <jglick@netbeans.org>
Log: #196556: working around javac bug.

Need QE verification before sending to reviewers@nb.org I guess? Not sure how to get that.

This is 70_HR_FIX_CANDIDATE, am I supposed to get QE approval before submitting for review?

(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 ?)

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.

Seems fine to me.

releases #9aea2746e2d6

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 https://issues.apache.org/bugzilla/show_bug.cgi?id=51000 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.

releases #757c24b3d78a

Integrated into 'main-golden', will be available in build *201103310400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/8bcee3956dcc
User: Jesse Glick <jglick@netbeans.org>
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