Artículo 1 sobre la plataforma ECLIPSE

EL ARCHIPIÉLAGO ECLIPSE (PARTE 1 DE 4)

Fecha de última revisión: 21.05.2014

Miguel Ángel Abián mabian ARROBA aidima PUNTO es

ECLIPSE. (Del lat. eclipsis, y éste del gr. ékleipsis, de e kleípein, abandonar.). m. Astron. Oscurecimiento del sol o de un cuerpo celes te por interposición de otro astro que le oculta directamente o que infiere la luz que le ilumina. [Diccionario Enciclopédico SALVAT Universal]

1. Introducción

El artículo El archipiélago Eclipse pretende exponer qué es Eclipse, cuál es su estructura, en qué se diferencia o se asemeja a otros productos ya existentes, cuáles son sus ventajas e inconvenientes, cuál podría ser su utilidad para los desarrolladores (centrándose en la comunidad Java), qué estrategias empresariales subyacen bajo el proyecto Eclipse y cuál podría ser su futuro. Debido a su extensión, unas diecisiete mil palabras, se publicará dividido en cuatro partes.

En este artículo no se explica cómo utilizar Eclipse o cómo desarrollar aplicaciones Java con él, pues existe una amplia documentación acerca de estos temas en la ayuda del producto y en http://www.eclipse.org. Sin embargo, existe poca información -y toda en inglés- acerca de algunos de los puntos señalados arriba; además, mucha de esta escasa información está claramente sesgada, por motivos de estrategia comercial y empresarial, a favor o en contra del producto. Para obtener una valoración imparcial de Eclipse es obligatorio leer a menudo entre líneas, comprobar y contrastar cada afirmación, prestar atención a lo sobreentendido -que suele ser lo importante- y probar muchos productos.

El archipiélago Eclipse trata de cubrir este hueco informativo, de una manera independiente e imparcial. Hueco absoluto, por lo que sé, en nuestro idioma. Quizá no lo consiga, pero al menos mostrará la punta del iceberg, y espero sinceramente que anime a algunos desarrolladores a contarnos sus experiencias con Eclipse y sus opiniones.

Aclarado el objetivo del artículo, es el momento de comenzar el recorrido por los islotes que pueblan el archipiélago Eclipse.

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/).

of 12javaHispano. ECLIPSE

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

2. Los entornos de desarrollo integrado (IDEs)

Los desarrolladores de software se dividen en dos tipos: los que usan entornos de desarrollo integrado o IDEs (Integrated Development Environments) y los que no. Estos últimos prefieren un editor de texto (como Emacs o el Bloc de notas), un compilador y un depurador. Los pertenecientes al primer tipo, sin embargo, prefieren usar IDEs para ayudarles a la generación del código y a la construcción de proyectos. Tarde o temprano, independientemente del grupo al cual pertenezcan, todos se enfrentan a sus propios problemas.

No hace mucho (cronológicamente hablando, que no tecnológicamente), la única manera de desarrollar aplicaciones en C, COBOL o Fortran era recurrir a un editor de texto, un compilador y un depurador. Con la llegada de los lenguajes de cuarta generación, comenzaron a aparecer las primeras herramientas de desarrollo integrado, muy primitivas comparadas con las que podemos encontrar ahora (ya sea gratuita o comercialmente).

Cualquier entorno actual de desarrollo integrado ofrece, al menos, el control del editor de código, del compilador y del depurador desde una única interfaz de usuario. Su misión consiste en evitar tareas repetitivas, facilitar la escritura de código correcto, disminuir el tiempo de depuración e incrementar la productividad del desarrollador. Estas tareas pueden realizarse de muchas maneras distintas: mediante la inclusión de asistentes para las tareas más habituales y mecánicas, de editores que completen automáticamente el código y señalen los errores sintácticos, de gestores de archivos fuente, etc.

En teoría, un entorno de desarrollo integrado o IDE debería aportar funcionalidades al desarrollador durante todas las etapas del ciclo de vida del desarrollo de software (desde el análisis y diseño a la distribución del producto y su mantenimiento), de ahí la palabra "integrado". En la práctica, solamente los IDEs más modernos cumplen esta condición y, a menudo, de forma incompleta.

Después del impresionante éxito de Visual Basic, ha sido frecuente asumir que los IDEs necesitan incluir herramientas visuales de generación de interfaces de usuario (GUI builders), pero esta premisa resulta inexacta. Algunos IDEs carecen de diseñadores gráficos visuales y no por ello dejan de ser excelentes. En el caso específico de Java, la mayor parte de las aplicaciones actuales se ejecutan en el lado del servidor y no precisan interfaz gráfico. Muchas veces resulta más conveniente disponer de un buen editor JSP/HTML que de un vistoso diseñador gráfico.

