Community
Participate
Working Groups
Got this from the newsgroup: -------------------------------------- I receive the following every time I try to (re)build my Eclipse AJDT project: java.lang.StringIndexOutOfBoundsException: String index out of range: 67 at java.lang.String.charAt(String.java:687) at org.eclipse.ajdt.core.model.AJProjectModelFacade.programElementToJavaElement(AJProjectModelFacade.java:334) at org.eclipse.ajdt.internal.ui.markers.UpdateAJMarkers.getCustomMarker(UpdateAJMarkers.java:421) at org.eclipse.ajdt.internal.ui.markers.UpdateAJMarkers.createMarker(UpdateAJMarkers.java:183) at org.eclipse.ajdt.internal.ui.markers.UpdateAJMarkers.addMarkersForFile(UpdateAJMarkers.java:173) at org.eclipse.ajdt.internal.ui.markers.UpdateAJMarkers.addMarkersForProject(UpdateAJMarkers.java:127) at org.eclipse.ajdt.internal.ui.markers.UpdateAJMarkers.run(UpdateAJMarkers.java:94) at org.eclipse.ajdt.internal.ui.markers.DeleteAndUpdateAJMarkersJob.run(DeleteAndUpdateAJMarkersJob.java:62) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) This error started after I added a project to the Aspect Path, the project that contains my .aj version info: eclipse.buildId=M20080911-1700 java.version=1.6.0_11 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86 Eclipse AspectJ Development Tools Version: 1.6.3.20090122141228 AspectJ version: 1.6.4.20090106083800
This is happening when trying to create the handle for an aspect compilationunit on the aspect path. Should be a simple fix, but I would like to recreate it first before I do anything.
I can't reproduce this problem directly. The problem comes about when a compilation unit on the aspect path is asked to be translated from a JDT handle to an AspectJ handle, but without seeing the original project, I can't see why this is happening. Perhaps this points to a deeper problem. Regardless, however, AJProjectModelFacade.programElementToJavaElement should be robust to binary references to CompilationUnits. I will make the change.
Fix for this is in with test. Will be available in next dev build. While exploring what could have caused this, I found many small issues with handle generation in binary files. Binary navigation should be more robust now.