
 J 2 M E    T  E  C  H    T  I  P  S

                      TIPS, TECHNIQUES, AND SAMPLE CODE


WELCOME to the Java Developer Connection(sm) (JDC)
Java(tm) 2 Platform, Micro Edition (J2ME(tm)) 
Tech Tips, for February 26, 2002. This issue covers:

     * Optimizing J2ME Application Size
     * Object Serialization in CLDC-Based Profiles
      
The J2ME Tech Tips are written by Eric Giguere
(http://www.ericgiguere.com), an engineer at iAnywhere 
Solutions, inc. Eric is the author of the book "Java 2 Micro
Edition: Professional Developer's Guide" and co-author of the 
book "Mobile Information Device Profile for Java 2 Micro 
Edition," both books in John Wiley & Sons' Professional 
Developer's Guide series.

You can view this issue of the J2ME Tech Tips on the Web at
http://java.sun.com/jdc/J2METechTips/2002/tt0226.html

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
OPTIMIZING J2ME APPLICATION SIZE
  
If there's anything that differentiates J2ME applications from 
their J2SE(tm) counterparts, it's the limited environment in 
which they run. The primary limitation in many J2ME systems is 
the amount of memory available to store and run applications. 
Many current MIDP devices, for example, limit application sizes 
to 50K or less -- a far cry from the multi-megabyte applications 
possible in server-based J2SE environments. It's very easy to run 
up against these limits. So in this J2ME Tech Tip, you'll learn 
some techniques for minimizing application size. You'll use these
techniques to reduce the size of the following MIDlet which does
nothing but display a text field and beep whenever its contents 
change:

package com.j2medeveloper.techtips;

import javax.microedition.lcdui.*;

public class BeforeSizeOptimization extends 
                                         BasicMIDlet {

    public static final Command exitCommand =
                         new Command( "Exit",
                                    Command.EXIT, 1 ); 

    public BeforeSizeOptimization(){
    }

    protected void initMIDlet(){
        getDisplay().setCurrent( new MainForm() );
    }

    public class MainForm extends Form {
        public MainForm(){
            super( "MainForm" );

            addCommand( exitCommand );
            append( textf );

            setCommandListener( new CommandListener(){
                public void commandAction( Command c,
                                       Displayable d ){
                    if( c == exitCommand ){
                        exitMIDlet();
                    }
                }
              }
            );

            setItemStateListener( 
                              new ItemStateListener() {
                public void itemStateChanged( 
                                           Item item ){
                    if( item == textf ){
                        AlertType.INFO.playSound(
                                        getDisplay() );
                    }
                }
              }
            );
        }

        private TextField textf =
                  new TextField( "Type anything", null,
                                 20, 0 );

    }
}

Although a MIDlet serves as the example, the techniques described 
here apply to size optimization for any J2ME profile.

Note that the MIDlet class shown above depends on the following 
convenience class:

package com.j2medeveloper.techtips;

import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;

public abstract class BasicMIDlet extends MIDlet {

    private Display display;

    public BasicMIDlet(){
    }

    protected void destroyApp( boolean unconditional )
                    throws MIDletStateChangeException {
        exitMIDlet();
    }

    public void exitMIDlet(){
        notifyDestroyed();
    }

    public Display getDisplay(){ return display; }

    protected abstract void initMIDlet();

    protected void pauseApp(){
    }

    protected void startApp()
                    throws MIDletStateChangeException {
        if( display == null ){ 
            display = Display.getDisplay( this );
            initMIDlet();
        }
    }

}

When packaged using the J2ME Wireless Toolkit, the sample MIDlet 
is just over 4K bytes in size.

The first step in reducing size is to remove unnecessary classes 
by pruning the application's functionality. Are all the features 
of your application really necessary? Can your users get by 
without all the "bells and whistles?" Build the most minimal 
version of the application. Notice that the sample MIDlet is 
pretty minimal already.

The second step is to look closely at any inner classes defined 
by the application, particularly anonymous classes. Remember that 
each class file has a certain amount of overhead associated with 
it. Even the most trivial class has overhead:

    public class foo {
        // nothing here
    }

Compile this class and you get a class file that is almost 200 
bytes in size. A common use for an anonymous class, for example, 
is to implement an event listener. The sample MIDlet defines two 
listeners this way. An easy optimization to make, then, is to
make the main MIDlet class (which is not an optional or 
unnecessary class) implement the CommandListener and 
ItemStateListener interfaces, and move the listener code there.
Remember that multiple objects can use the same listeners. Use 
the arguments passed to the commandAction and itemStateChanged 
methods to distinguish between them if necessary.
   
Inner classes also bloat code other ways, because the compiler 
must generate special variables and methods to allow an inner 
class to access its enclosing class' private information. Read the 
original inner class specification at 
http://java.sun.com/products/jdk/1.1/docs/guide/innerclasses/
spec/innerclasses.doc.html for more details.

The third step is to maximize your use of pre-installed classes. 
For example, in CLDC-based profiles don't build your own set of 
collection classes. Use the built-in Hashtable and Vector classes 
and work around their limitations. The same goes for form 
creation in MIDP applications. The sample MIDlet defines a Form 
subclass to create its main form, but it could just as easily 
create it directly:

    mainForm = new Form( "MainForm" );
    mainForm.addCommand( okCommand );
    mainForm.setCommandListener( listener );

There's no right or wrong answer, it's simply something to 
consider. 

The fourth step is to collapse your application's inheritance 
hierarchies. You might have factored common code into one or more 
abstract classes, a recommended technique for object-oriented
design that promotes code reuse between applications. It might
contradict what you've learned, but it might make more sense to 
simplify the inheritance hierarchy. This is especially true if 
your abstract class -- which might be from another project -- is 
only subclassed once. The sample MIDlet extends the BasicMIDlet 
class, for example, but the two are easily combined into a single 
class.

The fifth step is to shorten the names of your packages, classes, 
methods and data members. This might seem silly, but a class file 
holds a lot of symbolic information. Shorten the names of things 
and you'll reduce the size of the class file. The savings won't 
be dramatic, but they can add up when spread over several 
classes. Package names are particularly ripe for shortening. 
Because MIDP applications are completely self-contained, you can 
avoid package names completely -- there is no chance of conflict 
with other classes on the device. The sample MIDlet could be 
moved out of the com.j2medeveloper.techtips package.

Note that name shortening is not normally something you want to 
do by hand. Instead, use a tool called an "obfuscator" to do it
for you. An obfuscator's primary purpose is to "hide" the code 
for an application by making it nearly unreadable when 
decompiled. A side effect of this process is to shrink the size 
of the application. That's because the hiding is done primarily 
by renaming methods and data members. There is an open source 
obfuscator called RetroGuard that is available for free from 
http://www.retrologic.com, and there are a number of commercial 
packages also available. (When obfuscating code for CLDC-based 
profiles, remember to do the obfuscation before the 
preverification step, otherwise the obfuscation will invalidate 
the preverification data stored in the class file.)

Finally, look closely at array initialization. (The sample MIDlet 
doesn't do any array initialization, but this is an important 
step for applications that do array initialization.) When 
compiled, an array initialization statement such as this:

    int arr[] = { 0, 1, 2, 3 };
  
actually produces code that behaves more like this:

    arr[0] = 0;
    arr[1] = 1;
    arr[2] = 2;
    arr[3] = 3;
   
To see this, use the javap tool that ships with the Java 2 SDK to 
disassemble the byte code to a class (use the -c option). You 
might be unpleasantly surprised at what you see, especially
if what you expected was a straight binary copy of constant data. 
Two alternative approaches are to (1) encode the data into a 
string and decode it into an array at runtime, or (2) store the 
data as a binary file packaged with the application and make it
accessible at runtime using the class loader's 
getResourceAsStream method.

These are just guidelines, and not every step mentioned here 
makes sense for every J2ME application. However, most of them do 
apply to the sample MIDlet. The optimized version of the MIDlet 
looks like this:

import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;

public class ASO extends MIDlet
                 implements CommandListener,
                            ItemStateListener {

    private Display   display;
    private Form      mainForm;
    private TextField mainFormTF =
                  new TextField( "Type anything", null,
                                 20, 0 );

    public static final Command exitCommand =
                         new Command( "Exit",
                                     Command.EXIT, 1 ); 

    public ASO(){
    }

    public void commandAction( Command c,
                               Displayable d ){
        if( c == exitCommand ){
            exitMIDlet();
        }
    }

    protected void destroyApp( boolean unconditional )
                    throws MIDletStateChangeException {
        exitMIDlet();
    }

    public void exitMIDlet(){
        notifyDestroyed();
    }

    public Display getDisplay(){ return display; }

    protected void initMIDlet(){
        mainForm = new Form( "MainForm" );
        mainForm.addCommand( exitCommand );
        mainForm.setCommandListener( this );
        mainForm.setItemStateListener( this );
        mainForm.append( mainFormTF );

        getDisplay().setCurrent( mainForm );
    }

    public void itemStateChanged( Item item ){
        if( item == mainFormTF ){
            AlertType.INFO.playSound( getDisplay() );
        }
    }

    protected void pauseApp(){
    }

    protected void startApp()
                    throws MIDletStateChangeException {
        if( display == null ){ 
            display = Display.getDisplay( this );
            initMIDlet();
        }
    }
}

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OBJECT SERIALIZATION IN CLDC-BASED PROFILES

The Connected Limited Device Configuration (CLDC) does not 
support object serialization or reflection. This means that 
unlike Mobile Information Device Profile (MIDP), there is no 
built-in way to persist objects into a byte stream for 
CLDC-based profiles. Applications that need to persist objects 
must build their own persistence mechanisms. That's true  
whether the need is to write the objects to a persistent storage 
facility like MIDP's Record Management System (RMS) or 
to send them across a network connection. It's hard to build
general persistence support that works with arbitrary objects.
However, writing task-specific persistence mechanisms is much 
simpler and arguably more suited to the constraints of the CLDC 
platform.

Persistence is easier to implement with the cooperation of the 
class that is to be persisted. At the most basic level it's just 
a matter of defining an interface like this:

import java.io.*;

/**
 * A simple interface for building persistent objects on
 * platforms where serialization is not available.
 */

public interface Persistent {

    /**
     * Called to persist an object.
     */

    byte[] persist() throws IOException;

    /**
     * Called to resurrect a persistent object.
     */

    void resurrect( byte[] data ) throws IOException;
}

Then you make your class implement the interface.

Consider a simple class describing an employee:

// Non-persistent version

public class Employee {
    private int      employeeID;
    private String   firstName;
    private String   lastName;
    private int      managerID;

    public Employee( int employeeID, String firstName,
                     String lastName, int managerID ){
        this.employeeID = employeeID;
        this.firstName = firstName;
        this.lastName = lastName;
        this.managerID = managerID;
    }

    public int getID() { return employeeID; }

    public String getFirstName() {
        return firstName != null ? firstName : ""; 
    }

    public String getLastName() {
        return lastName != null ? lastName : "";
    }

    public int getManagerID() { return managerID; }
}

The persistent version adds a null constructor and
implements the Persistent interface:

// Persistent version

import java.io.*;

public class Employee implements Persistent {
    private int      employeeID;
    private String   firstName;
    private String   lastName;
    private int      managerID;

    public Employee(){
    }

    public Employee( int employeeID, String firstName,
                     String lastName, int managerID ){
        this.employeeID = employeeID;t
        this.firstName = firstName;
        this.lastName = lastName;
        this.managerID = managerID;
    }

    public int getID() { return employeeID; }

    public String getFirstName() {
        return firstName != null ? firstName : ""; 
    }

    public String getLastName() {
        return lastName != null ? lastName : "";
    }

    public int getManagerID() { return managerID; }

    public String toString() {
        StringBuffer b = new StringBuffer();
        b.append( '{' );
        b.append( employeeID );
        b.append( ',' );
        b.append( firstName );
        b.append( ',' );
        b.append( lastName );
        b.append( ',' );
        b.append( managerID );
        b.append( '}' );
        return b.toString();
    }

    public byte[] persist() throws IOException {
        ByteArrayOutputStream bout = 
                           new ByteArrayOutputStream();
        DataOutputStream      dout = 
                          new DataOutputStream( bout );

        dout.writeInt( getID() );
        dout.writeUTF( getFirstName() );
        dout.writeUTF( getLastName() );
        dout.writeInt( getManagerID() );
        dout.flush();

        return bout.toByteArray();
    }

    public void resurrect( byte[] data ) 
                                   throws IOException {
        ByteArrayInputStream bin = 
                      new ByteArrayInputStream( data );
        DataInputStream      din = 
                            new DataInputStream( bin );

        employeeID = din.readInt();
        firstName = din.readUTF();
        lastName = din.readUTF();
        managerID = din.readInt();
    }
}

The persistence is actually accomplished using the
DataOutputStream and DataInputStream classes, which allow you to 
easily write and read Java primitives and strings. With the
Employee class, then, an employee can be persisted at any point, 
like this:

    Employee emp = .....; // an employee instance

    try {
        byte[] persisted = emp.persist();
    }
    catch( java.io.IOException e ){
        // do something here
    }
        
Restoring the employee is done like this:

    byte[] persisted = ....; // presistence info
    Employee emp = new Employee();
    
    try {
        emp.resurrect( persisted );
    }
    catch( java.io.IOException e ){
        // do something here
    }
    
Note that the Persistent interface uses byte arrays, not byte 
streams, for storing the persistence information. This is a 
deliberate choice. In MIDP applications you're most likely to 
persist objects to the RMS, and the RMS APIs are array-based, not
stream-based. That said, it would be just as simple to write 
stream-based persistence methods.

Things are more complicated, of course, if your objects contain 
references to other persistent objects. The example above
avoids this issue by storing the manager ID in the Employee
class. A more natural implementation is to use a reference to 
another Employee object. This complicates the persistence.
That's because, instead of persisting a single object, you need 
to persist a sequence of objects, possibly with cross-references 
to each other. Writing the code to deal with this scenario is 
non-trivial. You need to traverse the object graph, ensure that
each object gets written at most once, and deal with cycles in 
the graph. It's better to avoid these issues by making persisted 
objects completely self-contained, and use keys (unique 
identifiers) to link objects together.

Classes that don't implement the Persistent interface can also be 
persisted, but only if they expose enough information in their 
public interface. The java.util.Vector class, for example, can be 
persisted using static methods defined on a helper class:

import java.io.*;
import java.util.*;

public class VectorHelper {

    private static final int NULL = 0;
    private static final int INTEGER = 1;
    private static final int STRING = 2;
    private static final int PERSISTENT = 3;

    public static byte[] persist( Vector v )
                            throws IOException {
        ByteArrayOutputStream bout =
                          new ByteArrayOutputStream();
        DataOutputStream      dout =
                          new DataOutputStream( bout );

        int n = v.size();
        dout.writeInt( n );

        for( int i = 0; i < n; ++i ){
          Object o = v.elementAt( i );
            if( o instanceof String ){
                dout.writeByte( STRING );
                dout.writeUTF( (String) o );
            } else if( o instanceof Integer ){
                dout.writeByte( INTEGER );
                dout.writeInt( 
                            ((Integer) o).intValue() );
            } else if( o instanceof Persistent ){
                dout.writeByte( PERSISTENT );
                dout.writeUTF( 
                              o.getClass().getName() );
                byte[] data = 
                            ((Persistent) o).persist();
                dout.writeInt( data.length );
                if( data.length > 0 ){
                   dout.write( data );
                }
            } else if( o == null ){
                dout.writeByte( NULL );
            } else {
                throw new IOException( 
                "Cannot persist " +"object of type " +
                   o.getClass().getName() );
            }
        }

        dout.flush();

        return bout.toByteArray();
    }

    public static Vector resurrect( byte[] persisted )
                            throws IOException {
        ByteArrayInputStream bin =
                    new ByteArrayInputStream( 
                                          persisted );
        DataInputStream      din =
                    new DataInputStream( bin );

        Vector v = new Vector();
        int n = din.readInt();

        for( int i = 0; i < n; ++i ){
            int type = din.readByte();
            if( type == NULL ){
                v.addElement( null );
            } else if( type == INTEGER ){
                v.addElement( new
                       Integer( din.readInt() ) );
            } else if( type == STRING ){
                v.addElement( din.readUTF() );
            } else if( type == PERSISTENT ){
                String cname = din.readUTF();
                int    len = din.readInt();
                byte[] tmp = new byte[ len ];

                din.readFully( tmp );

                try {
                    Class cl = Class.forName( cname );
                    Object o = cl.newInstance();
                    ((Persistent) o).resurrect( tmp );
                    v.addElement( o );
                }
                catch( IOException e ){
                    throw e;
                }
                catch( Exception e ){
                    throw new IOException( 
                         "Exception " +e.toString() );
                }
                } else {
                   throw new IOException( "Unknown " +
                   "type " + type );
            }
        }

        return v;
  
    }
}

For brevity, the helper class only handles vectors whose 
elements are of type Integer or String, or that implement the 
Persistent interface. It can be easily extended to support other 
core types such as Long and Boolean.

Note that the VectorHelper class is fairly generic. So it has to 
write type information as part of the persistence  data in order 
to correctly recreate the vector's contents. Most vectors 
typically hold elements of the same type. In that case you might
be better off treating the vector as an array of objects, and 
simply writing out the element count and then each element, 
without all the extra type information.

Here is a simple MIDlet that uses the classes introduced in this 
tip to persist information to an RMS record store. The first time 
you run the MIDlet, it saves objects into the record store. The 
next run of the MIDlet reads the objects and displays their 
values.

import java.io.*;
import java.util.*;
import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;
import javax.microedition.rms.*;

public class PersistenceTest extends MIDlet
                 implements CommandListener {

    private Display   display;
    private Form      mainForm;

    public static final Command exitCommand =
                         new Command( "Exit",
                                     Command.EXIT, 1 ); 

    public PersistenceTest(){
    }

    public void commandAction( Command c,
                               Displayable d ){
        if( c == exitCommand ){
            exitMIDlet();
        }
    }

    protected void destroyApp( boolean unconditional )
                    throws MIDletStateChangeException {
        exitMIDlet();
    }

    public void exitMIDlet(){
        notifyDestroyed();
    }

    public Display getDisplay(){ return display; }

    protected void initMIDlet(){
        String str;
        RecordStore rs = null;

        try {
            rs =
                RecordStore.openRecordStore( 
                                       "test2", true );

            if( rs.getNumRecords() == 0 ){
                str = store( rs );
            } else {
                str = retrieve( rs );
            }
        }
        catch( Exception e ){
            str = e.toString();
        }

        mainForm = new Form( "MainForm" );
        mainForm.addCommand( exitCommand );
        mainForm.setCommandListener( this );
        mainForm.append( str );

        getDisplay().setCurrent( mainForm );
        
        if( rs != null ){
            try {
                rs.closeRecordStore();
            }
            catch( RecordStoreException e ){
            }
        }
    }

    protected void pauseApp(){
    }

    protected void startApp()
                    throws MIDletStateChangeException {
        if( display == null ){ 
            display = Display.getDisplay( this );
            initMIDlet();
        }
    }

    private String store( RecordStore rs )
                           throws RecordStoreException,
                                  IOException {
        Employee emp = new Employee( 
                                1, "Joe", "Clark", 0 );
        byte[]   data = emp.persist();

        rs.addRecord( data, 0, data.length );

        Vector v = new Vector();
        v.addElement( new Integer( 99 ) );
        v.addElement( "The Great One" );
        v.addElement( new Employee( 99, "Wayne",
                                    "Gretzky", 1 ) );

        data = VectorHelper.persist( v );
        rs.addRecord( data, 0, data.length );

        return "Wrote " + emp.toString() + " and " +
               v.toString();
    }

    private String retrieve( RecordStore rs )
                           throws RecordStoreException,
                                  IOException {

        byte[]   data = rs.getRecord( 1 );
        Employee emp = new Employee();

        emp.resurrect( data );

        data = rs.getRecord( 2 );
        Vector v = VectorHelper.resurrect( data );

        return "Read " + emp.toString() + " and " +
               v.toString();
    }
}

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

IMPORTANT: Please read our Terms of Use, Privacy, and Licensing
policies:
http://www.sun.com/share/text/termsofuse.html
http://www.sun.com/privacy/ 
http://developer.java.sun.com/berkeley_license.html

* FEEDBACK
  Comments? Send your feedback on the J2ME Tech Tips to: 
  
  jdc-webmaster@sun.com

* SUBSCRIBE/UNSUBSCRIBE
  - To subscribe, go to the subscriptions page,
    (http://developer.java.sun.com/subscription/), choose
    the newsletters you want to subscribe to and click "Update".
  - To unsubscribe, go to the subscriptions page,
    (http://developer.java.sun.com/subscription/), uncheck the
    appropriate checkbox, and click "Update".
  - To use our one-click unsubscribe facility, see the link at 
    the end of this email:
    
- ARCHIVES
You'll find the J2ME Tech Tips archives at:

http://java.sun.com/jdc/J2METechTips/index.html


- COPYRIGHT
Copyright 2002 Sun Microsystems, Inc. All rights reserved.
901 San Antonio Road, Palo Alto, California 94303 USA.

This document is protected by copyright. For more information, see:

http://java.sun.com/jdc/copyright.html

J2ME Tech Tips 
February 26, 2002

Sun, Sun Microsystems, Java, Java Developer Connection, J2ME, and
J2SE, are trademarks or registered trademarks of Sun Microsystems, 
Inc. in the United States and other countries.




