Community
Participate
Working Groups
With AJDT (AspectJ dev tools) installed users are reporting exceptions like this: 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) See AJDT bug 98547 for more details of the scenarios in which this occurs. Note that the problem can happen in regular Java projects, but of course only with AJDT in the picture. This happens because AJDT defines subtypes of CompilationUnit for aspects contained in .aj files. Util.getNameWithoutJavaLikeExtension (in the "model" source folder) currently looks like this: /** * Returns the substring of the given file name, ending at the start of a Java like extension. */ public static String getNameWithoutJavaLikeExtension(String fileName) { int index = indexOfJavaLikeExtension(fileName); return fileName.substring(0, index); } So it is getting called with a name like "MyAspect.aj", and the indexOfJavaLikeExtension() method is then returning -1, resulting in the out of bounds exception on the next line. The fix is therefore to simply make the method more robust, such as: /** * Returns the substring of the given file name, ending at the start of a * Java like extension. The entire file name is returned if it doesn't end * with a Java like extension. */ public static String getNameWithoutJavaLikeExtension(String fileName) { int index = indexOfJavaLikeExtension(fileName); if (index == -1) { return fileName; } return fileName.substring(0, index); }
Applied proposed fix and added regression test CompilationUnitTest#testNameWithoutJavaLikeExtension()
Hi Jerome, Thanks for the quick fix. Is there any possibility of also getting the fix into 3.1.1? This is a big deal for us as it can mean that with AJDT installed, Java searches can stop working completely, requiring a workbench restart.
Philippe, can I backport this to 3.1.1 ?
*** Bug 108089 has been marked as a duplicate of this bug. ***
*** Bug 108252 has been marked as a duplicate of this bug. ***
Philippe, This problem has resulted in about 10 separate bug reports now, and it will most likely result in many more if the fix isn't available until 3.2. When it hits it can result in a complete loss of major functionality - any action involving a Java search. The fix only has an effect when the exception is about to be thrown, so it is very low risk. Please can this be backported to the maintenance stream?
(back from vacation) +1 for 3.1.1, looks like a nasty issue with a good fix.
Backported fix and regression test to R3_1_maintenance branch.
Verified in I20050920-0010 for 3.2M2
Verified for 3.1.1 using M20050923-1430.