icedtea7 nio2 overlay

[Andrew John Hughes]

2009/5/30 Mark Wielaard <mark at klomp.org>:
> Hi,
>
> After going over the nio2 related make check failures with Alan Bateman
> we discovered that --enable-nio2 is still the default and that it still
> copies over some files from the nio2 overlay. In particular it copies
> over the non-final zipfs and the java.io.Inputs/Outputs classes which
> are still experimental. That causes a couple of test failures, in
> particular java/io/Inputs/Basic and demo/nio/ZipFileSystem/sanity.
>
> I would like to propose to not add these to our nio2 implementation
> until/unless they are included in jdk7 proper. Would it be OK if I just
> removed the nio2 overlay and the whole --enable-nio2 configury/build
> machinery?
>
> 2009-05-30  Mark Wielaard  <mark at klomp.org>
>
>    * configure.ac (enable-nio): Removed.
>    * Makefile.am (ICEDTEA_PATCHES): Remove patches/icedtea-nio2.patch.
>    (stamps/overlay.stamp): Don't copy overlays/nio.
>    * patches/icedtea-nio2.patch: Removed.
>    * overlays/nio/*: Removed.
>
> If people prefer to keep it around, then I would like to switch the
> default to --disable-nio2.
>
> Cheers,
>
> Mark
>

I was thinking about this too, but didn't want to change it just
before the release in case something else broke.  The additional files
don't really interact with anything else in the build and there is
always --disable-nio2 in the release.

Of course, now we are (finally) post-release, I'm more than happy for
this change to go in, as long as the committed patch also hg rms the
files in overlays/nio2 (your ChangeLog also has a typo: it says
overlays/nio).

When I can face hacking on IcedTea7 again, I want to try and simplify
the build further.  One thing this release reinforced for me was how
many build permutations we have and it's just ridiculous trying to
test them all.  As IcedTea7 has been maintained, used and tested
almost solely by myself before the release, when others started to
join in too things were found to be broken.  It seems we all have
slightly different ways of building things and if they are not
regularly tested, they break down.  This is especially true of jdk7
where the underlying OpenJDK code is changing at a much more rapid
rate. For OpenJDK6, build drops are becoming almost bi-annually and
you can probably investigate each and every changeset if necessary.
For jdk7, build drops are weekly and changesets pour in from numerous
feeder repositories.  This is also why I suggest we need to reevaluate
the inclusion of third-party code such as Xrender and CACAO; the
upstream (or someone at least) needs to be following jdk7 development.

I saw Clemens discussed Xrender with you on IRC after I left last
night.  If Clemens plans to base his forest on the 2d forest, then we
probably shouldn't pull from there as there may be 2d changes that
aren't in the jdk7 master.  At present, the IcedTea forest feeds from
the jdk7 master and has a few patches on top which didn't make b59 (a
LCMS security patch from aph and the DISABLE_NIMBUS changeset from
myself, both imported from the build forest IIRC).  It may be better
to just wait for Xrender to appear in jdk7 as far as IcedTea7 goes.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8