[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bryce McKinlay
Subject: Re: [really patch] Re: HashMap putAll/putAllInternal bug
Date: Fri, 10 Oct 2003 10:13:04 +1300

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

Bryce McKinlay <address@hidden> wrote on Fri, 10 Oct 2003 00:08:16

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]