La configuración cldc imprimible

1 Programación de dispositivos móviles Semana 2

LA CONFIGURACIÓN CLDC

Ya vimos de manera general la configuración CLDC, aquella en la que se

monta el perfil MIDP para hacer los MIDlets. Sin embargo, debido a su uso, es

necesario entenderla a profundidad la configuración, sus partes, su estructura y

la diferencia que existe entre ellas y otras plataformas.

De que se encarga exactamente la configuración CLCD. Esta configuración

tiene varias funciones (que estudiaremos a fondo en esta sección), entre las

cuales se destacan:

El lenguaje JAVA y las características particulares de la máquina virtual

en la que se corre: Características que se han mantenido y aquellas que

se han tenido que omitir en la configuración CLDC

Las librerías del Core de JAVA (Las librerías del Core de java son

“Java.lang” y “java.util”): Que librerías han sido heredadas por la

configuración CLDC y cuales son propias de la misma

Entrada y salida de información: Que entradas y qué salidas se han

mantenido en la configuración.

Comunicaciones OTA: Soportes de protocolos de comunicación por la

configuración.

Seguridad en el dispositivo: Modelo de seguridad proporcionado por la

configuración CLDC

Internacionalización: Variación idiomática

Veamos entonces cada uno de estos elementos a profundidad, junto con otros

que definen la configuración CLDC.


Objetivos de la configuración CLDC y requerimientos de la misma:

JAVA es un lenguaje muy extenso. Puede manejar bases de datos,

documentos, animaciones, simulaciones, redes empresariales e incluso

dispositivos móviles. Debido a lo extenso de su repertorio, debemos restringir

las características de funcionamiento del mismo. Esta restricción la hacemos a

través de una configuración. La configuración CLDC determina un conjunto de

características, que el lenguaje JAVA soporta, y que caracterizan un

determinado conjunto de dispositivos. Restringe el trabajo en red, la seguridad

del dispositivo, las APIs de programación, etc. Es como tener una masa para

galletas, y usar un molde para hacer galletas de determinada forma. Todas las

galletas que se puedan hacer con ese molde están caracterizadas por ser de la

misma masa (JAVA), pero todas tienen la misma forma porque fueron cortadas

con el mismo molde (Configuración).

Este molde, esta forma, es la base para diversos perfiles. Un perfil define un

conjunto más particular aún de características que hacen que el dispositivo se

pueda dirigir a un mercado más especializado. Si bien existen muchos perfiles1,

el perfil que nos interesa precisamente es el MIDP, porque este es el que

define las características de lo que es un dispositivo móvil de bajas

prestaciones y alta movilidad. Es como si las galletas sacadas por el mismo

molde, pudieran unas bañarse de chocolate, las otras de vainilla, las otras de

azúcar… y cada una de esas cubiertas fuera un perfil. En términos JAVA, un

celular puede verse como una galleta, en forma de bota, de chocolate; un

blacberry como una galleta, en forma de bota, de vainilla; un PC es una galleta,

en forma de círculo, con mora… etc. Teniendo esto mucho más claro, veamos

los objetivos específicos de la configuración:

1 Estas configuraciones se pueden encontrar en el documento “Configurations and Profiles

Architecture Specification, Java 2 Platform Micro Edition (J2ME), Sun Microsystems, Inc”


Objetivos

El objetivo principal de la configuración CLDC es, como se dijo ahora, servir

como un modelo para un determinado tipo de componentes. En este caso

particular, trata de definir un estándar para dispositivos de reducido tamaño

conectados a una red y con recursos limitados. Pero decir “recursos limitados”

es muy ambiguo. ¿Con respecto a qué? Se define un recurso como limitado

cuando es 10 veces menor que los recursos de un computador de escritorio

promedio. La configuración CLDC va más allá, definiendo un conjunto de

características que debe tener el dispositivo. Estas características son las

siguientes:

o Entre 160 y 512 Kb de memoria total disponible para la

localización de la plataforma JAVA

o Procesador de datos de 16 o 32 bits

o Bajo consumo energético, generalmente brindado por una

batería.

o Conectividad inalámbrica (recordemos que debe tener soporte

OTA) con conexión intermitente, y ancho de banda (“tamaño” del

canal de comunicación) rondando los 9600bps

