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 !

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.