Artículo 2 sobre la plataforma ECLIPSE

EL ARCHIPIÉLAGO ECLIPSE (PARTE 2 DE 4)

Fecha de la última revisión: 21.05.2014

Miguel Ángel Abián mabian ARROBA aidima PUNTO es

"Todo es un plug-in." Eslógan no oficial de la plataforma Eclipse

"La música lo es todo. La gente debería morir por ella. La gente está muriendo por todo lo demás, así que por qué no morir por la música. Salva más vidas." Lou Reed, Desde el proscenio

9. Eclipse como IDE

La plataforma Eclipse, combinada con el JDT (Java Development Tooling), permite disponer de un IDE (Integrated Development Environment o Entorno de desarrollo integrado) para Java de excelente calidad. Aquí cobra más sentido la frase "Eclipse es un IDE abierto y extensible para todo y, sin embargo, para nada en particular". Por sí misma, la plataforma Eclipse proporciona funcionalidades demasiado genéricas. Solamente cuando se amplia con otras herramientas (el JDT en este caso, que figura en la distribución estándar de Eclipse y que es un plug-in formado, a su vez, por otros plug-ins), permite desarrollar actividades útiles para los usuarios que la vayan a utilizar como IDE.

Como IDE de Java, Eclipse posee un editor muy visual con sintaxis coloreada, ofrece compilación incremental de código, un potente depurador (que permite establecer puntos de interrupción, modificar e inspeccionar valores de variables, etc. e incluso depurar código que resida en una máquina remota), un navegador de clases, un gestor de archivos y proyectos... pero no se limita sólo a esto. La versión estándar de Eclipse proporciona también una biblioteca de refactorización de código y una lista de tareas, soporta la integración con JUnit, y suministra un front-end gráfico para Ant, la conocida herramienta de código abierto que forma parte del proyecto Jakarta de Apache.

También incluye una herramienta para completar código: el asistente de contenido, encargado de mostrar los métodos y atributos de las clases con las que se está trabajando, ya formen parte de las APIs de Java o de cualquier otra clase en el build path, aunque estén en ficheros JAR. Este asistente también proporciona información de cada uno de los métodos mediante una ventana secundaria contextual (Figura 8), y avisa -cuando se graba la clase o la interfaz- de los errores cometidos al escribir el código (Figura 9). Eclipse incluye también asistentes para la creación de clases e interfaces, y proporciona una integración perfecta con el sistema open source CVS (Concurrent Version System), muy útil para llevar el control de la versiones con las que se trabaja y conocer en todo momento sus respectivas diferencias. CVS (http://www.cvshome.org) es uno de los sistemas de control de código fuente más usados; muchos de los sistemas UNIX lo llevan preinstalado por defecto.

A continuación me voy a extender respecto a dos características de Eclipse como IDE para Java: el HotSwap y la compilación incremental automática del código. He elegido éstas, y no otras, por dos razones: a) por motivos de espacio resulta imposible abordar todas las funcionalidades de Eclipse (además, algunas de ellas todavía se hallan en desarrollo o cambio); y b) las mencionadas características reducen el tiempo -y por tanto el coste- de construcción, depuración y distribución del software. Cualquier desarrollador, ya sea profesional, ya sea principiante, puede usarlas para no desperdiciar muchas horas repitiendo tareas mecánicas.

Una característica de Eclipse como IDE, poco mencionada pero que encuentro muy útil, es el soporte que ofrece Eclipse a HotSwap (cambio en caliente), una de las novedades del JDK 1.4. Esta propiedad, incluida en la Java Platform Debugger Architecture (Arquitectura del Depurador de la Plataforma Java) de la versión 1.4, permite sustituir código o modificarlo mientras se está ejecutando un programa, sin necesidad de pararlo, realizar las modificaciones, grabarlas, volver a compilar y -finalmente- ejecutar de nuevo. Si utilizamos Eclipse con la versión 1.4 de Java, podemos establecer puntos de interrupción en el código, ejecutarlo, comprobar el estado de las variables en los puntos de interrupción cuando éstos se alcancen, modificar el código o introducir código nuevo, grabar los cambios y continuar la ejecución del programa. Los fallos pueden localizarse y analizarse al vuelo, sin vernos obligados a salir de la aplicación, cambiar el código, recompilar y comenzar una nueva sesión de depuración.

Para sacar partido de esta característica -ya existente en Visual Age for Java- no precisamos investigar la documentación de Eclipse con una lupa de 50 aumentos y luz ultravioleta, ni invocar a Cthulhu a la luz de la luna (actividad no del todo infrecuente, por desgracia, entre los que hemos tenido que lidiar con productos de IBM): basta con iniciar una sesión de depuración, sustituir o cambiar el código generador de errores, grabar el archivo y apretar el botón Resume de la barra de herramientas Debug. Automáticamente, el programa sometido a depuración proseguirá su ejecución, teniendo en cuenta los cambios efectuados. Utilizando HotSwap con Eclipse, se reducen los tiempos destinados a depuración, en particular cuando se trabaja con aplicaciones que tardan mucho tiempo en arrancar -como aplicaciones web de cierta complejidad o aplicaciones que accedan a bases de datos remotas- o en las que se tarda mucho en alcanzar los puntos calientes o problemáticos.

