| By Joseph Ottinger |
Article Rating: |
|
| November 1, 2002 12:00 AM EST |
Reads: |
16,671 |
I've been actively involved with Java development in one way or another
since 1996, including working with some of the original issues of the
servlet specification, the early adaptation of the EJB spec, and migration
to JSP not long after it became an official part of the J2EE spec. I
remember when Rick Ross first sent his e-mails for Javalobby on Usenet; I
remember playing with the specs to discover if the grail was to be found in
them as promised.
It hasn't come through for me. That's okay, because technology is and
will always be a moving target; I've refined what the grail is as I've come
near it many times, and I will continue to do so as long as my career is not
completely stagnant. What worries me, though, is the thought that the grail
is actually moving further away as time goes by, instead of staying just out
of reach, like a carrot for a hungry dray horse.
The Java Community Process was supposed to give relevant people in the
Java Community a chance to influence the specifications in positive ways.
It's guaranteed to be an arduous process, and it has lived up to its
billing. What Sun needed to do was guide the expert groups down a path laden
with thorns to determine not only what was best, but how to get what was
best implemented. What it did was let the expert groups descend into a
morass where those who shouted most were heard.
The Enterprise JavaBean specification is a good example of this. EJB 1.0
fell critically short of being easily deployable; EJB 1.1 added some great
features, and 2.0, while fulfilling some of the void left by the 1.1
specification, has sadly started to invalidate EJB's promise. The best
things about EJB remain the same; the new additions, such as local
interfaces, simply add complexity where it's not needed. And that's where
Sun's community process has failed. Nearly every container already had an
implementation of local interfaces before they were added to the spec; they
were added as a sop to a few major players who simply hadn't kept up with
the "smaller" containers. Obviously, it was possible to do without a lot of
overhead, yet Sun felt it was all right to make not only every container but
every EJB coder work with extra interfaces as well as a separate use model.
This is the JCP breaking down; instead of making life simpler, it made it
harder and didn't actually finalize the most crucial areas left in the
entity bean section of the specification, such as finalizing the managed
relationships.
The 1.4 API's logging model is another example of this: taken nearly
verbatim from Log4J, it's a floodgate-based model, where each category can
be set up individually, and as messages rise above a deployer-specified
"message level," they become visible in the output stream. This is nice,
certainly nicer than System.out.println() strewn throughout code, but the
introduction into the 1.4 API would have been the perfect time to present
something more powerful by default, such as a bitmasked logger, where you
would be able to say you wanted to see all "startup," "info," and "fatal"
events in a given category, and in another you wanted to see only "startup"
and "shutdown" events. Instead, Sun continued to take the easy way out,
repackaging Log4J according to various contributors in the expert group and
letting it go.
I would have liked to see Sun actually leverage the expertise of the
Java community it could spend time developing the language and application
interfaces while accepting the contributions of programmers who could
improve the core implementations. That would yield massive benefits: a
best-of-breed would appear in the language API and application developers
would feel empowered and more invested in Java. A best-of-breed would
probably have prevented things such as local interfaces (which actually do
have a beneficial performance impact, just not enough of one to justify
their cost), and allowed a more open discussion of other relevant APIs.
As Sun continues to allow the JCP to run wild, contributing APIs that
don't actually improve the usage patterns of the language, Java will grow
more and more irrelevant, until the weight of the poor APIs drags it into
oblivion. Sun needs to listen to its own best practices groups, and
eliminate the cruft introduced by users who very competently implement
things that run counter to the mindset that made Java the useful tool it is
today.
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
