¿Qué es J2ME?  

J2ME (Java 2 Micro Edition) es la plataforma basada en el lenguaje Java que Sun Microsystems ha creado para la programación de dispositivos inalámbricos pequeños como teléfonos celulares, paginadores y PDA. La figura 4.1 muestra como está compuesta la plataforma J2ME.

Figura 4.1. Componentes de J2ME

La edición micro de Java se compone, además del lenguaje, de una máquina virtual, configuraciones, perfiles y paquetes adicionales (Fig. 4.1).

La máquina virtual es la base de la plataforma, es el interprete del lenguaje y sobre la cual se han de ejecutar las aplicaciones, también sobre esta máquina virtual corren las configuraciones (CDC y CLDC), las cuales incorporan apis básicas para la creación de aplicaciones y sirven de soporte a los perfiles. Los perfiles incluyen la mayor parte de las clases y apis que se van a utilizar en la programación, como pueden ser instrucciones de entrada y salida o de inicio y terminación de la aplicación.

Los paquetes adicionales son aquellos que la especificación de la tecnología inalámbrica Java (JSR185) no establece como obligatorios para incorporar en los dispositivos. Ejemplos de esto pueden ser las apis de mensajes inalámbricos (WMAPI) y de multimedia (WMAPI).

4.2. MIDP 2.0

Hasta este momento es el único perfil aplicado a los dispositivos en el mercado, aunque se están investigando algunos otros, como el especializado en PDA.

MIDP 2.0 incorpora apis de interfaz de usuario, de ciclo de vida del programa, almacenamiento persistente, juegos, trabajo en red y multimedia. Según la especificación de la tecnología inalámbrica de Java todo dispositivo que soporte MIDP 2.0 debe incluir mínimamente las siguientes características:

-Debe permitir archivos Java (JAR) de más de 64 KB. y archivos descriptores de aplicaciones (JAD) mayores a 5 KB.

-Se debe permitir a cada MIDlet la utilización de 30 KB de almacenamiento persistente y se recomienda que las MIDlets incluyan información acerca de el almacenamiento mínimo con el que trabajan correctamente.

-El espacio de memoria libre para una aplicación ejecutándose (Heap o del montón) debe ser por lo menos de 256 KB.

-Soporte para pantallas de 125 x 125 pixeles, con una profundidad de color de 12 bits.

-Se deben incluir la capacidad de que el dispositivo reaccione a eventos de tiempo (una alarma a determinada hora, los llamados ticklers o despertadores).

-Mecanismos para tomar un número telefónico del directorio del equipo.

-Soporte para imágenes en formato JPEG y PNG.

-Acceso a contenidos multimedia por el protocolo HTTP 1.1.

4.3. CLDC 1.1

Además de la Configuración para Dispositivos Conectados (CDC), CLDC (Connected Limited Device Configuration) es la única opción en configuraciones en la tecnología inalámbrica Java, aunque esta última está dedicada a la clase de aparatos que nos ocupan.

CLDC es la base para que los perfiles (como MIDP o PDAP) funcionen, proveyendo las apis básicas y la máquina virtual (KVM). CLDC está diseñada para equipos microprocesadores RISC o CISC de 16 a 32 bits y con una memoria mínima de 160 KB para la pila de la tecnología Java.

La JSR185 pide como requisitos mínimos para todo equipo que implemente CLDC 1.0 o 1.1

-Soporte mínimo para diez hilos relacionados con aplicaciones (MIDlets).

-Usar zonas de tiempo personalizables, con referencia en el formato de zonas de tiempo GMT (GMT \7:00, por ejemplo).

-Soporte para propiedades de carácter y conversiones mayúsculas-minúsculas en los bloques suplementales Unicode para Basic Latin y Latin-1 (nuestros caracteres).

4.4. KVM

Como ya se explicó anteriormente la máquina virtual es la base de la plataforma Java.

En el caso de la plataforma J2ME, debido a las capacidades limitadas de almacenamiento, memoria, procesamiento y pantalla de los dispositivos; no se puede integrar una máquina virtual Java (JVM) del las dimensiones de J2SE o J2EE. Por esto se ha creado una nueva máquina virtual: KVM (Kilobyte Virtual Machine)

KVM es una máquina virtual Java compacta y portable específicamente diseñada para ser la base de desarrollo en dispositivos pequeños y de recursos limitados. Actualmente CLDC trabaja sobre KVM. Además KVM está diseñada para mantener los aspectos centrales del lenguaje Java ejecutándose en unos cuantos kilobytes de memoria (de ahí su nombre).

