Community
Participate
Working Groups
Build Identifier: M20110210-1200 See the steps to repro Reproducible: Always Steps to Reproduce: 1. write the following classes: public interface A { <T extends B & C> T getaMethod(); <T extends B & C> void setaMethod(T param); } public class B { } public interface C { } public class D { public void someMethod(A aInstance) { aInstance.getaMethod(); } } 2. expected result: I should be able to assign the return value of aInstance.getaMethod() to either a B variable or C variable (or Object variable...) 3. actual result: I can't assign it to anything, the compiler always complains about: Bound mismatch: The generic method getaMethod() of type A is not applicable for the arguments (). The inferred type B is not a valid substitute for the bounded parameter <T extends B & C> Actually, also javac 6 complains: D.java:6: type parameters of <T>T cannot be determined; no unique maximal instan ce exists for type variable T with upper bounds java.lang.Object,B,C aInstance.getaMethod(); However, this sounds to me as a bug in javac, isn't it?
javac7 compiles the code fine with all the following variants: Object o = aInstance.getaMethod(); A o = aInstance.getaMethod(); B o = aInstance.getaMethod();
Do you think there's any dirty workaround to make such code compile even with Eclipse 3.6.x or javac<7?
(In reply to comment #2) > Do you think there's any dirty workaround to make such code compile even with > Eclipse 3.6.x or javac<7? Having B implements C would workaround the reported error.
*** Bug 341789 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Having B implements C would workaround the reported error. Thank you. However this is not applicable in my real-world case, since otherwise I wouldn't have needed to use the multiple bounds on the counterpart of A. I think I will have to leave a documented less strict bound and use casts by now. Thanks anyway.
I know what is the problem here, it is too late for 3.7, but I can include a fix for subsequent versions.
*** Bug 319436 has been marked as a duplicate of this bug. ***
Another test case: import java.io.Serializable; public class Test { public static void main(String[] args) { createObject(); } private static <T extends Comparable<?> & Serializable> T createObject() { return null; } }
*** Bug 346026 has been marked as a duplicate of this bug. ***
More tests: (some of them Java 7): 1. class C {} interface I {} public class X<T extends C & I> { X() {} X f = new X<>(); } 2. class C {} interface I {} public class X<T extends C & I> { static <U extends C & I> X<U> getX() { return null; } X f2 = getX(); } 3. class C {} interface I {} public class X<T extends C & I> { static <U extends C & I> X<U> getX() { return null; } X<?> f2 = getX(); } Junits org.eclipse.jdt.core.tests.compiler.regression.GenericsRegressionTest_1_7._test0030() - _test033() need to be enabled after the fix.
Created attachment 196509 [details] Patch under consideration. This is a cumulative patch and includes also the changes being considered for bug 242159. The code changes inside org.eclipse.jdt.internal.compiler.lookup.ParameterizedGenericMethodBinding.resolveSubstituteConstraints(Scope, TypeVariableBinding[], InferenceContext, boolean) are for the bug 341795. Other changes are for bug 242159 This patch is under test.
Passes all JDT/Core tests. I'll play around with it some more before releasing it. It is too late for 3.7, so this will be released only in the BETA_JAVA7 branch and will become available through a supported release when eclipse releases a java 7 enabled version later this year (per current plan)
Does the [1.7] tag added in the subject mean that the fix will be available only when using Eclipse compiler compliance level to 1.7? Or will it be available also for 1.5 and 1.6 compliance levels?
(In reply to comment #13) > Does the [1.7] tag added in the subject mean that the fix will be available > only when using Eclipse compiler compliance level to 1.7? Or will it be > available also for 1.5 and 1.6 compliance levels? At this point, we are looking at the fix being available for all levels, but only through a release enabled for Java 7. So the fix will be released only into the branch on which Java 7 development work is happening.
Created attachment 196639 [details] Revised cumulative patch under consideration. This is a cleaner, better documented patch.
As a part of this cumulative fix, I had to remaster 13 tests from GenericTypeTests suite - I have verified that in every one of these cases, the new behavior matches JDK 7b142 - javac compiler. The fix applies to all compliance levels. Released in BETA_JAVA7 branch only - this is too late for 3.7 stream (HEAD)
(In reply to comment #14) > At this point, we are looking at the fix being available for all > levels, but only through a release enabled for Java 7. So the fix > will be released only into the branch on which Java 7 development > work is happening. This is clear now, thank you!
Verified using Java 7 feature patch.
