Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4C804C05.2030604@zeus.net.au>
Date: Fri, 03 Sep 2010 11:14:45 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: CDC issues
References: <4C6E0F9C.5090302@acm.org>	<4C6F587F.6080904@zeus.net.au>
	<4C6F60F7.2020305@acm.org>	<4C6F6DD0.10407@zeus.net.au>
	<4C6FC021.5080904@acm.org>	<4C6FC72E.4040907@zeus.net.au>
	<4C7016DB.2070205@acm.org>	<4C70180D.2060203@acm.org>
	<4C70569F.5070203@zeus.net.au>	<4C70B2E6.9000801@acm.org>
	<4C719365.6050501@acm.org>	<4C71B92A.40000@acm.org>
	<4C71B974.3040304@zeus.net.au>	<4C72F571.7000706@acm.org>
	<4C74D59A.3090302@zeus.net.au>	<4C757A32.2050607@acm.org>
	<4C7CFEDB.6030705@zeus.net.au>
	<AANLkTikexXOcazw_P9ZpcViDyTE3A=ZhVTd-4ACP7dTV@mail.gmail.com>
 <AANLkTim8ZrczGqfx3naTw-woGxCdctzZ5yF97fVbmx_Y@mail.gmail.com>
 <4C7E0276.9050309@zeus.net.au> <4C7E4C8A.6080803@qcg.nl>
In-Reply-To: <4C7E4C8A.6080803@qcg.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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