Community
Participate
Working Groups
This is what I had during editing: //--- import java.lang.annotation.*; import java.util.*; import java.util.function.*; import java.util.stream.*; interface MyCollector<T, A, R> extends Collector<T, A, R> { } public abstract class AnnotationCollector { abstract <T, K, U, M extends Map<K, U>> MyCollector<T, ?, M> toMap(Function<? super T, ? extends K> km, BinaryOperator<U> mf); void test(Stream<Annotation> annotations) { annotations .collect(toMap(Annotation::annotationType, (Annotation first, Annotation second) -> first)); } Map<String, Person> test2(Stream<Person> persons) { return persons.collect(Collectors.toMap((Person p) -> p.getLastName(), Function::identity, (p1, p2) -> p1)); } } class Person { String getLastName() { return ""; } } //--- The compiler answer with java.lang.StackOverflowError at org.eclipse.jdt.internal.compiler.lookup.CaptureBinding18.isCompatibleWith(CaptureBinding18.java:123)
I'll investigate for 4.4
Mh, stackoverflow isn't exactly nice. Fix is simple: We encounter a recursive CaptureBinding18. Some queries in this class already avoid stackoverflow using the flag "inRecursiveFunction", doing the same also in CB18.isCompatibleWith fixes this bug. On the long run we can avoid this situation even earlier: the recursive CB18 is constructed from a type bound K#1 <: K#1 (an inference variable should be a subtype of itself). This type bound is legal but unnecessary, I will reduce it directly to TRUE.
Created attachment 240884 [details] test & fix Srikanth, Jay: I don't have the time to run all tests (RunAllJava8Tests are green). If you think this is good to have in GA and have the time to test it, from my p.o.v its safe and good to have. So feel free to release if you like. Otherwise I'll take it forward after GA. Point in favour: when it hits you, no editing is possible, your only option is: exit workbench, edit file externally, and restart.
I'll take a look later today. Thanks Stephan.
I'll first take this up for black box testing. Subsequently see if I have time for review and then decide.
(In reply to Srikanth Sankaran from comment #5) > I'll first take this up for black box testing. Subsequently see if I have > time for review and then decide. All JDT core tests went OK, Jay is doing additional testing ...
Testing went well and released the changes into BETA_JAVA8: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA8&id=1b7626b6bc39479837ae0cdb8edf077e6aad6481
(In reply to Jayaprakash Arthanareeswaran from comment #7) > Testing went well and released the changes into BETA_JAVA8: > > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?h=BETA_JAVA8&id=1b7626b6bc39479837ae0cdb8edf077e6aad6481 Thanks! Polish/optimization mentioned in comment 2 will be handled via bug 430404
Somehow we ended up with target 4.4 even though this was released in BETA_JAVA8. To take it through verification stage, setting it to RC1.
Verified for Luna 4.4 RC1 Build id: I20140518-2000.