commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacob Kjome (JIRA)" <j...@apache.org>
Subject [jira] Commented: (BEANUTILS-268) BeanComparator.compare() doesn't can't handle null values returned by bean properties
Date Tue, 23 Jan 2007 06:58:49 GMT

    [ https://issues.apache.org/jira/browse/BEANUTILS-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466661
] 

Jacob Kjome commented on BEANUTILS-268:
---------------------------------------


My point about the comparators was that the statement implies that BeanComparator's default
internal comparator doesn't deal with null values and that one would need to be provided that
does if the beans in question might return null for their properties.  Maybe I misinterpreted,
but there's no point in stating it the way it is stated if BeanComparator's default internal
comparator does, in fact, deal with null values.  Because in that case, it's not a necessity
to provide a custom comparator to the constructor.  Instead, it should read something like...

"Custom comparators should deal with the possibility of null values returned by bean properties
or risk a NullPointerException"

The above is more to the point and implies that BeanComparator's default internal comparator
deals with null bean property values, which really ought to be the case, especially in a library
that is supposed to be non-brittle....

But then again, after looking at the code, ComparableComparator does *not* deal with null
values.  And that's the reason for the NullPointerException I'm getting.  Of course the error
message could have been better to point that out in the first place.  I see it has been address
in the latest version.

I guess the way to deal with null values is to use the commons-collections NullComparator.
 And I suppose when using the ReverseComparator, I'd need to provide it with the NullComparator
in order for it to avoid NullPointerExceptions.  Ok, I think I get it.

Closing as invalid.

Jake

> BeanComparator.compare() doesn't can't handle null values returned by bean properties
> -------------------------------------------------------------------------------------
>
>                 Key: BEANUTILS-268
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-268
>             Project: Commons BeanUtils
>          Issue Type: Bug
>          Components: Bean-Collections
>    Affects Versions: 1.7.0
>            Reporter: Jacob Kjome
>
> I've got a bean that has properties that will, at times, return null values.  BeanComparator
appears to fail with a NullPointerException.  It's difficult to tell exactly where because
the exception thrown is a ClassCastException with a message of e.toString(), so all I know
is that a NullPointerException happened, not where it happened.
> I suspect that the exception happens inside the compare(Object, Object) method with the
call...
> Object value1 = PropertyUtils.getProperty( o1, property );
> Looking into PropertyUtils, and following the path, it seems like the problematic code
is in...
> PropertyUtilsBean.getNestedProperty(Object, String)
> That code is rather involved.  If I get around to performing a minimal testcase, I'll
see if I can narrow down the exception to a particular piece of code.  In any case, there's
no reason why a bean shouldn't be allowed to return null for a given property.
> My workaround is to add methods for respective properties that are guaranteed to not
return null.  For instance, if I have a getter called getMyValue(), I create a corresponding
method called getMyValueNotNul().  I have to take care with the value it returns, though.
 The position in a sort for a null value would be different than a literal empty String. 
So, depending on the Object type, I have to make up values which will either come before all
other non-null values or after all other non-null values (I don't recall what the natural
order of null values are; whether they come first or last.  I know when ordering on a SQLcolumn,
null values show up last.  Hopefully that behavior is consistent here, but that's beside the
point here).
> I hope this can be fixed before 1.8.0 is released!
> Jake

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message