Bugzilla – Full Text Bug Listing
| Summary: | Internal compiler error: java.lang.NullPointerException with a specific use of recursive generics | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Missing name <phineas919> | ||||||||
| Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> | ||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | P3 | CC: | amj87.iitr, Olivier_Thomann, rsitze, srikanth_sankaran, stephan.herrmann | ||||||||
| Version: | 3.6 | Flags: | Olivier_Thomann:
review+
|
||||||||
| Target Milestone: | 3.6.1 | ||||||||||
| Hardware: | Macintosh | ||||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Missing name
Created attachment 171919 [details]
Test project to reproduce java.lang.NullPointerException compiler error
Changed version to 3.6. Apologies if I've dropped this in the wrong place. I'll follow up. Created attachment 172092 [details]
Proposed patch
Created attachment 172093 [details]
Proposed patch
Earlier patch got truncated for some reason. Reposting.
Olivier, The proposed patch is simple and the change being made to org.eclipse.jdt.internal.compiler.lookup.TypeBinding.findSuperTypeOriginatingFrom(TypeBinding) is along the lines of existing protective code in org.eclipse.jdt.internal.compiler.lookup.TypeBinding.findSuperTypeOriginatingFrom(int, boolean). It fixes a crash which halts build with a compiler error. I think this is safe for 3.6.1, do you agree ? Please take a look at the patch from a 3.6.1 candidate p.o.v - Thanks. Released in HEAD for 3.7 M1. Will release in 3.6 maintenance stream if needed. (In reply to comment #8) > Released in HEAD for 3.7 M1. > Will release in 3.6 maintenance stream if needed. Personally, I worked around it for now, so I don't absolutely need it in 3.6. Things may change if someone else runs into it. Thanks for the fix. (In reply to comment #6) > I think this is safe for 3.6.1, do you agree ? yes, +1 for 3.6.1. Olivier, please update the review flag. Released in 3.6 maintenance stream for 3.6.1. One thing I don't understand: the majority of all callers of superInterfaces() now check for null before dereferencing, but I still count at least 10 callers that would actually break (NPE) if null is returned. Do you have a rule saying when it is safe to expect non-null, or should the remaining 10 or so callers be protected, too?? One interesting comment I found in ClassScope: // in code assist cases when source types are added late, may not be finished connecting hierarchy (In reply to comment #12) > Do you have a rule saying when it is safe to expect non-null, > or should the remaining 10 or so callers be protected, too?? > > One interesting comment I found in ClassScope: > // in code assist cases when source types are added late, may not be finished > connecting hierarchy By looking at the write references to the field, one can conclude when it is safe not to check for null. As the comment you referenced indicates (and as can be double checked by studying the write accesses), once type hierarchy is connected, org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.superInterfaces is guaranteed to be not null. However, such avoiding of null checks requires more understanding of the code than I have right now, presumably the instances where null check is missing some one reasonably felt sure it is ok - not always correctly of course. Verified for 3.7M1 using build I20100802-1800. *** Bug 321918 has been marked as a duplicate of this bug. *** (In reply to comment #11) > Released in 3.6 maintenance stream for 3.6.1. Much appreciated. The recursive generics matches my situation. I'm confident the fix will help resolve my issue. The impact of this should not be minimized: * any class referencing such an interface from within the same project seems to be fine. * any class in another project that references such an interface is broken... - F3 fails for pretty much everything in the class - Ctrl+Space for content-assist causes an error (same NullPointerException). - Any "automatic" content-assist while entering java code brings up the error. - Content-assist errors are on *any* java reference, not necessarily related to the recursive generics-interface. It becomes painful (errors popping up) just to enter/edit code, never mind "navigate" out of such a file. The buggy code seems to be on a nexus of GUI interaction. I want to say *everything* is broken... but it only seems that way. Unfortunately, I'm not in a position to work around this... so I'm working "through" it (disabling content-assist helps eliminate the pop-up errors, but does nothing for the quick navigation I'm use to). 3.5 (as noted above somewhere) is also broken. I feel I'm in the dark ages. How/when/where can I pickup an snapshot/early-update of the 3.6.1 maintenance stream, or at least the JDT Core stream, that'll give me back my Eclipse?! (In reply to comment #16) > I feel I'm in the dark ages. How/when/where can I pickup an > snapshot/early-update of the 3.6.1 maintenance stream, or at least the JDT Core > stream, that'll give me back my Eclipse?! This is fixed in M-builds since this build: Eclipse SDK 3.6.1 - July 7, 2010. So if you grab the latest M-build, it should work without a problem. Hope this help. |