Key Adapter y JPanel

El método addKeyListener de la clase Component de Swing nos permite agregar oyentes de teclado a cualquier componente. Por tanto, si estamos creando un JPanel, perfectamente podríamos intentar hacer algo así:

public class MyPanel extends JPanel {

public MyPanel() {
MyKeyAdapter keyAdapter = new MyKeyAdapter();
this.addKeyListener(keyAdapter);
}
...
}

Siendo MyKeyAdapter algo de este estilo.

public MyKeyAdapter extends KeyAdapter {

public void onKeyPressed(KeyEvent event) {
...
}

...
}

Pero si probamos este código, nos encontramos que por más que aporreemos el teclado, los eventos no se lanzan. El motivo es simple. Los eventos de teclado se lanzan siempre sobre el elemento de la interfaz que tiene el foco, y los JPanel, por defecto, no son enfocables (focusables). Así que una solución rápida al problema sería hacer el JPanel focusable de la siguiente manera.

public MyPanel() {
this.setFocusable(true);

MyKeyAdapter keyAdapter = new MyKeyAdapter();
this.addKeyListener(keyAdapter);
}
...
}

Ahora, al hacer click sobre el panel, ganará el foco. Si queremos dárselo desde algún rincón de nuestro código, también podemos hacerlo con la llamada panel.requestFocus().

Tutorial de Oracle ADF Business Components publicado en Javahispano

Hoy me han publicado un nuevo tutorial en Javahispano. En este caso el objetivo era hablar un poco de los Business Components de Oracle ADF, y explicar algunas de las cosas que se pueden hacer al trabajar con ellos en jDeveloper 11.

Este tutorial viene a complementar al que ya presenté hace unos meses sobre el desarrollo de una aplicación Web con ADF, y pretende además satisfacer algunas de las solicitudes que me llegaron en sus comentarios.

Espero que sea útil.

InstantiationException

En cuanto uno empieza a hacer cositas con reflexión en Java, es normal que se encuentre tarde o temprano con la excepción InstantiationException. Hasta la versión 1.5, el api de Java indicaba respecto a esta excepción algo así como:

Lanzada cuando una aplicación intenta crear una instancia de una clase utilizando el método newInstance de la clase Class, pero el objeto no puede ser instanciado porque es una interfaz o una clase abstracta.

Este mensaje tenía la habilidad de hacernos pensar que los especificados eran los únicos motivos que podían hacer que se lanzase esta excepción. Pero entonces, si estamos absolutamente seguros de que estamos intentando instanciar una clase no abstracta, ¿por qué me puede aparecer el error?

Pues por ejemplo, porque estés ejecutando algo así:

Object o = Class.forName("Clase").newInstance();

Y en la clase Clase no tengas explícitamente definido el constructor sin parámetros. Simplemente añadiéndolo a la definición de la clase solucionaremos entonces el problema.

Es por esto que a partir de la versión 6, el api de la clase InstantiationException ha cambiado su descripción a:

Lanzada cuando una aplicación intenta crear una instancia de una clase utilizando el método newInstance de la clase Class, pero el objeto no puede ser instanciado. La creación de la instancia puede fallar por varios motivos, incluyendo, pero no limitándolos a:

• El objeto representa a una clase abstracta, una interfaz, un array, un tipo primitivo o void.
• La clase no tiene constructor sin argumentos.

Mucho mejor.

Java FX 2 - Error de instalación del plugin para Net Beans 7.0

El pasado 24 de mayo salió la versión beta del nuevo Java FX 2. Tras mucho tiempo esperando este último intento de convertir Java FX en una tecnología con repercusión, andaba ansioso por empezar a cacharrear, y plantearme algún proyectito para ver qué nos podía ofrecer.

Pero nada más empezar, ya me estaba dando cabezazos. Resulta que tenemos disponible un plugin para la versión 7.0 de Net Beans. Me lo descargo, lo instalo, reinicio el IDE como me piden, y... casquiporre.

Warning - could not install some modules

Y una larga retahíla de librerías o similares.

Como en las instrucciones de instalación no se especifica nada sobre errores, y en principio las había seeguido tal cuál, incluyendo la instalación previa del runtime, empecé a probar siguiendo mi instinto. Reinstalación de Net Beans, rebajada del plugin, reinicio del pc, tonterías varias... nada de nada.

Hasta que en el foro de Oracle encontré la solución gracias a la ayuda de 862201. La historia es que antes de instalar el plugin en sí, hay que instalar todas las actualizaciones disponibles. Esto lo hacemos accediendo a Tools - Plugins, y seleccionando todos los elementos de la pestaña Updates.