En este rango de dispositivos, entran PDAs sencillas, celulares de cantidad de

generaciones, e incluso algunos GPS y Beepers. La configuración definida

define entonces los elementos mínimos necesarios para dispositivos

conectados pequeños. Si los dispositivos móviles usan herramientas de texto

en pantalla, se implementan las librerías requeridas para eso. Sin embargo, los

dispositivos móviles raras veces se usan para manejar bases de datos o nubes

de información, por lo que estas librerías no se incorporan en la respectiva

configuración. Sin embargo, aparte de definir un estándar, existen otros

objetivos que se ven a continuación:


Extensibilidad: Sabemos que nuestro dispositivo móvil tiene

conectividad, y sabemos que posee una KVM montada, junto con una

configuración CLDC. Esto permite que pueda bajar aplicaciones JAVA

de la red y, a través de la AMS instalarlas. Una sola aplicación en la red,

puede ser descargada por infinidad de dispositivos móviles. Estos

dispositivos móviles se comunican entre sí, intercambiando aplicaciones

y aumentando aún más la conectividad y el intercambio de información.

Estas aplicaciones pueden venir de diversidad de partes, de empresas

diversas, de operadores, incluso de usuarios, y empezaron a distribuirse

y compartirse entre sí, aumentando el alcance y la utilidad de los

dispositivos móviles. A esta característica la llamamos “extensibilidad”.

JAVA, y sobre todo, CLDC hace parte entonces de los esfuerzos que se

están llevando a cabo para aumentar la extensibilidad de los dispositivos

móviles

Desarrollo de terceras partes: Esto es una consecuencia de la

extensibilidad. Si queremos que los dispositivos sean más extensibles,

debemos darle a la configuración CLDC la posibilidad de que terceras

partes puedan programar para él. Es por esta razón que la propia

configuración debe permitir los elementos mínimos de alto nivel

necesarios para crear una abstracción para los programadores. Con esto

se intenta decir que el programador puede, y debe ser capaz de

programar cualquier aplicación, y la configuración CLDC debe servir

como un “traductor” entre sus aplicaciones y los protocolos internos de

comunicación y transferencia de archivo.


Requerimientos

Existen unos requerimientos de hardware, de software y otros basados en

la plataforma de JAVA J2ME, que son necesarios para la plataforma CLDC.

Estos los veremos a continuación:

o Requerimientos de hardware: Los requerimientos de hardware

que pide la configuración se refieren únicamente a la memoria.

Veamos que en el estándar que genera la configuración CLDC

caben muchos dispositivos, desde celulares, hasta

buscapersonas, pasando por PADs y organizadores personales,

terminales, etc. Como todas las características de estos

dispositivos móviles son muy diversas, la configuración solo

restringe el hardware en cuestiones de memoria. Para ser más

exactos, el requerimiento de memoria de estos dispositivos es el

siguiente:

128 Kb para la máquina virtual y las librerías de JAVA

32 Kb de memoria volátil para variables usadas mientras

se ejecutan las aplicaciones.

Estos rangos de memoria son dinámicos, y dependen

primordialmente del hardware del dispositivo.

o Requerimientos de software: Como lo vimos ahora, los

dispositivos móviles que entran en el perfil definido por la

configuración CLDC son muy diversos, y tanto el hardware como

el software varía enormemente. Es por esto que podemos

encontrar dispositivos con un sistema operativo complejo y

completo, que ejecute procesos multitarea y soporte hilos


(Threats, o procesos en ejecución), así como podemos encontrar

dispositivos con un rudimentario sistema operativo que no maneje

carpetas, o incluso carentes del mismo. Es por eso que los

requerimientos de software de la configuración CLDC son

mínimos. Se requiere que el dispositivo tenga un sistema

operativo rudimentario que permita ejecutar la máquina virtual de

JAVA. Con que el sistema operativo tenga una entidad de

planificación que permita ejecutar la máquina virtual, es suficiente.

o Requerimientos de J2ME: Recordemos que CLDC es una

configuración propia de J2ME. Esto significa que el propio JAVA

genera unos requerimientos sobre las especificaciones de esta

configuración, requerimientos que generan implicaciones sobre el

perfil:

Cuando hablamos de una configuración J2ME, hablamos

de un conjunto de APIs mínimas de la tecnología JAVA.

Esta configuración debe cobijar una gran cantidad de