Aunque KVM deriva de la máquina virtual J2SE (JVM), algunas características de esta última han sido eliminadas para soportar CLDC, debido a que resultan demasiado costosas de implementar o su presencia supone problemas de seguridad, resultando una KVM con las siguientes limitantes:

-Soporte de punto flotante.- KVM no soporta números de punto flotante, esto debido a que la mayoría de los dispositivos en los que se implementa no lo soportan tampoco.

-Finalización.- Las apis CLDC no incluyen el método object.finalize, así que no se pueden hacer operaciones de limpieza final antes de que el recolector de basura tome los objetos.

-Manejo de errores.- CLDC sólo define tres clases error: java.lang.Error, java.lang.OutOfMemoryError y java.lang.VirtualMachineError. Todo tipo de errores que no sean en tiempo de ejecución se manejan de modo dependiente del dispositivo, esto incluye la finalización de una aplicación o reinicio del dispositivo.

-Interfaz Nativa Java (JNI).-No se implementa JNI (posibilidad de incluir código en C dentro de clases Java), primeramente por motivos de seguridad, aunque también es considerado excesivo dadas las limitantes de memoria del dispositivo al que se dirige.

-Cargadores de clases definidas por el usuario.- KVM debe tener un cargador de clases que no pueda ser manipulado o remplazado por el usuario, principalmente por razones de seguridad.

-No hay soporte para la API reflection. La API reflection es más bien usada para aplicaciones de bajo nivel (depuradores, constructores GUI, etc). La falta de esta API impide también la serialización de objetos.

-Grupos de hilos o hilos "demonio".- Aunque CLDC soporta programación multihilo, no soporta grupos de hilos o hilos "demonio". Si requiere usar operaciones para grupos de hilos use objetos de colección para almacenar los objetos hilo a nivel de aplicación.

-Referencias débiles.- Ninguna aplicación construida con CLDC puede requerir referencias débiles.

4.4.1.Verificador de clases

En la máquina virtual de J2SE, el verificador de clases es el responsable de rechazar archivos de clase no válidos. Una máquina virtual que soporte CLDC (ahora KVM) también debe ser capaz de rechazar estos archivos. Sin embargo, el proceso de verificación de clases es tardado y costoso y, por lo tanto, no recomendable para equipos con recursos limitados.

Los diseñadores de KVM decidieron mover la mayor parte del trabajo de verificación de clases fuera del dispositivo, es decir, hacia la computadora de escritorio donde las clases son compiladas o el servidor de donde se descargan. A este proceso de verificación se le llama preverificación. Los dispositivos son únicamente responsables de ejecutar algunas pruebas en la clase preverificada para asegurarse de que aún es válida.

4.5. Apis en J2ME-CLDC

Las apis para CLDC tienen el objetivo de proveer un conjunto de bibliotecas mínimo y útil para el desarrollo de aplicaciones y definición de perfiles para una gran variedad de aparatos.

Las apis CLDC se pueden dividir en dos categorías:

-Clases derivadas de apis J2SE. Estas se localizan en los paquetes java.lang, java.io y java.util y se derivan de apis del Java Developement Kit (JDK) 1.3. En las tablas 4.1 y 4.2 se muestra una lista detallada de las clases incluidas.

-Clases específicas para CLDC. Se localizan en el paquete javax.microedition y sus subpaquetes y se explican con detalle abajo en la tabla 4.4.

4.5.1.Clases heredadas (derivadas)

CLDC hereda algunas clases de sistema, entrada y salida (E/S) y utilidades de la plataforma J2SE, las tablas 4.1 y 4.2 muestran los paquetes y sus clases que se heredaron de la edición estándar.

Tabla 4.1. Clases de NO excepción heredadas de J2SE

Tabla 4.2. Clases de excepción heredadas de J2SE

4.5.1.1.Soporte de propiedades

En CLDC no hay implementación para la clase java.util.Properties, sin embargo las propiedades mostradas en la tabla 4.3 están disponibles y se pueden obtener llamando al método System.getProperty(clave), donde clave puede ser cualquiera de las siguientes:

Tabla 4.3. Claves de las propiedades CLDC.

4.5.2.Clases específicas de CLDC

Las siguientes clases (Tabla 4.4) son específicas de CLDC y están contenidas en el paquete javax.microedition.io:

Tabla 4.4. Clases específicas de CLDC.

4.5.2.1.Clases específicas de MIDP

Además de las clases específicas de MIDP contenidas en javax.microedition.rms, javax.microedition.midlet y javax.microedition.lcdui; están disponibles las siguientes clases, interfaces y clases de excepción:

-IllegalStateException. Clase en el paquete java.lang.

-Timer y TimerTask. Clases en el paquete java.util.