Bugzilla – Full Text Bug Listing
| Summary: | [1.5][compiler] NullPointerException encountered while running Java Builder | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Elmar Sonnenschein <develop> | ||||||
| Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | fast.jack | ||||||
| Version: | 3.1 | ||||||||
| Target Milestone: | 3.1 RC2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Elmar Sonnenschein
ps: Tested with 3.1RC1 Please provide steps to reproduce, then reopen. A parameterized member type cannot have a type not associated with an enclosing type. Suspecting the type of param type to not be a generic type, but rather another parameterized type. Would need a testcase to find offending scenario. Created attachment 21934 [details]
ZIP containing Eclipse 3.1RC1 project to reproduce the problem
Ok, I took the code apart and isolated the problem. The attachment contains a stripped down Eclipse project that should allow you to reproduce the problem. Changing and then recompiling the "RecordStringTransform.java" sourcecode (or that of a base class) causes the mentioned compiler error on my system on each second compilation. While digging into this I also found a way to prevent the compiler error. You'll find the necessary change in the "StringTransform.java" sourcecode, preceded with a comment containing "FIX:". It is a declaration that misses a generic type declaration (the project had been converted to JDK 5.0). But as far as I can see the code is not wrong without the declaration but just using the raw type. Thank you much. Created attachment 22182 [details]
Batch compiler test case that reproduces the problem
_test34 shows that the suggested workaround works
_test35 reproduces the problem on a small code base
_test36 shows that simplistic attempts to simplify _test35 fail to reproduce
the problem
Problem came from lazy enclosing type resolution. When needing the enclosing type (during UnresolvedReferenceBinding.setResolvedType(...)), the binary type didn't yet know it had any. Moved enclosingType init in BinaryTypeBinding constructor, and ensured all creator of ParameterizedTypeBinding specify an enclosing type if any (it is no longer ok to pass null, and rely on resolution later on, since the enclosingType is a criteria for reusing the binding in the cache). Added GenericTypeTest#test711-712 (adapted from proposed batch test 34&35). forgot to reassign fixed *** Bug 98232 has been marked as a duplicate of this bug. *** Verified for 3.1 RC2 using build N20050607-0010 + JDT/Core HEAD Verified with I20050610-0010 |