Community
Participate
Working Groups
Refactor/Rename (attepting to rename a class) fails, mentioning an illegal class name. There once was a file with that name, but it was deleted through the eclipse UI. There doesn't seem to be any way to clear this error. -- Root exception: org.eclipse.jdt.internal.core.Assert$AssertionFailedException: Assertion failed; The source type has an invalid name: HexGameBoard.1.12.2.4 at org.eclipse.jdt.internal.core.Assert.isTrue(Assert.java:89) at org.eclipse.jdt.internal.core.SourceType.<init>(SourceType.java:43) at org.eclipse.jdt.internal.core.CompilationUnit.getType(CompilationUnit.java:807) at org.eclipse.jdt.internal.core.search.matching.PossibleMatch.getQualifiedName(PossibleMatch.java:103) at org.eclipse.jdt.internal.core.search.matching.PossibleMatch.<init>(PossibleMatch.java:41) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1110) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:208) at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:424) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:532) at org.eclipse.jdt.internal.corext.refactoring.RefactoringSearchEngine.internalSearch(RefactoringSearchEngine.java:130) at org.eclipse.jdt.internal.corext.refactoring.RefactoringSearchEngine.search(RefactoringSearchEngine.java:104) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameTypeProcessor.checkFinalConditions(RenameTypeProcessor.java:320) at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:169) 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.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:189) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1721) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:86) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113)
What is the eclipse build ID you're using? Is there any chance to try to update with 3.2 M5 (freshly available) and see if this problem still occurs. As indexes will be automatically regenerated on this milestones problem may be fixed if it comes from an invalid index file...
some cache seems to be permanantly polluted with the bad name. I'd really like to know which one and how to clear it. I'm pretty sure the invalid name got into the system when I did a refresh on the directory, and it contained an old version of a file with that name left there by CVS. The file contained an otherwise valid class, but the class name was valid.
Version: 3.1.2 Build id: M20060118-1600
I downloaded 3.2.5 and tried it. The rebuilding of caches as a result of the switch from 3.1.2 may have cleared the error, but when I recreated the original conditions that led to the error, the same error occurred again. There are two problems here. An illegal class name such as "HexGameBoard.1.12.2.4" should not have been inserted into the cache in the first place. And once there, it shouldn't persist and cause this breakdown. -- Root exception: org.eclipse.jdt.internal.core.Assert$AssertionFailedException: Assertion failed; The source type has an invalid name: HexGameBoard.1.12.2.4 at org.eclipse.jdt.internal.core.Assert.isTrue(Assert.java:89) at org.eclipse.jdt.internal.core.SourceType.<init>(SourceType.java:43) at org.eclipse.jdt.internal.core.CompilationUnit.getType(CompilationUnit.java:820) at org.eclipse.jdt.internal.core.CompilationUnit.findPrimaryType(CompilationUnit.java:520) at org.eclipse.jdt.internal.debug.core.refactoring.BreakpointRenameTypeParticipant.gatherChanges(BreakpointRenameTypeParticipant.java:58) at org.eclipse.jdt.internal.debug.core.refactoring.BreakpointRenameParticipant.createChange(BreakpointRenameParticipant.java:99) at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.createChange(ProcessorBasedRefactoring.java:249) at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:128) at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:189) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1733) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113)
Can you provide steps which reproduce this problem easily? This would be really helpful for me to understand what happen exactly here... Thanks
I think you can produce this easily in any workspace. Duplicate any class file, give class x.java a name such as x.1.2.java. Use "refresh" to cause eclipse to add x.1.2.java to your workspace. Now try to use rename/refactor to change the class name inside x.1.2.java to newx.java
(In reply to comment #6) > I think you can produce this easily in any workspace. Duplicate any class > file, give class x.java a name such as x.1.2.java. Use "refresh" to cause > eclipse to add x.1.2.java to your workspace. Now try to use rename/refactor > to change the class name inside x.1.2.java to newx.java > I got no problem with this scenario. When I click on refresh button x.1.2.java is not on the classpath. This is expected behavior as 1.2.java is not a java file extension. Then I can refactor this non-java resources as newx.java and see after this refactoring that the new file is now shown under the default package considered (its new name make it as a Java resource now...). I done this test with 3.2 M5 and 3.1.2 and both succeeded. Do you have any special settings on your project to have a different behavior?
Please reopen while providing requested info, thanks
