[muscle] Re: Patch for supporting NIO in Java client
- From: "Jeremy Friesner" <jaf@xxxxxxxxxxxx>
- To: muscle@xxxxxxxxxxxxx
- Date: Sat, 28 Jan 2006 12:19:09 PST (-0800)
Hi Lior,
> MessageTransceiver2 is exactly the same as MessageTransceiver, except
> that it uses NIO instead of the old I/O. The issue is that nio and old
> IO don't mix well, so I thought it would be better to separate the two
> driving classes completely. It is possible to reuse some parts of the
> identical code. I'll probably do it later on, when I have more time on
> my hands.
I see.
> In addition, it is possible to compile the Java client with a 1.4.0 or
> higher version of the Java compiler, in such a way as to allow older
> JVMs to use the generated class files. This would work, as long as the
> NIO code is not used at runtime in an older JRE.
That is what I'm most concerned about -- someone with an older
web browser not being able to run an applet because web browser's
older JVM can't handle the new code. (Having an applet that only
works on a few new browsers would defeat the "write once,
run anywhere" characteristic that makes Java attractive)
> lior:~/java/muscle/java$ mkdir bin
> lior:~/java/muscle/java$ javac -d bin -source 1.3 -target 1.3 `find .
> -name \*.java`
>
> The class files generated here will be usable for jdk version 1.3 and
> up, as long as you don't use unsupported things like NIO in the 1.3 runtime.
Interesting... so it would be up to the developer to check the host's JVM
version
at run time, and use MessageTransceiverThread or MessageTransceiverThread2
as appropriate. Perhaps we could include a factory method to do this
automatically?
The question would be, is the efficiency increase obtained by having NIO
support worth the extra versioning complexity? Or is either implementation
going
to be effectively bound by network bandwidth anyway, in which case one
might as well always use the older, more portable code?
Jeremy
Other related posts:
