#define atoi(str) Integer.parseInt(str)

J'ai beau essayer, essayer encore, y mettre de la bonne volonté, je ne comprends pas comment la version Java "Integer.parseInt(...)" peut être préférable à ma bonne vieille A(scii)TO()I(nteger). Les programmeurs sont supposés être des spécialistes. Celui qui trouve que strlen(itoa(42)) est obscur doit tout simplement pratiquer davantage et pas écrire un langage dans lequel il faille écrire new Integer(42).toString().length(), si ?

Je risque un deuxième coup de gueule contre Java the Hutt... Qui a été bourrer le crâne des gens au point que je me retrouve avec une classe Instances qui gère un vecteur de Instances, mais en donnant de nouveaux noms (numInstances(), enumerateInstances(), addInstance()) ? Hmmm ? Personne ne se dénonce? Eh bien vous serez tous privés de stdout! Tant pis pour vous.

J'ai peut-être bien été trop entrainé en secondaire à retenir "le sens" des choses plutôt que de retenir par coeur des phrases toutes faites ... Quant à dire que Java est le "langage plus simple qui crie pour sortir de C++", bin sorry, mais je ne ferai pas le pas: mes petits outils de conversion, ils resteront en PERL.

Bon, c'est pas tout ça, 'faut que je me replonge sur ce programme. Oh. length() n'est pas une méthode des tableaux, mais une ... euh. Une quoi, au fait? Rien d'autre dans Java ne semble se comporter de la même manière que args.length.

Tout n'est pas noir, dans Java, mais tout n'est pas rose non plus. Ils nous ont ajouté à la version 5 l'équivalent du foreach du PERL ... sympa et concis. Sauf que ça ne marche que sur les Iterators, qui avaient été introduits en remplacement des Enumeration -- dont les noms de méthodes avaient alors été jugés trop longs. Alors c'est vrai que getNextElement(), ça ne m'a jamais épaté, mais du coup, si j'utilise une bibliothèque (Weka ?) qui est restées aux Enumerations, je ne peux pas me servir de foreach >_<.

M'enfin !?

Nous avons donc dans java.io.File une classe qui ne permet en aucune manière d'accéder au contenu du fichier, ou je me trompe ? Pas une référence à Reader ou à InputStream !?

Si l'idée était d'avoir "une représentation abstraite d'un nom de fichier/répertoire", quelqu'un peut m'expliquer pourquoi ce truc ne s'appelle pas java.io.FileName ? Je prie pour le rétablissement de tous ceux qui trouvent ça normal, parce qu'ils ont dû se chopper un sérieux coup de soleil ...

Yeah, that's another Java rant. If you're wondering how on Arrakis you would get the content of that java.io.File object you just created, welcome aboard! Don't panic and open the javadoc for FileReader or FileInputStream instead, because noone at Sun thought you'd be happy to be notified those classes exists. Not even after +10 years of confused readers! Seriously, dudes, socket.getInputStream(), but new FileInputStream(file)?

bad IDEa

on dira ce qu'on veut, moi quand je croise

Logger.getLogger(DimLocalHandler.class.getName()).log(Level.INFO,
                 "Further improvement possible.");

dans du code, je me dis que même si ça a été facile à écrire (auto-complétion-power), ça reste lourd, c'est moche et ça encombre l'esprit de celui qui raisonne à propos du code. Et encore, il aura fallu importer java.util.logging.Level, pour pouvoir "raccourcir" en Level.INFO, j'imagine

On a pas droit à @INFO("Further improvement possible") ?

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.

Java pas m'énerver ...

Quand il s'agit de manipuler un document XML, moi, mon interface préférée, c'est XPath. Pas besoin de code bien compliqué: on fait comme si tous les éléments étaient des petits fichiers dans une arborescence, et on donne un chemin pour trouver les éléments qui nous intéressent. J'avais déjà pu m'en servir avec succès en PERL, je m'attendais à quelque-chose d'ultra-simple en Java, langage de l'XML par excellence.

J'y vais donc de mon petit test débile:

import java.lang.*;
import java.util.*;
import javax.xml.xpath.*;
import org.xml.sax.InputSource;

public class XpathTest {
 public static void main(String[] args) {
try {
    System.err.println("creating xpath...");
    XPath xpath = XPathFactory.newInstance().newXPath();
    String expression = args[0];
    InputSource src =
 new InputSource(new java.io.FileInputStream(new java.io.File(args[1])));
    System.err.println("search for "+args[0]);
    String content = xpath.evaluate(expression, src);
    System.out.println("here: "+content);

    xpath.reset();
    src = new InputSource(new java.io.FileInputStream(new java.io.File(args[1])));
    Object node = xpath.evaluate(expression, src, XPathConstants.NODESET);
    System.out.println("here: ("+node+")");
} catch (javax.xml.xpath.XPathExpressionException ex) {
    System.err.println("oops: "+ex);
} catch (java.io.FileNotFoundException ex) {
    System.err.println("no file : "+ex);
} catch (java.io.IOException ex) {
    System.err.println("doh: "+ex);
}
 }
}

