Community
Participate
Working Groups
Build Identifier: 20110916-0149 Name clash: The method put(K, V) of type KeyValueList<K,V> has the same erasure as put(K, V) of type Hashtable<K,V> but does not override it The class: public class KeyValueList<K, V> extends Hashtable<K, List<V>> { public synchronized void put(K pKey, V pValue) { //do anything } } // KeyValueList (complete class: http://jvx.svn.sourceforge.net/viewvc/jvx/trunk/java/library/src/com/sibvisions/util/KeyValueList.java?revision=3731&view=markup) We updated from Eclipse Galileo to Indigo and now we have a show stopper! Reproducible: Always Steps to Reproduce: Try to compile the KeyValueList class with jdk 1.5 and compiler compliance level 1.5
Change compiler compliance to 1.6 changes the compiler error to a warning. If you use jdk 1.5, you get an information that you should use a compatible JRE - but that is not a problem. Set .class and source compatibility to 1.5 if you need jre 1.5 compatibility.
Please see bug 293615. The difference was introduced some time between 3.5.2 and 3.6.0. Mapped to the current bug this is my understanding of matters: You are trying to override this method from Hashtable: V put(K key, V value) with your own (I renamed type variables in KeyValueList for clarity): void put(K2 pKey, V2 pValue) After substitution the inherited signature becomes List<V2> put(K2 key, List<V2> value) When comparing this to void put(K2 pKey, V2 pValue) we have no overriding because V2 and List<V2> are different types. OTOH, the erasure of the inherited method is Object put(Object,Object) and the erasure of the method in KeyValueList is: void put(Object,Object) Older versions (javac as well as ecj) wrongly accepted this by considering both signatures as distinguishable by their return type, which is against the JLS. In fact a method call to put(Object,Object) cannot distinguish these methods, although at the surface they have different signatures, hence the (correctly reported) error. => The error is correct, previous compiler versions which accepted the code were wrong.
It is exactly as described. It is clear why the problem occurs, but where is the difference between compliance level 1.5 (error) and 1.6 (warning). The "work-around" is good enough to work without problems, but there is still a warning.
(In reply to comment #3) > It is exactly as described. It is clear why the problem occurs, but where is > the difference between compliance level 1.5 (error) and 1.6 (warning). The > "work-around" is good enough to work without problems, but there is still a > warning. There is quite a bit of background for this. Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=317719 and the several bugs referenced there. As of https://bugs.eclipse.org/bugs/show_bug.cgi?id=317719#c28, we decided to make it a warning at 1.6 mode. Please see that your test case will not compile alright with JDK7 compiler from Oracle. So eclipse behavior matches oracle JDK7 compiler behavior and eclipse compiler at 1.6 compliance issues a warning to alert the user that this area needs attention as it will become a compiler error in future when upgrading to JDK7 or ECJ compliance level 7. As this is intentional behavior, closing as INVALID.
(In reply to comment #4) > As of https://bugs.eclipse.org/bugs/show_bug.cgi?id=317719#c28, we decided > to make it a warning at 1.6 mode. For the record, while the above comment called for it being made a warning for 1.6- modes, we ended up making it a warning only for 1.6 mode. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=317719#c40, there were a bunch of test cases where we couldn't make head or tail of javac behavior and could not reasonably emulate its behavior.
Also in future, please include a small test case that can be directly copy and pasted, Thanks,
Verified for 3.8 M5 using build I20120123-1300 that: - javac 1.7 reports an error - javac 1.6 does not complain - ecj in compliance 1.7 reports the same error as javac 1.7 - ecj in compliance 1.6 reports a warning This is the intended behavior to balance compatibility with the JLS vs. compatibility with javac.
