Re: Java to die in 2003

From: Galen Boyer <galenboyer_at_hotpop.com>
Date: 28 Dec 2002 21:17:07 -0600
Message-ID: <u7kdt9w8m.fsf@hotpop.com>

On 28 Dec 2002, stuartc_at_mac.com wrote:
> Nuno Souto <nsouto_at_optushome.com.au.nospam> wrote in message
> news:<3e0d4769$0$7817$afc38c87_at_news.optusnet.com.au>...
>

>> Precisely.  And let me stress: this "duality" comes from the J2EE
>> crowd every single time, IME.  Not once are they willing to accept
>> that there is a little bit more about databases than just what JDBC
>> has.

>
> Sadly, yes. (I'm a J2EE guy trying to fight this bullshit).
>
>

>> If it's not in the example cookbook provided by WSAD and IBM in a 
>> deranged red book somewhere, they don't even want to hear about it...

>
> That in itself is the root of the problem: the J2EE "crowd" is
> largely a bunch of recent college grads that jumped onto a bandwagon
> by reading the specifications/redbooks, and not having a whole heck of
> a lot of engineering expertise.
>
> There are exceptions, and I have seen passable J2EE applications. But
> they usually were led by a very experienced guiding hand.
>

>> >  Stored procedures
>> > aren't evil.  
>> 
>> Tell that to J2EE "God" Scott Ambler & Co.  And the Jakarta mob...

>
> I think the Jakarta mob is a bit too diverse to really label... Scott
> Ambler has his reasons for disliking stored procs, though I have no
> problems using them if they're warranted.

The issue with stored procedures from the J2EE point of view is that your application isn't portable. To port the application, the procedures have to be rewritten for the next database platform. So, the whole J2EE mantra becomes one of minimizing the chores of the developer of the application. The mantra isn't one of bringing the best application to the customer, it is one of building an app that can be ported easily. But, then, the ported application will invariably perform poorly and some of the sql will need to be rewritten for the next DB platform. So, complete portable is truly a pipe-dream.

My issue with not using stored procedures is the other side of this coin. JDBC doesn't provide you with platform independence or guarantee that you will execute high-performing SQL. It only provides a single API for dealing with interacting with databases. If you want a successful application, it needs to perform well. Letting application developers stick dynamic sql in java code will invariably end up with an application that doesn't perform well. Its not that J2EE developers aren't smart enough to be good db developers, its that most J2EE developers aren't good db developers. So, a way to guarantee that SQL code isn't in java code is to have everything go through a proc. Then, the database actually looks much more java like anyways. There is nothing java/object like about dynamic SQL. It is much more java/object like to ask something to execute a method.

[...]

>> Narh!  That would be too easy.  
>> Eschew simplicity is the middle name of J2EE...
>> :(

>
> Just one thought here, J2EE is not EJB. EJB is a demon-spawned (i.e.
> CORBA) technology that tries to do too much, all poorly. J2EE otoh,
> has some relatively simple approaches to reliable messaging,
> large-scale web dev, assuming people don't unnecessarily complicate
> things.
>
> Sun's blueprints of course don't help matters, but they really can't
> -- it's rather difficult to distill engineering expertise into a
> whitepaper or set of patterns. Patterns can help, but they're
> dangerous in the hands of newbies (oh oh, look! we can apply the
> abstract factory and visitor pattern here! that way we can iterate
> through 10,000 objects instead of having to write a SQL statement!)

Arghh!!! The next time someone creates a bean for every single row on a report screen I think I will scream.

-- 
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.

Received on Sat Dec 28 2002 - 21:17:07 CST