Community
Participate
Working Groups
Build Identifier: 20100610-0636 This is a challenging bug to describe in words, but easy to provide a small project to reproduce it. When you have a class that implements a recursive interface and a second referenced interface, and you have a member variable in that class that of type another class that is also templated on the referenced interface, you get an internal compiler error: java.lang.NullPointerException. I also found that this happens on Eclipse 3.5.2 (20100218-1602), but the error is more descriptive: Internal compiler error: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.TypeBinding.findSuperTypeOriginatingFrom(TypeBinding.java:301). When searching on that message I found this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=288621 which was supposed to be fixed, but that was happening under different conditions so I can't be sure it's the same. Note that I have only tried this on OS X, but it seems like the type of bug that may appear in all operating systems. Reproducible: Always Steps to Reproduce: 1. Create a new Eclipse Java project with the following files (I used J2SE-1.5, but JavaSE-1.6 also exhibits the problem): AnotherClass.java: ----- public class AnotherClass<I extends IRecursiveInterface<? super I>> { } ----- ImplementingClass.java ----- public class ImplementingClass implements IRecursiveInterface<IReferencedInterface>, IReferencedInterface { private AnotherClass<IReferencedInterface> m_var; @Override public void setAnother(final AnotherClass<? extends IReferencedInterface> a) { m_var = a; } } ----- IRecursiveInterface.java: ----- public interface IRecursiveInterface<I extends IRecursiveInterface<? super I>> { void setAnother(final AnotherClass<? extends I> a); } ----- IReferencedInterface.java ----- public interface IReferencedInterface extends IRecursiveInterface<IReferencedInterface> { } ----- 2. Ensure that the Java Builder is the only builder. This should be the default. 3. When the compiler goes to build the project, you'll see the java.lang.NullPointerException referenced in the Details section.
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.
