If you want to provide feedback or have any questions regarding Java generics, to which you cannot find an answer in this document, feel free to send me EMAIL or use the GENERICS FAQ form.
A printable version of the FAQ documents is available in PDF format (2.5MB).

Practicalities - Programming With Java Generics

Programming With Generics

Using Generic Types and Methods

Should I prefer parameterized types over raw types?

Why shouldn't I mix parameterized and raw types, if I feel like it?
 

Because it is poor style and highly confusing to readers of your source code.
Despite of the benefits of parameterized types you might still prefer use of raw types over using pre-defined generic types in their parameterized form, perhaps because the raw types look more familiar. To some extent it is a matter of style and taste and both styles are permitted.  No matter what your preferences are: be consistent and stick to it.  Either ignore Java generics and use raw type in all places, or take advantage of the improved type-safety and provide type arguments in all places. Mixing both styles is confusing and results in "unchecked" warnings that can and should be avoided.  Naturally, you have to mix both styles when you interface with source code that was written before the advent of Java generics. In these cases you cannot avoid the mix and the inevitable "unchecked" warnings. However, one should never have any "unchecked" warnings in code that is written in generic style and does not interface with non-generic APIs.  Here is a typical beginner's mistake for illustration.  Example (of poor programming style):  List <String> list = new ArrayList <String> (); Iterator iter = list.iterator();  String s = (String) iter.next(); ... Beginners often start out correctly providing type arguments and suddenly forget, in the heat of the fighting, that methods of parameterized types often return other parameterized types.  This way they end up with a mix of generic and non-generic programming style, where there is no need for it.  Avoid mistakes like this and provide type arguments in all places.  Example (corrected):  List <String> list = new ArrayList <String> (); Iterator <String> iter = list.iterator();  String s = iter.next(); ... Here is an example of a code snippet that produces avoidable "unchecked" warnings.  Example (of avoidable "unchecked" warning):  void f(Object obj) {   Class type = obj.getClass();   Annotation a = type.getAnnotation(Documented.class); // unchecked warning   ... } warning: [unchecked] unchecked call to <A>getAnnotation(java.lang.Class<A>) as a member of the raw type java.lang.Class         Annotation a = type.getAnnotation(Documented.class);                                          ^ The getClass method returns an instantiation of class Class , namely Class<? extends X> , where X is the erasure of the static type of the expression on which getClass is called. In the example, the parameterization of the return type is ignored and the raw type Class is used instead.  As a result, certain method calls, such as the invocation of getAnnotation , are flagged with an "unchecked" warning.  In general, it is recommended that type arguments are provided unless there is a compelling reason not to do so.  In case of doubt, often the unbounded wildcard parameterized type is the best alternative to the raw type.  It is sematically equivalent, eliminates "unchecked" warnings and yields to error messages if their use is unsafe.  Example (corrected):  void f(Object obj) {   Class <?> type = obj.getClass();   Annotation a = type.getAnnotation(Documented.class);    ... }
LINK TO THIS	#FAQ002
REFERENCES	What is the benefit of using Java generics? What does type-safety mean? What is an "unchecked" warning? What is the raw type? What is a parameterized or generic)type? How is a generic type instantiated? What is an unbounded wildcard parameterized type?

Should I use the generic collections or stick to the old non-generic collections?
 

