Eclipse Java en Espanol
Eclipse Java en Espanol
¿Qué es Eclipse?
En la web oficial de Eclipse (www.eclipse.org), se define como “An IDE for everything
and nothing in particular” (un IDE para todo y para nada en particular). Eclipse es, en el
fondo, únicamente un armazón (workbench) sobre el que se pueden montar
herramientas de desarrollo para cualquier lenguaje, mediante la implementación de los
plugins adecuados.
La arquitectura de plugins de Eclipse permite, demás de integrar diversos lenguajes
sobre un mismo IDE, introducir otras aplicaciones accesorias que pueden resultar útiles
durante el proceso de desarrollo como: herramientas UML, editores visuales de
interfaces, ayuda en línea para librerías, etc.
El Proyecto Eclipse
El IDE Eclipse es, únicamente, una de las herramientas que se engloban bajo el
denominado Proyecto Eclipse. El Proyecto Eclipse aúna tanto el desarrollo del IDE
Eclipse como de algunos de los plugins mas importantes (como el JDT, plugin para el
lenguaje Java, o el CDT, plugin para el lenguaje C/C++).
Este proyecto también alcanza a las librerías que sirven como base para la construcción
del IDE Eclipse (pero pueden ser utilizadas de forma completamente independiente),
como por ejemplo, la librería de widgets SWT.
El Consorcio Eclipse
La librería SWT
El entorno de desarrollo Eclipse, incluyendo sus plugins, está desarrollado por completo
en el lenguaje Java. Un problema habitual en herramientas Java (como NetBeans) es
que son demasiado “pesadas”. Es decir, necesitan una máquina muy potente para poder
ejecutarse de forma satisfactoria. En gran medida, estas necesidades vienen
determinadas por el uso del API Swing para su interfaz gráfico.
Swing es una librería de widgets portable a cualquier plataforma que disponga de una
máquina virtual Java pero a costa de no aprovechar las capacidades nativas del sistema
donde se ejecuta, lo cual supone una ejecución sensiblemente más lenta que la de las
aplicaciones nativas.
SWT es una librería de widgets equivalente a Swing en la cual, se aprovechan los
widgets nativos del sistema sobre el que se ejecuta. El hecho de aprovechar los widgets
nativos, permite que la ejecución de interfaces de usuario sea mucho más rápida y fluida
que si se utilizase Swing y, además, siempre dispone del “Look and Feel” del sistema,
sin necesidad de “emularlo”.
La contrapartida es que la librería SWT es nativa, es decir, es necesario disponer de una
librería SWT específica para cada sistema operativo.
Existen versiones de SWT para los S.O. más habituales, incluyendo Windows, Linux,
HP-UX, MacOS, etc.
La descarga básica del entorno Eclipse incluye algunos de los plugins más básicos, pero
siempre es deseable obtener alguna funcionalidad extra. Para ello, es necesario instalar
nuevos plugins.
En el apartado Community del sitio web oficial de Eclipse se pueden encontrar enlaces a
cientos de plugins.
Advertencia.
Ejecutar Eclipse
Las versiones que se pueden descargar del sitio web de Eclipse vienen con un ejecutable
que permite lanzar directamente el IDE Eclipse. Antes de ejecutar Eclipse es importante
verificar que se tienen permisos de escritura en el directorio, ya que, la primera vez que
se ejecuta, Eclipse tiene que crear las carpetas en las que guardará información sobre
workspaces, logs, etc.
Truco Linux.
La carpeta en la que está el ejecutable de Eclipse no tiene por qué ser, forzosamente,
la que tenga permisos de escritura para el usuario. Si que debe tenerlos el directorio
desde el cuál se ejecuta Eclipse. Es decir, se puede llamar a Eclipse a través de un
script que esté en cualquier directorio (este si debe tener permisos de escritura).
Esta solución es muy útil para sistemas con varios usuarios y para organizar mejor el
trabajo en varios workspaces independientes.
La primera vez que se ejecuta Eclipse se puede ver una pantalla muy similar a la que se
muestra en la Figura 1. Antes de enfrentarse a la dura tarea del programador, es
interesante echar un primer vistazo al entorno para conocer sus características
particulares, la forma que tiene de organizar el trabajo, las herramientas adicionales que
ofrece, etc.
Editores
La ventana principal (la mas grande en la Figura 1), se llama “Editor”. Los Editores son
el lugar donde se escribirán los programas. Es posible tener varios Editores abiertos a la
vez, apilados uno encima de otro. En la parte superior de la ventana de Editores, se
mostrarán solapas que permiten acceder a cada uno de los Editores abiertos (o bien
cerrarlos directamente).
Vistas
Cada plugin puede definir Editores propios y todas las Vistas que sean necesarias. En la
Figura 1, están abiertas dos ventanas de Vistas.
La Vista vertical de la izquierda, mostrará el árbol de directorios de los proyectos
(cuando los haya).
La Vista horizontal inferior muestra una pequeña “agenda” de tareas pendientes que
pueden ser introducidas por el usuario, de forma directa, o por Eclipse, en función de
determinados eventos.
Para seleccionar qué Vistas se deben mostrar, se utiliza la opción “Show View” en el
menú “Window” (ver Figura 2).
Barras de Herramientas
El tercero de los componentes del entorno son las barras de herramientas. Existen dos
barras de herramientas: la barra de herramientas principal y la barra de Perspectivas.
La barra de herramientas principal contiene accesos directos a las operaciones mas
usuales (guardar, abrir, etc.), botones que permiten lanzar la ejecución de herramientas
externas y tareas relacionadas con el Editor activo (ejecutar un programa, depurar, etc.).
La barra de Perspectivas contiene accesos directos a las Perspectivas que se están
utilizando en el proyecto. Una Perspectiva es un conjunto de ventanas (Editores y
Vistas) relacionadas entre sí. Por ejemplo, existe una Perspectiva Java que facilita el
desarrollo de aplicaciones Java y que incluye, además del Editor, Vistas para navegar
por las clases, los paquetes, etc.
La Perspectiva que está abierta en la Figura 1, es la llamada “Resource Perspective” y
su función es navegar por el árbol de directorios de un proyecto y editar los ficheros que
contiene utilizando el Editor mas adecuado.
Se puede seleccionar las perspectivas activas – las que se muestran en la Barra de
Perspectivas – utilizando la opción “Open Perspective” del menú Window. Desde este
mismo menú también es posible definir Perspectivas personalizadas.
Además de las barras de herramientas principales, cada Vista puede tener su propia
barra de herramientas.
Al crear el proyecto Java, Eclipse, de forma automática, abre la Perspectiva Java, que es
la colección de vistas que define el plugin JDT para programar con Java. Esta
Perspectiva está compuesta de las vistas: Package Explorer (que permite navegar por
todos los paquetes –classpaths- a los que puede acceder el proyecto) y Outline (que
muestra un esquema de la clase cuyo código se está visualizando en el Editor activo).
Además, si la Perspectiva Java está activa, se añaden a la barra de herramientas
principal algunos botones extra que permiten acceder con rapidez a las funciones más
usuales (ejecutar, depurar, crear clases, etc.)
Ejemplo.
Nuevas Clases
El modo más directo de crear una nueva clase (o interface) es utilizar el “wizard de
creación de clases” que se puede lanzar, teniendo la Perspectiva Java activa, a través del
botón correspondiente (Figura 4) en la barra de herramientas.
Ejemplo.
Truco.
Otra opción también sencilla es reutilizar el código ya escrito de otra clase. La forma
más rápida es, sobre la misma vista Navigator, copiar un fichero (ctrl.+C) y pegarlo
en otra carpeta (ctrl.+V). Cuando se abra la nueva clase en el Editor, Eclipse
detectará y marcará los errores que tenga (por ejemplo, que la declaración package
no se corresponda con la ubicación de la clase en el árbol de directorios del
proyecto) y se encargará de proponer y ejecutar las soluciones adecuadas.
Si se quiere cambiar los imports, includes o la superclase, la opción más cómoda es
dejar que el mecanismo code completion de Eclipse haga el trabajo.
Cuando se crea una nueva clase se puede ver, en la ventana Editor, que algunas palabras
están coloreadas de forma diferente. Este marcado de palabras es debido a que los
Editores Java que implementa el plugin JDT, incluyen capacidad para realizar syntax
highlighting (o reconocimiento sintáctico de palabras reservadas del lenguaje).
De esta forma, las palabras reservadas del lenguaje aparecerán escritas en negrita y en
color Burdeos, los comentarios en verde y los comentarios de documentación (javadoc)
en azul.
Corrector de Errores
Aparte de identificar las palabras reservadas del lenguaje, JDT puede detectar, y marcar
sobre el código de un programa, los lugares donde se pueden producir errores de
compilación. Esta característica funciona de forma muy parecida a los correctores
ortográficos que tienen los procesadores de textos (ver Figura 5).
Cuando Eclipse detecta un error de compilación, se marcará la sentencia errónea,
subrayándola con una línea ondulada roja (o amarilla, si en lugar de un error se trata de
un warning).
Si el programador posiciona el puntero del ratón sobre la instrucción que produjo el
fallo, se mostrará una breve explicación de por qué dicha instrucción se ha marcado
como errónea.
Truco.
Code Completion
Truco.
Hay veces (generalmente cuando más falta hace) que el mecanismo de completado
automático no se dispara cuando se espera que lo haga, o tarda demasiado. Otras
veces, parece que se dispara siempre y acaba siendo pesado. La mejor opción es
acostumbrarse a lanzarlo siempre manualmente (en Eclipse se utiliza la combinación
de teclas ctrl.+ espacio).
Templates
Ejemplo.
En el ejemplo inferior, se pretende escribir un bucle for que itere un array. Se trata
de un tipo de construcción muy común, por ello, es firme candidata a ser asociada a
un template.
El plugin JDT, por defecto, define una buena cantidad de templates, tanto para
construcciones de código, como para la escritura de javadoc pero, de todas formas, es
posible definir nuevos templates personalizados (o modificar los existentes).
A la ventana de configuración de templates se accede a través del menú principal en la
opción WindowÆPreferencesÆJavaÆEditorÆTemplates.
Figura 7. Configuración de templates.
Code Formatting
Para formatear el código que muestra el Editor activo, basta con seleccionar la entrada
SourceÆFormat del menú contextual que aparece al pulsar con el botón derecho del
ratón sobre el propio Editor.
Ejemplo.
Truco.
El formateador de código permite despreocuparse casi por completo del aspecto del
código. Es decir, se puede, sin problemas escribir líneas inusualmente largas, varias
sentencias en una misma línea, etc. En resumen, se pueden hacer todas esas cosas
que a los programadores nos encantan y que están completamente prohibidas (pero
que son tremendamente cómodas a la hora de programar).
Eso sí, es muy importante que el formateador de código esté configurado de acuerdo
a las convenciones de presentación que se quieran aplicar.
Refactoring
En el punto anterior, se comentaban algunas de las facilidades que ofrece Eclipse para
crear y manipular bloques de código de una forma fácil y cómoda, evitando el tedio de
tener que realizar todo el trabajo a mano.
Todas las operaciones de manejo de código explicadas trabajan, únicamente, con código
escrito sobre un mismo fichero (o perteneciente a una misma clase). Si las
modificaciones que se quieren realizar deben involucrar a varias clases, escritas en
varios ficheros diferentes, todos ellos pertenecientes al mismo proyecto, entonces se
pueden utilizar las herramientas de Refactorización.
Para realizar el cambio de nombre, habrá que seleccionar el nombre del método a
modificar y lanzar la operación RefactorÆRename… del menú contextual. Aparece
el diálogo que solicita un nuevo nombre y pide confirmación para actualizar también
las referencias que se hagan, en el proyecto, al método que se modifica.
Si se pulsa el botón “Preview >”, se muestra una comparación del antes y el después
de cada porción de código que se va a modificar.
Una de las características más curiosas del IDE Eclipse es el modo en que se compilan
los proyectos. No existe en Eclipse ningún botón que permita compilar individualmente
un fichero concreto. La compilación es una tarea que se lanza automáticamente al
guardar los cambios realizados en el código. Por esta razón es prácticamente innecesario
controlar manualmente la compilación de los proyectos.
En caso de necesidad, existe una opción en la entrada Project del menú principal,
llamada “Rebuild Project” que permite lanzar todo el proceso de compilación completo
(también existe la entrada “Rebuild All” para re-compilar todos los proyectos abiertos).
Truco.
Si se quiere utilizar una herramienta de compilación (en este caso Ant) diferente del
constructor (Builder) definido por defecto por la herramienta Eclipse, debe ejecutarse la
opción “ProjectÆPropertiesÆExternal Tool Builders”. En esta ventana, se pueden
añadir, modificar o eliminar los diferentes mecanismos de compilación y construcción
disponibles para el proyecto.
Para añadir un nuevo script Ant, habrá que pulsar el botón “New…” y seleccionar la
opción “Ant Build” que, nos llevará directamente al wizard de configuración de scripts
Ant.
Figura 8. Wizard Ant.
Como se puede ver en la Figura 8, el wizard Ant es una herramienta sencilla. En la
solapa principal (la que se muestra en la Figura 8) es necesario indicar la localización
del script Ant que se quiere utilizar para compilar el proyecto, así como el directorio
base y los argumentos. El resto de las solapas sirven para definir el modo en que Eclipse
va a gestionar las llamadas al script.
Ejecutar
Una vez compilado correctamente, ejecutar el proyecto es la parte más sencilla (si el
proyecto está correctamente programado claro). Prácticamente todas las opciones de
ejecución se pueden manejar desde el botón Run de la barra de herramientas principal
(ver Figura 9).
El botón Run puede utilizarse de dos formas: bien pinchando el propio botón, en este
caso, se repetirá la última ejecución realizada, o bien pinchado sobre la flecha a su lado
lo cual permitirá ver el menú de ejecución.
El menú de ejecución, a su vez tiene dos partes. La entrada “Run As” permite ejecutar
directamente la clase que se está mostrando en la ventana del Editor activo, utilizando la
configuración de ejecución por defecto.
La entrada “Run…”, permitirá definir nuevas configuraciones de ejecución.
Figura 10. Ventana de configuraciones de ejecución.
Depurar Aplicaciones
Lanzar el depurador es una tarea exactamente igual que ejecutar un programa, solo que
en lugar de utilizar el botón de ejecución, se utiliza el botón de depuración (ver Figura
11). Estos dos botones, y los menús que despliegan, tienen un comportamiento
exactamente idéntico (salvo por el hecho de que el botón de depuración provoca la
ejecución paso a paso de los programas).
Nota.
Vista Editor
Vistas de Inspección
En la parte superior izquierda, se puede ver la ventana Debug. En esta ventana es donde
se controla la ejecución del programa que se está depurando ya que contiene la barra de
botones de ejecución. En esta barra están los clásicos botones para detener la
depuración, ejecutar hasta el final, ejecutar paso a paso, etc.
Truco.
Es más útil controlar la ejecución del programa utilizando las teclas. Con F5 se
ejecuta paso a paso el programa y con F6 se ejecuta una función sin entrar a
ejecutarla paso a paso.
Además, esta ventana también muestra información a cerca de los hilos (threads)
activos y de los procesos de depuración realizados con anterioridad.
Atención.
Muchas veces, por prisa o por descuido, se lanzan nuevos procesos de depuración
sin detener los anteriores (sobre todo, cuando se entra en una vorágine de cambios
con el objetivo de solucionar un bug que se resiste más de lo esperado). Si los
procesos abiertos se apilan demasiado, se puede agotar la memoria. Para evitarlo, de
vez en cuando, se puede echar una ojeada a la perspectiva Debug y comprobar que
todos los hilos tengan el estado [terminated], y si no lo tienen, finalizarlos (con el
botón que detiene la depuración y el hilo previamente seleccionado en la vista
Debug).
La vista de inspección (a la derecha de la vista Debug), permite ver los valores de los
diferentes elementos (variables, breakpoints, expresiones…) que intervienen en el
programa, en un instante de ejecución determinado.
Las dos vistas más interesantes son la vista de inspección de variables, que muestra los
valores que toman todas las variables (atributos, campos, etc.) cuyo ámbito alcanza a la
línea que se está ejecutando en un momento dado y la lista de inspección de
breakpoints.
Establecer un breakpoint es tan sencillo como hacer doble clic en el margen izquierdo
del Editor del código, a la altura de la línea sobre la que se quiere detener la ejecución.
El breakpoint creado quedará identificado por un punto azul (ver Figura 12) sobre la
línea.
Vista Consola
Por último, en la parte inferior de la Perspectiva Debug, se muestra la consola. La
consola es la vista sobre la cual se redirecciona tanto la entrada como la salida estándar,
del programa que se está depurando (o ejecutando).
Documentación
Además de las librerías estándar de Java, es frecuente que en los proyectos se utilicen
otras muchas librerías, que tengan su propia documentación. Eclipse permite integrar en
su sistema de ayuda cualquier JavaDoc relacionado con las librerías que se utilicen en
un proyecto.
La configuración de la documentación de las librerías que utiliza el proyecto se realiza
desde la ventana de configuración de las propias librerías en ProjectÆPropertiesÆJava
Build PathÆLibreries.
En esta ventana, cada librería (.jar) en el classpath del proyecto, aparece como una
entrada que tiene dos propiedades (se muestran pulsando el signo “+” al lado de su
nombre): la ubicación de su documentación y la ubicación de su código.
Para poder utilizar la documentación de una librería, basta con escribir su ubicación en
el lugar correspondiente.
Utilizar la documentación
Una vez que todas las posibles fuentes de documentación del proyecto han sido
configuradas acceder a ellas es lo más sencillo, basta con seleccionar, en el Editor, el
elemento que se quiere consultar y pulsar F1. La ayuda se desplegará, en formato
HTML, en el navegador integrado de Eclipse (Figura 16).
Figura 16. Ayuda en línea de Eclipse.
Además de poder consultar las diferentes fuentes de documentación javadoc que maneja
el proyecto, Eclipse permite, de una forma muy sencilla generar, automáticamente, la
documentación del propio proyecto.
El plugin JDT incluye un wizard para la creación de casos de prueba (JUnit Test Cases)
muy similar al propio wizard de creación de clases, explicado en este mismo
documento.
Crear un nuevo TestCase, como decía, es muy similar a crear una nueva clase. De igual
forma, se puede utilizar el botón de creación de clases (en la barra de herramientas
principal, con la Perspectiva Java activa). En el menú desplegable que se muestra, en
lugar de seleccionar Class o Interface, como se había explicado, se debe seleccionar la
opción TestCase, lo cual mostrará el wizard JUnit.
Este wizard se compone de dos pantallas. La primera de ellas (Figura 21) sirve para
realizar una configuración general de la clase de prueba (TestCase), indicando, entre
otras cosas: su nombre, el paquete al que pertenecerá, su superclase, los métodos que
debe sobrescribir (por ejemplo, SetUp(), el main(String[]) , etc.) o la clase sobre la cuál
se va a realizar las pruebas.
En la segunda pantalla (Figura 22) del wizard JUnit se seleccionarán los métodos para
los cuáles se deben generar casos de prueba.
Figura 22. Wizard JUnit (II)
Ejemplo.
Para crear el caso de prueba, se utilizará el wizard JUnit tal cual se acaba de
explicar. En las Figuras 21 y 22, se pueden ver los datos de configuración del caso
de prueba de este ejemplo.
Al igual que en las perspectivas que se han tratado en este documento, en la Perspectiva
CVS, la ventana principal es el Editor. De forma análoga al resto, el Editor, en la
Perspectiva CVS permite ver el código de los archivos almacenados en el repositorio.
La vista “CVS Repositories” (a la izquierda en la Figura 23) es la ventana fundamental
para el acceso a repositorios de código. Sobre esta vista se podrán establecer (y romper)
conexiones con los diferentes repositorios, además de servir como navegador para cada
uno de ellos.
Para establecer (o eliminar) conexiones con repositorios, se utiliza el menú contextual
(pop-up) de la vista. En este menú, se puede acceder a opciones que permitirán
configurar conexiones, descartar conexiones activas, modificar sus parámetros, etc.
La tercera vista (en la parte inferior derecha) de la Perspectiva CVS (vista “CVS
Resurce History”) muestra el registro histórico de cambios aplicados sobre el archivo
que se está mostrando en el Editor.
Establecer una conexión CVS es tan sencillo como rellenar los campos del wizard,
proporcionando la información necesaria. Se puede ver en la Figura 24 que la
información necesaria es: localización del repositorio, autentificación del usuario en
dicho repositorio y método de conexión.
Compartir Proyecto
Control Cambios
Gestor de Tareas.
El entorno Eclipse incluye una vista, de nombre Tasks, que sirve para gestionar las
tareas pendientes en un proyecto.
La vista Tasks (Figura 26), actúa también como B.O.E (Boletín Oficial de Eclipse), ya
que es el medio a través del cual, Eclipse notifica cualquier error, advertencia, etc. que
detecte a la hora de compilar, generar código o de realizar cualquier tarea de forma
automática.
Figura 26
Cuando Eclipse compile una clase, si detecta algún error de compilación, o algún
warning, este evento se notificará, en la vista Tasks, como una tarea más. Lo mismo
ocurre cuando se escribe, de forma automática, esqueletos de código o documentación
que deben ser rellenados por el programador.
En el menú contextual (pop up) de la vista Tasks, además de introducir nuevas tareas, es
posible purgar las tareas completadas, establecer filtros para que solamente se muestren
las apropiadas, etc.
Búsqueda semántica.
Prácticamente todos (por no decir todos) los editores y entornos de desarrollo disponen
de un mecanismo de búsqueda más o menos completo. La diferencia del motor de
búsquedas que implementa Eclipse, respecto al de otros entornos, es que éste no se
limita únicamente a buscar coincidencias sintácticas en los archivos del proyecto (como
hacen la mayoría) sino que dispone de opciones de búsqueda semántica.
Todas las opciones que se han comentado hasta ahora, en este documento, están
implementadas en la versión estándar del IDE Eclipse.
Eclipse permite extender esta funcionalidad básica gracias a su arquitectura de plugins.
Instalar un plugin es muy sencillo, basta con descomprimir el archivo del plugin
(generalmente un .zip) en la carpeta Eclipse/Plugins. Una vez “instalado” el plugin de
esta manera, la siguiente vez que se ejecute Eclipse, éste se encargará de realizar la
carga de todos los nuevos plugins añadidos.
Es posible saber, qué plugins están activos en un momento determinado., para ello, es
necesario lanzar la ayuda de Eclipse (desde el menú principal, seleccionado la entrada
“HelpÆAbout Eclipse Platform”). Desde la ventana que se despliega, se puede ver la
lista de plugins (Figura 28) pulsando el botón “Plug-in Details”.
Figura 28
Plugins
CDT
CDT es el equivalente, para los lenguajes C y C++, al plugin JDT. Prácticamente todo
lo escrito, en este documento, referido JDT es aplicable a CDT. Las diferencias más
importantes están en la gestión de la documentación Javadoc (que es específica de la
plataforma Java) y en el uso de librerías JUnit (también específicas de Java). Otra
diferencia importante es que CDT no puede compilar automáticamente el código, es
necesario indicar un fichero Makefile para ello (si no se indica ningún Makefile y existe
alguno en el directorio principal del proyecto, lo utilizará). CDT es un plugin oficial de
la plataforma Eclipse y puede ser obtenido de la dirección www.eclipse.org.
VisualEditor
Hasta hace muy poco, la mayor pega que se le achacaba al IDE Eclipse era que no
disponía de un editor gráfico de interfaces de usuario. Pues bien, esta pega ya no existe.
El Proyecto Eclipse dispone de un plugin, llamado Visual Editor, que permite, de forma
sencilla y completamente visual, diseñar interfaces gráficos de usuario (Figura 29).
VE es un plugin oficial de Eclipse y puede obtenerse de la dirección www.eclipse.org.
Omondo UML
Los plugins disponibles para Eclipse no se tienen por qué limitar obligatoriamente a la
programación. Existen plugins que permiten integrar otras partes del proceso de
desarrollo de aplicaciones como, por ejemplo, el diseño. El plugin UML (Figura 30)
permite unificar diseño e implementación en una sola herramienta. Cualquier
actualización realizada sobre el modelo UML, se verá reflejada en el código fuente de
todas las clases a las que dicha modificación afecte, y a la inversa, cualquier cambio en
el código se verá reflejado en los diagramas de clases UML.
Figura 30. Plugin Omondo UML.
Jalopy
A pesar de que Eclipse incluye una herramienta para formatear el código fuente, es
posible, que sus opciones estén algo limitadas para determinados proyectos. Jalopy es
un plugin que permite formatear el código, añadir comentarios, etc. pero es mucho más
flexible que la herramienta de formateo estándar.
Lomboz