4. Introducción a la plataforma J2ME.

Transcripción

1 4. Introducción a la plataforma J2ME. Durante los últimos años se ha producido una gran evolución en el mundo de las telecomunicaciones. Sobre todo en el campo de las comunicaciones personales, con la aparición de una gran variedad de terminales móviles, tales como teléfonos móviles, PDAs, ordenadores portátiles Estos objetos han dejado de ser objeto de lujo, solamente al alcance de unos pocos, para pasar a formar parte de nuestra vida cotidiana Por ejemplo, actualmente, casi todo el mundo lleva consigo su propio teléfono móvil. Según las estadísticas, en España, casi el 70% de la población tiene un teléfono móvil. De toda la tecnología de terminales móviles, vamos a centrarnos en el caso de la telefonía móvil, que es la usada en este proyecto. Haciendo un poco de memoria, podemos ver como los terminales han evolucionado desde aparatos de bajas prestaciones, escasa funcionalidad y un tamaño relativamente grande, hasta los móviles actuales con cada vez más servicios y funcionalidades novedosas, tales como juegos, conexión a Internet, descarga de imágenes, videos, sonidos Todo ello en un tamaño cada vez menor. Los fabricantes de móviles han iniciado una carrera para comercializar el dispositivo más novedoso, con mejores prestaciones, con la última tecnología toda esa competencia ha llevado a que los últimos avances en telecomunicaciones estén presentes en los móviles y a que las aplicaciones comúnmente usadas en Internet, como coreo electrónico, se trasladen a los móviles, para que su utilidad sea mayor y los consumidores se decanten por un determinado modelo. Un fenómeno parecido también se ha producido con Internet. En cuestión de unos años ha pasado de ser un medio de uso restringido a grupos de carácter militar y científico, a un medio usado por millones de personas para consultar información y realizar transacciones diariamente. La tendencia evolutiva es ofrecer cada vez más aplicaciones y servicios a los usuarios. Internet se utiliza constantemente para buscar toda clase de información, descargar videos, libros electrónicos, realizar videoconferencias, etc. Un descenso de las tarifas de conexión tanto de módem como de líneas de alta velocidad (ADSL) ha permitido acercar el acceso a un número ingente de personas. La tendencia actual es que ambas tecnologías tiendan a encontrarse. Aprovechando la gran penetración de los móviles en el mercado, para un usuario es más cómodo acceder a Internet a través de su móvil sin necesidad de recurrir a otro terminal. Esta relación entre Internet y la telefonía móvil ha dado lugar a la aparición de nuevos servicios y aplicaciones en el campo de las comunicaciones. El desarrollo de éstos se ha visto favorecido con la aparición de nuevos lenguajes de programación con mayor potencia y características de portabilidad, entre ellos Java, que es el usado en la realización de este proyecto. Francisco Trujillo Hacha 1

2 Aprovechando la penetración de la telefonía móvil en la sociedad, en la actualidad se intenta dotar a los terminales móviles de todo tipo de protocolos y funcionalidades que permitan el acceso a Internet y el uso de sus servicios. Con unos índices de penetración tan altos en la sociedad, la idea de los fabricantes es que no sea necesario un ordenador para acceder a Internet, que cualquiera pueda hacerlo a través de su móvil, facilitando así su uso por parte de la población. Y, de esta forma, intentando acaparar una mayor cuota de mercado. Figura 4.1: Conexión terminal móvil con Internet 4.1. Java en los terminales móviles. Si atendemos un poco a la historia, nos daremos cuenta de que el lenguaje Java, que se utiliza en las aplicaciones de los ordenadores personales y servidores de red, fue diseñado con el objetivo de ser aplicado sobre dispositivos de reducidas prestaciones, tales como televisores y lavadoras. El objetivo de los creadores de Java fue el diseño de un nuevo lenguaje de alto nivel y elevadas prestaciones, que permitiese controlar dispositivos hardware de prestaciones más o menos reducidas. Se buscaba un lenguaje totalmente portable e independiente de la plataforma de ejecución, es decir, que una vez desarrollado un único programa, éste pudiera utilizarse en cualquier dispositivo independientemente de sus características específicas. Como resultado de esto ha nacido una nueva tecnología, llamada J2ME (Java para dispositivos móviles), que consiste en la adaptación del lenguaje Java para la programación de dispositivos de escasos recursos (los dispositivos móviles). Algunas características que hacen que Java sea una buena plataforma para el desarrollo de aplicaciones para dispositivos inalámbricos son las siguientes: Java es independiente del tipo de red usada, se puede descargar cualquier aplicación o contenido sin preocuparse de la red usada. Francisco Trujillo Hacha 2

