Pues sí… todo lo que empieza acaba, y las vacaciones no iban a ser una alegre excepción.

Aquí estamos de nuevo listos para entrar en combate. Esta vez, además, el retorno al MundoReal™ coindice con un momento de emocionantes cambios a nivel profesional, lo cual hace especialmente motivador el regreso.

En cuanto a las vas vacaciones, simplemente geniales: mucho descanso en las playas de Huelva y Cádiz y, sobre todo, un grato recuerdo de la visita a Lanzarote, que sin duda es espectacular; si alguna vez tenéis oportunidad de visitar la isla, no dudéis en ir a disfrutar de ese lugar tan diferente. La única pega ha sido la insistente ola de calor que nos ha perseguido a todos nuestros destinos, pero bueno, son gajes del oficio.

De compañero de viaje esta vez he elegido Struts 2 in action, una muy recomendable lectura para conocer este veterano framework Java de desarrollo de aplicaciones web bajo la filosofía MVC. Me ha resultado interesantísimo conocer el enfoque del marco de trabajo, y contrastarlo con el muy reciente ASP.NET MVC; aunque con las obvias diferencias vinculadas a las tecnologías subyacentes en cada caso y al nombrado de componentes, hay muchísimas coincidencias y es sencillo encontrar correspondencias entre ambos frameworks que facilitan la comprensión y asimilación de los conceptos.

El libro está editado en español por Anaya Multimedia, bajo el nombre Struts 2; aunque, como suele ocurrir en este tipo de textos, de vez en cuando te encuentras errores de traducción y contenidos, cumple bastante bien su cometido.

Y sin más preámbulos, comenzamos la temporada 2009-10 en Variable not found, donde espero seguir contando, como hasta ahora, con vuestra participación y apoyo.

Publicado en: Variable not found.

Vía The Server Side acabo de enterarme de la existencia de Quaere, una implementación para Java del proyecto LINQ de Microsoft, creada por Anders Norås.

Se trata de un DSL (Domain Specific Language, lenguaje específico de dominio) que permite integrar dentro de código Java sentencias muy parecidas a SQL para extraer información de arrays, colecciones y otros almacenes de información, de forma muy sencilla y potente. Gracias a la utilización de static imports y fluent interfaces, no es necesario usar preprocesadores o generadores de código intermedios, el código se compila directamente sobre javac importando las librerías de Quaere.

Y para que se entienda mejor el alcance del proyecto y cómo puede ayudarnos a desarrollar, unos ejemplos básicos tomados del blog del autor, que demuestran la potencia de esta extensión para gestión de datos:

// Obtiene los números menores de
// cinco del array:
Integer[] numbers = 
    {5, 4, 1, 3, 9, 8, 6, 7, 2, 0};

Iterable<integer> lowNums = 
    from("n").in(numbers).         
    where(lt("n", 5)).         
    select("n");

// Obtiene una colección
// de strings con los nombres de
// los productos:
List products = 
    Arrays.asList(Product.getAllProducts());

Iterable<String> productNames =
    from("p").in(products).
        select("p.getProductName()");

 

Sí, he de admitir que es una pregunta rara, pero me la hago desde que conocí hace ya muchos años que en lenguaje C podía incrementar una variable de tres formas, autoincrementando (var++), incrementando en uno (var+=1) o sumando la unidad (var=var+1)... ¿hay alguna diferencia entre ellas? Esta absurda inquietud la he mantenido durante lustros, viendo cómo estas construcciones se propagaban hacia lenguajes más actuales con sintaxis basada en C, como C++, C# o Java.

Claro está que desde el punto de vista semántico no existe diferencia alguna, pues todas comparten el mismo objetivo: incrementar en una unidad la variable indicada. Sin embargo, ¿existe diferencia en la forma en que el compilador las trata? ¿se genera código más eficiente utilizando una de ellas, o son absolutamente iguales?

