At 04:16 PM 6/21/2001 +0200, Edwin Martin wrote:
>At 17:33 20-6-2001 -0400, Berin wrote:
>>I have been looking through JDK 1.4, and there are a few
>>instances where what is included in the JDK steps on some
>>of our projects. Most notably:
>>
>>java.util.regex
>>---------------
>>This steps on the toes of both jakarta-regexp and jakarta-oro.
>>In fact by its existence in the JDK, the Apache projects will
>>either loose mindshare, or remain static in their mindshare.
>
>org.apache.regexp 1.2 is pretty much broken. It has some
>major flaws since 1.0 and they are still not addressed.
>
>See http://nagoya.betaversion.org/bugzilla/buglist.cgi?product=Regexp
>for a list of bugs (BTW none of them is assigned).
>
>Maybe it's better to just throw regexp out of the window and
>use Sun's "official" regex.
I'll only comment about the regex stuff in jdk 1.4 since I haven't messed
with any of the other counterparts for this discussion.
I've been playing with regex along with the nio classes and I must say that
they integrate with each other extremely well. You must try out some of the
new api's to fully appreciate the performance gains you will get from their
new SocketChannel/ByteBuffer approach to networking. The regex code will
parse through an existing buffer which could be a direct memory map from an
io device. I don't think there would be any way to do that level of
integration without rewriting lots of native code.
Jon wrote, and I agree, that Sun may make mistakes with their interfaces in
their attempt to maintain backward-compatibility, but now that they've
introduced a new select/poll style of networking that is really geared
toward performance, I'm happy to say that they've written it in new
packages from scratch rather than try to retrofit the existing io methods
to work with the new system.
It looks like they've left Strings and byte[] buffers in the dust with the
new ByteBuffer/xxxBuffer classes and all of the surrounding code works
directly on these buffers rather than needing to convert to strings or char
or byte arrays.
There was mention of NBIO <http://www.cs.berkeley.edu/~mdw/proj/java-nbio/>
recently which is a native-code nonblocking IO implementation which I've
been using for a while. The author of that code, Matt Welsh, is on the
expert group for the .nio classes of java and the Sun implementation has
stayed quite true to the desires of those of us who want the
best-performing networking possible.
It's pretty early to start switching any of the current Jakart projects to
1.4, but I'll venture to say that there will be very few java-based servers
in existence in a few years that are still using blocking
InputStream/OutputStreams and the one-or-more-threads-per-connection model.
Bernie
Bernie Bernstein
Liveworld Inc.
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
