> 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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