Los IDEs, por supuesto, también tienen sus desventajas: en comparación con el clásico triunvirato editor de texto-compilador-depurador consumen muchísimos más recursos, tienden a ser lentos (particularmente los escritos en Java) y su manejo requiere un cierto aprendizaje que se tira a la papelera cuando se pasa a otro IDE, debido a la heterogeneidad de los IDEs que proliferan en el mercado. Algunos IDEs son sumamente complejos de manejar, incluso para llevar a cabo las tareas aparentemente más sencillas; en otros los manuales demuestran al indefenso lector el odio, desinterés y ausencia de motivación pedagógica que deben de sentir aquellos que los escriben. En

Fig. 1. Eclipse como pentagrama. La figura muestra distintas facetas de Eclipse, que se abordarán a lo largo del artículo.



ocasiones, cuando generan código, es mejor mirar hacia otra parte o empezar de cero.

Todavía no existe un IDE universal o perfecto, capaz de reunir todas las características que un desarrollador puede necesitar. Por lo general, los puntos débiles de un IDE coinciden con los puntos fuertes de otro. Un buen ejemplo lo proporciona la comparación entre WebSphere Studio Application Developer (de IBM) y JBuilder (de Borland). JBuilder posee un excelente diseñador de interfaces gráficas para el usuario y proporciona una vista de la estructura jerárquica de los formularios que muestra todos los componentes visuales (botones, cuadros de texto,...) organizados por contenedores. WebSphere Studio Application Developer proporciona, en comparación, un diseñador gráfico mucho más simple, pero ofrece un editor JSP/HTML magnífico (uno de los mejores, si no el mejor, del mercado), que permite insertar componentes visuales, componentes ActiveX o imágenes, y ver la vista previa de las páginas web, entre otras muchas características. El editor HTML de JBuilder se limita, en cambio, a poco más que colorear las palabras reservadas.

Como puede extrapolarse a partir del ejemplo anterior, el desarrollador que trabaje en varios campos simultáneamente (desarrollo de servicios Web, creación de Enterprise JavaBeans, diseño de páginas web, edición de XML) necesitará usar varios IDEs o herramientas para trabajar de forma óptima.

En algunas ocasiones, la elección del IDE por parte de los desarrolladores no es libre, sino que está condicionada por decisiones previas (sistemas de gestión de bases de datos, servidores de aplicaciones). Por ejemplo, resulta muy fácil y cómodo construir aplicaciones Java capaces de trabajar con Oracle usando el JDeveloper de Oracle, por supuesto. Existen empresas que suministran componentes o módulos, añadidos ya a sus herramientas o por separado, con el fin de proporcionar soporte para las plataformas J2EE más populares pero, qué casualidad, son las que no comercializan sus propios servidores de aplicaciones o apenas obtienen ingresos de ello. Borland proporciona, por ejemplo, módulos en su JBuilder para WebLogic, Tomcat, iPlanet (Sun ONE) y Websphere (la cuota de Borland en el mercado de servidores de aplicaciones no llega al 1%), pero Websphere y WebLogic (de IBM y BEA, respectivamente) no suministran directamente módulos para JBuilder, continuando con el ejemplo, porque son los líderes en servidores de aplicaciones y prefieren dirigir a los desarrolladores hacia sus propios productos.

Una regla a menudo cierta para los IDEs comerciales es la del "80-20%": El ochenta por ciento de las características incorporadas sólo son útiles para el 20 por ciento de los usuarios. ¿Cuántas veces nos hemos encontrado con IDEs poco considerados que exprimen nuestras máquinas como si fueran limones, hasta la última gota? Muchas veces el abuso de los recursos del sistema se origina por la instalación con el IDE de muchas características poco o nada utilizadas. Esta inclusión de utilidades no solicitadas ni necesitadas también redunda en el precio del producto. Algunas compañías aprovechan la adición de unas pocas características nuevas, no siempre útiles, para lanzar nuevas versiones de sus IDEs.

Pese a todos estos inconvenientes, los IDEs suelen proporcionar una importante ayuda a la hora de conservar un registro de las versiones, generar y mantener la documentación de cada etapa del proyecto, y evitar tareas monótonas y repetitivas, dada la magnitud y complejidad de los proyectos empresariales que se afrontan actualmente, inabordables en solitario. El lector interesado en adquirir una panorámica rápida de las herramientas e IDEs open source o free software para Java puede consultar el excelente artículo Arquitectura empresarial y open source, J2EE de Martín Pérez y Alberto Molpeceres, publicado en javaHispano y llamado a convertirse en un clásico.

