[Isolate-interest] JSR-121 aggregates and links (strawman 10)
Godmar Back
gback@cs.vt.edu
Wed, 29 Sep 2004 15:34:34 -0400
On Wed, 29 Sep 2004 20:09:16 +0100, Miles Sabin <miles@milessabin.com> wrote:
>
> > What about subtypes? If the object being sent it a, say
> > SSLServerSocket, will the object received by a SSLServerSocket also?
> > Is the JSR-121 obliging all subclassers of Sendables to implement
> > JSR-121 send semantics?
>
> There's a fixed list of concrete types which are (little 's') sendable,
> so in many ways the (big 'S') Sendable interface is lying to you. At
> various times the method signatures that are now defined in terms of
> Sendable were instead defined in terms of Serializable, or Object.
>
> In all cases there's a possibility of a runtime error. What we're trying
> to capture is a non-extensible gerrymandered union of more or less
> unrelated types ... and there's no way of capturing that cleanly within
> Java's type system. We also wanted to avoid having to mandate _any_
> visible changes to types outside of the java.isolate packages, which
> meant that retrofitting an interface to all the (little 's') sendables
> wasn't an option even if it would have worked.
>
What specifically would that mean, for say SSLServerSocket?
Is an implementation obliged to throw a runtime exception (which one?)
if someone attempts to create an isolate message for an object
(SSLServerSocket, for instance) it can't safely transport?
Is it possible and permissible, in a clustered implementation, that
the creation of an isolate message with an SSLServerSocket succeeds
but the extraction of the socket on the receiver side fails?
- Godmar