Community
Participate
Working Groups
BETA_JAVA7 The fix for 347426 makes our TypeEnvironmentTests#testCaptureAssignments() fail. The test tests ITypeBinding#isAssignmentCompatible(ITypeBinding) with bindings from here: package xy; import java.util.ArrayList; import java.util.List; public class Try15 { void m(List<?> list) { list= new ArrayList<List<? extends String>>(); list= new ArrayList<String>(); } } If you take the resolved type binding of the first ClassInstanceCreation as 'this' and the resolved type binding of the Assignment node as the argument, then isAssignmentCompatible(..) used to return false but now returns true. The question is whether an ArrayList<List<? extends String>> can be assigned to a List<capture-of ?>. I couldn't find a way to express this test in source code, but the new behavior of the API feels wrong. When you do the same test with second ClassInstanceCreation, then isAssignmentCompatible(..) still returns false (can't assign ArrayList<String> to List<capture-of ?>). This shows that the API is inconsistent now. In the ASTView, you can see the difference with these steps: - select type binding of first Assignment node - context menu > Add to Comparison Tray - select the type bindings of a ClassInstanceCreation node
D'oh! Must learn to write "bug" in front of bug number: Bug 347426.
(In reply to comment #0) > BETA_JAVA7 > > The fix for 347426 makes our TypeEnvironmentTests#testCaptureAssignments() > fail. Markus, thanks for the report. Is it known if this is the only failure in your test suite caused at this point by JDT/Core changes ?
(In reply to comment #2) > Markus, thanks for the report. Is it known if this is the only failure > in your test suite caused at this point by JDT/Core changes ? Yes.
(In reply to comment #3) > (In reply to comment #2) > > Markus, thanks for the report. Is it known if this is the only failure > > in your test suite caused at this point by JDT/Core changes ? > > Yes. Is it yes and yes ? :) Thanks.
This is the only failure in JDT/UI in BETA_JAVA7 branch at this point :)
Released (disabled) junit org.eclipse.jdt.core.tests.dom.ASTConverter15Test._test0353() embodying the comment#0 scenario. Passes on HEAD and fails on JAVA7 branch along the lines described in comment# 0. Under investigation.
More precisely, there's just 1 failing test in JDT/UI. The test creates a bunch of bindings and then compares the TTypes results with the ITypeBinding results for all combinations. The given case is just the first difference that makes the test fail. To see all discrepancies, change the body of TypeEnvironmentTests#checkCanAssignTo(..) to: boolean coreResult= rhsBinding.isAssignmentCompatible(lhsBinding); boolean uiResult= rhs.canAssignTo(lhs); // assertEquals("Different assignment rule(" + // PrettySignatures.get(lhsBinding) + // "= " + PrettySignatures.get(rhsBinding) + // "): ", coreResult, uiResult); // see bug 348956 if (coreResult != uiResult) { System.out.println("Different assignment rule(" + PrettySignatures.get(lhsBinding) + "= " + PrettySignatures.get(rhsBinding) + "): Bindings<" + coreResult + "> TType<" + uiResult + ">"); } There are 12 differences, but all of them have a variable of type Collection or List<capture-of ? ...> and a List<List<...>> or a List<ArrayList<...>> as RHS.
Created attachment 198158 [details] Patch under consideration Looking at the fix for bug 347426, we are on something of a slippery slope there, this being an underspecified area and having to track the reference compiler instead which has changed its mind once going from JDK5 to JDK6 and yet again from JDK6 to JDK7. At the moment, I have simply tightened the fix for bug 347426 to avoid side effects: So, given class A<T extends B<?>>, we recognize that A<?> cannot be the universe of all parameterizations of A, but only those that also comform to the bounds specified, while for given class A<T>, A<?> can be. Deepak, Can I request you to run TypeEnvironmentTests#testCaptureAssignments and if that passes, then to run all tests and report any issues here ? TIA.
(In reply to comment #8) > Created attachment 198158 [details] [diff] > Patch under consideration Srikanth, with this patch there are 4 differences - Different assignment rule(java.util.List<capture-of ? extends java.lang.Object>= java.util.List<java.util.List<? extends java.lang.String>>): Bindings<true> TType<false> - Different assignment rule(java.util.List<capture-of ? extends java.lang.Object>= java.util.List<java.util.ArrayList<java.lang.String>>): Bindings<true> TType<false> - Different assignment rule(java.util.List<capture-of ? extends java.lang.Object>= java.util.List<java.util.List<? extends java.lang.Object>>): Bindings<true> TType<false> - Different assignment rule(java.util.List<capture-of ? extends java.lang.Object>= java.util.List<java.util.List<java.lang.String>>): Bindings<true> TType<false> The original 12 differences for reference - Different assignment rule(java.util.List<capture-of ?>= java.util.List<java.util.List<? extends java.lang.String>>): Bindings<true> TType<false> - Different assignment rule(java.util.List<capture-of ? extends java.lang.Object>= java.util.List<java.util.List<? extends java.lang.String>>): Bindings<true> TType<false> - Different assignment rule(java.util.Collection<capture-of ?>= java.util.List<java.util.List<? extends java.lang.String>>): Bindings<true> TType<false> - Different assignment rule(java.util.List<capture-of ?>= java.util.List<java.util.ArrayList<java.lang.String>>): Bindings<true> TType<false> - Different assignment rule(java.util.List<capture-of ? extends java.lang.Object>= java.util.List<java.util.ArrayList<java.lang.String>>): Bindings<true> TType<false> - Different assignment rule(java.util.Collection<capture-of ?>= java.util.List<java.util.ArrayList<java.lang.String>>): Bindings<true> TType<false> - Different assignment rule(java.util.List<capture-of ?>= java.util.List<java.util.List<? extends java.lang.Object>>): Bindings<true> TType<false> - Different assignment rule(java.util.List<capture-of ? extends java.lang.Object>= java.util.List<java.util.List<? extends java.lang.Object>>): Bindings<true> TType<false> - Different assignment rule(java.util.Collection<capture-of ?>= java.util.List<java.util.List<? extends java.lang.Object>>): Bindings<true> TType<false> - Different assignment rule(java.util.List<capture-of ?>= java.util.List<java.util.List<java.lang.String>>): Bindings<true> TType<false> - Different assignment rule(java.util.List<capture-of ? extends java.lang.Object>= java.util.List<java.util.List<java.lang.String>>): Bindings<true> TType<false> - Different assignment rule(java.util.Collection<capture-of ?>= java.util.List<java.util.List<java.lang.String>>): Bindings<true> TType<false>
Created attachment 198160 [details] Patch under consideration Is this patch better ?
(In reply to comment #10) > Created attachment 198160 [details] [diff] > Patch under consideration > > Is this patch better ? Yes, it is! TypeEnvironmentTests#testCaptureAssignments passes with this patch.
Passes all JDT/Core tests including the enabled regression test.
All JDT/UI tests also pass.
Thanks Deepak. Patch and test released in BETA_JAVA7 branch. I'll continue to test this area some more, as admittedly this is a bit of tinker - any issues discovered will be addressed via follow up defects.
Verified using Eclipse Java 7 Support(Beta) feature patch v20110623-0900.
