Cual ha sido mi sorpresa cuando en una de las actualizaciones del sistema venía la nueva versión del JDK. Sin embargo esta release no se convierte en la release por defecto, sino que si deseas utilizarla, debes hacer los cambios por ti mismo.

Investigando un poco logramos la ruta física donde se instalan todas las versiones de los JDK de java descargados:

/System/Library/Frameworks/JavaVM.framework/Versions

Además de todas las versiones, existen tres directorios llamativos: A, Current y CurrentJDK; estos dos últimos directorios son symbolic links a la versión que interesa. Lo que significa que para cambiar de versión del JDK sólo hay que cambiarlos a ellos.

Si buscáis por internet encontraréis un script bastante utilizado, que nos muestra las JDKS que existen instaladas en vuestra máquina y cambia el CurrentJDK a la versión que queramos. Sin embargo, habría que completar este script. Ambos Current y CurrentJDK deben ser cambiados o algunos programas os dejarán de funcionar. La verdad es que por lo que he encontrado, lo único que he podido sacar en claro es que hay algunas razones por las que no cambiar CurrentJDK:

it affects the system globally, it changes the system from how Apple shipped it (things under /System are Apple managed), and it can cause updates to fail and/or have unintended side effects.

Si aún así queréis seguir adelante con el cambio podéis hacer lo siguiente.

Un vistazo rápido al directorio : /System/Library/Frameworks/JavaVM.framework/Versions/ os devolverá algo parecido a:

weemac:Versions jenaiz$ ls -la
total 56
drwxr-xr-x 14 root wheel 476 15 jul 08:59 .
drwxr-xr-x 11 root wheel 374 4 jul 08:08 ..
lrwxr-xr-x 1 root wheel 5 7 may 20:39 1.3 -> 1.3.1
drwxr-xr-x 3 root wheel 102 29 sep 2007 1.3.1
lrwxr-xr-x 1 root wheel 5 21 oct 2007 1.4 -> 1.4.2
lrwxr-xr-x 1 root wheel 3 7 may 20:39 1.4.1 -> 1.4
drwxr-xr-x 8 root wheel 272 21 oct 2007 1.4.2
lrwxr-xr-x 1 root wheel 5 21 oct 2007 1.5 -> 1.5.0
drwxr-xr-x 8 root wheel 272 21 oct 2007 1.5.0
lrwxr-xr-x 1 root wheel 5 7 may 20:39 1.6 -> 1.6.0
drwxr-xr-x 8 root wheel 272 7 may 20:39 1.6.0
drwxr-xr-x 8 root wheel 272 7 may 20:40 A
lrwxr-xr-x 1 root wheel 1 15 jul 08:57 Current -> A
lrwxr-xr-x 1 root wheel 3 15 jul 08:59 CurrentJDK -> 1.5

Como podéis ver, en estos momentos mi CurrentJDK está usando la 1.5 y mi Current apunta a A.

Para hacer que el JDK 1.6 sea el actual, tendréis que hacer:

ln -hfs 1.6 Current
y
ln -hfs 1.6 CurrentJDK

Así es tal como darrell lo explica, y es parecido a como el script lo hace. Todo esto hay que hacerlo como super usuario.

El porqué algunas aplicaciones dejan de funcionar hay que encontrarlo a que existen algunos problemas en esta versión, que Apple no ha considerado en solucionar aún:

- Sólo soporta 64 bits: adios a los applets en Safari.
- No hay soporte para Cocoa: aplicaciones como Cyberdurk dejarán de funcionar. Esto no sólo significa que no podamos tener look&feel de Mac OS sino que también perderemos algunas de las utilidades tales, como poder usar Growl como sistema de notificación, por ejemplo.

Si el tema de cómo está organizado el directorio de versiones de Java y el porqué de esta cosas, os interesa realmente, os dejo unos links interesantes sobre todo esto, no sólo aplicable al JDK:

Anatomy of Framework Bundles
Framework Versions
What are Frameworks?

Por mi parte pude asistir a todas las charlas que se dieron los dos días, pero no pude quedarme a los talleres, otra vez será. La verdad es que se habló de todo: Cherokee, Software Quality Assurance, JCR, Struts 2, Grails, RIA, Netbeans Rich Client Platform, Maven, JavaME, y un largo etcétera.

Me gustaría hablar de todas ellas, cada una a su modo me aportó algo interesante, las experiencias vertidas, los problemas con los que se habían topado. Sin embargo mi memoria y las que más se me quedaron grabadas, por determinados temas fueron dos charlas: Software Quality Assurance, impartida por Francisco Morero Peyrona y Desarrollo JavaME SIN necesidad de portabilidad, impartida por Curro Rueda.

Por su parte Peyrona logró hacerme recordar mi último proyecto, a cada cosa que Peyrona contaba, me acordaba de una situación distinta, de una fase. Como comentaba, la responsabilidad de que se pueda garantizar calidad en cada una de las partes, recae en cuánta calidad queremos dar a cada fase más que en sí realmente podemos dar dicha calidad. Una conclusión extraida allí mismo, hablando la voz de la experiencia:

Dime cuánto quieres gastar y te diré cuantas garantías de calidad tendrá tu software.

Por otro lado Curro me hizo recordar una época anterior, en la que trabajé con móviles, y pude realizar algunas cosillas, y digo bien, cosillas, porque oirle hablar de los problemas que se habían encontrado, oirle decir que el orden en la ejecución de determinadas funciones afectaba a que determinados terminales funcionen y otros no, el ver como resolvieron el problema de los tamaños de las fuentes, cómo ahorrar en cantidad de espacio en memoria, y un largo etcétera. Sin duda me hace recordar que yo hice cosillas, y ellos han realizado un trabajo impresionante para garantizar que con un sólo jar, puedas tener una aplicación corriendo en una gran cantidad de dispositivos, al margen del:

Java Write Once, Run Anywhere.

… y de la cruda realidad.

Una espinita que se me quedó clavada fue oir en la mesa redonda sobre frameworks web algunas cosas sobre Ruby on Rails, que ya han sido suficientemente desmitificadas y demostradas, o algunas otras que carecen de fundamento.

Por otro lado, destacar que como suele pasar en estos casos, hubo oportunidad de saludar a los amigos y de hacer nuevos conocidos, al igual que de cenar con algunos de ellos , un saludo a todos ellos y nos vemos en la próxima!

La plataforma está basada en la tecnología OSGi de forma interna, además de permitir su uso al usuario final. Comenta la participación de SpringSource en orientar más a OSGi al sector empresarial. También han estado trabajando de forma intensa en la nueva versión de Spring la 2.5.

El porqué su Application Platform, no implementa Java EE 5 según sus propias palabras:

[...]does not satisfy the needs of our customers[...]

También es cierto que nos habla de incompatibilidades entre OSGi y Java EE. Creen que el JSR-277 y OSGi podrían convivir de una mejor manera.

Con OSGi tendremos una mejor, más eficiente y rápida manera de desplegar/testear y de redesplegar nuestras aplicaciones. Pudiendo desplegar sólo las partes que hayan cambiado. Podremos empaquetar en grupos y versionar esos paquetes (bundles). Tendremos más modularidad y un sistema de versiones encargado de todo ello, manejado por el servidor. Dando al usuario un mayor control sobre la división de la aplicación. Podremos hacer uso de dos versiones distintas de una librería, especificando al servidor la versión que queremos utilizar. OSGi y la forma de trabajar con bundles, permitirá una forma más rápida de parchear posibles fallos en su servidor.

La licencia es GPLv3, por lo que la gente podrá crear plugins para la infraestructura, y liberarlos como open source.

La explicación a ser Platform y no server:

We didn’t want to call it a server because it will be able to be extended and accept different deployment modules, so it will be broader in scope than a typical server.

Algo que nos facilitará la vida de cara al desarrollo, es SpringSource Tool Suite. Podremos declarar módulos OSGi, pudiendo desplegar sólo las partes que han cambiado. Aunque esto estará disponible para sus clientes, proveeran alguna herramienta adicional para open source.

La conclusión del para qué y el porqué ahora, viene dada al final de la entrevista. Concluyendo:
- Es el momento correcto, el mercado y los analistas lo confirman.
- La idea de los servidores tradicionales es demasiado anticuada y OSGi plantea grandes beneficios junto con Spring.
- Y por los beneficios reales: inicios rápidos, da solución al versionado, manejo de librerías y dependencias y cree que:

the product is introduced in the right place at the right time.

Es cierto que la curva de aprendizaje de Java es elevada, que se necesita tirar muchas líneas de código para determinadas tareas, que el conocimiento de todas las librerías que existen es imposible, que para un proyecto de cierta embergadura en Java se necesita un equipo quizás más elevado que para otras tecnologías.

Algunas veces me encuentro con historias que no me dejan indiferente porque quizás no todos, pero sí te llegan al alma algunas curiosidades que cuentan. He visto en ocasiones que para realizar determinadas tareas necesitas escribir más líneas de la cuenta.

¿Es un problema de la tecnología? ¿Es un problema del modo en que hacemos los proyectos? ¿Está el problema en los equipos gestores? No sé que ocurrirá en otros países, pero no es la primera vez que oigo a alguien con suficiente experiencia y ganas por la tecnología decir que cada vez odia más desarrollar en general y con Java en particular.

¿Son los lenguajes de script la solución? Cuando pienso en estas generalizaciones que me encuentro por ahí, siempre me acuerdo de una charla en el primer Congreso de JavaHispano donde un colosal Ricardo Devis con una forma extravagante, no dudó es destrozar no una tecnología en concreto sino el mal uso que en demasiadas ocasiones hacemos de ella. No uses una tecnología para hacerlo todo, si no atente a las consecuencias.

JavaConGanas inicia su primer curso, de la mano de Alberto Molpeceres, yo por mi parte ya estoy apuntado.

Daos prisa, quedan pocas plazas: anuncio

He visto en la web de IBM que los sistemas operativos para los que que esta JVM es distribuida son:

- Linux® on x86
- Linux® on PowerPC® 32-bit
- Linux® on PowerPC® 64-bit
- Linux® on AMD64/EM64T
- IBM AIX® on PowerPC 32-bit
- IBM AIX® on PowerPC 64-bit

Al ver esto, se me plantea una duda con respecto a la elección de IBM de no soportar plataformas Windows. Siendo totalmente prácticos e irreflexivos, podríamos pensar que esta estrategia está totalmente equivocada, tengamos en cuenta que la mayor parte de usuarios cuentan con Windows como sistema operativo; y claro, esto podría llevarnos a fabricar la hipótesis, ¿algo errada!, de que su estrategia empresarial está totalmente equivocada, dado que de esta forma no van a conseguir que su JVM sea utilizada por el público en general, ni por los desarrolladores que tengan que trabajar en entornos Windows, que son unos pocos.

Quizás, la hipótesis pueda ser otra. IBM como gigante de la informática que es, cuenta con muchas vías de negocio dentro de la compañía y una que no debemos olvidar son sus máquinas. Dispone de una vía de negocio muy amplia con el negocio de servidores. No parece extraño pensar, por lo tanto, que si optimizas un JVM para los sistemas operativos que más se utilizan en tus máquinas, a la vez estás haciendo más atractivo el potencial que ofrecen tus servidores frente a los del mercado. En este punto no podemos olvidar que el principal representante de Java, Sun MicroSystems, también trabaja en ese mercado.

Por otro lado, me asalta la curiosidad. Si planteo un caso hipotético, un caso en el que el usuario de partida trabaja sobre windows, y realiza todo su desarrollo en dicha plataforma, necesita utilizar un JDK para ella, pongamos por caso que utiliza el de Sun, tras meses de desarrollo, su aplicación a sido preparada para un JDK, y ha sido más que probada, hasta la saciedad si se ha contemplado bien el tiempo de pruebas dentro del proyecto. Cabe hacerse la pregunta de si verdaderamente dicho software debe terminar o no ejecutándose en una JVM para la que apenás ha sido probada. Podrían presentarse, ¿incompatibilidades? Entiendo que no deberían de ser con respecto al lenguaje, pero cuando uno hace las cosas de diferente manera (me refiero a la JVM de IBM) se enfrenta a que quizás lo que el programador consideró más óptimo en un JDK-SUN no lo es en un JDK-IBM, por lo que parte del trabajo que se realizó en la fase de pruebas de desarrollo se ha perdido por completo. Además si hacemos bien las cosas, el salto de desarrollo a preproducción, implicará en la mayoría de los casos un tiempo extra para ver si el JDK-IBM continúa funcionando correctamente y nos ese mayor rendimiento del que hablábamos.

Preguntas que se me ocurren para aquellos que hayáis cambiado de un JDK-SUN a un JDK-IBM: ¿Es considerable el tiempo empleado en probar con un JDK y luego con el otro? Dado el modo en el que se suelen hacer las cosas para los cambios de desarrollo a preproducción y finalmente a producción, ¿os arriesgaríais a cambiar de una a otra?

A todo esto, ¿no os parece que así se pierde, un poco, una de las principales características de java, la multiplataforma?

(Más características).

La última vez que hice esto tuve que bajarme el binario de la web de Sun y seguir el proceso de instalación. Lo que pasa que desde entonces ha llovido mucho, y para los que no lo sepáis, desde hace un tiempo se puede instalar la máquina virtual y algunas cosas más desde los repositorios de apt. El único problema que podríais encontrar, es que los repositorios por default de apt no incluyen el necesario para instalar la máquina virtual de Sun.

Investigando por la red, conseguí encontrar algo interesante: aquí; sin embargo antes de poder ver cuales eran los repositorios que debía configurar, me acordé de synaptic, y decidí probar a ver que tal funcionaba. Y he ahí donde encontré un tesoro: AQUÍ.

Al hilo de esto os voy a comentar una cosa interesante. Por defecto las distribuciones que yo he instalado últimamente, si no le dices lo contrario, suelen instalar el gcj, que es la máquina virtual de Java de GNU, bien, pues existe un archivo interesante en la configuración de Linux: /etc/jvm en este se lista los directorios por orden de preferencia donde quieres que se busquen tus máquinas virtuales, en mi caso como siempre suelo utilizar la de Sun Microsystems, he eliminado el directorio de gcj y he dejado sólo el del jdk de sun.

La misión en mi caso era sencilla, montar el típico ejemplo para ver como funciona JNI y como quería probar Code::Blocks, decidí buscar un artículo y probar suerte. Increiblemente no conseguía hacer funcionar el ejemplo más sencillo que puedes imaginar, y sin embargo todo el mundo lo hacía funcionar más o menos rápido. Desesperado por la falta de habilidad aparente, me dirigí a la web de Sun y me descarge el manual que os he comentado, y como podéis ver, dedica su capítulo 2 a hacer funcionar el ejemplo, así que me dispuse a seguir paso a paso el procedimiento como si de una receta se tratase.

Incluso la parte de java la hice con bloc de notas en mano, nada de Eclipse y haciendo copy&paste del código, para no decirme a mi mismo que me había equivocado. El misterio empezó a desvelarse, cuando llegué a la parte de compilación del código en C para obtener la DLL. Dicho manual utiliza Microsoft Visual C++ como compilador, ahí fue donde empezé a dudar de lo que yo había hecho con Code::Blocks. Cuando terminé el ejemplo, todo funcionaba, incluso logré hacer funcionar todo con lo que había montado en entorno Eclipse y con mis clases iniciales. Sin embargo aunque para este ejemplo disponía de Visual C++, no era mi intención seguir utilizándolo, y pensé en buscar la clave a porqué con Code::Blocks no había sido capaz de lograr la hazaña.

En principio, ya había buscado en google cosas sobre jni y Code::Blocks pero no creí que el fallo fuese el último sino mi inexperiencia con dicha tecnología. Localizado el error, decidí hacer búsquedas más concretas. Resulta que en un foro de dicho software, se encuentra la respuesta: Code::Blocks no produce una buena DLL sino que cambia el nombre de los métodos, por lo que luego no son accesibles desde java por que los nombres a los que hacemos referencia han cambiado. Fuente.

En este mismo hilo viene como se obtiene la solución. Tenemos que recurrir a la línea de comandos y generar la librería dinámica desde este entorno. Sin embargo si haces lo que en el foro se dice, la solución que un tal Michael da, no obtendrás el éxito que esperabas, así que tuve que seguir buscando. El procedimiento a seguir es algo así como:

- Para compilar el código C que tenemos:

gcc -c HelloWorld.c

- Para obtener el fichero de definición necesario para la generación de la DLL:

dlltool -z HelloWorld.def HelloWorld.o

- En este punto viene nuestra intervención manual, este fichero generado es incorrecto, al editarlo os daréis cuenta que los nombres de los métodos han cambiado y por ejemplo nuestro método antes: Java_HelloWorld_print ha pasado a Java_HelloWorld_print@8 @ 1, he aquí el error!!!!. Por eso nuestras clases Java nos dan el error de que no pueden encontrar el método en cuestión. Osea, que no es Code::Blocks quien tiene el error sino el compilador gcc que no es capaz de generar bien este archivo, que es necesario para generar la DLL. La solución pasa por editar esto a mano y eliminar los caracteres extraños y luego ejecutar:

gcc -shared -o HelloWorld.dll HelloWorld.o HelloWorld.def

Esta DLL ya si es funcional y operativa, tanto como la de Visual C++.

Si por algún casual probáis:

gcc -shared -o HelloWorld.dll HelloWorld.o

Veréis que os genera la DLL sin necesidad de necesitar el .def, sin embargo si váis a comprobarlo, podréis ratificar que dicha DLL tampoco es buena. Supongo que en este punto gcc evita el segundo paso y se genera un .def que utiliza internamente.

Comprobado esto, podemos seguir utilizando Code::Blocks que sin duda es Open Source por si alguno lo dudábais.