From: "arthur alexander" <[EMAIL PROTECTED]>
> 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.
An obvious soltion for this problem would be an open-source JdbcOdbc bridge.
Or we could get the sources of Sun's driver, improve it and have the result
in the next JDK, but the SCSL has yet to be accepted by most of the OSS
community.
> 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.
There are free, open-source implementations of CORBA orbs. You only need a
commercial ORB if you really need its advantages like cute admin tools,
superior performance or robustness (and I say that as an ORB reseller).
Actually, the basic ORB product is rapidly being commoditized; vendors will
make money in services and application servers.
There is a significant synergy between teh Java and CORBA worlds. They are
a great match for many reasons, and OMG follows Java as much as Sun follows
CORBA today. The same is not true for Java/COM, and I can see no technical
reason to include COM support in Java (only the practical reason of
supporting a popular technology). Finally, a Java/CORBA program wll be WORA
while a Java/COM program will not -- although COM has been ported to
non-Windows platforms, these ports are outdated, incomplete (for server
side) and expensive, and basically nobody uses them, so COM is "de facto"
non-multiplatform. I support entirely Sun's position of not including as a
standard Java feature any support for a single-platform technology. Of
course this is sometimes posible, when the technology in question is masked
by a neutral API (e.g. Java3D supporting Direct3D)... we could have a JNDI
provider supporting Microsoft's new directory services and things like that.
If Microsoft produced a JavaCOM API that would run on any compliant JVM,
then I think Sun should make this available as an extension. But when
Microsoft produced COM libraries that work only on Win32, and particularly,
only on Microsoft's own JVM, Microsoft lost any moral rights to ask Sun to
support COM.
A+
Osvaldo
===========================================================================
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
