aspose file tools*
The moose likes Java in General and the fly likes remove(Object Element) of Collections - Reason for parameter type Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "remove(Object Element) of Collections - Reason for parameter type "Object" instead of "E"" Watch "remove(Object Element) of Collections - Reason for parameter type "Object" instead of "E"" New topic
Author

remove(Object Element) of Collections - Reason for parameter type "Object" instead of "E"

Kalpana Periasamy
Greenhorn

Joined: Jan 05, 2012
Posts: 11
Hi Java Geeks,
This is my first post in Java Ranch. Happy new year to all.

Coming to the question, I was looking at the "Collections" interface. I saw these 2 methods.

void add(E element);
void remove(Object Element);

Why isnt the remove method declared as void remove(E Element)?

Thanks in advance,
Kalps.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14269
    
  21

Because the remove(Object element); method already existed before generics were added to Java (in Java 5). For backward compatibility reasons, the old method that takes an Object has been preserved. If Java would have had generics from the beginning, it wouldn't have had this method that takes an Object instead of an E.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Jesper de Jong wrote:Because the remove(Object element); method already existed before generics were added to Java (in Java 5)...

@Kalpana: And just to add to what Jesper said, there are other examples too, such as Map.get().
In practise, these methods don't violate type safety too much, since what they do relies on finding the passed object in the collection (which won't be the case if it's the wrong type). They are also documented to optionally throw ClassCastException if the passed type is incompatible.

Perhaps they'll add a delete(E element) method at some point, but I don't see any burning need for it.

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19720
    
  20

They can't add new methods to any existing interfaces, or it would break all implementations by other developers. This actually is already the case with JDBC. PreparedStatement, ResultSet and a few other interfaces have received extra methods in Java 6 that will not be implemented by older drivers. Perhaps the JDBC framework has solved this by catching errors and transforming them in SQLExceptions (e.g. SQLFeatureNotSupportedException), but it's also possible that you get a NoSuchMethodError instead (I haven't tested this yet). Perfect.

However, as Winston said, there is no need for a method like that. remove accepts any object as its argument which mean that a delete(E) method would do exactly the same but with some extra compiler checking. During runtime the two would be equivalent since type erasure would turn delete(E) into delete(Object).


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3647
    
  17

Actually, there's another important reason.

The method takes an Object for greater flexibility. Say we have a variable:

List<? extends Number> numbers = new ArrayList<Integer>();

If the remove method took a generic type, we could not use it to remove anything from the numbers list. After all, numbers isn't aware of what the exact type argument is.
Since the remove takes an Object, we can try to remove anything from the list referenced by numbers. If the list doesn't contain the value, nothing happens.

Adding the wrong type to a list would cause great problems at runtime. That's why a compiler check is important. Removing a wrong type from a list does nothing, so checking is unnecessary.
Kalpana Periasamy
Greenhorn

Joined: Jan 05, 2012
Posts: 11
@All : Thanks for the explanation.
For my understanding, what was the method definition of add before Generics were added in Java 5. Was it void add(Object element)? If so, when add(Object element) is rewritten as add(E element), why not remove(Object element) is rewritten?
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4422
    
    8

Well, Stephan's given one reason why they didn't.
Kalpana Periasamy
Greenhorn

Joined: Jan 05, 2012
Posts: 11
I understand his reason. I think that I dint understand the basics of generics yet. Do you have any pointers to good generics tutorial?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: remove(Object Element) of Collections - Reason for parameter type "Object" instead of "E"