3 El uso de la verificación de ficheros de clase aporta una gran seguridad de que las aplicaciones desarrolladas funcionen correctamente. La portabilidad hace este lenguaje adecuado para implementar aplicaciones que serán ejecutadas en dispositivos de distintos fabricantes. Las aplicaciones J2ME tienen vida propia y no requieren una conexión permanente a la red. Estas aplicaciones residen en el dispositivo y no tienen por qué ser descargadas cada vez que vayan a ser ejecutadas. Existe una amplia comunidad de desarrolladores trabajando en este campo. La idea principal de J2ME es proporcionar aplicaciones de desarrollo sencillas, que permitan al programador desarrollar aplicaciones de usuario para el consumidor de dispositivos móviles y portátiles. De esta forma se abre un amplio mercado para todas aquellas empresas que deseen cubrir las necesidades que los usuarios demandan en sus dispositivos móviles, tales como teléfonos móviles o agendas personales. J2ME está orientada a dos categorías muy concretas de productos, como son: Dispositivos de información compartidos y conectados de forma permanente. Esta categoría se conoce con la denominación CDC (Connected Device Configuration). Ejemplos típicos de estos son televisores, teléfonos conectados a Internet y sistemas de navegación y entretenimiento para el automóvil. Estos dispositivos se caracterizan por tener un amplio rango de interfaces de usuario, conexión permanente a Internet de banda ancha de tipo TCP/IP y unos rangos de capacidad de memoria entre 2 y 16 MB. Dispositivos de información personales móviles. Categoría conocida como CLDC (Connected, Limited Device Configuration). De entre todos estos los más representativos son los teléfonos móviles y las agendas personales PDAs. Caracterizados por disponer de interfaces simples, conexión no permanente a Internet, de menor ancho de banda, normalmente no basada en TCP/IP y con rangos de capacidad de memoria muy reducidos, entre 128 y 512 KB. Claro está con el paso de los años la línea fronteriza, que separa ambos grupos, es cada vez más fina y cada vez está más difuminada lo cual, a medida que la tecnología avanza, y van apareciendo nuevos tipos de dispositivos, y van evolucionando los ya existentes, va potenciándose aún más. De esta forma hoy ya se confunden los ordenadores y los dispositivos de comunicaciones y cada vez más se va haciendo mayor uso de conexiones sin cables, lo cual nos lleva a realizar en la práctica una agrupación de equipos basándonos únicamente en sus capacidades de memoria, sus consumos de batería y el tamaño de la pantalla. Francisco Trujillo Hacha 3

4 4.2. Arquitectura J2ME. Aunque los dispositivos mencionados tales como teléfonos móviles, agendas personales (PDAs) o televisores tienen muchos aspectos en común, también son muy diferentes en cuanto a forma y función. Estos contarán con diferentes configuraciones hardware, diferentes modos de uso (uso de teclados, voz, etc.), diferentes aplicaciones y características software, así como todo un amplio rango de futuras necesidades a cubrir. Para considerar esta diversidad la arquitectura J2ME está diseñada de forma modular y extensible de tal forma que se de cabida a esta extensa variedad de dispositivos así como a aquellos que sean desarrollados en un futuro. La arquitectura J2ME tiene en cuenta todas aquellas consideraciones relativas a los dispositivos sobre los que tendrá que trabajar. De esta forma, son tres los conceptos básicos en los que se fundamenta: KVM (K Virtual Machine): Ya que el mercado de venta de los dispositivos a los que se refiere J2ME es tan variado y tan heterogéneo, existiendo un gran número de fabricantes con distintos equipos hardware y distintas filosofías de trabajo, J2ME proporciona una máquina virtual Java completamente optimizada que permitirá trabajar con diferentes tipos de procesadores y memorias comúnmente utilizados. Configuración y Perfil: Como los dispositivos sobre los que trabaja J2ME son tan reducidos en lo que se refiere a potencia de cálculo y capacidad de memoria, J2ME proporciona una máquina virtual Java muy reducida que permite solo aquellas funciones esenciales y necesarias para el funcionamiento del equipo. Además, como los fabricantes diseñan distintas características en sus equipos y desarrollan continuos cambios y mejoras en sus aplicaciones estas configuraciones tan reducidas deben poder ser ampliadas con librerías adicionales. Para conseguir esto se han considerado dos conceptos extremadamente importantes que son las Configuraciones y los Perfiles. El objetivo de realizar esta distinción entre Perfiles y Configuraciones es el de preservar una de las principales características de Java, la portabilidad. Francisco Trujillo Hacha 4

