Community
Participate
Working Groups
When compiling in 1.6 mode, if several units have been retrieved through accept(ICompilationUnit) in the compiler, the processAnnotations loop is boggus. It is using this.unitsToProcess.length for the top value instead of this.totalUnits. The consequence is: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:659) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:374) at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:3411) at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1565) at org.eclipse.jdt.core.tools.compiler.Compile.main(Compile.java:94) This should be backported to 3.3.2.
Created attachment 82968 [details] Proposed fix
Moving to JDT/Core as the loop in located in the Compiler itself.
Created attachment 82983 [details] Proposed fix
Released for 3.4M4. Walter, please verify. Thank you. The last patch also includes the regression test. Philippe, I think this is worth being backported to 3.3.2 since it is causing a bad NPE.
Created attachment 82985 [details] Proposed fix I forgot to include the corresponding change in the EclipseFileManager located in compiler.apt in the last patch.
With the patch, all tests pass and manual testing of the product, including file generation with both Java 5 and Java 6 processors active, appears to work correctly. I am +1 for putting this into 3.3.2. One very small comment: It would be nice to rename the "iterable" variable in EclipseFileManager to something more descriptive, like "oldClasspath". Further discussion: This bug is very closely related to bug 203454; the fix is in the same algorithm. Perhaps this code is tricky because it is trying to maintain a complex data structure, without a layer of abstraction? I think the data structure here is functionally equivalent to a linked list. Even if the existing array implementation is necessary for speed and/or size, perhaps the code should be refactored to abstract the data structure into a separate class, that would be easier to understand, test, and maintain.
This is a complement for bug 203454. I missed it when fixing bug 203454. The steps to get it are not exactly the same.
*** Bug 207944 has been marked as a duplicate of this bug. ***
Philippe, +1 for 3.3.2? The export test case from bug 207944 could be used to verify it. I would not backport the regression test from HEAD since it implies many changes in the apt tests. The fix itself is a one line change.
+1 for 3.3.2
Verified for 3.4M4.
The request for 3.3.2 is due to the following reasons: - NPE is thrown - fix is trivial and implies no risk - this can occur as soon as compiling the first compilation unit requests more units through the accept method. If the number of requested units is lower than the unitsToProcess size, the NPE will occur. - it is not easy for the user to find out what is going on.
Reopen for 3.3.2 release.
Released for 3.3.2. The regression tests is not backported as it implies too many changes for 3.3.2 in the test suite. The test case in bug 207944 should be used to verify it.
Verified for 3.3.2 using build M20080123-0800. Note: the bug reproduction using the test case of bug 207944 seems to need that a fresh workspace be used (at least, I consistently failed to reproduce it when starting with a non-empty workspace and eclipse-SDK-M20070905-1045, while I reproduced it without problem when using the same build on a fresh workspace).
*** Bug 236255 has been marked as a duplicate of this bug. ***
