[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