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