On Wed, 2005-07-27 at 10:11 +0100, Gary Benson wrote:
Robin Green wrote:
> [Footnote 1] - I found a bug in AspectJ yesterday which only
> appeared under libgcj, but *wasn't* a libgcj bug. It was a latent
> bug in AspectJ that was only exposed by a slightly different, but
> still valid, collection class implementation in libgcj. So it's not
> logically valid to assume that a bug that only occurs on libgcj is
> necessarily a bug *in* libgcj.
This kind of thing happens all the time. The Java specification can
be quite loose, and often things will because applications rely on
unspecified defaults or behaviours that libgcj's (correct, as per the
spec) implementation does not provide.
One thing that is nice is that our collection classes seem more strict
on concurrent modifications. I have found a couple of programs that
modified list collections while simultaneously iterating over them. The
result of that isn't deterministic, but other implementations just allow
it since they don't have to throw a ConcurrentModificationException, but
we always detect this situation and do throw the exception.
Not that we don't have our own bugs or do things wrong in some other
direction. But in a couple of places our strict reading and checking for
method pre-conditions does help find (latent) bugs in programs.
Cheers,
Mark
BTW. If something doesn't seem to work/compile with the free tool set,
because it depends on com.sun.* classes please take a look at the
following wiki page for some pointers:
http://developer.classpath.org/mediation/ClasspathMigration
(Updates welcome of course!)