collection API and Null elements

[Murat Tasan]

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

 

[John C. Bollinger]

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.

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.

 

[Chris Smith]

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;

...
}

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Murat Tasan]

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;

...
}

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?

 

[Chris Smith]

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.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation