Question

I wrote some code using generics and I got into the following situation I didn’t manage to understand:

I have the interface IpRange, and the following class:

public class Scope<IpRange<T extends IP>> {
     List<IpRange<T>> rangesList;
     public List<IpRange<T>> getRangesList() {return rangesList;}
}

Now from some test class if i write the following:

Scope<Ipv4> myScope = new Scope<Ipv4>(); 
scope.getRangesList().get(0)

I’m getting object of IpRange type, but if I’m using a raw type and doing this:

Scope myScope = new Scope();
scope.getRangesList().get(0)

I’m getting Object, and I can’t use the ipRange methods unless i explicitly cast it to Range.

If it would have been List<T> i get it, since i used raw type the compiler has no way to know what is the actual type of the list items, but in this case it will be always IpRange type, so why I’m not getting Object?

The thing is that when I’m creating the scope I don’t necessarily know the actual range type. Consider this constructor: public Scope(String rangeStringList); for all I know, the string could be “16.59.60.80” or “fe80::10d9:159:f:fffa%”. But what I do know is that I passed some IpRange object to the compiler and I would expect to be able to use this interface whether this is ipv4 or ipv6. And since the compiler can know for sure that this is ipRange even if I used row type, i wonder why java chose to do it this way

Answer 1

People have pointed out that all generic type information is stripped when using raw types, and hinted that this is to do with backwards compatibility. I imagine this might not be satisfactory without an explanation, so I’ll try to explain how such a problem might be encountered with code like yours.

First of all, imagine the code you have written there is part of an old library, and you’re in the process of upgrading the library by adding generics. Perhaps it’s a popular library and lots of people have used the old code.

Someone may have done something like this using the classes from your library:

private void someMethod(Scope scope, Object object) {
  scope.getRangesList().add(object);
}

Now, looking at this we know that Object might not be of the type IpRange, but this is a private method, so let’s assume that type checking is effectively performed by whatever methods call someMethod. This might not be good code, but without generics it does compile and it might work just fine.

Imagine that the person who wrote this upgraded to the new version of your library for some new features or unrealted bug fixes, along with this they now have access to more type safety with your generic classes. They might not want to use it, though, too much legacy like the extract above code using raw types.

What you are effectively suggesting is that even though ‘scope’ is a raw type, the List returned from getRangesList() must always be of type List<IpRange<? extends IP>>, so the compiler should notice this.

If this were the case though, the legacy code above which adds an Object to the list will no longer compile without being edited. This is one way backwards compatibility would be broken without disregarding all available generic type information for raw types.