[kaffe] Bug Report: StackOverflowError and Collections

[Jim Pick]

On 09 Sep 2003 10:11:27 -0600
Tom Tromey <tromey at redhat.com> 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