[Isolate-interest] CLDC compatiblity

[Grzegorz Czajkowski]

Sutanu,

thanks for your message, it neatly summarizes how I
and the rest of the JSR 121 Expert Group feel about
this issue. As it happens, 121 is a J2SE JSR.
However, we made an extra effort to accommodate
CDC - except for vararg methods all of the API
is verbatim applicable to CDC, and we added a note
to the specification about the treatment of varargs.
As to CLDC, proper subsetting is in order here,
as it is not clear whether the whole API would
be needed by these platforms.

-- Greg


Sutanu Ghosh wrote:
> I think the goal to create a single unified api to
> serve both JavaSE and JavaME/CLDC environments is not
> a good idea. In trying to do so, it might limit the
> full capability or future expansion of isolate spec in
> JavaSE environment. Also, as already happened, the
> java 5 language features were taken out from the api
> in order to comply with JavaME.
> 
> I propose to make the JSR-121 api/spec targeted to
> JavaSE platform only. A separate JSR can create the
> JavaME/CLDC version of the isolate api. This has been
> done for several other JavaSE packages in the past. 
> 
> Thanks,
> -Sutanu
> 
> 
> --- Jesper Zuschlag <jesper at zuschlag.dk> wrote:
> 
> 
>>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
>>
>>
>>
>>
>>
>>  > _______________________________________________
>>Isolate-interest mailing list
>>Isolate-interest at altair.cs.oswego.edu
>>
> 
> http://altair.cs.oswego.edu/mailman/listinfo/isolate-interest
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> Isolate-interest mailing list
> Isolate-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/isolate-interest