Andrew Haley wrote:
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.
Change it back in classpath or in a Sun JRE? For the first point we have
mauve. If the Sun implementation changes, libraries will be adapted
because the developers will run into that bug themselve...
So, use this as a temporary hack if you must, but prepare to be
disappointed.
Disappointed because my patch will be rejected by classpath or because
the Sun implementation will change?
Marco
