Mercredi 7 mars aura lieu la 2ème session Hackergarten. Après Soat, on a le plaisir d’être hébergé par Valtech (103 Rue de Grenelle, 75007 Paris) et il y aura des pizzas, gros merci à eux.

Hackergarten c’est le rendez-vous des gens qui veulent participer aux projets opensource. L’idée c’est, dans un format de 3h, de contribuer un logiciel, un fix, un feature, une documentation dont d’autres pourraient avoir l’usage. Il s’articule autour de commiters actifs pour mentorer les hackers qui participent à l’évènement.

Bref que du bon. Pour la planification de l’évènement c’est par là ⇒ http://hackergarten-paris.eventbrite.com/

Alors pour éviter les soucis de setup le jour J, ce post donne quelques informations sur ce qu’il y aurait à récupérer ou faire en avance sur votre machine. Si vous avez des questions ou si vous voulez participez aux discussions : inscrivez vous sur la mailing-list à cette adresse ⇒ http://groups.google.com/group/hackergarten-paris/

Hibernate OGM / Hibernate Search ⇐ mentoré par Emmanuel Bernard

IDE : IntelliJ mais Eclipse fait l’affaire

Pour builder : Maven 3.0.3
JDK 1.6 recommandé
changer les ~/.me/settings.xml selon https://community.jboss.org/wiki/MavenGettingStarted-Users

Installer Cassandra 1.0.8 (download sur Apache)
Et pour les motivés NoSQL, installer votre moteur préféré aussi histoire de contribuer un dialect pour Hibernate OGM

Forker + cloner localement
- git clone https://github.com/hibernate/hibernate-search
- git clone https://github.com/hibernate/hibernate-ogm

Cloner
- git clone https://code.google.com/a/apache-extras.org/p/cassandra-jdbc/

Lancer mvn clean install sous chacun des clones pour être sûr que Maven télécharge bien la terre.

Maven / Jenkins ⇐ mentoré par Arnaud Héritier

IDE : Pour Maven & Jenkins : IntelliJ ou eclipse + m2e versions recentes si possibles

Git pour Jenkins, SVN pour Maven

Pour builder :  Maven 2.2.1 min, 3.0.x serait un mieux
(De memoire pas de settings additionnels pour seulement builder)

Infinitest ⇐ mentoré par David Gageot

Lancer mvn dependency:go-offline pour récupérer toutes les dépendances

Mockito ⇐ mentoré par Brice Dutheil

IDE : IntelliJ en particulier, la version Community suffira. Eclipse peut faire l’affaire. Attention on a eu des soucis avec Netbeans la dernière fois.

Pour Builder : Ant (IntelliJ contient un Ant)
JDK 5 préféré, mais pas obligatoire.

Forker et cloner localement depuis Google code : http://code.google.com/p/mockito/source/checkout
Attention ici c’est du mercurial.

Il n’y a plus qu’à ouvrir les fichiers du projet.

FluentLenium ⇐ mentoré par Mathilde Lemée

IDE : Un IDE qui gère maven, genre IntelliJ.

Pour Builder : Maven

Checkout depuis : https://github.com/FluentLenium/FluentLenium

Votre projet

Et oui si vous avez une idée à coder en Open Source et que vous cherchez des intéressés c’est peut-être l’endroit pour en parler et dresser un plan

1000 mercis

Gros merci à tous ceux qui participent aux Hackergarten Paris

• Arnaud Héritier
• Guillaume Laforge
• Emmanuel Bernard
• David Gageot
• Eric Lefevre
• Mathilde Lemée
• Et vous tous qui venez

Gros merci aussi à ceux qui hébergent l’évènement, c’est bien sympa :

• Soat
• Valtech

Évidement merci à Hamlet D’Harcy pour avoir initier l’idée là bas en Suisse

Après pas mal de travail avec des périodes plus ou moins intenses – bref les vicissitudes du développement Open Source – le projet sort une nouvelle version 1.9.0 en Release Candidate, avec des bugfixes et bien sûr des nouvelles features. Il y a un changelog mais dans les faits le billet suivant liste brièvement ce qui est nouveau. Ah oui la version est téléchargeable ici et bientôt disponible sur le central maven.

• Pour être plus fluent et expressif, l’API introduit les alias then et will pour les réponses personnalisées (Answer). Ainsi que d’autres petits tweak de l’API:

  @Test
  public void engine_should_only_work_with_diesel() {
    given(engine.start()).will(throwExceptionIfEssenceInsteadOfDiesel());
    // ...
  }
  
  private Answer throwExceptionIfEssenceInsteadOfDiesel() {
    return new Answer<EngineStatus>() {
      public EngineStatus answer(InvocationOnMock invocation) {
        // answer code
      }
    };
  }

• Les mocks peuvent maintenant être déclaré dans la configuration du stub, sur une ligne.

  DieselEngine de = given(mock(DieselEngine.class).start()).willThrow(TankIsEmpty.class).getMock();

• On peut maintenant renvoyer la classe d’une exception plutôt que son instance.

  given(someMock).willThrow(IllegalArgumentException.class, SomethingIsWrongException.class);

• Si jamais vous avez besoin de debugguer un bout de code ou les interactions sont non prédictibles, il est maintenant possible de loguer les invocations du mock ou de l’espion. Attention, bien qu’utile à l’occasion avec du code legacy, quand même si jamais ce besoin s’en fait sentir sur un nouveau développement c’est que ce code devient trop complexe.

  List mockedList = mock(List.class, withSettings().verboseLogging());
  mockedList.get(0);

  On pourra également ajouter des callbacks sur chaque interaction du mock.

  Observer observer = mock(Observer.class, withSettings().invocationListeners(listener1, listener2));
  willThrow(IllegalArgumentException.class).given(observer.update(observable, "what has changed"));

• Pas mal de travail a été fait sur les annotations. Maintenant il n’est plus nécéssaire d’initialiser un champ annoté par @Spy s’il existe dans la classe un constructeur sans argument.

  @RunWith(MockitoJUnitRunner.class)
  public class SomeTest {
    // pas besoin d'initialiser le champs
    @Spy private ArrayList spiedArrayList;
  
    @Test public void verify_some_interactions() {
      spiedArrayList.iterator();
      verify(spiedArrayList, once()).iterator();
    }
  }

• Et pour la fin mais pas des moindres, le mécanisme d’injection de mockito supporte maintenant l’injection par constructeur. A l’heure actuelle, seul les mocks et spies déclaré dans le test en tant que champs pourront être injecté dans le constructeur du champs annoté par @InjectMocks.

  @RunWith(MockitoJUnitRunner.class)
  public class EngineTest {
    @Mock Diesel diesel;
    @InjectMocks Engine engine;
  
    @Test public void engine_should_consume_Diesel() {
      engine.start();
    }
  }

  Ou Engine a un constructeur avec le paramètre Diesel.

  public class Engine {
    Diesel diesel;
    public Engine(Diesel diesel) {
      this.diesel = diesel;
    }
  
    public boolean start() {
      checkNotEmpty(diesel);
      // ...
    }
    // ...
  }

Pour l’instant en RC, cette release permettra d’adoucir les angles si nous en avons loupé certains éléments. N’hésitez pas à nous poser des questions sur la mailing list ou stackoverflow.

Pour ça je me suis créé dans mon IDE favori, IntelliJ, ce qu’on appelle des Live Template. Ces templates permettent à partir d’une abréviation d’insérer des fragments de code. Ainsi par exemple :

Taper iter dans votre éditeur puis de faire Ctrl+J (sous OSX) va développer cette abréviation dans le bout de code ci-dessous (suivant le contexte bien entendu)

for (TypeInIterable type : someIterable) {

}

Taper sur Ctrl+J (sous OSX) vous permet de lister les abréviations disponible dans le contexte courant.

Les Live Template pour Mockito

Bien qu’imparafaite pour des raisons de limite technique d’IntelliJ, elles sauvent un minimum de temps, multiplié par le nombre de test. Malheureusement il n’y a pas non plus d’import export uniquement pour les live template, il faut donc se taper la configuration de intellij à la main. Cela dit il est possible de contourner partiellement ce problème avec la sauvegarde de la configuration personnelle sur les serveurs intellij, ou encore d’exporter la configuration pour les live templates, les file templates, et encore autre chose.

J’ai défini toutes ces annotations dans un nouveau groupe ‘test’, et j’ai activé pour toutes le contexte Java, avec reformatage et simplification du nom qualifié.

1. Description : Creates a field with the @Mock annotation
   Abbréviation : ‘am’
   Template text :

   @org.mockito.Mock private $TYPE$ $MOCK_FIELD$
   

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   TYPE	variableOfType(“Object”)
   MOCK_FIELD	suggestVariableName()

2. Description : Creates a field with the @Spy annotation
   Abbréviation : ‘as’
   Template text :

   @org.mockito.Spy private $TYPE$ $MOCK_FIELD$
   

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   TYPE	variableOfType(“Object”)
   MOCK_FIELD	suggestVariableName()

3. Description : Creates a field with the @InjectMocks annotation
   Abbréviation : ‘aim’
   Template text :

   @org.mockito.InjectMocks private $TYPE$ $MOCK_FIELD$
   

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   TYPE	variableOfType(“Object”)
   MOCK_FIELD	suggestVariableName()

4. Description : Add @RunWith(MockitoJUnitRunner.class)
   Abbréviation : ‘rwm’
   Template text :

   @org.junit.runner.RunWith(org.mockito.runners.MockitoJUnitRunner.class)
   

5. Description : BDD Stub mock with given(…).willReturn(…) style
   Abbréviation : ‘gw’
   Template text :

   given($MOCK$).willReturn($ARGS$)$END$
   

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   MOCK	variableOfType(“Object”)
   ARGS

6. Description : BDD Stub spy/mock with willReturn(…).given(…) style
   Abbréviation : ‘wg’
   Template text :

   org.mockito.BDDMockito.willReturn($RETURNED$).given($MOCK$).$CALL$ $END$
   

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   RETURNED	complete()
   MOCK	variableOfType(“Object”)
   CALL	complete()

7. Description : Inserts a verify(…) statement
   Abbréviation :‘verif’
   Template text :

   org.mockito.Mockito.verify($MOCK$).$CALL$
   

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   MOCK	variableOfType(“Object”)
   CALL	complete()

8. Description : Inserts Mockito.inOrder(mocks) followed by inOrder.verify(…) statement
   Abbréviation : ‘ioverif’
   Template text :

   org.mockito.InOrder $inOrderVar$ = org.mockito.Mockito.inOrder($MOCKS$);
   $IN_ORDER_VAR$.verify($MOCK$).$CALL$;
   

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   IN_ORDER_VAR	suggestVariableName()
   MOCKS	variableOfType(“Object”)
   MOCK	variableOfType(“Object”)
   CALL	complete()

9. Description :Inserts a verify(…) statement
   Abbréviation :‘verif’
   Template text :

   $IN_ORDER_VAR$.verify($MOCK$).$CALL$;
   

   Les variables du templates sont :

   Name	Expression	Default value	Skip if defined
   IN_ORDER_VAR	variableOfType(“org.mockito.InOrder”)
   MOCK	variableOfType(“Object”)
   CALL	complete()

Voilà donc les templates que je me suis créé pour IntelliJ, il manque certainement des cas d’utilisation, mais je trouvais plus judicieux de mettre ces cas là au moins. Pour nos amis Eclipse oou Netbeans, il y a des fonctionnalités comparables plus ou moins évoluées (de mémoire le système d’Eclipse est plutôt pas mal).

Références

