introducción a j2me - mi materia en líneamoodle2.unid.edu.mx/.../am/07/introduccion_a_j2me.pdf ·...
TRANSCRIPT
Introducción a J2ME
Felipe Vidueira Estévez
Departamento de Ciencias de la Computación de la Universidad de Alcalá
1. INTRODUCCIÓN. ..................................................................................... 4
2. COMPONENTES DE J2ME...................................................................... 7
2.1. Máquina virtual ..............................................................................................................................8
2.2. Configuración .................................................................................................................................8
2.3. Perfil ................................................................................................................................................8
3. ESTANDARIZACIÓN DE COMPONENTES J2ME................................. 10
3.1. Ciclo de vida de una JSR .............................................................................................................10
3.2. Compatibilidad entre componentes ............................................................................................11
4. ARQUITECTURA J2ME ......................................................................... 12
4.1. Máquinas virtuales .......................................................................................................................13 4.1.1. C Virtual Machine ..................................................................................................13 4.1.2. K Virtual Machine..................................................................................................14
4.2. Configuraciones ............................................................................................................................15 4.2.1. Connected Device Configuration...................................................................15 4.2.2. Connected Limited Device Configuration................................................15
4.3. Perfiles ...........................................................................................................................................17 4.3.1. Foundation Profile ..................................................................................................17 4.3.2. Personal Profile ........................................................................................................17 4.3.3. Mobile Information Device Profile ..............................................................18
5 INSTALACIÓN........................................................................................... 20
5.1 WINDOWS ...................................................................................................................................20
6 UN PRIMER EJEMPLO ............................................................................. 24
7 PAQUETES Y CLASES PRINCIPALES.................................................... 30
7.1 JAVAX.MICROEDITON.MIDLET...........................................................................................30
7.2 JAVAX.MICROEDTION.LCDUI..............................................................................................31
Charla J2ME Departamento de Ciencias de la Computación
2
7.3 ALMACENAMIENTO DE DATOS...........................................................................................37
7.4 COMUNICACIONES DE RED MEDIANTE J2ME MIDP ....................................................39
8 BIBLIOGRAFÍA ......................................................................................... 42
9 DIRECCIONES DE INTERÉS .................................................................... 42
Charla J2ME Departamento de Ciencias de la Computación
3
1. Introducción.
La empresa Sun Microsystems lanzó a mediados de los años 90 el lenguaje de programación Java, orientado en un principio a la creación de componentes interactivos embebidos en páginas HTML, y que presentaba las siguientes características: • Inspirado inicialmente en C++, pero con adiciones de alto nivel, como soporte nativo de
strings y garbage collection.
• Código independiente de plataforma, precompilado a bytecode intermedio y ejecutado en el
cliente por una JVM (Java Virtual Machine).
• Modelo de seguridad tipo sandbox proporcionada por la JVM.
• Abstracción del sistema operativo subyacente mediante un juego completo de APIs de
programación.
Con el curso de los años, Java ha progresado enormemente en dos dimensiones:
• Nuevos ámbitos de ejecución: Programas aislados, servicios HTTP (servlets, JSP),
servidores de aplicaciones (EJB).
• Mayores y más diversas funcionalidades: APIs para acceso a bases de datos (JDBC),
telefonía (JTAPI), multimedia (JMF), mensajería (JMS), transacciones (JTS).
De resultas de esta explosión tecnológica, en la actualidad es poco realista concebir Java como
un simple lenguaje de programación; en su lugar, resulta más conveniente considerarlo como
un conjunto de tecnologías diseminadas en todos los ámbitos de computación con dos
elementos comunes:
• El código fuente en lenguaje Java es compilado a código intermedio interpretado por una
JVM.
• Todas las tecnologías comparten un conjunto más o menos amplio de APIs básicas del
lenguaje, agrupadas principalmente en los paquete java.lang y java.io.
En el mundo de los dispositivos electrónicos, como teléfonos móviles, PDAs o dispositivos
embebidos, la situación es aún más caótica, debido a que las plataformas en consideración son
fuertemente disimilares en cuanto a capacidad y requisitos. Han surgido en el pasado
numerosas iniciativas, con frecuencia incompatibles entre sí, para introducir Java en el
desarrollo de aplicaciones para estos dispositivos.
Charla J2ME Departamento de Ciencias de la Computación
4
En los últimos tiempos, Sun ha reconocido esta diversidad de ámbitos tecnológicos en los que
Java se desenvuelve, y los ha agrupado en tres grandes entornos de aplicación, o ediciones,
por seguir la terminología de la empresa:
Charla J2ME Departamento de Ciencias de la Computación
5
• J2EE (Java 2 Platform, Enterprise Edition), orientada al desarrollo de servicios web y
aplicaciones distribuidas mediante EJBs (Enterprise Java Beans) y tecnologías
relacionadas, con APIs para la gestión de transacciones, persistencia de objetos, servicios
de nombres, XML, autentificación, etc.
• J2SE (Java 2 Platform, Standard Edition), que abarca las APIs orientadas a la
programación de aplicaciones de usuario final: interfaz gráfica de usuario, multimedia,
networking. Esta edición es la que en cierta forma recoge la iniciativa original del lenguaje
Java.
• J2ME (Java 2 Platform, Micro Edition), enfocada a la aplicación de la tecnología Java en
dispositivos electrónicos con capacidades computacionales y gráficas muy reducidas, tales
como teléfonos móviles, PDAs o electrodomésticos inteligentes.
Figura 1: Relaciones entre ediciones de Java.
Sólo de forma muy simplista puede considerarse que J2ME y J2EE son versiones reducida y
ampliada, respectivamente, de J2SE: en realidad, cada una de las ediciones enfoca ámbitos de
aplicación radicalmente distintos e independientes entre sí. Después de todos, las necesidades
computacionales y APIs de programación requeridas por, por ejemplo, un juego gráfico
ejecutándose sobre una PDA no tienen mucho que ver con los de un servidor distribuido de
aplicaciones basado en EJB.
En lo que sigue estudiaremos con más detalle los componentes que integran la plataforma
J2ME, la taxonomía propuesta por Sun de entornos de ejecución basados en las capacidades
gráficas y computacionales de los dispositivos y la funcionalidad para la que están diseñados,
la integración en J2ME de otras tecnologías Java relacionadas y la relevancia de la iniciativa
J2ME para el desarrollo de aplicaciones y servicios embebidos en dispositivos móviles 2,5 y
3G.
Charla J2ME Departamento de Ciencias de la Computación
6
2. Componentes de J2ME Al contrario que en otras tecnologías orientadas a PCs y ordenadores convencionales, en
J2ME el espectro de dispositivos considerados varía enormemente en cuanto a capacidad
computacional, memoria y capacidades gráficas. Ante la imposibilidad de establecer una
arquitectura común que se adecue a esta variedad de entornos hardware, J2ME define una
serie de componentes (building blocks) a partir de los cuales se construye una implantación
concreta para un dispositivo determinado. Estos componentes se agrupan en los siguientes
tipos:
• Máquina virtual
• Configuración
• Perfil
• Paquetes opcionales.
Un entorno de ejecución determinado de J2ME se compone entonces de una selección de
máquina virtual, configuración y perfil, y posiblemente otros paquetes opcionales. En la figura
se muestran las relaciones entre los distintos componentes de un entorno de ejecución de
J2ME.
Figura 2: Relaciones entre componentes J2ME.
sistema operativo subyacente
máquina virtual
configuración
perfilpaquetes
opcionales
aplicaciones
J2ME
Charla J2ME Departamento de Ciencias de la Computación
7
2.1. Máquina virtual
Una máquina virtual de Java (JVM, Java Virtual Machine) es un programa encargado de
traducir código intermedio (bytecode) de los programas Java precompilados a código máquina
ejecutable por la plataforma, efectuar las llamadas pertinentes al sistema operativo subyacente
y observar las reglas de seguridad y corrección de código definidas para el lenguaje Java. De
esta forma, la JVM proporciona al programa Java independencia de la plataforma con respecto
al hardware y al sistema operativo subyacente.
Las implementaciones tradicionales de JVMs son en general muy pesadas en cuanto a
memoria ocupada (footprint) y requerimientos computacionales. J2ME define varias JVMs de
referencia adecuadas al ámbito de los dispositivos electrónicos, que en algunos casos se
apartan de la especificación estándar relajando algunas exigencias con el fin de obtener
implementaciones más ligeras.
2.2. Configuración
Una configuración es un conjunto de APIs básicas de Java que definen un entorno
generalizado de ejecución. Una configuración no está orientada a ningún campo específico de
aplicación, sino que más bien trata de agrupar los dispositivos en cuanto a sus capacidades
computacionales y entorno genérico de operación (por ejemplo, si tienen conectividad o no). En
particular, las librerías de interfaz gráfica nunca pertenecen a la definición de una configuración
J2ME.
Usualmente, una configuración especifica una JVM de referencia sobre la que debe correr; en
algunos casos, además, esta JVM se aparta del estándar, relajando algunas características.
Esta JVM de referencia no es una exigencia de la configuración, sino que más bien establece
la funcionalidad mínima que debe pedirse a las implementaciones de la JVM utilizadas. Por
supuesto, una implementación inteligente de una configuración J2ME dada se ceñirá en la
medida de lo posible a las especificaciones mínimas requeridas.
2.3. Perfil
Charla J2ME Departamento de Ciencias de la Computación
8
Un perfil es un conjunto de APIs orientadas a un ámbito de aplicación determinado, para una
configuración J2ME dada. Los perfiles identifican un grupo de dispositivos por la funcionalidad
que proveen (por ejemplo, teléfonos móviles, electrodomésticos) y el tipo de aplicaciones que
típicamente correrán sobre ellos.
La librería de interfaz gráfica es generalmente una componente muy importante de la definición
de un perfil. Las interfaces gráficas difieren mucho entre distintos perfiles (displays textuales en
teléfonos móviles, interfaces basadas en pen para PDAs, etc.), y en algunos perfiles ni siquiera
existen (sistemas embebidos, por ejemplo).
Un perfil siempre se define a partir de una configuración dada. Así, cabe pensar en un perfil
como un conjunto de APIs que dotan a una configuración J2ME de funcionalidad específica
para una familia de dispositivos concreta y para un tipo de aplicaciones determinado.
Charla J2ME Departamento de Ciencias de la Computación
9
3. Estandarización de componentes J2ME
La intencionada indefinición en cuanto a especificación y selección de componentes de la
arquitectura J2ME podría dar lugar a la proliferación de numerosos entornos de ejecución
incompatibles y pseudo propietarios de no mediar alguna clase de esfuerzo coordinado de
estandarización en el seno de la industria de los dispositivos electrónicos.
Con el fin de involucrar a la industria software y hardware en la evolución y el soporte de la
tecnología Java, Sun ha creado el programa Java Community Process (JCP), un foro de
estandarización con aproximadamente 300 participantes entre particulares, instituciones
académicas y empresas de software, electrónica, telefonía móvil, comunicaciones, etc.
Notablemente, ni Microsoft ni Intel pertenecen al programa JCP. El trabajo del programa JCP
se articula en torno a la producción y aprobación de documentos de estándar conocidos como
JSRs (Java Specification Requests), similares en forma e intención a las RFCs de la IETF.
Uno de los campos de actividad del programa JCP es la especificación de componentes de
J2ME, con el objetivo de llegar a un consenso amplio en torno a un número razonablemente
pequeño de entornos de ejecución de J2ME agrupados por mercados de aplicación bien
definidos, como el de las PDAs o el de la telefonía móvil. De los esfuerzos del programa JCP
han surgido ya componentes estandarizados de J2ME, con diferentes grados de aceptación e
implantación en la industria.
3.1. Ciclo de vida de una JSR
En la Figura 3 se definen los sucesivos estadios por los que una Java Specification Request
(JSR) atraviesa hasta que se convierte en un estándar aprobado (Final Release). Estos
estadios van desde la aprobación del comienzo de la JSR y la formación de un grupo de
trabajo hasta la publicación del Final Draft y la aprobación final del mismo.
En la figura se muestra el ciclo de vida de una JSR junto con las estimaciones temporales de
algunos procesos críticos en la evolución del proyecto. Esta información puede ser útil a la hora
de evaluar el tiempo que resta para que un estándar en progreso sea completado por el JCP.
Charla J2ME Departamento de Ciencias de la Computación
10
Figura 3: Ciclo de vida de una JSR.
Com
mun
ity R
evie
w
Publ
ic R
evie
w
Fina
l Dra
ft Pr
opos
al
Fina
l Rel
ease
Bal
lot
Fina
l Rel
ease
Mai
nten
ance
Rev
iew
14 daysEC vote
Expert GroupFormed
30-90 days
Last 7 daysfor EC vote
30-90 days 14 daysEC vote
30 days
Last 7 days for ECItem Exception vote
EC: Executive Committee
JSR
Rev
iew
3.2. Compatibilidad entre componentes
Ante la multiplicidad de entornos de ejecución que presenta J2ME, el antiguo lema “Write
Once, Run Anywhere” asociado al lenguaje Java no parece muy aplicable en el mundo de los
dispositivos electrónicos. Esto difícilmente puede verse como una debilidad de la plataforma
J2ME, teniendo en cuenta la enorme variedad de dispositivos y ámbitos de aplicación que esta
tecnología abarca.
En general, los desarrolladores de aplicaciones para J2ME pueden esperar y deberían
promover la compatibilidad entre plataformas dentro del ámbito de un mismo perfil. De esta
forma, las aplicaciones para teléfonos móviles 2,5G, por ejemplo, deberían poder correr en
todos aquellos dispositivos que soporten el perfil MIDP.
Otras compatibilidades cruzadas, como entre perfiles más limitados y menos limitados, en
general no están garantizadas, y lo máximo que puede esperarse en este campo es que al
menos grandes porciones de código puedan utilizarse en proyectos basados en distintos
entornos J2ME.
Charla J2ME Departamento de Ciencias de la Computación
11
4. Arquitectura J2ME
Como se ha explicado anteriormente, el programa de estandarización JCP ha definido diversos
entornos de ejecución de J2ME identificados por una selección particular de máquina virtual,
configuración y perfil J2ME. Es de suponer que esta arquitectura evolucionará en dos sentidos:
Refinamiento de los entornos de ejecución definidos (nuevas versiones de los componentes),
definición de nuevos entornos de ejecución.
Figura 3: Arquitectura de J2ME.
CVM KVM
CDC CLDC Configuraciones
Máquinasvirtuales
FP PDAP MIDP PerfilesPP
En la figura se muestra el estado actual de la arquitectura J2ME. Solamente se han incluido en
el diagrama los componentes de J2ME que están estandarizados o muy próximos a ser
estandarizados y que tienen especial relevancia para el mercado de los dispositivos para
comunicaciones móviles.
Así como en el campo de los perfiles la arquitectura de J2ME es aún dispersa y está sujeta a
cambios, parece que se ha alcanzado un consenso bastante estable en cuanto a las dos
configuraciones disponibles:
• Connected Device Configuration (CDC), para dispositivos dotados de conectividad y con
(relativamente) alta capacidad computacional,
• Connected Limited Device Configuration (CLDC), para dispositivos con capacidades
(proceso y memoria) limitadas dotados de conectividad.
En la Figura 4 se relacionan unos cuantos tipos de dispositivos con la configuración más
apropiada para los mismos.
Charla J2ME Departamento de Ciencias de la Computación
12
Figura 4: Relación de configuraciones con tipos de dispositivos
4.1. Máquinas virtuales
4.1.1. C Virtual Machine La C Virtual Machine (CVM) es una implementación de referencia escrita en lenguaje C de la
máquina virtual de Java (JVM) estándar, orientada a dispositivos electrónicos con
procesadores de 32 bits de gama alta y en torno a 2 MB o más de memoria RAM. Según Sun,
la CVM está diseñada de forma que su portado a distintos sistemas operativos y/o
procesadores sea relativamente fácil, lo cual debe ayudar a extender las configuraciones J2ME
basadas en una JVM estándar (no reducida). La ocupación en memoria (footprint) de la CVM
está en torno a los 256 KB.
En la actualidad, CVM tan sólo se encuentra disponible para el sistema operativo Linux sobre
procesadores Intel x86, pero Sun apoya el portado de la CVM a otras plataformas.
Charla J2ME Departamento de Ciencias de la Computación
13
La liberación de la CVM obedece a una política de open source de Sun Microsystems
encaminada a promover la ubicuidad de Java, favoreciendo de esta forma la migración de la
tecnología Java a muchas más plataformas de las que en principio una sola empresa podría
abarcar.
La CVM ha sido tomada como JVM de referencia en la definición de la CDC
4.1.2. K Virtual Machine
La K Virtual Machine ó KVM (la K viene de kilobyte, haciendo referencia a la baja ocupación en
memoria) se desarrolló en parte en el programa de investigación Spotless de Sun
Microsystems dedicado a la implementación de un sistema Java para el Organizer de Palm. Se
trata de una implementación de referencia para una JVM reducida especialmente orientada a
dispositivos con bajas capacidades computacionales y memoria limitada. En concreto, la KVM
presenta las siguientes limitaciones (entre otras) con respecto a la especificación estándar de
la JVM:
• No hay soporte para tipos de coma flotante (float y double).
• No hay soporte para métodos nativos (Java Native Interface, JNI).
• No se soporta la reflexión de clases.
• No se soporte la finalización de objetos (método Object.finalize()).
• Tratamiento limitado de excepciones.
Además, el sistema de seguridad de la JVM ha sido simplificado y modificado para
ajustarse a limitaciones computacionales y de memoria más estrictas.
La KVM está escrita en lenguaje C y, según Sun, en mayo de 2000 había sido portada al
menos a 25 plataformas distintas, entre las que se encuentran:
• Palm OS,
• Win32,
• Solaris.
A fecha actual, los autores no conocen ninguna versión para Windows CE de la KVM, aunque
los dispositivos típicos sobre los que corre Windows CE tienen potencia suficiente para ejecutar
una JVM estándar.
La ocupación en memoria (footprint) de la KVM oscila entre los 40 y los 80 KB.
La KVM ha sido tomada como JVM de referencia en la definición de la CLDC
Las primeras versiones de la KVM se incluyeron así mismo en las distribuciones de KJava.
Charla J2ME Departamento de Ciencias de la Computación
14
4.2. Configuraciones
4.2.1. Connected Device Configuration
La configuración J2ME conocida como Connected Device Configuration (CDC) está siendo
elaborada dentro de la JSR 36 del JCP; la versión 0.2 alcanzó el estatus de Final Draft el 21 de
febrero de 2001.
La CDC está orientada a dispositivos electrónicos con las siguientes capacidades:
• Procesador de 32 bits.
• 512 KB mínimo de memoria ROM.
• 256 KB mínimo de memoria RAM.
• Conectividad a algún tipo de red.
• Soporte total de la JVM v.2
Como ya se ha explicado, la CDC no se hace ninguna asunción acerca de las capacidades
gráficas de los dispositivos. Dispositivos típicos a los que la CDC se orienta son:
• Descodificadores de TV,
• teléfonos con navegación de Internet (communicators),
• sistemas de navegación para coches.
Como se ha dicho, la CDC corre sobre una JVM estándar; no obstante, las implementaciones
de referencia, desarrolladas para los sistemas Linux y VxWorks, utilizan la CVM.
La CDC está basada en J2SE v1.3, e incluye varios paquetes Java de la edición estándar. Las
peculiaridades de la CDC están principalmente contenidas en el paquete javax.microedition.io,
que incluye soporte genérico para comunicaciones HTTP y comunicaciones basadas en
datagramas.
Un aspecto importante de la CDC es que engloba totalmente las APIs de la CLDC.
4.2.2. Connected Limited Device Configuration
La configuración J2ME conocida como Connected Limited Device Configuration (CLDC) está
siendo elaborada dentro de la JSR 30 del JCP; la versión 1.0 alcanzó el estatus de Final
Release el 30 de mayo de 2000.
Charla J2ME Departamento de Ciencias de la Computación
15
La CLDC está orientada a dispositivos dotados de conectividad con reducidas capacidades
computacionales y memoria limitada, de acuerdo a los siguientes parámetros:
• Procesador de bajas prestaciones, posiblemente de 16 bits.
• De 128 a 512 KB de memoria total, incluyendo ROM/Flash y RAM.
• Potencia limitada, frecuentemente alimentados por baterías.
• Conectividad reducida (9600 bps o menos), como en el caso de GSM.
Entre los dispositivos a los que la CLDC se orienta tenemos:
• PDAs de bajas prestaciones (tipo Palm),
• teléfonos móviles GSM y 2,5G (GPRS).
• buscas (pagers),
• terminales de transacciones electrónicas.
Con objeto de adaptarse a las restrictivas capacidades de este tipo de dispositivos, la CLDC no
opera sobre una JVM estándar, sino que define un subconjunto de ésta conocido como KVM.
En cuanto a las APIs incluidas, parte de ellas provienen de la edición estándar de Java (J2SE),
y además se incluyen unas APIs genéricas de conectividad en el paquete javax.microedition.io.
Todas las APIs de la CLDC están también contenidas en la CDC.
CLDC para Palm
Posiblemente, la implementación más popular actualmente de CLDC/KVM es la del Palm
Connected Organizer, que actualmente ya está siendo usada para desarrollo de pequeñas
aplicaciones en este dispositivo.
Una característica interesante de la distribución que hace Sun de CLDC/KVM para Palm es que
incorpora una pequeña librería no estándar denominada Palm API para gestión de la interfaz
gráfica de la Palm. De esta forma es posible desarrollar aplicaciones gráficas para Palm
directamente sobre CLDC/KVM sin instalar ningún perfil J2ME (los cuales, según los filosofía
de la arquitectura, son los encargados de especificar las interfaces gráficas). La Palm API está
contenida en el paquete com.sun.kjava, proveniente de la tecnología pre-J2ME KJava. Sun
efectúa esta distribución no estándar de CLDC/KVM con el objeto de proporcionar soporte y
continuidad a los desarrolladores de KJava.
Charla J2ME Departamento de Ciencias de la Computación
16
4.3. Perfiles
4.3.1. Foundation Profile
El perfil J2ME conocido como Foundation Profile (FP) está siendo elaborado dentro de la JSR
46 del JCP; la versión 0.2 alcanzó el estatus de Final Draft el 21 de febrero de 2001.
El FP define una serie de APIs sobre la CDC para dispositivos sin interfaz gráfica dentro del
rango de aplicabilidad de la CDC, esto es, algún tipo de conectividad y potencia y memoria
suficiente (1024 KB ROM, 512 KB RAM).
El mismo nombre del FP sugiere que este perfil incorpora muy poca funcionalidad específica, y
en la mayor parte de los casos se espera que esté complementado por paquetes opcionales, o
que sea extendido a otro perfil. Se añaden al API de la CDC tres nuevos paquetes y 130 clases
adicionales, con funcionalidades variadas.
4.3.2. Personal Profile
El Personal Profile (PP) de J2ME está siendo elaborado dentro de la JSR 62 del JCP;
actualmente, está en el estado JSR Approved, esto es, en fase de definición. El PP se definirá
a partir de FP/CDC y añade una interfaz gráfica completa, con capacidades web y soporte de
applets Java.
En la actualidad no hay mucha información disponible sobre el PP. La principal motivación para
crear este perfil es la de ofrecer una vía de migración a J2ME de la tecnología PersonalJava
PDA Profile
El perfil para PDAs (PDAP) de J2ME está siendo elaborado dentro del marco de la JSR 75 del
JCP, y en la actualidad está en el estado JSR Approved, esto es, en fase de definición. PDAP
se basa en la CLDC y pretende abarcar PDAs de gama baja, tipo Palm, con una pantalla y
algún tipo de puntero (ratón o pen) y una resolución de al menos 20.000 pixels (esto es, de al
menos 200×100 pixels para un factor de forma típico 2:1).
Actualmente, no es posible dar mucha más información sobre este perfil en vías de definición.
La principal motivación para crear este perfil es la de ofrecer una vía de migración a J2ME de la
tecnología KJava.
Charla J2ME Departamento de Ciencias de la Computación
17
4.3.3. Mobile Information Device Profile
El Mobile Information Device Profile de J2ME (MIDP) ha sido desarrollado dentro de la JSR 37
del JCP, que aprobó la Final Release de la versión 1.0 el 19 de septiembre de 2000.
El MIDP se basa en CLDC/KVM y se orienta a dispositivos con las siguientes características:
• Reducida potencia computacional y memoria.
• Conectividad limitada (como la provista por las redes celulares actuales, en torno a 9600
bps).
• Capacidades gráficas muy reducidas (mínimo un display de 96×54 pixels monocromo).
• Entrada de datos alfanuméricos reducida (p.ej., como la provista por los teléfonos móviles).
Los tipos de dispositivos que se adaptan entonces al MIDP son: Teléfonos móviles del rango
de los actuales teléfonos WAP, buscas bidireccionales (two-way pagers) y PDAs de gama baja
con conectividad celular.
El MIDP proporciona APIs que soportan la siguiente funcionalidad:
• Una forma limitada de almacenamiento de datos.
• Conectividad celular basada en HTTP 1.1.
• Timers.
• Presentación de imágenes de baja resolución.
• Entrada de datos de usuario.
• Un modelo rudimentario de ciclo de vida de las aplicaciones (llamadas midlets, por
simpatía con “applet”).
Estas APIs están contenidas en los paquetes específicos javax.microedition.rms (persistencia),
javax.microedition.midlet (ciclo de vida), y javax.microedition.lcdui (interfaz de usuario).
Sun proporciona una implementación de referencia basada en un emulador de MIDP para
Windows y un entorno completo de desarrollo para este mismo sistema operativo.
Charla J2ME Departamento de Ciencias de la Computación
18
Figura: Ejemplos de aplicaciones MIDP (midlets) provistos por Sun: Selector, Sokoban,
La tecnología MIDP parece solaparse en cuanto al ámbito de aplicación con otra iniciativa de
Sun conocida como JavaPhone. La postura oficial de Sun al respecto es que JavaPhone está
orientada a dispositivos de mayores prestaciones que los que soportarán MIDP. En cualquier
caso, la comparación de requisitos para ambas tecnologías es complicada, puesto que
JavaPhone no está incluida en la arquitectura J2ME.
Se está desarrollando una nueva versión de MIDP, la llamada MIDP NG, y se prevee que
estará lista para principios del 2003.
Charla J2ME Departamento de Ciencias de la Computación
19
5 INSTALACIÓN
5.1 WINDOWS Antes de comenzar a implementar un MIDLET se precisa tener instalado un software
determinado que constituirá el entorno desarrollo J2ME. Los componentes están disponibles en
http://www.java.sun.com y son los que se presentan a continuación:
• Java 2 SDK
• Entorno de desarrollo visual (opcional)
• J2ME Wireless Kit
Java 2 SDK, es el Kit de desarrollo estándar de Java que se emplea para diseñar aplicaciones
estándares. Este elemento debe ser el primero en instalarse ya que los siguientes se apoyan
en él. Se requiere la versión 1.3 o superior que encuentra disponible en el enlace
http://java.sun.com/j2se/1.3/download-windows.html.
J2MEWT se puede ejecutar individualmente o como un componente integrado en uno de los
siguientes entornos gráficos de desarrollo:
• _ KToolBar : Es el entorno visual de desarrollo que permite la creación de MIDLETS con
J2ME. Se considera el más simple de todos los aquí mencionados ya que ni siquiera
cuenta con un editor. Para incluir los fuentes editados con otro programa se debe haber
creado un proyecto desde KToolBar,
La herramienta crea la siguiente estructura de directorios dentro del proyecto.
En el directorio src se deben incluir los fuentes para que KToolBar los pueda compilar, pre-
verificar y posteriormente emular.
Charla J2ME Departamento de Ciencias de la Computación
20
• Forte : Java: Se debe instalar antes que las J2MEWT, éste se puede descargar de la
página http://www.cun.com/forte/ffj/buy.html. Durante la instalación hay que seleccionar
la versión de JDK que se ha instalado.
• Los requisitos hardware de Forte Java son un Pentium II a 300 MHz, 128 MB y 30 MB
de espacio en disco. Este entorno provee un entorno de desarrollo para J2SE Y J2EE.
El entorno incluye un editor de texto de GUI, un buscador de clases y un buscador de
Web. El buscador de clases proporciona una vista gráfica de las clases que contiene el
MIDLET que se está desarrollando.
Utilizando este browser se puede navegar fácilmente por los métodos y atributos de las clases,
así como analizar la clase compilada almacenada en el .JAR .
Charla J2ME Departamento de Ciencias de la Computación
21
• Code Warrior for Java: es un entorno visual que da soporte a J2ME , similar a Forte
Java, que cuenta con un editor de textos y un browser de clases. Este software se
puede adquirir en http://www.codewarrior.com/.
• Jbuilder Handheld Express: presenta las mismas opciones que Forte Java y Code
Warrior, soporta el entorno de desarrollo J2ME pero sólo para Palms, aunque se
espera que en breve se presente la versión que da soporte a móviles y agendas
personales. La página en la que se puede adquirir el software y obtener más
información es http://www.inprise.com/jbuilder/hhe/ .
J2ME Wireless Kit disponible para dos plataformas: Sun Solaris y Microsoft Windows, se puede
descargar en http://java.sun.com/ products/j2mewtoolkit/ download.html . A continuación se va
a comentar la instalación en Windows.
La versión Windows de la herramienta requiere un mínimo de 64MB y un espacio en disco de
15MB.
Charla J2ME Departamento de Ciencias de la Computación
22
Se deben haber llevado a cabo los pasos anteriores, ya que si en la instalación se detecta que
no existe una versión de JDK no se permite continuar con la instalación. El entorno de
Charla J2ME Departamento de Ciencias de la Computación
23
desarrollo es opcional. Si se desea trabajar con un entorno de desarrollo no se debe
seleccionar la opción de “Integrated”, sino la de “Stand Alone”.
Una vez completada la instalación se debe asegurar que todo está correctamente instalado.
Desde el promt de DOS vaya al directorio J2MEWTK_DIR\apps\ example\bin\, luego verá que
existe un fichero run.bat, ejecútelo y si la instalación tuvo éxito verá la pantalla de inicio de la
aplicación ejemplo que incluye el paquete.
Ahora ya está todo listo para comenzar.
6 UN PRIMER EJEMPLO Una vez superada la fase de instalación llegamos a la fase de creación de un primer programa.
Para ello basta disponer de un editor de texto cualquiera en el que se irá escribiendo el código
fuente que compilaremos bien desde el interfaz gráfico que el Wireless Toolkit ofrece o desde
la propia línea de comandos.
A continuación se detallan los pasos para hacer funcionar nuestro “primer programa”.
1.- Escribir el código fuente del programa, en este caso va a ser el HolaMundo.java.
Charla J2ME Departamento de Ciencias de la Computación
24
Charla J2ME Departamento de Ciencias de la Computación
25
Esta clase hereda de la clase MIDLET. En el constructor se capturan las características del
display, se crea una instancia de la clase Form , StringItem y del Comando que me permite
salir. Luego se añade la cadena y el comando de salida al formulario y se incluye el capturador
de eventos del comando, éste tiene una acción asociada que se ejecutará al pulsar sobre esta
opción.
2.- Compilar desde la línea de comandos:
C:\c:\jdk1.3\bin\javac -g:none
-bootclasspath %SUNJ2MEHOME%\lib\midpapi.zip
-classpath %SUNJ2MEHOME%\lib\kvem.jar
HolaMundo.java
Al utilizar el compilador de J2SE para compilar el ejemplo es necesario indicar de alguna
manera que las librerías CLDC y MIDP se encuentran en un lugar diferente. Esto se hace
mediante la opción –bootclasspath.
La opción –g:none se ha empleado para desactivar la posibilidad de incluir información en la
depuración, haciendo de este modo los ficheros .class más pequeños.
3.- Preverificar Cuando se trabaja con J2SE la máquina virtual Java (JVM) lleva a cabo un proceso de
verificación en tiempo de ejecución. Esto ocupa ciertos recursos que en dispositivos
inalámbricos son relativamente escasos. Debido a las restricciones de estos dispositivos se ha
creado en J2ME un proceso denominado preverification consistente en llevar a cabo parte de la
verificación de la KVM off-line, el resto será llevado a cabo como una verificación normal.
El comando utilizado es el siguiente:
C:\>%SUNJ2MEHOME%\bin\preverify.exe -classpath %SUNJ2MEHOME%\lib\midpapi.zip
-d c:\Ejemplos c:\Ejemplos
4.- Crear el fichero .jar
El siguiente paso consiste en empaquetar el Midlet en un MidletSuite, que es un simple fichero
.jar. Esto es un requerimiento por parte de muchos dispositivos MIDP. Para realizar este
proceso JDK1.3 dispone de la utilidad jar para archivar y comprimir ficheros .class en un
paquete.
C:\>c:\JDK1.3\bin\jar cmf MANIFIESTO.MF HolaMundo.jar HolaMundo.class
5.- Ejecutar el Midlet
Una vez dispuesto el Midlet dentro de un paquete llega la fase de ejecución. Para simplificar la
línea de comandos establecemos en primer lugar las variables de entorno necesarias.
C:\>set CODEPATH=c:\Ejemplos
C:\>set CLASSPATH=%SUNJ2MEHOME%\lib\kvem.jar;%SUNJ2MEHOME%\lib\kenv.zip;
%SUNJ2MEHOME%\lib\lime.jar;%CODEPATH%
Charla J2ME Departamento de Ciencias de la Computación
26
A continuación se lanza el emulador para ejecutar el programa:
C:\c:\jdk1.3\bin\java.exe -Dkvem.home=%SUNJ2MEHOME%
-classpath %CLASSPATH% com.sun.kvem.midp.Main DefaultGrayPhone
-descriptor HolaMundo.jad
Charla J2ME Departamento de Ciencias de la Computación
27
Charla J2ME Departamento de Ciencias de la Computación
28
El resultado obtenido es el siguiente:
Finalmente se muestra un esquema de las fases anteriores
Charla J2ME Departamento de Ciencias de la Computación
29
7 PAQUETES Y CLASES PRINCIPALES A lo largo de este apartado se comentan los paquetes lcdui y midlet así como sus clases más
importantes, siendo el resto explicados en apartados independientes.
Los principales paquetes de J2ME son los siguientes:
• javax.microediton.lcdui
• javax.microediton.midlet
• javax.microediton.rms
• javax.microediton.io
Se incluye una breve descripción de ciertos métodos en los casos que se considere relevante,
ya que no hay que perder de vista que el objetivo de este documento es iniciar, no ilustrar de
forma detallada, con lo que si en algún momento desea información más concreta remítase a la
ayuda online del perfil MIDP.
7.1 JAVAX.MICROEDITON.MIDLET
Un MIDlet es una aplicación de MIDP. La aplicación debe heredar de esta clase para que le
permita gestionar el control del software.
Un MIDLET tiene 3 estados que son activo, pasivo y destruido, éstos se corresponden con los
siguientes métodos:
• startApp( )- La aplicación inicialmente se encuentra en el estado “pausa”.A este método se
le puede llamar varias veces si entre medias se llama al método pauseApp()
• destroyApp( )- Mediante este método, la aplicación libera recursos.
• pauseApp( ) - Este método permite intercambiar el MIDLET que se está ejecutando,
pasándolo de activo a pasivo.
Charla J2ME Departamento de Ciencias de la Computación
30
El administrador del entorno de ejecución de las aplicaciones es el que llama directamente a
estos métodos, ya que un MIDLET no cuenta con el método “main”.
El método de esta clase permite al gestor software de la aplicación crear, iniciar, pasar al
estado de pausa y destruir el MIDlet. Un MIDlet es el conjunto de clases diseñadas para ser
ejecutadas y controladas por la aplicación vía la interfaz. Se pueden tener varios MIDlets a la
vez, y seleccionar cual está activo en un tiempo concreto llamando al metodo startApp( ) y
ponerlo en pausa con la llamada a otro método, el pauseApp().
7.2 JAVAX.MICROEDTION.LCDUI
En el paquete javax.microedtion.lcdui se encuentran las clases que nos permiten desarrollar
una interfaz de usuario.
La clase pública Display representa el gestor de las entradas y salidas del dispositivo del
sistema. Por cada MIDlet se crea una instancia de Display y la aplicación hace referencia a
esta instancia con la llamada al método getDisplay(). La aplicación llama a este método desde
startApp(). La clase Displayable es una superclase de todas las pantallas que se pueden
poner en el Display.
Charla J2ME Departamento de Ciencias de la Computación
31
La clase Displayable tiene dos descendientes directos , Screen y Canvas.
La principal abstracción de la interfaz de usuario de MIDP es la pantalla, instancia de la clase
Screen. Una pantalla es un objeto que encapsula las especificaciones gráficas del dispositivo.
Este objeto captura todos los eventos que tienen lugar cuando el usuario está navegando por
su pantalla.
La aplicación puede cambiar de pantalla invocando al método Display.setCurrent (Displayable).
Esta clase presenta la posibilidad de incluir un título para la pantalla y un Ticker, para ello
cuenta con los métodos getTitle(), setTitle(String), getTicker(), setTicker(Ticker).
Para incluir elementos (deben ser del tipo Item) dentro de una pantalla hace falta un
contenedor, que viene representado por la clase Form.
Los métodos principales de esta clase, que son los que permiten trabajar con Items, realizan
funciones tales como la inserción, borrado y obtención de un Item.
Se presentan a continuación:
• int append(Item elemento)
• void insert(int index,Item elemento)
• get(Item)
• set(int index, Item elemento)
• delete(int index)
Otro elemento que se puede incluir en un objeto Screen es un mensaje informativo para el
usuario, teniendo la posibilidad de definir la duración del mismo en pantalla, esto se consigue
instanciando la clase Alert.
Charla J2ME Departamento de Ciencias de la Computación
32
Alert(String titulo,String texto, Image imagen, AlertType a)
El primer parámetro que se incluye en el constructor de esta clase es el título que se asocia al
mensaje a visualizar. En el parámetro texto se incluye el contenido a mostrar por pantalla, el
mensaje propiamente dicho. El parámetro imagen es la imagen que se va a incluir en el
mensaje, aunque se puede obviar poniéndolo a nulo. Por último el parámetro AlertType indica
el tipo al que corresponde este mensaje, éstos pueden ser:
• Alarm
• Confirmation
• Error
• Info
• Warning
El método más destacable de esta clase es el que permite determinar el tiempo que
permanecerá en pantalla el mensaje que es setTimeout(int time). A continuación se muestra como crear un objeto Alert, su asignación de tiempo y la
visualización en pantalla.
List(String titulo,int tipolista,String[] Elementos, Image[] imágenes) Los elementos que se van a incluir en la lista así como las imágenes que se relacionan con los
mismos se pasan al método como un array.
A continuación se presenta una clase que crea una lista y la inicializa con los valores "Opcion
A","Opcion B","Opcion C".
Charla J2ME Departamento de Ciencias de la Computación
33
Charla J2ME Departamento de Ciencias de la Computación
34
La clase TextBox implementa un componente de texto que rellena toda la pantalla. El
constructor nos permite incluir el título, un texto inicial, el tamaño máximo de caracteres que se
pueden incluir en ese TextBox, así como las restricciones del tipo de datos que se pueden
incluir.
Las restricciones son las siguientes:
• ANY - no impone restricciones en el tipo de texto a incluir
• EMAILATOR - sólo se permite incluir direcciones de e-mail
• NUMERIC – los datos han de ser de tipo numérico
• PASSWORD – este tipo enmascara los caracteres que se introducen
• PHONENUMBER – permite incluir exclusivamente números de teléfono
• URL – permite la inserción de URLs
En el API de MIDP también están incluidos los componentes que derivan de la clase Item y
ChoiceGroup.
Charla J2ME Departamento de Ciencias de la Computación
35
La clase StringItem representa un elemento que contiene una cadena de texto, y cuenta con
dos de métodos para coger y devolver el valor de la cadena.
Para representar imágenes se cuenta con la clase ImageItem.
A continuación se presenta un ejemplo en el que se trabaja con la clase StringItem e
ImageItem. Primero se crean y se inicializan la pantalla, el formulario, los comandos y se crea
un elemento StringItem a cuyo constructor se le pasa la cadena que contiene, en este caso
“Bienvenido”. A continuación se crea una imagen indicando dónde se encuentra y
posteriormente se le pasa al constructor de ImageItem, junto con la ubicación que se quiere
que ocupe en la pantalla. Ya para finalizar se añade el objeto frase y dibujito, ambas instancias
de las clases StringItem e ImageItem, al formulario mediante la invocación al método
append(Item).
TextField presenta una ventana de texto que se incluye en un formulario. A diferencia de la
clase TextBox, se puede añadir a un formulario junto con otros elementos y no ocupa toda la
pantalla.
Este ejemplo se va a comentar a la vez que se muestra el código. Dentro de la clase que se ha
creado se define un elemento de tipo Form y otro de tipo TextField y se inicializan en el
constructor.
En el caso del TextField, se indica el titulo que queremos que aparezca en el TextField, el valor
inicial que en este caso es nulo, la restricciones de los tipos de datos que se admiten en este
elemento, son las mismas que las de TextBox y en este caso se indica que sólo se admiten
datos de tipo numérico.
Ahora ya solo queda añadírselo al formulario y para ello lo hacemos como se muestra a Continuación
DateField es un componente editable que presenta información de tipo fecha y hora en un
formulario. En el constructor se añade la etiqueta que se le asigna y el modo que viene definido
por unas constantes que son:
• DATE – Tipos de datos de fecha
• TIME – para horas
• DATE_TIME – para horas y fechas
La Clase Gauge implementa un gráfico de barras para visualizar valores representados en
rangos de porcentajes.
La clase ChoiceGroup es como la de JDK, representa una lista de elementos que el usuario
puede seleccionar y que cada uno de ellos tiene una acción asociada.
Charla J2ME Departamento de Ciencias de la Computación
36
Una vez comentada la clase Screen ,se dará una breve descripción de la clase Canvas y
Graphics ya que no presentan ninguna diferencia sobre las de JDK.
La clases Canvas se emplea para las aplicaciones en las que se necesita capturar eventos y
realizar llamadas gráficas para dibujar en el display. Esta clase es intercambiable con la clase
Screen, por ejemplo en un formulario se puede incluir un elemento List y que la opción
seleccionada realice un dibujo, utilizando para ello la clase Canvas.
Para dibujar cualquier elemento es imprescindible invocar al método paint(Graphics dibujo) de
la clase Canvas. El objeto Graphics define una región que se considera inválida, con la llamada
al método paint() se consigue que se pinten todos los pixels de esa región.
La clase Graphics provee la capacidad de renderizar figuras geométricas 2D, permite dibujar
textos , imágenes, líneas, rectángulos y arcos, para ello cuenta con los métodos:
• drawString()
• drawImage (Image img, int x, int y, int anchor)
• drawLine(int x1, int y1, int x2, int y2)
• drawRect(int x, int y, int width, int height)
• drawRoundRect(int x, int y, int width, int height, int arcWidth, int arcHeight)
• drawArc(int x, int y, int width, int height, int startAngle, int arcAngle)
Los rectángulos y los arcos se pueden rellenar con la llamada al método fillRect(int x, int y, int
width, int height) y fillArc(int x, int y, int width, int height, int startAngle, int arcAngle).
7.3 ALMACENAMIENTO DE DATOS El almacenamiento y recuperación de datos de forma persistente es una característica propia
de prácticamente todos los lenguajes de programación.
J2ME MIDP define una simple base de datos de registros denominada record management
system (RMS) con el objetivo de poder almacenar información una vez que el MIDlet finalice.
La unidad de almacenamiento básica dentro de RMS es el record que es almacenado en una
base de datos especial denominada record store. Un record (registro) como su nombre indica
es un simple array de bytes, mientras que un record store es un fichero binario que contiene
una colección de registros.
El API empleado para la creación y manejo de estos registros es descrito en el paquete
javax.microedition.rms; este paquete define dos clases, tres interfaces2 y cinco excepciones.
RecordStore, RecordEnumeration
Charla J2ME Departamento de Ciencias de la Computación
37
RecordComparator, RecordFilter, RecordListener
InvalidRecordIDException, RecordStoreException, RecordStoreFullException,
RecordStoreNotFoundException, RecordStoreNotOpenException.
A continuación se describen las clases disponibles en el API así como sus funciones de manejo
básicas.
RecordStore
Algunas de las normas básicas a la hora de crear un RecordStore son las siguientes:
• Los nombres no deben superar los 32 caracteres, cabe mencionar que se distingue entre
mayúsculas y minúsculas.
• Dentro de un MIDlet suite no deben existir dos record store con el mismo nombre
• Los RecordStores creados dentro de un MIDlet suite no son accesibles a otros.
Las funciones básicas de manejo de record store se muestran a continuación:
. openRecordStore: abre un record store existente, en caso contrario crea uno nuevo.
Ej. RecordStore fichero = null;
fichero = RecordStore.openRecordStore("fichero_prueba",true);
. closeRecordStore: cierra un record store
Ej. fichero.closeRecordStore();
• deleteRecordStore: borra un record store
• getName: obtiene el nombre de un record store
• getNumRecords: obtiene el número de registros dentro de un record store
Existen una serie de métodos adicionales para la obtención de la información de cabecera
sobre el record store, las más empleadas son: getLastModified, getNextRecordID,
getNumRecords, getVersion. Es posible asimismo obtener otros tipos de información sobre el
record store, esta información no está disponible en la cabecera, pero se puede acceder a ella
mediante implementación, para ello se dispone de los métodos: getSizeAvailable, getSize,
listRecordStores. Este último método merece mención especial ya que ofrece la posibilidad de
obtener un array con los nombres de todos los record stores que pertenecen a un MIDlet suite.
Con respecto al manejo de registros se dispone de los siguientes métodos:
Charla J2ME Departamento de Ciencias de la Computación
38
• addRecord: añade un nuevo registro, éste debe encontrarse como un array de bytes,
el valor devuelto por esta función es un entero denominado record ID
• getRecord: se obtienen los datos almacenados en un determinado registro
• setRecord: este método se emplea para establecer los datos de un registro.
• deleteRecord: eliminar un registro de un record store
Cada vez que se crea un nuevo registro en un fichero se le asigna un identificador único dentro
del mismo, record ID, éste será utilizado para localizarle dentro del fichero de manera única,
una vez eliminado un registro, este permanece a NULL, su identificador con.
Por último comentar que una opción interesante a la hora de navegar entre los registros, es la
clase RecordEnumeration que ofrece las siguientes funciones: hasNextElement,
hasPreviousElement, nextRecord, nextRecordId, numRecords, previousRecord,
previousRecordId, rebuild y reset.
7.4 COMUNICACIONES DE RED MEDIANTE J2ME MIDP La capacidad de movilidad y conectividad de los dispositivos móviles quedaría mermada si no
se dispusiese de un mecanismo para poder acceder a datos remotos y redes corporativas, en
resumen, Internet.
El funcionamiento de red en J2ME tiene que ser muy flexible para soportar una gran variedad
de dispositivos, para ello se introduce un nuevo concepto, "marco de conexión general"
consistente en abstraer el funcionamiento de red y los ficheros de entrada/salida.
Todas las clases e interfaces se encuentran en el paquete javax.microedition.io. J2ME
soporta las siguientes formas de comunicación:
• HTTP
• Sockets
• Datagramas
• Puerto serie
• Fichero
Charla J2ME Departamento de Ciencias de la Computación
39
Charla J2ME Departamento de Ciencias de la Computación
40
Todas estas formas de comunicación son creadas mediante el método Connector.open(), al
que se le especificará el tipo de comunicación.
static Connection open(String connectString, int mode, boolean timeouts)
En los ejemplos anteriores se está creando en primer lugar una comunicación http, a
continuación mediante datagramas para finalmente llevar a cabo una comunicación serie. En
estos ejemplos no se ha especificado ninguno de los dos parámetros posibles: modo y timeout.
El parámetro mode permite seleccionar el tipo de acceso, existen tres posiblidades: READ,
READ_WRITE y WRITE. El valor tomado por defecto en caso de que no se seleccione ningún
modo es de lectura/escritura. Hay que tener en cuenta que si el modo de acceso no es
soportado por el protocolo, se lanza una IllegalArgumentException. En caso de que el
parámetro timeouts esté a true genera una excepción de tipo InterruptedIOException, indicando
que se ha superado el tiempo de espera en la apertura de la comunicación.
Cabe destacar que de todas las implementaciones MIDP existentes, MotoSDK es la única que
soporta los tres protocolos de red (http, udp, tcp/ip), aunque el J2ME Gíreles Toolkit de Sun
sólo soporta comunicación http, existe una característica no documentada que permite ejecutar
un socket o programa que utilice udp estableciendo para ello la variable de entorno
ENABLE_CLDC_PROTOCOLS = INTUITIVE_TOOLKIT.
Charla J2ME Departamento de Ciencias de la Computación
41
8 Bibliografía • [SAMS 2001] Yu Feng y Dr. Jun Zhu. “Wireless Java Programming with J2ME”, Junio 2001.
• [SAMS] Michael Morrison. “Wirele ss Java with J2ME in 21 Days”, Junio 2001.
• Application for Mobile Information Device. [White Paper]
• J2ME Technology for creating Mobile Devices. [White Paper]
• CLDC Specification. Version 1.0a
• J2ME Wireless Toolkit User’s Guide. Version 1.0
• Mobile Information Device Profile (JSR-37). Draft 0.9
9 Direcciones de Interés http://www.java.sun.com
http://java.sun.com/j2se/1.3/download-windows.html
http://www.cun.com/forte/ffj/buy.html
http://www.codewarrior.com/
http://www.inprise.com/jbuilder/hhe/
http://java.sun.com/ products/j2mewtoolkit/ download.html
Charla J2ME Departamento de Ciencias de la Computación
42