Jon Stevens wrote:
>
> on 6/20/01 2:33 PM, "Berin Loritsch" <[EMAIL PROTECTED]> 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:
>
> Turbine has this problem in a great degree. For example, we wrote a JDBC
> Connection pool about 3 years ago. Now, JDBC has an interface and whole
> system for creating a Connection pool. Personally, I think that it's
> implementation is bad OO design because they overloaded the use conn.close()
> to release the connection back to the pool in order to maintain backwards
> compatibility easily without having to modify existing code. Sure, it makes
> a good business case for existing code, but 10 years down the line, people
> will wonder why close() also returns a connection to the pool. Long term
> considerations were simply not made. :-(
It has an interface--but I have yet to find any documentation that allows
me to get a handle on the DataSource object in the client drivers. It wants
you to go through a J2EE server--but what if you are writing the server?
Avalon has pooling code as well, modeled after the JDBC methodology. I don't
think that JDBC 3 will obviate the need for custom pooling techniques.
> This problem is only becoming more and more apparent and important as more
> and more people's excellent OSS code becomes obsolete or "questioned"
> (because it is not "standard") literally overnight. It is nice to see that
> others are now starting to get bitten by this as well. :-)
It's not nice. I work mostly with Avalon, and we have been pretty protected
up to now. Although with JSR-111 on the horizon, it will hit Avalon square
on the shoulders. I am involved with that effort so it is in my best interest
to champion the way Avalon does things.
However, when the "standard" sucks like JSR-42 logging, why use it?
> For example, I also have to deal with people like Craig constantly bringing
> up the fact that Struts is more "J2EE Compatible" (and therefore better in
> his eyes) than Turbine even though Turbine has had the same exact features
> for years now and they have been well used, well liked, and well tested.
> Probably more so than existing J2EE code.
My biggest complaint with it is that there is nothing that tells me exactly
what it is trying to accomplish. That and the fact that it has been a moving
target with the API. Cocoon had to alter their hooks into Struts JDBC pooling
a few times. But that's water under the bridge.
> Next year, you might hear him and others saying that Log4J or ORO or Regexp
> (which is included in Catalina) or Avalon isn't J2EE Compatible because they
> don't follow the specifications that Sun releases.
Hopefully you're off the mark there. The danger is in J2EE next-gen standards.
There are some serious holes in J2EE that I don't like--and want to change.
> One could bring up the OSS argument and say that the code in the JDK isn't
> OSS and therefore isn't worth using the API's, but that gets nullified as
> soon as Sun decides to OSS the code or someone realizes that IT managers
> don't listen very well.
The fact that the code is in the JDK means that the API is not going to change
drastically. This is a major plus for IT managers and programmers. The fact
that it is a standard also means that questions about it's longevity are removed
from the pointy-haired boss. In my company, we have deviated from the standard
and used another product when that other product suited our needs better.
> Also, where do you draw the line? I know that JDBC has been around forever
> and everyone agrees to use it, but what if we had some special way of
> abstracting out talking to the database and suddenly JDBC came along and
> usurped whatever we had used before? Same problem...
It's somewhat different. JDBC is a standard that all DB vendors can rally around
and ship drivers for. A consortium of them have been trying to push an alternative
called JSQL or something like that--but people stick with JDBC.
> One can also spend many hours working for Sun for free, to try to convince
> the super powers that their code is better than Sun's code or that Sun and
> the JCP are doing something wrong in the API, but you end up having to
> battle with the needs of not only yours but whatever commercial pressures
> that Sun is under (look at their stock price as an example). You also get to
> battle with the spec leads individual preferences. This is what Ceki is
> doing with his Log4J. I'm sure that Daniel Savarese would be doing the same
> for his ORO package if he had the time and energy to spend on it.
This is true. But put yourself in Ceki's position. He feels a responsibility
because of the number of users of his project--and he feels slighted because
of the lesser known and in many people's opinion lesser logging kit was the main
prototype.
> I guess the whole thing comes down to a matter of choice. Do we believe in
> what we are doing here in Jakarta land? I certainly do. I don't always agree
> with the choices that are made or the code that is produced, but I certainly
> like our Apache open decision making processes a hell of a lot better than I
> like the Sun/JCP's political mess.
I agree. I like the projects at the Apache Software Foundation as a whole.
I do think that we need to compare conflicting projects to the standard and
explain why things are different--or why our project is better. That is something
that will give ammunition to developers to go to their managers and say "we need
project Jakarta-X because....."
S/MIME Cryptographic Signature
