[Isolate-interest] deafening silence about refactored APIs

[Pete Soper]

Jesper Zuschlag wrote:
> I have been looking into the strawman API for some time now and have be trying to interpret it by comparison to the original public review API and put it into the CLDC perspective. 
> 
> here is a quick overview of the notes that I have made until now:
> 
> * I like the refactoring of the quite large Message class into separate message classes for each message type
> 
> * I sympathize with the use of type-safe enum pattern for ExitReason and Type but in order to fit the API into CLDC/MIDP plain static final int's could be used instead. It is not that big as problem as these constants are not used 
> 
> * As messages are pure copy based I assume that some kind of serialization/deserialization mechanism must be available. Consequently, it will not be possible to implement MessageObject in the CLDC/MIDP platform as it lacks Java level serialization/deserialization.

There must definitely be an "as if by serialization/deserialization" 
aspect since we must keep the behavior consistent across platforms, but 
the lack of serialization/deserializion in the public Java APIs is not a 
problem for implementation of the JSR-121 APIs, it's an additional 
aspect of the "too big" problem, which is as much about the bulk and 
complexity of implementation on highly constrained platforms as about 
the apparent size of the exposed API classes.

> 
> * Are the details of ownership of object that are handed over from one isolate to another intentionally left unspecified. I mean what happens if e.g. a socket is handed over from one isolate to another that subsequently both isolates tries to use this socket. Although, the two socket are distinct on the Java level (as they are living in separate isolates) they could very well map down to the same underlying socket in the host system.
> 

Objects are in fact copied, so ownership isn't ambiguous (but we have to 
be careful to explain what it means to be mutating an object while also 
trying to send it). But the answer for a Socket is that the receiving 
Isolate will have an object that *does* relate to the same underlying 
i/o mechanism but with whatever per-instance state is defined for the 
object it has (very little for a socket). The EG wrestled with "move 
instead of copy" semantics and whether the sender's Socket should be 
closed by the send but we talked ourselves out of both of those for 
various reasons. It might be helpful to realize that a typical 
implementation will be using dup() or domain sockets to transport and 
copy a file descriptor from the source object to the destination.


> * Why does the method “byte[] getData(byte[] b)” from CompsiteMessage take a byte array as argument? Is it the resulting array which must be provided by the caller?

I can't remember or this is a typo. I'll look into this.

> * The security aspects in the context of CLDC/MIDP must be analyzed and described further
> 
When did CLDC/MIDP get security features?  :-) But seriously, security 
has been a big aspect of EG work on the APIs, however each time the 
subject comes up in the highly constrained Java context I'm told there 
isn't much to talk about. I won't be suprised to hear I'm out of date 
with this attitude. But again, a great deal of thought has gone into 
security implications (and opportunities!) involving isolates, both 
inside and outside the EG.

> * Most message types are obviously not relevant for CLDC/MIDP (FileMessage,  SocketMessage, ByteBufferMessage, ChannelMessage, ObjectMessage). J2ME include a replacement API in shape of the Generic Connection API although I’m currently uncertain if it would be possible to add some kind of Connector message type because of the extensible nature of the GCF API.

Yes, the current proposal is to only offer the javax.isolate package and 
nothing more for CLDC/MIDP.

> * I have tried categorized the types in accordance to whether they should be included (either mandatory or optional) in a CDLC/MIDP subset or not included in order to get an estimate on the size of such a subset:
> 
> Mandatory classes:
> 
> javax.isolate.Message
> javax.isolate.DataMessage
> javax.isolate.Isolate
> javax.isolate.IsolateParameters
> javax.isolate.Link
> javax.isolate.StatusMessage
> javax.isolate.StatusMessage.ExitReason <-- Could be replaced by static final int’s
> javax.isolate.StatusMessage.Type <-- Could be replaced by static final int’s
> javax.isolate.IsolateStartException
> javax.isolate.io.IOMessage
> javax.isolate.io.IOIsolateParameters
> javax.isolate.io.LinkClosedException
> 
> Classes that would be “nice to have”
> 
> javax.isolate.io.DataMessageInputStream
> javax.isolate.io.DataMessageOutputStream
> javax.isolate.util.MessageHandler
> javax.isolate.util.MessageDispacther
> javax.isolate.util.MessageVisitor (must be a subset too)
> 
> Classes without relevance for CLDC/MIDP subset
> 
> javax.isolate.io.FileMessage
> javax.isolate.io.SocketMessage
> javax.isolate.nio.ByteBufferMessage
> javax.isolate.nio.ChannelMessage
> javax.isolate.tbd.IsolatePermission
> javax.isolate.tbd.ObjectMessage
> 
> * I find it strange that some parties should find the API already to large for CLDC/MIDP. Which J2ME authorities were you talking about?
> 

Bernd Mathiske. Until recently Bernd was the tech lead of Sun's "Monty" 
JVM but I think he's gone back into research now. Again, to some degree 
the visible APIs are like the visible part of the iceberg and we just 
don't have a good feel for the total overhead yet but I trust Bernd's 
concerns to be serious.

> Just my initial thoughts!

And this is the first significant interest list input from the "tiny 
Java" camp and is much appreciated!

-Pete