Otra característica de Eclipse, muy eficiente para reducir los tiempos de depuración y pruebas, es la compilación incremental automática del código. Eclipse -al igual que Visual Age for Java- no cuenta con un menú de compilación pues no es necesario: cada vez que se hacen cambios en uno o más ficheros, el compilador interno de Eclipse recompila todos los ficheros fuente afectados por los cambios. El usuario no tiene que preocuparse de compilar, y puede estar seguro de contar con archivos siempre compilados. En consecuencia, tampoco resulta preciso esperar a la compilación para detectar ciertos errores: Eclipse muestra indicaciones de los errores aparecidos según se van realizando o guardando los cambios.

Las ventajas que aportan estas dos propiedades se apreciarán mejor con un ejemplo: consideremos que trabajamos con servlets y JSPs (Java Server Pages), y que hemos decidido usar Eclipse junto con algún servidor web. Debido al ciclo de vida de los servlets, se necesita parar y volver a arrancar el servidor web cada vez que se desea actualizar la clase servlet o recargar el código Java llamado por algún fichero JSP. Durante el desarrollo se cambia a menudo el código de los servlets y de las JSPs. En la mayoría de los IDEs resulta bastante tedioso y largo depurar el código, sobre todo si los problemas se producen sólo cuando el servlet (o la JSP) lleva un

Copyright (c) 2003-2014, Miguel Ángel Abián. Este documento puede ser distribuido solo bajo los términos y condiciones de la licencia de Documentación de javaHispano v1.0 o posterior (la última versión se encuentra en http://www.javahispano.org/licencias/).

Page 1 of 10javaHispano. ECLIPSE

21/05/2014file://F:\ArticuloEclipse\Art_Eclipse_2\Copia de EclipsePart...

cierto tiempo en ejecución, o dentro de algún bucle largo, porque hay que parar y reiniciar el servidor web y sus plug-ins. Cuando se cambia en Eclipse un método de un servlet o de un fichero JSP, Eclipse compila incrementalmente solamente el método modificado en la clase, no la clase completa, y la liga en caliente al programa en ejecución. El ahorro de tiempo es considerable, pues no hay que volver a recrear el estado de ejecución (del programa) que ocasiona los problemas; puede modificarse repetidamente el servlet o la JSP en ejecución sin parar y reiniciar el servidor, y se pueden usar todas las características de Eclipse mientras el servidor está ejecutándose.

Sólo hay un tipo de IDEs libres de defectos o ausencias: el que no existe más que en las mentes de sus creadores (a condición de que no sean demasiado pragmáticos); lógicamente, Eclipse no constituye una excepción, y tiene algunas carencias y deficiencias reprochables. Las tres más relevantes, desde mi punto de vista, se detallan aquí:

� Eclipse no incluye un diseñador visual de interfaces gráficas (GUI builder).

� Eclipse no incorpora plug-ins para comunicarse con servidores de aplicaciones J2EE.

� La falta de soporte a los Enterprise JavaBeans, a las Java Server Pages y a los servlets es total. No se incluyen asistentes o plug-ins para la edición o depuración de estos.

Tanto las versiones comerciales de Eclipse distribuidas por IBM como los productos profesionales de la compañía que tienen como núcleo la plataforma Eclipse sí cuentan con algunas de las características (o con todas) que faltan en el SDK (Standard Development Kit o Kit de desarrollo estándar) de Eclipse. Existen plug-ins gratuitos que permiten integrar eficazmente Eclipse con servidores open source o free software de aplicaciones, como JBoss, o con servidores propietarios como los de IBM, BEA u Oracle; estos plug-ins permiten arrancar y parar el servidor dentro de Eclipse, así como depurar el código fuente dentro del servidor de aplicaciones. Igualmente, existen plug-ins -algunos comerciales- para el resto de características que Eclipse no incorpora, basta con ensamblarlos.

Fig. 8. El asistente de contenido de Eclipse permite seleccionar métodos y ver una breve descripción de los mismos.



Al ser neutral con respecto a la plataforma y al lenguaje, Eclipse puede utilizarse con otros lenguajes además de Java; basta con usar los plug-ins adecuados. Hasta la fecha [Abril 2003], el consorcio Eclipse.org proporciona plug-ins sólo para C/C++ y COBOL, pero existen proyectos independientes más o menos avanzados (aunque todavía no estables o definitivos) para que pueda usarse con C#, PHP, Eiffel, JavaScript, Ruby, Pascal, Phyton y con algunos lenguajes experimentales.

El IDE de C y C++ se encuentra asignado al subproyecto CDT (C/C++ Development Tools) del proyecto Herramientas Eclipse; y proporciona ya un editor que ofrece sintaxis coloreada y que completa automáticamente el código, además de adjuntar un depurador. Los plug-ins del IDE están escritos en Java, sin código nativo.

La prueba evidente de que COBOL no está muerto y de que sigue gozando de una relativa buena salud en el siglo XXI (para desespero de muchos ingenieros de software y programadores: la informática no miente, nunca nos prometió un jardín de rosas) la aporta el hecho de que se ha desarrollado un IDE para él antes que para lenguajes mucho más modernos. El IDE de COBOL está también escrito en Java, sin código nativo, pero sólo puede trabajar en sistemas en los que exista un compilador de COBOL, un depurador y una interfaz puente (bridge interface) que permita a los plug-ins (seis por ahora) invocar al depurador y al compilador COBOL nativo. Inicialmente el IDE de COBOL de Eclipse se basa en un compilador y depurador comercial de COBOL (Fujitsu NetCOBOL 7.0), para el cual existe un puente entre los plug-ins, el compilador y el depurador; este IDE sólo funciona, por ahora, sobre Red Hat Linux 7.2.

Para C# existe un plug-in llamado Improve CSharp, gratuito y bajo licencia CPL, que permite la edición y compilación de código C# e incluye un asistente de contenido para las palabras clave del lenguaje. Está disponible para Windows y Linux. Aunque este plug-in funciona correctamente, queda aún mucho por hacer; por ahora no se ha implementado ni siquiera la noción de proyecto C#, y cuando se genera un nuevo fichero C#, Improve CSharp no crea automáticamente su estructura, salvo que sea la básica.

Para Python disponemos del plug-in Python Editor for Eclipse (Pe4eclcipse), capaz de editar y depurar aplicaciones Phyton. Se encuentra disponible para Windows 95/98/2000, AIX, Linux y SunOs/Solaris. Es una versión pre-alfa y se licencia bajo GNU GPL.

Para PHP existe -en estado de desarrollo beta- el PHP plug-in for Eclipse, disponible para Windows y Linux bajo la licencia CPL de IBM. Ruby cuenta con el plug-in Ruby Development Tool, independiente del sistema operativo, en estado beta.

El plug-in JSEditor es un editor de ficheros JavaScript. Muestra las funciones JavaScript en la vista Outline de manera que resulta muy sencillo navegar a través de los ficheros JavaScript para alcanzar las funciones implementadas; ofrece también sintaxis coloreada para funciones, cadenas y comentarios.

Un lenguaje tan veterano como Pascal también encuentra albergue en Eclipse: Pasclipse es un plug-in bajo licencia CPL, disponible para Mac Os, Windows y Linux, que proporciona la posibilidad de integrar cualquier compilador de Pascal basado en línea de comandos; Pasclipse incluye también un formateador de código fuente. Por ahora se halla en fase pre-alfa.

Para el desarrollo de aplicaciones J2EE hay disponibles muchas soluciones distintas: Lomboz, BEJY, DeployGUI, EASIE JBoss Plugin, EASIE Orion/Oracle 9iAS Plugin, EASIE Weblogic Plugin, EASIE Wepsphere Plugin, Easy Struts, EclipseAxis, EJBBuilder, JBoss-IDE... Una comparación crítica entre ellos queda fuera del objetivo de este artículo, pero me permito llamar la atención sobre dos de ellos: Lomboz y JBoss-IDE. Lomboz es un plug-in J2EE que permite construir aplicaciones web con páginas HTML, JSPs y servlets. Incorpora un editor para JSPs con sintaxis coloreada, asistente para código y comprobación de la sintaxis. Varios asistentes y generadores de código facilitan el trabajo con EJBs, y cuenta con la interesante característica de permitir la depuración de código JSP y EJB desde el depurador de Eclipse. Lomboz es gratuito para fines no comerciales. Por otro lado, JBoss-IDE ofrece un IDE para controlar el conocido servidor JBoss desde el Workspace de Eclipse; se distribuye bajo licencia CPL.

Para XML existen numerosos plug-ins comerciales y open source: eclipsetydy, Improve XSLT, JMXLEditor, MetaCoder ...

Para el análisis y diseño de software mediante UML ya hay disponibles varios plug-ins open source para la plataforma Eclipse: EMF,

Fig. 9. Al guardar una clase, Eclipse muestra los errores cometidos en el código.



magicdraw, OMONDO y Slime UML. Ofrecen, en general, las utilidades habituales: generación de diagramas UML, ingeniería inversa, generación de código a partir de los diagramas de clases, etcétera.

10. Eclipse y Visual Age for Java: una sensación déjà vú, pero sólo una sensación. El reemplazo generacional llega a IBM. ¿Cómo encaja Eclipse en la nueva generación de herramientas de IBM?

Los desarrolladores que hayan trabajado con Visual Age for Java notarán algunas similitudes al trabajar con Eclipse. Muchos de los asistentes son iguales y también algunos botones (como el del hombre que corre o el que muestra un insecto; tienen asociadas las acciones de iniciar la ejecución del programa y arrancar el depurador, respectivamente).

Internamente, sin embargo, hay muchas diferencias. La lista sería muy larga, pero las más relevantes son éstas:

� Eclipse se basa en ficheros individuales, muchos de los cuales tienen formato ASCII y, por tanto, son accesibles a otras herramientas. En Eclipse, IBM ha abandonado el repository propietario (EMSRV - ENVY) que usó para Visual Age for Java (tal y como se ha visto en el apartado anterior, Eclipse usa CVS de forma estándar). Para ejecutar o distribuir el código fuente en VAJ, debe exportarse el código al sistema de ficheros de la máquina donde vaya a ser utilizado. Nadie que manejara el repository propietario lo echará en falta; su insidiosa tendencia a corromperse era uno de los mayores problemas de los usuarios de VAJ, pero no el único: su excesivo consumo de espacio en el disco duro, y su complejo sistema de mantenimiento y administración tampoco contribuyeron a hacerle popular entre los desarrolladores. Una confesión personal: el único momento en que el repository de VAJ me dio una alegría fue cuando me dijeron que ya no iba a necesitar usarlo.

� Eclipse es mucho más configurable para diferentes máquinas virtuales Java que VAJ. Visual Age for Java emplea una máquina virtual llamada UVM (Universal Virtual Machine, Máquina Virtual Universal) que permite ejecutar código Java y código SmallTalk. La UVM es propiedad de IBM y el usuario de VAJ no puede utilizar ninguna otra máquina virtual. Eclipse, en contraste, permite elegir para la ejecución la máquina virtual Java que se desee, desde la versión 1.1.7 del JRE a la versión 1.4, sin excluir máquinas virtuales hechas a medida, como la J9 VM de IBM para dispositivos embebidos. Esta posibilidad, ausente en VAJ, resulta muy ventajosa para los programadores: pueden elegir el JRE que vaya a emplear el usuario final, sin depender de las actualizaciones, por parte de IBM, de la UVM. Existe un pequeño matiz de carácter técnico: Eclipse usa un compilador interno, al igual que VAJ, pero el conjunto de clases contra el cual se compila el código fuente es el establecido por el usuario en Preferences/Installed JREs.

� VAJ permite la generación y distribución de Enterprise JavaBeans, Java Server Pages y servlets, incluye asistentes tanto para la generación como para la distribución de EJBs, y soporta de serie la plataforma J2EE. Por citar ejemplos concretos, la última versión de VAJ incluye un Entorno de pruebas WebSphere (WebSphere Test Environment), un servidor EJB, un depurador integrado para servlets, EJBs y JavaBeans, y un monitor de ejecución para JSPs. Todo lo necesario, en definitiva, para desarrollar aplicaciones J2EE dentro de un único entorno de desarrollo integrado.

[Nota técnica: Un repository (almacén de datos) en programación es, en esencia, una base de datos que almacena código y material complementario (documentación, imágenes, etc.). Cuando se usa un repository, el código fuente con el que se trabaja se almacena en la base de datos y se extrae de él cuando se necesita.El código se almacena en el repository, no en ficheros. Este sistema de almacenamiento ofrece ventajas para los lenguajes orientados a objetos, pues resulta más fácil seguir la pista a las clases, con sus relaciones de herencia, en una base de datos. Además, la estructura de una base de datos se muestra idónea para llevar un control de las versiones y para la programación en equipo. Al ser el repository una base de datos se necesita configurarlo y mantenerlo a lo largo del tiempo.]

La actual generación de herramientas de desarrollo de IBM (WebSphere Studio Application Developer, Websphere Studio Site Developer, WebSphere Studio Enterprise Developer, Websphere Studio Workbench, etc.) se basa en Java, al igual que los productos de la familia Visual Age se basaban en Smalltalk. IBM está reemplazando, tanto interna como externamente, sus productos de la familia Visual Age y WebSphere Studio por los nuevos productos basados en Eclipse. IBM ha abandonado ya Visual Age for Java en favor de sus nuevos productos basados en Eclipse; no habrá nuevas versiones de VAJ, aunque continuará dándole soporte durante un tiempo.

Los motivos de esta nueva estrategia basada en Eclipse obedecen a una suerte de relevo generacional tecnológico: Visual Age for Java y Websphere Studio se crearon en una época en la que las páginas web eran páginas HTML servidas por CGIs (Common Gateways Interfaces). Hablo de época aunque sé que no han pasado muchos años, pero si comparásemos las tecnologías actuales con las de hace diez o veinte años, parecería que éstas últimas han salido de otra época, casi de una Edad Media incrustada en el siglo XX. En aquel entonces, gracias a los applets, Java alcanzó una gran popularidad en el lado del cliente. El panorama actual apenas guarda parecido con el de hace diez años: las páginas web actuales incluyen vídeo de alta resolución, animaciones, sonidos, HTML dinámico... Las redes de fibra óptica, extendidas ahora por todo el mundo, permiten olvidarse de las limitaciones de una Internet que daba sus primeros balbuceos, y posibilitan la inclusión de recursos multimedia, no sólo de texto e imágenes. También para Java ha pasado el tiempo: los applets han caído en desuso, y el lenguaje, ya maduro, se ha hecho fuerte en el lado del servidor. La plataforma J2EE, que comenzó a existir cuando ya se habían lanzado las primeras versiones de Visual Age y WebSphere Studio, ha crecido mucho y en direcciones muy distintas: servlets, JSPs, EJBs, XML, etc.

A toda herramienta, como a toda tecnología, le llega un momento en que intentar seguir expandiéndola resulta similar a pretender aumentar el volumen cerebral de un dinosaurio condenado a la extinción. IBM, consciente de que no hay tecnología que cien años dure, decidió -tal como se vio en la primera parte de este artículo- abandonar Visual Age for Java y WebSphere Studio, y construyó la plataforma Eclipse, escrita en Java, como base para su nueva generación de herramientas.

WebSphere Studio Site Developer y WebSphere Studio Application Developer han sido los primeros productos de la nueva familia WebSphere Studio que han visto la luz; forman parte de la nueva generación de herramientas de desarrollo de aplicaciones web construida sobre Eclipse. IBM distribuye su propia versión comercial de Eclipse (WebSphere Studio Workbench), que actúa como base de la nueva familia WebSphere Studio y de las futuras herramientas middleware de IBM. WebSphere Studio Site Developer permite el desarrollo de sitios web dinámicos (con servlets, XML, JSPs, servicios Web, etc.)

WebSphere Studio Application Developer va varios pasos por delante del Site Developer: permite el desarrollo de aplicaciones J2EE y de bases de datos en un entorno de programación en equipo. Incluye todas las funciones del Site Developer y permite la creación y distribución de EJBs, incorpora asistentes para conexiones a bases de datos y permite usar el servidor de aplicaciones de IBM (WebSphere Application Server) para efectuar pruebas. Dar una descripción exacta de todas sus capacidades escapa a los propósitos



de este artículo, pero el repertorio de asistentes para XML, para la creación de bases de datos, para la implementación de consultas a bases de datos y para J2EE deslumbra por su extensión. WS Application Developer es un producto hecho por y para profesionales, además de ser una de las herramientas más completas que existen en el mercado.

Eclipse (en su versión comercial WS Workbench) constituye el núcleo de estas herramientas. Aunque WS Application Developer es una herramienta excelente, todas sus virtudes y funcionalidades derivan de una misma base: Eclipse. Cualquier programador o programadora puede añadir al SDK estándar de Eclipse los plug-ins -propietarios, open source o free software- que desee, y obtener un producto final comparable a WS Application Developer (o incluso más adaptado a sus necesidades). Los productos comerciales de IBM son derivaciones concretas de Eclipse, pero no tienen virtudes intrínsecas que no puedan obtenerse ensamblando plug-ins. IBM cuenta con la baza de proporcionar asesoramiento, asistencia técnica y soluciones personalizadas; no se limita a proporcionar el producto, pero sus herramientas basadas en Eclipse no tienen ninguna bendición papal: forman parte de la miríada de productos que cualquiera puede formar alrededor del archipiélago Eclipse.

La obsesión de IBM por el software open source es demasiado racional para figurar dentro del índice de Introducción a la Psiquiatría Moderna, en algún lugar entre Obsesiones-compulsiones y Paranoia. El fracaso de Eclipse implicaría el fracaso de toda la nueva gama de productos de IBM basados en él, y el adiós definitivo a su permanencia como líder en el mercado de herramientas de desarrollo. La competencia es demasiado fuerte y competitiva como para que IBM pueda conseguir una segunda oportunidad; Eclipse no forma parte de una de sus estrategias: es la Estrategia. Honradamente, no lanzar Eclipse bajo la licencia open source sí hubiera merecido estar en el índice de Introducción a la Psiquiatría Moderna, por algún lugar entre Lo-tuyo-no-son-los-negocios (Síndrome de) y Narcisismo. Esta opción hubiera entrañado el riesgo -tremendamente real- de quedarse descolgado del proceso de creación de herramientas, proceso cada vez más comunitario, y de llegar solamente a la porción de desarrolladores que ya utilizaban productos de IBM.

Los cuarenta millones de dólares invertidos en Eclipse acabarán dando buenos dividendos a IBM; probablemente no obtendrá de ellos la rentabilidad que algunos y algunas consiguieron con las punto com antes del hundimiento del mercado -al más puro estilo Titanic-, un hundimiento tan previsible e inevitable como la implosión del boom inmobiliario en Japón durante la década de los noventa, pero conseguirá mayor rentabilidad que la que proporcionan los bonos cupón cero del Tesoro de los Estados Unidos. Si IBM no pensara así, hubiera invertido el dinero en estos bonos y se hubiera limitado a esperar mejores tiempos antes de sacar al mercado su nueva generación de herramientas de desarrollo. Explicar a los gestores de fondos de pensiones estadounidenses, con cientos de millones de dólares invertidos en acciones de blue chips, que IBM dona dinero por puro y sincero amor al desarrollo y progreso del software hubiera sido incómodo, cuanto menos. Los gestores hubieran sentido en sus oídos las mismas punzadas de dolor, aparejadas a la sensación común de que alguien les estaba hurgando en los bolsillos, que sufrieron los ejecutivos de RCA cuando Lou Reed les dio a escuchar Metal Machine Music (intentaron sacarlo en la serie clásica, pero el bueno de Lou se opuso, arguyendo que hubiera sido pretencioso). Cuando las empresas punto com estaban en la cúspide -dislumbrada, alcanzada y pronto olvidada, como un mal sueño-, hasta las sillas subían en bolsa, pero no las donaciones en las que no se veía recompensa, presente o futura, alguna. Habrá que esperar... y ver.

11. Eclipse y su énfasis en la calidad del software

Tal y como se comentó en el apartado 2, una herramienta de desarrollo integrado debería ayudar a los desarrolladores en todas las etapas del ciclo de vida del software. Rational Software (miembro de la junta directiva de Eclipse.org y cuya adquisición por parte de IBM finalizó en enero de este año) tiene su metodología RUP (Rational Unified Process), un proceso unificado de desarrollo de software que utiliza UML y se sostiene sobre tres ideas básicas: casos de uso, arquitectura y desarrollo iterativo e incremental. De acuerdo con la metodología RUP, el proceso unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema software. Cada ciclo debe tener los siguientes modelos:

� Un modelo de casos de uso

� Un modelo de análisis

Fig. 10. Eclipse dentro de la familia WebSphere de IBM



� Un modelo de diseño

� Un modelo de implementación

� Un modelo de despliegue o distribución

� Un modelo de prueba

En consecuencia, los flujos de trabajo de cada ciclo, según esta metodología, son cinco: requisitos, análisis, diseño, implementación y prueba.

Independientemente de la metodología seguida, los cinco flujos de trabajo expuestos suelen formar parte del desarrollo de software. Desde luego, Rational Software tiene su propia herramienta de desarrollo de acuerdo con RUP, pero resulta difícil encontrar IDEs que ayuden a los desarrolladores en todos los flujos de trabajo. Por ello, resulta fundamental la extensibilidad de los productos. En ese aspecto, Eclipse -debido a su arquitectura abierta- permite acoplar mediante plug-ins tantas herramientas de apoyo (open source o comerciales) como el desarrollador necesite, de manera que éste, independientemente de la metodología concreta usada, pueda conseguir con Eclipse su propio IDE, personalizado a sus necesidades. Por ejemplo, los desarrolladores pueden incorporar a Eclipse herramientas de distintos vendedores (un IDE no estándar, una herramienta de modelado UML, un framework de pruebas como JUnit, un editor de XML o de HTML, una herramienta como Ant, etc.) y beneficiarse así de una apariencia común y un control integrado para todas las herramientas.

De hecho, la versión estándar de Eclipse incluye una biblioteca de refactorización de código Java, utilizable a través de un sencillo interfaz para el usuario. Erich Gamma, uno de los grandes especialistas del momento en patrones y refactorización, forma parte del proyecto Eclipse.

Eclipse rompe, posiblemente debido a la participación de Rational Software y de TogetherSoft, con una larga -y justificada- tradición de que las herramientas de desarrollo de software aceleran el desarrollo de software al precio de conseguir diseños pobres, poco escalables y que suelen requerir un mantenimiento excesivo cuando los sistemas van creciendo, al permitir preocuparse tanto de la calidad del software como de su diseño, y no únicamente de la productividad inmediata.

Otras herramientas Java (JBuilder 7 y 8, IDEA de Intellij, por ejemplo) también proporcionan soporte a la refactorización del software, pero -por ahora- sólo Eclipse muestra tan claramente la importancia que los patrones y la refactorización han tenido en su propia construcción y sólo Eclipse, por su arquitectura abierta, permite integrar tantas herramientas para mejorar la calidad del software, facilitar los procesos de análisis y diseño, y documentar estas etapas.

12. La estructura de la plataforma Eclipse: una vista subterránea

Un concepto fundamental de Eclipse, necesario para comprender lo que sigue, es el de recurso. En Eclipse, un recurso básico es simplemente un fichero ASCII que contiene código fuente para un lenguaje de programación.

La plataforma Eclipse se compone de 6 grandes componentes:

� 1) El Platform runtime, que se encarga de gestionar los recursos y los plug-ins, además de permitir el arranque de la plataforma. Cuando se arranca Eclipse, este componente se encarga de buscar los ficheros de manifiestos de los plug-ins (que son archivos XML que describen los plug-ins), y carga esta información en un registro. Solamente cuando se requiere por primera vez un plug-in, el Platform runtime lo ejecuta; este componente descubre de forma dinámica plug-ins durante el tiempo de ejecución. Grosso modo, el Platform runtime define los puntos de extensión y el modelo de plug-ins.

