[Isolate-interest] JSR-121 aggregates and links (strawman 10)
Pete Soper
Pete@Soper.US
Tue, 28 Sep 2004 21:34:31 -0400
Godmar Back wrote:
> [ did you mean to send the answer to me personally as opposed to the list? ]
I've lost track of which msgs you sent directly and which included the
list. I hope you don't mind that I just include the list for the sake of
getting to the bottom of things.
>
> thanks for your answers.
>
> It seems the FAQ should omit aggregates if the spec doesn't mention them.
What we've been saying is that aggregate is just an abstraction with
this first version of the isolate specification. It's just a better way
of expressing a collection of isolates sharing a common ancestor, rather
than "multi-isolate JVM" or "expanded notion of JRE", etc, as detailed
in one of the JAOO slides.
>
> My question was what does it mean to copy an object such as a file
> descriptor or socket over a Link. Could you point me at where this is
> described?
As I said, strict copy semantics are used, period and all copies are the
same (+/- mutations done up to the send happening, as described in the
public review draft).
For instance, what does copying a ServerSocket to multiple
> receivers mean? Does it mean you get automatic load balancing ;-)?
The expectation is that having passed a socket off the sender will save
its copy or nil it out.
> Does sending a file descriptor close it?
No.
> If not, will a close on the
> sender side cut the receiver's use off?
No.
All these things that
> traditional capability channel go into great length to describe and
> define and that I didn't see in the JSR spec I looked at.
Sorry. Is there a particular example that we could look at as a good model?
>
> Finally, could you explain the jsr121x thing and strawman API that's a
> "moving target": I thought JSR-121 was voted on and is final and only
> waiting to be included in a future JDK?
The formal JCP (Java Community Process) info for JSR-121 (the link
called [1] on the interest page) will have "proposed final" and then
"final" when its done and a formal TCK (validation suite) and RI must be
made available too. I apologize for assuming familiarity with the JCP.
>
> Is the API shape and
> semantics still open to discussion?
Yes.
> Related to that are obviously are permissions. What did you decide to
> do about those? Can Links be used to circumvent permissions?
Yes. But put in a positive way, Links define an additional security
mechanism.
> Can I
> receive an open File*Stream that I wouldn't normally have permission
> to create via a link if I have the necessary LinkPermissions?
Yes, but put a different way Link enables permission to operate on
exactly the file(s) exposed to the isolate instead of more general file
creation permission.
Each isolate operates within its own traditional Java security domain.
That is, security management & policy can be specified for every isolate
independent of others, although a common administrative domain defines
default policy. There is also a child of Permission available if you go
beyond the base package.
> Regarding your other comment, I don't think adding equals() and
> hashCode() to an interface has any effect whatsoever, either
> semantically or syntactically. Do you want to say that Sendable's
> must override or do override equals/hashCode?
Oops! What was I thinking? I've put this back the way it should be.
-Pete
--------------
// Strawman 10
package jsr121x.isolate;
interface Sendable { }
public final class Isolate implements Sendable {
public Isolate(String mainClass, String[] mainArgs) {}
public Isolate(IsolateParameters params) {}
public static Isolate currentIsolate() {}
public static Link[] currentIsolateStartLinks() {}
public static IsolateParameters currentIsolateParameters() {}
public Link newStatusLink() {}
public void start(Link[] links) throws IsolateStartException {}
public void exit(int status) {}
public void halt(int status) {}
public StatusMessage.Type getStatus() {}
public boolean equals(Object o) {}
public int hashCode() {}
}
public class CompositeMessage implements Sendable {
CompositeMessage() {}
public Message[] getComposite(Message[] msgs) {}
public static CompositeMessage newCompositeMessage(Message[] msgs) {}
}
public class DataMessage implements Sendable {
DataMessage() {}
public long size() {}
public byte[] getData() {}
public static DataMessage newDataMessage(byte[] b) {}
}
public class StatusMessage implements Sendable {
StatusMessage() {}
public final class ExitReason {
private ExitReason() {}
public final ExitReason IMPLICIT_EXIT = new ExitReason();
public final ExitReason OTHER_EXIT = new ExitReason();
public final ExitReason OTHER_HALT = new ExitReason();
public final ExitReason SELF_EXIT = new ExitReason();
public final ExitReason SELF_HALT = new ExitReason();
public final ExitReason UNCAUGHT_EXCEPTION = new ExitReason();
}
public final class Type {
private Type() {}
public final Type STARTING = new Type();
public final Type EXITING = new Type();
public final Type TERMINATED = new Type();
}
public ExitReason getExitReason() {}
public Type getType() {}
public int getExitStatus() {}
public Isolate getIsolate() {}
public boolean equals(Object o) {}
public int hashCode() {}
}
public abstract class Link implements Sendable {
Link() {}
public static Link newLink(Isolate sender, Isolate receiver) {}
public abstract Message receive();
public abstract void send(Message msg);
public abstract void close();
public abstract boolean isOpen();
public abstract boolean isSender(Isolate i);
public abstract boolean isReceiver(Isolate i);
public boolean equals(Object o) {}
public int hashCode() {}
}
public class IsolateParameters implements Sendable {
public IsolateParameters(String classname, String[] mainArgs) {}
public void setContext(String name, String value) {}
public String getContext(String name) {}
}
public class IsolateStartException extends Exception {
public IsolateStartException() {}
public IsolateStartException(String detail) {}
}