Artículo 1 ECLIPSE y JAVA

EL ARCHIPILAGO ECLIPSE (PARTE 1 DE 4)
Fecha de ltima revisin: 21.05.2014

Miguel ngel Abin
mabian ARROBA aidima PUNTO es
ECLIPSE. (Del lat. eclipsis, y ste del gr. kleipsis, de eklepein, abandonar.). m.
Astron. Oscurecimiento del sol o de un cuerpo celeste por interposicin de otro astro que
le oculta directamente o que infiere la luz que le ilumina. [Diccionario Enciclopdico
SALVAT Universal]
1. Introduccin
El artculo El archipilago Eclipse pretende exponer qu es Eclipse, cul es su estructura, en qu se
diferencia o se asemeja a otros productos ya existentes, cules son sus ventajas e inconvenientes, cul
podra ser su utilidad para los desarrolladores (centrndose en la comunidad Java), qu estrategias
empresariales subyacen bajo el proyecto Eclipse y cul podra ser su futuro. Debido a su extensin, unas
diecisiete mil palabras, se publicar dividido en cuatro partes.
En este artculo no se explica cmo utilizar Eclipse o cmo desarrollar aplicaciones Java con l, pues
existe una amplia documentacin acerca de estos temas en la ayuda del producto y en
http://www.eclipse.org. Sin embargo, existe poca informacin -y toda en ingls- acerca de algunos
de los puntos sealados arriba; adems, mucha de esta escasa informacin est claramente sesgada, por
motivos de estrategia comercial y empresarial, a favor o en contra del producto. Para obtener una
valoracin imparcial de Eclipse es obligatorio leer a menudo entre lneas, comprobar y contrastar cada
afirmacin, prestar atencin a lo sobreentendido -que suele ser lo importante- y probar muchos
productos.
El archipilago 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 artculo, es el momento de comenzar el recorrido por los islotes que pueblan el
archipilago Eclipse.
Copyright (c) 2003-2014, Miguel ngel Abin. Este documento puede ser distribuido solo bajo los trminos y
condiciones de la licencia de Documentacin de javaHispano v1.0 o posterior (la ltima versin se encuentra en
http://www.javahispano.org/licencias/).
Page 1 of 12 javaHispano. ECLIPSE
21/05/2014 file://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 generacin del cdigo y a la construccin de proyectos. Tarde o temprano, independientemente
del grupo al cual pertenezcan, todos se enfrentan a sus propios problemas.
No hace mucho (cronolgicamente hablando, que no tecnolgicamente), 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 generacin, 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 cdigo, del compilador y del
depurador desde una nica interfaz de usuario. Su misin consiste en evitar tareas repetitivas, facilitar la escritura de
cdigo correcto, disminuir el tiempo de depuracin e incrementar la productividad del desarrollador. Estas tareas
pueden realizarse de muchas maneras distintas: mediante la inclusin de asistentes para las tareas ms habituales y
mecnicas, de editores que completen automticamente el cdigo y sealen los errores sintcticos, de gestores de
archivos fuente, etc.
En teora, un entorno de desarrollo integrado o IDE debera aportar funcionalidades al desarrollador durante todas las
etapas del ciclo de vida del desarrollo de software (desde el anlisis y diseo a la distribucin del producto y su
mantenimiento), de ah la palabra "integrado". En la prctica, solamente los IDEs ms modernos cumplen esta
condicin y, a menudo, de forma incompleta.
Despus del impresionante xito de Visual Basic, ha sido frecuente asumir que los IDEs necesitan incluir herramientas
visuales de generacin de interfaces de usuario (GUI builders), pero esta premisa resulta inexacta. Algunos IDEs
carecen de diseadores grficos visuales y no por ello dejan de ser excelentes. En el caso especfico de Java, la mayor
parte de las aplicaciones actuales se ejecutan en el lado del servidor y no precisan interfaz grfico. Muchas veces
resulta ms conveniente disponer de un buen editor JSP/HTML que de un vistoso diseador grfico.
Los IDEs, por supuesto, tambin tienen sus desventajas: en comparacin con el clsico triunvirato editor de texto-
compilador-depurador consumen muchsimos ms 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 ms sencillas; en otros los manuales demuestran al indefenso
lector el odio, desinters y ausencia de motivacin pedaggica que deben de sentir aquellos que los escriben. En
Fig. 1. Eclipse como pentagrama. La figura muestra distintas facetas de Eclipse, que se abordarn a lo
largo del artculo.
ocasiones, cuando generan cdigo, es mejor mirar hacia otra parte o empezar de cero.
Todava no existe un IDE universal o perfecto, capaz de reunir todas las caractersticas que un desarrollador puede
necesitar. Por lo general, los puntos dbiles de un IDE coinciden con los puntos fuertes de otro. Un buen ejemplo lo
proporciona la comparacin entre WebSphere Studio Application Developer (de IBM) y JBuilder (de Borland). JBuilder
posee un excelente diseador de interfaces grficas para el usuario y proporciona una vista de la estructura jerrquica
de los formularios que muestra todos los componentes visuales (botones, cuadros de texto,...) organizados por
contenedores. WebSphere Studio Application Developer proporciona, en comparacin, un diseador grfico mucho
ms simple, pero ofrece un editor JSP/HTML magnfico (uno de los mejores, si no el mejor, del mercado), que permite
insertar componentes visuales, componentes ActiveX o imgenes, y ver la vista previa de las pginas web, entre otras
muchas caractersticas. El editor HTML de JBuilder se limita, en cambio, a poco ms que colorear las palabras
reservadas.
Como puede extrapolarse a partir del ejemplo anterior, el desarrollador que trabaje en varios campos
simultneamente (desarrollo de servicios Web, creacin de Enterprise JavaBeans, diseo de pginas web, edicin de
XML) necesitar usar varios IDEs o herramientas para trabajar de forma ptima.
En algunas ocasiones, la eleccin del IDE por parte de los desarrolladores no es libre, sino que est condicionada por
decisiones previas (sistemas de gestin de bases de datos, servidores de aplicaciones). Por ejemplo, resulta muy fcil
y cmodo construir aplicaciones Java capaces de trabajar con Oracle usando el JDeveloper de Oracle, por supuesto.
Existen empresas que suministran componentes o mdulos, aadidos ya a sus herramientas o por separado, con el fin
de proporcionar soporte para las plataformas J2EE ms populares pero, qu casualidad, son las que no comercializan
sus propios servidores de aplicaciones o apenas obtienen ingresos de ello. Borland proporciona, por ejemplo, mdulos
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 mdulos para JBuilder, continuando con el ejemplo, porque son los lderes 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 caractersticas
incorporadas slo son tiles para el 20 por ciento de los usuarios. Cuntas veces nos hemos encontrado con IDEs
poco considerados que exprimen nuestras mquinas como si fueran limones, hasta la ltima gota? Muchas veces el
abuso de los recursos del sistema se origina por la instalacin con el IDE de muchas caractersticas poco o nada
utilizadas. Esta inclusin de utilidades no solicitadas ni necesitadas tambin redunda en el precio del producto.
Algunas compaas aprovechan la adicin de unas pocas caractersticas 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 documentacin de cada etapa del proyecto, y evitar tareas
montonas y repetitivas, dada la magnitud y complejidad de los proyectos empresariales que se afrontan
actualmente, inabordables en solitario. El lector interesado en adquirir una panormica rpida de las herramientas e
IDEs open source o free software para Java puede consultar el excelente artculo Arquitectura empresarial y open
source, J2EE de Martn Prez y Alberto Molpeceres, publicado en javaHispano y llamado a convertirse en un clsico.
La irrupcin 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 slo de Java) y de
establecer un estndar para las herramientas de desarrollo de software. Eclipse no es un IDE ms a aadir 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 programacin. Eclipse anhela ser, no estar.
3. Terminologa oficial de Eclipse.
Segn la documentacin oficial de Eclipse (http://www.eclipse.org), Eclipse es un proyecto de desarrollo de
software de cdigo fuente abierto (open source) cuyo objetivo es la construccin de herramientas integradas para el
desarrollo de aplicaciones. La palabra "Eclipse" se utiliza en dicha documentacin para referirse al proyecto en
conjunto de creacin de herramientas integradas para desarrollar aplicaciones. Este proyecto global se compone de
tres subproyectos (vase http://www.eclipse/projects):
Proyecto Eclipse
Proyecto Herramientas de Eclipse
Proyecto Tecnologa Eclipse
El proyecto Eclipse es el subproyecto de Eclipse dedicado a proporcionar una plataforma base comn 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 (ncleo bsico o kernel de Eclipse), del JDT (Java Development Tools) y del PDE (Plug-in
Development Kit). El trmino "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 acrnimos se irn explicando a lo largo del artculo.
Aunque entiendo la preocupacin de Eclipse (como proyecto global) por definir correctamente los trminos desde un
principio para conseguir una documentacin precisa y sin ambigedades, como este artculo pretende ser informativo,
de propsito 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 artculo, trminos como "la programacin 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 trmino "proyecto
Eclipse" (aunque sera lo lgico) para referirme al proyecto global, pues estrictamente hablando constituye un
subproyecto de Eclipse, de acuerdo con la terminologa 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 terminologa oficial, para designar a un subproyecto del
proyecto global, encargado del desarrollo y mejora del SDK.
Se utiliza "plataforma Eclipse" o "plataforma" slo para designar el ncleo o kernel del SDK de Eclipse (o,
equivalentemente, del proyecto Eclipse). Como la palabra "plataforma" se utiliza tambin para designar una
combinacin de hardware, sistema operativo y entorno grfico, en caso de ambigedad se usar "plataforma
Eclipse".
4. Qu es la plataforma Eclipse?
En la antigua Grecia, al pie del monte Parnaso, existi un orculo muy famoso: el orculo de Delfos. ste se
expresaba en distintas lenguas y sus respuestas solan ser muy crpticas y ambiguas. Una vez pronostic: "Si el rey
Creso cruza el ro Halys con su ejrcito, destruir un poderoso imperio". Y as ocurri, pero result ser el suyo. Cuando
se lee en la documentacin 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 ingls el orculo de Delfos y se dedica a redactar
la documentacin de Eclipse para IBM? Si no ha sido as, la definicin no desentonara, por su ambigedad y
laconismo, con las respuestas habituales del orculo. Adems, tal y como se ir mostrando, resulta tan cierta como
muchas de las enigmticas respuestas que daba el orculo.
Una definicin un poco ms 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
cdigo 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. Jerarqua de proyectos en Eclipse.
(entorno de desarrollo integrado) de cdigo 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
interpretacin quiz maliciosa, pero cuando a uno le dan un cuchillo es inevitable no acabar cortando algo: Cuntos
crticos literarios resistieron la tentacin de asociar a Sauron el Seor Oscuro de El seor de los Anillos con Hitler?,
Cuntos lectores no identificaron al cerdo Napolen de Rebelin en la granja con Stalin cuando se public el libro?
5. Historia de Eclipse
Gran parte de la programacin 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 aparicin de Java en los 90, IBM desarroll una maquina virtual
vlida tanto para Smalltalk y Java. La rpida expansin de Java y sus ventajas con miras a una Internet en plena
expansin obligaron a IBM a plantearse el abandono de esta maquina virtual dual y la construccin de una nueva
plataforma basada en Java desde el principio. El producto final resultante es Eclipse, que ya haba costado unos 40
millones de dlares a IBM en el ao 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 inclua 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) tambin forma parte de la junta directiva.
La ltima versin 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 versin 1.3 o superior.
Existe ya una versin 2.1 de Eclipse, pero no est tan probada, por ahora, como la versin 2.0.2 y todava no ha sido
marcada por Eclipse.org con la "R" de Released (lanzada). Esta ltima versin se encuentra disponible para los
sistemas operativos anteriores y para Mac OS X. Las nuevas caractersticas que ofrece con respecto a la versin oficial
2.0.2 an necesitan pulirse y depurarse, pero probablemente se lanzar como la ltima versin 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) versin 1.0 de IBM,
aprobada por la organizacin Open Source Initiative (OSI). A diferencia de otros proyectos open source (o, ms
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 inclusin de plug-ins propietarios o ser usado como base para
la creacin de nuevas herramientas y, tras reempaquetarse y compilarse el cdigo resultante, el producto final puede
venderse de forma comercial, mantenindose pblico el cdigo de Eclipse utilizado o modificado, pero sin la obligacin
de poner a disposicin del pblico el nuevo cdigo aadido (ste ltimo puede ir bajo la licencia que se desee).
Como es bien sabido, el software propietario o cerrado se caracteriza porque su redistribucin y modificacin est
prohibida o requiere autorizacin previa; la mayor parte del software comercial es propietario, pero no cabe identificar
ambos tipos de software: se pueden obtener beneficios econmicos de Eclipse (al igual que de cualquier otro proyecto
de cdigo 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 continuacin (el resto pueden consultarse en
http://www.opensource.org):
Distribucin gratuita: Cualquier software bajo licencia CPL puede distribuirse libremente, permitindose la venta
sin que se requiera el pago de royalties o compensaciones de cualquier tipo.
Cualquier programa bajo licencia CPL debe permitir la distribucin en forma de cdigo fuente y en forma
compilada. Si el producto no incluye el cdigo fuente, deber incluirse en l la manera de conseguirlo.
Cualquier programa bajo licencia CPL debe permitir la produccin de trabajos derivados a partir de l y la
introduccin de modificaciones en el programa original.
Un programa difundido bajo licencia CPL puede ser distribuido por cualquiera en forma compilada o de cdigo 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 cdigo 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 cdigo fuente, quedar
automticamente bajo la "sombrilla" de la licencia CPL y no podr utilizarse ninguna otra licencia. IBM distribuye una
versin 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
modificacin sobre el cdigo original) y venderse el resultado de modo comercial sin requerir el pago de royalties u
otras formas de compensacin, de acuerdo con los trminos de CPL; lo cual implica, aparte de otras obligaciones,
poner a disposicin del pblico el cdigo fuente. Si una aplicacin tiene una parte licenciada bajo CPL y el resto no
(propietaria), la parte bajo CPL debe cumplir con esta licencia y, en consecuencia, el cdigo de esa parte debe estar a
disposicin del pblico. El cdigo fuente de la parte propietaria no tiene por qu licenciarse bajo CPL ni estar
disponible al pblico. En contraposicin, licencias como la GNU GPL (GNU General Public License, bajo la cual se
distribuye Linux) exigen que, si se incorpora cdigo bajo GPL a un programa, aunque ste sea propietario, el
programa completo se licencie bajo GPL (ponindose, por tanto, a disposicin del pblico todo el cdigo fuente,
tanto GPL como no GPL). Desde el punto de vista de una empresa interesada en mantener la propiedad de su
software, el cdigo propietario que se incorporara a un programa bajo licencia GPL o similar sera infectado o
contaminado por el cdigo GPL y perdera su carcter propietario.
Con la licencia CPL, el concepto de copyright sigue vigente: el copyright de los programas, el cdigo, etc. pertenece a
sus legtimos 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 trminos y restricciones;
vase 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 extrao ver el copyright de IBM en la documentacin de Eclipse y en el propio producto, pues
desarroll inicialmente la mayor parte de ste. Cualquier desarrollador puede modificar el cdigo open source de
Eclipse, redistribuirlo, comercializarlo crear trabajos derivados, etctera sin pagar royalties a IBM, pero no puede
eliminar o modificar el copyright de IBM. En el supuesto de que modificara el cdigo o aadiera nuevos mdulos y
redistribuyera comercialmente el resultado (ya fuera bajo licencia CPL o no), el desarrollador poseera el copyright de
su trabajo, pero IBM seguira siendo el titular del copyright de las partes que cre, aunque no podra exigir royalties o
compensaciones por el uso comercial o lucrativo de su cdigo 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 cdigo fuente de
sta para crearlos. En este caso no se necesita poner a disposicin de otros el cdigo 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 contina hasta hoy. IBM ha invertido unos mil millones de dlares 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 conversacin, hace ya varios aos, una
responsable de marketing de IBM me dijo: "Linux es ms que alguien de la familia". Frase un tanto intrigante por su
ambigedad: Quera mucho a Linux o poco a su familia? Esta opinin, como supe poco despus, no era el fruto de
una concienzuda reflexin sobre el tema ni una muestra de cario desmedido y un tanto fetichista por un sistema
operativo (en realidad, ella nunca haba llegado a usar Linux: trabajaba con Windows 95), sino una cuestin de
estrategia comercial y de marketing.
Al leer las declaraciones de algunos responsables de IBM, uno se da cuenta de que la frase "obsesin por el software
open source" refleja a la perfeccin el sentir de la empresa. Pero casi se debe mirar hacia otro lado para no justificar
lcidamente esta obsesin 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 migracin 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. Obsesin por el software open source? Ms bien obsesin por matar dos pjaros 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 carcter open source y su calidad indudable, son herramientas utilizadas por IBM (como
podra ser cualquier otra empresa; por qu engaarse?, 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 favorecern -directa o indirectamente- el retorno a sus arcas de las inversiones efectuadas. Ahora bien, el
carcter open source de Eclipse tambin 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 jams 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 pblicamente, 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 cdigo
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 (ms 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 tambin otro rasgo diferenciador entre ambos proyectos que
contribuye a la vertiginosa expansin de Eclipse: poca gente (comparativamente hablando) tiene conocimientos de
programacin de sistemas operativos; sin embargo, cualquier desarrollador usuario de Eclipse -y hay muchos ms
desarrolladores que expertos en sistemas operativos- es un potencial colaborador del proyecto Eclipse.
7. Pero era necesario aadir un IDE ms a la larga lista de los ya
existentes?
El lector escptico podra 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
caractersticas 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 pennsula (la plataforma Eclipse) rodeada de un archipilago de
plug-ins que expanden sus capacidades hasta donde llegue la imaginacin 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 anlisis inicial de requerimientos hasta la distribucin final y el mantenimiento. Casi con
toda seguridad, Rational Software, con su metodologa RUP (Rational Unified Process), y TogetherSoft
(adquirida por Borland hace unos meses) han influido mucho en esta caracterstica.
La primera caracterstica no es del todo nueva, pues la plataforma NetBeans de Java (tambin una iniciativa open
source) sigue una estrategia similar, pero no cuenta con el respaldo de empresas tan importantes como las citadas.
En relacin con la ltima caracterstica, casi todas las herramientas de desarrollo en Java proporcionan algn tipo de
asistencia para el modelado y el diseo, 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 integracin de herramientas de
desarrollo y un framework de aplicaciones.
8. La arquitectura del SDK de Eclipse: una vista area.
El Standard Development Kit (Kit de desarrollo estndar) de Eclipse se compone de tres elementos:
La Plataforma Eclipse (cuya arquitectura interna se describir ms 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 programacin, sino tambin con ficheros generados por aplicaciones como Word, ficheros de
vdeo, de grficos, etctera), pero carece del conocimiento especfico de cmo tratarlos. Es decir, Eclipse puede
mostrar un fichero C, por ejemplo, pero desconoce la gramtica y sintaxis de C (palabras reservadas, bloques, etc.).
La palabra main no significa ms que la palabra vino para la plataforma aislada, pues no proporciona facilidades
especficas para la depuracin, edicin, 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 grfico alrededor).
Sin embargo, para el desarrollador de plug-ins y de IDEs se presenta una situacin muy distinta: la plataforma por s
sola le proporciona un conjunto de frameworks, un conjunto de reglas de integracin con la plataforma, una interfaz
grfica francamente esplndida, soporte para el control de versiones, infraestructura para la depuracin independiente
del lenguaje usado y el control de las bibliotecas grficas, entre otras muchas caractersticas. 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 cmo se deben tratar y gestionar los
distintos tipos de archivos, y aumentan la funcionalidad del sistema resultante (o, dicho de otro modo, extienden o
amplan la plataforma).
Fig. 4. Estructura general de Eclipse. Extrado de la documentacin oficial de Eclipse.
Para aadir nuevas capacidades o funcionalidades a la plataforma Eclipse se usan los puntos de extensin. Los puntos
de extensin son, segn la documentacin oficial de Eclipse, "lugares bien definidos del sistema donde otras
herramientas (llamadas plug-ins) pueden aadir funcionalidad". De conformidad con la terminologa orientada a
objetos, un punto de extensin 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
extensin define el nico modo de aadir nuevas funcionalidades a la plataforma.
Los plug-ins no slo extienden o amplan la plataforma base, tambin pueden extender, a su vez, otros plug-ins que
hayan definido sus propios puntos de extensin. Un plug-in puede hacer pblicos interfaces que otros plug-ins pueden
implementar. Las implementaciones de los interfaces (llamadas extensiones) mostrados por los puntos de extensin
se realizan tpicamente en Java, aunque algunos puntos de extensin pueden acomodar extensiones proporcionadas
por ficheros ejecutables nativos o componentes ActiveX; incluso pueden programarse en lenguajes de script. El
principal obstculo 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 slo 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 separacin, 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 caractersticas para la
edicin, compilacin, depuracin y ejecucin de cdigo Java (explica a la plataforma cmo 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 caractersticas para la edicin, compilacin, depuracin y ejecucin de cdigo Java.
El Plug-in Development Environment (PDE) proporciona herramientas y asistentes que automatizan y facilitan
considerablemente la creacin, desarrollo, depuracin y distribucin de plug-ins.
Fig. 5. Arquitectura de los plug-ins de Eclipse. Traducido de la documentacin 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 pennsula (la plataforma) rodeada de un archipilago (los plug-ins), pudiendo cada islote del archipilago
tener su propio archipilago (plug-ins extendidos por otros plug-ins).
Si acercramos una lupa a Eclipse, nos daramos cuenta de su geometra fragmentaria, discontinua e incompleta;
conforme furamos aproximando la lupa, podramos observar cmo todos sus componentes, salvo uno, se
descomponen en plug-ins compuestos, a su vez, por otros plug-ins ms simples, y as sucesivamente. Veramos,
acercando mucho la lupa, los puntos de extensin de los plug-ins, algunos ocupados (es decir, implementados), pero
la mayora no. Los puntos de extensin libres estaran disponibles para futuras ampliaciones de Eclipse, ampliables
tambin. Esta geometra recursiva me recuerda, superficialmente, a las figuras fractales de Mandelbrot.
Fig. 6. Vista del PDE. Extrado de la documentacin oficial de Eclipse.
[Fin de la primera parte]
Acerca del autor
Miguel ngel Abin
Miguel ngel Abin naci en Soria. Obtuvo la suficiencia investigadora en el Dpto. de Fsica Aplicada de la Universidad
de Valencia con una tesina sobre electromagnetismo. Realiz varios cursos de doctorado relacionados con
electromagnetismo, electrnica, semiconductores y cristales fotnicos. Ha recibido becas del IMPIVA (Instituto de la
Mediana y Pequea Industria Valenciana) y de la Universidad Politcnica de Valencia. Curs un Mster estadounidense
en UML y Java y otro sobre tecnologas de Internet/Intranet.
Se incorpor en 1998 a AIDIMA, donde ha participado como investigador en 24 proyectos de investigacin nacionales
e internacionales relacionados con la Web semntica, tecnologas de la informacin, madera en construccin,
biosensrica, bioelectrnica, telecomunicaciones, visin artificial; as como en la Red de Excelencia de la Comisin
Europea INTEROP 2003-2007. Algunos de los proyectos europeos relacionados con las tecnologas semnticas en los
que ha participado son ATHENA y STASIS (http://www.stasis-project.net/).
El ao 2006 estuvo cuatro meses como investigador invitado en el departamento Lehrstuhl fr Messsystem und
Sensortechnik de la Universidad Politcnica de Munich (TUM), donde colabor en el desarrollo de nuevos mtodos para
la deteccin de defectos en superficies acabadas y en el diseo e implementacin de sistemas distribuidos de sensores
para el sector del automvil y de energas 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 ms prestigioso en el sector forestal y de la madera- por su aportacin al desarrollo de nuevas tecnologas
de evaluacin no destructiva de la madera en construccin.
Actualmente es Responsable del Departamento de Tecnologa y Biotecnologa de la Madera y del rea de Construccin
de Madera.
Es coautor de 7 libros y guas tcnicas relacionadas con el uso de la madera en la construccin y la visin artificial.
Tambin ha publicado varios artculos cientficos 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 ms de 22 artculos
tcnicos en revistas sectoriales y tcnicas.
Es autor o coautor de 8 patentes, algunas de ellas en trmite. Tres de ellas corresponden a dispositivos y mtodos
para detectar la biodegradacin de la madera en construccin.
Actualmente, entre otros proyectos como SHBUILDINGS, WOODTECH, WOODRUB y CELLUWOOD, ha trabajado en
SEMCONCEPT, un proyecto de I+D+i para aplicar tecnologas semnticas (ontologas, buscadores semnticos) en el
diseo conceptual de productos industriales. Sus intereses actuales son la evolucin de la programacin orientada a
objetos, Java, la Web semntica y sus tecnologas, la arquitectura orgnica, el surrealismo y Pars, siempre Pars.
Fig. 7. Eclipse como archipilago


Artículo 1 ECLIPSE y JAVA

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Artículo 1 ECLIPSE y JAVA

Uploaded by

Copyright:

Available Formats

EL ARCHIPILAGO ECLIPSE (PARTE 1 DE 4)

Fecha de ltima revisin: 21.05.2014

You might also like