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!)
Attachment:
signature.asc
Description: This is a digitally signed message part
