Hi Craig,
MicroEmu has Skeletons for all API that it
supports. The problem with MicroEmu was that their CLDC stubs had a corrupted
bytecode, preventing it to work properly with WTK preverifier. This problem is
already fixed and will be released in version 2.0.3 of MicroEmu (current is 2.0.2).
I do not think we really need this skeletons
distributed with MTJ, as they are supposed to be part of a device SDK. If initial
your intention was to provide a better out-of-the-box experience, I still think
that the skeletons should come of the SDK and providing only them will not
improve the OOTB experience. If we really need to improve it, we can think
about, in the future, distributing and entire SDK within MTJ (one of this
JavaSE based SKD, ME4SE, MicroEmu or MPower).
Lets try to keep this discussion in order
to have an agreement soon and decide what to do with the CQs
J
Hugo
From:
dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: Wednesday, July 30, 2008
10:00 PM
To: Mobile Tools for The Java
Platform mailing list
Subject: Re: [dsdp-mtj-dev]
EmptyAPIGenerator and Embedded Preverifier
I've not had time to go back through and take a look at what has been
done in terms of the skeleton API's. I'm concerned because I remember
going in this direction to support much more than just the microemu emulator.
Does Microemu have skeletons for all of the API's that the skeleton's
support?
On Jul 29, 2008, at 6:23 PM, Raniere Hugo-wha006 wrote:
During the code transition from EclipseME
to MTJ, we’ve opened a CQ for the EmptyAPIGenerator tool. In our
understanding, this tool was used to generate JavaME stubs to be used by the
embedded preverifier, and non-UEI SDKs.
We fixed the support to MPower and
MicroEmu using their own stubs, and by now, the embedded preverifier is not
being used in MTJ. Therefore I would like to discuss two topics with you:
- Can
we withdraw the EmptyAPIGenerator CQ? We are afraid that this CQ will be
hard to approve, as IP team could consider the EmptyAPIs as a derivative
work from WTK stubs L
- What
should we do with the Embedded preverifier code? MTJ user’s can set
an external preverifier if the SDK don’t have one, and MAC users can
use MPower preverifier. Do you think it is worth to keep this code in MTJ
svn considering that it will be finished and used in the future, or should
we remove it from there and leave it only in EclipseME SVN?
Looking forward to hear from you
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev