Java 1.3 en Ubuntu Feisty

Esta semana he estado trabajando con unas aplicaciones antiguas que requieren Java 1.3 por la versión del Application Server que están utilizando. Java 1.3 es bastante antiguo y depende de algunas bibliotecas igual de antiguas, piensen en esos tiempos en que no se usaba UTF-8 por omisión en Linux.

Tal como esperaba, no lo pude ejecutar directamente en Ubuntu Feisty, trate de darle algunas pistas al sistema, como el clásico LD_ASSUME_KERNEL pero tampoco tuve éxito. Al final, el procedimiento era bastante sencillo, pero bien podría haber perdido mucho más tiempo en esto. Estoy seguro de que alguien más agradecerá este tip (Hi Aldrin!)

Se necesitan 4 sencillos pasos:

Paso 1: Descargar Java 1.3 desde el sitio de Sun

  • Ir a http://java.sun.com/products/archive/
  • Seleccionar J2SDK 1.3 o J2RE 1.3 segun se necesite. Yo me fui por J2SDK 1.3.1_20

Paso 2: Cambiar los permisos y ejecutar el archivo .BIN para aceptar la licencia y descomprimir el archivo. Recomiendo hacer esto en el directorio /opt

cd /opt
chmod 755 ELARCHIVO.BIN
./ELARCHIVO.BIN

En mi caso, esto generó el directorio /opt/jdk1.3.1_20

Paso 3: Instalar libstdc++ compatible con esta version de Java. Ojo que el numero de version podria cambiar, lo importante es que sea 2.x

apt-get install libstdc++2.10-glibc2.2

Paso 4: Crear un link simbólico para que el binario de java pueda encontrar la biblioteca libstdc++ que espera. Ojo que las versiones pueden cambiar

cd /usr/lib
sudo ln -s /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so libstdc++-libc6.1-1.so.2

Con eso ya podrán ejecutar java, pero seguramente tendrán problemas por el soporte multilenguaje, entonces antes de ejecutar java asegurense de ejecutar

export LANG=en_US

Resultado final:

fcatrin@shaman:~$ /opt/jdk_1.3.1_20/bin/java -version
java version "1.3.1_20"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_20-b03)
Java HotSpot(TM) Client VM (build 1.3.1_20-b03, mixed mode)

Pasos opcionales pero convenientes
Con esos pasos podrán ejecutar java directamente con /opt/jdk_1.3.1_20/bin/java, pero es muy engorroso. Personalmente uso un método que me simplifica el problema de rutas y versiones de java. Todas las versiones de java instaladas las hago vivir en /opt. En ese directorio creo un enlace simbólico apuntando al nombre real del java instalado. Tengo algo asi:

java13 -> jdk1.3.1_20
java14 -> j2sdk1.4.2_02
java -> java14

Para crear uno de esos enlaces aplico:

cd /opt
ln -s jdk1.3.1_20 java13

De esta forma, java13 siempre sera /opt/java13 independiente del java instalado, y el java por omisión siempre sera /opt/java, y si lo deseo lo puedo cambiar para que apunte a java14 o java 13 depende de qué java quiero tener por omisión. En mi .bashrc dice :

export JAVA_HOME=/opt/java
export PATH=$JAVA_HOME/bin:$PATH

Con eso tengo lo suficiente para que cualquier aplicación java que ejecute utilice el java por omisión (1.4 en este caso). Para el caso de java13 me cree un script /usr/local/bin/java13 que dice:

export JAVA_HOME=/opt/java13
export PATH=$JAVA_HOME/bin:$PATH
export LANG=en_US

Entonces cuando requiero java 1.3 simplemente ejecuto source java13 y listo. De esta forma:

fcatrin@shaman:~$ java -version
java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode)
fcatrin@shaman:~$ source java13
fcatrin@shaman:~$ java -version
java version "1.3.1_20"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_20-b03)
Java HotSpot(TM) Client VM (build 1.3.1_20-b03, mixed mode)

El polémico Acuerdo Marco entre Microsoft y el Gobierno de Chile

Hace un par de dias se produjo una gran revuelta cuando se dio a conocer el Acuerdo Marco de Colaboración Microsoft – Gobierno de Chile. Hubo mucho ruido, bombas lacrimógenas y barricadas virtuales, creo que muchos reaccionaron con la cabeza caliente, sobre todo en FayerWayer, uno de los blogs de tecnología mas influyentes, pero no siempre el más preciso.

No quise escribir nada sin tener más o menos claro de que se trataba todo este asunto, y confieso que aun no lo tengo completamente claro, pero al menos ya no siento el disgusto y decepción inicial.

Como bien dice JCI, un Acuerdo Marco no es un contrato, a pesar de que esta escrito como tal. Un Acuerdo Marco es una iniciativa en donde se declaran intenciones que pueden dar origen posteriormente a acciones reales, es decir, son sólo palabras y no hechos. No es la primera vez que Microsoft tiene acuerdos con el Gobierno, ni tampoco son los únicos, hace unos años atrás por ejemplo RedHat también hizo un acuerdo con el Gobierno. Creo que los aspectos que hacen la diferencia son el «amor» que tienen hacia Microsoft la gente que sabe de tecnología (o cree saberlo), y el momento en que este acuerdo se produce. Hemos visto como últimamente en varios países se ha tratado de impulsar la llamada «neutralidad tecnológica» a través de uso de estándares que permitan acceder a la información en forma independiente de implementaciones particulares (ver caso ODF vs OpenXML) y como Microsoft ha luchado por no perder su dominio, lo que se conoce como «vendor lock-in», es decir, amarrado a un proveedor, en este caso Microsoft. Es sabido que una de las estrategias de Microsoft para extenderse y prevalecer es que cada vez que pueden te hacen depender de su tecnología, o como dicen : «hacer que nos necesiten».

Pero si uno lee el acuerdo, no hay indicaciones acerca de definiciones de protocolos, estándares o formatos de documento a utilizar. Lo que se lee en el acuerdo es la intención de Microsoft de ayudar al gobierno a inyectar mas tecnología en el ámbito público y por otra parte la intención del Gobierno de aceptar esta ayuda de Microsoft, las deducciones maquiavélicas que se puedan hacer del texto son sólamente suposiciones de cosas en que nadie tiene certeza, muchas de ellas escritas detrás de las trincheras haciendo que la comunidad simpatizante el software libre nos veamos como extremistas (zealots). De todo lo que he leido, el articulo que me parece más decente es el de JCI : Stop being a fanboy! (o deja de ser un fan, en castellano), y se acerca bastante a mi opinión sobre el asunto, si es que se llega a concretar.

Pensemos un poco mas, se puede llevar a cabo algo similar a lo que aparece en el Acuerdo usando tecnologías no-Microsoft? Hay alguna empresa en Chile que pueda asumir el mismo desafió? Personalmente creo que no. En Chile recién se están estableciendo empresas que puedan satisfacer la demanda de servicios básicos de soporte de plataformas libres, se sabe también que falta mano de obra realmente capacitada en Linux y su ecosistema, muchos de ellos aun son estudiantes y llegará el momento en que se alcance la masa critica en el mercado laboral, pero sinceramente creo que aun no estamos ahí.

Juego de disfraces

Lo que si me tiene molesto aun, es como algunas organizaciones actúan como disfraces de «poderes ocultos». La semana pasada se publicó un Proyecto de Acuerdo de la cámara de diputados en donde se pide al Ejecutivo la «implementación del sistema de software libre». El texto es bastante inocente y se nota que no se conoce realmente del tema, ademas que se trata solo de un Proyecto de Acuerdo, a diferencia del Acuerdo de Microsoft que es un acuerdo ya firmado por el Ministerio de Economía.

Inmediatamente aparecieron notas de prensa en donde se ponia el grito en el cielo por este Proyecto de Acuerdo, que es insignificante al lado del Acuerdo de Microsoft, sin embargo cuando se publica el Acuerdo de Microsoft, se quedan calladitos y no dicen ni pio.

Es más. Uno que frecuentemente lee artículos extranjeros cuando se han realizado iniciativas pro-software libre y aparece Microsoft defendiendo su «vendor lock-in», reconoce inmediatamente en la redacción el torcido uso de términos como la Propiedad Intelectual y el fantasma de la destrucción de la economía tal y como la conocemos.

Vean ustedes mismos las semejanzas entre esta nota publicada en Venezuela, y esta nota publicada en Chile.