Para responder a esta cuestión, he realizado una pequeña aplicación en varios lenguajes y plataformas, generado posteriormente un ejecutable y desensamblado el binario de salida con la herramienta correspondiente en cada caso. A continuación describo los resultados obtenidos.

En primer lugar, he atacado al lenguaje C, compilado bajo Linux con gcc y desensamblando con ndisasm.

La aplicación con la que he realizado las comprobaciones era la siguiente:

#include "stdio.h"
main()
{
   int i;
   i = 0x99f;
   i++;
   i += 1;
   i = i + 1;
   printf("Vale: %d", i);
}

Nota: el 0x99f con el que inicializo la variable "i" me sirve para buscar rápidamente en el código ensamblador dónde se encuentran las instrucciones a estudiar.

Bueno, a lo que vamos. Una vez compilado y desensamblado, el código que encuentro es:

...
mov word [di-0x8], 0x99f
add [bx+si], al
add word [di-0x8], byte +0x1
add word [di-0x8], byte +0x1
add word [di-0x8], byte +0x1
...

Según parece, el compilador gcc ha generado exactamente el mismo código en todos los casos. La verdad es que este resultado me ha sorprendido un poco, esperaba que se utilizaran en los primeros casos las instrucciones de incremento directo del procesador, optimizando el binario generado, pero no ha sido así. A la vista de esto, he preguntado a Google y parece ser que es un comportamiento recomendado para los compiladores de C, por lo que podemos dar por concluida esta línea de la investigación.

A continuación he pasado a C#, compilando tanto con .NET Framework de Microsoft como con Mono. La aplicación era similar a la anterior (traducida, obviamente), y el resultado en lenguaje intermedio (MSIL), obtenido tanto con ildasm como con su equivalente monodis es el mismo:

[...]
//000011:      int i = 0x99f;
  IL_0001:  ldc.i4     0x99f
  IL_0006:  stloc.0
//000012:      i++;
  IL_0007:  ldloc.0
  IL_0008:  ldc.i4.1
  IL_0009:  add
  IL_000a:  stloc.0
//000013:      i += 1;
  IL_000b:  ldloc.0
  IL_000c:  ldc.i4.1
  IL_000d:  add
  IL_000e:  stloc.0
//000014:      i = i + 1;
  IL_000f:  ldloc.0
  IL_0010:  ldc.i4.1
  IL_0011:  add
  IL_0012:  stloc.0
[...]

Podemos observar que, como en el caso anterior, el compilador no diferencia entre el tipo de incremento que utilicemos, da exactamente igual.

Por último, probamos con Java 5, utilizando el JDK de Sun. La aplicación es exactamente igual a las anteriores, con la correspondiente adaptación a este lenguaje, algo así como:

class Prueba
{
  public static void main(String[] args)
  {
    int i = 0x99f;
    i++;
    i+=1;
    i=i+1;
    System.out.println("Vale: " + i);
  }
}

El compilador de Java, en este caso, sí hace distinciones entre los dos primeros modelos de incremento y el tercero. El autoincremento e incremento los genera exactamente iguales, creando una instrucción bytecode de incremento en una unidad, mientras que el último lo crea como una suma; supongo que la primera será posible optimizarla y su ejecución será más rápida:

 0: sipush 2463
 3: istore_1
        // i++:
 4: iinc 1, 1
        // i+=1:
 7: iinc 1, 1
        // i=i+1:
 10: iload_1
 11: iconst_1
 12: iadd
 13: istore_1
        // Resto...
[...]

En resumidas cuentas, podemos usar con toda tranquilidad cualquiera de los operadores de suma para incrementar una variable, puesto que el código será igual de eficiente (o poco eficiente, según se mire) y prácticamente no tendrá incidencia en la velocidad de ejecución, al menos con las opciones de compilación por defecto. Sólo Java parece estar adelantado en este sentido, pues es capaz de distinguir estos casos.

Y sí, era una inquietud de lo más absurda, lo dije desde el principio, pero me he quedado muy tranquilo, y con una duda menos en mi saco de ignorancia.