Discussion :

[Idelways]

Java : Google introduit la programmation par contrat
Avec une extension open source qui aiderait aussi à sécuriser les programmes



Google vient de passer sous licence open source un projet destiné à introduire la programmation par contrat au langage Java.

Ce paradigme de conception logiciel initié pour le langage Eiffel devrait faciliter le développement et aider la détection précoce des imperfections dans les premières phases de créations du code.

Ce nouveau projet, appelé Cofoja (contraction de « Contracts For Java ») devrait également permettre de sécuriser les applications contre les exploits de type dépassement de tampon notamment, véritable plaie de sécurité pour Java - comme pour d'autres langages.

Concrètement, la programmation par contrats définit des critères auxquels doit correspondre chaque valeur passée à une méthode d'un programme en exécution. Des critères peuvent aussi être spécifiés aux valeurs de retour de ces méthodes.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
interface Time {
  ...
 
  @Ensures({
    "result >= 0",
    "result <= 23"
  })
  int getHour();
 
  @Requires({
    "h >= 0",
    "h <= 23"
  })
  @Ensures("getHour() == h")
  void setHour(int h);
 
  ...
}

Il s'agit donc de contrats entre les composants du même programme qui assurent l'intégrité de ce dernier et aident à réduire considérablement le nombre de bogues, qui sont détectés plus tôt dans le cycle de développement.

Un concept aux objectifs similaires à ceux de la programmation pilotée par les testes (TDD) sauf que les assertions avec Cofoja sont écrites et testées directement dans le programme et non pas dans des classes dédiées aux tests et exécutées séparément durant cette phase.

Les développeurs Java pourront donc définir des contrats sur la longueur des valeurs d'entrées éliminant ainsi le risque d'attaques par dépassement de tampon.

Cofoja s'appuie sur le projet « Modern Jass », un ensemble d'annotations Java développées par Johannes Rieken et repris par deux ingénieurs à temps partiel.



Le projet Cafoja est disponible sur Google code sous licence LGPL

Source : le blog de Google open source

Et vous ?

Que pensez-vous de ces extensions ?

[ManusDei]

Ca me fait penser à mes tests JUnit.

[kaymak]

J'ai du mal à percevoir la place à lui donner entre
- le typage fort
L'exemple donné, n'est finalement qu'une définition de type déguisée, exprimée autrement.
- le découplage des métiers
L'exemple donné est simpliste, mais au vu de ce qui est présenté, on pourrait imaginer mettre des règles relatives aux métiers. Mais pour autant, ce n'est pas son rôle. Ne serait ce que par le fait qu'aucune modalité de réponse n'est proposée.

Pour autant ce n'est pas du test comme on peut l'avoir entendu jusqu'à présent, puisque on valide cette règle jit*, et non à postériori dans le scénario d'un cas de test.

* D'après ce que j'ai compris ici :

Concrètement, la programmation par contrats définit des critères auxquels doit correspondre chaque valeur passée à une méthode d'un programme en exécution.

Bref, je trouve l'idée sympa au départ, et je suis sur qu'elle sera utile dans l'état actuelle des choses, mais il y à quand même quelque chose qui me chiffonne.

a+

[frfancha]

J'ai du mal à percevoir la place à lui donner

Il faut lire le bouquin OOSC2 et cela devient clair (tout programmeur devrait l'avoir lu d'ailleurs, c'est une base de l'informatique).

Object-Oriented Software Construction, 2nd Edition by Bertrand Meyer.
Prentice Hall Professional Technical Reference.
1254 + xxviii pp.
Soft cover.
ISBN 0-13-629155-4
This Jolt Award winner takes the reader through the clear, logical, and comprehensive formation of a method for object-oriented software development ... the Eiffel method. During this journey, the author evolves a notation capable of expressing the products of each phase of development, from analysis through implementation. This notation is Eiffel the language.

[kaymak]

Bon, si vraiment il faut en passer par la lecture complète du bouquin.... J'ai plus qu'à !
http://fr.wikipedia.org/w/index.php?...=0-13-629155-4


merci,
a+

[Flaburgan]

Ça existe en Ada depuis les années 70
heure : integer (1..23);

[Phelim]

Le livre de Bertrand Meyer est traduit en français pour les programmeurs qui ne sont pas à l'aise avec l'anglais.

C'est nettement moins bien que l'original certes mais déjà que ce livre est très complet et les concepts parfois délicats, devoir décrypter le rend difficile à lire.

Titre : Conception et programmation orientées objet
ISBN : 978-2212122701

Je rejoins l'avis d'au dessus, un livre à lire, à relire et à avoir dans sa bibliothèque pour le consulter très souvent.

Les contrats ne remplacent pas les tests unitaires et inversement, ce sont 2 concepts complémentaires. Utiliser l'un ne signifie pas que l'on utilise pas l'autre, au contraire.

[YannPeniguel]

La définition de conditions booléennes dans des chaines de caractères, c'est vraiment pas beau.

Ça existe en Ada depuis les années 70
heure : integer (1..23);

J'ai été voir des docs sur ADA, que je ne connaissais que de nom.

Effectivement, on borne à la déclaration, c'est plus propre.

Cela dit, rendons à César ce qui est à César: Un manque du Java est comblé grâce à ce projet.

[lenhat]

J'ai du mal à percevoir la place à lui donner entre
- le typage fort
L'exemple donné, n'est finalement qu'une définition de type déguisée, exprimée autrement.

L'idée du typage fort est intéressante et c'est une perspective que j'aime bien, personnellement. On peut voir les contrats comme une extension dynamique (à l'exécution) du typage. Les contrats permettent potentiellement de spécifier n'importe quelle condition (avec les limitation de portée et de condition d'activation qui leur sont intrinsèques), potentiellement très difficile à vérifier statiquement. Cette difficulté relève en partie de défis théoriques mais en pratique surtout du fait que les spécifications sous forme de contrats sont rarement assez complètes pour permettre une analyse statique aboutie.

[thelvin]

Ça existe en Ada depuis les années 70
heure : integer (1..23);

On n'a jamais dit que c'était un concept nouveau, juste que Google proposait une manière de le mettre en Java.

Bon, et puis, les contrats ça va un tout petit peu plus loin que borner les paramètres d'entrée ou fortifier le typage, 'faut arrêter de se toucher, les gens.

[cyrus.31]

Vous croyez qu'il est possible d'ajouter la contrainte value != 2.2250738585072012e-308 ?

[Tcharl]

C'est n'est pas vraiment de la programmation par contrat, mais de l'assertion.
Il faut quand même écrire le code derrière...

[YannPeniguel]

J'ai du mal à percevoir la place à lui donner entre
- le typage fort
L'exemple donné, n'est finalement qu'une définition de type déguisée, exprimée autrement.
- le découplage des métiers
L'exemple donné est simpliste, mais au vu de ce qui est présenté, on pourrait imaginer mettre des règles relatives aux métiers. Mais pour autant, ce n'est pas son rôle. Ne serait ce que par le fait qu'aucune modalité de réponse n'est proposée.

Pour autant ce n'est pas du test comme on peut l'avoir entendu jusqu'à présent, puisque on valide cette règle jit*, et non à postériori dans le scénario d'un cas de test.

* D'après ce que j'ai compris ici :


Bref, je trouve l'idée sympa au départ, et je suis sur qu'elle sera utile dans l'état actuelle des choses, mais il y à quand même quelque chose qui me chiffonne.

a+

