[patch] Support New NIO in IcedTea

[C. K. Jester-Young]

Hi Mark,

On Sun, Aug 31, 2008 at 04:41:33PM +0200, Mark Wielaard wrote:
> Nice idea. I wasn't aware that NIO2 was progressing already. I now see
> that my ignorance was partly because it seems this work is done in the
> nio/nio forest instead of in the jdk7/nio2 forest. Do you know how they
> relate?

Looking at the jdk7/nio2, the last push was in February. The current
nio2 stuff seemed to have been established in April (see, e.g., [1]),
by different parties. But I'm not involved in NIO2 currently, let alone
back then, so I can't really say anything.

[1] http://mail.openjdk.java.net/pipermail/nio-dev/2008-April/000001.html

> Also, how do you keep track of which commits are really nio2 related and
> which ones are the commits that just sync with the master jdk7 repo? It
> would be nice to have an easy way to see just those changes/commits made
> for the new nio support.

Yes, I'm much wondering about the same question myself. One of my
aspirations is to have an IcedTea build that incorporates multiple
projects simultaneously (NIO2, MLVM/Da Vinci Machine, and BGGA Closures
are three of the ones I have an interest in), and being able to work
with _just_ the diffs would be nice.

On that note, the MLVM project works as a set of patches against the
mainline jdk7 code (although I have had some success applying it
against the NIO2 code too). It uses the Mercurial mq extension for
doing all the patching, and patches can be marked as being for specific
releases of jdk7, for example.

> Do you need any special tag to get that tag? While building with your
> patch applied and doing just:
> autoreconf --force --install \
>   && ./configure --enable-hg --with-project=nio2 \
>   && make

The tip revision is, at the time of writing, at -b94. I successfully
built with the supplied patches on Ubuntu 8.04, on amd64. Just to test
portability, I'm now building within a 32-bit chroot, just to see if
it works correctly there too.

(This process is a notorious PITA; I've had to write a fakeuname.so
to ``convince'' the build tools that I'm building on a 32-bit machine,
because some of the scripts don't respect the --build option that I
sent to configure.)

Here are the configure arguments I used:

./configure --with-openjdk --with-openjdk-home=/usr/lib/jvm/java-6-openjdk \
--enable-hg --with-project=nio2

In other words, I'm building with OpenJDK 6 as supplied with Ubuntu.
(With the icedtea-implicit-enable-hg.diff I recently sent, that makes
the --enable-hg option redundant. My patch is, by the way, designed to
be applied to IcedTea revision 1158.)

I noticed from your build output that you're also using 1.6 javac for
bootstrapping; is that a Sun build, or from IcedTea? Should it make
a difference?

> I got:
> 	  /home/mark/src/icedtea/bootstrap/jdk1.6.0/bin/javac  -g \
> 	    -d lib/hotspot-tools \
> 	    -source 1.5 \
> 	    -sourcepath \
> 	      'hotspot-tools:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes:/home/mark/src/icedtea/generated:/home/mark/src/icedtea/rt' \
> 	    -bootclasspath '' @hotspot-tools-source-files.txt ; \
> 	fi
> incorrect classpath: hotspot-tools/com/sun/codemodel/internal/ClassType.java

This is very odd. The first line in hotspot-tools-source-files.txt is
indeed hotspot-tools/com/sun/codemodel/internal/ClassType.java, which
means that whatever make system you have is not passing the '' argument
before it. Either that, or the javac you have is disregarding it.

> 1. ERROR in /home/mark/src/icedtea/openjdk/jdk/src/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java (at line 144)
> 	public void disableInterruptor(AbstractInterruptibleChannel ch) {
> 	            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The method disableInterruptor(AbstractInterruptibleChannel) of type new JavaNioChannelsSpiAccess(){} must override a superclass method

This is to do with your javac too. Some compilers support the @Override
annonation being applied to interface methods, it seems, whereas other
ones don't. I haven't quite figured out which ones do/don't allow it.

I remember seeing some IcedTea patches whose sole purpose is to remove
@Override annotations that would choke some compilers. However, since I
don't have such a compiler, working out which @Override annotation to
remove would be difficult task, since I presume the best way to find
them is by trial and error. :-)

> Did I get the wrong nio tree, or did I apply the patch wrongly?

No, and no, it seems. :-)

> There are no real legal requirements except for making sure every
> contribution is free software. But it is encouraged to push anything
> upstream into openjdk of course to keep divergence as low as possible.

Cool, thanks for the clarification!

> Thanks for working on this, nio2 is very exciting.

No worries, and yes, I'm totally keen to get this working on IcedTea!

Many thanks,
	---Chris K.