Re: [really patch] Re: HashMap putAll/putAllInternal bug

[Bryce McKinlay]

On Oct 10, 2003, at 12:40 AM, Sascha Brawer wrote:

> Bryce McKinlay <address@hidden> wrote on Fri, 10 Oct 2003 
> 00:08:16
> +1300:
>
> > I wrote a quick test program to examine the behaviour of Sun's
> > ArrayList - and it definitely calls and relies on size().
>
> Would it make sense to have such test programs in the Mauve test suite?

In this case: no. I'm reluctant to add such a test because it doesn't 
test whether we match the specification, but rather the behaviour of 
another vendors implementation. The internal implementation of 
addAll/putAll is clearly undefined, and properly written code should 
not rely on them being implemented one way or another - only that they 
do what the spec says.

As an analogy, the Linux & glibc developers have never attempted to 
duplicate in precise detail the internal behaviour of functions from 
Solaris or any other OS - instead, they implemented the POSIX spec. 
Likewise, GCC doesn't precisely replicate other vendors compilers, it 
implements the ISO specifications for C and C++. If you rely on a 
behaviour of eg Microsoft's compiler that is undefined by the specs, 
such as evaluation orders or aliasing behaviour, thats too bad - your 
code is broken.

Unfortunately in classpath we often have to make compromises and match 
the JDKs behaviour because many classes and packages are 
under-specified. In those cases we need to make an effort to fix Sun's 
mistake and specify the behaviour properly in our docs.

The collections classes, on the other hand, are actually quite well 
specified in my opinion (having architected many of the current 
collections implementations used in classpath). I don't believe that 
anyone should need to write collections code that relies on unspecified 
details.  Besides, matching every single one of those details would be 
close to impossible without copying Sun's source code virtually line 
for line. I think its better to stop now, while we have a very stable 
and bug-free set of collections classes, or we will forever be chasing 
silly, unspecified details like this, and potentially introducing real 
regressions and reducing performance in the process.

Regards

Bryce.