Java Connected Limited Device Configuration

• This is Java for the small, 160kb+ embedded market
• It consists of a configuration to run a tiny VM
• The size of the VM + libraries in ROM should fit in less than 128kb
• The runtime requirements of the VM are only 32k of RAM
• There are a number of profiles to run applications in small memory devices - these will typically add more ROM and RAM requirements
• Sun's Wireless Toolkit contains a Programmer's Guide

CLDC Configuration

• The CLDC cuts chunks out of the language to reduce the size of the interpreter/runtime
• Real number arithmetic/floats are gone. Software support for the float data type uses a lot of space, and most embedded applications do not use the float type
• No support for the Java Native Interface - vendors can use their own techiques (Sun's KVM has a KNI, but this does not allow DLLs like JNI)
• Class loaders can be defined in J2SE to e.g. load classes across the network, or via serial lines. This is removed - you cannot change class loaders
• Reflection allows a program to examine classes and methods, and define new classes and methods at runtime. These techniques are often used by Artificial Intelligence programs. Reflection is removed
• Thread group management is also gone

Classfile verification

• A strong selling point for Java in the early days was the sandbox model, where code loaded across the network was strictly limited in what it could do (e.g. no reading/writing local files)
• The Java 2 security model allows this to be customised by the user (e.g. allow code from www.monash.edu.au that is signed by IT Services to be able to reformat the disk - but no-one else can do this)
• In addition to runtime restrictions, code is also verified for things like array and stack overflows when it is loaded
• Load-time verification requires code in the VM, and hence uses space
• Load-time verification is replaced by pre-verification on some host

Standard packages

• CLDC has a lot of classes from J2SE, such as
  • java.lang.Object
  • java.lang.Class
  • java.lang.Runtime
• CLDC is missing a lot of classes from J2SE such as
  • java.lang.Math
  • java.lang.Number
  • java.lang.Package
  • java.lang.Process
• The classes that are there may not have all the methods of the J2SE classes e.g in java.io.DataOutputStream these are missing
  • writeBytes()
  • writeFloat()

Additional libraries

• Classe such as File and all of the java.net classes such as java.net.URL hava gone, because they are too heavyweight
• CDLC has an additional package javax.microedition.io
• This allows you to open sockets, files and URLs by e.g

  
        Connector.open("http://www.monash.edu.au");
        Connector.open("socket://192.168.1.1:8000");
        Connector.open("file:word.doc");
        

  Note: attempting to open a connection to an unsupported type will throw a ConnectionNotFoundException
• Objects like DataOutputStream can then be created by

  
        connection.openDataOutputStream()
        

KVM

• The K(ilobyte) Virtual Machine (KVM) is the Sun reference implementation of a VM written to CLDC
• Other vendors will create their own VMs for CLDC
• It is written in C and requires 40k of runtime
• Versions are available for Solaris, Linux and Windows for development, and Palm OS to show it really works
• It is supplied in source code form for building. It uses the Java JDK compiler during this
• For the versions that run on e.g. Windows, compile them in the usual way e.g. using javac and run them by using kvm class-file instead of java class-file

Profiles

Future Profiles

A number of other profiles are going through the Java Community Process (March 2003) to maybe become standards

• Information module - networking but no GUI
• RMI - remote method invocation
• USB support
• SIP -session initiation protocol, for session management (e.g. phone calls)
• JDBC
• Security and trust
• Industrial automation

Checking configuration

• There are two J2ME configurations (in different versions)
  • CDC
  • CLDC
• The property microedition.configuration will contain a string containing the configuration
• The MIDP 2.0 spec says that this will be For example, "CLDC-1.0"
• Hopefully, the syntax and values will be defined exactly for each configuration and version

Checking profiles

• The property microedition.configuration will contain a space separated list of profiles supported
• For MIDP 2.0, this list must contain MIDP-2.0

  
  
  
  
  
  public class CheckProfile {
  
      public static void main(String[] args) {
  	String prop = System.getProperty("microedition.configuration");
  	System.out.println(prop);
  	prop = System.getProperty("microedition.profiles");
  	System.out.println(prop);
      }
  }
  

  Run by

  
  kvm -classpath .:/usr/local/personaljava/WTK2.2/midpapi20.jar CheckProfile
        

Ok example

This compiles and runs okay:

public class Hello {

        public static void main(String[] args) {
            System.out.println("Hello world");
        }
}

Non-okay examples

This doesn't, because the class java.lang.Math is not known:

public class Hello {

        public static void main(String[] args) {
            System.out.println("Hello world");

            double x = java.lang.Math.PI;
        }
}

This fails because the field System.in has been removed

public class Hello {

        public static void main(String[] args) {
            System.out.println("Hello world");

            try {
                System.in.read();
            } catch(java.io.IOException e) {
            }
        }
}

Compiling against KVM libraries

• Normal use of the javac compiler automatically uses the standard J2SE core libraries
• These can be replaced by using the option -bootclasspath
• The KVM distribution builds specialised libraries in the api/classes.zip file
• Compile using the command

  
        javac -bootclasspath $KVM_HOME/api/classes.zip Hello.java