On Wed, Feb 17, 2010 at 9:03 AM, Mark Hindess <mark.hind...@googlemail.com>wrote:
> 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!
