Costin Manolache wrote:
So for NIO - we should create another copy of 5 large files ? Most of
the functions are complete duplicates - a simple extend would eliminate
them.
The problems are in few abstractions - like Handler - which can be
easily fixed to
accomodate NIO / APR or traditional.
NIO is a valid solution - and may be as fast as APR, in particular
with JDK1.6 -
and it avoids the JNI layer.
I like APR more too - but I don't think it's wise to say there will be
no better solution
in the future :-) It just happens that today APR is faster - and has a
lot of features beyond
NIO.
IMO the future is in features integrated at the low-level with the VM
- in particular
if they can bypass JNI or use non-garbage-collected heaps ( as in
real-time java ). It
would be hard for any JNI solution to beat this - but of course,
that's future, not so easy
to predict...
I completely disagree. APR is a well accepted IO impl for webservers
(obviously), and works very well. There's room for experimentation as
separate implementations, but should NIO get better and support the
features we need (somehow, I doubt the second one will ever be the case
...), there's going to be ample time to switch to it later (emphasis on
later; Java 6 as the Tomcat target is quite far away). In the meantime,
I don't see the point of yet another abstraction layer.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
