Maven : assurance qualité du code en JAVA

Depuis que j’ai découvert le blog de Frederic Hardy et son outil Atoum pour les tests unitaires en PHP, je m’intéresse beaucoup à l’assurance qualité dans les codes.

Dans le cadre d’un projet scolaire, j’utilise le langage Java pour créer un outil qui fait tourner des algorithmes génétiques à la manière de jgap. Pour ce projet, nous avons à disposition un ensemble d’outils tels que redmine (voir comment intégrer Redmine à Netbeans) ou bien Maven. Au départ nous utilisions Maven surtout pour la gestion des dépendances. En effet, nous avons eu besoin des bibliothèques externes (JFreeChart par exemple) et cela était nécessaire de ne pas se perdre dans nos dossiers avec des classpath locaux.

Ensuite, nous utilisions aussi JUnit pour les tests unitaires. L’avantage alors c’est que Maven, à chaque compilation, exécute les tests : nombreuses heures de débug économisées.

Mais d’ici peu, la deadline arrivera, et comme notre nombre de lignes de code à la minute ne cesse d’augmenter, on s’est rendu compte que parfois nos codes étaient… douteux. J’ai donc pris quelques minutes pour chercher des outils d’analyse du code, j’ai trouvé PMD et FindBugs qui sont très performants. Je les ai fait tourner en parallèle à mon code et finalement, je ne faisais que perdre du temps. Les rapports étaient sur deux logiciels différents, l’ordinateur avait même fini par ralentir (bon, OK, il vieillit quand même). J’ai donc décidé qu’il fallait absolument intégrer ça à Netbeans, ou au moins à Maven. Et j’ai réussi. J’ai par la même découvert des fonctionnalités que je n’attendais pas sur Maven.
Continue reading

Utiliser JFreeChart pour représenter une fonction

Actuellement sur un projet d’optimisation par algorithme génétique, j’ai décidé d’utiliser JFreeChart, un outil de création de diagramme en Java.Cet outil est gratuit mais les tutoriels exemples sont payants, rendant difficile le mimétisme de code, sauf à explorer pendant pas mal de temps stackoverflow.

Le cas d’utilisation que je donne ici est le rendu qui ressemble à celui-ci :

Résultat de l'optimisation

Résultat de l’optimisation

La fonction de base doit être dessinée en continue, puis, les points correspondant aux meilleurs résultats de l’algorithme sous forme de point.

I L’organisation de JFreeChart

Avant de pouvoir dessiner des fonctions avec JFreeChart, il faut comprendre comment un tel dessin est mis en place. Cela permet surtout de savoir dans quelle ordre il faut construire les différents objets.

diagramme UML de JFreeChart

diagramme UML de JFreeChart

Ainsi, il faut commencer par construire les “Series”. Ce sont les ensembles des couples “(t, f(t))”.

Une fois ces Series créées, il faut les ajouter dans une XYSeriesCollection qui doit contenir toutes les séries de données qu’on veut afficher sur le Plot.

Ensuite, la théorie voudrait qu’on crée un Plot puis une Chart. Heureusement, JFreeChart possède des Factory qui prennent en paramètre des XYSeriesCollection :

Le mieux est de créer un ChartPanel, qui étend de JPanel et qui surcharge certaines méthodes afin de mieux redessiner la chart.
Un clic droit sur l’image générée vous permettra de l’enregistrer sous format PNG.

Changer le rendu

Actuellement, nous avons les deux séries qui sont rendues de la même manière.
Nous, ils nous faut un rendu différent selon les séries. Dans notre cas : soit des points soit des lignes.
La configuration à changer dans notre cas, c’est celle du Renderer. Par défaut, les XYChart ont un LineRenderer. Nous, nous allons utiliser le XYLineAndShapeRenderer.

 

Comment un langage lambda peut-il devenir cool?