5 Figura 4.2: Entorno de ejecución J2ME K Virtual Machine. La tecnología KVM define una máquina virtual Java específicamente pensada para su funcionamiento en dispositivos de pequeño tamaño y de características muy reducidas y limitadas. El objetivo de esta tecnología fue el de crear la mínima máquina virtual posible, pero que mantuviese los aspectos fundamentales del lenguaje Java todo ello funcionando en un dispositivo con una capacidad de memoria de tan solo unos cuantos centenares de KB. (Precisamente esto es lo que le da nombre). KVM puede trabajar con microprocesadores de 16/32 bits tales como teléfonos móviles, PDAs, equipos de audio/vídeo portátiles, etc. La mínima cantidad ideal de memoria necesaria para la KVM es de 128 KB en los cuales se incluyen la propia máquina virtual, un mínimo número de librerías y espacio libre para las aplicaciones. A pesar de esto, una implementación típica real necesita de unos 256 KB de los que aproximadamente la mitad es para las aplicaciones, de 60 a 80 KB es para la máquina virtual y el resto para las librerías. La KVM está escrita en lenguaje C, aproximadamente unas líneas de código, y fue diseñada para ser: Pequeña, con una carga de memoria entre los 40Kb y los 80 Kb, dependiendo de la plataforma y las opciones de compilación. Alta portabilidad. Modulable. Lo más completa y rápida posible y sin sacrificar características para las que fue diseñada. Sin embargo, esta baja ocupación de memoria hace que posea algunas limitaciones con respecto a la clásica Java Virtual Machine (JVM): No hay soporte para tipos en coma flotante. No existen por tanto los tipos double ni float. Esta limitación está presente porque los dispositivos carecen del hardware necesario para estas operaciones. No existe soporte para JNI (Java Native Interface) debido a los recursos limitados de memoria. No existen cargadores de clases (class loaders) definidos por el usuario. Sólo existen los predefinidos. No se permiten los grupos de hilos o hilos daemon. Cuándo queramos utilizar grupos de hilos utilizaremos los objetos Colección para almacenar cada hilo en el ámbito de la aplicación. Francisco Trujillo Hacha 5

6 No existe la finalización de instancias de clases. No existe el método Object.finalize(). No hay referencias débiles. Limitada capacidad para el manejo de excepciones debido a que el manejo de éstas depende en gran parte de las APIs de cada dispositivo por lo que son éstos los que controlan la mayoría de las excepciones. Reflexión Aparte de la no inclusión de estas características, la verificación de clases merece un comentario aparte. El verificador de clases estándar de Java es demasiado grande para la KVM. De hecho es más grande que la propia KVM y el consumo de memoria es excesivo, más de 100Kb para las aplicaciones típicas. Este verificador de clases es el encargado de rechazar las clases no válidas en tiempo de ejecución. Este mecanismo verifica los bytecodes de las clases Java realizando las siguientes comprobaciones: Ver que el código no sobrepase los límites de la pila de la VM. Comprobar que no se utilizan las variables locales antes de ser inicializadas. Comprobar que se respetan los campos, métodos y los modificadores de control de acceso a clases. Figura 4.3: Preverificación de clases en CLDC/KVM Por esta razón los dispositivos que usen la configuración CLDC y KVM introducen un algoritmo de verificación de clases en dos pasos. Este proceso puede apreciarse gráficamente en la Figura 1.4. La KVM puede ser compilada y probada en 3 plataformas distintas: Francisco Trujillo Hacha 6

