Community
Participate
Working Groups
Build ID: M20090211-1700 The snippet below is a self-contained minimized portion that repros a problem I found. The problem manifested in an test that uses the well-known EasyMock, so I preserved the EasyMock class names, prefixed by "Z", to give it the right flavor, but it's completely self contained. javac compiles this code, and it seems valid, but Eclipse complains: The method andReturn(capture#1-of ? extends SomeTest.Baz) in the type SomeTest.ZIExpectationsSetters<capture#1-of ? extends SomeTest.Baz> is not applicable for the arguments (SomeTest.Baz) ******************* public class SomeTest { public void testFoo() throws Exception { Bar<? extends Baz> bar = null; Baz baz = null; ZEasyMock.expect(bar.get()).andReturn(baz); } static class Baz {} interface Bar<T> { T get(); } static class ZEasyMock { public static <T> ZIExpectationSetters<T> expect(T value) { return null; } } interface ZIExpectationSetters<T> { /*IExpectationSetters<T>*/ void andReturn(T value); } }
Need to check but believe this is a javac bug. In this case: class X { void a(J<? extends X> j, X x) { aHelp(j.getX()).andReturn(x); // javac accepts } <T> I<T> aHelp(T v) { return null; } void b(J<? extends X> j, X x) { bHelp(j).andReturn(x); // javac reports error // required: capture#1 of ? extends X // found: X } <T> I<T> bHelp(J<T> j) { return null; } } interface J<T> { T getX(); } interface I<T> { void andReturn(T value); } javac reports an error when the result of I<T> bHelp(J<T> j) is sent andReturn(x) but not for I<T> aHelp(T v) eclipse treats both cases the same since the return type of aHelp and bHelp is capture of ? extends X, and the expected type of andReturn is X
Similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=271160#c2
This case shows that eclipse is inconsistent - it appears that we do not use the expected return type to infer the return type of a nested message send. class X { <T> I<T> foo(T v) { return null; } void testReturnType(J<? extends X> j) { X x = j.get(); I<X> a = foo(x); // javac & eclipse accept I<X> a2 = foo(j.get()); // javac accepts, eclipse reports error } } interface J<T> { T get(); } interface I<T> {}
There was a query about the status of this bug in the forums. I'll take a look at this for 3.8
Informal assessment: bar : Bar<? extends SomeTest.Baz> bar.get() : capture#1-of ? extends SomeTest.Baz ZEasyMock.expect(bar.get()) : ZIExpectationSetters<capture#1-of ? extends SomeTest.Baz> argument value in andReturn : capture#1-of ? extends SomeTest.Baz In parameter position no type is conform to <? extends X> Changing the declaration of bar to Bar<? super Baz> bar = null; makes all compilers happy (except that bar can only be null and shouldn't be dereferenced :) ). Thus I'm leaning towards closing as INVALID. Did I miss anything?
(In reply to comment #3) > This case shows that eclipse is inconsistent - it appears that we do not use > the expected return type to infer the return type of a nested message send. > > > class X { > <T> I<T> foo(T v) { return null; } > > void testReturnType(J<? extends X> j) { > X x = j.get(); > I<X> a = foo(x); // javac & eclipse accept > > I<X> a2 = foo(j.get()); // javac accepts, eclipse reports error > } > } > > interface J<T> { T get(); } > interface I<T> {} That's a different problem requiring separate investigation. Error message is: Type mismatch: cannot convert from I<capture#2-of ? extends X> to I<X> Without context this message would seem correct to me. It would require further digging in the JLS whether the capture#2-of part must be retained or can be substituted by the upper bound when inferring types of foo(). Srikanth, can you recall/reconstruct whether the forum question related to comment 0 or comment 3?
(In reply to comment #6) > Srikanth, can you recall/reconstruct whether the forum question related to > comment 0 or comment 3? No :(. I am moving this out to later as I don't expect to get to this for 3.8. Sorry.
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.
We consider the deviation re comment 0 as a bug in javac. Regarding comment 3 both compiler agree on accepting (at compliance 1.8).
Verified for Eclipse 4.12 M1 with Build id: I20190408-1800
