Re: [dsdp-mtj-dev] EmptyAPIGenerator and Embedded Preverifier

[Craig Setera <craigjunk@xxxxxxxxxx>]

I finally found some time today to take a look at where things are at 
with the current MTJ code.  I wrote up a few bugs and fixed a couple of 
them.  There are two outstanding bugs that I wrote that are related to 
this discussion:

Can't import Microemu 2.0.3 snapshot 37
https://bugs.eclipse.org/bugs/show_bug.cgi?id=243000

Embedded preverifier fails with NPE
https://bugs.eclipse.org/bugs/show_bug.cgi?id=243001

While I'm concerned with the removal of all of the empty API stuff and 
the related loss of functionality, I think it is a reasonable thing to 
do for the first release.  I'd like to see how it goes in the future 
without that support.  In order for this to work, it seems to me that at 
least two things need to happen:

- The user needs a place in the preference to point to a default 
preverifier to be used for the Java emulators.  Without that option, the 
user is forced to alter each device that is imported. 
- The system needs to automatically associate the configured default 
preverifier whenever the user imports a Java-based emulator.  Otherwise, 
it is way too confusing and leads to bugs like the above.

I did not write up specific bugs for this functionality, because I 
thought it was worth discussing via the email list before deciding on a 
final solution.  What are others thoughts on this topic?

Thanks,
Craig

Raniere Hugo-wha006 wrote:
> 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
>
>