Provide type arguments when you use collections; it improves clarity and expressiveness of your source code.
The JDK collection framework has been re-engineered. All collections are generic types since Java 5.0.  In principle, you can choose whether you want to use the pre-defined generic collections in their parameterized or raw form.  Both is permitted, but use of the parameterized form is recommended because it improves the readability of your source code.  Let us compare the generic and non-generic programming style and see how they differ.  Example (of non-generic style):      final class HtmlProcessor {         public static Collection process( Collection files) {             Collection imageFileNames = new TreeSet();             for (Iterator i = files.iterator(); i.hasNext(); ) {                 URI uri = (URI) i.next();                 Collection tokens = HtmlTokenizer.tokenize(new File(uri));                 imageFileNames.addAll(ImageCollector.collect(tokens));  // unchecked warning             }             return imageFileNames;         }     }     final class ImageCollector {         public static Collection collect( Collection tokens) {             Set images = new TreeSet();             for (Iterator i = tokens.iterator(); i.hasNext(); ) {                 HtmlToken tok = (HtmlToken) i.next();                 if (tok.getTag().3("img") && tok.hasAttribute("src"))  {                     Attribute attr = tok.getAttribute("src");                     images.add(attr.getValue());       // unchecked warning                 }              }             return images;         }     } From the code snippet above it is relatively difficult to tell what the various collections contain.  This is typical for non-generic code.  The raw type collections do not carry information regarding their elements.  This lack of type information also requires that we cast to the alledged element type each time an element is retrieved from any of the collections.  Each of these casts can potentially fail at runtime with a ClassCastException . ClassCastException s are a phenomenon typical to non-generic code.  If we translate this non-generic source code with a Java 5.0 compiler, we  receive "unchecked" warnings when we invoke certain operations on the raw type collections.  We would certainly ignore all these warnings, or suppress them with the SuppressWarnings annotation.  Example (of generic counterpart):      final class HtmlProcessor {         public static Collection<String> process( Collection<URI> files) {             Collection<String> imageFileNames = new TreeSet<String>();             for (URI uri : files) {                 Collection<HtmlToken> tokens = HtmlTokenizer.tokenize(new File(uri));                 imageFileNames.addAll(ImageCollector.collect(tokens));             }             return imageFileNames;         }     }     final class ImageCollector {          public static Collection<String> collect( Collection<HtmlToken> tokens) {             Set<String> images = new TreeSet<String>();             for (HtmlToken tok : tokens) {                 if (tok.getTag().equals("img") && tok.hasAttribute("src"))  {                     Attribute attr = tok.getAttribute("src");                     images.add(attr.getValue());                 }              }             return images;         }     } From the generic source code we can easily tell what type of elements are stored in the various collections. This is one of the benefits of generic Java: the source code is substantially more expressive and captures more of the programmer's intent. In addition it enables the compiler to perform lots of type checks at compile time that would otherwise be performed at runtime.  Note that we got rid of all casts. As a consequence there will be no runtime failure due to a ClassCastException .  This is a general rule in Java 5.0:  if your source code compiled without any warnings then there will be no unexpected ClassCastException s at runtime. Of course, if your code contains explicit cast expressions any exceptions resulting from these casts are not considered unexpected.  But the number of casts in your source code will drop substantially with the use of generics.
LINK TO THIS	#FAQ003
REFERENCES	package java.util Should I prefer parameterized types over raw types? What is the benefit of using Java generics? What is an "unchecked" warning? How can I disable or enable unchecked warnings? What is the SuppressWarnings annotation? What is the raw type? What is a parameterized or generic type? How is a generic type instantiated?

What is a checked collection?
 

A view to a regular collection that performs a runtime type check each time an element is inserted.
Despite of all the type checks that the compiler performs based on type arguments in order to ensure type safety it is still possible to smuggle elements of the wrong type into a generic collection.  This can happen easily when generic and non-generic code is mixed.  Example (of smuggling an alien into a collection):  class Legacy {   public static List create() {     List rawList = new ArrayList();     rawList.add("abc");            // unchecked warning     ...     return rawList;   }   public static void insert(List rawList) {     ...      rawList.add(new Date ());        // unchecked warning     ...   } } class Modern {   private void someMethod() {     List< String > stringList = Legacy.create();  // unchecked warning     Legacy.insert(stringList);      Unrelated.useStringList(stringList);   } } class Unrelated {   public static void useStringList(List<String> stringList) {     ...     String s = stringList.get(1);   // ClassCastException     ...   } } An "alien" Date object is successfully inserted into a list of strings.  This can happen inadvertantly when a parameterized type is passed to a piece of legacy code that accepts the corresponding raw type and then adds alien elements.  The compiler can neither detect nor prevent this kind of violation of the type safety, beyond issuing an "unchecked" warning when certain methods of the raw type are invoked. The inevitable type mismatch will later show up in a potentially unrelated part of the program and will mainfest itself as an unexpected ClassCastException .  For purposes of diagnostics and debugging JDK 5.0 adds a set of &ldquo;checked&rdquo; views to the collection framework (see java.util.Collections ), which can detect the kind of problem explained above.  If a checked view is used instead of the original collection then the error is reported at the correct location, namely when the "alien" element is inserted.  Example (of using a checked collection):  class Legacy {   public static List create() {     List rawList = new ArrayList();     rawList.add("abc");          // unchecked warning     ...     return rawList;   }   public static void insert(List rawList) {     ...      rawList.add(new Date());     // ClassCastException     ...   } } class Modern {   private void someMethod() {     List<String> stringList        = Collections.checkedList (L egacy.create() ,String.class) ; // unchecked warning     Legacy.insert(stringList);      Unrelated.useStringList(stringList);   } } class Unrelated   public static void useStringList(List<String> stringList) {     ...     String s = stringList.get(1);      ...   } } The checked collection is a view to an underlying collection, similar to the unmodifiable and synchronized views provided by class Collections . The purpose of the checked view is to detect insertion of "aliens" and prevent it by throwing a ClassCastException in case the element to be inserted is of an unexptected type.  The expected type of the elements is provided by means of a Class object when the checked view is created. Each time an element is added to the checked collection a runtime type check is performed to make sure that element is of an acceptable type.  Here is a snippet of the implementation of  the checked view for illustration.  Example (excerpt from a checked view implementation):  public class Collections {    public static <E> Collection<E> checkedCollection(Collection<E> c, Class<E> type ) {     return new CheckedCollection<E>(c, type);   }   private static class CheckedCollection<E> implements Collection<E> {     final Collection<E> c;     final Class<E> type;     CheckedCollection(Collection<E> c, Class<E> type) {       this.c = c;       this.type = type;     }     public boolean add(E o){       if (! type.isInstance (o))         throw new ClassCastException();       return c.add(o);     }   } } The advantage of using a checked view is that the error is reported at the correct location. The downside of using a checked collection is the performance overhead of an additional dynamic type check each time an element is inserted into the collection.  The error detection capabilities of the checked view are somewhat limited.  The type check that is performed when an element is inserted into a checked collection is performed at runtime - using the runtime type representation of the expected element type.  If the element type is a parameterized type the check cannot be exact, because only the raw type is available at runtime.  As a result, aliens can be inserted into a checked collection, although the checked collection was invented to prevent exactly that.  Example (of limitations of checked collections):  class Legacy {   public static List legacyCreate() {     List rawList = new ArrayList();     rawList.add(new Pair("abc","xyz"));  // unchecked warning     ...     return rawList;   }   public static void legacyInsert(List rawList) {     ...      rawList.add(new Pair(new Date(),"Xmas") );        // unchecked warning     ...   } } class Modern {   private void someModernMethod() {     List< Pair<String,String> > stringPairs        = Collections.checkedList( legacyCreate() ,Pair.class) ; // unchecked warning     Legacy.insert(stringPairs);      Unrelated.useStringPairs(stringPairs);   } } class Unrelated {   public static void useStringPairs(List<Pair<String,String>> stringPairList) {     ...     String s = stringPairList.get(1).getFirst(); // ClassCastException     ...   } } The checked view can only check against the raw type Pair and cannot prevent that an alien pair of type Pair<Date,String> is inserted into the checked view to a collection of Pair<String,String> .  Remember, parameterized types do not have an exact runtime type representation and there is not class literal for a parameterized type that we could provide for creation of the checked view.  Note, that a checked view to a collection of type Pair<String,String> cannot be created without a warning.  Example:  Lis t<Pair<String,String>> stringPairs        = Collections.checkedList         (new ArrayList< Pair<String,String> > () , Pair .class); // error Lis t<Pair<String,String>> stringPairs        = Collections.checkedList         ( (List<Pair>) (new ArrayList< Pair<String,String> > ()) , Pair .class); // error Lis t<Pair<String,String>> stringPairs        = Collections.checkedList         ( (List) (new ArrayList< Pair<String,String> > ()) , Pair .class); // unchecked warning We cannot create a checked view to a parameterized type such as List<Pair<String,String>> , because it is required that we supply the runtime type representation of the collection's element type as the second argument to the factory method Collections.checkedList .  The element type Pair<String,String> does not have a runtime type representation of its own; there is no such thing as Pair<String,String>.class .  At best, we can specify the raw type Pair as the runtime type representation of the collection's element type.  But this is the element type of a collection of type List<Pair> , not of a List<Pair<String,String>> .  This explains why we have to add a cast.  The natural cast would be to type List<Pair> , but the conversion from ArrayList<Pair<String,String>> to List<Pair> is not permitted. These two types a inconvertible because they are instantiations of the same generic type for different type arguments.  As a workaround we resort to the raw type List , because the conversion ArrayList<Pair<String,String>> to List is permitted for reasons of compatibility.  Use of the raw type results in the usual "unchecked" warnings.  In this case the compiler complains that we pass a raw type List as the first arguments to the Collections.checkedList method, where actually a List<Pair> is exptected.  In general, we cannot create a checked view  to an instantiation of a collection whose type argument is a parameterized type (such as List<Pair<String,String>> ). This is only possible using debatable casts, as demonstrated above.  However, it is likely that checked collections are used in cases where generic and non-generic legacy code is mixed, because that is the situation in which alien elements can be inserted into a collection inadvertantly.  In a mixed style context, you might not even notice that you work around some of the compiler's type checks, when you create a checked view, because you have to cope with countless "unchecked" warnings anyway.  The point to take home is that checked views provide a certain safety net for collections whose element type is a raw type, but fails to provide the same kind of safety for collections whose element type is a parameterized type.
LINK TO THIS	#FAQ004
REFERENCES	class java.util.Collections What is an "unchecked" warning? What is the raw type? What happens when I mix generic and non-generic code? How do I pass type information to a method so that it can be used at runtime? How do I perform a runtime type check whose target type is a type parameter? Why is there no class literal for concrete parameterized types? How does the compiler translate Java generics? What is type erasure? What is the type erasure of a parameterized type?

What is the difference between a Collection<?> and a Collection<Object>?

How do I express that a collection is a mix of objects of different types?

What is the difference between a Collection<Pair<String,Object>>, a Collection<Pair<String,?>> and a Collection<? extends Pair<String,?>>?

How can I make sure that a wildcard that occurs repeatedly in the same scope stands for the same type?

Using Generic Methods

Why doesn't method overloading work as I expect it?
 

Because there is only one byte code representation of each generic type or method.
When you invoke an overloaded method and pass an argument to the method whose type is a type variable or involves a type variable, you might observe surprising results.  Let us study an example.  Example (of invocation of an overloaded method):  static void overloadedMethod( Object o) {         System.out.println("overloadedMethod(Object) called"); } static void overloadedMethod( String s) {         System.out.println("overloadedMethod(String) called"); } static void overloadedMethod( Integer i) {         System.out.println("overloadedMethod(Integer) called"); } static <T> void genericMethod(T t) {         overloadedMethod (t) ;  // which method is called?  } public static void main(String[] args) {         genericMethod( "abc" ); } We have several overloaded versions of a method.  The overloaded method is invoked by a generic method which passes an argument of type  T to the overloaded method.  Eventually the generic method is called and a string is passed as an argument to the generic method. One might expect that inside the generic method the string version of the overloaded method is invoked, because the method argument is a string.  This, however, is wrong. The program prints:   overloadedMethod( Object ) called How can this happen?  We pass an argument of type  String to the overloaded method and yet the version for type  Object is called. The reason is that the compiler creates only one byte code representation per generic type or method and maps all instantiations of the generic type or method to that one representation.  In our example the generic method is translated to the following representation:   void genericMethod( Object t) {         overloadedMethod (t) ;  } Considering this translation, it should be obvious why the  Object version of the overloaded method is invoked.  It is entirely irrelevant what type of object is passed to the generic method and then passed along to the overloaded method.  We will always observe a call of the  Object version of the overloaded method.  More generally speaking:  overload resolution happens at compile time, that is, the compiler decides which overloaded version must be called. The compiler does so when the generic method is translated to its unique byte code representation.  During that translation type erasure is performed, which means that type parameters are replaced by their leftmost bound or  Object if no bound was specified.  Consequently, the leftmost bound or Object determines which  version of  an overloaded method is invoked.  What type of object is passed to the method at runtime is entirely irrelevant for overload resolution. Here is another even more puzzling example. Example (of invocation of an overloaded method):   public final class GenericClass<T> {     private void overloadedMethod( Collection<?> o) {         System.out.println(" overloadedMethod (Collection<?>)");     }     private void overloadedMethod( List<Number> s) {         System.out.println(" overloadedMethod (List<Number>)");     }     private void overloadedMethod( ArrayList<Integer> i) {         System.out.println(" overloadedMethod (ArrayList<Integer>)");     }     private void method(List<T> t) { overloadedMethod(t);  // which method is called?     }     public static void main(String[] args) { GenericClass <Integer> test = new  GenericClass < Integer >();         test.method( new  ArrayList< Integer > () );     } } The program prints:   overloadedMethod (Collection<?>) One might have expected that version for  ArrayList<Integer> would be invoked, but that again is the wrong expectation.  Let us see what the compiler translates the generic class to.  Example (after type erasure):   public final class GenericClass {     private void overloadedMethod( Collection o) {         System.out.println(" overloadedMethod (Collection<?>)");     }     private void overloadedMethod( List s) {         System.out.println(" overloadedMethod (List<Number>)");     }     private void overloadedMethod( ArrayList i) {         System.out.println(" overloadedMethod (ArrayList<Integer>)");     }     private void method(List t) { overloadedMethod(t);     }     public static void main(String[] args) { GenericClass test = new  GenericClass ();         test.method( new  ArrayList () );     } } One might mistakenly believe that the compiler would decide that the  List version of the overloaded method is the best match.  But that would be wrong, of course.  The  List version of the overloaded method was originally a version that takes a  List<Number> as an argument, but on invocation a  List<T> is passed, where  T can be any type and need not be a  Number . Since  T can be any type the only viable version of the overloaded method is the version for  Collection<?> . Conclusion: Avoid passing type variables to overloaded methods. Or, more precisely, be careful when you pass an argument to an overloaded method whose type is a type variable or involves a type variable.
LINK TO THIS	#FAQ050
REFERENCES	How does the compiler translate Java generics? What is type erasure? What is method overriding? What is method overloading? What is a method signature? What is the @Override annotation? What are override-equivalent signatures? When does a method override its supertype's method? What is overload resolution?

Why doesn't method overriding work as I expect it?
 

Because the decision regarding overriding vs. overloading is based on the generic type, not on any instantiation thereof.
Sometimes, when you believe you override a method inherited from a supertype you inadvertantly overload instead of override the inherited method.  This can lead to surprising effects.  Let us study an example. Example (of overloading):   class Box <T> {   private T theThing;   public Box( T t)        { theThing = t; }   public void reset( T t) { theThing = t; }   ... } class WordBox< S extends CharSequence > extends Box< String > {   public WordBox( S t)    { super(t.toString().toLowerCase()); }   public void reset( S t) { super.reset(t.toString().toLowerCase()); }    ... } class Test {     public static void main(String[] args) {         WordBox<String> city = new WordBox<String>("Skogland");         city.reset("Stavanger");  // error: ambiguous     } } error: reference to reset is ambiguous,  both method reset (T) in Box<String> and method reset(T) in  WordBox<String> match         city.reset("Stavanger");             ^ In this example, one might be tempted to believe that the method  WordBox<String>.reset(String) overrides the superclass method  Box<String>.reset(String) .  After all, both methods have the same name and the same parameter types.  Methods with the same name and the same parameter types in a super- and a subtype are usually override-equivalent.  For this reason, we might expect that the invocation of the  reset method in the  Test class leads to the execution of the  WordBox<String>.reset(String) method.  Instead, the compiler complains about an ambiguous method call.  Why? The problem is that the subclass's  reset method does not override the superclass's  reset method, but overloads it instead.  You can easily verify this by using the @Override annotation. Example (of overloading):   class Box <T> {   private T theThing;   public Box( T t)        { theThing = t; }   public void reset( T t) { theThing = t; }   ... } class WordB ox <S extends CharSequence> extends Box <String> {   public WordBox( S t)    { super(t.toString().toLowerCase()); } @Override    public void reset( S t) { super.reset(t.toString().toLowerCase()); }    ... } error: method does not override a method from its superclass         @Override           ^ When a method is annotated by an  @Override annotation, the compiler issues an error message if the annotated method does not override any of its supertype's methods.  If it does not override, then it overloads or hides methods with the same name inherited from its supertype.  In our example the  reset method in the generic  WordBox<S extends CharSequence> class overloads the  reset method in the parameterized  Box<String> class. The overloading happens because the two methods have different signatures. This might come as a surprise, especially in the case of the instantation  WordBox<String> , where the two  reset methods have the same name and the same parameter type.  The point is that the compiler decides whether a subtype method overrides or overloads a supertype method when it compiles the generic subtype, independently of any instantiations of the generic subtype.  When the compiler compiles the declaration of the generic  WordBox<S extends CharSequence>  class, then there is no knowledge regarding the concrete type by which the type parameter  S might later be replaced.  Based on the declaration of the generic subtype the two  reset methods have different signatures, namely  reset(String) in the supertype and  reset(S_extends_CharSequence) in the generic subtype. These are two completely different signatures that are not override-equivalent.  Hence the compiler considers them overloading versions of each other. In a certain instantiation of the subtype, namely in  WordBox<String> , the type parameter  S might be replaced by the concrete type String.   As a result both  reset methods visible in  WordBox<String> suddenly have the same argument type.  But that does not change the fact that the two methods still have different signatures and therefore overload rather than override each other. The identical signatures of the two overloading version of the  reset method that are visible in  WordBox<String>  lead to the anbiguitiy that we observe in our example. When the  reset method is invoked through a reference of type  WordBox<String> , then the compiler finds both overloading versions.  Both versions are perfect matches, but neither is better than the other, and the compiler rightly reports an ambiguous method call. Conclusion: Be careful when you override methods, especially when generic types or generic methods are involved.  Sometimes the intended overriding turns out to be considered overloading by the compiler, which leads to surprising and often confusing results.  In case of doubt, use the  @Override annotation.
LINK TO THIS	#FAQ051
REFERENCES	How does the compiler translate Java generics? What is type erasure? What is method overriding? What is method overloading? What is a method signature? What is the @Override annotation? When does a method override its supertype's method? Can a method of a generic subtype override a method of a generic supertype?

Coping With Legacy

What happens when I mix generic and non-generic legacy code?
 

The compiler issues lots of "unchecked" warnings.
It is permitted that a generic class or method is used in both its parameterized and its raw form.  Both forms can be mixed freely.  However, all uses that potentially violate the type-safety are reported by means of an "unchecked warning".  In practice, you will see a lot of unchecked warnings when you use generic types and methods in their raw form.  Example (of mixing paramterized and raw use of a generic type):  interface Comparable<T> {   int compareTo(T other); } class SomeClass implements Comparable {   public int compareTo(Object other) {     ...   } } class Test {   public static void main(String[] args) {     Comparable x = new SomeClass();     x.compareTo(x);     // "unchecked" warning   } } warning: [unchecked] unchecked call to compareTo(T) as a member of the raw type java.lang.Comparable         x.compareTo(x);                    ^ The Comparable interface is a generic type.  Its raw use in the example above leads to "unchecked" warnings each time the compareTo method is invoked.  The warning is issued because the method invocation is considered a potential violation of the type-safety guarantee.  This particular invocation of compareTo is not unsafe, but other methods invoked on raw types might be.  Example (of type-safety problem when mixing parameterized and raw use):  class Test {   public static void someMethod( List list) {     list.add("xyz");     // "unchecked" warning   }   public static void test() {     List<Long> list = new ArrayList<Long> ();     someMethod(list);   } } warning: [unchecked] unchecked call to add(E) as a member of the raw type java.util.List      list.add("xyz");              ^ Similar to the previous example, the invocation of the add method on the raw type List is flagged with an "unchecked" warning.  The invocation is indeed unsafe, because it inserts a string into a list of long values.  The compiler cannot distinguish between invocations that are safe and those that are not.  It reports "unchecked" warnings just in case that a call might be unsafe.  It applies a simple rule: every invocation of a method of a raw type that takes an argument of the unknown type that the class's type parameter stands for, is potentially unsafe.  That does not mean, it must be unsafe (see Comparable.compareTo ), but it can be unsafe (see List.add ).  If you find that you must intermix legacy and generic code, pay close attention to the unchecked warnings. Think carefully how you can justify the safety of the code that gives rise to the warning. Once you've made sure the warning is harmless suppress it using the SuppressWarnings annotation.  If you can re-engineer existing code or if you write new code from scratch you should use generic types and methods in their parmeterized form and avoid any raw use.  For instance, the examples above can be "repaired" as follows:  Example #1 (corrected):  interface Comparable<T> {   int compareTo(T other); } class SomeClass implements Comparable <Object> {   public int compareTo(Object other) {     ...   } } class Test {   public static void main(String[] args) {     Comparable <Object> x = new SomeClass();     x.compareTo(x);     // fine   } } No "unchecked" warning occurs if the Comparable interface is used in its parameterized form in all places.  Example #2 (corrected):  class Test {   public static void someMethod( List <String> list) {     list.add("xyz");     // fine   }   public static void test() {     List<Long> list = new ArrayList<Long> ();     someMethod(list);   // error   } } error: someMethod(java.util.List<java.lang.String>) cannot be applied to java.util.List<java.lang.Long>)         someMethod(list);         ^ The "unchecked" warning in someMethod is no longer necessary if the generic type List is used in its parameterized form as List<String> .  With this additional type information the compiler is now capable of flagging the formerly undetected type-safety problem in method test as an error.
LINK TO THIS	#FAQ101
REFERENCES	What does type-safety mean? What is the raw type? Can I use a raw type like any other type? What is an "unchecked" warning? How can I disable or enable unchecked warnings? What is the SuppressWarnings annotation?

Should I re-engineer all my existing types and generify them?