Java Bien!

Ca trolle sévère sur la mailing liste de Cast Codeurs concernant le code de Scalaz.

Qu’il est difficile de comparer, Java, un langage conçu pour aider les développeurs à évoluer dans un monde pas trop dangereux pour lui-même et Scala, un langage conçu pour donner les pleins pouvoirs au développeur quitte à ce que l’arme lui pète entre les mains.

Cela est d’autant plus difficile que paradoxalement Java n’a pas atteint son objectif de protection du développeur (cf. Java Puzzlers) et Scala offre aussi une protection par son système de typage.

Et la lisibilité du code ?

La lisibilité des deux langages entre aussi en jeu dans la comparaison. Chaque langage porte ses contradictions:

• Java a une syntaxe redondante, lourde mais rassurante pour le lecteur.
• Scala a une syntaxe ultra ramassée et un système de typage très verbeux pour qui cherche le maximum de protection à la compilation.

OO versus FP

Et puis il y a la programmation fonctionnelle qui fait grincer les dents. Ceux qui ont pratiqué aiment, les autres n’arrivent souvent pas à lire le code, faute d’habitude. Pour shématiser, on passe du mode ‘une opération par ligne’ facile à lire au one-liner ‘un concept par ligne’ rapidement trop ramassé. Ceci étant dit, j’aime la programmation fonctionnelle. Que de contradictions.

L’effet DSL

Enfin, la mode des DSLs obscurcit elle aussi le débat Java/Scala. Je m’explique:

• En Java, on n’écrit pas de DSL ou alors ultra rudimentaire. Mockito ou FestAssert par exemple.
• En Scala (ou Groovy ou Lisp), on écrit des DSL un peu partout.

Or, le code derrière un DSL est toujours plus difficile à lire que le code utilisant le dit DSL. Peu importe l’outillage ou le langage, un “interpréteur” est plus abstrait, plus exhaustif, plus précis que le code utilisateur.
Tout ca pour dire que comparer la lisibilité d’un code métier Java avec du code implémentant un DSL en Scala est un non sens. Allez lire le code derrière Mockito et riez à l’idée du peu de code nécessaire pour coder ça en Lisp (et sans doute en Scala).

L’effet humain

Bien sur il est humainement possible d’écrire du code métier Java moins expressif qu’une implémentation de DSL en Scala. Ca aussi ça brouille les cartes !

Les lenteurs de l’âge

Personnellement, je suis très bloqué dans mon adoption de Scala par la lenteur de compilation. Pourtant javac 1.0 était beaucoup beaucoup plus lent et je me suis jeté dessus. Trop vieux pour ce genre de conneries…

Sur ce, je retourne faire du Ruby!

If somebody asked me this question “Is it always safe to put/remote ‘final’ keyword on a read only local variable?”, honestly I would have answered “Yes”.

Until I read JavaPuzzlers by Joshua Bloch and Neal Gafter and realized what a little variant of puzzle #8 would look like:

What’s the output of this code?

public static void main(String[] args)
{
    int z1 = 0;
    final int z2 = 0;

    System.out.println(false ? z1 : 'X');
    System.out.println(false ? z2 : 'X');
}

J’aurais l’honneur d’animer le prochain Paris JUG, le 11 janvier.

Triple honneur puisque qu’il s’agit non seulement du premier JUG de l’année 2011, de mon deuxième JUG en tant que présentateur et enfin d’une soirée exceptionnelle animée par moi seul. J’ai une grosse, grosse pression !

Voici le programme, que j’espère vous apprécierez:

Comment j’ai mis ma suite de tests au régime en 5 minutes par jour

Ecrire des tests, toujours plus de tests, une étape nécessaire à tout logiciel de qualité. Seulement, plus il y a de tests, plus le build est long. Plus le build est long, plus il faut de temps pour corriger un bug, plus il faut de temps pour déployer des nouvelles fonctionnalités.

Pour être efficace, un build complet devrait durer moins de cinq minutes. C’est le cas de votre build. Non ? Si tel n’est pas le cas, comment réduire la durée des tests ? Par où commencer ?

Plusieurs stratégies sont efficaces: rendre certains tests inutiles, convertir des tests fonctionnels en tests unitaires, exécuter les tests en parallèle, mettre en commun les lourdes initialisations… De nombreux outils peuvent vous aider en chemin. Partageons des dizaines de conseils pour accélérer vos tests de façon TRES significative.

Attention ! Cette présentations est destinée aussi bien aux fainéants et aux tricheurs, qu’aux courageux. Trois approches à explorer seules ou à combiner.

Techniques de test avancées

A part @Test, quelles fonctionnalités de JUnit4 utilisez-vous ? Les @Rules, les @Datapoints, les @BeforeClass, les @Theories, ça vous parle ?

Et pour rendre les tests plus lisibles, vous préférez les commentaires ou Fest Assert ?
Et pour rendre les test plus rapides, vous savez mocker une seule méthode d’un bean Spring dans les tests fonctionnels avec Mockito ?

Bref, du test, du lourd.

Bonne soirée.

My previous post presents a typical classloading dead-lock. Java classloaders are lazy by nature and when two different threads need to load two classes with a cyclic dependency (A references B, B references A), there is a good chance that the two threads end up being blocked one by the other.

Here is the simplest code I found to show the problem:

public class Main {
    static class A {
        static B B = new B();
    }

    static class B extends A {
        void hello() {
            System.out.println("Hello");
        }
    }

    public static void main(String[] args) throws InterruptedException {
        Thread thread = new Thread() {
            @Override
            public void run() {
                A.B.hello();
            }
        };
        thread.start();
        new B().hello();
        thread.join();
    }
}

You should be able to reproduce the problem. But sometimes, if one thread is for any reason slower than the other one, it will work ok.

I wonder if tools like Sonar, FindBugs or PMD can spot this kind of problem with static code analysis. It seems very easy to do. Any feedback on these tools?

What’s the result of running this piece of code?

a) Done.
b) InterruptedException is thrown
c) It depends
d) Code doesn’t compile

import java.util.Vector;

public class Main {
  interface A {
  }
  
  static class AImpl implements A {
    static AImpl DUMMY = new BImpl();
  }

  interface B extends A {
  }

  static class BImpl extends AImpl implements B {
  }

  public static void main(String[] args) throws InterruptedException {
    final Vector<Object> values = new Vector<Object>();

    Thread thread = new Thread() {
      @Override
      public void run() {
        values.add(AImpl.DUMMY);
      }
    };
    thread.start();
    values.add(new BImpl());
    thread.join();

    System.out.println("Done.");
  }
}