Submit My Question - Recent Questions - Recent Answer
java >> Core >> Core APIs

Why is List.remove(...) accepts Object and not <E>?

Hi thereCan anyone explain why in java 1.5 the List.remove(Object obj) method expect Object and not 'generic'?Thanks, Oren
[145 byte] By [og104716a] at [2007-9-23]
«« Connecting a Local Java Program with a Mysql Database Hosted on the Interne
»» write several time in an excel file?
# 1

You have a point. I guess they figure that doing a runtime check on the class here isn't worth it, as the operation will still perform like it would if the object was not in the list.

> Hi there

> Can anyone explain why in java 1.5 the

> List.remove(Object obj) method expect Object and not

> 'generic'?

>

> Thanks, Oren

tjacobs01a at 2007-7-11 > top of java,Core,Core APIs...
# 2

i'm assuming that they compare by references, so the type of the Object does not need to be know

example

public boolean remove(Object o){

for (int i = 0; i < lastIndex; i++){

if (o == innerArray[i]){

// create a new array (which does not include the removed object)

return true

}

}

return false;

}

now..the remove is not implemented like this...just making an assumption that checking for equality is done by references

tnguyen1973a at 2007-7-11 > top of java,Core,Core APIs...
# 3

It doesn't matter whether the comparison is done by references (it generally isn't). It accepts Object because passing in some type other than what's in the List won't "corrupt" it - the List will still contain only that type of object. So there's no use in restricting the type passed in.

nasch_a at 2007-7-11 > top of java,Core,Core APIs...
# 4

No, it compares with equals.

But the first poster is right--there's no need to type-check what's removed. If your list takes only Foo and you try to remove a Bar, well, it simply won't be there. There's no danger of a runtime problem due to lack of compile-time type safety like there is with add().

jverda at 2007-7-11 > top of java,Core,Core APIs...
# 5

> If your list takes only

> Foo and you try to remove a Bar, well, it simply

> won't be there.

Not exactly, for two reasons.

First, Bar and Foo are types, not classes. If Foo and Bar are, say, interfaces, then an class might implement both of them.

Second, lists are based on equality, not identity, so a Foo and a Bar might be equal to each other (and thus remove would work) even though they aren't the same.

Malvolioa at 2007-7-11 > top of java,Core,Core APIs...
# 6

> Second, lists are based on equality, not identity, so

> a Foo and a Bar might be equal to each other (and

> thus remove would work) even though they aren't the

> same.

Yeah, but since you know lists are based on equality, you know that when you say list.remove(bar), you're saying "remove the first item that's equal() to bar". There's only so much that it's reasonable to expect the compiler to protect you from. :-)

jverda at 2007-7-11 > top of java,Core,Core APIs...
# 7

>> If your list takes only

>> Foo and you try to remove a Bar, well, it simply

>> won't be there.

>Not exactly, for two reasons.

>First, Bar and Foo are types, not classes. If Foo and Bar are, say, interfaces,

>then an class might implement both of them.

Technically correct, but not really relevant. Sure, if I have a collection of Foo's and I try to remove a Bar, then based on just that sentence, you can't say for sure that there isn't a Bar in the list. Bar might be an interface, it might be a subtype of Foo, etc. But the original point was, if I have a list of Foo's and I try to remove a Bar from it, and in fact a Bar would not be a legal member of the list, then it's going to end up not-found. There's no way that attempting to remove inconsistent members is going to corrupt the list, like attempting to add inconsistent members would corrupt the list if allowed.

jay.johansena at 2007-7-11 > top of java,Core,Core APIs...
Core
Core APIs

Core Hot Topic

Core New Topic

Core

Site Classified