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+

[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.

[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.

[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.

[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 )

[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 :!

[tchize_]

c'est à proprement parler illisible! Et j'ai du mal à voir l'intérêt par rapport à un assert (ben oui, y a pas qu'en c que assert existe)

[fredusa]

intéressant que ça arrive enfin en java

[darrylsite]

J'ai commencé en java avec un livre sur le C prenant java pour une extension dudit langage et introduisait la notion de contrat dans le langage Java. J'ai passé des mois à écrire les @require, ... dans mon code sans savoir que le JDK n'avait rien à f**tre.

je vais enfin pouvoir réellement utiliser la notion de contrat en java.

Merci google

[Flaburgan]

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

[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.

[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...

[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