El archipielago Eclipse, 2º Parte
lunes, mayo 19, 2003 at 2:00AM EL ARCHIPIÉLAGO ECLIPSE (PARTE 2 DE 4)
Fecha de creación: 10.04.2003
Revisión 1.0 (10.04.2003)
Miguel Ángel Abián
mabian AT aidima DOT es
|
Introducción
"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 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.
| Carencias de Eclpise |
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.
 |
| Figura 8: El asistente de contenido de Eclipse |
 |
| Figura 9: Al guardar una clase, Eclipse muestra los errores cometidos |
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,
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.]
| Diferencias más relevantes entre Eclipse y VAJ |
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.
 |
| Figura 10: Eclipse dentro de la familia WebSphere de IBM |
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 miles 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
- Un modelo de diseño
- Un modelo de implementación
- Un modelo de despliegue o distribución
- Un modelo de prueba
| Modelos dentro de un ciclo de RUP |
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:
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.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.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).El componente de ayuda (
Help) permite a los plug-ins proporcionar documentación HTML
que pueda ser presentada contextualmente por el
Workbench.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.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.
| Componentes de la plataforma Eclipse |
 |
| Figura 11: Arquitectura de la plataforma Eclipse |
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ú.
| Funciones del Workbench |
 |
| Figura 12: Ventana del Workbench y sus elementos |
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.
 |
| Figura 13: El AWT |
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.
| Desventajas de Swing |
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]
Recursos
[1] Primer artículo de la serie.,
/articles.article.action?id=75
Acerca del autor
Miguel Ángel Abián
Miguel Ángel Abián
Miguel Ángel Abián nació en Soria (1972). Se licenció en
Ciencias Físicas en 1995 por la U. de Valencia y consiguió la
suficiencia investigadora en 1997 dentro del Dpto. Física Aplicada
de la U.V. Además ha realizado diversos cursos de Postgrado sobre
bases de datos, lenguajes de programación Web, sistemas Unix, UML y
Java. Ha participado en diversos programas de investigación TIC
relacionados con el estudio de fibras ópticas y cristales
fotónicos, y ha publicado diversos artículos en el IEEE
Transactions on Microwave Theory and Techniques relacionados con el
análisis de guías de onda inhomogeneas y guías de onda elípticas.
Laboralmente ha trabajado como gestor de carteras y asesor
fiscal para una agencia de bolsa y ahora trabaja en el Laboratorio
del Mueble Acabado de AIDIMA (Instituto Tecnológico del Mueble y
Afines), ubicado en Paterna (Valencia), en tareas de normalización
y certificación. En dicho centro se están desarrollando proyectos
europeos de comercio electrónico B2B para la industria del mueble
basados en Java y XML (más información en
www.aidima.es).
Sus intereses actuales son: el diseño asistido por ordenador
de guías de ondas y cristales fotónicos, la evolución de la
programación orientada a objetos, Java, el surrealismo y París,
siempre París.
Reader Comments