harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Wilson <jessewil...@google.com>
Subject Re: svn commit: r910980 - /harmony/enhanced/classlib/branches/java6/modules/luni/src/main/java/java/util/TreeMap.java
Date Wed, 17 Feb 2010 18:30:38 GMT
On Wed, Feb 17, 2010 at 9:03 AM, Mark Hindess

> I have solid evidence that this change is wrong... it breaks Harmony
> tests that pass on the RI.  I've no solid evidence that this change is
> required.  So my inclination is not to put the check back.

That's curious, but I guess I haven't looked into the navigable stuff that's
new in 1.6.

A null check may be required but I'm not convinced this is the right
> place for it.  The toComparable method is just a trivial helper function
> that is clearly being used (probably quite reasonably) in a context that
> doesn't require a null check.

I think toComparable() is the right place. TreeMaps operates in two
different modes:

   - *With a comparator.* In this mode objects don't need to be comparable.
   Null is permitted, because comparators can decide where null fits in the
   total ordering.
   - *Without a comparator.* In this mode everything must be comparable.
   Null is not comparable and must be forbidden.

> Sorry, I've not got time to investigate this further right now but rest
> assured we will get to the bottom of it and fix it correctly. Raise a JIRA
> if you want to make sure it doesn't get forgotten.

Sounds good.

In general I don't think Harmony developers should submit changes when they
don't have time to investigate the problems that result from them. Ie. if a
change is controversial, the burden should be on the submitter!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message