4 bits blog

De forma predeterminada, los applets de Java tienen sus funciones limitadas por la sandbox para que no puedan acceder a la máquina local. Pero si el applet se firma, y el usuario acepta su ejecución (mediante una ventana de aviso) el applet podrá acceder a la máquina local como si se tratase de una aplicación Java más.

Hasta aquí todo bien, pero resulta que si desde la web en la que se carga el applet firmado, se realiza una llamada a cualquier método de éste desde JavaScript, el applet vuelve a perder los privilegios ya que el código JavaScript proviene es inseguro.

Aquí surge la pregunta, ¿cómo se hace para poder ejecutar métodos de un applet firmado desde JavaScript sin que el applet pierda los privilegios? La respuesta es utilizar el siguiente trozo de código:

AccessController.doPrivileged (
    new PrivilegedAction () {
        public Object run () {
            // Código con privilegios
        }
    });

Este código permite ejecutar el código que se quiera con privilegios, además el valor devuelto es de tipo Object, por lo que se puede devolver el tipo de objeto que se quiera.

Basado en JavaScript and Applet interaction.

Al actualizar el código de un proyecto antiguo uno se puede encontrar cualquier cosa. En una de esas paranoias mías (o eso creía yo) me dio por dedicarme a cambiar todos los compareTo por equals, que me parecía como una instrucción más directa, óptima y mejor. No iba yo muy desencaminado.

La primera nos devuelve un entero que indica si el objeto es mayor que el parámetro de entrada, menor, o igual. La segunda nos devuelve directamente un booleano que nos dice si son iguales o no. Pero yo personalmente no recuerdo haber utilizado nunca el compareTo para algo que no fuera comprobar si un objeto (y más en concreto un String) es igual a otro. Así pues, me he creado un código chorras para saber cuánta diferencia hay (de paso metí el equalsIgnoreCase):

public static void main (String [] args) {
  String s = "necesito una prueba a ver si cuela ésta misma";
  long ini = System.nanoTime ();
  for (int i = 0 ; i < 10000000; i ++ ) {
    boolean b = s.compareTo ("necesito una prueba") == 0;
  }
  System.out.println (
      "CompareTo: " + (System.nanoTime () - ini)/1000000.0);

  ini = System.nanoTime ();
  for (int i = 0 ; i < 10000000; i ++ ) {
    boolean b = s.equals ("necesito una prueba");
  }
  System.out.println (
      "equals: " + (System.nanoTime () - ini)/1000000.0);

  ini = System.nanoTime ();
  for (int i = 0 ; i < 10000000; i ++ ) {
    boolean b = s.equalsIgnoreCase ("necesito una prueba");
  }
  System.out.println (
      "equalsIgnoreCase: " + (System.nanoTime () - ini) /1000000.0);
}

Los resultados son demoledores. compareTo es unas 150 veces más lento que equals:

(el tiempo va en milisegundos)
CompareTo: 1886.853143
equals: 71.728111
equalsIgnoreCase: 60.81111

Sorprende que equalsIgnoreCase sea más rápido que equals, sobre todo porque lo primero que hace es ejecutar el equals. Puede ser cosa del orden, pero probando a cambiarlas los datos no variaban demasiado. Sí puedo decir que de tanto en tanto equals es más rápido. En cualquier caso, puede parecer una chorrada perder 1'8 segundos en 10 millones de consultas que no se van a dar así en un programa real, pero al final todo suma y si los Strings ya son poco óptimos de por sí...

Una de las cosas que se nos vende con Java es que al depender de una máquina virtual tu código es independiente de la plataforma sobre la que se ejecute. Esta afirmación se cumple para la gran mayoría de casos (especialmente si eres un buen programador y utilizas los menores literales posibles), pero no es una tautología. Es como decir que la tierra es esférica. Casi, pero no.

Una cosa muy curiosa que me ha pasado hoy y me ha tenido entretenido la mitad del día va relacionada con esto. Para ciertas tareas Java se apoya en librerías nativas del sistema operativo. Y con los nativos hemos topado. Imaginad que os habéis currado una aplicación que os muestra una serie de gráficos. Depurais, probais, mostrais al cliente y, por fin, pasais a producción. Aquí se produce la hecatombe. Error Java chungo:

Can’t connect to X11 window server using ‘:0.0′ as the value of the DISPLAY variable.

