Gimenoblog

Ayer estaba compilando en línea de comandos con Ant y me empezaron a ocurrir cosas muy extrañas. Al ejecutar unas clases me sucede algo que nunca me había pasado: me da un java.lang.VerifyError. Eliminé todos los archivos de bytecodes y volví a compilar. Nada, el error persistía. Pensé que era culpa del j2sdk de Sun ya que estaba trabajando con una versión beta, así que me bajé la última versión del j2sdk1.4, la instalé y probé de nuevo. Nada, me seguía apareciendo ese dichoso error.

Como no sabía que hacer me puse a hacer otras cosas con el ordenador. Más tarde volví a probar, y nada. Cúal fué mi sorpresa al darme cuenta de que había indicado en el build.xml que usara gcj para compilar. Dije: "bueno, pues voy a compilar con el javac del jsdk de Sun...", y sorpresa!! no compilaba el código que tantos días llevaba compilando. Tenía bastantes errores. Pero, ¿cómo es posible que hace unas horas y durante varios días el gcj hubiese sido capaz de compilar esos archivos que contenían errores? Si alguien tiene curiosidad los errores más frecuentes eran "import"s olvidados y expresiones con poco sentido como comparar null con un boolean: if(funcionBooleana() == null). ¿Cómo había sido capaz gcj de "adivinar" lo que pretendía hacer el código? Porque el código en días anteriores compilaba y ejecutaba bien.

Arreglé los errores y volví a compilar, ahora todo funcionaba bien.... o no. Me dió una NullPointerException; dije "Bueno, esto se arregla en seguida, a ver en qué línea salta el error...". Sorpresa!! el printStackTrace() no me mostraba las líneas por donde pasaba la excepción! "Y ahora qué hago" me pregunté. Bien, lo que hice fue compilar con gcj y voilá ningún problema. Así que mientras no me salga otro java.lang.VerifyError seguiré compilando con gcj.