Para sobreescribir las propiedades por defecto del API, será necesario establecer un recurso con nombre “/config/sign.properties” anterior al API (xxxxxx.jar) en el classpath de la aplicación.

Leyendo y releyendo, no doy crédito a lo que dice: ¿Tengo que poner en el classpath un archivo antes que otro para que la aplicación funcione? WTF?

No se me ocurre ninguna razón para tomar este criterio de diseño, aparte de un malísimo entendimiento de cómo funcionan los JARs. Así que, con vuestro permiso, voy a intentar explicarlo, a ver si ayuda a alguien.

NOTA: Algunas explicaciones usan fuentes con colores para que se entiendan mejor. Si lees esto a través del Planeta Gul o del feed no los verás.

Máquina Virtual

Todos los programadores Java saben que las aplicaciones Java se ejecutan en una máquina virtual, la JVM, pero parece que nadie hace caso realmente a este hecho. Cuando programas en Java, tienes que olvidar cosas como tu sistema de archivos local o tu ruta actual de trabajo. Estoy harto de encontrarme cosas como:

File f = new File("recursos/blablabla.conf");

Cuando cojas tu aplicación y la metas en un servidor de aplicaciones, por ejemplo, directamente no va a funcionar. Así que el primer paso es no olvidar lo que significan las siglas VM en JVM. Los programadores que hacen este tipo de barbaridades siempre añaden algún tipo de documentación que dice algo así como “asegúrate de ejecutar java en el directorio tal”. Si te encuentras con algún programador así, dile de mi parte que es idiota.

Sistema de archivos virtual

Es cierto que la JVM puede acceder al sistema de archivos local (dependiendo de los permisos que le otorgues, no lo olvides). Pero, y he aquí lo más importante de todo, la JVM tiene un sistema de archivos virtual. No sé si este nombre se usa oficialmente en la documentación de la JVM, pero creo que es un buen nombre. Este VFS no es otra cosa que un árbol de directorios y archivos que contiene todo lo necesario para que funcione tu aplicación.

Cuando ejecutas una aplicación Java, la JVM toma todo lo necesario de tu disco duro (clases, recursos, etc) y los mete en un sistema de archivos virtual, un árbol de archivos. He aquí otra clave para entender el funcionamiento de Java: las clases no se cargan desde el disco duro, sino desde el sistema de archivos virtual.

En este sistema de archivos virtual, los directorios reciben el nombre de paquetes. Habrás leído que los paquetes siguen una jerarquía. Ahora que sabes que un paquete no es más que un directorio, eso de la jerarquía de paquetes te parecerá lo más tonto del mundo.

Por último, en el árbol del VFS, el nodo raíz se llama paquete por defecto, que es otro nombre chulo para algo tan tonto como /

Clases y paquetes

Cuando creas una clase Java, debes especificar el paquete al que pertenece.

package es.voiser.personas;
class Persona {  /* vale por un main() */  }

Guarda el archivo donde quieras. Yo te recomendaría algo así como:

src/es/voiser/personas/Persona.java

pero (por ahora) eres libre de guardalo donde quieras. Ahora lo compilamos, y queremos que los .class resultantes los guarde en el directorio:

classes/

Para ello:

javac -d classes donde/esté/el/archivo/Persona.java

El .class resultante se guarda automáticamente en:

classes/es/voiser/personas/Persona.class

La información de dónde dejar el .class la obtiene de la instrucción package y del parámetro -d. Por tanto, el directorio de clases tiene este aspecto:

Habrás adivinado que el amarillo representa un .class y el resto directorios. Y que el cilindrito del fondo representa tu disco duro

En definitiva, cuando creas una clase, la metes en un paquete. Cuando compilas tus clases con un parámetro -d, java escupe los .class creando una jerarquía de directorios y archivos que refleja la jerarquía de paquetes y las clases que contienen.

CLASSPATH

Seguro que has escuchado a alguien decir que el CLASSPATH es la ruta donde Java busca las clases. Probablemente esta definición viene de buscar un paralelismo con el PATH típico de un sistema operativo. En realidad, el CLASSPATH lo que hace es (atención) indicar a la JVM qué archivos y directorios forman el sistema de archivos virtual de la JVM.

Vamos a ejecutar la aplicación. Para ello se hace:

$ java -cp classes es.voiser.personas.Persona

¿Qué hace este comando?

1- Se instancia la JVM:

$ java -cp classes es.voiser.personas.Persona

2- Se toma el contenido del CLASSPATH y se mete en la burbujita:

$ java -cp classes es.voiser.personas.Persona

3- Y ya, por fin, ejecutamos la clase es.voiser.personas.Persona. Fíjate que esta clase ya está en el VFS de la JVM.

$ java -cp classes es.voiser.personas.Persona

Varios CLASSPATH

Cuando una aplicación es muy grande, suele dividirse en componentes o bibliotecas (los puristas dirán que no es lo mismo, no quiero entrar en eso). De esta manera evitamos tener un monstruo de miles de archivos y directorios. Supongamos que nuestra aplicación que versa sobre personas necesita, por la razón que sea, una biblioteca que modele colores (por ejemplo para poder decir el color del pelo de una persona).

Creamos una biblioteca de colores, totalmente aparte del proyecto anterior. Crearemos las clases en el paquete es.voiser.colores, con dos clases: Rojo y Verde:

// Rojo.java
package es.voiser.colores;
Class Rojo { ... }

// Verde.java
package es.voiser.colores;
class Verde { ... }

Guardamos este código donde sea, y compilamos. Quiero generar los .class en el directorio:

classes_colores/

así que haré:

$ javac -d classes_colores donde/este/Rojo.java

Ahora, el disco duro tendrá este aspecto:

Ahora ejecutamos la aplicación:

$ java -cp /donde/esté/classes:/donde/esté/classes_colores es.voiser.personas.Persona

Veamos de nuevo qué hace esto:

1- Se instancia la JVM:

$ java -cp /donde/esté/classes:/donde/esté/classes_colores es.voiser.personas.Persona

2- Se copia el contenido del CLASSPATH al sistema de archivos virtual.

$ java -cp /donde/esté/classes:/donde/esté/classes_colores es.voiser.personas.Persona

3- Por fin, se ejecuta la clase es.voiser.personas.Persona:

$ java -cp /donde/esté/classes:/donde/esté/classes_colores es.voiser.personas.Persona

La moraleja de esta parte es que la JVM trabaja sobre un sistema de archivos virtual que contiene el agregado de todos los directorios especificados en el CLASSPATH.

Como curiosidad, que no debería ser más que un dato anecdótico pero que veremos que no lo es: imagina que existieran estos dos archivos:

classes/es/voiser/app.config

classes_colores/es/voiser/app.config

A la hora de copiarlos al interior de la JVM, ambos archivos se guardarían con el mismo nombre,

/es/voiser/app.config 

Lo que la JVM hace es quedarse con el primero que se especifique en el CLASSPATH, en este caso

 classes/es/voiser/app.config

¿Qué es un JAR?

Un JAR es un árbol de directorios comprimido en ZIP. Sirve para coger una biblioteca de clases, comprimirla en un ZIP y distribuirla como un único archivo. Supongamos que queremos distribuir nuestra biblioteca de colores Rojo y Verde. Haremos esto:

$ jar -C classes_colores cvf colores.jar .

Este comando lo que hace es meter en el archivo colores.jar el contenido del directorio classes_colores.

Lo bonito de un JAR es que puede incluirse en un CLASSPATH. Siguiendo con el ejemplo, ahora tenemos esta situación: un directorio classes donde están las clases de la aplicación de personas, y un JAR que contiene la biblioteca de colores:

Ahora ejecutamos la aplicación de la siguiente manera:

$ java -cp classes:colores.jar es.voiser.personas.Persona

Lo que hará la JVM es crear un sistema de archivos con el contenido de classes y el contenido de colores.jar. O sea, esto:

Que es idéntico a lo que vimos en el caso anterior.

Entonces… ¿Importa el orden del CLASSPATH?

La respuesta es: no debería importar. Cuando una aplicación necesita muchas bibliotecas, se carga el contenido de los JAR en el sistema de archivos virtual de la JVM y punto. Si dos archivos colisionan se toma el primero que llegó, pero este hecho no debería tomarse como criterio para diseñar tu aplicación. Más que nada porque si usas un IDE, cosa muy recomendable al trabajar con Java, es el propio IDE el que escribe el CLASSPATH así que te será complicadillo especificar el orden de los JARs.

¿De qué me vale este sistema de archivos virtual?

Una aplicación no es solo código, sino que también contiene otros recursos como por ejemplo los iconos o los archivos de internacionalización. Si haces un JAR de tu aplicación, estos archivos viajan con tu aplicación, lo cual es estupendo. Una aplicación autocontenida.

Para acceder a estos recursos se puede usar una función Class.getResourceAsStream(String path), que recibe la ruta al archivo en el sistema de archivos virtual y devuelve un ImputStream. Se podría usar, por ejemplo, algo así como

InputStream config = this.class.getResourceAsStream("/es/voiser/app.config");

¿Qué han hecho los de la aplicación que comentabas al principio?

El requisito es el siguiente: la aplicación debe leer un archivo de configuración. Si no se especifica ninguno, se toma una configuración por defecto.

Qué han hecho estos chavales:

1- Nuestra biblioteca lee siempre el archivo “/config/sign.properties”

2- Creamos un archivo “/config/sign.properties” con la configuración por defecto

3- Para sobreescribir esta configuración, meter en el CLASSPATH lo primero de todo un JAR que contenga un /config/sign.properties. Así prevalecerá sobre la configuración por defecto.

Evidentemente este diseño es una basura. Primero, si quieres configurar la aplicación tienes que crearte el archivo, comprimirlo y meterlo en el CLASSPATH en primer orden. Si usas un IDE, probablemente te cueste (o te sea imposible) cambiar el orden del CLASSPATH así que tendrás que hacerlo a manubrio. Si metes la biblioteca en un Tomcat o similar tendrás que lidiar con los Manifest del WAR. Vamos, lo mires por donde lo mires, es una mala idea.

¿Cómo se puede hacer?

De varias maneras, pero una más o menos fácil y general sería:

1- La configuración se carga cuando alguien invoca un método determinado. Nunca automáticamente.

2- La configuración por defecto se guarda en un recurso en el JAR de la biblioteca.

3- La configuración se lee a través de un InputStream que apunta inicialmente al recurso con la configuración por defecto.

4- Un método permite que el InputStream apunte a un archivo del sistema de archivos real.

Y con esto y un bizcocho, te has quitado el problema de encima sin hacks estúpidos, sin tocar las narices al usuario final, y haciendo las cosas bien.

Atendiendo a su posición respecto al software libre, las personas o empresas pueden catalogarse según dos variables: su posición oficial respecto al software libre y su posición real. La posición oficial se refiere a si apoya o no al software libre, y la real es si es sincero o no en su posición oficial. Dicho de otro modo: qué digo a los demás y qué hago en realidad.

Estas variables dividen el plano en cuatro cuadrantes:

• El primer cuadrante: no apoyo el soft libre pero me aprovecho de él. Aquí se encuentra el grueso de la Sociedad: la mayoría de las empresas de TI, Microsoft, las consultoras, etc.
• El segundo cuadrante: no apoyo el software libre y no lo uso. No sé si hay alguna empresa que use software 100% privativo, teniendo en cuenta que tanto Microsoft como Apple usan pedacitos de software libre en sus sistemas operativos. Algunos sistemas empotrados son 100% privativos, pero el software se usa para el desarrollo del negocio no. Dejémoslo en un interrogante, pero yo diría que este cuadrante está vacío.
• El tercer cuadrante: apoyo el software libre y lo uso y promuevo. La Fundación Apache, Mozilla, el GUL, etc. Tienen políticas que están acorde con la comunidad del software y el conocimiento libre y son coherentes con ellos.
• El cuarto cuadrante: voy de guay-moderno pero a mi que me lo den todo hecho, también llamados “pozo sin fondo”. De cara a los demás defienden el software libre, lo usan constantemente y hacen alarde de ello, pero están dispuestos a incumplir licencias, obviar el trabajo de los demás, no citar fuentes, no respetar identidades ni derechos. Si les llamas la atención suelen excusarse con accidentes, casualidades, no lo sabía, fíjate qué penita, vaya lío.

Todo este rollo es solo para pedir a los chicos de Pánico en el Núcleo que no se enfaden ni desesperen por las acciones de Cuartos Cuadrantes ni similares: independientemente de si queréis o no cambiar el nombre, no perdáis de vista el verdadero objetivo del podcast, que es dar un buen contenido, elaborado e interesante.

En otras palabras: ¿Para cuándo el próximo capítulo de Pánico en el Núcleo?

- un segurata

Para hacerse una idea de lo que es el espectáculo de Muse (pillada de aquí):

Hubo dos teloneros. Los primeros, The Big Pink, flojillos, al menos en directo. Vale que tampoco es gracioso que hagas canciones de cinco minutos con una única nota de bajo, guitarra y voz. A ver, es bueno si quieres hacer archivos MIDI pequeñitos, pero como música deja algo que desear. Al acabar alguien soltó un “bueno, vale, como broma está bien”.

Los segundos, The Editors, muy muy muy buenos. A medio camino entre Depeche Mode y Coldplay, habrá que informarse.

Después de tres horitas de espera, aparecieron ellos. Una entrada espectacular, con un desfile de tíos con bengalas y pancartas en las que podían leerse frases de la letra de Uprising. El escenario se convirtió en la nave espacial de Encuentros en la tercera fase y nos quedamos alucinados con las pantallas del escenario.

Espero que a mi Ali, que era su primer concierto serio (¡lo de la gala de los 40 no cuenta como concierto, preciosa! ) y que se dedicó a empapar a un vigilante de agua y a caminar como si fuera un compás con botellas escondidas en los calcetines se lo pasara tan bien como yo. Ahora a dormir, que 3 horas de sueño no son suficientes

No es para nada un libro técnico, apenas toca temas complicados y si en algún momento cuenta algo que se le pueda escapar al lector, rápidamente hace algún tipo de comparativa para que quede claro. Me hizo mucha gracia una que decía que esperar que la vida surgiera espontáneamente de un mar de proteínas es como esperar que un tornado pase por un desguace lleno de piezas sueltas y que al marcharse dejara atrás un avión perfectamente montado. O cuando cuenta que ha habido buceadores que, sometidos a enormes presiones, empezaron a experimentar una borrachera que los animaba a ofrecer las boquilas de oxígeno a los peces que pasaban.

Lo que me ha decepcionado un poco de este libro es que al principio es muy prometedor pero a mitad del libro empieza a flojear y llega a convertirse en un almanaque de cifras y comparaciones. Incluso en algún momento parece unos apuntes de alguna asignatura, con listas de conceptos y millones de cifras. Y para rematar la faena, el final te deja con un poquito de mal sabor de boca. En otras palabras, parece que el autor empezó con ganas pero no pudo mantenerse así hasta el final.

En cualquier caso, si tienes algo más de paciencia que yo y te interesan desde los átomos hasta las migraciones de los homínidos, probablemente te guste el libro.

Fdo: un usuario de mac con un iphone touch y al que le encanta el iPad.

El viernes pasado hicimos una entrevista en la radio ECO Leganés donde charlamos sobre las jornadas del GUL y el software libre en general. Tenéis la entrevista aquí. Nos lo pasamos fenomenal y nos ofrecieron la oportunidad de hacer un programa mensual nosotros solitos. Creo que la aprovecharemos.

Si tienes pensado acudir a la charla de calidad, repasa un poco cómo funciona el lenguaje C (básicamente qué diferencia hay entre un .c, un .h, un .o y un ejecutable). Si vas a ir a algún taller, no olvides llevarte un portátil con la última versión que tengas de Python y/o Ruby instalado.

Los que trabajamos no tenemos la posibilidad de ir todos los días a las 17:00, por lo que espero que algunos guleros que viven en la uni puedan acudir a esas charlas para ayudar con las llaves del aula, el cable VGA, etc. Este paso es el más importante de todos.

Y, por supuesto, entrada libre y gratuita. Más información:

www.gul.es

Si eres de los que leen las sinopsis de los libros, tampoco te fíes de la de Anatema. Aunque es cierto eso de los alienígenas, religión y política, el libro es en realidad una narración que sirve como excusa para comentar una teoría existencialista platónica “con amiguitos”: si recuerdas lo del mundo de las ideas que estudiaste en el instituto, medio libro te será familiar. El otro medio es mecánica cuántica del montón.

Hay dos cosas que me han sorprendido bastante de este libro. La primera es el cambio de estilo, mucho más serio, sin el gamberrismo que le caracteriza, se podría decir que es casi maduro. La segunda, la costumbre que ha adoptado de huir de las explicaciones. Acostumbrado, de cierta forma, a encontrarme capítulos enteros que explican con detalle el funcionamiento de un ataque tempest, veo que en Anatema algunas ideas clave en la novela -y algunas que ciertamente no lo son pero que resultan igual de inquietantes- se citan, se dejan caer, se comentan en un mísero parrafillo, cuando merecen varias páginas de atención. De hecho, en una entrevista, Stephenson admitió que cierta idea que no se explica en el libro es fundamental para entender la novela.

Esta clave es la siguiente: para pasar de un argumento A a otro argumento B se debe coger información de B y plasmarla de forma física en A. Para mantener la inviolabilidad de las leyes físicas, el argumento A necesita cambiar de dirección y converger a un punto donde la información que se extrajo de B sea efectiva. Creo que es una teoría suficientemente interesante como para desarrollarla, y a medida que pasan las últimas páginas del libro te angustias pensando que no llega el momento en que se explique esta clave. Efectivamente, no llega. Como tampoco llega la explicación de cómo son capaces de separar la información real del Retículum de la información errónea que se sintetiza sistemáticamente.

Esto no significa que la novela decepcione. A mi, al menos, no lo ha hecho, he disfrutado con ella. Me ha gustado mucho la forma en la que describe el planeta donde se desarrolla la acción: en primera persona y a través de la vida diaria del protagonista. Es una dosis de realismo que se agradece en una obra de ficción especulativa, en contra de la ciencia ficción tradicional donde naves espaciales disparan haces de láser de escasos metros de longitud a velocidades newtonianas y todas esas cosas. Stephen King dice que la clave para escribir una novela de ficción es ser creíble. Puedes escribir sobre fantasmas o sobre extraterrestres, pero la novela tiene que ser creíble. Creo que esto es una máxima en Anatema: llega a ser agradable encontrarse con una novela donde la gente no se reúne para tomar una decisión en diez segundos y acto seguido ya se encuentran en naves espaciales peleando contra la Estrella de la Muerte, ni donde de repente los protagonistas necesitan viajar a Londres y sorprendentemente aparece un amigo que tiene un avión privado. Aquí las decisiones se discuten, los políticos se pelean, los científicos realizan observaciones y hacen experimentos para obtener modelos, y los astronautas se entrenan para calcular el azimut y el tiempo de propulsión para desplazarse por el espacio en sus trajes espaciales, y donde si fallan tienen que esperar unas cuantas horas para situarse de nuevo en una posición de la órbita donde puedan ser rescatados. Eso es una historia y lo otro son historietas.

Una vez hice un curso en Colmenarejo sobre sistemas embarcados en la industria aeroespacial. Uno de los ponentes trabajaba en la ESA y nos comentaba con mucha gracia que en las películas, cuando el espía malo entraba en la embajada de turno, los buenos apretaban un botón y el satélite en apenas unos segundos se colocaba encima de dicha embajada para hacer las mejores fotos de la Historia De Las Fotos Por Satélite. En el mundo real, el satélite está orbitando a su bola y las fotos se hacen cuando el satélite pase por allí. Y a veces hay nubes. Esa diferencia entre a lo que estamos acustumbrados y lo que es físicamente posible es lo que Anatema ofrece como novela de ficción.