Community
Participate
Working Groups
To be precise, I have an IComparable interface, derived from java.lang.Comparable, this interface merely does declare the compareTo method one more, but with additionally all possible exceptions being listed in the throws clause. Eclipse will now, when I derive from a class implementing the IComparable interface, first include the compareTo method from that interface, then, transcending the hierarchy upwards, it will find the compareTo method defined by the java.lang.Comparable interface and will try to import that one, too, but eventually fails, because of the same signature. The source class file will be created, but no code a/o auto-comments will be generated for the class. Likewise, eclipse always does comply about inherited methods (the compareTo method in this case) not being implemented by the class, although this already has been implemented, as it has been derived from the IComparable interface. Here is some snippet of code to get you going =) public interface IComparable extends BaseInterface, Comparable { public int compareTo(Object aObject) throws NullPointerException, ClassCastException; } public class AbstractType extends BaseObject implements Cloneable, IComparable { public abstract int compareTo(Object aObject) throws NullPointerException, ClassCastException; public boolean equals(Object aObject) { try { return compareTo(aObject) == 0; } catch (Exception e) { return false; } } } Note: comparison is done based on the value of the object rather than the object itself, therefore, equals has been defined to re-use compareTo() instead of comparing directly. Next, I will derive from AbstractType and this will cause the above mentioned erroneous behaviour, namely the compareTo method will be tried to be included twice (once directly from AbstractType a/o IComparable, and second from Comparable, which eventually fails due to the identical method signature, but for the throws clause). Thanks in advance for fixing this.
Please provide an accurate and complete test case. The one you provided is lacking referenced types and abstract modifiers. Also, you never need to declare runtime exceptions or errors (those are unchecked exceptions). Did you obtain a different behavior with other vendors' compilers ?
Actually, there is nothing more to it. I am using the JDK 1.4.1_02. The BaseInterface is merely a base interface and does not define any methods, so you could actually leave that one out. I don't think that this is related to the compiler, because it will compile and work properly and as expected. I throw the runtime exceptions because otherwise the components which I am going to implement would cause a failure of possibly the application for which they have been designed, thus I force the user to watch out for these exceptions and errors and provide proper logic to resolve the error directly, as a last resort, he may re-throw the exception and cause the component and eventually the application to fail. As to the compilers of other vendors I don't have any experience with them. But I'd think that Eclipse is not checking properly the method signatures and when it encounters public int compareTo(Object aObject) throws NullPointerException, ClassCastException; and subsequently in the base interface Comparable public int compareTo(Object o); it renders these two different methods, whereas they are exactly the same apart from the throws clause. Thus, for experiencing the above mentioned failure to create the derived classes from AbstractType, you would need public interface IComparable extends Comparable { public int compareTo(Object aObject) throws NullPointerException, ClassCastException; } import IComparable; public class AbstractType extends Object implements Cloneable, IComparable { public abstract int compareTo(Object aObject) throws NullPointerException, ClassCastException; public boolean equals(Object aObject) { try { return compareTo(aObject) == 0; } catch (Exception e) { return false; } } } and naturally Eclipse setup and running, the package definition is the default package. Then, go to the New Class Dialog and create a new class, being derived from AbstractType. On my system's configuration this will fail, as I have already written in the first posting, due to the duplicate compareTo() methods. I will try this one out today later in the afternoon and, if the error will not show up, I will post the classes in question from my current development, including BaseObject, BaseInterface, AbstractType, IComparable, ICloneable, ISerializable etc. Hope this helps... Carsten
Works for me in latest. Was able to create a class extending AbstractType.
