Re: LWUIT code size
JSR 75 and 184 (PIM and 3D) aren't used by LWUITs core. If your
application doesn't make use of these features they don't need to be
in the obfuscated jar or in the device.
Since the LWUIT demo makes use of 3D in the 3D transitions this code
is packaged in, but if you don't use it the obfuscator removes the
unused classes implicitly.
I would still like to reduce the JAR size further and this is
something I'm working on, the strategy being to reduce class coupling
and shrink down the size of the hello world MIDlet. This is on my
todo list among way too many things that should be done ;-)
If you suspect the size of your MIDlet is too big try following the
instructions in the proguard manual to track down size: http://
Generate an obfuscation log and see what gets kept, you can use
options such as "-whyareyoukeeping className" to understand what
gets included. If there is something kept that seems like it
shouldn't be there just let us know.
As a side note it is possible that the current drop build of LWUIT is
a debug build that contains some references to the Log class which
makes use of JSR 75 in some situations. This shouldn't be the case in
the next drop (hopefully).
> Hi there,
> Good to know that the LWUITâ€™s code size, after compression, is now
> I have noticed to make LWUIT based J2ME app work, the minimum API
> support, apart from MIDP 2.0 and CLDC 1.1, is File and PIM API, and
> Mobile 3D API. I was just wondering if there is still further
> potential to make the code size smaller, since these 2 APIs are
> usually not used in the app, or maybe the obfuscator has already
> figured this out and no code from these two APIs are actually
> included in the final app so 123k is final.
> Any thoughts?
> Many thanks,