Community
Participate
Working Groups
User-Agent: Opera/9.80 (Windows NT 6.1; U; en) Presto/2.2.15 Version/10.01 Build Identifier: Galieleo SR1 While doing coding on a jboss project Kabir Kahn bumped into code with generics wihch compiles on Eclipse 3.4 and javac but not with eclipse 3.5. The following illustrates it in a single class: import java.util.Collection; import java.util.HashSet; import java.util.Set; /** * * @author <a href="kabir.khan@jboss.com">Kabir Khan</a> * @version $Revision: 1.1 $ */ public class SimpleExample { Set<Data> data; public void setData(Set<Data> data) { this.data = data; } public void copy(SimpleExample clone) { clone.setData(cloneCollection(data, HashSet.class, Data.class)); } public static <U extends Interface, T extends Collection<U>> T cloneCollection(T collection, Class<? extends T> expectedClass, Class<U> componentType) { return null; } private interface Interface { } private class Data implements Interface { } } The error you will get is something like: Description Resource Path Location Type The method setData(Set<SimpleExample.Data>) in the type SimpleExample is not applicable for the arguments (Collection) SimpleExample.java /jboss-kernel/src/main/java/org/jboss/beans/metadata/plugins line 44 Java Problem i.e. clone.setdata should work with this. javac gives warnings about unchecked code, but it does compile and works as expected. This prevents us from using Eclipse 3.5 for developing code that has these constructs. Reproducible: Always
This is certainly a duplicate of bug# 277643. This tiny patch that attempts to short circuit the key change that went in for fix of bug #258798 (which led to bug# 277643) fixes the current problem. ------------------------------------8<----------------------- ### Eclipse Workspace Patch 1.0 #P org.eclipse.jdt.core Index: compiler/org/eclipse/jdt/internal/compiler/ast/MessageSend.java =================================================================== RCS file: /cvsroot/eclipse/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/ast/MessageSend.java,v retrieving revision 1.144 diff -u -r1.144 MessageSend.java --- compiler/org/eclipse/jdt/internal/compiler/ast/MessageSend.java 19 Feb 2009 18:54:57 -0000 1.144 +++ compiler/org/eclipse/jdt/internal/compiler/ast/MessageSend.java 11 Nov 2009 10:36:25 -0000 @@ -486,7 +486,7 @@ this.resolvedType = this.actualReceiverType; } else { TypeBinding returnType; - if ((this.bits & ASTNode.Unchecked) != 0 && this.genericTypeArguments == null) { + if (false && (this.bits & ASTNode.Unchecked) != 0 && this.genericTypeArguments == null) { returnType = this.binding.original().returnType; if (returnType != null) { returnType = scope.environment().convertToRawType(returnType.erasure(), true); -----------------------------------8<------------------------------------- bug #258798 is attempt to close the gap between ecj and jls with respect to section JLS 15.12.2.6 (2nd bullet) Need to check the fix to see if all is well. Here is a curious thing: bug #258798 comment#0 says given the snippet: class Foo<T> {} public class X { public void test() { Integer i = m(new Foo<Foo<Integer>>(), new Foo()); } public <T> T m(Foo<T> x, T t) { return t; } } we should be complaining that "Type mismatch: cannot convert from Foo to Integer" ^^^ instead of: Type mismatch: cannot convert from Foo<Integer> to Integer HOWEVER before the fix for bug #258798 we were complaining "Type mismatch: cannot convert from Foo<Integer> to Integer" After that fix went in, we now complain : "Type mismatch: cannot convert from Object to Integer" ^^^^^^ Note that javac7 b75 complains: X.java:4: incompatible types Integer i = m(new Foo<Foo<Integer>>(), new Foo()); ^ required: Integer found: Foo Note: X.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 1 error
Resolving as a duplicate of bug# 277643. If that gets reopened will include the test case here in the regression tests. *** This bug has been marked as a duplicate of bug 277643 ***
Verified for 3.6M6 using build I20100305-1011.
