Community
Participate
Working Groups
3.1-RC1 test pass - have the type hierarchy below (note that the two type variables are not connected) - try to pull up sub from SubType to SuperType - get the JavaModelException below ------- SuperType.java --------- package com.example; public class SuperType<ELEM extends Number> { void add(ELEM e) { } ELEM get() { return null; } } ------- SubType.java ----------- package com.example; public class SubType<ELEM> extends SuperType<Integer> { void sub(Integer i) { add(i); } } -------------------------------- java.lang.reflect.InvocationTargetException at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:90) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113) Caused by: Java Model Exception: Java Model Status [add(Integer) {key=Lcom/example/SuperType;.add(TELEM;)V} [in SuperType [in [Working copy] SuperType.java [in com.example [in src [in Generics]]]]] does not exist] at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:468) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:499) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:232) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:218) at org.eclipse.jdt.internal.core.Member.getFlags(Member.java:147) at org.eclipse.jdt.internal.corext.refactoring.structure.MemberVisibilityAdjustor.adjustOutgoingVisibility(MemberVisibilityAdjustor.java:671) at org.eclipse.jdt.internal.corext.refactoring.structure.MemberVisibilityAdjustor.adjustOutgoingVisibility(MemberVisibilityAdjustor.java:690) at org.eclipse.jdt.internal.corext.refactoring.structure.MemberVisibilityAdjustor.adjustOutgoingVisibility(MemberVisibilityAdjustor.java:722) at org.eclipse.jdt.internal.corext.refactoring.structure.MemberVisibilityAdjustor.adjustVisibility(MemberVisibilityAdjustor.java:763) at org.eclipse.jdt.internal.corext.refactoring.structure.PullUpRefactoring.createChangeManager(PullUpRefactoring.java:949) at org.eclipse.jdt.internal.corext.refactoring.structure.PullUpRefactoring.checkFinalConditions(PullUpRefactoring.java:615) at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:84) at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:114) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1719) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:86) ... 1 more
Note (1): the same happens if SubType is not a generic type Note (2): the same works, if SubType.sub(Integer) does not call SuperType.add(ELEM). In this case, the method is correctly pulled up. The pulled up method still has an 'Integer' parameter type - one could expect that since the parameter type corresponds with the type argument to the superclass specification of SubType, the pull up operation could offer to convert the method and substitute ELEM as parameter type.
Re. the last note (2): Expanding the parameter type if it is the same as a type argument to the supertype would make 'Push Down' and 'Pull Up' symmetrical, as the conversion happens when pushing down: In the example, 'add(ELEM)' is pushed down to 'add(Integer)'.
Tobias, a candidate for 3.2. How risky is it to fix. I am asking since the visibility adjuster is used in several other places.
ad 1: Its a search problem, see bug 94160 ad 2: This must be fixed
Approved for RC2. If we have to change the MemberVisibilityAdjustor and it is a larger change then I would prefer that you review it since the code is used in Move member as well.
Just to clarify: Comment 0 is entirely covered by bug 94160, which does not involve any changes in JDT UI. The only thing to fix in the PullUp Refactoring is the renaming of the type parameters during pull up.
Thanks for clarification. You consider 94160 a must fix I guess.
Yes, the search engine seems to deliver incorrect resolved source methods.
Fixed > 20050606
Start verifying...
Verified that the exception doesn't occur anymore. However the generated result has a compile error in SuperType. Will open a separate bug report (see 99211).
