La configuración CLDC

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.

Semana 2
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”

Semana 2
 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:

Semana 2
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.

Semana 2
 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

Semana 2
(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

Semana 2
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

Semana 2
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.

Semana 2
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

Semana 2
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

Semana 2
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

Semana 2
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:

Semana 2
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

Semana 2
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

Semana 2
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

Semana 2
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:

Semana 2

Semana 2
 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

Semana 2
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

Más contenido relacionado

La actualidad más candente

Similar a La configuración CLDC

Más de CESAR A. RUIZ C

Último

La configuración CLDC