Community
Participate
Working Groups
I have: public class MyClass extends ParentClass<AnotherClass> { public MyClass(SomeClass someClass) { super(someClass, value1, value2, value3); } } Where ParentClass<T> has the following constructor: public ParentClass(SomeClass someClass, ValueClass... values) I get: Internal compiler error java.lang.ArrayIndexOutOfBoundsException: 2 at org.eclipse.jdt.internal.compiler.lookup.ParameterizedGenericMethodBinding.computeCompatibleMethod(ParameterizedGenericMethodBinding.java:98) at org.eclipse.jdt.internal.compiler.lookup.Scope.computerCompatibleMethod(Scope.java:231) at etc. This occurs on I20041101, and has occurred for quite a while. I can't build my project, even though it builds fine on NetBeans. Garret
Could you please provide a test case and the whole .log file? You remove part of the stack trace that we would like to see.
Created attachment 15530 [details] log entries for described error I'm afraid I can't provide a test case right now, but I am attaching the relevant log entries.
We can reproduce a failure in the reconciler, but we don't get the stack trace. So a test case would really help to get it fix.
Likely a bug in SourceTypeConverter
package p; public class MyClass extends ParentClass { public MyClass(Exception someClass) { super(someClass, "", "", ""); } } package p; public class ParentClass<T> { public ParentClass(T someClass, T... values) { System.out.println("Toto"); } }
Olivier says: "You won't get the crash anymore, but if you write a simple test case you will see the red line under the method call"
To be exact, Olivier says that the calls to super(...) is underlied in red, wheras the compiler doesn't find a problem.
Did this get into I20041102? Let me know, and I'll test it out.
In I20041102, we still have a bug in the reconciler. But I cannot reproduce the stack trace you got. It would be nice if you could give it a try and let us know. Also it would be nice to get your test case. Thanks.
Simpler test case: package p; public class ParentClass { public ParentClass(String... values) { } } package p; public class MyClass extends ParentClass { public MyClass() { super(""); } }
SourceElementParser is not marking the constructor with AccVarargs
Created attachment 15593 [details] Proposed fix
Created attachment 15594 [details] Proposed regression test
Patches are against I200411022000
FYI I still get the stack trace in I20041102 from the internal compiler error. Note there is also an error (not an internal compiler error, but an inability to resolve the super method) on the following line: void foo(MyClass myClass) { super.foo(myClass.getProperty(), myClass.getEnumProperty()); } where super.foo() is defined as in an abstract base class: protected void foo(Object... values); and MyClass.getEnumProperty() returns a value of type MyClass.MyEnum. Eclipse seems to be having trouble with an enum being passed to a vararg method of an abstract base class. (I don't know if this is the ultimate source of the internal compiler error.) I realize that a true test case would be helpful---I'm trying to get the time to produce one. (It's a busy week.)
Ok for M3
Released propoosed patch and regression test.
Verified for 3.1 M3 with build I200411040010 + jdt.core HEAD I've tested test similar to comment 0: MyClass.java: package q; import static q.ValueClass.*; class AnotherClass {} class SomeClass {} public class MyClass extends ParentClass<AnotherClass> { public MyClass(SomeClass someClass) { super(someClass, VALUE1, VALUE2, VALUE3); } } ParentClass.java: package q; public class ParentClass<T> { public ParentClass(SomeClass someClass, ValueClass... values) { } } ValueClass.java: package q; public enum ValueClass { VALUE1, VALUE2, VALUE3 } and it compiles without any error nor exception.
As I mentioned earlier, this bug still shows up---on 20041104, at least. On the positive side, I've managed to managed to produce a test case (see below). Note that this appears to be the same bug, even though it may in the end not have to do with accessing a generic superclass. (I debated whether to consider this a new bug, but as my original complaint was never fixed, I'll consider this the same bug, even if my original post allowed you to fix some *other* bug which you found because of my post. :) ) package com.example; import java.util.*; public class TestClass<T> { public boolean test1() { test2("test", null, 0); } public <F> List<F> test2(final List<F> list, final String... strings) { return null; } }
Um, don't want to argue, but this seems to be more severe than "normal". On the other hand, I suppose it seems worse from my point of view because I've been forced to use Net@#$Beans for weeks because my code won't compile on Eclipse. :)
This is a bug in the compiler. It doesn't handle variable arguments inside generic method. With a test case earlier in the week, this could probably be fixed for M3. I let Philippe set the severity. Compiling your test case with the batch compiler also produces the same stack trace.
*** Bug 78016 has been marked as a duplicate of this bug. ***
Problem comes from the lack of support for varargs in generic methods. Inference mechanism naively relies on same argument and parameter count.
Support added. Added regression tests: GenericTypeTest#test387-test392 Fixed
In order to benefit from fix, you could take the next nightly/integration build, and copy org.eclipse.jdt.core plugin back into 3.1M3.
This is some trivial code that causes the problem. %cat Test.java import java.util.Arrays; import java.util.Collection; public class Test { public static void main(String[] args) { final Collection<String> x = Arrays.asList("A", "B"); } }
*** Bug 78467 has been marked as a duplicate of this bug. ***
Verified in 200412140800
