Laissez tomber GCJ, les gars.

sudo ln -s /usr/lib/jvm/java-6-sun-1.6.0.17/bin/java /etc/alternatives/, c'est tout ce qu'il y a à dire. J'ai facilement perdu 2 heures vendredi dernier, à chercher dans le code de mes étudiants un problème qui se trouvait clairement dans les bibliothèques Java qui accompagnent la JVM "gnu", le "choix par défaut" d'Ubuntu Lucid Lynx. Et là, je regrette, les cocos, mais ce n'est absolument pas lucide.

java.util.Scanner[delimiters=\p{javaWhitespace}+][position=372][match valid=true][need input=false][source closed=false][skipped=false][group separator=\,][decimal separator=\.][positive prefix=][negative prefix=\Q-\E][positive suffix=][negative suffix=][NaN string=\QNaN\E][infinity string=\Q?\E]
java.lang.NullPointerException
   at java.util.regex.Matcher.toMatchResult(libgcj.so.10)
   at java.util.Scanner.myCoreNext(libgcj.so.10)
   at java.util.Scanner.myPrepareForNext(libgcj.so.10)
   at java.util.Scanner.myNextLine(libgcj.so.10)
   at java.util.Scanner.hasNextLine(libgcj.so.10)
   at Flux2.getRadioMetaData(Flux2.java:237)
   at Flux2.connect(Flux2.java:214)
   at FluxFeeder.run(FluxFeeder.java:21)

au énième appel de hasNextLine sur un parseur a priori impeccable, mais qui est simplement arrivé au bout de la chaine sur laquelle il travaille. J'aurais volontiers fait un vrai "bug report" aux responsables de la maintenance de la libgcj.so.10, mais on dirait bien que la politique d'Ubuntu s'est encore dégradée à ce sujet. Non content de répondre régulièrement "ah oui, on arrangera ça dans la version suivante" lorsqu'ils ont choisi une version incomplète ou buggée d'un programme mais que des correctifs existent chez le développeur (j'en veux pour preuve ce problème dans desmume), même lorsque la distribution affectée est une Long Term Support.
Enfin ... on va essayer quand-même.