dispositivos, de diferentes naturalezas, y a veces poco

relacionados entre sí. Para definir características

específicas de un dispositivo, de un mercado o de una

industria, se debe hacer uso de un perfil, y no de una

configuración. Esto hace entonces que un perfil sea

limitado (servir a muchos dispositivos a veces equivale a

no servir bien a ninguno de ellos), y que deba ser siempre

complementado con perfiles.

En el apartado superior se indicó que el objetivo principal

de la configuración CLDC era, aparte de definir un

estándar, generar extensibilidad entre componentes. Esto

significa que la configuración solo tiene los componentes


necesarios para garantizar esta extensibilidad, y ningún

otro elemento adicional. Esto hace que la característica

principal de un dispositivo con configuración CLDC debe

ser definida en los perfiles, y no en la propia configuración.

DIFERENCIAS DE CLDC CON J2SE

Si tenemos un dispositivo móvil con una maquina virtual montada y una

configuración CLDC activa, nos interesa que esta combinación sea lo más

compatible posible con cualquier especificación de JAVA que pueda

presentarse (recordemos que no todos los componentes de JAVA se pueden

ejecutar en todas sus versiones y en todas sus máquinas virtuales), teniendo

en cuenta las restricciones de memoria anteriormente citadas. Esto significa

que, como lo habíamos anotado anteriormente, existan diferencias entre CLDC

y J2SE. Si la J2ME es un subconjunto de JAVA, con una librería adicional,

significa que hay diferencias entre el lenguaje JAVA usado entre la J2SE y la

configuración CLDC (por las APIs propias y exclusivas de J2ME usadas en

CLDC), aparte de que algunos procesos escritos en JAVA, al ser limitada la

configuración CLDC, no pueden ser ejecutados por esta configuración. La

segunda diferencia fundamental es por la máquina virtual usada en J2SE y la

usada para soportar la configuración CLDC. Profundicemos más estas

diferencias para conocer los límites y los alcances de nuestra configuración.

1. No se soportan operaciones de punto flotante

Una operación en punto flotante, como el aprendiz debe conocer, es una

operación que permite ampliar el rango de valores operados usando varios

bits adicionales en una representación numérica para guardar un exponente

que eleva al número. Para estas operaciones, se requieren arreglos de


memoria que permitan el uso de Bytes, Words y Longs (es decir, cadenas

de 8, 16 y 32 bits definidas para un mismo carácter), pero la mayoría de

dispositivos móviles no poseen el hardware necesario para ejecutar este

tipo de operaciones (y de hecho, no las necesitan generalmente. Un celular

en muy pocas situaciones tiene como proceso prioritario la multiplicación de

2 cadenas de 8 o 16 bits). Es por esto que se ha eliminado esta

característica con respecto a su homóloga J2SE.

2. No se finalizan los objetos

Cuando intentamos finalizar un objeto, usamos las librerías de la

configuración CLDC. Estas librerías no contienen el método

Object.finalize(), por lo que no podemos finalizar objetos a través de ella

3. Manejo de errores limitados

Cuando se produce un error en JAVA, en vez de bloquearse o cerrarse (se

produce un “core” o “crash”), esta lanza una excepción que nosotros

debemos recibir para corregir el error. Si bien pueden ocurrir errores por

una gran cantidad de posibilidades (solo miremos los errores que se

producen en la instalación de un MIDlet), el conjunto de las clases de

errores que se han incluido en la CLDC es limitado, por varias razones:

a. Antes que nada, la configuración CLDC posee un subconjunto

limitado de todas las excepciones de J2SE, lo cual reduce el

manejo de estas drásticamente.

b. Una de las clases de JAVA que maneja excepciones, la clase

java.lang.error, y todas sus subclases, han sido eliminadas de la

configuración CLDC.


Estas limitaciones en el manejo de errores se dan gracias a que, cuando un

dispositivo tiene instalado una máquina virtual y una configuración, no

depende de ellas directamente para funcionar. Es decir, esta máquina y

este perfil existen para poder ejecutar aplicaciones de JAVA, mas no para

llevar a cabo procesos críticos del dispositivo. Esto hace que cada máquina

tenga su propio manejo de errores, por lo que los errores de JAVA resultan

redundantes. Además, generalmente un programador “agarra” excepciones,

