Community
Participate
Eclipse IDE
3.1-RC4 - have the CU I will attach - try to Refactor>Move Nested Type to New File on nested type 'Domain<T>' -> AFE: Caused by: org.eclipse.jdt.internal.corext.Assert$AssertionFailedException: null argument; at org.eclipse.jdt.internal.corext.Assert.isNotNull(Assert.java:108) at org.eclipse.jdt.internal.corext.Assert.isNotNull(Assert.java:86) at org.eclipse.jdt.internal.corext.refactoring.structure.MoveInnerToTopRefactoring.findTypeDeclaration(MoveInnerToTopRefactoring.java:406) at org.eclipse.jdt.internal.corext.refactoring.structure.MoveInnerToTopRefactoring.createNewSource(MoveInnerToTopRefactoring.java:1018) at org.eclipse.jdt.internal.corext.refactoring.structure.MoveInnerToTopRefactoring.createChangeManager(MoveInnerToTopRefactoring.java:839) at org.eclipse.jdt.internal.corext.refactoring.structure.MoveInnerToTopRefactoring.checkFinalConditions(MoveInnerToTopRefactoring.java:743) 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) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113)
Created attachment 24029 [details] PreferencesView.java Java file as described in comment 0.
Unfortunately, it's a regression: The AFE happens in situations where a top- level class contains more than one direct member type and the refactoring is not applied to the first one. It has nothing to do with generics and/or enums. All other cases work fine. Workaround is to move the class to be refactored to the first position within the top-level type.
Comment 2 is only partially correct: The following case works fine: public class Foo{ class Bar1{ } class Bar2{ } class Bar3{ } } Since the fix does not seem very easy and there is no general pattern to produce the failure, I suggest to leave this for 3.1.
I was finally able to track down the problem: During rewriting of the inner class, a new AST is created, but the ASTParser is not currently set up (only a call to setSource) The result is that the parser is trying to parse 5.0 code in 1.4 compliance mode. The enum keyword in the code example causes unrecoverable problems to the parser, which results in a compilation unit node where some the inner types after the enum appear as top-level types, causing the refactoring to fail. This defect is not an actual regression, since it is not caused by changes in the refactoring code, but by the fact that the setup of the ASTParser described above is not sufficent anymore for 5.0 code, but is still for 1.4. The fix is to call ASTParser#setProject(...) before creating the AST.
Will not fix for 3.1 for the following reasons: - inner enums or inner classes inside enums are both special cases - the refactoring fails, but does no harm I suggest to add this to the list of 3.1.1 bugs
The refactoring works correctly wrt. this bug for all <= 1.4 code. The only setup that is causing the AFE is a class which is moved out of a 5.0 compliant compilation unit where enums are declared with a source offset less than the offset of the class to be refactored. All other scenarios work fine.
Given this I opt to postpone the bug to 3.1.1.
Fixed in HEAD > 20050630
*** Bug 102483 has been marked as a duplicate of this bug. ***
Martin, can you please yote?
Dirk, can you please vote?
Tobias, can you please provide a patch we can vote on ?
Created attachment 25965 [details] proposed fix
patch looks good.
Patch looks good to me.
Fixed in 3.1.1 maintenance stream > 20050810
verifying...
verified the "Move to its own CU" refactoring works as expected in the described scenarios.
*** Bug 120432 has been marked as a duplicate of this bug. ***
