On 09 Sep 2003 10:11:27 -0600 Tom Tromey <[EMAIL PROTECTED]> wrote: > >> Basically, LazyHashtable.contains(Object value) calls > >> super.contains(Object value) in Hashtable, which in Classpath's > >> implementation, calls Hashtable.containsValue(Object value). > >> Unfortunately, LazyHashTable.containsValue(Ojbect value) overrides that, > >> just calling calling LazyHashTable.contains(Object value) again, and we > >> have a loop. > > It isn't clear to me that this is definitively a Classpath bug. Who's > to say there isn't currently-working code out there that does the > opposite? The JDK docs certainly don't specify this sort of thing.
I think it depends on how you define "what is a bug". Sure, it's not in the spec, but Sun implemented it a certain way, and that gets exposed, and code (eg. Ant, and probably others) depends on the way it was implemented. Since it's unlikely that any Java(tm) branded JVM is going to use an alternate implementation, people are going to unwittingly rely on these hidden dependencies. It's going to be really difficult to try to mount a campaign to try to convince people to code to the spec (if you can call the Javadocs a spec), vs. coding to the implementation, especially when only 0.0001% of Java developers use ours. It might be easier to just admit defeat, and change our implementation when it doesn't match. > I think it would be easy to change ant to be robust in the face of any > implementation of Hashtable. > > > What version of ant is this? I don't see this file in the ant in rhug > (1.5). I stumbled across it in Ant from CVS dated '4/28/2003 00:00 UTC' (the newer CVS stuff doesn't work for me yet because of nio). I'm trying to build a regression test based on Jakarta Gump (2gigs of code!). Cheers, - Jim _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath