3.3 branch, 3.3.1, 3.4, etc

Mark Wielaard mark@klomp.org
Mon Dec 16 08:10:00 GMT 2002


On Mon, 2002-12-16 at 07:48, Tom Tromey wrote:
> There are still a number of bugs I want to have fixed before 3.3
> ships.  My current list:
> [...]
> * Class loader fixes (going in tonight or tomorrow)

Yeah! I would like to see these made part of the official tree since
that makes playing with Eclipse easier.

> * Consider java.util.prefs import (low risk... worth it?)

Then also consider importing java.util.logging which is currently more
useful then prefs. But at least to get more things to compile out of the
box with gcj this does make sense. Importing java.util.prefs should be
no work at all. Importing java.util.logging means deciding what to put
in a standard logging.properties file we ship with libgcj.

> I'll try to get these all in Gnats and make sure everything is marked
> appropriately.  Comments on this list, suggestions for additions or
> removals, etc, welcome.

I couldn't check the Gnats bug numbers since I keep getting:

        Error: Couldn't connect to gnats server
        host localhost, port 1529
        connect: Connection refused

So these may already been in your list:

- java.security startup refs "GNU libgcj.security"
- BigInteger fix, either the simple one already submitted or the rewrite
  that Raif wants to do.

> I think our release criteria should be:
> * Work on all platforms supported by 3.2, plus whatever new platforms
>   make sense (S/390, SH, x86-64 -- assuming we can find testers)

I can (and already am) test on gnu-linux-unknown-powerpc.

> * Pass test suite with 0 FAIL (mostly this means XFAILing tests we
>   know we won't fix).  This includes Mauve and Jacks (with suitable
>   xfail files in place -- no way we'll really pass Jacks in the near
>   future)

This is a good idea. It was probably a mistake to keep some of the Mauve
failures open since that produced to much noise. But we did clean up a
lot of failures in Mauve already. I will send an overview of the
remaining issues later today. There are some additional bugs/regressions
that have to be fixed for 3.3.

> * Build rhug
> * Build Classpath
> * Build kawa and pass test suite
>   (I'm currently using 1.6.99, but hopefully Per will provide guidance
>   on what version is best as a reference.)

I would like to add GNU Crypto as soon as a release is made that
includes the javax.crypto stuff and the BigInteger fix is in. We have
worked hard on making gcj and GNU Crypto work together and the GNU
Crypto developers found (and solved) a lot of issues for us.
With the prelimenary BigInteger fix I now finally get 0 FAIL on the GNU
Crypto unittests. I would like to keep it that way :)

> In the past once a release has gone out we've essentially ignored the
> release branch, concentrating on the next major release.  With the 3.3
> series I plan to change that and consider fixes for the minor
> releases.  My current plan is to examine all patches for suitability
> for the branch -- if I forget this when reviewing a patch, feel free
> to remind me.
> The criteria for what to put on the branch are still unknown.  Some
> ideas include: "bug fix only", "binary compatible changes only", or
> "upwardly binary compatible changes only" (we could add a new package
> or static method, but not a new virtual method).

I am very in favor of at least active bug fixing for the 3.3 branch. In
the past it might not have been that productive since gcj wasn't as full
featured as it is now. But it seems that now a lot of people are
interested in using it for their projects. I would like to go with the
"upward compatible changes only" scenario so we can add missing classes,
methods or packages for 3.3.x, but I don't know the testing impact of



More information about the Java mailing list