Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Java to die in 2003

Re: Java to die in 2003

From: Stu Charlton <stuartc_at_mac.com>
Date: 29 Dec 2002 00:04:09 -0800
Message-ID: <21398ab6.0212290004.4e5892e@posting.google.com>


Galen Boyer <galenboyer_at_hotpop.com> wrote in message news:<u7kdt9w8m.fsf_at_hotpop.com>...

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

This culture (which I do sadly see as well) is due to the Sun marketing spew with regards to "100% Pure Java". Java/J2EE does reduce the business risk of vendor lock-in, but it CANNOT eliminate it because it's JUST A SPEC.

This goes beyond using Oracle correctly and comes to a fundamental disconnect between the "idealistic" J2EE view that some in Sun's marketing department hold, and the reality of software development. If something mandatory (i.e. processing a million DB rows) lies out of the spec, do you A) not do the job, B) do the job poorly, or C) do the job in a proprietary manner?

This has been a long-controversial issue with J2EE and the press has done wonders in exacerbating it. If anyone comes out with an "innovative" (i.e. needed in reality) feature, they are cast as heathens! eWeek will have an article "Has J2EE lost its grip?", mailing lists flutter, egos soar.

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

It never should have been billed as "complete"; J2EE really's about "lowering but not eliminating your switching costs" with regards to vendors and framework skills. It's nice, but it's certainly low on the list of priorities in a project (or it should be!).

Many IT managers don't understand engineering, but they do understand economics, and hearing buzzwords like "complete portability", "zero switching costs" gets their juices flowing. This needs to be tempered with "but we can't actually do the job with complete portability". The operation was a success but the patient died....

> 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

ODBC had this problem too :)

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

The solution chosen depends a lot on your team & their skills, and the culture of your IT staff.

For example, many DBA organizations in my experience will not write stored procs for developers (no time or motivation), yet the developers aren't very good at dealing with the database. So why bother (unless there's a technical reason like lots of data to process)? It's really a matter of having tech lead(s) that know detailed database issues and can coach the programmers on this.

In a small team, I've managed to get people to use PreparedStatement bind variables, SQL*PLUS autotrace, and write their JDBC in a repeatable, maintainable manner, so we can tune them as we study our TKPROF outputs.

With a larger or dispersed team, this is harder to do. In those situations it makes sense to wrap procs with static methods in Java.

Another solution I've tried with mixed results is to use TOPLink, where I could control the configuration (ensuring bind variables, etc), the developers got their nice-nice OO interface, and I can hunt down features that should be procs.
I would work with the DBAs to ensure generated queries were sane, perhaps add needed SQL hints... it can work but TOPlink is quite pricy & complex and really needs a good justification beyond "we don't know SQL!".

Cheers
Stu Received on Sun Dec 29 2002 - 02:04:09 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US