7 1. Solaris Operating Environment. 2. Windows 3. PalmOs La CVM (Compact Virtual Machine) ha sido tomada como Máquina Virtual Java de referencia para la configuración CDC y soporta las mismas características que la Máquina Virtual de J2SE. Está orientada a dispositivos electrónicos con procesadores de 32 bits de gama alta y en torno a 2Mb o más de memoria RAM. Las características que presenta esta Máquina Virtual son: 1. Sistema de memoria avanzado. 2. Tiempo de espera bajo para el recolector de basura. 3. Separación completa de la VM del sistema de memoria. 4. Recolector de basura modularizado. 5. Portabilidad. 6. Rápida sincronización. 7. Ejecución de las clases Java fuera de la memoria de sólo lectura (ROM). 8. Soporte nativo de hilos. 9. Baja ocupación en memoria de las clases. 10. Proporciona soporte e interfaces para servicios en Sistemas Operativos de Tiempo Real. 11. Conversión de hilos Java a hilos nativos. 12. Soporte para todas las características de Java2 v1.3 y librerías de seguridad, referencias débiles, Interfaz Nativa de Java (JNI), invocación remota de métodos (RMI), Interfaz de depuración de la Máquina Virtual (JVMDI) Configuraciones. Ya hemos mencionado algo anteriormente relacionado con las configuraciones. Para tenerlo bien claro diremos que una configuración es el conjunto mínimo de API s Java que permiten desarrollar aplicaciones para un grupo de dispositivos. Éstas API s describen las características básicas, comunes a todos los dispositivos: Características soportadas del lenguaje de programación Java. Características soportadas por la Máquina Virtual Java. Bibliotecas básicas de Java y APIs soportadas. Por tanto, todos los dispositivos que se encuadren dentro de una Configuración concreta deben cumplir todas las características de ésta, y todas las aplicaciones que corran sobre estos dispositivos deben cumplir las restricciones del Perfil que se monta sobre esta Configuración. El objetivo de esto es evitar la fragmentación y limitar en lo posible el número de Configuraciones desarrolladas por los fabricantes. Concretamente, sólo existen dos Configuraciones estándar permitidas, que son: Francisco Trujillo Hacha 7

8 CLDC (Connected Limited Device Configuration) abarca el conjunto de los dispositivos móviles personales móviles, tales como teléfonos móviles, PDAs, etc. Implementa una serie de librerías y APIs que no se encuentran en J2SE y que son específicas para este tipo de dispositivos. CDC (Connected Device Configuration) que abarca fundamentalmente el conjunto de dispositivos de información compartida, fijos y de conexión permanente, tales como televisores, terminales de comunicación, etc. Figura 4.4: Relación J2SE-J2ME Ésta incluye un conjunto de librerías mucho mayor que el del anterior, siendo CLDC un subconjunto de ésta. La mayoría de las funcionalidades de CLDC y CDC son heredadas de J2SE, de forma que toda clase perteneciente a CDC y CLDC debe ser exactamente igual a su correspondiente en J2SE o bien un subconjunto de ésta. Pero además ambas configuraciones pueden añadir características que se encuentren en J2SE y que sean específicas del dispositivo en sí. Las tecnologías CLDC y KVM están íntimamente relacionadas, ya que actualmente CLDC sólo está disponible para KVM y KVM solo soporta CLDC. Esta situación se prevé que cambiará cuando el proceso de desarrollo de J2ME está más avanzado Configuración CDC. La CDC está orientada a dispositivos con cierta capacidad computacional y de memoria. Por ejemplo, decodificadores de televisión digital, televisores con internet, algunos electrodomésticos y sistemas de navegación en automóviles. CDC usa una Máquina Virtual Java similar en sus características a una de J2SE, pero con limitaciones Francisco Trujillo Hacha 8

9 en el apartado gráfico y de memoria del dispositivo. Ésta Máquina Virtual es la que hemos visto como CVM (Compact Virtual Machine). La CDC está enfocada a dispositivos con las siguientes capacidades: Procesador de 32 bits. Disponer de 2 Mb o más de memoria total, incluyendo memoria RAM y ROM. Poseer la funcionalidad completa de la Máquina Virtual Java2. Conectividad a algún tipo de red. 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 contenidas principalmente en el paquete javax.microedition.io, que incluye soporte para comunicaciones http y basadas en datagramas. La Tabla 4.1 nos muestra las librerías incluidas en la CDC: Tabla 4.1: Librerías de configuración CDC Configuración CLDC. La CLDC está orientada a dispositivos dotados de conexión y con limitaciones en cuanto a capacidad gráfica, cómputo y memoria. Un ejemplo de éstos dispositivos son: teléfonos móviles, buscapersonas (pagers), PDAs, organizadores personales, etc. Ya hemos dicho que CLDC está orientado a dispositivos con ciertas restricciones. Algunas de estas restricciones vienen dadas por el uso de la KVM, necesaria al trabajar con la CLDC debido a su pequeño tamaño. Los dispositivos que usan CLDC deben cumplir los siguientes requisitos: Disponer entre 160 Kb y 512 Kb de memoria total disponible. Como mínimo se debe disponer de 128 Kb de memoria no volátil para la Máquina Virtual Java y Francisco Trujillo Hacha 9

