[Top][All Lists]

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

Re: GNU Classpath 0.12, ..., 1.0

From: Mark Wielaard
Subject: Re: GNU Classpath 0.12, ..., 1.0
Date: Sat, 13 Nov 2004 11:58:53 +0100

Hi all,

On Wed, 2004-11-10 at 22:15, Mark Wielaard wrote:
> We do now have a few small regressions however. There is something wrong
> with zip/jar archives on the classpath (this might or might not be a GNU
> Classpath issue, we changed the VM interface subtly so maybe it is a
> runtime issue). Opening a JarFile with 'verify' set to false  breaks
> (and is not thread-safe) [I have a fix for that].
> RepaintManager.paintDirtyRegions() seems broken [saw a fix for that in
> libgcj gui branch]. And at least with jamvm Eclipse 3 starts up, but
> crashes immediately after that [it did work correctly 2 weeks ago].
> I want to try to make the 0.12 release with all the great new stuff on
> Friday (Nov 12). But then we need to focus on fixing the regressions. If
> you have larger updates, please discuss on the mailinglist (or
> #classpath) first before committing.

It seems all the known regressions have now be fixed (those above, plus
the problem with JikesRVM). I have one last Swing.ToolTipManager fixlet,
but that can wait (and must see below, for savannah status).
The Eclipse 3 (but not 2) startup problem seems to only happen on SMP
machine (it disappears when I don't use a SMP kernel, this is on a Intel
hyperthreading system) with jamvm [*]. It works fine with gcj/gij (it
doesn't work anymore with kaffe though since they don't implement
java.lang.ClassLoader.setSigners which we now call).

What is holding up the release is writing the announcement and NEWS
entries. And the fact that savannah seems to be down... Hopefully both
will be fixed later this weekend.



[*] Hint for Robert. When inspecting with -verbose I can see that some
classes are [loaded] multiple times. I can slow down crashing a bit by
making various VMClass static methods synchronized, but that is not a
full solution. I think this is a bug in the runtime that needs to guard
against defining the same class from multiple threads and not completely
fixable in our core libraries setup.

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

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