Re: Patches waiting to be committed ...

[Stephen Crawley]

> Stephen> 1532  Fix equals/hashcode for DateFormat classes
> 
> This one looks fine to me.  I assume this was discovered by running
> some actual program?  Otherwise I'd be surprised by this behavior.

Yes indeed.  I wrote a test program to create and compare DateFormat
instances, and ran on Classpath/Kissme and on various Sun JDKs.

Actually, I can see a rationale for the Sun JDK behavior.  Normally when
you explicitly create a DateFormat object, it is because you intend to
use it to format a number of Dates.  In context, you would expect two
DateFormat objects created the same way to compare as "equal".  After
all, they represent the "same format", right?

In fact, the Sun spec says that the DateFormat constructor snarfs the
current date.  Hence, two newly created DateFormat objects may give
different output strings when formatted.  Hence, the current Classpath
behavior makes sense too.  However, since the Sun javadocs don't make
any statements on the meaning of equals (>sigh<), the actual behaviour
of the Sun JDK implementation is the specification.

> I'll check it in.

Thanks.

> Stephen> 1535  --disable-gtk-peers to allow build on RH7.2
> 
> This is kind of ugly but I suppose it is temporary as well.

Agreed on the first point, though the real ugliness is that autoconf
does not support this better.  

On the second point, this is a temporary issue for me, but there's no
reason not to leave the ugly hack in permanently, or at least until the
(unlikely) event that someone implements a gtk-peer layer for gtk+1.x!.
IMO, it is definite plus to be able to build and use (most of) Classpath
on older Linux platforms, and being able to do this with almost zero
maintenance cost is cool!

> I'll check it in.

Thanks.

-- Steve