Summary: | [search] ClassCastException during move class refactoring | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Karsten Panier <karsten.panier> | ||||
Component: | Core | Assignee: | Satyam Kandula <satyam.kandula> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | amj87.iitr, f.quadt, frederic_fusier, Olivier_Thomann, pascal, steffen.pingel, stuart_morris | ||||
Version: | 3.4 | ||||||
Target Milestone: | 3.8 M3 | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Karsten Panier
2008-07-23 12:11:56 EDT
Would it be possible to zip the project you were splitting? If not can you try to reduce it to a small project to help me to reproduce this exception? Of course the change you did help the refactoring to pass but it could be only a workaround and we definitely prefer find the origin of the problem to be sure that the fix shouldn't be located elsewhere... Thanks in advance The project to split is property of the company I work for. So I can't zip it. I'll try to reproduce the problem with a similar Project structure and attach it to this bug. I am getting a similar issue that might be related. When attempting to extract a class consisting of data members using refactor, I get this class cast exception: java.lang.reflect.InvocationTargetException at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:403) at org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2.run(RefactoringWizardDialog2.java:317) ... snip ... Caused by: java.lang.ClassCastException: org.eclipse.jdt.internal.core.search.matching.OrPattern cannot be cast to org.eclipse.jdt.internal.core.search.matching.VariablePattern at org.eclipse.jdt.internal.core.search.matching.MatchLocator.newFieldReferenceMatch(MatchLocator.java:1409) ... snip ... Could this be the same problem? Should I post the whole stack? (In reply to comment #3) > > Could this be the same problem? Should I post the whole stack? > No, this sounds like a different issue. Please open a new bug providing the full stack trace and a as simple test case as possible to help me to reproduce. Thanks *** Bug 336028 has been marked as a duplicate of this bug. *** *** Bug 352934 has been marked as a duplicate of this bug. *** (In reply to comment #6) > *** Bug 352934 has been marked as a duplicate of this bug. *** Hi. I just encountered the same issue today. I cannot move some classes to a different package. Neither a restart nor a deletion and reimport of this classes solves the issue. The only way to move those classes is on file-system but the error will occur again. After some testing it occurs that a @link ... in javadoc produces this error. Say I have a class Foo in org.test.foobar that is copied from another Class org.other.Foo that contains a {@link org.other.Foo}. So the copied class contains a @link to the old class.(see below for a scratch of the old and new class) Then moving the org.test.foobar.Foo causes the strange error. After removing the link to nowhere everything works fine. This seems to fit to the "MissingType..." thingy in the stacktrace. I hope that helps. Best regards, Florian Quadt The src-folder is under svn control and I am using mylyn.eclipse.buildId=I20110613-1736 ---------------------------------------------- class that is copied: package org.other; /** *{@link org.other.Foo} */ class Foo { } class that produces error: package org.test.foobar; /** *{@link org.other.Foo} */ class Foo { } (In reply to comment #7) Thanks for the detailed steps. I am able to reproduce the problem now. Simplifying the testcase. #### package org.test.foobar; /** *{@link org.missing.Foo} */ class Foo { } #### 1. Copy/paste this class 2. Make sure that javadoc is processed. 3. Move this class to another package. one should see the error. Created attachment 204192 [details]
Patch + test
Released the fix on master Commit id: 6ed1cf547d485640f7cc1b111de3d2b3735f006a Raised a follow up bug /361869 for some weird behaviour. Verified that no exception is thrown, using build N20111022-2000. |