You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Sim IJskes - QCG <si...@qcg.nl> on 2010/09/01 14:52:26 UTC

CDC issues

On 09/01/2010 09:36 AM, Peter Firmstone wrote:
> The original intent behind the changes to RemoteEvent, were to change
>  it's internal handback object to a MarshalledInstance from
> MarshalledObject, so the Java CDC Personal Basis Profile could
> participate in a djinn, with some very basic simple services and as a
>  client.
>
> Since proxy's that aren't compatible with CDC simply either won't
> unmarshall or can't be matched, this makes it relatively simple.

The bouncy castle crypto project, has had some challenges as well with
running under CDC. Maybe we could learn from them?

 From the faq:

> 3. I am using the lightweight library to create some MIDlets and my
> device/simulator is complaining about creation of classes in the Java
> package (such as java/math/BigInteger, java/security/SecureRandom,
> java/io/FilterInputStream), don't you Bouncy Castle guys know that's
> not allowed?
>
> The lightweight library contains some compatibility classes in the
> java/* namespace to make development easier for compatibility between
> client/server code (otherwise the MIDlet would be
> org/bc/math/BigInteger and the Servlet would be java/math/BigInteger)
> as well as keeping the BC codebase as small as possible. This change
> was introduced a number of years ago, and announced on the BC mailing
> list. Since then, many users have been creating MIDlets using the
> cldc_classes.zip and the world is a happy place.
>
> There is one, fundamental, important step that is required when
> creating a MIDlet. That is you must, must, must obfuscate the
> classes. If you do this correctly, everything works fine. If you do
> not do this correctly, your device/simulator will complain. Correctly
> in this case means that the package names also need obfuscating, not
> just the class names. The options for doing this are obfuscator
> dependent.
>
> Here is a thread from a Nokia forum discussion how to do this in
> Netbeans.


Gr. Sim



Re: CDC issues

Posted by Peter Firmstone <ji...@zeus.net.au>.
Thanks Sim,

I'm going to drop the CDC work for now, thanks for the link though.

Sim IJskes - QCG wrote:
> On 09/01/2010 09:36 AM, Peter Firmstone wrote:
>> The original intent behind the changes to RemoteEvent, were to change
>>  it's internal handback object to a MarshalledInstance from
>> MarshalledObject, so the Java CDC Personal Basis Profile could
>> participate in a djinn, with some very basic simple services and as a
>>  client.
>>
>> Since proxy's that aren't compatible with CDC simply either won't
>> unmarshall or can't be matched, this makes it relatively simple.
>
> The bouncy castle crypto project, has had some challenges as well with
> running under CDC. Maybe we could learn from them?
>
> From the faq:
>
>> 3. I am using the lightweight library to create some MIDlets and my
>> device/simulator is complaining about creation of classes in the Java
>> package (such as java/math/BigInteger, java/security/SecureRandom,
>> java/io/FilterInputStream), don't you Bouncy Castle guys know that's
>> not allowed?
>>
>> The lightweight library contains some compatibility classes in the
>> java/* namespace to make development easier for compatibility between
>> client/server code (otherwise the MIDlet would be
>> org/bc/math/BigInteger and the Servlet would be java/math/BigInteger)
>> as well as keeping the BC codebase as small as possible. This change
>> was introduced a number of years ago, and announced on the BC mailing
>> list. Since then, many users have been creating MIDlets using the
>> cldc_classes.zip and the world is a happy place.
>>
>> There is one, fundamental, important step that is required when
>> creating a MIDlet. That is you must, must, must obfuscate the
>> classes. If you do this correctly, everything works fine. If you do
>> not do this correctly, your device/simulator will complain. Correctly
>> in this case means that the package names also need obfuscating, not
>> just the class names. The options for doing this are obfuscator
>> dependent.
>>
>> Here is a thread from a Nokia forum discussion how to do this in
>> Netbeans.
>
>
> Gr. Sim
>
>
>