Community
Participate
Working Groups
I got a NPE when trying to rename an interface method. Investigating the issue I noticed that null can be put in a type hierarchy in the case this.builder.getHandle(this.typeModels[t], interfaceBinding); return null. See org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.findSuperInterfaces(IGenericType, ReferenceBinding) I could not end up creating a small test case that exhibits the problem, but I have a workspace that is broken because of this. Here is the stack trace I got: ... Root exception: java.lang.NullPointerException at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.isInterface(TypeHierarchy.java:1042) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getSuperclass(TypeHierarchy.java:656) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.getSupertypes(TypeHierarchy.java:675) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.uniteWithSupertypes(RippleMethodFinder2.java:397) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.uniteWithSupertypes(RippleMethodFinder2.java:403) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.createUnionFind(RippleMethodFinder2.java:384) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.findAllRippleMethods(RippleMethodFinder2.java:196) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.getAllRippleMethods(RippleMethodFinder2.java:168) at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.getRelatedMethods(RippleMethodFinder2.java:161) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameMethodProcessor.initializeMethodsToRename(RenameMethodProcessor.java:236) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameMethodProcessor.doCheckFinalConditions(RenameMethodProcessor.java:360) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameVirtualMethodProcessor.doCheckFinalConditions(RenameVirtualMethodProcessor.java:143) at org.eclipse.jdt.internal.corext.refactoring.rename.JavaRenameProcessor.checkFinalConditions(JavaRenameProcessor.java:46) at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:224) at org.eclipse.ltk.core.refactoring.Refactoring.checkAllConditions(Refactoring.java:160) at org.eclipse.jdt.internal.ui.refactoring.RefactoringExecutionHelper$Operation.run(RefactoringExecutionHelper.java:80) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:4662) at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:106) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Created attachment 131823 [details] Proposed fix Possible fix? Jérôme, please review.
I believe the problem comes from the fact that the type org.eclipse.jdt.launching.sourcelookup.containers.JavaSourcePathComputer has also a method getId(). I tried to rename a method getId() to getTimestamp(). No idea why that unrelated type is checked, but this is causing the NPE. Surprisingly enough, I can properly open the type hierarchy for org.eclipse.jdt.launching.sourcelookup.containers.JavaSourcePathComputer without getting an exception with or without the patch.
Would be nice to get this reviewed for 3.5M7.
Fix looks good. A regression test would be awesome.
I could not extract a regression test so far. I'll release the fix today as this is fixing a real bug.
Released patch for 3.5M7. No regression test so far.
Verified for 3.5M7 by reading the code
