[4690] in java-interest
Re: Java and CORBA/OLE
daemon@ATHENA.MIT.EDU (Jonathan Locke)
Wed Jan 10 22:37:00 1996
Date: Wed, 10 Jan 1996 16:39:06 -0800 (PST)
From: Jonathan Locke <jonl@sealevelsoftware.com>
To: Mike Paluka <mikep@exmachina.com>
Cc: java-interest@java.sun.com
In-Reply-To: <199601101341.IAA14403@exmachina.com>
On Wed, 10 Jan 1996, Mike Paluka wrote:
> At 07:38 PM 1/9/96 -0800, you wrote:
> >
> >all right... i'm probably opening a can of worms here, but i'm not sure the
> >question at hand is whether java needs CORBA support or COM support (it will
> >probably end up with both)... i think the issue is whether java *needs* an
> >object model at all because java already *has* (is?) an object model and
> >i am not convinced that java couldn't be easily extended to provide
> >excellent support for distributed objects on its own. because of all the
> >nasty dependencies COM has on C++ ugliness, i imagine it would be much
> >easier to make distributed objects directly in java than it would be to do
> >the same thing to COM... *MUCH* easier. most particularly, i see no reason
> >why distributed objects shouldn't receive language-level support. feel
> >free to get up on your own soapbox. ;-)
> >
>
> Sorry to be so wordy, but I haven't heard these particular issues raised:
>
> I understand your point, and agree with it, as far as it goes. I believe
> that there are a few additional issues to consider:
>
> 1) CORBA, et al, vis-a-vis Java, provide an alternative to the DEADLY path
> down the road of "native" methods. I agree that native methods are
> necessary for ad-hoc applications that either don't require full portability,
> or that require OS services that have not yet been implemented by a Java
> peer. They also provide the ability to work-around bugs in Java. However,
> I have been fearing from the beginning, that 'natives' will be abused, just
> like in the early days of the IBM-PC when everybody started writing to the
> hardware directly. Further, experience shows that Microsoft is the most
> likely candidate to bastardize Java in this manner (although OLE, sans
> CORBA, would still be better than native methods alone).
while i certainly share your fear, i have lots of optimism about it.
i think native methods will largely go away once java becomes truly fast.
also, native methods aren't a problem except for applets. obviously you
can't makeyour object distributed if you have native methods. so people
will just not do it.
> 2) While Java guarantees that, sans native methods, a Java app will run on any
> supported platform, it doesn't guarantee (to my knowledge) that "object-data"
> will be transportable. For example, if I create an instance of a MyObject,
> can I then ftp (or whatever) the INSTANCE (not just the definition) to
> another machine that may use different encoding (byte order, ASCII vs
> EBCDIC,etc.) ? I don't think so.
on the contrary!
my understanding is that the classes (code) AND the data are transportable.
i believe the java VM defines all primitive data types (little endian
machines have to byte swap all the time because java is defined to be
big endian)i believe with some communications and serialization support
that you could do exactly what you said... transport an INSTANCE of a java
object transparently with basically no effort to any java machine anywhere.
that's why i'm thinking built-in support of serialization is so terribly
important. just serialize your java object to a socket connection! *poof*
it's transmitted and running on another machine.
observations about COM:
java has huge advantages over COM. COM made some big mistakes (all a result
of C++ for the most part):
1) manual reference counting
2) reference counting
3) dependence on vtable layout and other C++ish things
4) static binding of COM objects (no class loader)
5) dependence on native machine types -- i think fixing this is going to
be a big hit for COM in terms of code complexity, size and speed.
6) the C++ language has no knowledge of COM. you have to do
"QueryInterface" instead of just casting an object to the right
interface type.
7) probably lots of other things
i think if sun does java object serialization well and adds good, easy to
use distributed features to java (or java class libraries where
appropriate), a lot of people are simply going to lose interest in COM
(and other object models). if it's done right, there should be no
comparison.
>
> You may ask, why would you want to transmit an INSTANCE? The most
> salient reason is for persistance at remote sites; but also for
> OODBMS's, cookies, public security keys, etc.
agreed. totally important. a major part of the future of computing,
perhaps.
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
