java.lang

Team-Fly

---

Table 4-1 lists the classes and interfaces of java.lang in both J2SE (SDK version 1.3) and CLDC/MIDP. Keep in mind that just because a class is listed in the CLDC/MIDP column, it may not have the same API as its J2SE counterpart.

Table 4-1: The java.lang Package

INTERFACES
J2SE	MIDP
Cloneable	-
Comparable	-
Runnable	Runnable

CLASSES
J2SE	MIDP
Boolean	Boolean
Byte	Byte
Character	Character
Character.Subset	-
Character.UnicodeBlock	-
Class	Class
ClassLoader	-
Compiler	-
Double	-
Float	-
InheritableThreadLocal	-
Integer	Integer
Long	Long
Math	Math
Number	-
Object	Object
Package	-
Process	-
Runtime	Runtime
RuntimePermission	-
SecurityManager	-
Short	Short
StrictMath	-
String	String
StringBuffer	StringBuffer
System	System
Thread	Thread
ThreadGroup	-
ThreadLocal	-
Throwable	Throwable
Void	-

java.lang.Object, as always, is the root of every Java class. It remains mostly unchanged from J2SE, but there are some important differences.

No User Classloading

As I discussed in Chapter 1, one of the strengths of the Java platform is the ability to load classes at runtime. Unfortunately, because of resource constraints, CLDC/MIDP does not allow you to define your own classloaders. The application manager that runs MIDlets has a classloader, but you cannot access it or use it yourself in any way.

No Object Finalization

Object finalization is not available in CLDC (and, by extension, MIDP). Finalization is a mechanism by which objects can clean up after themselves just before they are garbage collected. In J2SE, an Object's finalize() method is called before the object is reclaimed by the garbage collector. No such mechanism exists in the CLDC. If you need to clean up resources, you will need to do it explicitly instead of placing cleanup code in finalize(). This is a good idea anyhow, particularly in a small device with limited resources. Explicitly cleaning up resources means that the memory and processing power they consume will be reclaimed sooner rather than later. Cleanup code in finalize() methods doesn't get executed until the garbage collector runs, and you never know exactly when that's going to happen.

No Reflection

The CLDC does not support the Reflection API. The target devices of CLDC/MIDP are simply too small to allow it. Although most developers don't need to use reflection directly, it has some important implications. Without reflection, no Remote Method Invocation (RMI) is possible. Without RMI, JINI is not possible. Therefore, CLDC/MIDP implementations cannot run JINI. If you want to run JINI, you'll need to investigate one of the larger J2ME profiles, most likely the RMI Profile or Personal Profile (see Chapter 1).

No Native Methods

Native methods are not supported in CLDC (and, by extension, MIDP). The specification does not support a way to write native device methods and access them from Java.

Multithreading

Using threads is much as you remember it from J2SE, as long as you keep things simple. Creating new threads, starting them, and using the handy java.lang.Runnable interface are the same as in J2SE. One important omission is the interrupt() method, which is not present in CLDC's java.lang.Thread class.

The pause(), resume(), and stop() methods (which are deprecated in J2SE SDK 1.3) are also absent. Thread groups and daemon threads are not supported in CLDC/MIDP; thread naming is also unsupported.

String and StringBuffer

Both String and StringBuffer are present in CLDC java.lang package. They are largely unchanged from their J2SE counterparts.

The largest change in the String class is the elimination of valueOf() static methods that convert between floating-point primitives and Strings. A few other obscure methods are absent from CLDC's String class, but you probably won't miss them. For example, although CLDC's String includes the compareTo(String str) method, it doesn't have either the compareTo(Object o) or compareToIgnoreCase(String str) methods that are found in J2SE SDK 1.3.

StringBuffer's append() and insert() methods do not include overrides for floating-point types in the CLDC version of the class. Also, the substring() method has been pruned. Other than that, however, StringBuffer should be very familiar for seasoned J2SE programmers.

Math

The Math class contains static methods for performing mathematical calculations. In J2SE, many of these methods involve trigonometric functions on floating-point numbers. In CLDC, these are all gone, leaving only a handful of methods:

 public final class Math     extends java.lang.Object {   // Static methods   public static int abs(int a);   public static long abs(long a);   public static int max(int a, int b);   public static long max(long a, long b);   public static int min(int a, int b);   public static long min(long a, long b); } 

Runtime and System

Runtime and System provide access to the Java Virtual Machine and system-wide resources. These two classes are greatly reduced from their J2SE counterparts, so much so that it makes sense to reproduce their entire public API here. First, let's take a look at Runtime:

 public class Runtime     extends java.lang.Object {   // Static methods   public static Runtime getRuntime();  // Methods   public void exit(int status);   public native long freeMemory();   public native void gc();   public native long totalMemory(); } 

To get the single Runtime instance, call getRuntime(). You can tell the JVM to run its garbage collector (gc()) or shut down (exit()). The other two methods, totalMemory() and freeMemory(), allow you to examine the amount of memory that is available for your application's data.

Note that Runtime does not support running external processes with the exec() method. MIDlets cannot step outside the bounds of the JVM.

System provide static methods for performing various common tasks:

 public final class System     extends java.lang.Object {   // Constants   public static final PrintStream err;   public static final PrintStream out;   // Static methods   public static native void arraycopy(Object src, int src_position,       Object dst, int dst_position, int length);   public static native long currentTimeMillis();   public static void exit(int status);   public static void gc();   public static String getProperty(String key);   public static native int identityHashCode(Object x); } 

The first thing you might notice is that while the err and out PrintStreams are defined, there is no System.in. This makes sense-System.in represents the console input; on a MID, there really isn't any console. In fact, it may seem weird to have System.out and System.err defined. If you print information to System.out, it may not come out anywhere on a device; however, on a device emulator, you may be able to view System.out in a console window.

The gc() and exit() methods are shortcuts for calling the corresponding methods in the Runtime class.

All of System's methods are static. The arraycopy() method provides a fast implementation of array copying. You can access MIDlet properties (described in Chapter 3) using getProperty().

Finally, identityHashCode() is a default used by Object's hashCode() method.

---

Team-Fly