� 2) El Workspace (Espacio de trabajo) permite gestionar el acceso a ficheros tanto a alto como a bajo nivel. Actúa como un componente que encapsulara la gestión de archivos, permitiendo que los plug-ins utilicen sus métodos sin tener que trabajar directamente con distintos sistemas de archivos, según la plataforma que se utilice.

� 3) El Workbench (Banco de trabajo) se encarga de la presentación de la información al usuario y de la gestión del diálogo con el mismo. Proporciona la interfaz gráfica de Eclipse y constituye uno de sus puntos más cuidados y atractivos. Resulta difícil no dejarse seducir por su apariencia, aunque uno se haya curtido en un entorno de línea de comandos y haya jurado no mirar de reojo, bajo pena de extirpación ocular, a cualquier cosa similar a una ventana en un monitor. Desde el punto de vista del usuario una ventana del Workbench consiste en vistas y editores. Tanto la API como la implementación del Workbench se han realizado mediante SWT y JFace.

El SWT se explicará más adelante, pero puede adelantarse que es -fundamentalmente- una biblioteca encargada de proporcionar los componentes gráficos (botones, listas, cuadros de texto, etc.), y que permite obtener una interfaz gráfica muy integrada con la plataforma nativa bajo la cual se use Eclipse. ¿Por qué utilizar una nueva biblioteca gráfica? La pregunta se contestará en la próxima entrega del artículo, pero aquí va un adelanto: porque esta biblioteca permite crear interfaces de usuario nativas, utilizando las capacidades gráficas del sistema operativo y del sistema gráfico de ventanas que se esté usando, a cambio de ciertos inconvenientes que ya veremos. JFace proporciona una interfaz de más alto nivel que la del SWT, basada en los componentes SWT, y lleva incorporadas muchas facilidades para usar con los plug-ins (preferencias, asistentes, etc.), además de definir frameworks muy útiles, como el modelo MVC (Model View Controller).