mas no errores, por lo que el uso de la clase java.lang.error no se ve

necesario.

Hemos visto las diferencias que existen, en el nivel de lenguaje de JAVA, entre

la configuración CLDC y J2SE. Anteriormente habíamos dicho que las

diferencias entre estos 2 elementos se daba por sus diferencias en el lenguaje

JAVA y por diferencias entre las máquinas virtuales Ahora veremos las

diferencias que existen entre las máquinas virtuales.

Algunas características de la J2SE han sido eliminadas en la configuración

JVM/CLDC, ya que las librerías que posee esta configuración son mucho más

limitadas que las de su contraparte estándar. Y no solo por esto. Algunas de las

características eliminadas entraban en un conflicto de seguridad con el modelo

manejado por la configuración CLDC, generando problemas de seguridad. Para

tener claras cuales han sido las características eliminadas de la configuración,

procederemos a explicar cada una a continuación.

4. Java Native Interface (JNI) no implementada

La JNI, para recordarle al aprendiz, es uno de los frameworks de java que

permite interacción entre programas de JAVA y otros programas no escritos


en este lenguaje. En la configuración CLDC, la JNI no ha sido

implementada, y esto se ha producido por 2 razones fundamentales:

o Primero, cuando la JNI “permite” la interacción entre programas,

lo hace a través de “invocaciones” de métodos nativos, y los otros

programas pueden invocar también a la JNI. Vemos entonces que

estas invocaciones hacen uso de programas externos en caso de

que sea necesario. Uno de esos programas puede, por ejemplo,

ser usado para violar la seguridad del dispositivo, y el modelo de

seguridad de la CLDC es limitado. Por tanto, para eliminar esa

posibilidad, el modelo de seguridad no soporta la invocación de

métodos nativos

o La memoria de un dispositivo es muy limitada, por lo que la

implementación de la JNI se considera muy costosa en término

de recursos, para ser implementada en la misma.

5. Cargadores de clase definidos por el usuario, suprimidos.

Una máquina virtual de JAVA que tenga implementada la configuración

CLDC no permite que el usuario defina cargadores de clase. En vez de

esto, implementa un cargador de clases que no puede ser ni suprimido,

ni sustituido, ni reconfigurado por el usuario. Esto también se lleva a

cabo porque el modelo de seguridad proporcionado por la configuración

CLDC (modelo de seguridad tipo SandBox) genera esta restricción.

6. Reflexión no implementada:

¿Qué es la reflexión en JAVA? Imaginemos que pensamos sobre

nuestra vida, todas las cosas que hemos vivido, aprendido, interiorizado,

y las formas de actuar que hemos creado a lo largo de nuestra vida. En


ese momento, estamos haciendo una reflexión sobre nuestra vida. De

manera similar, JAVA reflexiona, mirando dentro de una máquina virtual

la cantidad de clases, el tipo de clases, de objetos, campos, métodos,

pilas, hilos… esta capacidad de inspección interna se ha eliminado de la

máquina virtual que soporta CLDC

7. Grupos de hilos o hilos daemon.

Un hilo se define, de manera básica, como un proceso en tiempo de

ejecución. A estos hilos también se les llama “Threads”. Los dispositivos

“multitareas” son aquellos que pueden soportar varios hilos al mismo

tiempo. Sin embargo, cada hilo pertenece a un proceso diferente. La

JVM de la configuración CLDC permite la ejecución multitareas, pero no

soporta grupos de hilos (varios hilos de un mismo proceso). Tampoco

se soportan hilos llamados “Daemon”. En el ámbito de programación, un

“daemon” o demonio, es un proceso que se ejecuta sin interfaz gráfica

que el usuario pueda observar y que lo hace sin el conocimiento del

usuario. Un hilo daemon sería el equivalente a un proceso no visible,

ejecutado en tiempo real. La máquina virtual de CLDC no permite la

ejecución de hilos daemon.

8. Referencias débiles no implementadas

La JVM/CLDC puede generar referencias a otros objetos. Algunas de

estas referencias son prioritarias para el funcionamiento de un código.

Otras de estas referencias pueden ser prescindibles, de manera que

cuando se ejecuta el recolector de basura para liberar memoria, estas

referencias pueden ser eliminadas2. Para recordarle al aprendiz, un