Dans ce titre un peu étrange se cache un certain enthousiasme : le Java qui m’énerve, me fait râler, me fait faire des choses répétitives, crades (classes anonymes) mais pourtant si stricte qu’on dirait un grand père réac est en train, enfin, de disparaître. Une nouvelle fonctionnalité, les lambda functions arrivera avec Java 1.8 et j’avoue qu’à mon sens ces expressions sont crées en Java de la plus belle manière qui soit, petit aperçu.

Ce qui importe : les parties codantes

J’ai assisté au Ch’ti JUG mardi dernier, la conférence était animé par Rémi FORAX qui a d’emblée mis le doigt sur un problème important en JAVA : la part très importante de cérémonie et de code superflu face aux parties codantes. Eh oui, plus que la déclaration des classes et des fonctions, en JAVA vous pouvez surcharger votre ligne de code avec des “cérémonies” très -trop- nombreuses.

L’idée est donc d’incorporer des fonctionnalités qui feront que les parties codantes seront vraiment plus importantes. Premièrement, on va essayer d’arrêter de créer des classes anonymes quand on veut juste une expression. En plus d’être très inefficace pour différentes raisons (accès disque multipliés…) cela prend pas mal de temps à coder, et en plus c’est difficilement parallélisable. Alors on va créer les fonctions lambda et les expressions statiques.

Par exemple, pour reprendre ce que nous a montré R.Forax, pour lister tous les dossiers contenus dans le dossier courant, la “vieille version” consistait en cela :
[cc lang=”java”]
public class DirectoryLister{
public static File[] listDirectory(File rootDir){
File[] files = rootDir.listFiles(new FileFilter(){
@Override
public boolean accept(File path){
return path.isDirectory();
}
});
return files;
}
public static void main(String[] args){
File root = new File(".");
for(File f: listDirectory(rootDir)){
System.out.println(f);
}
}
}[/cc]
Avec les lambda on peut faire, a première vue :
[cc lang=”java”]
public static File[] listDirectory(File rootDir){
File[] files = rootDir.listFiles((File file)->file.isDirectory());
return files;
}
[/cc]
La syntaxe pour une lambda est [cci lang=”java”](Type1 var1,Type2 var2)->expression[/cci] et si vous avez besoin de plus de lignes :
[cc lang=”java”](Type1 var1,Type2 var2)->{
var1.fonction();
var2.fonction();
return /* ce qu’il y a a retourner*/;
}[/cc]
Mieux encore, comme dans notre exemple il s’agit simplement d’appeler une fonction de l’objet de type File, on peut réduire [cci lang=”java”](File file)->file.isDirectory()[/cci] à
[cci lang=”java”]File::isDirectory[/cci].

Là où Java devient cool : les Stream

Presque tous les langages dynamiques possèdent les fonctions lambda, peu importe leur nom. Mais en Java, quand on réforme le langage (car derrière les lambda, il y a un vrai gros changement de Java quand même), on ne le fait pas pour si peu…
Alors on va créer l’idée des “Streams” et là c’est vraiment immense.
Pour expliquer ce qu’est un stream, rien de mieux qu’un schéma (merci V.Plantevin). Partons d’une collection, un tableau par exemple. Nous voulons le filtrer puis faire une opération sur chaque élément restant.
Les filtres sont dit “méthodes intermédiaires”, alors que le “foreach” est dit “méthode finale”.flux7L’idée c’est que les méthodes intermédiaires vont créer un pipeline extrêmement optimisé et qui peut utiliser toutes les ressources processeur moderne. Ce pipeline n’est construit, à la compilation, que s’il y a une méthode finale : on ne peut pas filtrer un flux sans lui appliquer quelque chose à la fin, sinon le compilateur ne sait pas créer le pipeline.

Alea jacta est

Pour télécharger la dernière version de la JDK 8 :
JDK 8 with lambda
N’hésitez pas à remonter les bugs :
lambda-dev@openjdk.java.net