� 4) El componente de ayuda (Help) permite a los plug-ins proporcionar documentación HTML que pueda ser presentada contextualmente por el Workbench.

� 5) El componente de equipo (Team o Team support) define un modelo de programación en equipo para crear y mantener un registro de las versiones de las aplicaciones que se desarrollen. Este componente permite que diferentes plug-ins de repositorys (véase la nota técnica del Apdo. 10) convivan dentro de la plataforma. Asimismo, añade las vistas que el usuario necesite para interaccionar con cualquier sistema de control de versiones (si hay alguno) que se esté usando. Tal y como se ha mencionado ya, Eclipse incluye de forma estándar un plug-in CVS, pero pueden añadirse repositorys como ChangeMan (Serena), ClearCase (Rational), CM Synergy (Telelogic), PVCS (Merant) y StarTeam (Starbase). Independientemente del VCM (Version Control System) que se use, la interfaz de usuario no cambia.



� 6) El componente de depuración (Debug) proporciona un modelo genérico de depuración, en el que se permiten expresiones, puntos de interrupción, acciones habituales de depuración, etc., junto a una interfaz gráfica genérica de depuración. Cualquier plug-in puede aprovechar los mecanismos de depuración que proporciona este componente.

El Workspace o espacio de trabajo refleja el estado actual de los proyectos locales, con su código fuente y sus ficheros compilados, que estén en la memoria activa. Al cerrar Eclipse se guarda el estado actual del Workspace local, de modo que cuando se reinicia Eclipse vuelve al estado en que se cerró.

El Workbench o banco de trabajo proporciona lo siguiente:

� Editores: Un editor es un componente que permite interaccionar con los contenidos de un fichero (no sólo con el código fuente, sino también con su fichero XML asociado, sus propiedades, etc.) y modificarlos.

� Vistas: Una vista proporciona metadatos sobre el recurso que se haya seleccionado: organización de un recurso dentro de un paquete o proyecto, estado de la compilación, etc.

� Perspectivas: Una perspectiva representa una configuración de editores y vistas relacionadas, al igual que opciones de menú y de compilación. Hay tres perspectivas estándar en Eclipse (CVS, Install/Update y Resource), pero usando plug-ins pueden añadirse otras nuevas. Al cambiar una perspectiva por otra se muestran diferentes editores, vistas y opciones de menú.

Fig. 11. Arquitectura de la plataforma Eclipse. Extraído de la documentación oficial de Eclipse.



El único de los seis componentes de Eclipse que no es un plug-in es el Platform runtime. Los otros cinco componentes son plug-ins: adondequiera que dirijamos la mirada divisaremos plug-ins flotando en las apacibles aguas del archipiélago Eclipse. Cualquier plug-in susceptible de incorporarse a Eclipse se integra con éste de la misma manera que cualesquiera de los plug-ins que incluye de forma estándar. El Workbench y el Workspace son dos plug-ins indispensables porque proporcionan puntos de extensión usados por casi todos los plug-ins, pero su funcionamiento no difiere del de otros plug-ins.