• Live Templates

Il faut ajouter dans la section build/plugins du pom une tache ant qui efera simplement un echo. A noter que cette tache est disponible dans la phase validate.

<build>
<plugins>

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.1</version>
        <executions>
            <execution>
                <phase>validate-property</phase>
                <goals>
                    <goal>run</goal>
                </goals>
                <configuration>
                    <tasks>
                        <echo>Displaying properties resolution</echo>
                        <echo>some.property]= ${some.property}</echo>
                        <echo>project.build.directory = ${project.build.directory</echo>

                        <echo>project.build.finalName= ${project.build.finalName}</echo>
                    </tasks>
                </configuration>
            </execution>
        </executions>
    </plugin>

</plugins>
<build>

Cela dit n’étant pas un expert maven, il y existe peut-être une solution plus élégante, un commentaire est le bienvenu dans ce cas.

Première approche; vous enregistrez vos MBean sur un MBeanServer, disons celui de la plateforme (avec Java 6 : ManagementFactory.getPlatformMBeanServer()).

mBeanServer.registerMBean(theMBean, theMBean.getObjectName());

Étant donné que MBeanServer étends MBeanServerConnection il est possible d’exécuter des querys, de faire des invocations sur les MBean etc. Si le code est suffisamment isolé des aspects techniques de connexion à JMX, vous passerez le MBeanServer en lieu et place de la MBeanServerConnection.

Supposons le code suivant.

public class OperateOnJMXConnection implements JMXOperation {

    public void perform(MBeanServerConnection connection) {
        // doing some stuff there
    }

    public Result getResult() { return result; }
}

Pour tester ce code il faudrait alors écrire :

@Test
public void do_not_fail() {
    operateOnJMXConnection.perform(mbeanServer);

    assertThat(result).satisfies(someCondition);
}

Mais voilà, vous restez en local, et par exemple si vous avez merdé sur la sérialisation de vos beans, vous ne verrez pas d’échec dans vos test et vous aurez une surprise en prod, ou avant si votre projet a un processus qualité décent.

Évidement il y a une solution, l’idée c’est de pouvoir se connecter au mBeanServer local à votre processus (typiquement dans maven 3, l’exécution de vos tests peuvent être forkée).

Alors j’ai essayé de récupérer les informations pour récupérer les informations de la VM qui tourne, mais bon on tombe dans des classes sun, j’ai préféré ne pas continuer sur ce chemin semé d’embûches, sans compter sur la faiblesse de cette approche.

Bref en relisant les articles de Khanh sur JMX, j’ai vu quelque chose d’intéressant JMXConnectorServerFactory. Cette classe permet donc de créer un JMXConnectorServer avec l’URL qu’on lui spécifie et d’un MBeanServer. A noter que cette URL doit respecter un certain formalisme tel que la javadoc l’indique : service:jmx:protocol:remainder.

Le protocole ne peut pas être n’importe quoi, il faut qu’il y ait le bon service enregistré pour qu’il soit géré. Dans notre cas RMI est standard, c’est donc le protocole que je prendrai. Pour le remainder, il s’agit plus d’une partie d’une URL, je vous laisse voir la Javadoc de JMXServiceUrl à ce sujet, mais dans les grandes lignes la forme doit être la suivante :  //[host[:port]][url-path]

JMXConnectorServer connectorServer = JMXConnectorServerFactory.newJMXConnectorServer(
new JMXServiceURL("service:jmx:rmi://"),
null,
mBeanServer
);

connectorServer.start();

Hop dans le code précédent, on a créé puis démarrer notre JMXConnectorServer. Il n’y a plus qu’à se connecter dessus de manière standard :
Je vais utiliser connectorServer.getJMXServer() pour récupérer l’URL du service, il y a une raison à cela, c’est que comme l’indique la javadoc, l’URL passée pour la création du JMXConnectorServer peut être légèrement modifiée par celui-ci, il faut donc récupérer la nouvelle URL.

JMXConnector jmxConnetor = JMXConnectorFactory.connect(connectorServer.getJMXServiceUrl());
MBeanServerConnection connection = jmx.getgetMBeanServerConnection();

Et voilà vous avez accès à une MBeanServerConnection, qui vit dans la JVM locale, mais qui utilise RMI pour communiquer avec le MBeanServer, du coup vous êtes nettement plus proches des conditions du code de production et c’est ce qui nous intéresse dans cet article.

Pour référence les articles de Khanh, et en français s’il vous plait :

• Partie 1 : http://jetoile.blogspot.com/2010/10/jmx-pour-les-nuls-les-concepts-partie-1.html
• Partie 2 : http://jetoile.blogspot.com/2010/11/jmx-pour-les-nuls-les-differents-mbeans.html
• Partie 3 : http://jetoile.blogspot.com/2010/11/jmx-pour-les-nuls-les-agents-jmx-partie.html
• Partie 4 : http://jetoile.blogspot.com/2010/11/jmx-pour-les-nuls-les-classes-de-base.html
• Partie 5 : http://jetoile.blogspot.com/2010/11/jmx-pour-les-nuls-le-mbean-server.html
• Partie 6 : http://jetoile.blogspot.com/2010/12/jmx-pour-les-nuls-chargement-dynamique.html
• Partie 7 : http://jetoile.blogspot.com/2010/12/jmx-pour-les-nuls-les-services-jmx.html
• Partie 8 : http://jetoile.blogspot.com/2010/12/jmx-pour-les-nuls-les-connecteurs.html

Quelques liens javadoc :

• JMXConnectorFactory
• JMXConnectorServerFactory
• JMXServiceURL
• JMXConnectorServer

Enfin je me suis créé une petite classe de commodité qui permet de créé facilement un loopback pour les TU :

http://support.apple.com/kb/DL1421

Bon ça fait une chose de plus pour nous ennuyer, mais bon comme toujours pour ceux qui veulent bosser sur un JDK 1.5, il vous faudra tricher un peu plus, il n’y a pas de mise à jour standard ou facile pour installer le JDK 5 sur 10.7.

Certains ont trouvé l’astuce en téléchargeant la mise à jour Java pour Mac OS X 10.5, et avec quelques outils et commandes dans le terminal. Cela dit le processus est un poil long. Du coup je me suis codé un petit script pour automatiser ces étapes. Pour l’instant le script repose sur un téléchargement manuel de cette mise à jour.

1. En premier on télécharge la mise à jour du JDK5 ici :
   

   http://support.apple.com/kb/DL1359

2. Ensuite dans le même répertoire on y téléchargera le script
3. Dans un terminal dans le dossier du téléchargement

   chmod +x install_jdk5_lion.sh

4. Il faut être root, attention quand même, le script fonctionne sur les environnements Lion que j’ai pu testé, mais il peut très bien casser votre système, déclencher un tempête ou je ne sais quoi encore… je ne garantis rien.

   sudo -s

5. Bref il se lance comme ça :

   ./install_jdk5_lion.sh

6. Si tout se passe bien alors, les préférences Java de Mac s’ouvriront en listant le JDK 5.
7. exit

En images, ça donne :

Evidement si vous repérez une coquille, je suis à l’écoute. Bonne soirée

EDIT 29/08/2011: Tant qu’à faire autant montrer comment avoir plusieurs JDK dans IntelliJ sous macosx.

1. Donc une fois le projet ouvert, il faut aller dans les préférences du projet (Project Settings).
   
2. Ensuite ajouter le JSDK.
   
3. Puis sélectionner dans l’explorateur le dossier /System/Library/Java/JavaVirtualMachines/1.5.0/Contents/Home
   
4. Hop, c’est fini, dans IntelliJ vous avez le JDK 5
   

Idée originale : Zend Studio 5.x for OS X Lion (Java SE 6)

Sources : 

• Le premier, dans la continuité des groupes ce sont les constructions de look behind et look ahead.
• Le deuxième point abordera le support de Unicode dans nos expressions régulières.

Avoir le coup d’œil

C’est bien de ça dont il s’agit; ce feature, introduit grâce aux groupes non-capturant, permet de vérifier si une autre expression matche avant ou après une expression capturante  sans consommer de caractères. Il y a 4 constructions de types :

• Les constructions look ahead

1. 1. (?=X) X, via zero-width positive lookahead : L’expression cherche à matcher X après la position courante et sans consommer.
   2. (?!X) X, via zero-width negative lookahead : L’expression cherche à ne pas matcher X après la position courante et sans consommer.

• Les expressions look behind

1. 1. (?<=X) X, via zero-width positive lookbehind : L’expression cherche à matcher X avant la position courante et sans consommer, ou X est une expression régulière de longueur connue.
   2. (?<!X) X, via zero-width negative lookbehind : L’expression cherche à ne pas matcher X avant la position courante et sans consommer, ou X est une expression régulière de longueur connue.

Ces assertions ressemblent aux bornes b elles ont un fonctionnement similaire mais plus complexes. Passons aux tests pour voir leur fonctionnement.

Les groupes de look ahead

Par exemple avec le look ahead positif :

public class LookAheadLookBehind {

    private String text = "static private String aStaticVarLabel;" +
            "static private Long anotherStaticVarLabel;" +
            "private String anInstanceVar;" +
            "protected String anInteger;";

    @Test
    public void classicRegex() {
        assertEquals("aStaticVarLabel", regexMatch(text, "\w+Label"));
    }

    @Test
    public void positiveLookAhead() {
        assertEquals("aStaticVar", regexMatch(text, "\w+(?=Label)"));
    }

    private String regexMatch(String text, String regex) {
        Matcher matcher = Pattern.compile(regex).matcher(text);

        return matcher.find() ? matcher.group(0) : "";
    }
}

Ligne 10, on veut chopper les lignes qui se terminent par “Label” avec une expression usuelle. Si on ne voulais pas la partie “Label”, alors il aurait fallu créer un autre groupe autour de w+, cependant le curseur aura consommé les caractères. L’alternative est d’utiliser un look ahead positif, c’est ce qu’on a à la ligne 15, ici le curseur s’arrête après le “r” juste avant “Label”.

Notez que dans l’exemple ce qui est retourné est le groupe 0 (ligne 21), c’est à dire l’ensemble de ce qui est capturé par toute la regex. Ceci illustre à nouveau que les groupes de look ahead/begind ne capturent pas (méthode positiveLookAhead, ligne 15). C’est assez pratique pour faire des sélections ou des remplacements, dans Eclipse par exemple.

Si typiquement on cherche des termes qui ne se terminent pas par “Label”. On écrira simplement :

@Test
public void negativeLookAhead() {
    assertEquals("private", regexMatch(text, "\w+(?!Label)"));
}

L’expression chope en premier “private”, tout simplement parce que cette partie du texte matche le fait qu’il n’y a pas Label qui suit, si on veut chopper le nom d’une variable alors on peut ajouter des constructions de look behind. C’est ce qu’on regarde juste après.

Les groupes de look behind

@Test
public void positiveLookBehind() {
    assertEquals("anotherStaticVarLabel", regexMatch(text, "(?<=private Long )\w+"));
}

Donc là j’ai préfixé la regex par ce que je voulais voir juste avant. De la même manière si on ne veut pas d’un terme, on utilisera un look behind négatif (?<!), par exmple si on ne veut pas de “String”.

@Test
public void negativeLookBehind() {
    assertEquals("anotherStaticVarLabel", regexMatch(text, "(?<=private \w{4,8} )(?<!String )\w+"));
}

Observez ici qu’il y a deux constructions adjacentes look behind, l’une positive l’autre négative, ce qui illustre encore mieux que ces constructions ne consomment pas la séquence de caractères.

Observez également que l’expression ici est de longueur connue : le w{4,8} ne prend que de 4 à 8 caractères. Il n’est pas possible d’écrire un look behind avec un quantificateur où la longueur n’est pas connue, la construction suivante est fausse et provoquera une erreur de syntaxe : (?<!private w+ ). C’est une limite technique qui impose aux groupes de look behind d’avoir une longueur fixe ou calculable; le quantificateurs borné {n,m}, l’option ? ou l’alternative | tombent dans cette catégorie. Ainsi on pourrait écrire :

@Test
public void negativeLookBehind() {
    assertEquals("anotherStaticVarLabel", regexMatch(text, "(?<=(?:static )?private long|Long )\w+"));
}

Et donc par opposition les quantificateurs * et + ne sont pas autorisés.

Attention aux quantificateurs sur une même classe de caractère

Bon, il existe certains cas un peu délicats ou les caractères adjacents d’une séquence font partie de la même classe. Dans le bout de texte utilisé dasn le premier exemple, les nom variables correspondent typiquement à ça:

anotherStaticVarLabel

Le nom de la variable appartient à la classe de caractère [a-zA-Z0-9_] ou encore à w.

Lorsqu’on faisait un positive look ahead, le quantificateur w+ va chercher à matcher l’ensemble des caractères de cette classe, ce qui veut dire que w+ va matcher et consommer les caractères “anotherStaticVarLabel”. Du coup lorsque la construction (?=Label) cherche à matcher “Label”, elle n’y arrive pas. Ce n’est pas grave, avec le backtracking l’expression w+ reviens en arrière jusqu’à ce que (?=Label) matche.

L’histoire est différente avec un negative look ahead; une fois que la partie w+ a matché “anotherStaticVarLabel”, le curseur est positionné après le “l”. Maintenant le moteur teste (?!Label), qui cherche donc à ne pas matcher “Label”, normal c’est une négation. Et là ça marche, cette partie de l’expression ne peut plus trouver “Label”, donc la construction est validée.

Bref ce n’est pas ce qu’on veut, nous voulons par exemple identifier les variables qui ne sont pas suffixées par “Label” !

Pour ne éviter ce problème, il faut placer le groupe look ahead négatif avant w+. Cela ne posera pas de problème étant donné que les look ahead ne consomment pas la séquence de caractères. Ainsi en écrivant :

@Test
public void controlYourQuantifiers() throws Exception {
    assertEquals("anInstanceVar", regexMatch(text, "(?<=String )(?!\w+Label)\w+"));
}

La première partie est un look behind pour avoir ce qui est après “String “, le deuxième groupe est le look ahead dont je parlais, ce groupe cherche à ne matcher w+Label, si les derniers caractères Label de la regex ne sont pas trouvés alors c’est bon. Finalement l’expression se termine par w+. L’astuce donc se fait en deux étapes:

1. Déplacer le look ahead avant l’expression qui consomme les caractères et qu’on veut capturer, ici w+
2. Faire précéder dans le look ahead négatif l’expression qu’on veut capturer, ici le groupe est devenu (?!w+Label), grâce au backtracking dans ce groupe une valeur “aStaticVarLabel” ne sera pas matchée (negative look ahead).

Voilà pour les possibilités de look ahead et de look behind dans les expressions rationnelles.

Passons maintenant au support Unicode par la classe Pattern.

Unicode

En quoi Unicode est intéressant dans nos regex en Java?

1. Unicode est supporté nativement par Java, le format interne des String est Unicode.
2. Unicode nous apporte des classes, des catégories ou des propriétés de caractères bien plus étendues que les classes ASCII couramment utilisées.

Juste pour une lettre

Par exemple, j’ai une application US qui vérifie que le texte entré est uniquement composé de lettres. Facile avec la regex suivante:

[a-zA-Z]

Maintenant je me dit que je souhaiterais avoir des clients français! Aille! L’approche facile mais peu élégante est d’écrire une regex dans ce genre :

[a-zA-Zéèêïôàù]

Et encore j’oublie les accents sur les majuscules et encore d’autre caractères spéciaux, alors qu’ils ont pourtant pleine valeur orthographique sur les majuscules également. S’il fallait en plus gérer le grec, l’allemand, l’espagnol, nous aurions du mal avec une telle expression régulière. Et le raccourci w n’aide pas vraiment non plus! C’est là que viennent les classes de caractère Unicode, pour identifier un caractère qui est une lettre, on écrira très simplement :

p{L}

Ainsi en Java on aura par exemple

@Test
public void matchLettersInDifferentLanguage() throws Exception {
    Assert.assertTrue(Pattern.matches("(\p{L}| )+", "une manœuvre sur un chêne"));
    Assert.assertFalse(Pattern.matches("[\p{Lower} ]+", "une manœuvre sur un chêne")); // Attention p{Lower} est une classe POSIX ou ASCII !
    Assert.assertTrue(Pattern.matches("[\p{Ll} ]+", "une manœuvre sur un chêne")); // Classe des petites lettres en Unicode p{Ll} !

    Assert.assertTrue(Pattern.matches("[\p{L} ]+", "eine kleine Straße in München"));

    Assert.assertTrue(Pattern.matches("[\p{L} ]+", "Это настоящая красота"));
}

IntelliJ est très bien, il fourni l’auto-complétion dans les regex c’est assez pratique à l’intérieur du code, mais pas d’explication sur la signification de ces blocs de caractères Unicode. Eclipse n’en parlons pas, et NetBeans je ne sais pas. En tous cas on trouve une réponse ici ou encore là à propos des blocs Unicode:

Matcher les caractère d’un alphabet seulement

Si je veux vérifier que mon texte appartient à de l’hébreu ou du chinois c’est faisable. Dans Unicode il faut remarquer qu’il y a plusieurs notion pour les “alphabets”; il y a les Blocs et les Scripts, cependant le moteur de Java qui se base essentiellement sur le moteur de perl, ne gère pas les scripts, donc on se contentera des blocs.

Ci-dessous je teste l’appartenance à un bloc :

@Test
public void matchABlock() throws Exception {
    Assert.assertFalse(Pattern.matches("(\p{InBASIC_LATIN}| )+", "une manœuvre sur un chêne"));
    Assert.assertTrue(Pattern.matches("(\p{InLATIN_EXTENDED_A}|\p{InLATIN_1_SUPPLEMENT}|\p{InBASIC_LATIN}| )+", "une manœuvre sur un chêne"));

    Assert.assertTrue(Pattern.matches("[\p{InLATIN_1_SUPPLEMENT}\p{InBASIC_LATIN} ]+", "eine kleine Straße in München"));

    Assert.assertTrue(Pattern.matches("[\p{InCYRILLIC} ]+", "Это настоящая красота"));
    Assert.assertFalse(Pattern.matches("[\p{InHEBREW} ]+", "Это настоящая красота"));

    Assert.assertTrue(Pattern.matches("[\p{InCJK_UNIFIED_IDEOGRAPHS} ]+", new String(Character.toChars(0x6C23)))); // chi écriture traditionnel
    Assert.assertTrue(Pattern.matches("[\p{InHIRAGANA} ]+", new String(Character.toChars(0x304D)))); // ki écriture Hiragana
}

Plusieures choses sont à remarquer :

• Le nom de l’alphabet est précédé par “In“
• Pour avoir une phrase en français on a très vite plusieurs blocs “LATIN EXTENDED A” pour le graphème ‘œ’, “LATIN 1 SUPPLEMENT” pour le ‘ê’ E accent circonflexe.
• D’autres alphabet sont plus pratique à utiliser comme l’hébreu, le cyrillique, le grecque, etc.
• L’utilisation des alphabet Chinois, Japonais, Coréen peut aussi soulever des question surtout quand on ne le parle pas

A noter également :

Sur les deux dernière lignes noter que j’ai utiliser le code hexadécimal UTF-16 (j’y reviendrais après) pour obtenir les caractères 氣 et き (Chi en chinois traditionnel, Ki avec l’alphabet Hiragana). Pourquoi? Parce que Unicode c’est bien joli mais dans le monde réel il y a des limitations, pour moi il s’agit de la police de caractère de mon éditeur qui ne possède pas ces blocs de caractères défini. Peut-être aurez vous des limitations sur la police de votre navigateur. A noter également que l’encodage de vos fichier peut faire mal quand on joue avec les caractères en dehors du latin basique.

Chi (0x6C23)	Ki (0x304D)

On peut encore s’amuser

Pour revenir dans les choses qui nous intéresse, imaginons que nous voulions compter tous les caractères accentués dans un texte. Le bloc Unicode p{L} n’est pas approprié, mais comme je l’ai dit avec Unicode on peut accéder aux propriété d’un caractère.

Déjà pour commencer il faut savoir qu’en Unicode, un graphème comme ‘é’ peut correspondre à un seul caractère ‘é’ ou à deux caractères ‘e’ suivi du modificateur accent grave. Cela dépend de la source, mais ces cas sont probables.

@Test
public void graphemes() {
    Assert.assertTrue(Pattern.matches("\p{InLATIN_1_SUPPLEMENT}+", "éèêu00E9"));
    Assert.assertFalse(Pattern.matches("\p{InLATIN_1_SUPPLEMENT}+", "eu0301"));
    Assert.assertTrue(Pattern.matches("(\p{L}\p{M})+", "eu0301"));
    Assert.assertTrue(Pattern.matches("(\p{InLATIN_1_SUPPLEMENT}|\p{L}\p{Mn})+", "éêeu0301u0065u0302"));
    System.out.println("éêeu0301u0065u0302");
}

Ainsi dans les lignes précédentes pour rechercher un graphème représenté par un seul codepoint, il faudra aller le chercher dans le bloc idoine, ici “LATIN 1 COMPLEMENT”, 0x00E9 est le codepoint du caractère ‘é’. La forme décomposée de ‘é’ est ‘e’ (0×0065) suivi du modificateur accent grave (0×0301).

Pour matcher cette forme décomposée du graphème, il faut simplement écrire p{L}p{M}. Il est toujours possible d’affiner l’expression en choisissant des propriétés plus précises (cf. Tableau plus haut, voire la référence Unicode). Du coup pour matcher n’importe quelle forme d’un graphème on pourra écrire l’expression de la ligne 6.

Enfin rapidement on peut exprimer les compléments à la manière standard avec [^p{Lu}] ou plus simple avec un grand P P{Lu}. Les intersections entres les classes / propriétés Unicode se font sans problèmes également :

@Test
public void complements() throws Exception {
    Assert.assertTrue(Pattern.matches("[^\p{Lu}]+", "une manœuvre sur un chêne")); // exclusion
    Assert.assertFalse(Pattern.matches("[^\p{Lu}]+", "Une Manœuvre sur un chêne"));
    Assert.assertFalse(Pattern.matches("\P{Lu}+", "Une Manœuvre sur un chêne")); // complément

    Assert.assertFalse(Pattern.matches("[[^\p{Lu}]&&\p{IsL} ]+", "une manœuvre sur un chêne 123164")); // exclusion et intersection
    Assert.assertTrue(Pattern.matches("[[^\p{Lu}]&&\p{IsL} ]+", "une manœuvre sur un chêne")); // exclusion et intersection
}

Petit retour sur les base de Java

Java gère nativement Unicode, les String sont encodées en UTF-16. Ce qui explique par conséquent que lorsque je veux exprimer un caractère sous forme hexadécimale, il faut l’écrire dans sa forme UTF-16.

@Test
public void utf16() throws Exception {
    Assert.assertTrue(Pattern.matches("u00E9", "é"));
    Assert.assertTrue(Pattern.matches("\u00E9", "é"));
    Assert.assertTrue(Pattern.matches("u00E9", new String(Character.toChars(0x00E9))));
    Assert.assertTrue(Pattern.matches("\u00E9", new String(Character.toChars(0x00E9))));
}

Ces assertions marches toutes mais il faut noter que u00E9 est compris par le compilateur et remplacera u00E9 par ‘é’, alors que dans la forme ou le backslash est échappé \u00E9 le compilateur ne fera rien. Ce sera au moteur Pattern de traiter la chaîne.

@Test
public void charLengthForCodePoint() throws Exception {
    Assert.assertEquals(1, Character.toChars(0x00E9).length); // é
    Assert.assertEquals(1, Character.toChars(0x304D).length); // ki
    Assert.assertEquals(2, Character.toChars(0x0001D50A).length); // MATHEMATICAL FRAKTUR CAPITAL G
}

La plupart des caractères tiendront dans le type primitif char qui fait donc 16 bits (voilà pourquoi Java gère nativement l’UTF-16) , cependant il peut arriver que certains caractères demandent davantage. Character.toChars(int) prend donc un codepoint représenté par en entier, qui fait en Java 32 bits pour exprimer Unicode en UTF-32 donc. Dans le code ci-dessus la 3ème assertion montre d’ailleurs que Java doit splitter le caractère en question sur deux char.

De la même manière l’encodage change naturellement la taille d’un tableau de byte (8 bits).

@Test
public void encodingDifferenceForAsciiChars() throws Exception {
    String string = "une chaine ascii";
    assertEquals(string.length(), string.getBytes("ASCII").length);
    assertEquals(string.length(), string.getBytes("UTF-8").length);
}

@Test
public void encodingDifferenceForAccentedChars() throws Exception {
    String string = "un chêne, un frêne, une orchidée";
    assertTrue(string.length() == string.getBytes("ASCII").length);
    assertEquals(string.length() + 3, string.getBytes("UTF-8").length);
}

Bilan

Voilà cet article clos la série que je voulais écrire sur les expressions régulière. Il y a probablement d’autres arcanes à connaître. Mais sur cette série le but était de couvrir ce que le moteur Java nous permet de faire. Je pense que comprendre le fonctionnement du moteur en particulier sur le backtracking, la manière du moteur de tester une expression, la manière dont le moteur parcoure / consomme les caractères en entrée, sont des facteurs clé pour réussir une bonne expression. Cette compréhension est d’autant plus importante quand celles-ci sont liée à des éléments de performance.

Les constructions apportées avec Unicode, même limitées, ouvrent certaines possibilités intéressantes, mais clairement il y a du travail à faire : Unicode n’est manifestement pas simple.

Références

• Le tutorial perl : http://perldoc.perl.org/perlretut.html
• La classe Pattern : http://download.oracle.com/javase/1.5.0/docs/api/java/util/regex/Pattern.html
• Unicode Regular Expressions: http://unicode.org/reports/tr18/
• Unicode Character Datablase : http://www.unicode.org/Public/5.1.0/ucd/UCD.html
• FileFormat, pour en savoir plus sur un certain caractère :  http://www.fileformat.info/info/unicode/char/search.htm
• Types primitifs en Java : http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html

• Les groupes qui ne capturent pas (non-capturing group)
• Les backreferences
• Les autres quantificateurs
  • Les quantificateurs gourmands (dits greedy quantifiers)
  • Les quantificateurs paresseux (dits lazy quantifiers ou comme le dit la javadoc de Pattern reluctant quantifiers)
  • Les quantificateurs possessifs (dits possessive quantifiers)
• Le backtracking

Certaines des constructions présentées ici démontrent que le moteur de regex de java fait partie des toutes dernières générations. Afin de mieux expliquer la manière de fonctionner des quantificateurs, je vais faire un tour sur la technique de backtracling du moteur de regex, feature essentiel pour faire fonctionner ces constructions.

Et aussi pourquoi certaines expressions régulières sont risquées en ce qui concerne les performances.

Les groupes qui ne capturent pas

Pour comparer voici les groupes capturant

Vous connaissez certainement déjà les groupes, par exemple :

public class Groups {
  private static final String mail = "brice [dot] dutheil [at] gmail [dot] com";

  @Test
  public void grouping() {
    Matcher matcher = Pattern.compile("([a-z]+) ( ?\[[a-z]+\] ([a-z]+))+").matcher(mail);
    matcher.find();

    assertEquals("brice", matcher.group(1));
  }
}

Dans l’expression ci-dessus, il y a trois groupes définis dans l’expression rationnelle.

• ([a-z]+) qui est donc le groupe 1
• ( ?[[a-z]+] ([a-z]+)) qui est le groupe 2
• ([a-z]+) enfin qui est le groupe 3 il est défini à l’intérieur du groupe 2

Le moteur de l’expression régulière enregistre juste la référence du groupe, et lorsque qu’il y a récursion sur les groupes, le groupe prend la valeur du dernier contenu matché. Ainsi dans cet exemple après un premier appel à find, l’ensemble de la chaîne de caractère a été consommée, et les groupes 2 et 3 son valorisés par :

assertEquals("[dot] com", matcher.group(2));
assertEquals("com", matcher.group(3));

En plus de ça, les références aux groupes sont limitées à 10. Honnêtement c’est rare d’avoir besoin de plus de 10 groupes. Dans ce cas il faut splitter la chaîne ou la regex.

Cependant on peut en partie s’arranger pour que les groupes qui ne nous intéressent pas ne soit pas référencés, il faut utiliser un groupe on-capturant.

Les non-capturing groups

C’est presque à la fin de la javadoc de la classe Pattern. Ils se construisent de la manière suivante :

(?:regex)

Pour reprendre l’exemple plus haut, le groupe 2 n’est pas vraiment utile à notre expression régulière. Du coup on pourrait écrire :

@Test
public void groupingNonCapturing() {
  Matcher matcher = Pattern.compile("([a-z]+) (?:[ ]?\[[a-z]+\] ([a-z]+))+").matcher(mail);
  matcher.find();

  assertEquals("brice", matcher.group(1));
  assertEquals("com", matcher.group(2));
}

Il y a alors 2 groupes uniquement qui sont référencés.

Les constructions avancées des groupes sont la preuve que le moteur fait partie des dernière générations.

Les backreferences

Les références des groupes qui capturent, elles sont utilisées dans les moteurs de recherche et de remplacement. Typiquement avec Eclipse, le format utilisé pour faire référence à un groupe est :

X

Ou X est le numéro du groupe, sa référence.

En fait cette notation peut également s’utiliser à l’intérieur d’une expression régulière, c’est ce qu’on appelle donc une backrefrence. Pour back; parceque le groupe doit déjà être défini et matché pour être référencé dans une regex. Par exemple le cas le plus simple :

assertTrue(Pattern.compile("([0-9]+) \1").matcher("123 123").matches());
assertFalse(Pattern.compile("([0-9]+) \1").matcher("123 1234").matches());

Première assertion; le groupe 1 matche 123, la backreference va chercher à matcher le contenu exacte qui a été matché par le groupe 1, donc 123. La deuxième assertion montre bien que la backreference ne matchera pas 1234, car elle s’attend donc au même contenu que 123 (notez quand même l’utilisation de l’appel <strong>matches()</strong> plutôt que <strong>find()</strong>).

Bien entendu il faut que ce soit un groupe capturant, sinon la backreference ne sait pas ou chercher sa valeur. L’exemple qui suit montre un Pattern qui compile, mais qui ne fonctionnera pas:

assertFalse(Pattern.compile("(?:[0-9]+) \1").matcher("123 123").matches());

Le simple fait que ce pattern compile m’étonne, j’aurais plutôt choisi une approche fail-fast dans ce cas, c’est peut-être un oubli.

Ce genre de construction est assez pratique si on veut valider un langage comme le XML.

assertTrue(Pattern.compile("<([a-z]+)>.*</\1>").matcher("<strong>dude!</strong>").matches());
assertTrue(Pattern.compile("<([a-z]+)[^>]*>.*</\1>").matcher("<strong style="">dude!</strong>").matches());
assertTrue(Pattern.compile("<([a-z]+)[^>]*>.*</\1>").matcher("<strong>dude!</strong>").matches());

Attention il peut y avoir des astuces, en particulier sur le groupe qui fait le premier match. Par exemple dans le suivant on va voir le moteur regex valider l’expression, alors que la chaîne à valider n’est pas correcte :

assertTrue(Pattern.compile("<([a-z]+)[^>]*>.*</\1>").matcher("<strong>dude!</s>").matches());

Effectivement “<strong></s>” n’est pas correct pourtant, le moteur valide la séquence de caractère. En fait c’est un des features du moteur de regex, le backtracking, que je vais expliquer dans la section suivante. L’idée c’est que le moteur matche bien “strong” pour le groupe 1, mais lorsqu’il essaye de matcher la backreference avec “strong”, il n’y arrive pas donc il reviens en arrière jusqu’à ce que le groupe 1 est pour valeur “s”, ce qui permet à la backreference de matcher. Le reste de la balise “trong” est matchée par cette partie de l’expression “[^>]*“.

La solution, est d’utiliser une borne de mot vu dans la partie 1 de cette petite série d’article.

assertFalse(Pattern.compile("<([a-z]+\b)[^>]*>.*</\1>").matcher("<strong>dude!</s>").matches());

De cette façon le groupe 1 est littéralement obligé d’être suivi par autre chose qu’un caractère de mot. Avec cette expression la mauvaise séquence de caractère n’est donc plus validée.

Utilisation sympa des backreference est de chercher dans un texte les mots répétés :

assertTrue(Pattern.compile("\b(\w+)\s+\1\b").matcher("the the is repeated").find());

Les quantificateurs

Les quantificateurs permettent comme leur nom l’indique de quantifier (une expression). À l’exception de l’opérateur de Kleene, géré par les moteurs de regex depuis très longtemps, tous les autres quantificateurs sont des représentations simplifiées de ce qui est exprimable par des constructions basiques.

• dady? Le quantificateur optionnel peut s’exprimer par une alternative (attention à l’ordre) : dady|dad
• (?:pa){1,3} Le quantificateur borné peut s’exprimer en répétant les termes et/ou avec une alternative : pa|papa|papapa
• vrou+m Le quantificateur 1 ou plus peut être remplacé par l’occurrence 1 puis par une construction avec l’opérateur de Kleene : vrouu*m

Bref ces notations simplifiées sont bien pratiques.

Les quantificateurs gourmand (greedy quantifiers)

Pas de surprise ces quantificateurs font partie de la catégorie des quantificateurs dit gourmands. Vous savez certainement déjà les utiliser, cependant il peut y avoir des cas qui peuvent poser problèmes.

Dans l’exemple suivant je voudrais chopper la balise ouvrante.

public class Quantifiers {
  @Test
  public void greedy() {
    assertEquals("<h1>wont match</h1>", regexFirstMatch("<h1>wont match</h1>", "<.+>")); // greediness busted
    assertEquals("<h1>", regexFirstMatch("<h1>wont match</h1>", "<.+?>"));
    assertEquals("<h1>", regexFirstMatch("<h1>wont match</h1>", "<[^>]+>"));
  }

  private String regexFirstMatch(String text, String regex) {
    Matcher matcher = Pattern.compile(regex).matcher(text);

    return matcher.find() ? matcher.group(0) : "didnt found match";
  }
}

Dans la première approche on utilise un quantificateur gourmand “<.+>” ce qui veut dire que le moteur va essayer de consommer au maximum la séquence de caractères.

1. Pour la section .+ de la regex, le quantificateur va essayer de valider au maximum le “.“
2. Du coup le premier caractère “>” est validée par la construction “.“,
3. Puis il valide le deuxième “>”.
4. Après ce dernier “>” dans la séquence de caractère la chaîne complète est consommée, mais il reste le dernier “>” dans l’expression régulière rationnelle.
5. Du coup le moteur utilise le backtracking pour revenir en arrière, il tombe sur le “1“.
6. Finalement le “>” de l’expression matche le “>” de la séquence de caractère.

Comme ce n’est pas ce qu’on veut  récupérer, la balise ouvrante, une solution serait donc de prendre un quantificateur paresseux identifiable par le point d’interrogation qui suit le quantificateur.

Question performance dans le cas présent, il est plus intéressant de ne pas utiliser le point “.” mais plutôt d’utiliser un complément de l’ensemble qu’on ne veut pas matcher, c’est à dire une classe de caractère avec exclusion du caractère non voulu “>”. C’est la troisième solution du bout de code.

Les quantificateurs paresseux (lazy quantifiers)

Ces quantificateurs sont bien nommés parce dans le genre, ils vont en faire vraiment le moins possible. Pour les comparer donc avec un quantificateur gourmand ou la séquence maximum est consommée (notez que la méthode regexFirstMatch est la même que dans le bout de code ci-dessus) :

assertEquals("abc1abc2", regexFirstMatch("abc1abc2", "abc1(?:abc\d)?"));

Le quantificateur “?” essaye de matcher la regex du groupe, et il y arrive, donc la séquence complète est consommée. Par contre ci la regex utilise une construction avec un quantificateur paresseux “??” :

assertEquals("abc1", regexFirstMatch("abc1abc2", "abc1(?:abc\d)??"));

Alors le quantificateur ne va pas s’emmerder à matcher, si la regex matche déjà ce qui est fait par la première partie de la regex “abc1“. Ce qu’il faut retenir c’est qu’un lazy quantifier, ne matchera jamais si le moteur valide déjà l’expression, et le corollaire est que le lazy quantifer cherchera toujours à matcher si et uniquement si la regex n’a pas déjà été validée.

Autre exemple avec un quantificateur borné :

assertEquals("abc1abc2abc3", regexFirstMatch("abc1abc2abc3", "(?:abc\d){2,3}")); // greediness busted
assertEquals("abc1abc2", regexFirstMatch("abc1abc2abc3", "(?:abc\d){2,3}?")); // lazyness
assertEquals("didnt found match", regexFirstMatch("abc1", "(?:abc\d){2,3}?"));

À la ligne 2, le quantificateur paresseux est obligé d’être exécuté une fois au moins pour matcher, mais il en fait le moins possible.

Les quantificateurs possessifs (possessive quantifiers)

Les quantificateurs gourmands et paresseux, utilisent intelligement la capacité de backtracking afin d’évaluer les permutations possible qui permettent de valider l’expression régulière suivant leur stratégies respectives (en faire le plus ou en faire le moins). Cette propriété permet d’avoir des expressions assez souples pour matcher un grand nombre de séquence de caractère.

Cependant cette souplesse a un coût, le backtracking a un coût en mémoire et en temps CPU. Ce coût monte suivant la complexité de l’expression rationnelle et en fonction de la séquence de caractère. Pour des raisons de performance les créateurs des moteurs de regex ont introduit une nouvelle construction qui améliore les performances de votre regex : les quantificateurs possessifs.

Cette catégorie de quantificateur est un peu différente des deux autres, dans la mesure ou le backtracking est désactivé. Ce qui veut dire, si vous avez suivi, que l’expression régulière ne peut pas revenir en arrière chercher une précédente position ou la regex validait. Cependant il faut noter qu’un possessive quantifier cherche également à matcher le plus possible.

Typiquement dans le code suivant :

assertEquals("<h1>will match</h1>", regexFirstMatch("<h1>will match</h1>&nbsp;", "<.+>"));

La partie de l’expression régulière “.+” va tout matcher jusqu’au point virgule “;”. Seulement comme expliqué plus haut, une fois que la String est consommée, le caractère “>“ dans la regex ne peut pas matcher, donc le moteur reviens plusieurs fois sur ses pas, puis ressaye de matcher le “>” de la regex. Ce comportement peut être désiré dans certains cas, mais parfois si on souhaite juste rechercher quelque chose de spécifique ou valider très vite un texte sans chercher d’autres combinaisons alors ce n’est pas l’idéal.

assertEquals("didnt found match", regexFirstMatch("<h1>will match</h1>&nbsp;", "<.++>"));

Ici l’expression est constituée d’un possessive quantifier, et en effet l’expression ne matche pas parce qu’une fois que la regex a consommée l’ensemble de la chaîne, et qu’elle ne peut plus matcher le dernier “>“, elle se déclare en erreur. On peut voir ça comme une construction du genre fail-fast.

L’intérêt véritable des constructions de cette catégorie est intéressante uniquement si les sections adjacentes de la regex sont mutuellement exclusives. L’exemple le plus prégnant est lorsqu’on utilise un complément avec un quantificateur possessif :

assertFalse(Pattern.compile("<[^>]++>").matcher("<property attr1="blah" ....").matches());

Ici le complément “[^>]” est naturellement mutuellement exclusif avec le caractère “>“, ce qui permet à la regex d’invalider très vite la séquence de caractère. Si on avait utilisé un greedy quantifier, alors le moteur serait revenu en arrière autant de fois que possible pour tenter de valider l’expression, ce qui est impossible avec la séquence passée en paramètre.

Exemple à ne pas faire, car les tokens ne sont pas mutuellement exclusifs ; “a*+” immédiatement suivi d’un “a“, du coup la regex ne peut pas matcher car “a*+” consomme tous les a :

assertFalse(Pattern.matches("\ba*+ab\b", "aaaaaaab"));

Les quantificateurs possessifs sont des constructions qui sont supportées par les dernières générations de moteur de regex, parce qu’ils sont en réalité des groupes spéciaux. En effet dans la Javadoc de la classe Pattern, on trouve à la fin une partie sur les constructions spéciales, et celle qui nous intéresse dans ce cas, c’est celle là :

• (?>X) X, as an independent, non-capturing group

1. “non capturing” : Simplement parce que le groupe ne fait pas de capture lorsque X matche.
2. “independant” : Ici ce n’est pas très clair dans la javadoc de Pattern, pour trouver la signification il faut se rendre sur la documentation des regex en Perl, on y apprend qu’il s’agit d’un groupe indépendant du reste de l’expression régulière, que ce groupe ne sait pas revenir en arrière (pas de backtracking), en gros le moteur de regex permet à ce groupe de consommer tout ce qu’il peut sans considérer les autres parties de la regex.

Une petite vérification :

assertTrue(Pattern.matches("\ba*+b\b", "aaaaaaab"));
assertFalse(Pattern.matches("\ba*+b\b", "aaaaaaa"));

assertTrue(Pattern.matches("\b(?>a*)b\b", "aaaaaaab"));
assertFalse(Pattern.matches("\b(?>a*)b\b", "aaaaaaa"));

Donc un quantificateur possessif est une notation simplifiée d’un groupe indépendant et non capturant!

Le backtracking

Comme vous le savez, je l’ai bien répété, le backtracking c’est ce qui permet au moteur de regex de traquer les constructions qui ont validé. Le backtracking n’a de sens que pour les quantificateurs, en effet ce sont les quantificateurs qui vont essayer de tester une construction un certain nombre de fois. Cela dit cette construction peut-être suvi par une autre et le moteur doit s’assurer que les constructions qui suivent le quantificateur valident également le reste de la séquence.

Prenons un exemple :

Dans le cas suivant on le pattern, observez le fait que le point “.” n’est pas mutuellement exclusif avec “bob“.

ab.*bob

Et on essaye de valider la chaine de caractères, les chiffres sont là pour illustrer la partie sur la quelle la construction “.*” devrait matcher, mais des lettres auraient pu faire l’affaire.

ab1234bob

A la première étape Pattern.compile, l’expression va être transformée dans un arbre. Techniquement le code ressemble à la fois au pattern Chain of Responsability et au pattern Composite (pour les groupes ou pour les quantificateurs notamment). Le moteur ajoute ses propres nœud au début et à la fin de l’arbre pour travailler avec cette représentation.

Dans le diagramme suivant chaque cadre correspond à l’état de la consommation de la séquence de caractère et à celui de l’expression régulière ainsi découpée en nœuds.

On comprend immédiatement le problèmes potentiels sur des expressions qui utilisent énormément les quantificateurs non-possessifs :

• Plus la partie à matchée est longue pour le quantificateur, plus la mémoire sera consommée.
• Si les constructions qui suivent ne matchent pas, celles-ci devront être annulée et réessayée, ce qui veut dire un temps d’exécution plus long!

La solution c’est de faire attention quand on construit une expression rationnelle. En particulier si elle est critique, l’idée serait de la benchmarquer, mais bon il faut pas tomber non plus dans ce qu’on appelle Premature Optimisation.

Bilan

Le backtracking c’est bien ; c’est ce qui permet à la regex d’être souple, mais clairement il faut faire attention à ce mécanisme. Il sera intéressant du coup d’utiliser des groupes non-capturants et indépendants si l’opportunité le permet.

Cette série s’achèvera par une troisième et dernière partie ou j’aborderais les possibilité de travailler avec Unicode, et surtout comment indiquer dans une regex qu’on ne veut pas d’une construction complète.

Références

• http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html
• http://perldoc.perl.org/perlretut.html

Depuis bien longtemps je connais et pratique les expressions régulières, à la fois au moment de coder, mais également dans mes éditeurs de texte, parfois aussi dans le shell, lors d’un grep par exemple. Bref les expressions régulières sont pratiques dans la vie de tous les jours pour un ingénieur logiciel.

Seulement voilà je me suis aussi rendu compte que certains d’entre nous n’ont pas une connaissance approfondie des expressions régulières et de leurs arcanes. Effectivement il y a parfois certaines expressions qui sont assez absconses. Et aujourd’hui les moteurs des expressions régulières dépassent ce le cadre dans lequel ces expressions ont été conçue. Elle permettent certaines constructions qui sont peu connues.

Les expressions régulières hier et aujourd’hui

Sans remonter aux origines des expressions régulières -cette partie là est couverte par wikipedia- il est intéressant de noter que les expressions régulières et leur moteur ont bien évoluées en 60ans. En effet le mot régulier vient de l’état de fait que ces expressions permettaient de rechercher dans des langages formels et non-contextuel; aujourd’hui les recherches ont avancées et les moteurs permettent maintenant de dépasser le cadre du langage formel pour permettre de travailler dans l’espace du langage contextuel. Les racines des expressions régulières remontent bien avant l’avènement de l’informatique pour aller jusqu’aux raisonnements complexes de la logique mathématique.

Il y a une une grosse différence entre un langage non-contextuel et un lange contextuel, dans les faits cette évolution explique pourquoi il y a aujourd’hui des différences dans les moteurs qui sont intégrés dans les différents programmes (en fonction de la plateforme, des outils, du langages etc.) Aujourd’hui en Perl, en C#, et en Java nous avons la chance d’avoir des moteurs qui font partie des dernières générations. C’est sur cet héritage que je vais disserter, cela dit uniquement dans le cadre de Java et de sa fameuse classe Pattern. (Vous remarquerez d’ailleurs que le moteur est nommé Pattern plutôt que Regex ou quelque chose du genre, l’explication est simple : cette génération de moteur n’est plus simplement à propos d’expression régulière mais donc de pattern.) Je tiens aussi à préciser que cet article se concentre sur la création d’expressions régulières et non sur l’usage de la classe Pattern.

Les différentes constructions

Petit rappel

Je passe rapidement sur les bases, j’imagine que tout le monde connaît les constructions basiques d’une expression régulière :

• Les classes de caractère [ ] et les compléments [^ ]
• L’opérateur de Kleene *
• L’alternative | (le pipe)
• Les autres quantificateurs : +, ?, {}, ces quantificateurs ne sont vraiment que des raccourcis de ce qui est déjà exprimable avec les autres constructions, mais ils nous simplifient la vie.
• Les groupes ()

Globalement pas de surprises ici, avec ses constructions il assez facile d’écrire l’expression la plus simple jusqu’à l’expression un poil plus élaborée.

Par exemple pour valider un mail (sans rentrer dans les arcanes de la RFC) on peut avoir ça:

@Test
 public void simpleEmailMatch() {
 String regex = "[a-z]+(\.[a-z]+)*@[a-z]+\.[a-z]{2,6}";

 assertTrue(Pattern.compile(regex).matcher("brice.dutheil@gmail.com").matches());
 }

Ok, c’est déjà pas mal, mais si on veut extraire une section d’un texte ou valider précisément certaines sections d’un texte, il faut connaitre les constructions un peu plus pointues.

Les ancres

Les ancres sont rangées dans la javadoc de la classe Pattern sous la catégorie Boundary matchers. Une ancre identifie juste une position à laquelle elle matche, elle ne consomme pas de caractères dans la séquence traitée.

Le début et la fin d’une ligne

Généralement les personnes qui ont beaucoup travaillé avec le shell connaissent les deux principales ancres, à savoir le début d’une ligne ^ et la fin d’une ligne $. Mais il y a une astuce en Java, c’est que par défaut ^ et $ repèrent le début et la fin du CharSequence uniquement, pas de notion de saut de ligne!

Pour s’en convaincre on écrit un petit test simple qu’on enrichira d’assertions, la méthode regexFirstMatch extrait la première section du texte qui matche la regex :

@Test
public void startEndOfLineVsPermanentStartEndOfString() {
  String text = "The account number is :n" +
  "t123456789n" +
  "the client phone number is :n" +
  "t0-987-654-321n";

  assertEquals("T", regexFirstMatch(text, "^.")); // Tout le temps le début de la séquence
  assertEquals("1", regexFirstMatch(text, ".$")); // Tout le temps la fin de la séquence
}

private String regexFirstMatch(String text, String regex) {
  Matcher matcher = Pattern.compile(regex).matcher(text);
  return matcher.find() ? matcher.group(0) : "";
}

Et ouai, on ne s’attend pas à ça (matche T et 1) surtout quand la description de ces ancres utilise le mot ligne. En fait il faut activer l’option multiligne Pattern.MULTILINE dans le moteur, pour que celui-ci identifie les sauts de ligne.

Ainsi dans le contexte du bout de code du dessus, les lignes suivantes permettent de voire qu’il s’agit bien du caractère ‘:’ de la première ligne qui est trouvé.

Matcher matcher = Pattern.compile(".$", Pattern.MULTILINE).matcher(text);
matcher.find();
assertEquals(":", matcher.group(0));

Nice, mais il y a encore mieux, le moteur de regex de Java (comme certains autres) permet de donner les options à l’intérieur de la regex, la javadoc de Pattern donne cette info dans la catégorie Special constructs (non-capturing), celle qui nous intéresse est la construction sur les options pour toute l’expression.

• (?idmsux-idmsux) Nothing, but turns match flags on – off

Il faut le placer au début de l’expression régulière, ici (?m) :

assertEquals(":", regexFirstMatch(text, "(?m).$"));

On choppe alors bien le caractère à la fin de la première ligne.

Le début et la fin d’une séquence de caractères

Dans notre expression si on veut se caler dans tous les cas sur le début et la fin d’une séquence de caractères, il y a des ancres dédiées A et Z. Celles-ci ne sont bien entendu pas affectées par l’option multiligne.

assertEquals("T", regexFirstMatch(text, "\A.")); // Tout le temps le début de la séquence
assertEquals("1", regexFirstMatch(text, ".\Z")); // Tout le temps la fin de la séquence
assertEquals("1", regexFirstMatch(text, "(?m).\Z")); // Tout le temps la fin de la séquence

Notez quand même qu’en ce qui concerne le Z le dernier caractère de la séquence qui est un séparateur de ligne n’est pas retourné! Comme indiqué dans la javadoc, cette ancre repère la position avant le dernier caractère séparateur (écrit comme terminators dans la javadoc).

Il existe d’autres ancres, mais elles sont moins utiles, je vous laisse voir par vous même.

Les options

On a vu qu’on pouvait activer des options pour une expression régulière, effectivement c’est assez pratique.

Les options possibles utilisables à la construction ou dans le pattern sont dans la javadoc, mais les plus intéressantes sont :

Certaines options comme vu dans le tableau n’ont pas d’équivalence dans la regex.

Bon c’est bien pratique ça, mais parfois on aimerait bien s’assurer que la casse est ou n’est pas vérifiée sur une portion de la regex. Il existe une construction qui permet d’activer/désactiver une option dans une section de l’expression régulière :

• (?idmsux-idmsux:X) X, as a non-capturing group with the given flags on – off

A peu près la même chose que pour les options avec une portée sur toute la regex, sauf que cette fois, la portion soumise à l’option changée est à l’intérieur d’un groupe. Et là vous remarquerez que la javadoc dit bien “non-capturing” ça veut dire que la regex ne gardera pas en mémoire le contenu de ce groupe, contrairement aux groupes qui, donc, capturent et sont identifiables par l’encadrement du groupe par des parenthèses (X).

Ainsi par exemple si on ne veut pas tenir compte de la casse dans une portion de la regex on écrirait:

assertFalse(Pattern.compile("(?-i)[a-z]+ [a-z]+ [a-z]+").matcher("jqsdfkjkd fdfhJGJKGFQSDKjb ckbvg").matches());
assertTrue(Pattern.compile("(?-i)[a-z]+ (?i:[a-z]+) [a-z]+").matcher("jqsdfkjkd fdfhJGJKGFQSDKjb ckbvg").matches());

Dans la première expression, qui ne marche pas, l’ensemble de l’expression est sensible à la casse c’est l’option (?-i) en début d’expression. Mais au milieu on voudrait quand même autoriser les majuscules. Pour ce faire on active l’insensibilité uniquement pour le groupe du milieu (?i:[a-z]+).

Les bornes de mot

Les bornes de mots sont des ancres de type particulier. Comme n’importe quelle ancre, ces bornes ne consomment aucun caractère. La borne b s’utilise avant ou après un mot pour marquer le début ou la fin d’un mot.

Par exemple en utilisant la classe de caractère w.

assertTrue("word".matches("\bword"));
assertTrue("word".matches("word\b"));
assertTrue("word".matches("\bword\b"));
assertTrue("word".matches("\b\w+\b"));

assertTrue("12dsk_".matches("\b\w+\b"));

assertTrue("12dsk;  fdg987".matches("\w+\b.*\b\w+"));

assertFalse("12dsk;   ;:!,:".matches("\w+\b.*\b\w+"));

assertTrue(Pattern.compile("\bes\b").matcher("Tu es encore dans ces histoires ").find());
assertFalse(Pattern.compile("\bes\b").matcher("Tu as encore des histoires ").find());

assertFalse("12dsk-".matches("\w+"));

assertFalse("12dsk-".matches("\w+-\b"));
assertTrue("12dsk-".matches("[0-9a-z-]+"));
assertFalse("12dsk-".matches("[0-9a-z-]+\b"));

assertFalse("12dsk. ".matches("\w+.\b."));

assertFalse("bobEtLéa".matches("bob\b\w+\bLéa"));

Bon c’est bien cool, mais si je veux matcher un texte en allemand, du grec ou simplement des lettres accentuées de notre bon français ? Là ça pèche un peu si on utilise le w.

assertFalse("Éole".matches("\b\w+"));
assertTrue("Éole".matches("\bÉole"));

assertTrue("Éole".matches("\b[Éa-z]+"));
assertTrue("Éole".matches("\b\p{L}+"));

En effet la classe w ne connait que les caractères ASCII et plus précisément; uniquement ceux de cette classe [a-zA-Z0-9_] tel que c’est mentionné dans la javadoc. Pour palier à cette limitation soit il faut ajouter le caractère accentué à une classe de caractère, soit on utilise une classe de caractère Unicode, c’est ce qui est fait dans la dernière assertion j’utilise p{L} ! Je reviendrais plus tard sur Unicode avec les expressions régulières.

Attention à l’encodage de vos codes source ! J’ai eu des erreurs d’encodage du fichier sur Eclipse, IntelliJ et NetBeans qui provenaient de plateformes différentes (MacOSX et Windows), du coup le caractère É n’était pas bien encodé (comprendre que l’IDE encodait ce caractère dans autre chose qu’une lettre), ce qui faisait évidement échouer l’expression.

Enfin le complément d’une borne b est représenté par la borne B, celle-ci matche tout ce que b ne matche pas. Dans les faits B marque la borne entre deux classes de caractères à l’exception d’une classe composée des caractères qu’on peut trouvé dans w.

assertTrue("12dsk-".matches("\w+-\B")); // B capture l'inverse b
assertTrue("12dsk.".matches("\w+\.\B"));
assertTrue(".!? nt".matches("[.!?]+\B\s+"));
assertTrue(".!?,,,;:".matches("[.!?]+\B[,;:]+"));

Fin de la partie 1

Voilà pour la première partie, la plus simple, sur les expressions régulières en Java. Pour la suite qui arrive très bientôt j’exposerai la manière de fonctionner de certaines constructions un peu particulières :  les backreferences, les quantificateurs possessifs, les possibilités de lookahead / lookbehind.

Références

• http://en.wikipedia.org/wiki/Regular_expression
• http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html
• http://perldoc.perl.org/perlretut.html

Le contexte

“The context is King” disait Andy Hunt dans son livre Pragmatic Learning and Thinking. Alors brève introduction au contexte du problème.

• Application assez simple qui permet de rechercher, consulter, créer, modifier des données différentes issues du domaine métier.
• L’application tourne sur un WebSphere.
• WebSphere tourne sur une JVM IBM. Ah là ça sent la pêche aux informations, n’ayant jamais travaillé sur cette JVM, et pas de bol non plus la JVM IBM sur Windows n’est pas accessible gratuitement depuis le site de IBM.
• L’ensemble tourne sur une machine AIX.
• L’entreprise utilise l’outils Introscope qui permet d’avoir plein de métriques.

Le problème

Les utilisateurs ressentent des lenteurs, voire des freezes. L’outil INSC identifie ces threads en Stalled, et permet de donner des métriques sur les temps d’attentes et de réponses de certains éléments du systèmes, les ingénieurs systèmes utilisent abondamment cet outils. Bref, les temps de réponses vont de quelques dizaines de secondes à plusieurs minutes.

Il y a définitivement un problème. Forcément quand on a un super outils comme INSC qui a plein de métriques, on se balade dedans pour essayer de trouver le problème. Malheureusement un seul thread dump pour voir ce qu’il se passe dans les threads ne suffit pas. Le thread dump révèle que la plupart des threads sont à l’état “Waiting On Condition“. Le super outils INSC indique un usage de la heap, il indique aussi que certaines requêtes SQL sont très très longues, il indique les sessions web ouvertes une petite trentaine, pas de quoi fouetter un chat. Et pourtant il y aurait du CPU assez fortement utilisé, vu depuis Introscope.

Mais voilà l’analyse tourne un peu autour du pot. Pourquoi ces threads sont-elles bloquées? Pourquoi les requêtes SQL sont-elles aussi longues?!

Le problème dans l’analyse

Récapitulons, dans cette situation les métriques de Introscope ont été regardées, et on a un seul thread dump.

Introscope malgré ces métriques ne dit pas ou est le problème, il ne dit même pas quel est le type de problème. Les métriques affichées sont pour certaines intéressantes, je pense à l’identification des threads figées, les temps de réponses de certains composants, la consommation mémoire, et l’utilisation du CPU.

Mais pourquoi cet outils n’a pas aidé à trouver le problème, parce qu’il ne mesure pas les bonnes choses. Et il faut en particulier comprendre que quand un système fonctionne mal il y a un effet de corrélation qui s’applique sur un ensemble de variable. Et ce n’est pas avec Introscope qu’on va pouvoir identifier la cause du ralentissement généralisé, ni trouver une relation de cause-à-effet.

Pour résoudre un problème, il faut s’équiper avec les bons outils! Il faut aussi regarder les bonnes données, au bon endroit, et au bon moment!

A la poursuite du vrai problème (partie 1)

Bon hop, déjà pour commencer j’écarte pour le moment Introscope. Et j’ai un thread dump … de la JVM de IBM, il va falloir essayer les outils IBM qui permettent de traiter ces informations. Je vais me satisfaire ça pour l’instant.

L’analyse du thread dump

Avec : IBM Thread and Monitor Dump Analyzer for Java

Évidement le format ne correspond pas à celui de Sun, heureusement IBM nous fournit des outils pour analyser ces informations. Direction http://www.alphaworks.ibm.com/tech/jca.

A l’ouverture un rapport apparait, il commence par ça en rouge :

***WARNING*** Java heap is almost exhausted : 0% free Java heap Please enable verbosegc trace and use IBM Pattern Modeling and Analysis Tool(http://www.alphaworks.ibm.com/tech/pmat) to analyze garbage collection activities. If heapdumps are generated at the same time, please use IBM HeapAnalyzer(http://www.alphaworks.ibm.com/tech/heapanalyzer) to analyze Java heap.

Ok, là c’est assez facile de savoir ou ça va! Mais allons plus loin!

Il y a également :

Number of Processors : 4
Java version : J2RE 5.0 IBM J9 2.3 AIX ppc64-64 build j9vmap6423-20090707

Java Heap Information
Maximum Java heap size : 384m
Initial Java heap size : 384m

OK, j’en apprends un peu plus sur la JVM et la machine.

Free Java heap size: 0 bytes

Allocated Java heap size: 402 653 184 bytes

Ok évidement tout s’explique il ne reste plus rien pour allouer dans la Heap.

Tiens dans la ligne de commande je voit que Introscope est un agent de le JVM:

-Xshareclasses:name=webspherev61_%g,groupAccess,nonFatal
-Dibm.websphere.internalClassAccessMode=allow
-Dcom.wily.introscope.agentProfile=/opt/wily/wilyAgent/AvtAgent.profile
-javaagent:/opt/wily/wilyAgent/Agent.jar

C’est intéressant, si la JVM est lente, ca peut vouloir dire que les mesures Introscope sont aussi soumises aux lenteurs de la JVM.

Le rapport est sympa, il donne la répartition de la mémoire de la JVM :

Memory Segment Analysis

Memory Type	# of Segments	Used Memory(bytes)	Used Memory(%)	Free Memory(bytes)	Free Memory(%)	Total Memory(bytes)
Internal	13	1 191 740	88,4	156 452	11,6	1 348 192
Object (reversed)	1	402 653 184	100	0	0	402 653 184
Class	9 735	228 637 344	90,96	22 724 116	9,04	251 361 460
JIT Code Cache	5	41 943 040	100	0	0	41 943 040
JIT Data Cache	3	17 018 496	67,63	8 147 328	32,37	25 165 824
Overall	9 757	691 443 804	95,71	31 027 896	4,29	722 471 700

Ok, c’était un tableau intéressant, on voit clairement que dans une JVM il n’y a pas que de la Heap (pour ceux qui ne le savait pas), en effet on voit donc les sections suivantes (les passages surlignés viennent de moi, malheureusement l’outil d’IBM ne nous aide pas là dessus) :

• la mémoire interne de la JVM (les objets internes, les structure de thread, et autres objets natifs) : bonne utilisation
• les objets, en une seule section de mémoire, c’est la Heap, et là ben effectivement elle utilisée à 100%.
• les sections des classes, c’est la ou le byte code de vos classes est stocké par la JVM, mais ce n’est pas dans la Heap (chez la JVM de Sun ça correspondrait à la PermGen area), bref là aussi 90% d’utilisation c’est plutôt pas mal.
• JIT Code Cache et JIT Data Cache, c’est là ou la JVM va stocker le code natif qu’elle aura compilée depuis le bytecode, là aussi c’est rempli à100% mais c’est peut-être normal, après tout la taille totale est plus petite.

On voit aussi que la mémoire accessible dans la Heap est quand même supérieure a ce qui est indiqué dans la ligne de commande, à savoir les 384 MB. Ne connaissant pas la JVM IBM, je ne suis pas certains des raisons induisant ce phénomène.

Mais à 100% d’utilisation, ça sent le GC qui s’excite pour garder ses petits. Mais le rapport est long et n’est pas terminé, il reste des choses à lire.

Thread Status Analysis

Status	Number of Threads : 170	Percentage
Deadlock	0	0 %
Runnable	12	7 %
Waiting on Condition	158	93 %
Waiting On Monitor	0	0 %
Suspended	0	0 %
Object.wait()	0	0 %
Blocked	0	0 %
Parked	0	0 %

Vous vous souvenez des threads vues en Wait on Condition au tout début, on les retrouve donc ici dans les stats du thread dump. Il y a environ 158 thread qui ne font rien et 12 threads qui travaillent. Alors petite parenthèse, qu’est ce que ça veut dire ce Waiting on Condition. Les raisons peuvent être les suivantes :

• Thread.sleep(), en gros on indique simplement à la thread de ne rien faire, mais c’est quand même la JVM qui gère ce sleep()
• Object.wait(), en gros quelque part dans le code un thread est en attente pour qu’une condition se réalise, voire le code en question pour en savoir plus sur la condition. Cette condition peut aussi être une condition interne à la JVM.
• La thread est en train de se synchroniser avec une autre, elle doit donc attendre que l’autre thread finisse son job, on verra probablement dans la stack un appel à un Thread.join().
• Unsafe.park, et autres support pour les lock
• La thread est blockée par des opérations d’I/O.

Déjà ce n’est pas forcément un problème pour toutes les threads, typiquement on peut s’attendre à voir des threads relatives aux systèmes de cache (ehcache et consorts) qui sont dans ces états. Ensuite il faut comprendre que ce mécanisme implique des conditions internes à la JVM. L’ordonnanceur (scheduler) de la JVM, qui en réalité fait appel au scheduler de l’OS, donne la main à d’autres traitements (java ou pas).

Le prochain tableau du rapport nous indique ou sont (toutes) nos threads, mais pas d’analyse par type de statut. On observe bien certaines des raisons citées plus haut.

Thread Method Analysis

Method Name	Number of Threads : 170	Percentage
java/lang/Object.wait(Native Method)	88	52 %
java/lang/Thread.sleep(Native Method)	63	37%
NO JAVA STACK	6	4 %
java/net/PlainSocketImpl.socketAccept(Native Method)	5	3 %
java/net/SocketInputStream.socketRead0(Native Method)	3	2 %
com/ibm/misc/SignalDispatcher.waitForSignal(Native Method)	1	1 %
d’autres ligne à 1%…

Pas mal de thread sont en attente, et beaucoup d’autres dorment. Quelques threads sans stack Java, ce sont des threads qui appartiennent à la JVM.

J’arrête là pour le moment  sur le rapport de cet outils IBM, mais ce qu’il faut retenir c’est que le thread dump est utile pour étudier des threads, mais c’est utile sur un laps de temps, avec un seul cliché on ne se rends pas compte réellement du comportement. Et en plus ces données ne sont pas intéressantes pour savoir ce qu’il se passe coté gestion mémoire. Heureusement que J9 (la JVM de Mr IBM) fournit quelques infos, sinon je ne vois pas comment diagnostiquer le problème sans jeter un œil sur les données adéquates, c’est à dire le log du Garbage Collector.

L’analyse du log GC, enfin!

Après l’obtention du fameux log, il faut encore trouver un outil IBM pour analyser le fichier. Les choses deviennent intéressantes. Comme je l’ai déjà dit, les logs sont au format IBM, ça ressemble à du XML. Et pour analyser ces logs rien de mieux que les outils de IBM, non? Google me dit rapidement qu’il me faut donc ce truc Pattern Modeling and Analysis Tool for Java Garbage Collector, direction http://www.alphaworks.ibm.com/tech/pmat.

Avec : Pattern Modeling and Analysis Tool for Java Garbage Collector

Un petit graphique pour regarder ce qu’il se passe.

En rouge l’usage de la Heap, en bleu le marquage des objets à virer, et en vert les temps de compression de la mémoire. Effectivement le GC à l’air de bien s’amuser dans la mémoire, et d’être appelé assez souvent.

Bon celà dit je ne suis pas convaincu par l’outil IBM, il manque des informations que j’avais vu en texte dans le log GC ; un évènement GC à  cette tête là :

<af type="tenured" id="388571" timestamp="Jun 21 03:01:11 2010" intervalms="228.858"></pre>
  <minimum requested_bytes="168" />
  <time exclusiveaccessms="0.489" />
  <tenured freebytes="0" totalbytes="402653184" percent="0" >
    <soa freebytes="0" totalbytes="402653184" percent="0" />
    <loa freebytes="0" totalbytes="0" percent="0" />
  </tenured>
  <gc type="global" id="388576" totalid="388576" intervalms="230.720">
    <refs_cleared soft="0" threshold="32" weak="76" phantom="0" />
    <finalization objectsqueued="0" />
    <timesms mark="408.282" sweep="5.061" compact="0.000" total="415.341" />
    <tenured freebytes="209018360" totalbytes="402653184" percent="51" >
      <soa freebytes="209018360" totalbytes="402653184" percent="51" />
      <loa freebytes="0" totalbytes="0" percent="0" />
    </tenured>
  </gc>
  <tenured freebytes="209013328" totalbytes="402653184" percent="51" >
    <soa freebytes="209013328" totalbytes="402653184" percent="51" />
    <loa freebytes="0" totalbytes="0" percent="0" />
  </tenured>
  <time totalms="417.431" />
</af>

Vu l’allure du log, on a pas l’impression d’être sur un GC de type generationnel, mais je ne suis pas encore sûr, c’est une JVM IBM. Bon revenons à nos moutons:

• il y a eu 230 ms d’écoulées avant le dernier GC.
• la tenured indique directement qu’il n’y a plus de place dans la mémoire,
• on voit que le GC est de type global, ce qui veut dire que c’est toute la zone mémoire qui est affectée par le GC, c’est long
• la tenured libère environ 200 MB, soit 51%!
• le temps total mis par ce GC est de 420 ms, c’est long.

Et il y a plein d’entrées comme ça, ça fait beaucoup de GC globaux de 1 demi-secondes, tous les 5ème de secondes. Le GC prends du temps CPU pour nettoyer la mémoire un peu trop souvent. Et ce ci pourrait bien être la cause des ralentissements observés. En gros soit il n’y a simplement pas assez de mémoire, soit il y a une fuite mémoire.

Avec : IBM Support Assistant et Garbage Collection and Memory Visualizer

En me renseignant, je voulais jeter un œil aux outils IBM plus récents, tel que celui mentionné par Holly Cummins au ParisJug (le 8 Juin 2010). Pour commencer il faut un compte IBM et télécharger IBM Support Assistant, direction http://www-01.ibm.com/software/support/isa/.

Après une fois qu’on a l’outil, il faut à nouveau télécharger des plugins (nommé additif sur l’interface en français). Bon en fait le Health Center en me sert à rien puisqu’il il faut se connecter à une JVM IBM, ayant une JVM Sun sur mon poste je ne vais quand même pas aller taper sur la prod si tenté que ce soit possible. Finalement j’opte pour le plugin : Garbage Collection and Memory Visualizer.

Donc finalement j’essaye cet outils d’analyse, et j’ai un rapport bien plus sympa et complet avec plein de graphiques qui m’intéressent.

Déjà le rapport débute par :

Your application appears to be leaking memory. This is indicated by the used heap increasing at a greater rate than the application workload (measured by the amount of data freed). To investigate further see Guided debugging for Java

Ok, je m’en doutais déjà mais c’est quand même mieux que de dire que la mémoire est quasiment entièrement utilisée. Et on retrouve les alertes suivantes dans le rapport :

The application seems to be using some quite large objects. The largest request which triggered an allocation failure (and was recorded in the verbose gc log) was for 5242904 bytes.

5MB quand même! Cela dit ça n’arrive pas souvent, c’est peut-être un cache qui charge des données depuis le disque. Le graphe suivant (choisir Object Size dans les templates de graphique sur la droite) montre la taille des allocations demandées.

Mais la concomitance de ses demandes d’allocation avec l’utilisation de la heap fait sourciller.

On continue

Garbage collection is causing some large pauses. The largest pause was 7362 ms. This may affect application responsiveness. If responsiveness is a concern then a switch of policy or reduction in heap size may be helpful.

Effectivement le temps passé dans l’application et le temps passé dans le GC indique manifestement qu’il y a une suractivité anormale du GC.

En fait on voit même que le GC est en train de compacter la mémoire au moment  de l’incident, c’est la courbe rouge clair (entre ~0.5s et 1s), ajouté à cela le temps de marquage des objets à virer (bon en fait dans le graphique que j’ai fait, le temps de pause est principalement du au temps de marquage), l’ensemble donnant un temps de pause pour laisser le GC travailler allant de 1 à 7s (par GC bien évidement).

Et là effectivement expliquer les ralentissements de l’application devient plus facile, merci à ces beaux graphiques explicites.

On peut regarder vraiment beaucoup de chose avec cet outils, même s’il y a des défauts manifestes dans l’interface utilisateur. C’est quand même plutôt pas mal.

Je termine sur un petit résumé des valeurs intéressantes que nous donne cet outils.

Allocation failure count	59971
Forced collection count	3
GC Mode	optthruput
Largest memory request (bytes)	5242904
Mean garbage collection pause (ms)	491
Mean heap unusable due to fragmentation (MB)	0.2
Mean interval between collections (minutes)	0.01
Number of collections	59974
Proportion of time spent in garbage collection pauses (%)	58.24
Proportion of time spent unpaused (%)	41.76
Rate of garbage collection (MB/minutes)	13250

Tiens le mode GC est optthruput, en fait c’est une des polices du comportement du GC, et probablement de la manière de segmenter la mémoire (Nursery (Young), Old (Tenured)).

En effet dans les logs GC, je n’ai pratiquement vu que des GC globaux et uniquement sur la section de la tenured, à priori pas de zone nursery, c’est probablement du à ce comportement du GC.

En me renseignant donc, il y a 4 polices de GC dans la JVM J9 de IBM :

• optthruput : Optimisé pour throughput (le débit), flat heap <= Bingo
• optavgpause : Optimisé pour les temps de pause (Stop-The-World), le CMS est configuré pour prendre le moins de temps, flat heap
• subpool : Un police optimisé pour les machine multi-processeur, flat heap
• gencon : C’est le GC générationnel, qui est divisé en zone
  • nursery : qui permet la collection rapide et efficace des objets de vie courte, pas de pause
  • tenured : zone des vieux objets, mais un GC dans cette zone est global et demande à pauser l’application

A la poursuite du vrai problème (partie 2)

La pèche aux informations

Après avoir passé le GC au mode générationnel, il y a toujours ces problèmes de lenteurs mais ce n’est plus généralisé à toute l’appli, pas de log GC pour vérifier mais Introscope indique une utilisation relativement correcte de la mémoire, bizarre. Back to basics!

Le thread dump de la JVM IBM me dit toujours que la Heap est utilisée à 100%, mais je vois quand même

Free Java heap size: 72 041 864 bytes

Allocated Java heap size: 402 653 184 bytes

Et plus loin :

Last Garbage Collection Detail

Nursery Area Free : 59 307 392 bytes Total : 60 397 568 bytes 98 % free
Tenured Area Free : 17 058 368 bytes Total : 335 544 320 bytes 5% free
Global Garbage Collector Counter : 148

La tenured est bien remplie et utilise un très grosse partie de la heap ; memory leak ou beaucoup d’objet à mettre en cache. Ou encore autre chose, sans mesures claires pour écarter les hypothèses ces dur.

Pour quoi ne pas activer dans tous les cas le log GC, la JVM IBM offre des option pour gérer la rotation des logs GC, comme ça l’argument de saturation du disque tombe à l’eau. Mais bon il faut lire la documentation; donc petit passage chez IBM grâce à Google, et hop :

-Xverbosegclog[:<file>[,<X>,<Y>]]

Et voilà : file étant le couple chemin + fichier, X le nombre de fichier maximum (ça tourne et écrase les fichiers), Y le nombre de cycle GC. Ce que ne dis pas par contre la doc IBM c’est la taille approximative d’un GC, donc 700 cycles de GC ≃ 1 MB. Il est même possible d’utiliser des tokens utilisés pour les dumps dans WAS 7 (voir ici).

Recoupement des informations

Le log du Garbage Collector ne venant pas, il faut chercher autrement. Je demande au moment ou le problème se reproduit , de faire plusieurs thread dump d’affilé séparé de quelques secondes (~20s) et de faire également un listing des sous-processus java.

En effet le thread dump est bien sympa, mais il ne donne pas la consommation CPU des threads.

Dans un environnement il faut entre dans le terminal (Dans Linux l’identifiant des thread est dans la colonne LWD.) :

ps -fLp <processid> -L

Evidement il s’agit d’un AIX et les commendes sont différents, pas de soucis un petit tour dans la doc IBM et il faut entrer la commande suivante, et là l’identifiant de la thread est dans la colonne TID :

ps -mp <processid> -o THREAD

On a alors un listing énorme, que j’ai tronqué ici.

USER    PID   PPID       TID S  CP PRI SC    WCHAN        F     TT BND COMMAND
wasadmin 393262 401580         - A 188  60 203        *   202001      -   - /opt/was61/java/bin/java ...
 -      -      -    700535 S   0  82  1 f100070f1000ab40  8410400      -   - -
 -      -      -    741581 S   0  82  1 f100070f1000b540  8410400      -   - -
 -      -      -    802997 S   0  82  1 f100070f1000c440  8410400      -   - -
 -      -      -    884895 S   0  82  1 f100070f1000d840  8410400      -   - -
 -      -      -   1183791 Z   0  82  1         -       c00001         -   - -
 -      -      -   1667157 R  60 122  0            -    400000       -   - -
 -      -      -   1708269 S   0  82  1 f100070f1001a140  8410400      -   - -
 -      -      -   1736831 S   0  82  1 f100070f1001a840  8410400      -   - -

La colonne CP me dit que manifestement la thread 1667157 utilise plutôt pas mal le CPU, qu’est-ce que donne cette thread du coté du thread dump ?! Au fait on repère 3 threads dans le même cas.

Il faut savoir que dans le thread dump il y a l’identifiant de la thread en Java, mais qu’il y a aussi et surtout de mentionné l’identifiant natif de la thread, par exemple NID.

Je google “1667157 in hex” ce qui me renvoie 0×197055. En utilisant l’outils IBM mentionné plus haut, on voit clairement que la thread en cause correspond à du code métier, développé ici.

Chacune des 3 threads passent dans le même bout de code. Autant au début j’ai des doutes, après toute la présomption d’innocence compte aussi pour le code, d’autant plus qu’il s’agit d’un code lent qui utilise beaucoup de reflection. Mais faut prendre en compte aussi le fait que la pile descend à chaque fois dans la couche Hibernate, ça vaut le coup d’aller voir. Les développeurs qui connaissent un peu mieux le code poussent dans cette direction.

Entre temps les DBA confirme que la base de données réponds très bien, mais qu’elle enregistre un très fort nombre d’un certain type de requête SQL.

Bingo, il y a une race condition dans une des boucles, et celle-ci part en boucle infinie. Ceci explique la très forte utilisation de la mémoire et les lenteurs remarquées.

Bilan

Un problème peut en cacher un autre, ou plus exactement un problème peut en provoquer d’autres. Il faut juste avoir des moyens de mesurer les changements qu’on apporte si on veut isoler / écarter des catégorie de problèmes.

L’outillage on l’a vu est essentiel, Introscope apporte des choses, mais il ne permet pas tout. Qui plus est, on ne sait pas précisément ce qu’il mesure et ou! Les temps de réponses SQL, n’étaient par exemple pas crédible, car Introscope mesurait également les GC.

Dans notre cas ici, j’aurais aussi bien aimé avoir une JVM IBM sur mon poste histoire de jouer plus facilement avec. C’est dommage que IBM ne fournisse pas gratuitement sa JVM au moins pour le développement.

Accessoirement ce serait bien un jour d’avoir des format de log normalisé entre les JVM, ainsi que certaines des options afférentes.

Finalement ce qui a pris le plus de temps était d’obtenir les bonnes données, pour prendre les meilleurs choix. L’impression de travailler les mains dans le noir n’était pas l’idéal pour résoudre le problème, mais c’est au moins formateur. Je peux dire que j’ai bien apprécié certains retours et recommandations des  développeurs. L’équipe système étant surchargée n’a pas pu nous donné un support optimal, et cette carence s’est ressentie notamment pour avoir les données à temps. Mais leur vu du problème a permis d’orienter la recherche sur les parties qui pouvait poser problème.

Références & Documentation

• http://websphere.sys-con.com/node/921279?page=0,1
• http://sites.google.com/site/threaddumps/java-thread-dumps
• http://java.sun.com/developer/technicalArticles/Programming/Stacktrace/
• http://geekexplains.blogspot.com/2008/07/threadstate-in-java-blocked-vs-waiting.html
• http://www.ibm.com/developerworks/java/library/j-nativememory-aix/
• http://www.ibm.com/developerworks/ibm/library/i-garbage1/
• http://www-01.ibm.com/support/docview.wss?rs=180&context=SSEQTP&dc=DB560&dc=DB520&uid=swg21384096&loc=en_US&cs=UTF-8&lang=en&rss=ct180websphere
• http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.60/diag/appendixes/cmdline/cmdline_gc.htm