Comments on: J2ME Optimizations http://www.agilefusion.com/2006/09/29/j2me-optimizations/ Integrating into the future Tue, 06 Jan 2009 21:07:31 +0000 http://wordpress.org/?v=2.6 By: Gal http://www.agilefusion.com/2006/09/29/j2me-optimizations/#comment-247 Gal Thu, 28 Dec 2006 08:14:42 +0000 http://www.agilefusion.com/2006/09/29/j2me-optimizations/#comment-247 Hi Alexey, Would like to connect with you. Have an initiative in the mobile space and looking for a technologists. Can you send me your email/ phone? Thanks Gal Hi Alexey,

Would like to connect with you. Have an initiative in the mobile space and looking for a technologists.

Can you send me your email/ phone?

Thanks

Gal

]]> By: David Landwehr http://www.agilefusion.com/2006/09/29/j2me-optimizations/#comment-71 David Landwehr Mon, 09 Oct 2006 07:13:12 +0000 http://www.agilefusion.com/2006/09/29/j2me-optimizations/#comment-71 The problem was not to do with initialization of the CSSHelper as initializing a couple of 100 constants does not take 50 seconds not even on a mobile phone. However this issue did reveal an interesting problem when a class uses final static arrays which are supposed to be removed in the shrinking/obfuscating phase (this is only verified with proguard). E.g. if you have: private static final VALUES = {"Value1", "Value2", "Value3"}; and you remove all reverences to VALUES then the proguard obfuscater will remove VALUES in the class, however if you decompile the class you will find the following code: static { String[] a = new String[3]; a[0] = "Value1"; a[1] = "Value2"; a[2] = "Value3"; } Which means that the class constant pool will have constants which is never used. This will impact the application in two ways:1) the jar size will be larger size the constants is included. 2) the constants will increase the VM's heap size since they are interned and the loading time of the class will increase because of this (e.g. it will take time to intern the strings and initializing the array which will later be garbage collected which also takes time). The solution is to either use a flag in the definition of the static array, like: private static final VALUES = FLAGS.INCLUDE ? {"Value1", "Value2", "Value3"} : null; or to make use the entire class is removed in the obfuscation step. The problem was not to do with initialization of the CSSHelper as initializing a couple of 100 constants does not take 50 seconds not even on a mobile phone. However this issue did reveal an interesting problem when a class uses final static arrays which are supposed to be removed in the shrinking/obfuscating phase (this is only verified with proguard). E.g. if you have:
private static final VALUES = {”Value1″, “Value2″, “Value3″};

and you remove all reverences to VALUES then the proguard obfuscater will remove VALUES in the class, however if you decompile the class you will find the following code:
static {
String[] a = new String[3];
a[0] = “Value1″;
a[1] = “Value2″;
a[2] = “Value3″;
}

Which means that the class constant pool will have constants which is never used. This will impact the application in two ways:1) the jar size will be larger size the constants is included. 2) the constants will increase the VM’s heap size since they are interned and the loading time of the class will increase because of this (e.g. it will take time to intern the strings and initializing the array which will later be garbage collected which also takes time).

The solution is to either use a flag in the definition of the static array, like:
private static final VALUES = FLAGS.INCLUDE ? {”Value1″, “Value2″, “Value3″} : null;
or to make use the entire class is removed in the obfuscation step.

]]>