10 las bibliotecas CLDC, y 32 Kb de memoria volátil para la Máquina Virtual en tiempo de ejecución. Procesador de 16 o 32 bits con al menos 25 Mhz de velocidad. Ofrecer bajo consumo, debido a que éstos dispositivos trabajan con suministro de energía limitado, normalmente baterías. Tener conexión a algún tipo de red, normalmente sin cable, con conexión intermitente y ancho de banda limitado (unos 9600 bps). La CLDC aporta las siguientes funcionalidades a los dispositivos: Un subconjunto del lenguaje Java y todas las restricciones de su Máquina Virtual (KVM). Un subconjunto de las bibliotecas Java del núcleo. Soporte para E/S básica. Soporte para acceso a redes. Seguridad. La Tabla 3.2 nos muestra las librerías incluidas en la CLDC. Tabla 4.2: Librerías de configuración CLDC. Un aspecto muy a tener en cuenta es la seguridad en CLDC. Esta configuración posee un modelo de seguridad sandbox al igual que ocurre con los applets. En cualquier caso, una determinada Configuración no se encarga del mantenimiento del ciclo de vida de la aplicación, interfaces de usuario o manejo de eventos, sino que estas responsabilidades caen en manos de los perfiles Perfiles. Francisco Trujillo Hacha 10

11 Acabamos de decir que el perfil es el que define las APIs que controlan el ciclo de vida de la aplicación, interfaz de usuario, etc. Más concretamente, un perfil es un conjunto de APIs orientado a un ámbito de aplicación determinado. Los perfiles identifican un grupo de dispositivos por la funcionalidad que proporcionan (electrodomésticos, teléfonos móviles, etc.) y el tipo de aplicaciones que se ejecutarán en ellos. Las librerías de la interfaz gráfica son un componente muy importante en la definición de un perfil. Aquí nos podemos encontrar grandes diferencias entre interfaces, desde el menú textual de los teléfonos móviles hasta los táctiles de los PDAs. El perfil establece unas APIs que definen las características de un dispositivo, mientras que la configuración hace lo propio con una familia de ellos. Esto hace que a la hora de construir una aplicación se cuente tanto con las APIs del perfil como de la configuración. Tenemos que tener en cuenta que un perfil siempre se construye sobre una configuración determinada. De este modo, podemos pensar en un perfil como un conjunto de APIs que dotan a una configuración de funcionalidad específica. Ya hemos visto los conceptos necesarios para entender cómo es un entorno de ejecución en Java Micro Edition. Anteriormente vimos que para una configuración determinada se usaba una Máquina Virtual Java específica. Teníamos que con la configuración CDC usábamos la CVM y que con la configuración CLDC usábamos la KVM. Con los perfiles ocurre lo mismo. Existen unos perfiles que construiremos sobre la configuración CDC y otros que construiremos sobre la CLDC. Para la configuración CDC tenemos los siguientes perfiles: Foundation Profile. Personal Profile. RMI Profile. Para la configuración CLDC tenemos los siguientes: PDA Profile. Mobile Information Device Profile (MIDP). En la siguiente figura se puede observar en entorno de ejecución completo de la J2ME: Francisco Trujillo Hacha 11

12 Figura 4.5: Arquitectura del entorno de ejecución J2ME. Un perfil puede ser construido sobre cualquier otro. Sin embargo, una plataforma J2ME sólo puede contener una configuración Capas altas. Sobre las capas anteriores se implementan las distintas aplicaciones que corren sobre el dispositivo, éstas pueden ser de tres tipos: Una aplicación MIDP o también llamada MIDlet es una aplicación que solamente hace uso de librerías Java definidas por las especificaciones CLDC y MIDP. En este tipo de aplicaciones está enfocado el desarrollo de la especificación MIDP y por tanto se espera será la más usada. Una aplicación OEM-specific es aquella que no utiliza clases propias de MIDP, sino que utiliza clases de la especificación OEM las cuales normalmente no son portables de un equipo a otro, ya que son clases propias de cada fabricante. Una aplicación Nativa es aquella que no está escrita en lenguaje Java y va montada sobre el software nativo del propio equipo. Francisco Trujillo Hacha 12

