1.2. Origen y breve descripción de J2ME.

 Java comenzó su andadura como lenguaje de programación a mediados de la década de los noventa del siglo pasado. Originalmente fue concebido como un lenguaje para poder programar un amplio rango de aparatos electrónicos con capacidades de conectividad a partir de otro dispositivo del tipo de un asistente personal digital.  El espíritu inicial era realizar una adaptación de C++, tomando lo mejor de él, y que se adecuara a las restrictivas condiciones ofrecidas por los chips de los aparatos a programar, teniendo como principales objetivos la fiabilidad y la seguridad. Además, se intentaba que una vez que fuera desarrollado el programa se pudiera ejecutar en varios tipos diferentes de aparatos sin necesidad de volver a compilarlo.

    Con la llegada de Internet y los primeros navegadores para la World Wide Web, los desarrolladores de Java se dieron cuenta de su aplicabilidad a este nuevo medio, naciendo así la tecnología de los applets de Java, que permite, de nuevo, poder desarrollar una aplicación una única vez y ejecutarla tantas veces cómo se desee en un conjunto heterogéneo de ordenadores conectados a la Red.

    Así, en Mayo de 1995 Sun lanzó oficialmente Java al mercado con el Java Development Kit (JDK) en su versión 1.02., es decir, un entorno de desarrollo y una implementación del lenguaje Java.  Este JDK fue ampliado  y mejorado (se subsanaron algunos problemas), dando lugar a la versión 1.1. De ahí se pasó a la siguiente , el SDK 1.2 (Software Development Kit), la cual entre otras muchas características incluye una colección nueva de clases y de elementos para el diseño de interfaces gráficos. Surgieron seguidamente la versión, SDK 1.3 y, finalmente y actual, el SDK 1.4.

    Cabe destacar en este punto la distinción entre la plataforma Java y las diferentes versiones JDK y SDK. El primero se refiere al lenguaje abstracto y a la especificación del mismo. Los segundos son, como ya hemos dicho, implementaciones que ha realizado Sun, así como un conjunto de herramientas que ofrece esta empresa para facilitar el desarrollo de aplicaciones.  Si nos fijamos en la plataforma, sólo ha habido dos versiones principales Java 1 y Java 2.  La segunda se introdujo coincidiendo con la llegada de el SDK 1.2.

    Y finalmente, ya en 1999, se vuelve a cerrar el ciclo que lleva a Sun a desarrollar una versión de Java especialmente diseñada para dispositivos móviles: Java 2 Micro Edition, basada en una máquina virtual llamada KVM.  Este primera versión sólo contenía una única máquina virtual y un único API (inicialmente diseñados para Palm OS), hecho que puso de manifiesto la insuficiencia de esta solución para la gran variedad de dispositivos diferentes. De esta forma, en el año 2000, nació la primera versión de una configuración, es decir, el Connected Limited Device Configuration (J2ME CLDC 1.0).  Una configuración ofrece el API básico para programar dispositivos, aunque no aporta todas las clases necesarias para desarrollar una aplicación completa.  Por tanto, la primera configuración no tenía las herramientas necesarias para permitir a los desarrolladores escribir programas para el dispositivo Palm.  En julio de 2000 nació la primera implementación de un perfil, concretamente el llamado Mobile Information Device Profile (MIDP), aunque no estaba destinado a PDAs sino a teléfonos móviles y a paginadores.  A partir de este primer perfil, J2ME fue considerablemente aceptado por la comunidad de desarrolladores de dispositivos móviles, expandiéndose a una gran velocidad hasta nuestros días.

Por tanto, actualmente, la versión 2 de Java de Sun Microsystem contiene tres ediciones distintas:

• Standard Edition (J2SE): entorno básico de Java. Ofrece un conjunto de clases  y APIs (Application Program Interface - Interfaz para Programas de Aplicación) que permiten desarrollar  y ejecutar aplicaciones clientes y servidoras, así como programas que se ejecuten en navegadores (applets).

• Enterprise Edition (J2EE): agrupa APIs Java y tecnologías que no están basadas en este lenguaje. Se aconseja para el desarrollo de aplicaciones distribuidas.

• Micro Edition (J2ME): específicamente diseñado para desarrollar aplicaciones para dispositivos embebidos y electrónicos, que tienen características peculiares ya que dos ediciones anteriores no son adecuadas para su utilización con ellos. Éstos dispositivos normalmente tienen una potencia limitada, posibilidad de conectividad a una red (normalmente sin cables) y poseen interfaces gráficos.

En la siguiente ilustración podemos ver gráficamente la relación entre cada una de las ediciones de Java y los tipos de dispositivos con que se podrían programar:

Algunas diferencias que ofrece J2ME con respecto a J2EE, directamente derivadas de las condiciones en las que se va a hacer uso de esta edición, son las siguientes:

