Community
Participate
Working Groups
See this SO thread: https://stackoverflow.com/questions/47662493/eclipse-ecj-accepts-this-code-javac-doesnt-who-is-right Here, ecj accepts the code, while javac rejects. On closer look this is (probably) caused by a bug similar to javac's https://bugs.openjdk.java.net/browse/JDK-8026527 in that we accept ⟨AtomicReference#RAW <: AtomicReference<?>⟩ where in fact types are only convertible, no subtype relation. Simply switching from isCompatibleWith() to isSubtypeOf() produces these differences wrt javac (9.0.1) in GRT_18: testBug424415b: ecj accept, javac reject testBug488663: ecj reject, javac accept testBug506022b: ecj reject, javac accept (with warnings) The same experiment before the pending fix yields: testBug424415b: ecj accept, javac reject testBug488663: ecj reject, javac accept this bug: ecj accept, javac reject Disregarding the first two differences (which are independent of the issue discussed here) it seems we can choose between this bug and (part of) Bug 506022...
New Gerrit change created: https://git.eclipse.org/r/114442
(In reply to Eclipse Genie from comment #1) > New Gerrit change created: https://git.eclipse.org/r/114442 This "obvious fix" gave more regressions than expected (at 1.8 and 9): org.eclipse.jdt.core.tests.compiler.regression.AmbiguousMethodTest.test014h org.eclipse.jdt.core.tests.compiler.regression.AmbiguousMethodTest.test014i org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test0394 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test0459 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test0600 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test0901 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test1234 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test1235 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test1349 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test1429 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test1430 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test277643 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test280054 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test283306 org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test294724 org.eclipse.jdt.core.tests.compiler.regression.GenericsRegressionTest.test283353 org.eclipse.jdt.core.tests.compiler.regression.GenericsRegressionTest.test434118 org.eclipse.jdt.core.tests.compiler.regression.MethodVerifyTest.test094 org.eclipse.jdt.core.tests.compiler.regression.NullTypeAnnotationTest.testTypeVariable18raw org.eclipse.jdt.core.tests.compiler.regression.GenericsRegressionTest_1_8.testBug506022b
To overlay the list of regressions with the current state in bug 404648: (In reply to Stephan Herrmann from comment #2) > (In reply to Eclipse Genie from comment #1) > > New Gerrit change created: https://git.eclipse.org/r/114442 > > This "obvious fix" gave more regressions than expected (at 1.8 and 9): Tests where current state (without pending patch) detects a difference between ecj & javac: > org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test277643 > org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest.test283306 Of these, test277643 changed behavior between javac8 and javac9. In all other tests mentioned in comment 2 current behavior (without pending patch) is in sync with javac. Ergo: that patch does not bring us closer to javac, quite to the contrary.
Gerrit change https://git.eclipse.org/r/114442 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=ec76c89defa5f96571519ef98af5fe717abfdb09
(In reply to Eclipse Genie from comment #4) > Gerrit change https://git.eclipse.org/r/114442 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=ec76c89defa5f96571519ef98af5fe717abfdb09 I found a deficiency in our implementation of isSubTypeOf(), fixed & released for 4.8 M5. NB: I introduced a new parameter simulatingBugJDK8026527, but clients are not yet consistent about when to pass false, or propagate their own simulatingBugJDK8026527 value. Since this is neither spec'ed nor influences the outcome of tests I can't really tell which strategy should be "correct".
The latest test build[1] informed me, that the fix is not good: the test expects the wrong result thus creating a failure during comparison with javac. Re-opening. [1] https://ci.eclipse.org/jdt/job/eclipse.jdt.core-run.javac-9/5/testReport/
I'm having good mail exchange with Oracle regarding this issue. Rejecting the example in this bug can be achieved by post-inference sanity checks, which would detect that an argument is not compatible to the corresponding method parameter. Unfortunately, adding such sanity check breaks other tests, one of which is currently being discussed with Oracle.
In discussing this with Oracle we touched on the issues of bug 448793: javac applies the branch in 18.4, where fresh type variables Y1,... are created, because the variables to be resolved appear in capture bounds. We don't get there because of prematurely deleting capture bounds during incorporate. I made some more experiments with avoiding that premature deleting, but this causes around 30 regressions just in GRT_18. I even tried the advice quoted in bug 448793 comment 3, to not much avail. Also the recommended sanity checks cause many regressions. For the records: the test we discussed was testBug506022b() where inference needs to infer a parameter to be a wildcard capture, but nowhere in JLS do I see a chance that inference could make use of the wildcard :( => Moving out of M5, not sure if this is a game we can win. Better let missing sanity checks camouflage the problems we have around the business of capture bounds and fresh type variables.
After all discussion (internal and with Oracle) it is still not clear how exactly javac is handling wildcard capture during type inference, nor what we should be doing in this field. Until bug 448793 is resolved (if possible), I don't see how we can make progress in this bug.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
