Community
Participate
Working Groups
To reproduce: - Open a .aj file in the editor - Delete the file - Create a new .aj file of the same name in the same package - An message appears saying "The file has changed on disk - do you want to load the new version?" To reprodice with a project: - Install the TJP example - Open GetInfo in the editor - Delete the TJP project - Re-install the TJP example - Try to open GetInfo again. - The message described above pops up
This also has consequences for refactoring in plain java projects: - create a java project that contains one class C - Install the TJP example - Open GetInfo in the editor - Delete the TJP project - Rename the class C by right clicking on C and do Refactor > Rename This causes a StringOutOfBoundsException: Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1768) at org.eclipse.jdt.internal.core.util.Util.getNameWithoutJavaLikeExtension(Util.java:839) at org.eclipse.jdt.internal.core.search.matching.PossibleMatch.getQualifiedName(PossibleMatch.java:101) 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:1097) 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.findAffectedCompilationUnits(RefactoringSearchEngine.java:72) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameTypeProcessor.checkConflictingTypes(RenameTypeProcessor.java:593) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameTypeProcessor.analyzeAffectedCompilationUnits(RenameTypeProcessor.java:584) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameTypeProcessor.checkFinalConditions(RenameTypeProcessor.java:330) at org.eclipse.jdt.internal.corext.refactoring.rename.RenameCompilationUnitProcessor.checkFinalConditions(RenameCompilationUnitProcessor.java:258) 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:1719) at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:86) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113)
The problem that caused this bug was that dispose() was called on the editor after the CompilationUnit had been deleted. This meant that the editor was unable to call discardWorkingCopy() on the CompilationUnit. This seems to have been fixed in Eclipse 3.1, so AJDT 1.3 will contain a complete fix for this bug. I have added a partial fix in AJDT 1.2.1 by adding a DeleteParticipant. The participant is notified of deletes and so it is able to close any open editors before the corresponding CompilationUnits are deleted. Unfortunately DeleteParticipants do not seem to be able to be notified of projects being deleted, which is why this is a partial fix. So if you have a file open in the AspectJ editor and you delete either the file, its package or its source folder the working copy will also be deleted. If you delete the parent project the working copy will not be deleted in AJDT 1.2.1.
I've just retried the steps in comment #1 and the StringOutOfBoundsException is still happening (I've tried with the latest AJDT on Eclipse 3.1). However, as Sian said, the original problem has been fixed. Therefore, maybe my original thought on the relationship between these two issues is wrong. The stack trace I reported is the same as that on bug 98547 - I'm therefore adding this comment to that bug.
