[444] in java-interest
Re: Java Objects over the Network
daemon@ATHENA.MIT.EDU (David Hopwood)
Thu Jun 22 13:58:51 1995
From: David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
To: jpayne@starwave.com (Jonathan Payne)
Date: Thu, 22 Jun 1995 18:18:11 +0000 (BST)
Cc: java-interest@java.sun.com
In-Reply-To: <9506212122.AA28430@flim.starwave.com> from "Jonathan Payne" at Jun 21, 95 02:22:26 pm
Jonathon Payne wrote:
>
> > From: Gregory Zoller - Imonics Development <gzoller@imonics.com>
> >
> > Someone earlier posted their idea that Java should be able to port
> > objects over the network.
> >
> > I second that motion as a feature request.
> >
> > I think it would be very handy to be able to take an object, wrap
> > in some Network wrapper object, and send it to a waiting Java client.
> >
> > Since Java is interpreted, would it be terribly difficult to send
> > an object's bytecodes (and data) over the net?
>
> It's not hard to do this, but it's hard to do it in the middle of an
> instruction (or even all the way through an instruction). The
> execution context, including open file descriptors, net connections,
> any other threads it depends on, etc. - well, try moving all that to
> another machine.
Even something rather more restricted than this would be very useful.
I would be satisfied with something that would take a network of Java
objects, and turn it into a MIME entity (application/java-pickled, or
whatever). Applying the appropriate content handler would reconsistute
it.
Each class would have a method to specify what other objects should be
stored with it. The default, in Object, would be to store the transitive
closure of all the objects pointed to (possibly skipping instance
variables that are marked in some way - is this what 'transient' is
for?)
You also have to specify the class of each object. It's probably sufficient
to store the class name, and (if it was loaded from the network) its URL
and context. Possibly also a hash and timestamp of the class file. In most
cases, the receiver will be using the same classes as the sender (or will
be the sender, if this is just used for persistence). If not, the new
class(es) can be downloaded from the net.
There is a potential security hole, in that applets could get access
to the instance variables of objects belonging to the system (eg. the
browser, or a server thread).
To fix this I suggest marking each non-primitive object with an owner
(similar to a process id). In particular, each thread has an owner. A
'new'ed object inherits the owner of its creating thread. It is possible
to create a thread with a new, otherwise unused owner (which is how the
browser launches an applet).
Then, you can throw an exception whenever a thread tries to pickle an
object that does not belong to it. When you unpickle an object, it
becomes owned by the thread that unpickled it, just like any other new
object.
As far as I can see, this should stop applets from doing anything nasty
that they couldn't otherwise do (although you have to be very careful
that the unpickling routine detects incorrectly formatted data).
Of course, if this is used to send agents to a remote machine, you have to
trust that that machine executes them correctly. But I don't think there
is any way around this.
David Hopwood
david.hopwood@lmh.ox.ac.uk
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