Situación: Servidor web Tomcat más viejo que la tarara montado sobre un Linux más viejo que el Tomcat más viejo que la tarara. A pesar de que me ha llevado bastante decidirme a buscarlo en Google pensando que sería un tema de librerías, al parecer es un problema bastante común en librerías no-PJA (Puro Java AWT), como jFreeChart, cuando el equipo donde se está ejecutando la aplicación no tiene un servidor gráfico rulando. Si fueran librerías Java puras no pasaría nada.

La solución es tan sencilla como lo que sigue como añadir la siguiente línea en el catalina.sh:

CATALINA_OPTS=”-Djava.awt.headless=true”

El motivo es que las funciones gráficas necesitan una ventana X ejecutándose. Si no la hay, el comando anterior le dice a la ejecución que utilice buffers virtuales (Fuente).

Y ahora, la pregunta. Si el programa instalado era una actualización, ¿cómo funcionaba antes?

Una de las cosas que hacen grande al IDE Eclipse (que recientemente ha estrenado versión, la 3.4) es la cantidad de plugins que uno encuentra para casi cualquier cosa. Uno de esos tipos de plugin, de los más útiles, son los de herramientas de revisión de código. Si nunca habéis usado uno y tenéis la moral baja, no los uséis ahora; la primera vez siempre sonroja un tanto. En mi caso, he utilizado 3 hasta la salida del nuevo Eclipse. La mayor parte de lo que viene a continuación lo encontré después de aquel post Plugins de Eclipse, así que vamos con ellos:

FindBugs

Éste estaba en la lista anterior. Es un analizador de código bastante eficiente en lo suyo (bugs potenciales y algunas malas prácticas de programación) marcando todo lo que encuentre en 3 niveles de gravedad. Personalmente es mi favorito, sobre todo para empezar, pues no me resulta tan paranoico como los demás y puedes corregir casi todo lo que marca.

PMD

Más completo que el anterior (mucho más), además de todo lo anterior, también comprueba la complejidad o longitud del código. Pero resulta un paranoico que ofrece pocas soluciones reales. Por ejemplo, te dice que una variable se puede declarar como final y cuando la declaras te dice que no, que no se deben declarar variables finales, que uses campos. ¿¿¿¡¡En qué quedamos!!???

A su favor tiene que es mucho más completo y que también permite buscar código duplicado (malditos copypastes).

Enerjy

Me enteré de este plugin a través de JavaHispano, debido a su reciente gratuidad. Es similar al PMD, tiene algunas reglas más paranoicas todavía (uso de tabulador en lugar de espacios) y tiene la grave, gravísima desventaja de que no se ejecuta bajo demanda. Aunque puedes marcar qué proyectos excluir del análisis, me parece un tanto inviable en workspaces con muchos proyectos. Una ventaja que le encuentro es que te cambia automáticamente los bucles for de Java 1.4 por los de Java 5 (donde es posible, claro), aunque tampoco estaría mal que lo hiciera sólo si estás trabajando con Java 5 ó superior :-/

Fin

Esta última fiebre revisionista me dio tras leer Revisiones de código automatizadas con Eclipse, donde se habla más extensamente de los 2 primeros y también del CheckStyle. Éste último lo instalé, me empezó a señalar que las variables no cumplían con el estándar de nombrado y, con la misma, lo envié al limbo. Paranoias vale, pero las justas; una variable boolean que no se llame sexo no es seria ;)

¿Habéis utilizado alguno de estos plugins? ¿Quizá otro que desconozca? ¿Qué ventajas y desventajas veis a estas herramientas?

¿Qué programador futbolero no ha soñado nunca con hacerse su propio PCFútbol? Pues a alguien se le ocurrió en su día que podía ser una buena idea programar equipos de fútbol y que jugaran entre sí una suerte de copa en busca de la gloria, la fama y la satisfacción de hacer morder el polvo a esos engreídos de los contrarios… pues eso es la JavaCup 2008, que desde la asociación JavaHispano piden ayuda para publicitarla.

La revista Sólo Programadores, la organización sin ánimo de lucro javaHispano y Sun Microsystems hemos organizado un concurso que consiste en un torneo virtual de fútbol donde cada equipo será una clase Java que implementa una interfaz predefinida.

La verdad es que suena muy interesante, ¿no creéis?, y hasta hay premio monetario (ah, el vil metal). ¿A qué esperáis para programar a vuestros gladiadores futboleros?