river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: CDC issues
Date Fri, 03 Sep 2010 01:14:45 GMT
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

View raw message