subscripción
Expediente X
Diciembre 7th, 2003 - [Enlace local]
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.
» Leer más, comentarios, etc...