13. AWT y Swing: Repaso de los hechos

Para entender por qué IBM optó por utilizar el SWT (Standard Widget Toolkit) en Eclipse conviene repasar, muy rápidamente, las limitaciones del AWT y Swing.

El AWT (Advanced Widget Toolkit) de Java utiliza widgets (componentes gráficos de la interfaz de usuario) nativos para los widgets que existen en todas las plataformas (botones, etiquetas, etc.), pero olvida necesariamente aquellos componentes que existen en una plataforma pero no en otras. Por ejemplo, los widgets tipo árbol (tree), tabla (table) y ToolBar, que son widgets nativos de Windows, no están incluidos en el AWT, pues no hay widgets árbol y tabla en plataformas como Motif.

Es importante comprender, al menos someramente, la estructura del AWT para comprender el distinto enfoque que aporta el SWT de Eclipse. El AWT usa una arquitectura peer: Cada componente AWT crea un objeto paralelo llamado su peer (igual). Los objetos peer implementan interfaces en el paquete Java java.awt.peer. Por ejemplo, cada java.awt.Label usa un objeto peer que implementa java.awt.peer.LabelPeer. A cada componente AWT le corresponde una clase peer escrita en el código nativo del sistema (C habitualmente), por lo que los componentes AWT son, por construcción, dependientes de la plataforma. Cada widget del AWT no se dibuja a sí mismo, sino que es su objeto peer asociado (y nativo) el que interacciona con los widgets nativos de la API gráfica del sistema operativo subyacente, que se encargan de dibujar y controlar los eventos del widget AWT.

En la implementación de Motif -un buen ejemplo para entender la arquitectura peer del AWT-, a cada clase AWT le corresponde un fichero C y cada método nativo AWT cuenta con una implementación en C, con el código común almacenado en ficheros separados.

La encapsulación que hace el AWT de los widgets nativos de la API gráfica del sistema operativo es totalmente opaca: el código que interacciona con los widgets nativos de la plataforma está escrito en C y no es accesible directamente.

Fig. 12. Ventana del Workbench y sus elementos. Traducido de la documentación oficial de Eclipse.



El AWT cuenta con muchos inconvenientes: la lentitud (muy notable cuando se usan simultáneamente muchos componentes), la imposibilidad de cambiar estática o dinámicamente la apariencia de los componentes, su dependencia de la plataforma y su limitación, por decisiones de diseño, a permitir trabajar sólo con un pequeño conjunto de componentes comunes a todas las plataformas. Además, no resulta adecuado para construir aplicaciones profesionales, pues da un aire un tanto naïf a las aplicaciones. Sin embargo, los componentes AWT fueron los responsables de la rápida expansión inicial de Java, al ser muy sencillos de usar. A veces, menos resulta más.

Swing, que fue introducido con Java 1.2, y en cuyo desarrollo participaron Netscape e IBM, utiliza la interfaz entre el sistema gráfico de ventanas del sistema operativo subyacente y los componentes GUI de Java que proporciona el AWT, pero únicamente la interfaz. Es decir, no usa los componentes AWT para -mediante los objetos peer- manipular los widgets nativos, sino que utiliza sus propios componentes, escritos en Java. Los desarrolladores de Sun reescribieron en Java, desde cero, todos los widgets para Swing. Al estar escritos en Java, los componentes Swing son independientes del sistema de ventanas nativo y pueden ejecutarse en cualquier plataforma cuyo sistema de ventanas admita AWT.

