My source does not compile in 1.5 because of generics in libraries

Question

Hi,
I have a problem with my source codes written for 1.3 and 1.4 java. I have been implementing Iterator, Collection, List and extending ArrayList in many ocassions. All works as expected in 1.4 but if I try to compile it with 1.5 it does not compile. I do receive many errors which generally speaking are showing that compiler does think that X subclass is not the same as a subclass of X<?> generic which simply makes all my code to not compile.
Does anybody had similar problems with their code? Does anybody knows how to rewrite problematic code so that it will compile under BOTH 1.4 and 1.5 without -source 1.4 option?
Some examples, stripped to problematic parts:
public class CSectionList extends ArrayList
public final boolean add(Object element)
             int p = Collections.binarySearch(this,element);
/** Here comes error:
cannot find symbol
symbol  : method binarySearch(sztejkat.utils.CSectionList,java.lang.Object)
location: class java.util.Collections
                int p = Collections.binarySearch(this,element);
          if (p<0)
public class CMemoryViewTable extends JTable
/** Here comes error:
name clash: setDefaultRenderer(java.lang.Class,javax.swing.table.TableCellRenderer) in sztejkat.hdl.debugger.ui.CMemoryViewTable and setDefaultRenderer(java.lang.Class<?>,javax.swing.table.TableCellRenderer) in javax.swing.JTable have the same erasure, yet neither overrides the other
public class CMemoryViewTable extends JTable
    public void setDefaultRenderer(Class columnClass,
                                         TableCellRenderer renderer)
          if (renderer!=null)
               super.setDefaultRenderer(columnClass,new CCursorRenderer(renderer));
          }else
           super.setDefaultRenderer(columnClass,null);
}In first example it seems to not catch that my CSectionList is a List<>, while in second it does not treat Class and Class<> equally what makes compiler to think that I don't override setDefaultRenderer method what I actually wanted to do (and did in 1.4).
Please help...
regards,
Tomasz Sztejka
P.S.
Where the source compatibility have gone between 1.4 and 1.5? If it will look like this I strongly vote to NOT touch java language specification - it was very nice, simple and clear language. With autoboxing and generics it starts to do a lot of things behind my back what I don't like - this is why I moved from C++ to Java - hate what C++ did with overloaded operators. But maybe I'm just to stupid.

Answer 1

Hi,
I'm still not getting a good grip on generics, and still think they are not necessary.True, but when you have assembler you might not need C or Java. With assembler, you can write the most efficient programmes, but fixing a bug is not easy. With the higher level of C and Java, fewer trivial errors are made. The introduction of generics is another step towards compile-time bug prevention.
Will your request block me from having a set of different classes,
derived from different superclasses, all
implementing Comparable in the way, that they use
instanceof to check for proper relation (ie. I would
like to sorting to sort all classes A by some value
and all classes B to land in front of list)?Regarding raw classes, my request will change the erased interface of Comparable from
int compareTo(Object o);to
int compareTo(Comparable o);This would mean that all non-generic implementions of Comparable would have to be modified. I should have requested this enhancement ten years ago, but back then I did not know about Java at all :(
Where largest common superclass is Object (ie Asuper
is not instanceof Bsuper and vice-versa).
Will soring list of such objects (both A and B) will
be legal after your RFE ?Both A and B implement Comparable, so that should not be a problem.