El archipielago Eclipse
martes, marzo 4, 2003 at 1:00AM EL ARCHIPIÉLAGO ECLIPSE (PARTE 1 DE 4)
Fecha de creación: 24.02.2003
Miguel Ángel Abián
mabian AT aidima DOT 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.
src="/articulos/eclipse/EclipseParte1/Fig1.png" width=602> |
| Fig. 1. Eclipse como pentagrama. La figura muestra distintas facetas de Eclipse, que se abordarán a lo largo del artículo. |
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 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.
src="/articulos/eclipse/EclipseParte1/Fig2.png" width=572> |
| Fig. 2. Jerarquía de proyectos en Eclipse. |
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 (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 la década de 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.
src="/articulos/eclipse/EclipseParte1/Fig3.png" width=603> |
| Fig. 3. Voces desde el software libre y el software open source. |
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) 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).
src="/articulos/eclipse/EclipseParte1/Fig4.png" width=588> |
| Fig. 4. Estructura general de Eclipse. Extraído de la documentación oficial 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).
Para el desarrollador de plug-ins y de IDEs, sin embargo, la situación adquiere un aspecto
muy distinto: 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).
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.
src="/articulos/eclipse/EclipseParte1/Fig5.png" width=558> |
| Fig. 5. Arquitectura de los plug-ins de Eclipse. Traducido de la documentación oficial de Eclipse. |
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. 6. Vista del PDE. Extraído 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. 7. Eclipse como archipiélago |
[Fin de la primera parte]
Acerca del autor
Miguel Ángel Abián
Miguel Ángel Abián nació en Soria (1972). Se licenció
en Ciencias Físicas en 1995 por la U. de Valencia y consiguió la suficiencia investigadora
en 1997 dentro del Dpto. Física Aplicada de la U.V. Además ha realizado diversos
cursos de Postgrado sobre bases de datos, lenguajes de programación Web, sistemas
Unix, UML y Java. Ha participado en diversos programas de investigación TIC relacionados
con el estudio de fibras ópticas y cristales fotónicos, y ha publicado diversos
artículos en el IEEE Transactions on Microwave Theory and Techniques relacionados
con el análisis de guías de onda inhomogeneas y guías de onda elípticas.
Laboralmente ha trabajado como gestor de carteras y asesor fiscal
para una agencia de bolsa y ahora trabaja en el Laboratorio del
Mueble Acabado de AIDIMA (Instituto Tecnológico del Mueble y Afines), ubicado en Paterna (Valencia), en
tareas de normalización y certificación. En dicho centro se están desarrollando proyectos europeos
de comercio electrónico B2B para la industria del mueble basados en Java y XML (más información en www.aidima.es).
Sus intereses actuales son: el diseño asistido por ordenador de guías
de ondas y cristales fotónicos, la evolución de la programación orientada
a objetos, Java, el surrealismo y París, siempre París.
Reader Comments