DMReMon Monitor de Recursos Multiplataforma con entorno de desarrollo

Tecnologías utilizadas

• J2SE: Java 2 Platform Standard Edition

  J2SE [2 y 3] es el entorno de desarrollo de aplicaciones Java (de la versión 2) orientado a las aplicaciones autónomas (standalone) y los Applets.

  La arquitectura de la plataforma se puede ver en la siguiente figura:

  

  Sun proporciona J2SE dividido en dos entregas: por un lado está el entorno de desarrollo [10] (JDK: J2SE Development Kit) y por otro el entorno de ejecución (JRE: Java Runtime Edition). Ambos pueden ser descargados de la página de Sun.

  A continuación se describen algunas de las APIS y herramientas de la plataforma que han sido utilizadas en el desarrollo del proyecto y que son más "desconocidas".

  • Reflexión: API Reflection

    La reflexión en Java [16] es la capacidad para averiguar cosas acerca de las clases y sus propiedades en un programa en ejecución. Se puede decir que el API de reflexión (API Reflection) representa, o refleja, las clases, interfaces y objetos que están en la Máquina Virtual de Java (JVM: Java Virtual Machine) en ejecución.

    Algunas de las cosas que permite la reflexión son:

    • Determinar la clase de un objeto.
    • Obtener información acerca de los modificadores, campos, métodos, constructores y superclases de una clase determinada.
    • Descubrir qué constantes y métodos están declarados en una interfaz.
    • Crear una instancia de una clase cuyo nombre no se conoce hasta tiempo de ejecución.
    • Obtener y establecer el valor de un campo de un objeto, incluso si el nombre del campo no se conoce hasta tiempo de ejecución.
    • Invocar a un método de un objeto, incluso si el método es desconocido hasta tiempo de ejecución.
    • Crear un nuevo array cuyo tamaño y tipo de componentes no se conocen hasta tiempo de ejecución y después modificar los componentes de este array.

    Las principales clases que componen el API Reflection son las siguientes (las clases Class y Object pertenecen al paquete java.lang, mientras que las demás pertenecen al paquete java.lang.reflect):

    • Array: Proporciona métodos estáticos para crear arrays y acceder a ellos dinámicamente.
    • Class: Representa, o refleja, clases e interfaces.
    • Constructor: Proporciona información y acceso al constructor de una clase. Permite instanciar una clase dinámicamente.
    • Field: Proporciona información y acceso dinámico a un campo de una clase o de una interfaz.
    • Method: Proporciona información y acceso a un método de una clase o de una interfaz. Permite invocar a un método de un objeto dinámicamente.
    • Modifier: Proporciona métodos estáticos y constantes que permiten obtener información sobre los modificadores de acceso (público, privado o protegido) de una clase y sus miembros.
    • Object: Ésta es la clase padre de todas las clases en Java. Esta clase pertenece al API Reflection ya que proporciona un método que permite a cualquier objeto obtener su clase (mediante el método getClass).

    Para finalizar, podemos decir que la reflexión es una potente característica (para muchos desconocida), pero compleja de usar. Es una característica que permite escribir programas con gran generalidad. Este capacidad está más orientada al desarrollo de herramientas (depuradores por ejemplo) o frameworks (como Struts, que es un entorno para crear aplicaciones Web siguiendo el Modelo-Vista-Controlador) que al desarrollo de aplicaciones. El principal problema de la reflexión, y de ahí su complejidad, es que los errores no se detectan en tiempo de compilación, sino que se detectan en tiempo de ejecución (viendo las posibles excepciones que se generen).

  • API JNI: Java Native Interface

    El API JNI [8] (el cual forma parte del JDK) permite la comunicación entre código Java con código escrito en otro lenguaje (código nativo) en ambos sentidos, es decir, permite utilizar código escrito en otro lenguaje desde código Java y viceversa.

    Las razones principales por las que desde una aplicación Java se decide usar código nativo (normalmente se usa C, aunque podría ser cualquier cualquier lenguaje como C++, Fortran o incluso ensamblador) suelen ser las siguientes:

    • Se tiene un código comprobado y depurado en otro lenguaje y convertirlo a Java podría llevar mucho tiempo, ya que habría que migrar el código además de comprobarlo y depurarlo.
    • La aplicación que se está desarrollando requiere acceso a características o dispositivos del sistema. Esto a veces es imposible realizarlo en Java.
    • El tiempo de ejecución de la tarea a desarrollar es un factor crucial, por lo que se podría usar un lenguaje nativo (como por ejemplo C) para maximizar la velocidad.

    La principal desventaja de usar código nativo desde Java es que se pierde la portabilidad. La aplicación desarrollada se deberá suministrar con una biblioteca de métodos nativos distinta para cada plataforma que se tenga intención de soportar. Además, otra desventaja es que el código nativo no tendrá tanta seguridad como el código desarrollado en Java. Este es el principal problema de los desarrollos en C, ya que al ser C un lenguaje tan flexible es fácil cometer errores que puedan comprometer la seguridad del sistema operativo. Por todo esto, sólo conviene usar código nativo cuando sea la única solución que haya.

    El API JNI también permite utilizar objetos Java desde una aplicación escrita en otro lenguaje del mismo modo que el código Java usaría estos objetos. Un método nativo puede crear objetos Java e invocar a métodos de estos objetos. JNI permite aprovechar las ventajas de la programación en Java desde el código nativo. Un ejemplo de esto es que se pueden elevar y capturar excepciones desde el código nativo y manejar estas excepciones en la aplicación Java. Además, desde el código nativo se pueden cargar clases Java y obtener información de las mismas (como se hace con el API Reflection).

    Los siguientes esquemas muestran ejemplos de uso de JNI:

    • En la siguiente figura se muestra un programa en C que usa JNI para enlazar con bibliotecas Java, invocar a métodos Java, usar clases Java, etc.

      

    • En la figura siguiente se muestra el uso de código nativo desde una aplicación Java. Algunas de las posibilidades son llamar a rutinas de C, utilizar clases C++, llamar a rutinas de ensamblador, etc.

      

  • API Swing

    En sus orígenes, Java (la versión 1.0) tenía una biblioteca de clases llamada AWT (Conjunto de herramientas abstracto de ventanas) que servía para realizar la programación de las interfaces gráficas de usuario (GUI). La biblioteca AWT trata con los elementos de la interfaz de usuario delegando su creación y comportamiento a las herramientas nativas de la GUI de la plataforma destino (Windows, Solaris, Linux, etc.). De esta forma, en teoría, el programa resultante podría ejecutarse sobre cualquier plataforma, con el aspecto de esa plataforma, pero en la práctica, y especialmente en aplicaciones complejas, esto no era del todo cierto y existían numerosos fallos (específicos en cada plataforma) que provocaban el tener que depurar una aplicación en cada una de las plataformas en las que se quería ejecutar.

    Para superar estas limitaciones se creó Swing. Swing se basa en dibujar los componentes gráficos en ventanas en blanco, por tanto la única funcionalidad que se necesita de la GUI nativa de la plataforma es el poder crear ventanas y dibujar en ellas. Swing no reemplaza por completo a AWT, ya que por ejemplo el manejo de eventos no ha cambiado a lo largo de las versiones de Java.

    De todo esto, se puede llegar a la conclusión de que los elementos basados en Swing serán más lentos que los elementos basados en AWT, aunque con el avance de las máquinas actuales esto ya no es un problema. Además existen una gran cantidad de ventajas de Swing respecto a AWT como las siguientes:

    • Swing tiene un conjunto de elementos de la interfaz de usuario mucho más amplio que AWT.
    • Swing depende mucho menos de la plataforma en la que ejecuta, por lo que es menos propenso a fallos que AWT.

    Además, la arquitectura de Swing permite que existan diferentes aspectos a la hora de crear interfaces de usuario. Existen aspectos específicos para cada una de las plataformas (Windows, Motif, GTK, etc.) y un aspecto independiente desarrollado por Sun llamado "Metal". También es posible personalizar un aspecto determinado o crear uno propio para lo cual habría que especificar cómo se dibujarán los distintos componentes de Swing.

    En conclusión, Swing es más robusto, tiene más características, es más portable y es más fácil de usar que AWT y a día de hoy es el futuro de la programación de interfaces gráficas de usuario en Java.

  • API JAXP: Java API for XML Processing

    El API Java para procesamiento de XML facilita el proceso de datos XML con aplicaciones escritas en Java. Inicialmente JAXP era una extensión del lenguaje Java, pero desde la versión 1.4 ha sido integrada en el SDK.

    JAXP contiene los analizadores estándares SAX y DOM. La versión 1.1 de JAXP soporta el estándar XSLT. JAXP también proporciona soporte para espacios de nombres, permitiendo trabajar con DTDs que de otra forma tendrían conflictos de nombrado.

    JAXP está diseñado para ser flexible, con lo que se nos permite usar cualquier analizador compatible XML dentro de nuestra aplicación. Esto es posible gracias a una capa de conectividad que permite "enchufar" una implementación de las APIs SAX o DOM. Mediante esta capa de conectividad también se nos permite "enchufar" un procesador XSL.

    Algunos de los analizadores de XML más conocidos son Xerces (desarrollado por el grupo Apache) y Crimson (desarrollado conjuntamente entre Apache y Sun). En cuanto a procesadores XSL, destaca Xalan (de Apache).

  • JPDA: Java Platform Debugger Architecture

    JPDA [19] es una arquitectura que define todo lo necesario para construir herramientas de depuración para la plataforma Java.

    JPDA está formada por tres capas:

    • Java Virtual Machine Debugger Interface (JVMDI): Se trata de una interfaz implementado por la Máquina Virtual (VM: Virtual Machine). Define (en formato de bajo nivel) los servicios que la VM debe proporcionar para la depuración. Incluye peticiones de información (por ejemplo, el estado actual de la pila), acciones (por ejemplo, establecer un punto de ruptura) y notificaciones (por ejemplo, el alcance de un punto de ruptura).
    • Java Debug Wire Protocol (JDWP): Se trata de un protocolo que define el formato de la información y peticiones intercambiadas entre el proceso que se está depurando y el depurador. Este protocolo no define el mecanismo de transporte (que puede ser mediante sockets, puerto serie, memoria compartida, ...). La especificación del protocolo permite que el proceso que se depura ejecute en plataformas distintas al depurador. Esto es la base de la depuración remota (muy útil para depurar por ejemplo una aplicación Web o la parte servidora en una aplicación basada en servicios Web).
    • Java Debug Interface (JDI): Se trata de una interfaz Java para el proceso depurador. Define en formato de alto nivel la información y las peticiones intercambiadas. Aunque los depuradores pueden usar directamente el protocolo JDWP o la interfaz JVMDI es recomendable que utilicen esta interfaz.