Ahora sí, ¡a juguetear!

4F530E43505002EF

Ese críptico código es el que nos encontramos hace unos meses, junto con un mensaje de error no mucho más elocuente en el log de nuestro servidor de aplicaciones OAS 10.1.2.0.2.

Unexpected Signal : 11 occurred at PC=0xB7D49B2D 

Function=(null) 

Library=[...]/jdk/jre/lib/i386/server/libjvm.so 

NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. 

Heap at VM Abort: 

Heap 

def new generation total 3392K, used 1221K 

eden space 3072K, 33% used 

from space 320K, 63% used 

to space 320K, 0% used 

tenured generation total 29264K, used 18790K 

the space 29264K, 64% used 

compacting perm gen total 29184K, used 29050K 

the space 29184K, 99% used 

Elapsed Time = 1602 

# 

# HotSpot Virtual Machine Error : 11 

# Error ID : 4F530E43505002EF 

# Please report this error at 

# http://java.sun.com/cgi-bin/bugreport.cgi 

# 

# Java VM: Java HotSpot(TM) Server VM (1.4.2_06-b03 mixed mode) 

# 

# An error report file has been saved as hs_err_pid20003.log. 

# Please refer to the file for further information. 

#

Cuando uno se encuentra con este tipo de errores sufre un repentino estado de ansiedad y se acuerda de aquel lejano día en que se decantó definitivamente por la informática como profesión.

Aunque en realidad el tema parece claro: ha habido un error de la máquina virutal de Java, ésta ha cascado irremediablemente, y tu aplicación se ha quedado tostada con el consiguiente cabreo del sufrido usuario.

Y en este caso, ¿podemos hacer algo aparte de largarle el problema a nuestro amigo Larry? (es lo que tiene comprar empresas, que te las llevas con lo bueno y lo malo).

Pues sí, podemos.

Lo que tenemos ante nosotros es la consecuencia de uno de los habituales bugs informáticos, que se resuelve con una actualización de versión de la JVM. Para este error concreto era necesario pasar de la 1.4.2_06-b03 a la 1.4.2_26_b07 (por contextualizar, se trata de una aplicación basada en ADF-UIX)

Para actualizar la JVM de una instancia de OAS ya instalada, lo que tenemos que hacer es seguir estos sencillos pasos.

- Instalar la nueva versión en la ruta .../oracle/product/10.1.2.0.2/midtier_1/j2ee/nombreInstancia/jdk.

- Modificar, a través del Enterprise Manager, la propiedad Ejecutable java de la instancia en cuestión, apuntando a la ruta 

.../oracle/product/10.1.2.0.2/midtier_1/j2ee/nombreInstancia/jdk/j2sdk1.4.2_26/bin/java, y aplicar los cambios.

- Ejecutar el comando opmnctl reload.

- Reiniciar la instancia desde el Enterprise Manager.

Y podemos seguir respirando tranquilos.

Ejecutable Java

Una pregunta que todos nos hacemos alguna vez cuando empezamos a trabajar con Java es: ¿cómo creo un ejecutable para mis programas? Esta pregunta, normalmente, parte de una laguna conceptual, ya que no tiene ninguna lógica. Java es un lenguaje interpretado, cuyos programas corren sobre la máquina virtual, luego no tiene sentido pensar en un ejecutable, que es algo que se lanza directamente sobre la máquina real.

De todas formas, posiblemente, lo que la mayoría de nosotros quiere decir con esa pregunta es: ¿¿en serio tengo que escribir java -jar programa.jar en la línea de comandos cada vez que quiero arrancar mi aplicación?? ¿¿No existe una forma de tener un iconito en el escritorio, y hacer doble clic sobre él??

Pues sí, claro. De hecho existen varias alternativas para tener un "ejecutable" java; pero es importante tener claro que en ningún caso se trata de un ejecutable realmente.

La primera opción es crear un fichero .bat, y dentro meter los comandos para situarnos en la ubicación de nuestro programa y lanzarlo. Un ejemplo lo podemos ver con la herramienta JMeter. En la carpeta bin de su instalación encontraremos un fichero jmeter.bat, que hace esto básicamente, fijando montones de parámetros e historias antes, eso sí.

La segunda opción sería simplemente la de indicarle a nuestro amigo Windows que a la hora de abrir los ficheros con extensión jar tiene que utilizar la máquina virtual de Java. Esto lo podemos hacer seleccionando el menú Abrir con... sobre el jar, y eligiendo el correspondiente java.exe. Si le decimos al sistema operativo que utilice siempre esa opción podremos ejecutar los jar con doble clic sobre ellos.

