Community
Participate
Working Groups
I'm getting an ArrayIndexOutOfBoundsException in JavaModelManager:219: java.lang.ArrayIndexOutOfBoundsException: 60 at org.eclipse.jdt.internal.core.JavaModelManager$CompilationParticipants.getCompilationParticipants(JavaModelManager.java:219) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.notifyParticipants(ReconcileWorkingCopyOperation.java:197) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:74) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:720) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:779) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1123) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:97) The error happens when I switch editors, when I try to compile, opening the context menu and at thousands of other times. After some searching, I stumbled over the settings in a new project which (no idea why) suddenly decided to require Java 6.0. It seems that Eclipse doesn't do the correct bounds checking in this case. I wonder why this is. Isn't Java 6 supported by Eclipse 3.2? If not, why can I select it in the project properties?
I'll investigate. I am surprised because I ran using a 1.6 VM last week and I didn't get it.
Could you please provide your workspace settings or project settings if you used project specific options? You should have 1.6.
I have no 1.6 JRE installed. My latest JRE is 5 but I had a project set to Java 6 compliance level. Maybe that's the cause.
Can you attach the org.eclipse.jdt.core.prefs of this project (you'll find it in .settings directory)? Thanks
I had some trouble to reproduce the bug now that it's fixed. I'm using the maven 2 plugin and, well, see for yourself: org.eclipse.jdt.core.compiler.codegen.targetPlatform=${maven.compile.target} org.eclipse.jdt.core.compiler.codegen.unusedLocal=preserve org.eclipse.jdt.core.compiler.compliance=${maven.compile.source} org.eclipse.jdt.core.compiler.debug.lineNumber=generate org.eclipse.jdt.core.compiler.debug.localVariable=generate org.eclipse.jdt.core.compiler.debug.sourceFile=generate org.eclipse.jdt.core.compiler.problem.assertIdentifier=error org.eclipse.jdt.core.compiler.problem.enumIdentifier=error org.eclipse.jdt.core.compiler.source=${maven.compile.source} It seems that Eclipse tries to make sense of these and fails :-) Proposed solution: Eclipse should check the values it gets from this file and complain if they don't make sense instead of starting to throw strange exceptions. I'll also file a bug report against m2eclipse.
Created attachment 54171 [details] Proposed patch
What happens if the string is just "x"? I suggest to add a real check like Pattern.compile("1\\.[1-5]").match(sourceLevel).match() and check against that before you try to evaluate the string.
Created attachment 54183 [details] New proposed patch You're right, my initial fix wasn't really good, this one should be better... It does not use Pattern method which would be too costly for such a verification.
Are you sure VERSION_JSR14 ("jsr14") is no longer necessary? Your new patch doesn't support it anymore. If so, why not also delete the constant?
(In reply to comment #9) > Are you sure VERSION_JSR14 ("jsr14") is no longer necessary? Your new patch > doesn't support it anymore. > > If so, why not also delete the constant? > VERSION_JSR14 is a specific version for target platform and only used by batch compiler. In this bug test case, we're in Java Model (and so do not use batch compiler) and we're testing source level... So, this constant is still necessary but we do not need to support it in this peculiar case.
I just wanted to make sure the batch compiler won't be using the new code eventually. Someone, who doesn't notice this patch, might be surprised when versionToJdkLevel suddenly behaves differently.
(In reply to comment #11) > I just wanted to make sure the batch compiler won't be using the new code > eventually. Someone, who doesn't notice this patch, might be surprised when > versionToJdkLevel suddenly behaves differently. > Please, note that: 1) versionToJdkLevel does not behave differently, I just rewrote it to be more optimized (avoid several calls to String.equals(Object) method) as it is called from JavaModelManager method in my new fix and I didn't want to have time penalty using this method... 2) even this method is public, it's not API as CompilerOptions is in an internal package => it's only supposed to be used by our own code (ie. JDT/Core) => nobody should be surprised even if we decided to change this method behavior...
Created attachment 54244 [details] Last proposed patch Point 1) in my previous comment was wrong (this was not my day yesterday :-( ...) I effectively modified versionToJdkLevel method behavior as I missed VERSION_JSR14 value! New patch fix this last (?) issue. Thanks the review :-)
Created attachment 54255 [details] Ultimate proposed patch After Philippe's review, change indexForSourceLevel(String) method of JavaModelManager.CompilerParticipant to avoid any assumption on JDK level major version value...
Released for 3.3 M4 in HEAD stream.
Verified for 3.3M4 with I20061212-0010.
