Community
Participate
Working Groups
Build Identifier: I20101028-1441 I am using a generic method that seems to infer the return type in a way that is different from the SUN compiler that reports an error there. I have attached a project that shows the use of this method and the generic types involved. In our build machines an error is reported like this: ERROR Type mismatch: cannot convert from Object to AtomicInteger Reproducible: Always
Created attachment 185126 [details] Project to reproduce
Eclipse 3.4.2 reports an error: Type mismatch: cannot convert from Object to AtomicInteger Main.java GenericTest/src line 12 Java Problem javac 1.6.0_21 (similar with 1.5 and 1.7) reports an error: C:\e\w\runtime-head-CLEAN-2\GenericTest\src\Main.java:12: warning: [unchecked] unchecked conversion found : ArtifactIdImpl required: IArtifactIdentifier<T> AtomicInteger i= new Main().resolveArtifact(new ArtifactIdImpl()); ^ C:\e\w\runtime-head-CLEAN-2\GenericTest\src\Main.java:12: warning: [unchecked] unchecked method invocation: <T>resolveArtifact(IArtifactIdentifier<T>) in Main is applied to (ArtifactIdImpl) AtomicInteger i= new Main().resolveArtifact(new ArtifactIdImpl()); ^ C:\e\w\runtime-head-CLEAN-2\GenericTest\src\Main.java:12: incompatible types found : java.lang.Object required: java.util.concurrent.atomic.AtomicInteger AtomicInteger i= new Main().resolveArtifact(new ArtifactIdImpl()); ^ 1 error 2 warnings Since 3.5, Eclipse doesn't report an error any more, which is IMO wrong. The type ArtifactIdImpl is raw, which erases the type parameter T from IArtifactIdentifier to Object. Therefore, the argument passed to "<T> T resolveArtifact(IArtifactIdentifier<T>)" has no free type variables and the compiler should not infer a different type for T.
I'll take a look.
I would also expect an error in that case.
Actually, need to double check, but it could be a consequence of the rework in 3.5 near JLS 15.12.2.8. I remember making the inference smarter to still infer T from expected type, when unbound from argument type. At that time, it was felt to be a good decision. Maybe the spec got clarified since then, that if not inferred via 15.12.2.7, you need to erase it.
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.
