Marco Trudel writes: > Andrew Haley wrote: > > Marco Trudel writes: > > > > Right, so if it isn't a bug it can't be a regression. > > True! But I made a bug in my patch, fixed in the attached one. > > > > >> So as I said, I don't mean to offend you, I just can't follow > > > >> why we wouldn't follow the RI when we still fulfill the > > > >> specifications. > > > >> > > > > > > > > I did say that I was against *going out of our way* to adhere to > > > > the precise behavior of the RI, when neither the spec nor the > > > > algorithms used require it. > > > > > > > > It's fine if you want to go looking for things like this, and > > > > writing fixes for them. These are not a bugs, though, and are not > > > > a priority. > > > > > > Absolutely. There's no need to actively search such problems. But > > > if I stumbles over one, I will adapt classpath to follow the RI and > > > thus make the life of classpath users a tiny little bit easier... > > > > The problem with this kind of approach is that it is, in practice, > > impossible to maintain. Anywhere that uses a comparator might well > > break this again. In practice, that's almost certain to happen. > > > > So, we can change this now, but it will break in the future. Maybe > > tomorrow, maybe next week, but it will break. > > Do you mean if we change this now to be identical to the Sun behavior, > it will break bad comparators written for the classpath version of > Arrays.binarySearch()?
No, I don't mean that. I mean that if we change this behaviour today, we can't guarantee that someone won't chnage it back tomorrow. So, use this as a temporary hack if you must, but prepare to be disappointed. Andrew.