2 Vease el paquete java.lang.ref


recolector de basura es un proceso que permite llenar los huecos en la

pila de memoria con procesos ejecutados en tiempo real, de manera que

se recupera espacio. Digamos que la pila de memoria se llena con un

conjunto determinado de procesos. Y digamos que mientras se ejecutan

algunos procesos, otros desaparecen. La pila queda entonces de la

siguiente manera:

Vemos que los espacios en blanco son aquellos procesos que fueron

liberados, pero que la pila se encuentra llena. El recolector de basura

llena estos espacios, quedando la pila de esta manera:


Es así como se libera espacio en la pila, a través del recolector de

basura.

SEGURIDAD EN CLDC

Los dispositivos con configuración CLDC son extensibles, es decir, la extensión

de sus alcances se aumenta gracias a las aplicaciones que se ejecutan en los

mismos, combinado con la interactividad que hay entre dispositivos al

comunicarse entre sí. Estos dispositivos móviles, como nos acompañan en

todo momento, generalmente tienen información privada o confidencial. La

unión de interacción con información privada, casi nunca resulta cómoda. Es

por esto que se debe hacer gran énfasis en la seguridad de este tipo de

dispositivos. También debemos pensar en la posibilidad de que, al transmitirse

un MIDlet entre servidor y cliente, llegue íntegro y sin problemas en la

transmisión, ya que no queremos un error en tiempo de ejecución que nos

bloquee el equipo móvil, que nos sature la memoria, o que, en el peor de los

casos, comprometa nuestra información. Es por esto que se debe tener

especial cuidado en la integridad de las aplicaciones y los datos transmitidos.

¿Cuál es el modelo de seguridad usado en estos dispositivos? Es un modelo

que no es nuevo, y que se usa en aplicaciones generales de JAVA (es decir, en

applets). Este modelo de seguridad es llamado el “modelo SandBox” o el

modelo de aislamiento de procesos. Se puede decir entonces que el modelo de

seguridad de la configuración CLDC es similar al modelo usado por la J2SE

para ejecutar applets.

El modelo SandBox es un modelo que funciona como una “celda” o un “cuarto”

que aísla un proceso determinado, y le permite ser ejecutado dentro de él.

Cuando entramos a una página Web, y existe una aplicación JAVA, esta se

encuentra enmarcada en un cuadro que la contiene. Dentro, la aplicación es


funcional, pero fuera de la página, la aplicación de JAVA no puede moverse.

Este marco aísla la aplicación, funciona como una “caja de arena” para niños.

Este modelo entonces establece que solo se pueden llevar a cabo

determinadas acciones que él considera seguras. Eso significa que las

aplicaciones que se ejecutan dentro de la caja deben cumplir ciertas

condiciones:

- Cuando se ejecuta la aplicación, se verifica si los archivos de clase

JAVA son aplicaciones válidas.

- Solo las APIs autorizadas por la CLDC pueden ser ejecutadas en la

SandBox.

- La caja no permite cargar una clase que se haya definido por un usuario.

- La aplicación activa dentro de la SandBox solo puede ejecutar

características nativas internas del CLDC.

- Cuando ejecutamos una aplicación bajo una KVM, esta puede apuntar a

espacios de memoria que en un dispositivo móvil no existen. Este

proceso puede acarrear problemas serios en nuestro dispositivo, por lo

que se debe tener muy en cuenta esta característica. Para eso, el

verificador de clases se asegura en todo momento de que no hayan

referencias a posiciones no válidas de memoria. Este verificador de

clases también se encarga de observar que las clases cargadas no se

ejecuten de una manera no permitida por la configuración CLDC

LIBRERÍAS CLDC

La versatilidad de JAVA radica en la cantidad de librerías que incorpora,

convirtiéndolo en una herramienta de muy amplia gama, pues estas librerías

dan la capacidad de crear una gran cantidad de programas útiles para el

ámbito empresarial y personal. Desafortunadamente, todas estas librerías

requieren una gran cantidad de memoria (en comparación con la memoria de


un dispositivo móvil), teniendo generalmente tamaños de varios megabytes. Si

recordamos las capacidades de memoria de un dispositivo móvil que sea

arropado por a configuración CLDC, veremos que la memoria que estos

