Re: What are we doing in regards to JDK 1.4?

["Daniel F. Savarese" <df...@savarese.org>]

>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.

The java.util.regex package is completely orthogonal to the nio stuff and
reading input from a CharSequence doesn't qualify as integration.  Any
third-party package could do the same.  The nio stuff was sorely needed
and we shouldn't have had to wait for over 5 years for Java to be able to
do decent I/O.  The regex stuff has serious problems from both a
performance and API design perspective and had no business being thrown
in as an afterthought with JSR-51.

Regular expression and logging have no business being in the core anyway.
The story of Java is one of getting the APIs wrong and having to fix them
in a later release, throwing in unnecessary classes and packages,
retrofitting the language to make up for obvious oversights, and flat out
ignoring the lessons learned during the standardization process of languages
that came before, such as C++.  Guy Steele's OOPSLA 98 keynote is a model
of how Java should have evolved but clearly hasn't:
http://www.cs.bell-labs.com/who/wadler/pizza/gj/Documents/steele-oopsla98.pdf
A couple of years ago, Rick Ross wrote an editorial about the problem of
Sun putting Java companies out of business by putting the functionality
of their products into the Java core ("Tools Before Jewels", Java Developer's
Journal, April 1999 http://www.sys-con.com/java/archives/subscribe/0404/)
It mistakenly implied my old company went out of business because of Sun
(it didn't), but visits the same issue brought up about JDK 1.4 and some
of its new APIs.  This is a problem that's been with us for a while
and is not going away.

Anyway, my comments have strayed off-topic.  All we can do is keep writing
code as usual and hammer Sun with constructive criticism when they go astray
in the hopes they'll listen.  Yes, some of our projects will lose a certain
amount of following because their functionality is duplicated in JDK 1.4,
but they won't die.  For two years I didn't update the software that
became jakarta-oro, yet its following grew even though there were actively
maintained alternative products.  If you provide something that programmers
need and want that others don't, programmers will use your software and
stick with you.  log4j and jakarta-oro are distinguished by their
performance, feature set, and flexibility of their designs.
It's unfortunate that the JCP is leading to the unnecessary bloat of the
Java core by introducing functionality that is already provided by
numerous third-parties, but Jakarta will survive if we focus on quality
and the advantages of an open source development model.  As Jon
pointed out, you can get bugs fixed quickly, have your changes introduced,
and directly influence the development of the software.  Jakarta
evolves more rapidly and is much more responsive to developer needs.

No worries here.

daniel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re: What are we doing in regards to JDK 1.4?

[Endre Stølsvik <En...@Stolsvik.com>]

[ -- cut -- ]

| A couple of years ago, Rick Ross wrote an editorial about the problem of
| Sun putting Java companies out of business by putting the functionality
| of their products into the Java core ("Tools Before Jewels", Java Developer's
| Journal, April 1999 http://www.sys-con.com/java/archives/subscribe/0404/)

[ -- cut -- ]

| It's unfortunate that the JCP is leading to the unnecessary bloat of the
| Java core by introducing functionality that is already provided by
| numerous third-parties

Isn't it actually quite cool that Sun is including lots of functionality
with it's Java core? I kind of feel that this is among what makes Java so
extremely cool, that a _lot_ of commonly used functionality is already in
the core. And you're guaranteed that it will be there when you deploy your
little program somewhere else. This, of course, especially goes for the
native parts of the language, like GUI and Connections and other HW
interfacing parts.

If you look at it this way, then I feel that Sun is doing the right thing.
If a company comes up with something really smart, why shouldn't Sun
include it? Make a similar/better core-part of it? I feel that it's
_really_ cool that this happens, it makes the Java language evolve and
stay up-to-date.
  But, if they use it exclusively to close down competiotion, then they're
not much better than MS. But I have this good trust and faith in Sun, Sun
is Cool, Sun is Nice (brainwashed some time ago ;), and I believe that
they do most of their stuff "to be nice"..

But yes, I do agree that it might seem like the JCP is way to closed, and
that Sun and their heavy _money_ partners (but not necessarily with that
much more _brains_ than the OS community) should listen to feedback a bit
more.


-- 
Mvh,
Endre


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org