wood burning stoves 2.0*
The moose likes Beginning Java and the fly likes Optional Methods, Support for null values - Collection Interfaces Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Optional Methods, Support for null values - Collection Interfaces" Watch "Optional Methods, Support for null values - Collection Interfaces" New topic
Author

Optional Methods, Support for null values - Collection Interfaces

Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1013
    
  15
Hi,

I'm currently going through the Oracle tutorials - http://docs.oracle.com/javase/tutorial/collections/interfaces/list.html and as I read these tutorial, there are a couple of things that I find a little confusing.

One of the things that I don't understand is what do we mean when we say a collection implementation supports null values or doesn't support null values. I know, in general, Lists can have null values, a Set cannot have null values, and a Map can have one null key and several null values. But still I'm not sure about it.

Does an ArrayList support nulls?
I can add null values in an ArrayList<String> but I cannot use Collections.sort() method if it has nulls but contains() method would behave correctly. I could write a compare/compareTo method that could behave in a certain way with null values. Generally we wouldn't allow our Collection ( even more so, if the collection is a sorted collection implementation ) to contain nulls, but what do we exactly mean when we say that a collection can/cannot handle null values.

Would the following be true.
An implementation supports null values, if it can contain nulls, and such nulls are searchable? If a collection can contain null values, I guess we can't ever sort it. Right? Sorted collections hence can't contain nulls and these are the collection implementations that don't support nulls?

Another thing I don't really understand is the optional methods. If we have an implementation that we refer to as a concrete implementation ( a non abstract class ), shouldn't it( or its class hierarchy ) implement all the interface methods either directly or indirectly? I couldn't notice any optional List method that ArrayList class has not implemented. But am I missing something here?
The tutorial has the following text.

Here is a little text from the Oracle docs-

The Arrays class has a static factory method called asList, which allows an array to be viewed as a List. This method does not copy the array. Changes in the List write through to the array and vice versa. The resulting List is not a general-purpose List implementation, because it doesn't implement the (optional) add and remove operations: Arrays are not resizable.


So would it be correct to say that optional methods are for only those kind of interface implementations that cannot be directly instantiated but can be returned by a method ( or may be passed as an argument - perhaps the returned value only cause there'd be no other way to otherwise instantiate them).

Thanks,
Chan.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7696
    
  20

Chan Ag wrote:I could write a compare/compareTo method that could behave in a certain way with null values.

Well, you could write a Comparator that does. compareTo() is part of the Comparable interface, and so will be "part of" the object you're comparing, so if you didn't write it, you can't be sure that it caters for nulls, or how it does so even if it does. Many implementers will simply let it throw NPE, which is the easiest - since you rarely have to do anything explicit - and also correct, since behaviour is symmetrical.

On the occasions that I've catered for nulls, I usually make null greater than any actual value, because it puts them at "the end".

Would the following be true.
...If a collection can contain null values, I guess we can't ever sort it. Right?

No, you simply have to decide where 'null' comes in your ordering sequence.

Another thing I don't really understand is the optional methods.

Ah. And you're not the first.

If we have an implementation that we refer to as a concrete implementation ( a non abstract class ), shouldn't it( or its class hierarchy ) implement all the interface methods either directly or indirectly?

Yes, but an implementation doesn't actually have to do anything.

Many of the methods of AbstractList (from which a lot of the Java Lists are derived) throw UnsupportedOperationException by default, so unless they are overridden, that particular method doesn't "do" anything. Many developers (mistakenly, IMO) also implement Iterators that don't allow remove().

So would it be correct to say that optional methods are for only those kind of interface implementations that cannot be directly instantiated

Again, no. Arrays.asList(array) returns a List that can't be add()ed to. Try it.

The problem is more of a design one than than anything else. Personally, I find the List interface rather bloated, which results in many implementations that don't override ALL its methods - or simply have them throw UOE. The question then is: is it really a List?

I'm afraid that discussion might go on for a while, so I leave it for you to think about.

Suffice to say: there's no "black-and-white" about this sort of stuff.

Winston

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

Joined: Sep 06, 2012
Posts: 1013
    
  15
Thanks so much, Winston.

On the occasions that I've catered for nulls, I usually make null greater than any actual value, because it puts them at "the end".


This must be one of the best practices then if we cannot avoid null values. I will try it with some of the collection implementations I am currently trying to learn. I'm sure there will be other things to be kept in mind too but I hope to find those answers in the process of testing it along with equals, hashCode, and canEual methods . And I'm sure you all are still going to be around (like you've always been ) to help me through with it.

Yes, but an implementation doesn't actually have to do anything.


I just checked the source code of AbstractList class and now I understand what you're saying. The Arrays class defines a static inner class, ArrayList that extends from the AbstractList class and the add methods the AbstractList class has just throws the UOE. So it is this inner ArrayList type, the asList() method returns. Wow. This was interesting.

Thank you so much.

Chan.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7696
    
  20

Chan Ag wrote:This must be one of the best practices then if we cannot avoid null values. I will try it with some of the collection implementations I am currently trying to learn.

Yes, but you have to understand that unless you create some interface that indicates that subclasses specifically order nulls, the collection won't have any knowledge of how the type that it's storing orders itself, so you could still end up with NPEs if you try to order/sort the contents.

Thank you so much.

You're most welcome.

Winston
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7696
    
  20

Winston Gutkowski wrote:unless you create some interface that indicates that subclasses specifically order nulls, the collection won't have any knowledge of how the type that it's storing orders itself

Actually, that's not quite true. What you could do is have it impose an ordering for nulls that overrides anything that the stored type does. For example, for a collection that only allows Comparables:and have it use that whenever a comparison is needed.

And, as always, that's only ONE way to do it.

Winston
Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1013
    
  15
Thanks, Winston. I'm sure it's a great solution/thing to consider. I really appreciate that you shared it with us.

This is just a quick 'for now note' -I'm still processing it.

Thank you.
Chan.


My mind has suddenly stopped working ( it's temporary I know - I'm used to it). So I will take a break and try it later. :-)









Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1013
    
  15
Hi, Winston.

That's a wonderful ( smart, yet easy to understand- perhaps not as easy to come up with ) solution. Thanks so much.

So using this trick we can actually write our safest compare method without checking if the compareTo method ( if it's a class implementing the Comparable interface) has dealt with nulls and/or
replace the last part with additional checks we may have. That's really cool.

I have to say something else too. I just don't understand why I was not able to follow things yesterday. Seems I had temporarily forgotten the context, the problem, the solution, ...
It took me less than a few minutes to understand it today. Hope I didn't offend you.

Thanks,
Chan.
Volodymyr Levytskyi
Ranch Hand

Joined: Mar 29, 2012
Posts: 505
    
    1

Hello!

Please cover my tutorials on Java Collections to know them profoundly.

There you will see what is LinkedList and what is ArrayList, and what is HashMap


True person is moral, false is right!
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7696
    
  20

Chan Ag wrote:Hope I didn't offend you.

Not at all. Pretty much every time I have anything more than just basic to do with generics, I have to take a "time out" (or re-read the darn tutorial ). It's a natural by-product of thinking.

Anyways, glad it helped.

Winston
Chan Ag
Bartender

Joined: Sep 06, 2012
Posts: 1013
    
  15
Volodymyr Levytskyi -

Thanks.

 
 
subject: Optional Methods, Support for null values - Collection Interfaces