La irrupción de Eclipse, un nuevo jugador en el mercado de IDEs para Java apadrinado por IBM y respaldado por un poderoso consorcio de empresas, supone un firme intento de homogeneizar el mercado de IDEs (no sólo de Java) y de establecer un estándar para las herramientas de desarrollo de software. Eclipse no es un IDE más a añadir a la lista: el objetivo de IBM es crear una plataforma de desarrollo modular que cualquier herramienta de desarrollo pueda usar con cualquier lenguaje de programación. Eclipse anhela ser, no estar.

3. Terminología oficial de Eclipse.

Según la documentación oficial de Eclipse (http://www.eclipse.org), Eclipse es un proyecto de desarrollo de software de código fuente abierto (open source) cuyo objetivo es la construcción de herramientas integradas para el desarrollo de aplicaciones. La palabra "Eclipse" se utiliza en dicha documentación para referirse al proyecto en conjunto de creación de herramientas integradas para desarrollar aplicaciones. Este proyecto global se compone de tres subproyectos (véase http://www.eclipse/projects):

� Proyecto Eclipse

� Proyecto Herramientas de Eclipse

� Proyecto Tecnología Eclipse

El proyecto Eclipse es el subproyecto de Eclipse dedicado a proporcionar una plataforma base común para el desarrollo de herramientas integradas. Este proyecto, a su vez, se subdivide en otros tres, dedicados al desarrollo y mejora de la plataforma Eclipse (núcleo básico o kernel de Eclipse), del JDT (Java Development Tools) y del PDE (Plug-in Development Kit). El término "Eclipse SDK (Standard Development Kit)" alude al conjunto de la plataforma Eclipse, el JDT y el PDE; por tanto, puede afirmarse que el proyecto Eclipse se dedica, en conjunto, al desarrollo y mejora del SDK de Eclipse. Todos estos acrónimos se irán explicando a lo largo del artículo.



Aunque entiendo la preocupación de Eclipse (como proyecto global) por definir correctamente los términos desde un principio para conseguir una documentación precisa y sin ambigüedades, como este artículo pretende ser informativo, de propósito general y no acabar sumergido en un enredo de siglas, usaré "Eclipse" para designar tanto al kit SDK de Eclipse (el producto o herramienta) como al proyecto global. Dependiendo del contexto podrá deducirse el significado. Por ejemplo, en este artículo, términos como "la programación de Eclipse" o "la licencia de Eclipse" hacen referencia al SDK de Eclipse, mientras que "las metas de Eclipse" se refiere al proyecto global. No usaré el término "proyecto Eclipse" (aunque sería lo lógico) para referirme al proyecto global, pues estrictamente hablando constituye un subproyecto de Eclipse, de acuerdo con la terminología oficial.

En resumen, en lo que sigue:

� Se usa "Eclipse" para designar tanto al SDK de Eclipse como al proyecto global.

� Se utiliza "proyecto Eclipse", por coherencia con la terminología oficial, para designar a un subproyecto del proyecto global, encargado del desarrollo y mejora del SDK.

� Se utiliza "plataforma Eclipse" o "plataforma" sólo para designar el núcleo o kernel del SDK de Eclipse (o, equivalentemente, del proyecto Eclipse). Como la palabra "plataforma" se utiliza también para designar una combinación de hardware, sistema operativo y entorno gráfico, en caso de ambigüedad se usará "plataforma Eclipse".

4. ¿Qué es la plataforma Eclipse?

En la antigua Grecia, al pie del monte Parnaso, existió un oráculo muy famoso: el oráculo de Delfos. Éste se expresaba en distintas lenguas y sus respuestas solían ser muy crípticas y ambiguas. Una vez pronosticó: "Si el rey Creso cruza el río Halys con su ejército, destruirá un poderoso imperio". Y así ocurrió, pero resultó ser el suyo. Cuando se lee en la documentación de IBM que "Eclipse es un IDE abierto y extensible para todo y, sin embargo, para nada en particular", puede surgir esta razonable pregunta: ¿Habrá aprendido inglés el oráculo de Delfos y se dedica a redactar la documentación de Eclipse para IBM? Si no ha sido así, la definición no desentonaría, por su ambigüedad y laconismo, con las respuestas habituales del oráculo. Además, tal y como se irá mostrando, resulta tan cierta como muchas de las enigmáticas respuestas que daba el oráculo.

Una definición un poco más concreta se puede resumir así: "[es] una plataforma universal para integrar herramientas de desarrollo" con una "arquitectura abierta, basada en plug-ins". Plataforma universal, pues emplea una estructura abierta de plug-ins (extensiones; to plug in significa conectar y plug, enchufe o conector) que permite expandir las capacidades de la plataforma base hasta el infinito. Arquitectura abierta, en definitiva, porque es un producto de código fuente abierto u open source.

Desde el punto de vista del usuario que le eche un vistazo por vez primera, la plataforma Eclipse resulta ser un IDE

Fig. 2. Jerarquía de proyectos en Eclipse.



(entorno de desarrollo integrado) de código fuente abierto, la mayor parte del cual ha sido escrito en Java.

En cuanto al nombre, no puedo evitar pensar que es una referencia poco amistosa a Sun Microsystems. Una interpretación quizá maliciosa, pero cuando a uno le dan un cuchillo es inevitable no acabar cortando algo: ¿Cuántos críticos literarios resistieron la tentación de asociar a Sauron el Señor Oscuro de El señor de los Anillos con Hitler?, ¿Cuántos lectores no identificaron al cerdo Napoleón de Rebelión en la granja con Stalin cuando se publicó el libro?

5. Historia de Eclipse

Gran parte de la programación de Eclipse fue realizada por IBM antes de que se creara el proyecto Eclipse como tal. Las distintas versiones de VisualAge se construyeron usando Smalltalk (un lenguaje OO no excesivamente amigable) en un entorno de desarrollo llamado Envy. Con la aparición de Java en los 90, IBM desarrolló una maquina virtual válida tanto para Smalltalk y Java. La rápida expansión de Java y sus ventajas con miras a una Internet en plena expansión obligaron a IBM a plantearse el abandono de esta maquina virtual dual y la construcción de una nueva plataforma basada en Java desde el principio. El producto final resultante es Eclipse, que ya había costado unos 40 millones de dólares a IBM en el año 2001.

A finales de 2001 IBM puso el proyecto Eclipse en manos de un consorcio (Eclipse.org) de empresas fabricantes de herramientas de software. Originalmente la junta directiva del consorcio incluía a Borland, MERANT, IBM, QNX Software Systems, Rational Software, Red Hat, SuSE, TogetherSoft y Webgain; en junio de 2002 se agregaron Hitachi, Instantiations, MontaVista, Scapa Technologies, Telelogic,Trans-Enterprise Integration y Serena; en septiembre de 2002 se sumaron ETRI, HP, MKS, SlickEdit y se aprobó la entrada de Oracle; en diciembre de 2002 entraron como miembros AltoWeb, Catalyst Systems, Flashline, Parasoft, SAP, teamstudio y TimeSys. El grupo OMG (Object Management Group) también forma parte de la junta directiva.

La última versión estable de Eclipse (Eclipse 2.0.2, lanzada en noviembre de 2002) se encuentra disponible para los sistemas operativos Solaris 8, HP-UX, AIX, Windows 98/ME/2000/XP, Linux SuSE 7.1, Linux Red Hat 7.1 y QNX. Todas las versiones de Eclipse necesitan tener instalado en el sistema el JRE o JDK versión 1.3 o superior.

Existe ya una versión 2.1 de Eclipse, pero no está tan probada, por ahora, como la versión 2.0.2 y todavía no ha sido marcada por Eclipse.org con la "R" de Released (lanzada). Esta última versión se encuentra disponible para los sistemas operativos anteriores y para Mac OS X. Las nuevas características que ofrece con respecto a la versión oficial 2.0.2 aún necesitan pulirse y depurarse, pero probablemente se lanzará como la última versión estable de Eclipse antes de junio de 2003.

6. Eclipse y el software open source. Un matrimonio de conveniencia bien avenido.

Eclipse se distribuye actualmente bajo la licencia CPL (Common Public License o Licencia) versión 1.0 de IBM, aprobada por la organización Open Source Initiative (OSI). A diferencia de otros proyectos open source (o, más exactamente, free software) que no permiten que se deriven de ellos trabajos propietarios o cerrados, Eclipse puede extenderse -al estar bajo esta licencia CPL- mediante la inclusión de plug-ins propietarios o ser usado como base para la creación de nuevas herramientas y, tras reempaquetarse y compilarse el código resultante, el producto final puede venderse de forma comercial, manteniéndose público el código de Eclipse utilizado o modificado, pero sin la obligación de poner a disposición del público el nuevo código añadido (éste último puede ir bajo la licencia que se desee). Como es bien sabido, el software propietario o cerrado se caracteriza porque su redistribución y modificación está prohibida o requiere autorización previa; la mayor parte del software comercial es propietario, pero no cabe identificar ambos tipos de software: se pueden obtener beneficios económicos de Eclipse (al igual que de cualquier otro proyecto de código fuente abierto o de software libre).

Al igual que cualquier licencia autorizada o admitida por la OSI, la licencia CPL exige el cumplimiento de una serie de requisitos, algunos de los cuales figuran a continuación (el resto pueden consultarse en http://www.opensource.org):

� Distribución gratuita: Cualquier software bajo licencia CPL puede distribuirse libremente, permitiéndose la venta sin que se requiera el pago de royalties o compensaciones de cualquier tipo.

� Cualquier programa bajo licencia CPL debe permitir la distribución en forma de código fuente y en forma compilada. Si el producto no incluye el código fuente, deberá incluirse en él la manera de conseguirlo.

� Cualquier programa bajo licencia CPL debe permitir la producción de trabajos derivados a partir de él y la introducción de modificaciones en el programa original.

Un programa difundido bajo licencia CPL puede ser distribuido por cualquiera en forma compilada o de código fuente. En el primer caso, el programa puede ser distribuido bajo la licencia que determine el distribuidor, siempre que se cumplan los puntos expuestos en el apartado 3 de la CPL v 1.0 (Requisitos); entre otras condiciones, deberá establecerse que el código fuente está disponible por parte de las personas o empresas que hayan contribuido. En el segundo caso, cuando un programa bajo licencia CPL se distribuya en forma de código fuente, quedará automáticamente bajo la "sombrilla" de la licencia CPL y no podrá utilizarse ninguna otra licencia. IBM distribuye una



versión comercial de Eclipse, en forma compilada, llamada WebSphere Studio Workbench.

En consecuencia, cualquier programa bajo licencia CPL puede compilarse (aunque no se haya efectuado ninguna modificación sobre el código original) y venderse el resultado de modo comercial sin requerir el pago de royalties u otras formas de compensación, de acuerdo con los términos de CPL; lo cual implica, aparte de otras obligaciones, poner a disposición del público el código fuente. Si una aplicación tiene una parte licenciada bajo CPL y el resto no (propietaria), la parte bajo CPL debe cumplir con esta licencia y, en consecuencia, el código de esa parte debe estar a disposición del público. El código fuente de la parte propietaria no tiene por qué licenciarse bajo CPL ni estar disponible al público. En contraposición, licencias como la GNU GPL (GNU General Public License, bajo la cual se distribuye Linux) exigen que, si se incorpora código bajo GPL a un programa, aunque éste sea propietario, el programa completo se licencie bajo GPL (poniéndose, por tanto, a disposición del público todo el código fuente, tanto GPL como no GPL). Desde el punto de vista de una empresa interesada en mantener la propiedad de su software, el código propietario que se incorporara a un programa bajo licencia GPL o similar sería infectado o contaminado por el código GPL y perdería su carácter propietario.

Con la licencia CPL, el concepto de copyright sigue vigente: el copyright de los programas, el código, etc. pertenece a sus legítimos autores (u a otras personas o entidades a las que hayan cedido su copyright). Cuando un programa se distribuye bajo la licencia CPL, el creador del programa y poseedor de su copyright o de sus derechos de autor concede a cualquiera una licencia de copyright que proporciona derechos de autor para usar, modificar, redistribuir, comercializar el programa y/o las modificaciones efectuadas sobre éste (sujeta a ciertos términos y restricciones; véase la licencia completa en http://www-124.ibm.com/developerworks/oss/CPLv1.0.htm). El autor transfiere estos derechos de propiedad intelectual, pero no renuncia a su titularidad.

Por este motivo, no es extraño ver el copyright de IBM en la documentación de Eclipse y en el propio producto, pues desarrolló inicialmente la mayor parte de éste. Cualquier desarrollador puede modificar el código open source de Eclipse, redistribuirlo, comercializarlo crear trabajos derivados, etcétera sin pagar royalties a IBM, pero no puede eliminar o modificar el copyright de IBM. En el supuesto de que modificara el código o añadiera nuevos módulos y redistribuyera comercialmente el resultado (ya fuera bajo licencia CPL o no), el desarrollador poseería el copyright de su trabajo, pero IBM seguiría siendo el titular del copyright de las partes que creó, aunque no podría exigir royalties o compensaciones por el uso comercial o lucrativo de su código original.

Cualquiera puede distribuir de forma comercial, con la licencia que estime oportuna, plug-ins para Eclipse no derivados de él, aunque hayan sido desarrollados para la plataforma Eclipse y se haya consultado el código fuente de ésta para crearlos. En este caso no se necesita poner a disposición de otros el código fuente, pues estos plug-ins quedan fuera del alcance de la licencia CPL.

Algunas personas aplauden el mecenazgo de IBM sobre proyectos open source, que comenzó con su apoyo incondicional a Linux en 1997 y continúa hasta hoy. IBM ha invertido unos mil millones de dólares en Linux y productos relacionados, y se calcula que cuenta con unas cinco mil personas (entre empleados y colaboradores)

Fig. 3. Voces desde el software libre y el software open source.



dedicadas a temas relacionados con este sistema operativo. En una conversación, hace ya varios años, una responsable de marketing de IBM me dijo: "Linux es más que alguien de la familia". Frase un tanto intrigante por su ambigüedad: ¿Quería mucho a Linux o poco a su familia? Esta opinión, como supe poco después, no era el fruto de una concienzuda reflexión sobre el tema ni una muestra de cariño desmedido y un tanto fetichista por un sistema operativo (en realidad, ella nunca había llegado a usar Linux: trabajaba con Windows 95), sino una cuestión de estrategia comercial y de marketing.

Al leer las declaraciones de algunos responsables de IBM, uno se da cuenta de que la frase "obsesión por el software open source" refleja a la perfección el sentir de la empresa. Pero casi se debe mirar hacia otro lado para no justificar lúcidamente esta obsesión tan racional; qué mejor estrategia para IBM que apoyar un producto gratuito, serio competidor de Windows NT, Windows 2000 Server y Windows .Net Server, y recomendar desinteresadamente a los clientes del sistema operativo Solaris de Sun la migración a un entorno Linux sobre plataformas eServer de IBM, argumentando reducciones sustanciales en el coste total de la propiedad y mejoras considerables del rendimiento de los sistemas. ¿Obsesión por el software open source? Más bien obsesión por matar dos pájaros de un tiro. ¿Casualidad?... Sí, claro; por eso los directivos de IBM cobran sus abultados sueldos, por casualidad... En el fondo, todos conocemos el nombre del juego.

Linux y Eclipse, pese a su carácter open source y su calidad indudable, son herramientas utilizadas por IBM (como podría ser cualquier otra empresa; ¿por qué engañarse?, las empresas son depredadores en el amplio ecosistema del libre mercado) para obtener ventajas competitivas frente a sus competidores (Sun, Microsoft, HP, BEA, etc.), ventajas que favorecerán -directa o indirectamente- el retorno a sus arcas de las inversiones efectuadas. Ahora bien, el carácter open source de Eclipse también repite un mensaje constante a lo largo de la red de redes: Aquí no hay privilegios exclusivos. Cualquiera puede colaborar y ganar algo con ello. Los desarrolladores open source puede ganar prestigio y ostentar su copyright; las empresas pueden sacar rentabilidad a sus inversiones en Eclipse y conseguir productos que ellas solas jamás hubieran podido crear.

Un elevado porcentaje del éxito de Eclipse y de las mejoras continuas que experimenta se debe a la naturaleza de su licencia: la licencia CPL de IBM supone ventajas comerciales frente a licencias como la GNU GPL, las cuales impiden que se deriven o incorporen trabajos propietarios -como es bien sabido, los objetivos de las empresas con ánimo de lucro, aunque a algunas les cause sarpullidos reconocerlo públicamente, se fundamentan en dos reglas: 1) Gane dinero y mantenga su propiedad; 2) Nunca olvide la primera regla (eso sí, cada una las implementa como puede)-. Muchas empresas (grandes, PYMEs) pueden desarrollar plug-ins propietarios o sus propias herramientas derivadas de Eclipse y obtener beneficios de su trabajo sin ver mermadas sus ganancias por el pago de royalties, y los desarrolladores pueden planear con rapidez sus propias extensiones, modificaciones o mejoras, a la vista del código fuente de Eclipse y de los productos derivados bajo licencia CPL. Individuos y empresas pueden trabajar en simbiosis, lograr sus objetivos, contribuir a la mejora continua de Eclipse y ofrecer mejores productos (más competitivos en prestaciones y precio) a los consumidores finales. Al usuario final poco le importa que el gato sea blanco, negro, pardo o el pedigrí de sus progenitores: lo importante es que cace ratones. Y que los cace bien.

Aparte de las distintas licencias de Linux y Eclipse, hay también otro rasgo diferenciador entre ambos proyectos que contribuye a la vertiginosa expansión de Eclipse: poca gente (comparativamente hablando) tiene conocimientos de programación de sistemas operativos; sin embargo, cualquier desarrollador usuario de Eclipse -y hay muchos más desarrolladores que expertos en sistemas operativos- es un potencial colaborador del proyecto Eclipse.

7. Pero ¿era necesario añadir un IDE más a la larga lista de los ya existentes?

El lector escéptico podría pensar que Eclipse no deja de ser otra herramienta de desarrollo para Java, similar a herramientas como JBuilder (Borland), JDeveloper (Oracle) ó NetBeans (Sun), y que el uso de la palabra "plataforma" forma parte de una estrategia comercial de IBM, no muy innovadora. Sin embargo, no es así: Eclipse presenta cuatro características conjuntas muy importantes, ya esbozadas en apartados anteriores, que justifican el uso de "plataforma":

� Eclipse se beneficia de la capacidad de aceptar plug-ins open source o propietarios, escritos por los propios desarrolladores Java, que pueden extender la plataforma y, a su vez, otros plug-ins. Esta arquitectura abierta puede concebirse figuradamente como una península (la plataforma Eclipse) rodeada de un archipiélago de plug-ins que expanden sus capacidades hasta donde llegue la imaginación y la destreza de los desarrolladores.

� Eclipse cuenta con el respaldo de un consorcio de empresas muy importantes, ya detalladas.

� Eclipse es neutral con respecto a la plataforma y el lenguaje (aunque en su mayor parte esté escrito en Java).

� Eclipse permite realizar íntegramente el proceso de desarrollo de software tal y como se entiende en la actualidad, desde el análisis inicial de requerimientos hasta la distribución final y el mantenimiento. Casi con toda seguridad, Rational Software, con su metodología RUP (Rational Unified Process), y TogetherSoft (adquirida por Borland hace unos meses) han influido mucho en esta característica.

La primera característica no es del todo nueva, pues la plataforma NetBeans de Java (también una iniciativa open source) sigue una estrategia similar, pero no cuenta con el respaldo de empresas tan importantes como las citadas. En relación con la última característica, casi todas las herramientas de desarrollo en Java proporcionan algún tipo de



asistencia para el modelado y el diseño, pero no de forma tan detallada y continua, de principio a fin, como el que puede proporcionar Eclipse mediante plug-ins.

Eclipse puede considerarse, en justicia, como un IDE para Java, una plataforma de integración de herramientas de desarrollo y un framework de aplicaciones.

8. La arquitectura del SDK de Eclipse: una vista aérea.

El Standard Development Kit (Kit de desarrollo estándar) de Eclipse se compone de tres elementos:

� La Plataforma Eclipse (cuya arquitectura interna se describirá más adelante)

� El JDT (Java Development Tooling, las herramientas de desarrollo Java).

� El PDE (Plug-in Development Environment, el entorno de desarrollo de plug-ins).

Tal y como ya se explicó, su desarrollo y mejora está en manos del proyecto Eclipse (subproyecto de Eclipse).

En esencia, la plataforma Eclipse es una plataforma para el desarrollo general de herramientas (recordemos: "un IDE para cualquier cosa y para nada en particular"). Por sí sola, la plataforma resulta de escasa utilidad para el usuario último pues se halla capacitada para trabajar con cualquier tipo de fichero (no necesariamente con ficheros asociados a lenguajes de programación, sino también con ficheros generados por aplicaciones como Word, ficheros de vídeo, de gráficos, etcétera), pero carece del conocimiento específico de cómo tratarlos. Es decir, Eclipse puede mostrar un fichero C, por ejemplo, pero desconoce la gramática y sintaxis de C (palabras reservadas, bloques, etc.). La palabra main no significa más que la palabra vino para la plataforma aislada, pues no proporciona facilidades específicas para la depuración, edición, etc. La utilidad real de la plataforma por sí sola para el programador de C -o de cualquier otro lenguaje, incluido Java- no es mayor que la de un editor de texto plano (aunque con un extraordinario entorno gráfico alrededor).

Sin embargo, para el desarrollador de plug-ins y de IDEs se presenta una situación muy distinta: la plataforma por sí sola le proporciona un conjunto de frameworks, un conjunto de reglas de integración con la plataforma, una interfaz gráfica francamente espléndida, soporte para el control de versiones, infraestructura para la depuración independiente del lenguaje usado y el control de las bibliotecas gráficas, entre otras muchas características. Los desarrolladores de plug-ins e IDEs pueden usar todas estas funcionalidades ya incorporadas para desarrollar sus propias herramientas que expandan la plataforma.

Cuando se usa la plataforma Eclipse con plug-ins, empieza a vislumbrarse la potencia que ofrece a los usuarios no desarrolladores de plug-ins o IDEs. Los plug-ins explican a la plataforma cómo se deben tratar y gestionar los distintos tipos de archivos, y aumentan la funcionalidad del sistema resultante (o, dicho de otro modo, extienden o amplían la plataforma).

Fig. 4. Estructura general de Eclipse. Extraído de la documentación oficial de Eclipse.



Para añadir nuevas capacidades o funcionalidades a la plataforma Eclipse se usan los puntos de extensión. Los puntos de extensión son, según la documentación oficial de Eclipse, "lugares bien definidos del sistema donde otras herramientas (llamadas plug-ins) pueden añadir funcionalidad". De conformidad con la terminología orientada a objetos, un punto de extensión no deja de ser una interfaz que deberá ser implementada por cualquier desarrollador interesado en extender la plataforma. Conviene destacar un aspecto importante: el mecanismo de los puntos de extensión define el único modo de añadir nuevas funcionalidades a la plataforma.

Los plug-ins no sólo extienden o amplían la plataforma base, también pueden extender, a su vez, otros plug-ins que hayan definido sus propios puntos de extensión. Un plug-in puede hacer públicos interfaces que otros plug-ins pueden implementar. Las implementaciones de los interfaces (llamadas extensiones) mostrados por los puntos de extensión se realizan típicamente en Java, aunque algunos puntos de extensión pueden acomodar extensiones proporcionadas por ficheros ejecutables nativos o componentes ActiveX; incluso pueden programarse en lenguajes de script. El principal obstáculo con el cual se enfrentan las extensiones no realizadas en Java es la falta de acceso a la funcionalidad completa de la plataforma Eclipse. Por otro lado, los plug-ins sólo se cargan cuando son necesarios; así se evita disminuir innecesariamente el rendimiento de Eclipse. Tal y como se detalló en el Apdo. 2, esta propiedad traza una clara separación, en cuanto a consumo de recursos, entre los IDEs comerciales y Eclipse. A diferencia de estos, Eclipse solo carga en memoria los plug-ins cuando los necesita.

Por ejemplo, el JDT agrupa un conjunto de plug-ins que extienden la plataforma al proporcionar características para la edición, compilación, depuración y ejecución de código Java (explica a la plataforma cómo entender los ficheros Java, en definitiva). El JDT viene incluido en el SDK de Eclipse, pero resulta factible desarrollar otros plug-ins que permitan a la plataforma trabajar con otros lenguajes. Se encuentran ya disponibles plug-ins del consorcio Eclipse.org que proporcionan IDEs para C/C++ y COBOL.

El Java Development Tooling (JDT) es, tal y como ya se ha escrito arriba, un conjunto de plug-ins que extienden la plataforma al proporcionar características para la edición, compilación, depuración y ejecución de código Java.

El Plug-in Development Environment (PDE) proporciona herramientas y asistentes que automatizan y facilitan considerablemente la creación, desarrollo, depuración y distribución de plug-ins.

Fig. 5. Arquitectura de los plug-ins de Eclipse. Traducido de la documentación oficial de Eclipse.



La imagen mental que me viene a la cabeza cuando pienso en la arquitectura de Eclipse, que tal vez sea útil al lector, es la de una península (la plataforma) rodeada de un archipiélago (los plug-ins), pudiendo cada islote del archipiélago tener su propio archipiélago (plug-ins extendidos por otros plug-ins). Si acercáramos una lupa a Eclipse, nos daríamos cuenta de su geometría fragmentaria, discontinua e incompleta; conforme fuéramos aproximando la lupa, podríamos observar cómo todos sus componentes, salvo uno, se descomponen en plug-ins compuestos, a su vez, por otros plug-ins más simples, y así sucesivamente. Veríamos, acercando mucho la lupa, los puntos de extensión de los plug-ins, algunos ocupados (es decir, implementados), pero la mayoría no. Los puntos de extensión libres estarían disponibles para futuras ampliaciones de Eclipse, ampliables también. Esta geometría recursiva me recuerda, superficialmente, a las figuras fractales de Mandelbrot.

Fig. 6. Vista del PDE. Extraído de la documentación oficial de Eclipse.



[Fin de la primera parte]

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.

Fig. 7. Eclipse como archipiélago



Artículo 1 sobre la plataforma ECLIPSE

Software

Transcript of Artículo 1 sobre la plataforma ECLIPSE