13 Figura 4.6: Arquitectura de alto nivel Seguridad. Tanto empresas como usuarios individuales dependen cada vez más de información crítica almacenada en computadoras y redes, por lo que el uso de sistemas y aplicaciones de seguridad se ha convertido en algo extremadamente importante, y como no, esto es aún más importante en el ámbito de dispositivos móviles y redes inalámbricas. La plataforma de desarrollo de Java es muy útil en estos aspectos debido a su inherente arquitectura de seguridad. En la plataforma J2SE el modelo de seguridad proporciona a los desarrolladores de aplicaciones funcionalidades con las que crear distintas políticas de acceso y articular permisos independientes para cada usuario, manteniendo todo esto transparente al usuario. Desafortunadamente la cantidad de código con el que se consigue todo esto y que se encuentra en la plataforma J2SE excede en mucho las capacidades de memoria de los dispositivos sobre los que trabaja J2ME, por lo que se hacen necesarias una serie de simplificaciones que reduzcan este código pero que mantengan cierta seguridad. El modelo de seguridad definido en CLDC en conjunto con MIDP se basa en tres niveles: Seguridad de bajo nivel: También conocida como seguridad de la máquina virtual asegura que un fichero de clase, o un fragmento de código malintencionado no afecte a la integridad de la información almacenada en el dispositivo móvil. Esto se consigue mediante el verificador de ficheros de clase el cual asegura que los bytecodes almacenados en el fichero de clase no contengan instrucciones ilegales, que ciertas instrucciones no se ejecuten en un orden no permitido y que no contengan referencias a partes de la memoria no válidas o que se encuentren fuera del rango de direccionamiento real. Debido a esto, el estándar CLDC exige que bajo él se encuentre una KVM que realice estas operaciones de seguridad. Francisco Trujillo Hacha 13

14 Seguridad de nivel de aplicación: Este nivel de seguridad asegura que las aplicaciones que corren sobre el dispositivo solo puedan acceder a aquellas librerías, recursos del sistema y otros dispositivos que tanto el equipo como el entorno de aplicación permitan. Seguridad punto a punto: Garantiza que una transacción iniciada en un dispositivo móvil de información esté protegida a lo largo de todo el camino recorrido entre el dispositivo móvil y la entidad que provea el servicio. Este tipo de seguridad no está recogida en el CLDC o en el MIDP por lo que será siempre una solución propietaria del fabricante y del proveedor de servicios. El verificador de ficheros de clase solo puede garantizar que la aplicación dada es un programa Java válido, pero nada más, por lo que hay una serie de aspectos que se escapan del control del verificador de clases, como es el acceso a recursos externos tales como ficheros de sistema, impresoras, dispositivos infrarrojos o la red. Modelo Sandbox En el modelo CLDC y MIDP el nivel de seguridad de aplicación se obtiene mediante un sandbox el cual asegura un entorno cerrado en el cual una aplicación solo puede acceder a aquellas librerías que han sido definidas por la Configuración, el Perfil y las clases específicas OEM del dispositivo. El sandbox asegura que la aplicación no se escape de él y acceda a recursos o funcionalidades no permitidas. Más concretamente el uso de un sandbox asegura: Los ficheros de clases han sido preverificados y son aplicaciones Java válidas. La Configuración, el Perfil y las clases OEM han determinado un conjunto de APIs válidas para la aplicación. La descarga y gestión de aplicaciones Java dentro del dispositivo en su lugar correcto de almacenamiento, no permitiéndose el uso de clases y aplicaciones de descarga diseñadas por el usuario que podrían dañar a las del sistema. El programador de aplicaciones no puede descargar al dispositivo librerías que contengan nuevas funcionalidades nativas o que accedan a funcionalidades nativas no permitidas. Protección de clases de sistema Una de las características del CLDC es la habilidad de soportar la descarga dinámica de aplicaciones a la máquina virtual del dispositivo. Por lo que podría existir una falta de seguridad ya que una aplicación podría no hacer caso de ciertas clases de sistema. CLDC y MIDP se encargan de que esto no ocurra. Restricciones adicionales en la carga dinámica de clases Francisco Trujillo Hacha 14

15 Existe una restricción de seguridad muy importante en la carga dinámica de clases que consiste en que por defecto una aplicación Java solo puede cargar clases pertenecientes a su Java Archive (JAR) file. Esta restricción asegura que las distintas aplicaciones que corran sobre un dispositivo no puedan interferir entre sí. Francisco Trujillo Hacha 15