dispositivos manejan no sobrepasa generalmente los 500Kb (ni siquiera llega al

medio megabyte), por lo que es prácticamente imposible montar las librerías

estándar de J2SE y J2EE dentro de un dispositivo móvil. Acá veremos cuáles

son los objetivos generales de diseño de una librería para CLDC, cuáles son

sus objetivos generales, y que tipos de clases poseen dichas librerías.

Objetivos generales:

¿Cuál es el objetivo general del diseño de una librería JAVA para CLDC?

Creo que en este curso no nos cansaremos de comentar la limitación de

memoria que poseen los dispositivos móviles, y como dicha limitación

impone restricciones en todos los componentes y aplicaciones creadas. Con

estas limitaciones en la cabeza, creamos unas librerías completamente

básicas y fundamentales, propias para una variedad de pequeños

dispositivos. El objetivo de estas librerías es el de proporcionar un conjunto

básico de herramientas para desarrollar aplicaciones y definir perfiles para

estos pequeños dispositivos.

Compatibilidad:

Nuestro objetivo principal entre la plataforma J2SE, J2EE y la JVM con la

CLDC incluida, es garantizar la mayor compatibilidad posible entre

aplicaciones. Esto hace que las librerías de la J2ME sean un subconjunto

de las usadas en J2SE y J2EE. Por esta razón, muchas de las aplicaciones

de J2ME pueden ser ejecutadas en J2EE y J2SE, y viceversa.

Sin embargo, la memoria nos limita. Las librerías de las versiones estándar

y empresarial de JAVA están muy interconectadas entre sí. Algunos


elementos de las librerías dependen directamente de otras librerías,

haciendo que en algunos casos, querer incluir una librería obliga a la

inclusión de otras, y no nos podemos dar ese lujo. Sectores como la

seguridad, las entradas y salidas de datos, las interfaces de usuario y el

trabajo en red tienen bibliotecas fuertemente vinculadas entre sí. Esta

vinculación hace muy difícil la capacidad de crear subconjuntos de librerías,

lo que ha llevado al rediseño de algunas librerías para la configuración

CLDC, especialmente en el área de trabajo en red y de entrada y salida de

datos.

Por esta razón, podemos dividir las librerías de CLDC en 2 categorías

definidas:

- Librerías como subconjunto de las presentes en J2SE (es decir, librerías

heredadas)

- Librerías específicas de CLDC

Veamos cada una de ellas

Librerías heredadas

CLDC posee una gran cantidad de clases heredadas de la plataforma J2SE.

Para ser más específicos, hereda aproximadamente 37 clases

pertenecientes a los paquetes java.lang, java.util y java.io. Esas clases

heredadas tienen como característica ser idénticas o al menos es un

subconjunto de la clase correspondiente en J2SE. Los métodos y la

semántica trabajada en cada clase han permanecido idénticos para

mantener la compatibilidad entre plataformas. Podemos observar las clases

heredadas de J2SE en las siguientes tablas:


Librerías propias de CLDC

Memoria, memoria, memoria… La falta de memoria en los dispositivos limita

todos los procesos y aplicaciones de JAVA. En este punto, no es la

excepción. En las tablas anteriores vimos que la plataforma J2SE heredó

algunas de las clases de los paquetes java.io y java.net. Esos paquetes en

la J2SE están encargados de las operaciones de entrada y salida de datos.

Como se vio, no se pudieron heredar todas las clases, pero entre esas

clases no heredó ninguna encargada de la transferencia de ficheros, entre

otras. Esto se debe a que, como la aplicación CLDC maneja dispositivos

que en su sistema operativo no tienen la noción de fichero, lo cual hace

innecesario heredar esta característica. Otra de las clases no heredadas fue

la de comunicaciones basadas en TCP/IP presentes en el paquete java.net,

ya que no se puede asegurar que los dispositivos móviles usen este

protocolo de comunicación para interactuar con la red. Para solucionar

estos problemas, la plataforma J2ME tiene un conjunto de clases mucho

más genérico, llamado “Generic Connection Framework”, incluído en el


paquete javax.microedition.io. Estas clases se pueden observar en la

siguiente tabla:

El manejo de estas clases e interfaces es avanzado para un curso

introductorio, por lo que deben ser estudiadas por el aprendiz en otros cursos.

La configuración cldc imprimible

Technology

Transcript of La configuración cldc imprimible