Java: Raw Types vs. Generics

Question

Consider the sample code below

/* The new Java 5 or later Generic code */
class TestInserter {
    public static void main(String[] ar) {
        List<Integer> myList = new ArrayList<Integer>();
        myList.add(20);
        myList.add(42);
        Inserter ins = new Inserter();
        ins.insert(myList);
    }
}

/* Legacy Code */
class Inserter {
    public void insert(List list) {
        list.add(new Integer(55));
    }
}

Compiling and executing the above code will run just fine, without any complaints from the compiler or the JVM. The non type-safe insert() method is inserting a new Integer object in our type-safe ArrayList. However, if I change the insert method to something like this:

public void insert(List list) {
        list.add(new String("55"));
}

What say?! will the above code run? Think about it, Yes sure it will run, Strange but yes the above code compiles and runs just fine. This is a little different from Arrays, which gives you both compile time and run time protection and prevents such things to happen. Why did they do Generics this way? Why does Java allows Generics to put in a value other than the specified type?!

I would change the title of your question to explain more clearly what it is that you're explaining; maybe change it to "**Java: Raw Types vs. Generics**". Also, this might be a useful thing to have in Stackoverflow documentation, so maybe check if something similar has been added (it probably has). — ostrichofevil, Mar 20 '17 at 02:47
I haven't checked...did you find this topic as covered already in the docs? — Adil, Apr 18 '18 at 16:40

Adil · Accepted Answer · 2017-03-20T03:50:59.807

Now for the answer. Using the insert method to add an Integer to our list is quite safe and permissible, as it matches the type we have specified for our myList variable. But when we try to insert a String into an ArrayList that was meant to hold only Integer values, then there is a problem, not at compile time but at runtime, when you try to invoke an Integer-specific method on your wrongly added String instance.

There is one thing you ought to understand in order to understand this entire question and its purpose - The JVM has no idea that you were trying to insert a String into an ArrayList meant to hold only Integers. All your generics and their type-safety are restricted to compile time only. Through a process called "type erasure", the compiler removes all of the type parameters from the generic code. In other words, even though you wrote something like this:

List<Integer> myList = new ArrayList<>();

Becomes the following after the compiler is done with it:

List myList = new ArrayList();

However, why did they keep Generics like this?

The answer is simple! If it wouldn't have been for this weird behavior then the legacy code from earlier versions of Java would have been broken and Million Java developers would have to edit Trillions of their old Java code to make it work again!!

But don't blame the compiler; when you try to run the code, the compiler tries to warn you with the following warning:

$> javac TestInserter.java  
Note: TestInserter.java uses unchecked or unsafe operations.  
Note: Recompile with -Xlint:unchecked for details.

And when you do as the compiler asks you to do as follows:

$> javac -Xlint:unchecked TestInserter.java
TestInserter.java:15: warning: [unchecked] unchecked call to add(E) as a member of the raw type List  
        list.add(new String("55"));  
                 ^  
where E is a type-variable:  
  E extends Object declared in interface List  
1 warning

As far as the compiler is concerned, it tries to tell you that it suspects that some code in your program might end up in trouble.

To wrap it up, Think of generics as just compile time protection. The compiler uses the type information (Type specified in parameter) to make sure that you don't insert the wrong things into a collection (or a user defined generic type) and that you don't fetch values from the wrong reference type. All of the generic protection is compile time! That's it for this.

Great answer. I would have upvoted more than once if it were possible. — geco17, Jan 23 '21 at 12:25

score 0 · Answer 2 · answered Mar 20 '17 at 03:01

Compile-time generics cover nearly all situations where you need generic type assertions. For the rare cases where you need to design in run-time generics type safety, you can store a run-time type token (RTTT), an instance of Class<T> where T is the generic parameter.

public class Foo<T> {
  private final Class<T> rttt;
  public Foo(Class<T> rttt) {
    if (rttt == null) {
      throw new IllegalArgumentException("null rttt");
    }
    this.rttt = rttt;
  }
  // etc. RTTT handles runtime type safety
}

Besides that you don't need runtime generics most of the time, Java had a problem when it introduced generics. Making them runtime enforceable ("reifiable") would have either broken a bunch of legacy code or horridly complicated the language. Making generics compile-time-only by default allowed legacy code to live as raw types and still coexist with better-written code.

There's an element of compromise there, such as the temptation to write raw types. Don't do that. And we sometimes have to dance around unchecked conversions. But it gets the job done, nearly always.

Java: Raw Types vs. Generics

2 Answers2

Linked