Java Cache Viewer: dónde se esconden los jnlp

Como dice más o menos la Wikipedia, Java Web Start es un framework desarrollado por Sun Microsystems quer permite iniciar directamente desde el navegador aplicaciones Java preparadas específicamente (siguen el protocolo Java Network Launching Protocol – JNLP – ). A diferencia de los applets Java, las aplicaciones Web Start no se ejecutan dentro el navegador, por lo que las duras restricciones de seguridad del sandbox de los applets no se aplican en este caso (aunque este nivel de seguridad también puede configurarse para las aplicaciones JNLP).

Dicho lo anterior a modo de introducción, ayer mismo necesité ejecutar una aplicación Web Start, en concreto iRiverter. Es una mini aplicación Java que permite convertir, a golpe de ratón, un archivo de vídeo .AVI al formato necesario para distintos players de vídeo (en concreto, también para Creative Zen, mi nueva «mascota»). Todo muy bonito y muy bien, pero hoy, cuando he querido ejecutarla de nuevo, me ha surgido la duda. ¿Tengo que estar conectado a Internet para ejecutarla? ¿descargarla otra vez y volver a ejecutarla? No tiene mucho sentido. Además, seguro que está cacheada. Y efectivamente, la gente de SUN lo pensó muy bien. Y no sólo eso, sino que nos permite ver todas las aplicaciones JNLP que hemos descargado, ejecutarlas offline y si queremos, hasta crear un icono de acceso directo a la aplicación cacheada en local. ¿Cómo? Yo lo he hecho a través del Java Cache Viewer, pero seguro que hay alguna otra opción mejor (espero comentarios).

$ /opt/jdk1.6.0_10/bin/ControlPanel

Pulsamos ahora, dentro de la sección «Temporary Internet Files» en el botón «View…». Se abrirá el «Java Cache Viewer». En el imagen vemos que tengo disponible iRiver, la aplicación que me interesa (y que descargué ayer).

Ahora, con el botón derecho sobre iRiver:

Vemos que tenemos la opción de ejecutar la aplicación Offline, y también de instalar un acceso directo (con icono correcto) en el escritorio. +1 para Java Web Start…

«Patrón singleton» revisited

Estoy leyendo un delicioso libro, «Effective Java», de Joshua Bloch, sobre buenas prácticas Java para programadores Java (el segundo capítulo, por ejemplo, empieza explicando cómo usar métodos de factoría estáticos y sus ventajas sobre los constructores típicos, para que os hagáis una idea…). El libro es una joya, de los que merece la pena leer junto a un buen café, tomando notas en los laterales, porque está cargadito de apuntes que reutilizarás en el futuro, seguro, al menos si programas en Java (sí, ya sé, «Java is evil», etc.. etc…. ) Enumera distintos ítems, (vamos a llamarles recetas), en las que indica cómo se hace tal cosa en Java y cómo se debería de hacer. En muchas ocasiones, las recetas están directamente relacionadas con patrones de diseño, soluciones a problemas comunes. En otras, con anti-patrones : soluciones que NO se deberían de adoptar ante problemas comunes.

Sólo un comentario más de presentación, extraído del prefacio, en palabras de James Gosling, el padre de Java: «I sure wish I had had this book ten years ago. Some might think that I don’t need any Java books, but I need this one.»

Bien, una vez hechas las introducciones, pasamos a la chicha. Uno de los puntos sobre el que ya hablamos en otro post de DiarioLinux trata sobre el patrón singleton. El caso es que Bloch recomienda seguir una plantilla para aplicar el patrón singleton diferente a la que recomienda el libro de Liskov (Program Development in Java). La recomendación (de Bloch) es la siguiente:

// Singleton with public final field public class Elvis { public static final Elvis INSTANCE = new Elvis(); private Elvis() { ... } public void leaveTheBuilding() { ... } } // como todo el mundo sabe "<a href="http://www.imdb.com/title/tt1216513/">There's only one Elvis</a>" :-)

Yo mismo recomendaba la plantilla de Liskov frente a la de Bloch… pero visto lo visto, y sabiendo que la recomendación de Liskov podría tener condiciones de carrera… ya no hay duda. Sin embargo, el propio Bloch indica que «un consumidor de ese código con suficientes privilegios podría invocar al constructor privado usando las capacidades de introspección de Java, con el método AccessibleObject.setAccessible», así que para evitar ese problema (hay que ser rebuscado de narices), recomienda esta otra forma:

// Singleton with static factory public class Elvis { private static final Elvis INSTANCE = new Elvis(); private Elvis() { ... } public static Elvis getInstance() { return INSTANCE; } public void leaveTheBuilding() { ... } }

que se parece muchísimo a la recomendación de Liskov, pero sin el problema de las condiciones de carrera.

Finalmente, llega la guinda. Bloch dice que todo lo anterior está muy bien y tal, pero que teniendo disponible Java 1.5 desde hace ya unos cuantos añitos, que nos podríamos simplificar todos un poco la vida mediante el uso de tipos enumerados (disponibles en Java desde la versión 1.5, o 5.0 para aquellos lectores más comercial-friendly):

// Enum singleton - the preferred approach public enum Elvis { INSTANCE; public void leaveTheBuilding() { ... } }

«While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton.» Amén 🙂

PD: buscando documentación sobre esto, me he encontrado casualmente con la receta que comento en un artículo de InformIT.

Visual Paradigm, Linux y Compiz

No sólo ocurre con Visual Paradigm sino con muchas aplicaciones Java con interfaz gráfico SWING. Siempre que usemos Linux con Compiz (efectos gráficos) activado. El problema es que al lanzar la aplicación (en el ejemplo, al lanzar Visual Paradigm), la ventana sale «en blanco» :

Hay dos soluciones a este problema:

1) La obvia, desactivar Compiz momentáneamente (desde consola $ metacity –replace podría valer)

2) El problema concreto es que AWT no soporta (en todos los sentidos 😉 el gestor de ventanas Compiz Así que hay que decirle a AWT que use otro. ¿Cómo? Así: export AWT_TOOLKIT=MToolkit Lo que hace que AWT use Motif como gestor de ventanas.

La solución está documentada en la web de Visual Paradigm (No, VP no es libre . Sí, VP está hecho en Java. Sí, lo sé, pero es una aplicación extraordinaria)

Proyecto DJ Java: ejecuta componentes nativos Linux en Java

«Any sufficiently advanced technology is indistinguishable from magic.» Arthur C. Clarke. («Cualquier tecnología lo suficientemente avanzada es indistinguible de la magia.») Eso es lo que he sentido al ver «The DJ Project», un proyecto Java bajo licencia LGPL que permite integrar componentes nativos Linux en aplicaciones Java Swing. Traducido al castellano y con un ejemplo: puedes integrar el plugin de Flash en una aplicación Java Swing y controlarlo por programación desde Java. Puedes enviar desde Java parámetros a funciones Flash y viceversa. Puedes usar el plugin VLC, o el navegador Mozilla desde una aplicación Swing. Y todo ello funcionando en Linux sin problemas… o en Windows! (en MacOSX… tal vez, no tengo constancia de que no se pueda, pero tampoco de que sea posible en este sistema operativo).

La instalación es un poco compleja, dado que primero hay que tener XulRunner instalado: sh-3.2$ xulrunner -v Mozilla XULRunner 1.8.1.4_0000000000

Una vez hecho esto, hay que asegurarse de tener Java 1.6 y una versión moderna, no vale el update 2 o 3, sino que al menos, ha de ser el 5: java version "1.6.0_10-beta" Java(TM) SE Runtime Environment (build 1.6.0_10-beta-b25) Java HotSpot(TM) Client VM (build 11.0-b12, mixed mode, sharing)

Para lanzar la aplicación de demostración de DJ Java lo más sencillo es hacerlo a partir de la demo en formato Java Web Start, pero primero hay que indicar dónde tenemos instalados los plugins de Firefox (el plugin de Flash, por ejemplo): $ export MOZ_PLUGIN_PATH=/usr/lib/firefox/plugins/ Ahora sí, podemos lanzar la aplicación de mostración: $ ./javaws <a href="http://djproject.sourceforge.net/ns/DJNativeSwingDemo.jnlp">http://djproject.sourceforge.net/ns/DJNativeSwingDemo.jnlp</a> Las posibilidades que abre esta librería para el desarrollo de aplicaciones multimedia son impresionantes…