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 ekleípein, abandonar.). m.
Astron. Oscurecimiento del sol o de un cuerpo celeste 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/).
Page 1 of 12javaHispano. ECLIPSE
21/05/2014file://F:ArticuloEclipseArt_Eclipse_1Copia 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

of 12javaHispano. ECLIPSE

Artículo 1 sobre la plataforma ECLIPSE

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (20)

Similar a Artículo 1 sobre la plataforma ECLIPSE

Similar a Artículo 1 sobre la plataforma ECLIPSE (20)

Más de torrubia

Más de torrubia (20)

Artículo 1 sobre la plataforma ECLIPSE