[Isolate-interest] CLDC compatiblity

Bill Foote Bill.Foote at Sun.COM
Wed Jul 20 01:37:52 EDT 2005


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


IMHO it's a question of a cost/benefit analysis.  If we
can achieve less fragmentation across Java platforms at
the cost of a few superficial changes, then I think
it's pretty clear that the lower fragmentation is more
valuable.  That's, I think, what drove backing away from
the new language features.

In the case of CLDC, I think one should similarly
consider the costs and the benefits, and come to a
considered opinion.  It's not a binary thing.

Bill

> 
> --- 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





More information about the Isolate-interest mailing list