my dog learned polymorphism*
The moose likes Beginning Java and the fly likes Collection Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Collection " Watch "Collection " New topic
Author

Collection

Umesh Vajpai
Greenhorn

Joined: Mar 14, 2010
Posts: 26
I read it " Some of the operations in the interface are optional, meaning that a collection may choose to provide a stub implementation of such an operation that throws an UnsupportedOperationException when invoked. The implementations of collections from the java.util package support all the optional operations in the Collection interface" in Khalid Mughal's Book.Could you explain it.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14278
    
  21

Welcome to JavaRanch.

To me, that sentence is quite clear - if you create your own collection class, it doesn't need to implement all methods; some are optional, and if you don't need them, you should throw an UnsupportedOperationException from them.

Can you provide some more context, or explain in more detail what it is exactly that you don't understand?


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39478
    
  28
Welcome to the Ranch

Have you read this Java™ tutorials section? Did that help? Look at methods like Collections#unmodifiableList(java.util.List) which return a kind of List which has no add() method.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19725
    
  20

Well it does have an add method, only you can't use that add method. Just try it:
See what happens.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39478
    
  28
Yes, you are right there, Rob. I know already what will happen.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19725
    
  20

Sorry, that "try" was meant for Umesh. I should have made that more clear.
Umesh Vajpai
Greenhorn

Joined: Mar 14, 2010
Posts: 26
Jesper Young wrote:Welcome to JavaRanch.

To me, that sentence is quite clear - if you create your own collection class, it doesn't need to implement all methods; some are optional, and if you don't need them, you should throw an UnsupportedOperationException from them.

Can you provide some more context, or explain in more detail what it is exactly that you don't understand?



Hi Jesper Young,

Thanks.What i want to know is about interface rule.To implement a interface it is must to implement all methods then how could we can do it as collection is interface.can you explain it in more detail.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18914
    
  40

Umesh Vajpai wrote:
Thanks.What i want to know is about interface rule.To implement a interface it is must to implement all methods then how could we can do it as collection is interface.can you explain it in more detail.


Well, in this case, it did implement all methods of the interface -- it just implemented by simply throwing the unsuppported operation exception.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11444
    
  16

an interface is a contract - nothing more, nothing less. Someone has defined a 'Collections' contract. If you choose to write a class that "implements Collection", you MUST provide an implementation for each and every method listed in the class.

However, this contract explicitly states that you may not want to implement all the methods - some may not make sense for your Collection. The rules require you to, so what do you do?

You are allowed to have your implementation of the method throw an 'unsupported method' exception. You satisfy the language requirement of implementing the method, but don't have to have the method actually DO anything.

This is better than writing an empty block. By throwing the exception, you are giving the programmer an indication of what's wrong.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19725
    
  20

The alternative to allowing these methods to throw exceptions would be to remove them from Collection and add them to specific sub interfaces. This would lead to an explosion of interfaces. For instance:
As you see the number of interfaces triples.

There must be a distinction between collections that allow removal and collections that allow addition. For instance, the collections returned by Map.keySet(), Map.values() and Map.entrySet() only allow removal, not addition. ArrayList would then implement List, RemovableList and AddableList.

Another issue is the iterator() method. The Iterator interface has a remove() method. That means that Iterator needs to get a RemovableIterator sub interface as well. RemovableCollection would get two iterator() methods: iterator() that returns an Iterator and removableIterator() that returns a RemovableIterator.

Let's make it even worse. List has method listIterator() that returns a ListIterator. This interface does not only allow removal but also adding new elements. RemovableList would have removableIterator, AddableList would have addableIterator, but now we need an interface that extends both RemovableList and AddableList that has another method that returns an iterator that implements both RemovableListIterator and AddableListIterator.

An overview so far (limiting to Collection and List for now):
1) Collection
2) Iterator
3) RemovableCollection extends Collection (adds methods clear(), remove(Object), removeAll(Collection), retainAll(Collection), removableIterator())
4) RemovableIterator extends Iterator (adds method remove())
5) AddableCollection extends Collection (adds methods add(E), addAll(Collection))
6) List extends Collection (adds methods get(int), indexOf(Object), lastIndexOf(Object), listIterator(), subList(int, int))
7) ListIterator extends Iterator (adds methods hasPrevious(), previous(), previousIndex())
8) RemovableList extends List RemovableCollection (adds methods remove(int), removableListIterator(), removableSubList(int, int))
9) RemovableListIterator extends ListIterator, RemovableIterator
10) AddableList extends List, AddableCollection (adds methods add(int, E), addAll(int, Collection), addableListIterator(), addableSubList(int, int))
11) AddableListIterator extends ListIterator (adds method add(E))
12) ModifiableList extends AddableList, RemovableList (adds method modifiableListIterator())
13) ModifiableListIterator extends AddableListIterator, RemovableListIterator

Compare that with what we have now:
1) Collection
2) Iterator
3) List extends Collection
4) ListIterator extends Iterator

Did I say triples? It's even worse! And I haven't even touched the subject of List's and ListIterator's set methods! What about a List that does not allow adding or removing, but does allow replacing? There already is such a List - the return value of Arrays.asList. So that's even more interfaces:
14) ReplaceableList extends List (adds methods set(E), replaceableIterator(), replaceableSubList(int, int))
15) ReplaceableListIterator (adds method set(E))
(let ModifiableList also extend ReplaceableList, and ModifiableListIterator also extend ReplaceableListIterator so we won't get extra interfaces for that)

I'm getting a headache
 
Don't get me started about those stupid light bulbs.
 
subject: Collection