[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-mtj-dev] Preverification support on MTJ
|
Hi craig,
Totally agree with you :) I was already thinking about that and started to work on documenting some of the requirements that are currently implemented on
-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: terça-feira, 27 de maio de 2008 23:15
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] Preverification support on MTJ
Gustavo,
I think we probably need to have a conversation with the larger group concerning the scope of toolkit support that MTJ should support out of the box. I can see concerns with having an all-inclusive set of toolkits. With that said, I'd like to see us support at least one of the all-Java toolkits out of the box. It appears that MPowerPlayer has stagnated and that microemu is probably the better option at this point. To support one of these toolkits is going to require some kind of support for preverification on those platforms. The advantage of an all-Java solution (emulator and preverification) means that we can support pretty much any development platform.
The OSX preverifier can be downloaded as part of the MPowerPlayer toolkit. In addition, I managed to compile the preverifier from the phoneme project without too much trouble. I think there are some decent options there...
Craig
Paula Gustavo-WGP010 wrote:
> Hi craig,
>
> Some comments below
>
> :)
> gep
>
> -----Original Message-----
> From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
> Sent: sábado, 17 de maio de 2008 17:26
> To: Mobile Tools for The Java Platform mailing list
> Subject: Re: [dsdp-mtj-dev] Preverification support on MTJ
>
> If we don't support non-UEI SDK's, there are two significant (in my
> mind) problems:
>
> 1) We walk away from Mac because it does not currently have a UEI emulator.
> 2) We remove functionality that EclipseME had.
>
> I think both of these are bad choices. #1 because there is a growing Mac user base (including myself) and #2 because I'd like to transition to MTJ exclusively and yet I feel it is necessary to have the full EclipseME functionality in MTJ for me to do that.
>
> [gep]: I agree that we want to support mac, but I think that we need
> to consider the boundary between the SDKs and MTJ. Let's say that we
> want to support solaris and there is no MIDP SDK on solaris at all,
> does MTJ need to provide a MIDP/CLDC implementation on solaris? I
> wouldn't like to do that :)). That's why I'm not totally comfortable
> to maintain on MTJ a code that is "suppose" to be provided by the SDK
> (but I can change my mine on that :))
>
>
> In the long term, I'd like to see the embedded all-Java preverifier get fixed up, tested and working. I'm interested in doing that work, although I have no idea when I will find the time.
>
>
> [gep]: if you are interested in doing that work then I'm ok with that.
>
> In the mean time, I think it would be OK to require the MPowerPlayer osx preverifier for Mac users. In doing this, it would be necessary to allow the specification of an arbitrary path to the preverifier rather than assuming that it is tied to the location of the emulator. This would require some changes in the core as well as in the UI.
>
>
> [gep]: I haven't saw this osx preverifier yet, but, if there is already one there we can use, we can add the support to it. If you have some information about it, can you send to us? In the meantime I took some time to look at current MTJ preverification code and also at proguard preverifier. I did an initial prototype that use proguard preverifier and it seems to work ok. I attached a patch on https://bugs.eclipse.org/bugs/show_bug.cgi?id=234139 with the code. I didn't committed to svn, since there is no agreement yet that this is a good feature (and it is still a prototype). We can continue the discussion about this on the bugzilla.
>
>
> Those are my thoughts.
> Thanks,
> Craig
>
> PS - After talking to Eric LaFortune about the proguard preverifier, he thought it might be heavyweight to use as a pure preverifier (although possible). He seemed to imply that it was more meant to be used in a scenario where you want to obfuscate and preverify at the same time.
>
> On May 15, 2008, at 12:34 PM, Paula Gustavo-WGP010 wrote:
>
>
>> Hi guys,
>>
>> I'm back from javaone and I'm trying to catch up with all the
>> discussions on mtj list. There are a lot of emails :)
>>
>> About this preverifier question. As far as I know, the
>> preverification that was added to java 1.6 is different from the one
>> that is used on CLDC, since that we can not just use java 1.6
>> compiler to preverifier the CLDC classes
>> (http://forums.java.net/jive/thread.jspa?messageID=192443
>> ).
>>
>> I think that this is more a requirements issue. Do we want to have
>> that on MTJ or not??? I understand that we want to support different
>> platforms (linux, mac and windows), but based on craig's meail I
>> think that the real question is different:
>>
>> Do we want for now to support non-UEI SDKs???
>>
>> If we have a decision to support only UEI compliant SDKs then each
>> SDK is suppose to provide their preverifiers on each platform (linux,
>> mac or windows) and we don't need to add a preverifier on MTJ.
>>
>> The reason that EclipseME added this features was the supported to
>> those 2 SDKs that are not UEI compliant and do not include a
>> preverifier (please corret me if I'm wrong craig). Since that
>> eclipseME added its own to fill the gap of those SDKs.
>>
>> One possible plan to address the non-UEI SDKs is to use proguard 4.x
>> that includes a java preverifier (I never tested it, but it probably
>> works well). We can:
>> - document that in MTJ help
>> - add some UI that the user can configure proguard to preverify the
>> code
>> - remove our own preverifier implementation
>>
>> I'm not sure if a like the idea to have our own preverifier on MTJ
>> (and also to maintain it), since most SDKs include their own and also
>> it is possible to use other solutions like proguard that can be
>> downloaded and configured on our UI (but I'm open to change my
>> opinion
>> :) ).
>>
>> Comments???
>> :)
>> gep
>>
>> -----Original Message-----
>> From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
>> [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx
>> ] On Behalf Of Hildum Eric-XFQ473
>> Sent: terça-feira, 13 de maio de 2008 23:40
>> To: Mobile Tools for The Java Platform mailing list
>> Subject: RE: [dsdp-mtj-dev] Preverification support on MTJ
>>
>> 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
>> _______________________________________________
>> 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
> _______________________________________________
> 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
