collection API and Null elements

Thread view:

Murat Tasan - 06 May 2005 19:37 GMT

in a Set (and other Collection sub-interfaces), there are some rather
silly declarations for the jdk API.

for example, the Set.contains(Object) method throws NullPointerException
if, "the specified element is null and this set does not support null
elements (optional)."

while i understand why this is optional, it makes headaches for a
definition like this for a method like contains(). if anyone is accepting
a general Set into a custom method then, and i try to search for a null
element, i now have to worry about catching an exception.

such a declaration certainly makes sense for modification methods (like
add()), but does anyone know what the rationale is for this design in
non-modification methods (like contains())?

thanks for any insight,

murat

Reply to this Message

John C. Bollinger - 06 May 2005 23:11 GMT

> for example, the Set.contains(Object) method throws NullPointerException
> if, "the specified element is null and this set does not support null
[quoted text clipped - 4 lines]
> a general Set into a custom method then, and i try to search for a null
> element, i now have to worry about catching an exception.

Possibly. You can also specify in your method's docs that the Set
argument is required to support null elements, and that the method may
throw NPE if it does not.

> such a declaration certainly makes sense for modification methods (like
> add()), but does anyone know what the rationale is for this design in
> non-modification methods (like contains())?

A Collection implementation that cannot contain null elements for some
reason may not be able to test for them for the same reason. For
instance, consider a simplified HashSet without the special-case support
for null that java.util.HashSet has. To determine whether an instance
contains some object, that object's hash code must be computed, but
you'll get an NPE if you try to invoke hashCode() on a null reference.

Signature

John Bollinger
jobollin@indiana.edu

Reply to this Message

Chris Smith - 06 May 2005 23:56 GMT

> A Collection implementation that cannot contain null elements for some
> reason may not be able to test for them for the same reason. For
> instance, consider a simplified HashSet without the special-case support
> for null that java.util.HashSet has. To determine whether an instance
> contains some object, that object's hash code must be computed, but
> you'll get an NPE if you try to invoke hashCode() on a null reference.

That strikes me as a weak argument. If the implementation could not
contain null references, then the code would just look like this:

public boolean contains(Object o)
{
if (o == null) return false;

...
}

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Reply to this Message

Murat Tasan - 07 May 2005 00:05 GMT

>> A Collection implementation that cannot contain null elements for some
>> reason may not be able to test for them for the same reason. For
[quoted text clipped - 12 lines]
> ...
> }

exactly, this is basically what i would expect any such class to do. this
simple additions removes the need to constantly check for NPEs when using
the sub-interfaces of Collection.

i guess i should really try directing this question to the API
designers/implementors at Sun. i don't feel confident i'll get an answer,
though. has anyone else ever sent a similar high-level design question to
a big company and gotten a response?

Reply to this Message

Chris Smith - 07 May 2005 00:15 GMT

> i guess i should really try directing this question to the API
> designers/implementors at Sun. i don't feel confident i'll get an answer,
> though. has anyone else ever sent a similar high-level design question to
> a big company and gotten a response?

I doubt they'll write you an essay on design considerations. They'll
probably reject the suggested change as well, since it could break old
code.

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Reply to this Message

collection API and Null elements

Free Magazines