[1959] in java-interest
Re: comments on comments
daemon@ATHENA.MIT.EDU (Chuck McManis)
Wed Sep 20 15:33:59 1995
Date: Wed, 20 Sep 1995 09:18:26 -0700
From: cmcmanis@scndprsn.Eng.Sun.COM (Chuck McManis)
To: java-interest@java.Eng.Sun.COM, fgreco@lehman.com
Frank Greco writes:
> (thanks to the person that sent me a product ptr on this
> issue!) in Java, you have to build a socket connection and some
> back-n-forth "protocol". As simple as it may appear to us, this
> needs to be addressed from a higher level.
Realize that Java and HotJava are quite "young" and that only with the
preBeta release has their been the feeling of stability to the interfaces
that have been viewed over the past five months. The real answer to your
query is that for NOW you would have to write class that talked to a
socket etc, however this is a very common request. I expect that in at
most a couple of months after the beta release and certainly before the
final release there will be Java classes available that your basic MIS
person can use without having to learn network programming.
> I am getting the impression that MI *cannot* be done
> (equivalently) in Java.
That is correct you cannot do MI in Java. However, Java provides a
mechanism (Interfaces) that allows you to solve many of the same problems
that you might solve with MI, however the solution may appear to be
quite different, the behaviours should be identical.
> It appears that one cannot inherit a method from a class if
> that method was *not* previously declared as part of an
> interface. Is this true?
The set of methods in any class are :
The set defined in the class proper.
All of the methods in all of the class' super classes.
All of the methods in the interface(s) the class implements.
All of the methods in the interface(s) that the superclass implements
All of the methods in the superclasses of the interfaces.
That is a lot of different ways to get methods into a class :-)
> This is important. Hint: Microsoft doesn't have a way of versioning
> .dll's and its biting them in the corporate IS/IT/MIS (gawd, its tough
> to be politically correct) world.
We recognize that it is important. In the current browser model there are
two "sets" of classes, those associated with the HTML document, and those
in the system class path. The system classes are updated in a lump, the
HTML page classes are updated in a lump, it is easy to keep them both in
sync. As the world evolves to wanting to replace single classes in the
system set and to provide a new set of cached classes as an adjunct to
the classes in an HTML page, versioning becomes more critical.
> It [decompiling classes] has be harder then breaking
> Netscape's security code or else the corporate world
> won't adopt it.
Run javap -c on your compiled class. Is that easy or hard? Was the
information sufficient or lacking? "Hardness" in this context is
relative to the user.
--Chuck
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