Por último queda otra opcion que nunca he utilizado personalmente, que son los muchos programas que generan "ejecutables java", como exe4j, IzPack o JSmooth. Por lo que he podido ver, en general lo que hacen es simular de alguna forma lo que haría un ejecutable (algunos incluso ofrecen la posibilidad de incluir la JVM dentro del fichero de la aplicación). 

En cualquier caso hay que tener presente que los programas Java se lanzan siempre sobre la JVM, y por tanto no tiene sentido hablar de ejecutables tal cual.

¿SringTokenizer deprecated?

Hoy, con muchos años de retraso, me he enterado de que la clase StringTokenizer ha sido deprecada. Bueno, técnicamente no, porque en el API no aparece como tal, pero desde Java 1.4 se incluye este claro mensaje en la descripción de la clase.

"StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead."

Que viene a decir que no se recomienda el uso de la clase porque hay un alternativa mejor: el método split de la clase String. En la propia descripción de la clase hay un ejemplo de uso de este nuevo método, que no tiene mayor complejidad.

Lo que no entiendo realmente es por qué razón no se marca la clase como Deprecated si, atendiendo a ese texto, lo está a todos los efectos. Llevo años utilizando la clase sin saber que su uso no está recomendado, dado que en ningún momento ha habido un compilador capaz de avisarme de ello. Además, es lógico pensar que la mayoría de la gente que entra a consultar el API no se pare a leer todo el rollo que nos suelta la gente de Sun, y se vaya directamente a ver la definición de los métodos, que es lo que normalmente uno necesita.

Lógicamente me surgen dudas, ¿cuántas clases habrá en el vasto API de Java con advertencias similares a esta? ¿Por qué no las hieren de muerte? ¿Debería existir otro estado para clases "no recomendadas"? ¿En qué se diferencian de las deprecadas?

Seguiremos investigando...

Fecha de creación en Java

Un tema que acabo de descubrir gracias a una pregunta planteada en Debug Mode On.

Nunca me había encontrado con la necesidad de acceder a la fecha de creación de un archivo desde un programa Java, y como todos, al ver la pregunta pensé que sería tan simple como buscar un método tal que getCreationDate en el API... pues no.

Resulta que, por el momento, Java no ofrece ninguna opción para acceder a este dato, según parece por aquello de que pretende ser multiplataforma, y la fecha de creación no se puede recuperar en todos los sistemas operativos.

Así que hay que hay que buscarse la vida. Por lo que he podido leer, se plantean dos posibles alternativas para solventar este problema. Por un lado, hacer una llamada a nuestro sistema desde el código, y parsear la respuesta. Por otro, utilizar JNI.

Y, ¿qué es JNI? Pues una más de las muchas siglas que componen nuestro peculiar lenguaje. Java Native Interface, básicamente, sirve para poder invocar desde Java programas desarrollados en otros lenguajes. Por tanto, la solución la tenemos en hacer un programa en cualquier lenguaje que te permita consultar la fecha de creación, e invocarlo a través de JNI.

Si navegáis por ese maravilloso mundo que es Internet encontraréis varias páginas con código para ambas alternativas.

Por cierto, que según comenta GreenEyed en el hilo del comienzo de esta entrada, se está trabajando en la JSR-203, que proporcionará alguna forma de acceder a información proporcionada específicamente por cada sistema operativo, con lo que se acabarían nuestros problemas.

iReport - java.lang.NoClassDefFoundError: org/codehaus/groovy/control/CompilationFailedException

Un error bastante habitual que se produce cuando trabajamos con la herramienta iReports, creo que a partir de la versión 3 (en mi caso concreto, la 3.7.0).

Cuando creamos un informe con esta herramienta, podemos encontrarnos con el siguiente error al compilar:

java.lang.NoClassDefFoundError: org/codehaus/groovy/control/CompilationFailedException

La causa es tan simple como que el lenguaje seleccionado para el informe es, por defecto, Groovy en lugar de Java. Para solucionarlo seleccionamos nuestro report (el elemento raíz de la vista Report Inspector), y entre las propiedades editamos el valor de Language.

Para evitar tener que realizar este cambio con todos los nuevos informes que generemos, lo suyo es elegir Java como lenguaje predeterminado para nuestro iReports. Esto podemos hacerlo a través del menú Herramientas - Opciones, en la pestaña iReport - General (la que veremos al acceder al menú).