Le typage fort n'est pas la réponse à tout, dans l'exemple donné avec les heures, tu ne peux pas déclarer un int qui reste dans [0;24[ en Java, du moins pas sans librairie/extension.

Tu es donc obligé de te débrouiller avec les accesseurs, ou maintenant avec cofoja.

[Taka-kun]

Java : Google introduit la programmation par contrat
pas du tout mais vraiment pas du tout

Google à souvent tendance à reprendre des élements existants déjà... Ils ne connaissent donc pas JML ?

Je me demande ce que cette extension va apporter de plus par rapport à JML qui existe depuis un petit bout de temps.

http://fr.wikipedia.org/wiki/Java_Modeling_Language

[teddyalbina]

ça existe depuis longtemps en .net

http://msdn.microsoft.com/en-us/devlabs/dd491992

C'est même intégré dans VST 2010

[Uther]

Google à souvent tendance à reprendre des élements existants déjà... Ils ne connaissent donc pas JML ?

Je me demande ce que cette extension va apporter de plus par rapport à JML qui existe depuis un petit bout de temps.

http://fr.wikipedia.org/wiki/Java_Modeling_Language

Je ne connaissait pas JML mais d'après ton article, ça a l'air de reposer sur l'analyse des commentaires, je trouve l'approche des annotations choisies par Google plus logique.

[gorgonite]

Le typage fort n'est pas la réponse à tout, dans l'exemple donné avec les heures, tu ne peux pas déclarer un int qui reste dans [0;24[ en Java, du moins pas sans librairie/extension.

Tu es donc obligé de te débrouiller avec les accesseurs, ou maintenant avec cofoja.

et c'est bien cela le problème... en ne disposant d'un véritable typage fort, nombre de tests sont reportés à l'exécution (ce que nombre de développeurs Java reprochent aux langages plus dynamiques comme Python )
alors il est clair que le message d'erreur sera bien plus explicite... mais ça revient aux assert insérés dans les codes C ou C++, et un jour on voit apparaître les static_assert pour tout ce qui est possible de faire dès la compilation (optimisations quand tu nous tiens )

[lenhat]

Java : Google introduit la programmation par contrat
pas du tout mais vraiment pas du tout

Google à souvent tendance à reprendre des élements existants déjà... Ils ne connaissent donc pas JML ?

Je me demande ce que cette extension va apporter de plus par rapport à JML qui existe depuis un petit bout de temps.

http://fr.wikipedia.org/wiki/Java_Modeling_Language

C'est malheureusement une critique qui revient souvent. D'une part, oui, on connait JML, mais cela ne correspondait pas à nos besoins, donc on a choisi de partir de Modern Jass. Il y a une bonne dizaine de frameworks de programmation par contrats en Java (voyez ma réponse sur Hacker News[0]), et on en a choisi un en particulier parce qu'il fallait bien faire un choix, et que c'était celui qui nous convenait le mieux.

Quant aux différences JML vs Cofoja, du point de vue de l'utilisateur, j'ai répondu à la même question sur r/programming[1], il y a une semaine et je vais résumer ici : JML est plus complet, plus gros, fait beaucoup plus que des contrats, utilise sa propre toolchain, et a tendance à traîner le pied au niveau du support de nouvelles constructions dans le langage Java (du fait de la richesse des fonctionnalités qu'ils proposent, ajouter n'importe quelle construction au langage nécessite d'étendre le modèle conceptuel des spécifications JML de manière cohérente, ce qui n'est pas évident[2]).

Le principal problème qui a fait que l'on a éliminé JML de nos options assez tôt est qu'il utilise sa propre toolchain, dont la version stable ne supporte pas Java 6, et ce n'était absolument pas envisageable de faire migrer des portions entières de code Google sous une boucle de compilation différente. Au-delà du défi technique que cela représente, ce serait beaucoup trop risqué en termes d'ingénierie et un tel projet n'aurait jamais vu le jour à Google. Cofoja, et son prédecesseur Modern Jass, s'intègrent aux outils standards de Java, via des APIs standards; la syntaxe n'est peut-être pas idéale (les chaînes de caractères dans les annotations) mais le framework est utilisable « immédiatement » de manière très peu intrusive dans n'importe quel projet Java (et même GWT en mode Java).

Liens (en anglais) :
[0] http://news.ycombinator.com/item?id=2183504
[1] http://www.reddit.com/r/programming/...r_java/c1flbip
[2]*http://citeseerx.ist.psu.edu/viewdoc...0.1.1.159.6215

[kaymak]

Merci pour vos infos, et remarques et réponses : )

@YannPeniguel, @lenhat, OK, je comprend tout à fait vos remarques.

[/QUOTE]Bon, et puis, les contrats ça va un tout petit peu plus loin que borner les paramètres d'entrée ou fortifier le typage, 'faut arrêter de se toucher, les gens.[/QUOTE]
Alala on eu aimé que tu ai autant entrain à nous expliquer ce que TOI tu sais de ces contrats mais pas nous autres indigent :!

[YannPeniguel]

et c'est bien cela le problème... en ne disposant d'un véritable typage fort, nombre de tests sont reportés à l'exécution (ce que nombre de développeurs Java reprochent aux langages plus dynamiques comme Python )
alors il est clair que le message d'erreur sera bien plus explicite... mais ça revient aux assert insérés dans les codes C ou C++, et un jour on voit apparaître les static_assert pour tout ce qui est possible de faire dès la compilation (optimisations quand tu nous tiens )

Le mot clé assert existe en Java et fonctionne très bien!

Mais son usage est peu répandu.