IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Idelways

5PARTAGES

2  0 
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
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de lenhat
Membre à l'essai https://www.developpez.com
Le 11/02/2011 à 20:31
Citation Envoyé par Taka-kun Voir le message
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_Mo...eling_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
2  0 
Avatar de aimejeai
Futur Membre du Club https://www.developpez.com
Le 09/03/2011 à 16:22
Pour résumer, quand on écrit une fonction (en Java ou en ??) qui a des paramètres, on a intérêt à se soucier de la validité de ceux-ci, si on veut éviter les bugs.

Dans la programmation par contrat (cf. B Meyer), on établit un contrat entre la fonction et le code client qui appelle la fonction : la fonction peut être écrite en supposant que ses paramètres vérifient une précondition ; en retour, elle garantit son effet par le biais d'une postcondition. Cette notion de contrat est finalement assez naturelle, si on cherche à concevoir proprement.

Par exemple, si on veut écrire une fonction qui interclasse deux tableaux triés, on écrit
- Précondition = les 2 tableaux sont triés
- Postcondition = le tableau résultat est trié et contient exactement tous les éléments des 2 tableaux
Tout le monde bénéficie des avantages de ce contrat : la fonction est plus simple à écrire car elle peut s'appuyer sur l'hypothèse formulée par la précondition ; le code client qui appelle la fonction a la garantie que la fonction a fait son travail correctement.

En Eiffel, préconditions et postconditions sont des formules du calcul des prédicats, sans quantificateur. Ces assertions font partie intégrante de l'interface de la classe.
Pour l'histoire, il faut savoir que Eiffel permet aussi d'écrire d'autres assertions comme les invariants d'itérations et ainsi de réaliser la preuve de l'itération. Pour les programmeurs soucieux d'écrire du code impeccable, c'est un vrai bonheur ....

Pour appliquer ce type de programmation dans un langage dont la définition ne prévoit pas ce mécanisme, comme Java, on peut :

- utiliser JML qui permet d'écrire des pré et post avec quantificateurs, qui fait quelques vérifications pour interdire d'écrire des assertions qui modifient l'état de l'objet, et qui génère du Java.
Malheureusement, JML n'a pas évolué et n'est compatible qu'avec Java 1.4 .... Dommage, c'était bien.

- utiliser assert pour faire de la programmation défensive ; la fonction se défend elle-même contre les mauvais paramètres. Pour prévenir le client qu'une exception peut être déclenchée, on ajoute un commentaire en langage naturel avec la balise @exception.
Pour éviter toute mauvaise surprise, le programmeur est tenu de n'utiliser dans un assert que des fonctions qui observent l'objet, mais qui, surtout, ne le modifient pas, de sorte que si on désactive les assert (option -ea de java), le programme fonctionne de la même façon. Mais, le programmeur fait ce qu'il veut, le compilateur ne vérifie rien ......
Dans un assert, on ne peut pas utiliser de quantificateur ; pour écrire une propriété vraie sur un intervalle on est obligé d'écrire une fonction booléenne qui fait le test.
On utilise rarement assert à la fin de la fonction pour vérifier son bon fonctionnement, mais on pourrait le faire pour vériier la postcondition.

Donc pour résumer, si Java doit intégrer les pré et post, ce sera une bonne chose. S'il pouvait aussi intégrer les invariants d'itérations, on ne verrait peut-être plus trainer du code Java avec 2 itérations imbriquées et un return pour en sortir ......
Il reste à former les programmeurs pour utiliser les assertions et les inciter à bannir le bricolage. Tout un programme ....
2  0 
Avatar de frfancha
Membre éprouvé https://www.developpez.com
Le 11/02/2011 à 13:41
Citation Envoyé par kaymak Voir le message

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.
1  0 
Avatar de Flaburgan
Modérateur https://www.developpez.com
Le 11/02/2011 à 14:02
Ça existe en Ada depuis les années 70
heure : integer (1..23);
1  0 
Avatar de cyrus.31
Futur Membre du Club https://www.developpez.com
Le 11/02/2011 à 15:03
Vous croyez qu'il est possible d'ajouter la contrainte value != 2.2250738585072012e-308 ?
1  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 12/02/2011 à 1:44
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)
1  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 12/02/2011 à 1:47
Citation Envoyé par YannPeniguel Voir le message


Mais son usage est peu répandu.
a tord. Et souvent les assertion sont déactivées en production, encore plus à tord (c'est bien en production que t'as besoin de te rendre compte que t'as une valeur folle!, En test, tu teste ce que tu prévois, avec les assert tu teste l'imprévu)
1  0 
Avatar de ManusDei
Expert confirmé https://www.developpez.com
Le 11/02/2011 à 13:07
Ca me fait penser à mes tests JUnit.
0  0 
Avatar de kaymak
Membre émérite https://www.developpez.com
Le 11/02/2011 à 13:22
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+
0  0 
Avatar de kaymak
Membre émérite https://www.developpez.com
Le 11/02/2011 à 13:49
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+
0  0