Forums Register Login

Optional Methods, Support for null values - Collection Interfaces

+Pie Number of slices to send: Send
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.
1
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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.
1
+Pie Number of slices to send: Send
 

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
(1 cow) 1
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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. :-)









+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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
1
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
Volodymyr Levytskyi -

Thanks.

I wasn't selected to go to mars. This tiny ad got in ahead of me:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 2085 times.
Similar Threads
new SCJP in town :)
Out of Sorts
confusion about comparator, comparable and hashcode
Quession obout cellection again
NX: URLYBird / my approach of the reading problem
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 12:44:24.