• Tipos de datos: J2ME no incluye los tipos float y double, ya que la mayoría de los dispositivos CLDC no tienen unidad de coma flotante debido fundamentalmente a que es una operación muy costosa.
• Preverificación: La verificación del código en J2ME se hace fuera del dispositivo, con objeto de reducir la carga de la máquina.
• Inclusión de los ficheros "descriptor" y "manifiesto" al empaquetar ficheros J2ME, conteniendo información sobre las aplicaciones que incluyen.
• Nueva biblioteca gráfica adaptada a los dispositivos con memorias de poco tamaño y pantallas también pequeñas.
• No existe un método main como entrada para la ejecución de la función. Éste se sustituye por el método "start app".
• La recolección de basura se hace de manera manual y no automática como en el J2EE. Esta decisión se toma así para reducir la utilización de la memoria.

La arquitectura de J2ME define configuraciones (configurations), perfiles (profiles) y paquetes opcionales, como elementos básicos para desarrollar aplicaciones que se ajustan a las características de un amplio rango de dispositivos. Cada combinación se optimiza según la memoria, la capacidad de procesamiento y de entrada/salida de una categoría específica de dispositivos.

Las configuraciones están compuestas por una máquina virtual y un conjunto mínimo de bibliotecas de clases, las cuales serían un mínimo denominador común con que contarán todos los dispositivos de una configuración dada; o lo que es lo mismo ofrecen la funcionalidad para un rango particular de dispositivos con características comunes.  Existen dos configuraciones actualmente: Connected Limited Device Configuration (CLDC) y Connected Device Configuration (CDC). La primera es la más pequeña de las dos, designada para dispositivos con conexiones de red intermitentes, un procesador lento y memoria limitada (teléfonos móviles y PDAs, por ejemplo), es decir, CPUs de 16 o 32 bits y una memoria mínima de 128 a 256 Kbytes de memoria disponible para la implementación de Java y las aplicaciones. CLDC está estrechamente asociado a lo que se conoce como "Java inalámbrico" (Wireless Java), es decir la posibilidad de que teléfonos móviles puedan descargarse  aplicaciones Java, conocidas como MIDlets. Por otro lado, CDC está orientado a dispositivos con más memoria, procesadores más rápidos y un ancho de banda mayor (por ejemplo, TV set-top boxes), es decir, los aparatos que están entre los que trata CLDC y los ordenadores de sobremesa. Esta configuración incluye una máquina virtual completa y un subconjunto de J2SE mayor.  Los dispositivos a los cuales se dirige esta configuración tienen CPUs de 32 bits y como mínimo 32 Mbytes de memoria para la plataforma y las aplicaciones.

En la siguiente figura podemos ver un cómo se relacionan las dos configuraciones existentes y también con respecto a J2SE.

Las especificaciones de las configuraciones no indican ningún tipo de implementación de la máquina virtual, por lo que cada cual puede crear sus propios entornos de ejecución. Los que ha desarrollado Sun son Kilobyte Virtual Machine (KVM) para CLDC y C Virtual Machine (CVM).

En este curso estudiaremos de manera más detallada la configuración CLDC.

Con objeto de ofrecer un completo entorno de ejecución específico para cada categoría de dispositivo, las configuraciones de deben combinar con un conjunto de APIs de alto nivel, conocidas como perfiles, que definen el modelo de ciclo de vida de la aplicación, el interfaz de usuario y el acceso a las propiedades específicas del dispositivo. Algunos de los perfiles existentes son (varios todavía en la etapa de definición):

• Mobile Information Device Profile (MIDP). Diseñado para teléfonos móviles y PDAs, incluye la interfaz de usuario, conectividad de red, almacenamiento local de datos y gestión de aplicaciones. Combinado con CLDC, MIDP aporta un entorno de ejecución para Java que minimiza los consumos de memoria y de procesador. 
• Foundation Profile (FP). Este perfil es el de nivel más bajo asociado a CDC, ya que los perfiles CDC pueden ser vistos como capas que se añaden a  para proveer funcionalidades a los diferentes dispositivos. FP suministra una implementación de CDC con capacidades de acceso a red que se utiliza para aplicaciones embebidas en alto grado y sin interfaz de usuario.
• Personal Profile (PP) es un perfil diseñado expresamente para dispositivos con un interfaz gráfico completo y con posibilidad de ejecución de applets. Incluye además las bibliotecas del Abstract Windows Toolkit (AWT). Añade, por tanto, un interfaz de usuario básico a FP.
• Personal Basis Profile (PBP) es un subconjunto de PP que suministra un entorno para dispositivos que se puedan conectar a una red y que dispongan de un interfaz un poco más desarrollado que aquellos que posean los dispositivos donde PP va dirigido.
• PDA Profile (PDAP) es similar al MIDP pero diseñado para PDAs que tengan mejores pantallas y más memoria de los teléfonos móviles. 
• Game Profile (GP) ofrece la plataforma para escribir juegos en dispositivos CDC.

Actualmente el perfil más utilizado es MIDP, que será el que estudiemos con profundidad en este curso.

En el siguiente gráfico podemos ver un esquema modular con las diferentes configuraciones, perfiles y máquinas virtuales:

Las aplicaciones desarrolladas para un determinado perfil serán portables a cualquier dispositivo que soporte ese perfil. Cabe destacar también que un mismo dispositivo puede soportar varios perfiles y que sobre una configuración también pueden residir diversos perfiles.