[Isolate-interest] CLDC compatiblity

[Jesper Zuschlag]

CLDC has been mention several times during this current public review  
and I'm also of the opinion that multitasking capabilities is a very  
important element in the future evolution of CLDC-based platforms  
which makes CLDC-compatibility an important issue for JSR-121. I have  
been talking with Pete Sober about this on several occasions and  
apparently work has been done to make JSR-121 more compatible with  
CLDC, however several stumbling-stones remains.

I have made a quick survey of the latest API proposal and come up  
with a list of the issues I have found. The question is if these  
issues should be handled by JSR-121 (possible as an amendment to the  
JSR) or be postponed to a future JSR (e.g. next CLDC version).

Some issues could be easily solved:

On the issue of StreamBindings I agree with Bryn Rahm that using only  
InputStream and OutputStream as source and destination for the  
standard stream would make the design much cleaner (and make it  
suitable for CLDC).

The use of Serializable on exceptions classes could be dropped in a  
CLDC context similar to other exceptions in CLDC and MIDP.

So the remaining challenge is the whole area of security and context/ 
properties, which heavily depends on the Java SE architecture and  
thus cannot easily be applied to CLDC.

In my opinion, JSR-121 should include a base line semantic for  
adapting JSR-121 into a CLDC environment that is compatible with the  
current CLDC version, with the possibility for later versions of CLDC  
to expand the semantic. E.g. the specification should state than in a  
CLDC environment only classes from the same repository (jar file) as  
the parent Isolate can be used as starting-point/main-class of a new  
Isolate, and that Isolates always inherits permissions and properties  
from the parent Isolate (although a mechanism allowing the parent  
Isolate to add additional properties could perhaps be provided). Then  
later version of e.g. CLDC could perhaps extend this semantic with  
some kind of light-weight user-defined security mechanism.

By the way, is it the intent of the EG to write a "formal  
specification" or is the JavaDoc  the chosen format?

/Jesper



Classe survey:

--------------------

ClosedLinkException:

-       Implements java.io.Serializable

Isolate

-       Applies java.util.Properties

-       Uses variable arguments in several methods (Isolate(..), start 
(…)

IsolateException

-       Implements java.io.Serializable

IsolatePermission

-       Inheriting from java.security.BasicPermission

-       Incompatible security model. No extensible security model in  
CLDC (sandbox confinement to originating jar-file, no class path)

-       Implements java.io.Serializable

-       Implements java.security.Guard

IsolateStartupException

-       Implements java.io.Serializable

IsolateStatus.ExitReason

-       Implements java.io.Serializable

IsolateStatus.State

-       Implements java.io.Serializable

LinkMessage

-       Applies java.net.ServerSocket

-       Applies java.net.Socket

StreamBindings

-       Applies java.io.FileOutputStream

-       Applies java.io.FileInputStream

-       Applies java.net.Socket





  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20050718/a37e220a/attachment.htm