Swing, a diferencia del AWT, permite cambiar rápida y fácilmente el aspecto y la sensación (Look&Feel) de un componente o grupo de componentes. El aspecto y sensación de una aplicación consiste en el modo en que se presenta al usuario (su aspecto) y en la forma en que permite que el usuario interaccione con ella (su sensación). Swing incorpora los aspectos y sensaciones Basic, Mac, Motif, Windows, Organic y Metal. A diferencia también del AWT, Swing tiene sus propias implementaciones Java de los widgets y no depende de los widgets nativos, por lo que permite una mayor flexibilidad.

Las principales desventajas de Swing son:

� Alto consumo de recursos del sistema.

� Lentitud con respecto a las aplicaciones nativas.

� Tamaño muy grande de la biblioteca.

� Diferencias perceptibles en aspecto y sensación con respecto a las aplicaciones nativas y ausencia de soporte de características nativas.

Con respecto al último punto, la posibilidad de usar el L&F más adecuado para la plataforma que se esté usando permite realizar aplicaciones Java que se parezcan bastante a las nativas, pero suelen haber diferencias importantes en cuanto a la sensación (el modo en que se gestiona la interacción del usuario). A veces da la sensación de que Sun se olvidó de los eventos nativos y definió los suyos propios, al margen de la realidad de cada plataforma, lo que ocasiona comportamientos inesperados tanto para usuarios como para desarrolladores. Existe también una dificultad adicional: al usar en una aplicación un L&F similar al de una plataforma dada, Swing debe simular el L&F, con el consumo adicional de recursos, la lentitud y, en ocasiones, el comportamiento anómalo con respecto a las interfaces nativas que conlleva esta simulación.

En la versión 1.4 de Java se han reescrito los algoritmos gráficos, con lo que Swing corre más rápido que en versiones anteriores, pero dista mucho, salvo en condiciones muy específicas, de igualar en velocidad a las aplicaciones nativas. El consumo de recursos (en particular de memoria) que hace Swing en esta versión sigue siendo alto, como se puede notar si se ejecutan simultáneamente varias aplicaciones con muchos componentes Swing.

Están previstas nuevos L&F para Java 1.4.2 (tipo Windows XP y GTK) y Java 1.5 (un nuevo L&F, actual y moderno, para todas las plataformas, similar al L&F Metal de Swing), pero el futuro -a la vista de los resultados anteriores- no se presagia excesivamente prometedor.

[Fin de la segunda parte]

Fig. 13. El AWT de Java. Utiliza una arquitectura "peer", que el SWT de Eclipse evita.



Acerca del autor

Miguel Ángel Abián Miguel Ángel Abián nació en Soria. Obtuvo la suficiencia investigadora en el Dpto. de Física Aplicada de la Universidad de Valencia con una tesina sobre electromagnetismo. Realizó varios cursos de doctorado relacionados con electromagnetismo, electrónica, semiconductores y cristales fotónicos. Ha recibido becas del IMPIVA (Instituto de la Mediana y Pequeña Industria Valenciana) y de la Universidad Politécnica de Valencia. Cursó un Máster estadounidense en UML y Java y otro sobre tecnologías de Internet/Intranet. Se incorporó en 1998 a AIDIMA, donde ha participado como investigador en 24 proyectos de investigación nacionales e internacionales relacionados con la Web semántica, tecnologías de la información, madera en construcción, biosensórica, bioelectrónica, telecomunicaciones, visión artificial; así como en la Red de Excelencia de la Comisión Europea INTEROP 2003-2007. Algunos de los proyectos europeos relacionados con las tecnologías semánticas en los que ha participado son ATHENA y STASIS (http://www.stasis-project.net/). El año 2006 estuvo cuatro meses como investigador invitado en el departamento Lehrstuhl für Messsystem und Sensortechnik de la Universidad Politécnica de Munich (TUM), donde colaboró en el desarrollo de nuevos métodos para la detección de defectos en superficies acabadas y en el diseño e implementación de sistemas distribuidos de sensores para el sector del automóvil y de energías renovables. En 2007 recibió un premio BANCAJA-UPV por un proyecto relacionado con la calidad interna de la madera. En 2009 recibió el premio internacional Schweighofer Innovation Prize -el premio más prestigioso en el sector forestal y de la madera- por su aportación al desarrollo de nuevas tecnologías de evaluación no destructiva de la madera en construcción. Actualmente es Responsable del Departamento de Tecnología y Biotecnología de la Madera y del Área de Construcción de Madera. Es coautor de 7 libros y guías técnicas relacionadas con el uso de la madera en la construcción y la visión artificial. También ha publicado varios artículos científicos en revistas como IEEE Transactions on Microwave Theory and Techniques y Wood Science and Technology. Ha participado como ponente en congresos y conferencias como European Congress on Computational Methods in Applied Sciences and Engineering, IEEE International Conference on Multisensor Fusion and Integration for Intelligent Systems, International Conference on Space Structures (IABSE-IASS) y en reuniones COST (European Cooperation in Science and Technology). Ha publicado más de 22 artículos técnicos en revistas sectoriales y técnicas. Es autor o coautor de 8 patentes, algunas de ellas en trámite. Tres de ellas corresponden a dispositivos y métodos para detectar la biodegradación de la madera en construcción. Actualmente, entre otros proyectos como SHBUILDINGS, WOODTECH, WOODRUB y CELLUWOOD, ha trabajado en SEMCONCEPT, un proyecto de I+D+i para aplicar tecnologías semánticas (ontologías, buscadores semánticos) en el diseño conceptual de productos industriales. Sus intereses actuales son la evolución de la programación orientada a objetos, Java, la Web semántica y sus tecnologías, la arquitectura orgánica, el surrealismo y París, siempre París.

