Generics Question. Why is this acceptable?

[Mr. C Lamont Gilbert]

public void load(InputHandler input) throws IOException {
InputHandler [] childs = input.getNextChild().getChildren();
ArrayList<IBaseModel> list = new ArrayList<IBaseModel>(childs.length);
for(int i=0;i<childs.length;i++){
IStorable s = childs[i].readStorable();
list.add((IBaseModel)s); //Shouldn't this fail?
}
this.m_children = list;
super.load(input); //super classes element
}

Why doesn't the cast from IStorable to IBaseModel fail?
Why does the list which is parameterized for IBaseModel accept this cast without complaining about an unchecked cast?

I'm rusty so this may be simple...>

[Paul Clapham]

It's impossible to say without knowing at least something about IStorable and IBaseModel. But turning the question around, since it's acceptable that implies that IStorable can be cast to IBaseModel. Since the compiler says it can, then IStorable is a subclass of IBaseModel, or implements it, or something like that.

[Hauke Ingmar Schmidt]

You do an explicit cast. So the type the list will get is an IBaseModel - unless the cast fails. So no problem for the list here (or, to be specific, the compiler, who checks what you add to the list - the runtime does not have the type information anymore).

When you do an explicit cast you are telling the compiler that you know what you are doing. The type check will be done at runtime against the current object, so the compiler can't check anything. This is risky. So avoid explicit casts. If you really need them but don't know who created the objects, do a check with instanceof before.

[Mike Simmons]

 

Paul Clapham wrote:It's impossible to say without knowing at least something about IStorable and IBaseModel. But turning the question around, since it's acceptable that implies that IStorable can be cast to IBaseModel. Since the compiler says it can, then IStorable is a subclass of IBaseModel, or implements it, or something like that.

Assuming that both IStorable and IBaseModel are interfaces (based on the I- prefix), the compiler doesn't need to know anything else about this. It's always acceptable, at compile time, to cast a nonfinal reference type to an interface type. The compiler just assumes that your reference variable might refer to an instance of some subtype that implements the new interface, and the explicit cast means that this will be checked at runtime. But at compile time, the compiler just needs to know that it's possible that the instance in question might be a type that implements the interface, and that's all it needs.

[Paul Clapham]

 

Mike Simmons wrote:Assuming...

Yes. That's all we can do from what we were told.

[Hauke Ingmar Schmidt]

While I am no fan of the "I" notation I think it justifies the assumption (like in "IOException" or "InputHandler" ;-P).

[Mr. C Lamont Gilbert]

Duh! Sorry. I got interrupted in the middle of my post. I knew I forgot something.

IBaseModel and IStorable are both top level interfaces. They have no relation to each other.

[Mr. C Lamont Gilbert]

 

Mike Simmons wrote:

Paul Clapham wrote:It's impossible to say without knowing at least something about IStorable and IBaseModel. But turning the question around, since it's acceptable that implies that IStorable can be cast to IBaseModel. Since the compiler says it can, then IStorable is a subclass of IBaseModel, or implements it, or something like that.

Assuming that both IStorable and IBaseModel are interfaces (based on the I- prefix), the compiler doesn't need to know anything else about this. It's always acceptable, at compile time, to cast a nonfinal reference type to an interface type. The compiler just assumes that your reference variable might refer to an instance of some subtype that implements the new interface, and the explicit cast means that this will be checked at runtime. But at compile time, the compiler just needs to know that it's possible that the instance in question might be a type that implements the interface, and that's all it needs.

Really? I'm rusty but I thought in java everything was effectively an interface. Even classes can be used just like interfaces. So I don't think the compiler should think anything about an interface that it wouldn't about a class. Unless its a final class. Yes?

[Mike Simmons]

It's actually because the compiler is avoiding any assumptions about what class may ultimately implement an interface, that it gives the programmer the benefit of doubt and does not give a compiler error for a cast it can't verify at compile time. Consider code like this:

Foo f = getFoo();
Bar b = (Bar) f;

If Foo and Bar are both classes, and have no relationship to each other, then the compiler knows there is no possible way that f could ever contain a reference to anything that extends Bar. But if either Foo or Bar are interfaces, and if the other is not a final class, then there is a possibility that the getFoo() method might return a Foo that is also a Bar. So the compiler allows this cast at compile time, knowing that it will still be checked at run time.