Greg,
This started out as a simple explanation, and
blossomed into a diatribe. Hope it is usefull.
It starts to seem like a political issue more than
a technical one.
When SUN worked with Intersolv (now a division
of Merant) to develop the JDBC-ODBC Bridge
driver, it was in SUN's (and all JAVA developers)
best interest to get a JDBC driver in user's hands
that worked, as it was going to be a long while
before the DB Vendors all had working versions,
of any JDBC Type, available for testing, more or
less for any productive work.
http://java.sun.com/products/jdbc/drivers.html
Now that JAVA and JDBC are quite usefull and
popular, and a number of DB Vendors and third-
party Driver Vendors have good drivers for a
large number of the most popular RDBMS's, it
seems that neither SUN nor Merant have stepped
up to re-program the JDBC-ODBC bridge, and
why should they is the argument you will get.
SUN want's to divest Microsoft of any ownership
or even participation in the JAVA bandwagon, and
to crush it's competitor M$ (as it is often abbreviated
by anit-MS bigots). Why would they want to promote
the use of free ODBC drivers when they and their
partners can get more $UN dollars out of you by
promoting the alternative drivers.
In the interest of fairness, it should be noted that
the other driver Types (models?), ie. Type 2, 3, and 4,
offer a much better model for use in JAVA than the
bridge (especially types 3 and 4). But to specifically
hamstring a good choice for some people, namely the
bridge, in order to further political and market strategy
goes against everything the open source initiative should
stand for in my estimation. I feel it is time that someone
stood up and called SUN and it's architects on this two-
faced stance.
Now that I have got my two cents out regarding that
'soap-box' diatribe, I should say that I wish to support
the open source initiatives around JAVA, including the
standardization of the language. I think SUNs Javasoft
division, or whatever division it falls under today or tomorrow
has done, and hopefully will continue to do, a great job in
design (with some caveats of course, most of which they
graciously acknowledge and have either addressed or
plan to address in future releases), implementation and
delivery of the JAVA APIs and related support technologies.
I have similar gripes about Microsoft. Whenever marketing
driven inititives (also management's technology reliegion)
interfere with good design and product efforts, there is bound
to be conflict and resentment. This is no more or less a
Microsoft or SUN issue, but we must be fair and call them
both on their bad practices.
I am also not ignorant of the cash (greed) incentives at work
here ( I also need to eat and provide a roof ), but sometimes
it goes overboard and becomes a vendeta, an 'us vs. them'
at whatever cost philosophy that is harmfull to the customer
in the long run.
As an example, why is it that SUN has done so much work
providing good CORBA integration into the JAVA environment,
and not a single API initiative to support bridging the COM
based interfaces to JAVA? Many will counter with " CORBA
is an open source API, and COM is not ". That is a truly false
argument, and a red-herring. While it is technically correct on
the face, it does not address the real motives at work behind
the sceens.
The COM interface APIs are widely documented, and even
the network protocol for Distributed COM is in the public domain.
SUN could easily provide an API to support a bridge to COM,
but that would only foster the use of COM, and that is not what
SUN makes money on. In fact, the worse MS does in the market
the more opportunity there is for SUN to advance it's more costly
solutions to the same problem. Have you ever priced the market
average for a complete CORBA infrastructure? Thousands of
dollars and more complex Servers and technology to support,
with the requisite increase in support personell and skills.
Now why would anyone opt for that when COM is free, and is
already used by more than 70% of those companies that have
begun to use JAVA? It is nearly impossible to make a case for
it on the basis of ROI, unless you take into account the volume
use of the technology, the so called Scalability factor.
The case is made that when you need to scale the use of various
COM objects, vs. the CORBA based equivalents (forget EJB for
a moment), that COM just does not have what it takes. What do
I need, pray tell Mr. SUN? Why, many StarFire clusters, at many
millions of dollars in investment overall. Can I not put together an
equivalent strategy using clone hardware, and off-the-shelf OS and
object solutions? You can, but we will not support you, as that is
not our philosophy of scalability. What about my current infrastructure,
can I not find a migration path to bridge current COM efforts and
slowly move onto newer EJB based applications as my developers
have the time to build this infrastructure? No, that is your problem,
go and pay a third party to deal with that issue, as we cannot be
bothered to even touch the fringe of the garment of our enemy, M$.
So the real world scenario plays out, and so we go without a
migration path or way to bridge our COM world with JAVA.
Well, some say, you can use the MS JVM. Of course you have to
give up anything new since 1998, as SUN is not allowing MS to
enhance the JVM, and is suing MS to remove any enhancments
they have provided to date. Oh, you could use a third party solution
like IONA or Visigenic or Gemstone or Sapphire, right? Maybe, but
is that really a good answer to the simple problem of an integration
API? Do I really need to buy a full CORBA infrastructure and build
expertise in that product just to access my COM infrastructure?
What if my company merges with another, and we are using
incompatible vendor products for bridging COM? Another Y2K glut
of spending to synchronize systems just because SUN will not allow
a simple API to bridge COM to be part of the overall JAVA plan.
I think I have made the argument, at lease raised many of the issues,
related to it, that there is more politics and market incentive in many
of the problems we developers face that simply technology issues.
And that is what I believe is at work here in the JDBC-ODBC bridge
not having proper multi-threading support, or at lease why no one
at SUN is properly addressing the issue. They wish to leave that
product in the dust, now that it has served it's intended purpose
of moving a large body of developers into the SUN camp.
The opinion expressed above is the personal view of:
Arthur Alexander
Rocky Hill, CT
-----Original Message-----
From: Greg Ames <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Sunday, January 09, 2000 1:17 PM
Subject: JRUN-MS Access connection question
>We are using JRUN 2.3.3 and are trying to connect to a Microsoft Access
>Database. We are using Java 1.2 and Windows NT 4.0. We have tried:
>
> Class.forName ("sun.jdbc.odbc.JdbcOdbcDriver");
> Connection con =
DriverManager.getConnection( "jdbc:odbc:WadeTest" );
>
>If we just retrieve data, everything seems fine. If we update, or insert,
>Dr. Watson is called about every 3d time, and JRUN dies. We had similar
>problems with Oracle until we used their JDBC driver. A discussion on
>Alliare's site indicated that the JDBC:ODBC driver was not thread safe and
>that would be problematic with Servlets.
>
>http://www.allaire.com/Handlers/index.cfm?ID=12409&Method=Full
>
>http://java.sun.com/products/jdbc/faq.html#20
>
>
>Is there an alternative driver that works with MS Access. We could switch
>to the MS Java, and the problem would go away, but we also kiss off
>portability. (Not a good choice as we are using 1.2 features.) I once
>thought there was nothing I should be able to do to crash Java, but I was
>wrong. Am I really the only person having this problem? Any help or
>guidance would be appreciated.
>
>Greg
>
>===========================================================================
>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
>FAQs on JSP can be found at:
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
