Una de los mejores entornos de programación para Java, por no decir el mejor, es Eclipse. Está disponible para todas las plataformas habidas y por haber aunque se da el caso de que al bajarlo para Ubuntu por medio del sistema de paquetes su ejecución suele ser demasiado lenta. Esto ocurre a causa de que Eclipse está desarrollado en Java y por defecto se va a utilizar para su ejecución la implementación libre de la máquina virtual de Java conocida como GIJ (GNU Interpreter for Java).

He tenido la oportunidad de estudiar a fondo esta herramienta y comprobé que es muchísimo más lenta que su equivalente privativo por lo que si priorizamos la velocidad de ejecución recomiendo utilizar en nuestro sistema la versión de Sun. Eso hará que Eclipse se ejecute con mayor agilidad.

Lo primero que tenemos que hacer es instalar el Java Development Kit de Sun por medio del sistema de paquetes que incorpora Ubuntu. Escribiremos para ello:

 $ sudo apt-get install sun-java6-jdk

Una vez hecho esto vamos a seleccionar la ejecución de la máquina virtual de Sun cuando ejecutemos por consola “java” lo que haremos por medio del comando:

 $ sudo update-alternatives --config java
Hay 4 alternativas que proveen `java'.

  Selección     Alternativa
-----------------------------------------------
          1    /usr/bin/gij-4.2
          2    /usr/bin/gij-4.3
*+        3    /usr/lib/jvm/java-gcj/jre/bin/java
          4    /usr/lib/jvm/java-6-sun/jre/bin/java

Pulse  para mantener el valor por omisión [*] o pulse un número de selección:

Tendremos que pulsar, en este caso, 4. A continuación haremos que Eclipse seleccione para su ejecución la máquina virtual de Java de Sun. Para ello tenemos que editar el fichero /etc/eclipse/java_home y poner en primera línea la ruta a la JVM que vamos a utilizar, es decir, /usr/lib/jvm/java-6-sun. Ahora podremos ejecutar:

 $ eclipse
searching for compatible vm...
  testing /usr/lib/jvm/java-6-sun...found

Ya hemos conseguido que Eclipse vaya más rápido. Por último, si nos interesa compilar utilizando el Kit de Sun podemos entrar en Window>Preferences dentro de Eclipse y movernos hasta Java>Instaled JREs. Una vez ahí pulsaremos Search para añadir el JDK de Sun buscando desde el directorio /usr/lib. Una vez añadidos todos, seleccionaremos el que más nos convenga.

Para comunicar cualquier error o matiz en este tip, deja un comentario.

Una de las dudas más comunes que abordan a los usuarios nuevos en el mundo de GNU/Linux trata sobre el montaje automático de las particiones y de sus permisos. Las órdenes de montaje y sus opciones se encuentran alojadas en el fichero /etc/fstab.

Normalmente, al instalar distribuciones como Ubuntu, en el fstab se generan las líneas de montaje de nuestras particiones automáticamente pero de un modo genérico. Muchos habrán visto que si lo dejamos tal cual, los nombres de los archivos de la partición al hacer un ls aparece en color verde. Esto ocurre cuando los ficheros tienen permisos de ejecución. Sin más vamos a entrar en materia.

En primer lugar tenemos que identificar el dispositivo en el que se aloja la partición. Cuando el disco es SATA, el primer dispositivo se nombra como sda, el segundo será sdb, y así sucesivamente. Las particiones correspondientes al primer disco se nombrarán como sda1, sda2, etc. En caso de tener un disco IDE la nomenclatura será hda, hdb, y sus particiones hda1, hda2 … etc. Los descriptores de todos los dispositivos y sus correspondientes particiones están en el directorio /dev. Para identificar cuáles son las particiones que queremos montar podemos utilizar la herramienta fdisk, a la que pasaremos como argumento el disco que queremos examinar. Si queremos ver las particiones del disco sda haremos:

fdisk /dev/sda

Con fdisk podemos manejar las particiones de modo flexible y seguro. Mediante la introducción de p veremos un listado de las particiones que tenemos. En mi caso he obtenido:

Disposit. Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sda1   *           1        1848    14844028+  83  Linux
/dev/sda2            1849        1941      747022+  82  Linux swap / Solaris
/dev/sda3            1942        5766    30724312+   7  HPFS/NTFS
/dev/sda4   *        5767        7296    12289725    7  HPFS/NTFS

Una vez identificada la partición que queremos montar podemos empezar a definir el fstab. La estructura de este archivo usa una sintaxis especial. Cada línea está formada por seis campos, separados por espacios en blanco (espacio, tabuladores o una combinación). Cada campo tiene su propio significado:

• El primer campo muestra la partición descrita (la ruta al fichero de dispositivo)
• El segundo campo muestra el punto de montaje donde la partición debe montarse
• El tercer campo muestra el sistema de ficheros usado por la partición
• El cuarto campo muestra las opciones de montaje usadas por mount cuando trata de montar la partición. Como cada sistema de ficheros tiene sus propias opciones de montaje, le animamos a leer la página man de mount (man mount) para un listado completo. Cuando existen múltiples opciones se separan por comas.
• El quinto campo es usado por dump para determinar si la partición necesita ser volcada o no. En general puede dejar esto como 0 (cero).
• El sexto campo es usado por fsck para determinar el orden en que los sistemas de ficheros deben ser comprobados si el sistema no se apagó correctamente. La partición raíz debe tener un 1 mientras que el resto puede tener 2 (o 0 en el caso en que la comprobación del sistema de ficheros no sea necesaria).

Si queremos montar mi partición de datos, cuya ruta al descriptor es /dev/sda3, el primer campo será esta misma ruta. El segundo será el directorio en el que queremos montar la partición, el cual debe existir. En mi caso lo haré en /media/DATOS. Como ya hemos visto mediante fdisk, el sistema de ficheros de esta partición es ntfs por lo tanto esta va a ser la opción a especificar en el tercer campo. En el cuarto campo irán las opciones de montaje. El quinto y sexto campo lo dejaremos a 0. En este caso voy a explicar los que yo he utilizado y que considero más importantes; por supuesto, hay muchas otras opciones para las que os remito a las manpages. Veamos cuales son estas opciones:

• auto: Si especificamos esta opción, la partición se montará automáticamente al iniciar el sistema. La opción contraria es noauto. Lo más interesante es, sin duda, el montaje automático.
• exec: Esta opción la pondremos si tenemos interés en que podamos ejecutar binarios sobre la partición. Si por ejemplo vamos a programar y ejecutar sobre la partición será necesario especificarla. La opción contraria es noexec.
• rw: Al montar la partición, si especificamos esta opción estaremos permitiendo la lectura y escritura. Los permisos también deberán estar en concordancia con esta opción. Si queremos que la partición sea de sólo lectura la opción adecuada es ro (Read Only).
• uid: Digamos que está opción indicará a qué usuario/os pertenecen los ficheros de la partición que vamos a montar. Estos usuarios deberán ser indicados a través de su identificación. Podemos revisar qué número corresponde a cada usuario examinando el fichero /etc/passwd. En mi caso, el valor del uid para mi usuario es 1000.
• gid: Similar a la opción anterior pero referente al grupo de usuarios. Podemos ver el gid del grupo al que pertenecemos en el fichero /etc/groups. En mi caso es el mismo que el de usuario, 1000.
• fmask: Se trata del umask para los ficheros de la partición a montar. Así podremos especificar los permisos que tendrán estos ficheros. Dado que la partición de datos pertenece a mi usuario, voy a darle los mismos permisos que tendrán los ficheros de mi home por defecto que son lectura y escritura para el propietario (especificado en uid), lectura para usuarios del mismo grupo (especificado en gid) al que pertenece el fichero y  lectura para el resto de usuarios. Estos permisos son rw-r–r–, en binario serán 644 y dado que lo que utilizamos con fmask es un umask 777-644=133. El valor será 133.
• dmask: Es igual que la opción anterior pero en este caso se refiere a los directorios. Para que podamos abrir un directorio es necesario que éste tenga permisos de ejecución por lo que los permisos serán los mismos que para ficheros pero añadiendo permisos de ejecución para propietario, grupo propietario y el resto de usuarios. Por tanto los permisos serán rwxr-xr-x que en binario es 755. En umask sería 777-755=022. El valor será 022.
• utf8: Lo pondremos si la codificación de los nombres es utf8, si estamos utilizando otra codificación utilizaremos la opción que le corresponda.

Después de ver cada una de las opciones la línea será la siguiente:

/dev/sda3       /media/DATOS    ntfs    auto,exec,rw,uid=1000,gid=1000,dmask=022,fmask=133,utf8 0       0

Ahora tendremos que comprobar que funciona. Para ello utilizaremos la orden mount a la que tendremos que pasar el argumento -a para ejecutar el montaje de lo que se encuentra en el fstab. Eso sí, antes tenemos que desmontar la partición si ya la tenemos activa. Para ello escribiremos:

 $ sudo umount -a

Se intentarán desmontar todas las particiones del fstab lo que, obviamente, no es posible. En caso de que no podamos desmontar nuestra partición de datos es porque algún proceso la está utilizando y se nos mostrará un error que indicará que el dispositivo que queremos desmontar está siendo usado. Podemos comprobar qué proceso es el que lo está haciendo con la instrucción fuse y el descriptor de la partición del siguiente modo:

 $ sudo fuse -m /dev/sda3

Esta instrucción nos sacará por pantalla el PID de los procesos que están ocupando la partición. Suponiendo que el proceso con PID 7418 está utilizando la partición podemos proceder a matarlo, desmontar y volver a montar con:

 $ sudo kill -9 7418
 $ sudo umount -a
 $ sudo mount -a

Ahora podemos irnos a la partición montada y comprobar si los permisos están correctos por medio de un ls. Seguido el proceso tendremos los archivos montados en nuestra partición con los mismos permisos que los del HOME de manera que se integrarán perfectamente.

Si detectas algún error en este tutorial, hay algo mal explicado o te ha sido útil deja tu comentario !

Hoy voy a dejar un post de los que provocan un aluvión de entradas al Blog, entradas que seguramente serán puntuales pero no importa porque esto me ha sido útil y en un futuro me puede servir de nuevo, por eso lo voy a escribir. Somos muchos los que hemos migrado a ‘Amarok 2′ tras su liberación oficial hace un par de semanas. El cliente de mensajería que utilizo en mi desktop es ‘Emesene’, una aplicación escrita en Python que imita en cierto modo a Windows Messenger y que tiene una gran cantidad de plugins para su personalización.

El problema ha surgido con el plugin CurrentSong con el cual se puede poner como mensaje secundario del nickname el nombre de la canción que estamos escuchando. Si lo teníamos funcionando anteriormente con Amarok 1.4, el log del plugin no nos dará ningún error, simplemente expondrá que no se está escuchando ninguna canción.

Buscando en Google la verdad es que la solución ha sido fácilmente hallada. Resulta que la comunicación entre la versión anterior de ‘Amarok’ y ‘Emesene’ se realizaba a través de python-dcop pero aquí ha variado ligeramente por lo que es necesaria una modificación del plugin.

En el Trac de ‘Emesene’ es donde se encuentra un script para dar solución a este problema y que es el siguiente. Si la versión del cliente de mensajería que utilizamos es la 1.0, disponible en los repositorios de Ubuntu, la instalación se habrá realizado en /usr/share por lo que podemos pasar a ejecutar el script que realizará las modificaciones necesarias. Es necesario tener conexión a Internet ya que se descargarán ciertos archivos de código nuevos.

 $ sudo sh pluginamarok2

En caso de que utilicemos la versión SVN y tengamos el cliente en otro directorio habrá que modificar las rutas de los archivos reflejados en el script por lo que lo editamos y cambiamos /usr/share/ por nuestra ruta, en mi caso fue /etc/. Después podemos ejecutar el script igual que en la línea anterior.

Tan sencillo como eso. Ahora podemos abrir ‘Amarok’, ‘Emesene’ y activar el plugin en este último seleccionando como programa ‘Amarok2′ y listo. Si encuentras algún error o tienes alguna sugerencia deja tu comentario.

¡A disfrutar!

Es posible que se de la situación de que tengas que pasar un archivo muy grande, como por ejemplo de unos 8Gb de una partición a otra o incluso de una máquina a otra. Hace no demasiado tiempo era impensable tener archivos de tanto tamaño pero hoy en día no es algo raro por lo que los sistemas más antiguos puede tener ciertas dificultades para su manejo.

Para empezar yo hace ya bastante tiempo que utilizo Windows y GNU/Linux conjuntamente en la misma máquina. Tenía la necesidad de compartir los archivos entre los dos sistemas operativos por lo que recurrí a un formato de partición que se podía leer correctamente en los dos. Por aquél entonces no había soporte completo para NTFS en GNU/Linux por lo que, obviamente, me estoy refiriendo a FAT32.

Lo que yo no sabía, ni me había preocupado de saber hasta ayer, son las limitaciones de este sistema de ficheros. Ayer intentaba pasar un archivo de 8.6 Gb  de mi partición Linux Ext3 a la FAT32 y cuando iba por los 4GB me lanzaba un error alegando que el archivo era demasiado grande. Al principio pensé que podía ser por Nautilus, por el propio sistema operativo o incluso por Samba, ya que además me había ocurrido al copiar de una máquina a otra. Resulta que el error se da porque FAT32 no es capaz de manejar archivos de más de 4Gb de tamaño.

La solución es simplemente no utilizar este formato de partición. Hoy, gracias al avance del software libre, podemos utilizar las particiones NTFS sin ningún problema en GNU/Linux ya que el soporte va normalmente compilado como un módulo del kernel y su desarrollo es más que aceptable. Pienso que esta es la opción más recomendable para poder compartir archivos entre GNU/Linux y Windows ya que no hay una limitación en el tamaño de los archivos a manejar. Además si utilizamos los dos sistemas operativos podemos utilizar Partition Magic desde Windows para convertir la partición de FAT32 a NTFS sin tener que formatearla y, por tanto, sin perder archivos.

Entre los que utilizamos GNU/Linux, ya sea con Gnome, KDE o cualquier otro gestor de escritorio, siempre se suele tener un reproductor que mantenga una librería con toda nuestra música. Si además eres un apasionado de la música, todavía más. El más famoso, que más prestaciones ofrece y estéticamente más bonito es, sin ninguna duda, Amarok.

Hay gente que por utilizar escritorios distintos de KDE se niega a utilizar Amarok por el tiempo de carga de la aplicación, ya que es necesario cargar las librerías necesarias de este entorno para que funcione. Yo pienso que ese tiempo vale la pena porque se trata de una aplicación extraordinaria y ahora ha mejorado con la liberación de Amarok 2 que, además, es multiplataforma.

Sí, has leído bien, ahora Amarok también está disponible en Windows y Mac OS además de GNU/Linux aunque al ser la primera versión para los dos primeros sistemas operativos, es una beta. Amarok 2 ha sido completamente reescrito desde cero utilizando QT4 lo que le otorga un aspecto aún más atractivo que el anterior. La interfaz ha mejorado notablemente no solo en lo visual sino que además ahora es más sencilla la visualización de las letras, información del artista, estadísticas del tema que está sonando, etc, por medio de applets que podemos ir añadiendo según nuestro gusto en diferentes espacios que se muestran en la zona central.

Algunas de las características secundarias de la versión antigua no se han implementado todavía, como por ejemplo los efectos de visualización. A pesar de esto, se han aportado nuevas características, entre ellas está la integración con numerosos servicios online como Jamendo, Libribox, Magnatune, etc. Además se mantiene la sintonización de una interminable lista de estaciones de radio por medio de Shoutcast.

Se han implementado también las listas de reproducción dinámicas de modo que según lo que escuchemos más habitualmente y una cierta aleatoriedad es posible crear un tracklist que habitualmente nos será agradable. La visualización de nuestra biblioteca también ha sido mejorada y ahora se muestra el artwork en miniatura (que se puede buscar automáticamente en Amazon) de cada álbum junto al nombre del mismo. Por supuesto todo esto sólo son palabras y lo mejor es probarlo.

Para la instalación en Ubuntu se debe hacer lo típico. Si estamos utilizando Intrepid Ibex tenemos que poner un nuevo repositorio a las fuentes de APT editando el /etc/apt/sources.list y añadiendo:

 deb http://ppa.launchpad.net/kubuntu-members-kde4/ubuntu intrepid main

Si utilizamos otra versión de Ubuntu como por ejemplo Hardy utilizaremos el mismo repositorio cambiando intrepid por hardy. El nombre del paquete es amarok-kde4 por lo que para instalarlo escribiremos el siguiente comando en una consola:

 $ sudo apt-get install amarok-kde4

Comentar que la instalación en Intrepid elimina la versión anterior en caso de existir y porta la configuración de los directorios de la librería. En el caso de Hardy no nos borra la versión anterior y hay que configurarlo desde cero. Para la instalación en cualquier otro sistema operativo entrad aquí.

Realmente, la pregunta del millón es ¿va bien? y la respuesta es si pero. Podemos estar tranquilos, Amarok no va a borrarnos los archivos por un fallo al indexar ni nada parecido si bien es cierto que, como se anuncia en la web oficial, esto es sólo un comienzo y no un final. Existen algunos fallos por pulir todavía. Un ejemplo, que no tengo claro si es un fallo, es que un álbum en cuyo directorio tenga una lista de reproducción m3u no se agrega a la librería. Otro es que cuando queremos parar Amarok (no hay que confundir con pausarlo), el reproductor se detiene e inmediatamente después reanuda como si hubiéramos pulsado play. Para detenerlo completamente habría que darle a pausa y después al botón de stop; es una tontería, pero jode. Algo que si es más importante es que al probarlo en Hardy no se podía arrancar porque al intentar construir la lista de reproducción se lanzaba un error que no me he molestado en buscar porque iba a actualizar a Intrepid.

En definitiva, la nueva versión de Amarok ha mejorado lo presente. Al haber sido completamente reescrito tiene algunos fallos que se pueden mejorar pero la interfaz ahora es mucho más atractiva, con un acabado elegante y más fácil de utilizar. Os dejo una captura de mi Amarok 2; en mi caso he puesto en el centro la información del tema actual y la letra.

]]> http://just4cool.wordpress.com/2008/12/13/amarok-2-ya-esta-disponible/feed/ 0 elmo am2 pantallazo-radiohead-bodysnatchers-amarok-2 http://just4cool.wordpress.com/2008/12/06/makefiles-gnu-gcj/ http://just4cool.wordpress.com/2008/12/06/makefiles-gnu-gcj/#comments Sat, 06 Dec 2008 16:25:58 +0000 elmoesdios http://just4cool.wordpress.com/?p=123 ]]>

Como ya conté en anteriores posts, en mi proyecto de fin de carrera tenía que compilar una librería de clases Java bastante extensa con GNU GCJ. Es bastante sencillo compilar una clase simple, incluso compilar varias de ellas a mano, pero en el caso de una colección importante, el compilar y enlazar es una tarea muy larga y aburrida.

En su momento estuve buscando cómo podía automatizar esta tarea de compilación por medio de herramientas diseñadas para esta labor. Lo primero que se me ocurrió fue crear un paquete de instalación por medio de las GNU Autotools pero al mirar en la documentación pude comprobar que no había soporte para GCJ por lo que elegí una de las herramientas que se incorporan en este paquete: GNU Make.

Además de la utilización de las Autotools y Make también pensé en utilizar Apache Ant que tiene bastantes características positivas como por ejemplo que no depende de las órdenes del Shell en el que se ejecute el Antfile por lo que la portabilidad está garantizada. A pesar de ésto, y de que Make sí depende del Shell, me decanté por esta última opción al estar más extendido y generalizado en el mundo de GNU/Linux su uso.

La primera gran pregunta que me aborda es ¿cómo puedo escribir el Makefile para compilar toda la librería sin alterar la estructura de paquetes que originalmente tiene en el modelo tradicional de Java?. Podríamos escribir línea por línea la compilación de cada una de las clases con su ruta y al final enlazarlo todo en una línea enorme. Así se puede hacer pero lo mejor sería encontrar la manera de automatizar la lectura de todas las clases para no tener que escribir la ruta a cada una de ellas.

Lo que vamos a hacer es mantener dentro de Makefile varias cadenas que contengan la ruta a todos los ficheros de código fuente que queremos compilar y la ruta a todos los objetos que se originarán después de la compilación de las fuentes, que además serán enlazados. Para este fin utilizaremos la opción wildcard mediante la cual se puede utilizar un comodín tal como lo haríamos con un ls en Bash de manera que se nos devolverá el nombre de todos los ficheros que concuerden con la expresión regular. En primer lugar se obtienen los ficheros de código fuente y luego a partir de ellos cambiaremos .java por .o para tener los objetos.

Después de esto escribiremos las acciones del Makefile del modo lo más genérico posible. Definiremos una acción a partir del nombre de los objetos para compilarlos uno a uno mediante una expresión regular. Una vez tengamos todos los objetos simplemente habrá que realizar el enlace señalando cuál es las clase principal del programa. A continuación os dejo un pequeño ejemplo orientativo donde, en el directorio en el que se encuentra el Makefile ,se han incluido las fuentes en un subdirectorio llamado src y los objetos serán compilados a otro subdirectorio llamado bin:

##############################################
#  Makefile para compilación con GCJ
#  Creador por ELMOesDIOS para
#  http://just4cool.wordpress.com
##############################################

## Destino de los objetos y del ejecutable
DEST_DIR = bin

## Nombre del Ejecutable y la librería dinámica
BINARY_NAME := MiPrograma

## Cargamos las fuentes de todas las clases a compilar
JAVA_SOURCES := $(wildcard src/paqueteA/*.java)
JAVA_SOURCES += $(wildcard src/paqueteA/paqueteAA/*.java)
JAVA_SOURCES += $(wildcard src/paqueteA/paqueteAB/*.java)
JAVA_SOURCES += $(wildcard src/paqueteA/paqueteAB/paqueteABC/*.java)

## A partir de la cadena de fuentes obtenemos la de objetos
JAVA_OBJECTS := $(JAVA_SOURCES:src/%.java=$(DEST_DIR)/%.o)

## Macros para la compilación
GCJ := $(GCC_PATH)/usr/bin/$(GCC_TARGET)gcj
GCJ_FLAGS := -O2 -g --classpath=src

## Instrucción general para obtener el ejecutable
all: $(DEST_DIR)/$(BINARY_NAME)

## Compilar las fuentes de nuestro programa
$(JAVA_OBJECTS): $(DEST_DIR)/%.o: src/%.java
	$(GCJ) $(GCJ_FLAGS) -c $< -o $@

## El ejecutable final se obtiene en el enlace
$(DEST_DIR)/$(BINARY_NAME): $(JAVA_OBJECTS)
	$(GCJ) --main=paqueteA.paqueteAB.clasePrincipal $^ -o $(DEST_DIR)/$(BINARY_NAME)

## Habrá que crear los directorios donde se almacenarán los objetos una vez compilados
prepare:
        mkdir bin/paqueteA; mkdir bin/paqueteA/paqueteAA; mkdir bin/paqueteA/paqueteAB; mkdir bin/paqueteA/paqueteAB/paqueteAC;

En el ejemplo, antes escribir make, habría que generar la estructura de directorios para los objetos tal y como se describe en el ejemplo. Además podemos agregar nuevas opciones de instalación y limpieza para que la instalación de nuestro programa Java compilado con GCJ sea estándar del modo:

 $ make prepare
 $ make
 $ sudo make install

Para orientaros en lo que respecta a los símbolos utilizados para construir las expresiones regulares, podéis echar un vistazo al manual de GNU Make. Esto es para un caso pequeño en el que no se utilizan librerías externas. En caso de que se utilicen bastaría con añadir una nueva macro para almacenar sus fuentes; recordemos que en la Introducción a GNU GCJ ya se explicó que las colecciones de clases .class en .jar se pueden compilar. Luego se obtendría una macro para los objetos y se compilarían igual que en el ejemplo. Además habría que modificar el enlace.

Me gustaría indicar también que de esta manera obtendremos únicamente un ejecutable que contiene todo el programa. Es más adecuado compilar utilizando librerías dinámicas. El proceso se puede deducir a partir de este mismo ejemplo, aunque si tenéis algún tipo de problema o alguna duda, dejad un comentario. Espero que si os ha sido útil también lo hagáis. Proximamente dejaré más posts acerca de GNU GCJ, su rendimiento y otras características.

En esta entrada voy a ir completando lo comentado en la introducción a GCJ. Ya expliqué entonces como podemos compilar una clase sencilla, sin dependencias de otras, de manera que obtendremos un ejecutable de la misma manera que si utilizásemos otros lenguajes como C/C++.

La dependencia entre clases en Java se satisface a través del classpath, una variable de entorno (aunque hay otras formas de especificarlo) en la que se enumeran los directorios en los que se encuentran clases o paquetes utilizados. La comprobación se realiza, en el caso de Java, además de al compilar a bytecodes, en tiempo de ejecución de manera que si nos falta una clase, se nos lanzará una excepción del tipo classnotfound; con GCJ esto no es así.

En el caso de GCJ, la comprobación de las dependencias se hace únicamente durante la compilación de las clases mediante una implementación propia del classpath muy similar a la original del Java. Podemos indicarlo de varias maneras:

• -Idir : Es la opción es la recomendada por los desarrolladores de GCJ, ya que es la que va a permitir diferenciar el classpath para las aplicaciones construidas a partir de este compilador de las que se construyan a partir de otros que también lo implementan.
• –classpath=path: Mediante esta opción se establece el path del modo tradicional, separando los directorios por medio del símbolo ‘:’. Esta opción no sobrescribe el path por defecto para encontrar la librería de clases estándar que implementa GCJ.
• –bootclasspath=path: Sustituye al path generado por defecto en el que se encuentran las clases estándar que componen el API de Java para GCJ.
• CLASSPATH: Se trata de una variable de entorno a definir antes de la llamada al compilador y que mantiene una lista de directorios de la manera estándar.

Existe una prioridad entre cada una de estas posibles implementaciones.  De esta manera, es posible tener una implementación de una determinada clase agregada a la variable de entorno classpath, sin embargo, podremos compilar una aplicación que la utilice especificando una nueva implementación mediante el argumento -I. El orden de prioridades es el siguiente:

1. En primer lugar irán los directorios especificados por medio del argumento -I.
2. Se añaden los directorios especificados con la opción --classpath en caso de que haya sido definida.
3. A continuación irán los directorios especificados en la variable de entorno CLASSPATH.
4. Se añaden los directorios que están en la ubicación desde la que se llama a GCJ, es decir, el directorio ‘.’
5. Si se ha especificado un valor para la opción --bootclasspath se anexa su valor, en caso contrario se agrega la ubicación por defecto de libgcj.jar.
6. Si se especificó durante la compilación e instalación de GCJ, la opción --extdirs, se agregan al classpath los directorios que allí aparezcan.

Las clases que vayan definidas en los directorios incluidos en el classpath podrán ser código fuente o clases compiladas a bytecodes de Java. Vamos a ver un ejemplo sencillo de dos clases dependientes. En primer lugar, tenemos una clase Suma.java con un método que se encarga de sumar dos enteros pasados como parámetros:

// Suma.jav -> contiene un método para sumar dos enteros y devuelve el resultado
package ejemplo.blog;

public class Suma {
    public static int sumar (int a, int b) {
        int c = a+b;
        return c;
    }
}

A continuación tenemos otra clase que recibe dos cadenas como argumentos para hacerles un cast a enteros y sumarlos llamando al método de la clase Suma anterior.

// MiClase.java -> Suma dos números pasados como argumento
import ejemplo.blog.*;

class MiClase {
    public static void main(String args[]) {
        // Los dos números pasados como argumento los convertimos a enteros
        int a = Integer.parseInt(args[0]);
        int b = Integer.parseInt(args[1]);

        // Sumamos los dos números con la llamada al método Sumar.suma()
        int x = Suma.sumar(a, b);

        // Mostramos el resultado por pantalla
        System.out.println(x);
    }
}

La primera clase está ubicada en /home/elmo/miclase y la segunda se encuentra en /home/elmo/ejemplo/blog. Para el caso de la compilación tradicional en Java hemos de indicar la ubicación de las clases dependientes a través de la variable de entorno $CLASSPATH de modo que haremos:

$ cd /home/elmo/ejemplo/blog
$ javac Suma.java
$ cd /home/elmo/miclase
$ export CLASSPATH="/home/elmo/"
$ javac MiClase.java

Llegados a este punto, tenemos las clases compiladas a bytecodes. Hay que notar que, dado que en MiClase.java estamos importando las clases del paquete ejemplo.blog, la ruta indicada en el classpath será la que corresponde a la ubicación del paquete y no de la clase, es decir /home/elmo. Para ejecutar en Java tendríamos que indicar también en la variable de entorno dónde están todas las clases que vamos a utilizar por lo que haríamos:

$ export CLASSPATH=$CLASSPATH":/home/elmo/miclase"
$ java MiClase 5 7
12

Una vez visto cómo se hace en Java, vamos a ver como podemos compilar este ejemplo con GCJ. Vamos a indicar el classpath con el argumento -I que es la opción que recomiendan los desarrolladores. Por supuesto, la utilización en forma de paquetes es exactamente la misma por lo que las rutas de indicarán de la misma manera que tradicionalmente en Java.

$ export CLASSPATH=""
$ cd /home/elmo/ejemplo/blog
$ gcj -c Suma.java -o Suma.o
$ cd /home/elmo/miclase
$ gcj -c -I/home/elmo MiClase.java -o MiClase.o
$ cd /home/elmo
$ gcj --main=MiClase /home/elmo/miclase/MiClase.o /home/elmo/ejemplo/blog/Suma.o -o MiClase.out
$ ./MiClase 5 7
12

La primera línea la ejecutamos para borrar el classpath actual, luego compilamos a objeto el código fuente de la cada una de las clases. En el caso de MiClase.java indicamos la ruta del paquete que utiliza, ejemplo.blog, mediante el argumento -I/home/elmo. Por último hacemos el enlace indicando cual de las clases es la que contiene el método main de nuestro programa, en este caso MiClase. Es importante decir también que si hubiéramos hecho que MiClase.java fuera parte del paquete miclase, al indicar el main se haría por medio de --main=miclase.MiClase. En el caso de java tradicional la ejecución habría sido con java miclase.MiClase 5 7 y en el CLASSPATH en lugar de poner /home/elmo/miclase habría bastado con /home/elmo.

Espero que todo esto haya sido útil a quién lo lea y que si surge alguna duda o alguna corrección, dejéis un comentario.

Si algo he aprendido en el desarrollo de mi proyecto de fin de carrera es a utilizar GNU GCJ, cuáles son sus características, qué puede aportar a Java y cómo se utiliza. Cuando empecé a investigar busqué tutoriales sobre cómo compilar con este software y me encontré con apenas un par de ellos medianamente decentes pero insuficientes para mi propósito, que era compilar una librería de clases bastante grande.

Casi todo lo que he aprendido lo he hecho mirando tutoriales en inglés, leyendo la documentación y puede que aparentemente no sea gran cosa pero no fue sencillo. En esta entrada quiero dejar una introducción al uso básico de GCJ y en un futuro ir completando el manual con algunos posts más.

1 – ¿Por qué GCJ?

En primer lugar debemos preguntarnos qué es GNU GCJ. Este software se desarrolló como alternativa al compilador de Java desarrollado por Sun Microsystems. La idea principal era la de no caer en la trampa de Java promulgada por Richard Stallman en muchos de sus discursos que consiste en que el API de Java fue liberado pero no podemos utilizar Java libremente porque el Java Runtime Enviroment (JRE) no posee las tres libertades básicas.

La problemática de Java es que, según numerosos estudios, es un lenguaje más lento que otros como C/C++ lo que se atribuye principalmente al uso de una máquina virtual para ejecutar código. En Java no compilamos a código nativo sino que compilamos a lo que se conoce como bytecodes, la unidad interpretada por la máquina virtual. Ésta, además de intervenir como inconveniente en el rendimiento, otorga la principal ventaja del lenguaje e idea principal de su desarrollo, la portabilidad.

Con GCJ rompemos, en cierto modo, la idea con la que se concibió el lenguaje ya que cuando compilamos lo hacemos a código objeto nativo en lugar de a bytecodes lo que permite una ejecución directa de las aplicaciones. Aún así, disponemos también de una herramienta libre conocida como GIJ (GNU Interpreter for Java) que es otra implementación de la máquina virtual aunque su rendimiento es verdaderamente malo.

Además de estas características, GCJ incorpora una interfaz conocida como CNI (Compiled Native Interface) que permite mezclar código escrito en C/C++ con código Java mediante pequeñas modificaciones en la sintaxis del lenguaje de modo que, si lo utilizamos para implementar partes críticas de código, conseguiremos programas mucho más rápidos.

En resumen, con GCJ podemos construir aplicaciones Java nativas que, por tanto, no van a necesitar un software adicional para su ejecución. Además, el aspecto más importante es que nuestras aplicaciones serán completamente libres ya que el software ha sido desarrollado bajo licencia GNU GPL.

2 – Un ejemplo sencillo

GCJ viene incorporado en la familia de compiladores GCC que se puede obtener de la página web oficial. Dado que es un software imprescindible en UNIX, está disponible en los repositorios de cualquier distribución de GNU/Linux. El funcionamiento es similar al resto de compiladores, debemos dar un fichero de entrada y se nos proporcionará uno de salida. El software posee su propia implementación del API de Java incluida en una librería llamada libgcj que se instala junto con el compilador.

Como ficheros de entrada se permite código fuente .java, clases compiladas a bytecodes .class y colecciones de clases .jar o .zip.

La salida puede ser bien código objeto sin enlazar o un ejecutable ya enlazado. Como primer ejemplo vamos a compilar el clásico hola mundo de Java. Por el momento, el fichero se ubicará en nuestro HOME; la compilación y ejecución también se hará desde nuestro HOME. El código es el siguiente:

// Fichero HolaMundo.java
public class HolaMundo {
        public static void main(String[] args) {
           System.out.println("¡Hola, mundo!");
        }
 }

Como podemos ver, es el código más simple del mundo, no se utiliza ninguna clase externa, solamente el método System.out.println que es un estándar del API de Java implementado en libgcj. Para compilar y ejecutar la clase tradicionalmente en Java haríamos lo siguiente (previa instalación del JDK de Sun):

 $ javac HolaMundo.java
 $ java HolaMundo
¡Hola, mundo!

Cada clase que componga una librería Java puede implementar un método main propio. Cuando ejecutamos código con la máquina virtual siempre lo hacemos de una clase en concreto pero cuando lo que tenemos es un ejecutable tiene que haber un método main forzosamente y siempre el mismo. Por este motivo es necesario indicar a GCJ qué clase es la que contiene el método principal durante el enlace. Así, la compilación, enlace y ejecución respectivamente sería:

 $ gcj -c HolaMundo.java
 $ gcj --main=HolaMundo HolaMundo.o -c Hola
 $ ./Hola
¡Hola, mundo!

Hasta ahora hemos aprendido cómo se compila una clase simple. Esto es lo más sencillo y se puede encontrar sin mucha dificultad en Internet. El problema surge cuando lo que tenemos es una colección de clases con dependencias cruzadas, cuando esta colección está estructurada en paquetes, cuando queremos automatizar la compilación porque son muchas clases las que queremos compilar, etc.

3 – Próximos posts

Más adelante explicaré cómo es la implementación del CLASSPATH, qué opciones de compilación tenemos disponibles, qué características se comparten con el compilador de C, cómo podemos automatizar la compilación por medio de un Makefile, cómo funcionan las dependencias, etc.

Continuación: El classpath de GCJ.

Espero comentarios si os interesa el tema, un saludo.

Hace cuestión de una semana decidí aventurarme más en el mundo de GNU/Linux y probar la que dicen que es la distribución más difícil de instalar dado que todo está construido a gusto del consumidor: Gentoo Linux. El mayor atractivo está en que todo lo que instalamos en el sistema se compila especificando una serie de parámetros llamados USE, utilizados por Portage (el gestor de paquetes) ,que nosotros definimos según nuestras necesidades. Por medio de ese sistema, podemos indicar a las aplicaciones que vamos a compilar e instalar qué componentes son los que queremos y cuáles no.

Además de poder personalizar la instalación de aplicaciones, el núcleo también se configura e instala a nuestro gusto y es en todo esto en lo que está la dificultad. Además instalaremos inicialmente un sistema base, es decir, sin X, gestor de escritorio ni utilidades de modo que sólo tendremos instalado lo que nos sea necesario. Todo esto resulta muy interesante pero como todo en esta vida, tiene inconvenientes.

La mayor pega que le pongo a Gentoo Linux, y por la que no voy a tenerla de momento en el portátil, es que al tener que compilarse todo, si no disponemos de un procesador potente, el proceso de instalación de las aplicaciones más pesadas es extraordinariamente largo. Sin ir más lejos, esta mañana he instalado el visor de documentos kpdf con las QT4 y sólo las librerías han estado aproximadamente dos horas compilando. No quiero imaginar lo que tardarán las aplicaciones más pesadas como Open Office o Amarok … la pregunta es si vale la pena recompilar cuando actualicemos o incluso si algo nos falla y hay que cambiar parámetros.

Otro inconveniente que ha aparecido ahora para los nuevos usuarios, como lo sería yo, es que el wiki de documentación de Gentoo se ha perdido. Al parecer hubo una serie de problemas en el servidor y ahora están pidiendo las backups pero no hay respuesta. Esto no es seguro, me lo ha comentado un compañero. Si ahora me surge algún problema que no esté resuelto en la documentación oficial tocará recorrer la Web buscando soluciones.

Aparte de esto, lo he tenido instalado un par de días con Enligthenment y va espectacularmente rápido pero la comodidad es importante también, y el día que tenga un procesador de última generación con cuatro núcleos para compilar Open Office en 40 minutos, me pondré de nuevo Gentoo; mientras tanto… Ubuntu.

Con la propagación de usuarios que ha tenido Ubuntu, sobre todo en este 2008, ha surgido muchísima gente que defiende a capa y espada a esta distribución, o GNU/Linux en general, pretendiendo imponerlo de la forma más absoluta a todos sus familiares, amigos y conocidos. En muchos casos, estos usuarios son gente que trabajaba habitualmente con Windows XP hasta hace no mucho y que, al ver en Youtube muchos vídeos de los efectos que se puede dar al escritorio con Compiz Fusion, les picó la curiosidad y decidieron aventurarse a probar un nuevo sistema operativo.

Personalmente veo como la mayor ventaja de utilizar sistemas operativos tales como Ubuntu la libertad de poder descargar la imagen del CD desde Internet, instalarlo en mi PC y posteriormente descargar multitud de programas en la mayoría de los casos de una calidad muy aceptable sin tener que preocuparme de buscar licencias o cracks.

Mi opinión personal sobre Windows XP, basándome en mi experiencia con el SP2, es que no es un mal sistema operativo. Tiene el gran inconveniente de que la mayoría de los programadores utilizan GNU/Linux y muchos se dedican a desarrollar software malicioso que atenta contra los agujeros del sistema operativo de Microsoft. En consecuencia, los usuarios poco experimentados que se pongan a investigar de dónde bajar un disco que se pone a al venta dentro de un mes, pueden acabar perjudicados por malware. Otro problema viene de que es un software privativo y no podemos examinar el código (nosotros o los demás). Por eso, cuenta la leyenda que en muchas ocasiones se realiza una recolección de información sobre los archivos personales, cuentas de usuario, etc, que se envían a Microsoft sin que el usuario se entere de nada. Esta posibilidad existe y no es muy ética, pero tampoco es ético instalar Windows sin adquirir una licencia.

Una alternativa es utilizar Mac OS. Mi experiencia con éste se reduce a que mi novia, de la que estoy muy enamorado, tiene un iMac por lo que he utilizado este SO, lo he trasteado y la verdad es que lo prefiero antes que Windows XP. Raramente nos vamos a encontrar con software malicioso aunque sigue teniendo la gran desventaja de que es software privativo lo que quiere decir que es posible que, al no conocer el código, el sistema operativo emprenda acciones que no son conocidas por el usuario y que no tienen un fin.. digamos beneficioso. Otro aspecto negativo es que si lo queremos por lo legal y que vaya bien, lo idóneo es comprar un Mac, que no son excesivamente baratos en comparación con otros ordenadores. A pesar de esto, es un sistema operativo muy estable, fiable, intuitivo y bonito.

Finalmente tenemos los sistemas basados en GNU/Linux. He utilizado varias distribuciones como Mandrake, Debian, Ubuntu y Gentoo y mi opinión es que se trata de una opción excelente, pero sobre todo si estás familiarizado con la informática. Hay algunas distribuciones que son realmente sencillas de instalar en muchos casos como el de Ubuntu, sin embargo, hay otras que requieren un cierto aprendizaje como Gentoo. Una vez que tenemos todo instalado la cosa suele ir genial, pero muchas veces nos encontramos con problemas que hay que solucionar recurriendo a Google con la esperanza de que a alguien le haya ocurrido lo mismo. A mi no me importa cuando ocurre esto, es más, me gusta porque aprendo cosas nuevas, pero no todo el mundo es igual. Lo más importante es la libertad, poder ver el código de prácticamente cualquier programa y que la mayoría de las aplicaciones son de calidad.

En mi PC de sobremesa utilizo Ubuntu porque la considero una distribución estable, de gran calidad y en continuo desarrollo. Esto no quiere decir que imponga a mis amigos su utilización. Puedo recomendar su uso pero nunca imponerlo ya que hay muchos usuarios que quieren el ordenador sólo para que funcione, leer el correo, ver el periódico en Internet, descargar todo tipo de cosas de las redes P2P; si están acostumbrados a Windows y no tienen ganas de aprender, lo mejor es que se queden como están. Cierto que esto comprometerá su libertad, pero si a ellos no les importa poner números de serie falsos en el software ni que Microsoft sepa qué disco se bajaron ayer, a mi tampoco.

Creo que casi todos los que estamos en GNU/Linux hemos utilizado alguna vez Windows y la expresión “si para lo que quiero yo el ordenador me sobra con Windows…” es perfectamente válida. Por supuesto, antes que Windows preferiría utilizar Mac… pero ni tengo un MacBook Pro, ni tengo un iMac, así que el día que decida comprar uno posiblemente me quede con su sistema operativo… aunque sin dar la espalda a GNU/Linux.