Tout ça à l'aide de la première référence que je trouve: la doc de sun bien claire, sauf sur un point "c'est quoi cette 'nodelist' que je suis supposé recevoir mais qui m'est transmise sous la simple forme d'un 'Object' ?". Au bout de quelques minutes de tests, je me rends compte que la seule chose qui marche, c'est le chemin "/" qui reprend tout le texte du document. le reste ("/feed/entry[1]/title" ou "//author", ce genre de choses chouettes et utiles), ne donne aucun résultat. Pas une exception ou un message d'erreur. non. rien, tout simplement. que le chemin corresponde à un noeud existant dans le document ou pas, d'ailleurs.

grmbl.

Puis à force d'essayer, je finis par constater que le fameux objet que je récupère est de la classe com.sun.org.apache.xml.internal.dtm.ref.DTMNodeList.

Et là, je dis: ça pue. pourquoi m'ont-ils renvoyé un objet interne non-documenté et (de plus) qu'est-ce que c'est que ce "sun...apache..." ou bien c'est dans le standard, ou bien ça n'y est pas, non ?


allons bon ...

Xerces does not provide an XPath implementation (it implements only support for the limited expressions allowed by XML Schema constraints). Xalan provides an XPath 1.0 implementation and from the com.sun.org.apache... package name it seems there is the Sun (derived from Xalan) implementation that is included with the JVM.ref

Tout de suite, ça m'étonne moins. Reprenons calmement avec la doc d'apache, donc.

1. on installe le package "xalan", un traducteur XSLT qui est sensé fournir XPath pour de vrai
2. on redéfini sa variable d'environnement CLASSPATH pour pointer sur /usr/share/java/xalan2.jar
3. on google sur "org.apache.xpath example" et pas "xpath java example"

Voyons voir. Ouais. des tonnes de Factory et docBuilder.parse() ... 'fallait s'y attendre. Et naturellement, rien n'aide dans le code java ou dans JavaDoc à retrouver comment il serait bien possible de construire un objet de telle ou telle classe à partir d'un nom de fichier, ce qui rend toujours les tutoriels Java pénibles (très 'magie noire', si vous voyons c'que j'voulions dire).

Bref, le code le plus simple auquel j'arrive ressemble à ceci:

import org.apache.xpath.*;   // for XPathAPI, obviously!
import org.apache.xpath.objects.*; // for items, nodelists, etc. (XObject)
import org.w3c.dom.*;        // for Document and friends
import java.lang.*;          // for String and the like.

/** see also:
http://xml.apache.org/xalan-j/apidocs/javax/xml/parsers/DocumentBuilder.html
*/
class xpath2 {
   public static void main(String args[]) {
Document doc=FileToDoc(args[0]);
String xpath = args[1];
System.out.println("\nQuerying DOM using xpath string:" + xpath);
try {
    XObject o = XPathAPI.eval(doc, xpath);
    System.out.println(o.getTypeString()+"> "+o);
} catch (Exception e) {
    System.err.println("doh:" +e);
}
   }
}

mais pour ça, il me faut écrire une horrible fonction capable de passer d'un nom de fichier à un Document, parce que visiblement, les gens qui ont écrit XPathAPI n'ont pas pensé à rendre ce cas-là simple :(

    static Document FileToDoc(String fname) {
/* well, Document is an interface and cannot be built simply */
/*                       -- grmbl --                         */
try {
    javax.xml.parsers.DocumentBuilderFactory docBuilderFactory =
       javax.xml.parsers.DocumentBuilderFactory.newInstance();
    javax.xml.parsers.DocumentBuilder docBuilder =
       docBuilderFactory.newDocumentBuilder();
   
    // Parse the XML file and build the Document object in RAM
    return docBuilder.parse(new java.io.File(fname));
} catch (Exception e) {
    System.err.println("parse error: "+e);
    return null;
}
   }

Notez que si vous avez déjà un InputStream prêt sur le contenu (p.ex. une connexion réseau), inutile de passer par un fichier: docBuilder.parse(InputStream) existe également. Il y a même docBuilder.parse(URL) pour ceux qui ne sont pas occupés à faire un exercice sur l'écriture d'un client HTTP :P
(soupir)

Et pour être sûr, ils ont *aussi* rendu la réécriture de documents XML vers un fichier tordue:

 import javax.xml.transform.*;
import javax.xml.transform.dom.*;
import javax.xml.transform.stream.*;
TransformerFactory transformerFactory = TransformerFactory.newInstance();
Transformer transformer = transformerFactory.newTransformer();
DOMSource source = new DOMSource(document);
StreamResult result =  new StreamResult(System.out);
transformer.transform(source, result);

Pour la postérité, la javadoc de l'API XPath sur le projet Apache.