RE: [dsdp-mtj-dev] Preverification support on MTJ

["Hildum Eric-XFQ473" <XFQ473@xxxxxxxxxxxx>]

If I understood the context correctly, the point of the enhancements to
the Java 6 compiler was that it would preverify the code for J2ME and
Java 1.4 targets (which presumably should work for all J2ME
implementations...). 


Eric Hildum
Senior Product Manager, Mobile Developer Tools & SDK
Software Platforms and Delivery
Ecosystem and Market Development
Motorola
Direct: +1-408-541-6809
Mobile: +1-510-305-0801
 
809 11th Avenue
Sunnyvale, CA 94089
USA

-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: Tuesday, May 13, 2008 16:28
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] Preverification support on MTJ

My understanding is that while the concepts are the same between ME and
SE, that the actual code attributes that are generated are different.
It may be close and we may be able to "fudge", but for now, I don't
think it is going to work for us.  The other piece of that puzzle is
that a lot of the devices don't like code that is compiled beyond
version 1.2 of Java... Thus, switching to Java 6 isn't going to fly in
that regard.

Craig

On May 12, 2008, at 10:56 PM, Hildum Eric-XFQ473 wrote:

> I have recently heard that the Java 6 compiler contains the capability

> to build preverfied code directly through compile time switches. I am 
> not sure if this capability may help us. If this capability is also 
> built into the Eclipse Java compiler, then we may be able to sidestep 
> the preverifier completely. That would clear the way for Mac and Linux

> support in MTJ.
>
>
> Eric Hildum
> Senior Product Manager, Mobile Developer Tools & SDK Software 
> Platforms and Delivery Ecosystem and Market Development Motorola
> Direct: +1-408-541-6809
> Mobile: +1-510-305-0801
>
> 809 11th Avenue
> Sunnyvale, CA 94089
> USA
>
> -----Original Message-----
> From: dsdp-mtj-dev-bounces@xxxxxxxxxxx 
> [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
> Sent: Sunday, May 11, 2008 19:13
> To: Mobile Tools for The Java Platform mailing list
> Subject: Re: [dsdp-mtj-dev] Preverification support on MTJ
>
> Eric,
>
> Sorry for not getting a response back on this for a while.  Part of it

> is that I've been busy and part was that I was doing a bit of 
> experimenting.
>
> On Apr 28, 2008, at 11:30 AM, Hildum Eric-XFQ473 wrote:
>
>> I have two questions for multiplatform support:
>>
>> 1. Is it just the preverifier that is the issue, or are there other 
>> components we need to worry about as well?
>>
>
> Given projects like MPowerPlayer and microemu, Mac has basic emulation

> functionality.  These emulators are limited in their JSR support, but 
> are probably "good enough" for now.  The problem does tend to be with 
> the preverifier.
>
>> 2. Should we ask Sun if the existing PhoneME preverifier can also be 
>> released as EPL code within MTJ?
>>
>
> You can ask, but my guess is that they will say that it is already 
> "open source".  The problem is that it is GPL.
>
>> My thought is we must have Windows, Linux, and Mac support in MTJ, 
>> the real question is the best way to get there (fast).....
>>
>
> I agree.  I did some experimentation and found that building the 
> preverifier from source for the Mac was not terribly difficult.  This 
> might be a reasonable starting point... I can always provide it as a 
> download for people to avoid EPL licensing issues with the GPL code.
> To make user of this, it would be necessary to allow an arbitrary 
> external preverifier to be associated with mpowerplayer and microemu 
> projects.  This is not supported by the EclipseME code on which MTJ is

> based.  The best thing we could do would be to allow the user to 
> choose an external preverifier or the built-in preverifier for *any* 
> device.
>
> In terms of the built-in preverifier, I had a quick look at ASM 3.0 in

> the process of doing something else for work.  It appears there are 
> actually some better API's in there that could be used to "fix up" the

> current implementation.  Unfortunately, that may not be doable in the 
> short term.
>
> In summary... I think there are some reasonable options for Mac, but 
> one of them is going to force the user through more hoops and the 
> other requires more work on MTJ part.
>
> Craig
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev