Les FAQs Java :
FAQ JAVA FAQ Java EE FAQ Java ME FAQ Java XML FAQ JavaFX FAQ Java GUI FAQ Struts FAQ JSF FAQ JDBC JDO FAQ Hibernate FAQ Spring FAQ Eclipse FAQ NetBeans FAQ JCreator FAQ Maven 2

FAQ JavaConsultez toutes les FAQ

Nombre d'auteurs : 53, nombre de questions : 231, dernière mise à jour : 26 janvier 2014 

 
OuvrirSommaireConcepts fondamentaux

Java est un langage orienté objet développé par la société Sun. La syntaxe générale est très proche de celle du C, mais Java n'est pas une surcouche du C et la syntaxe est beaucoup plus claire que celle du C++.

Les avantages :
Les avantages de Java sont nombreux. Le byte-code, tout d'abord, qui assure à Java une portabilité complète vers de très nombreux systèmes. L'importance de l'api de base qui offre tous les services de base, notamment pour la construction des interfaces graphiques. La 3ème force de Java, c'est son adaptabilité dans de nombreux domaines, autant pour le web que pour les systèmes embarqués.

Liste des Système disposant d'une implémentation de Java :Windows 3.1/95/98/NT4/2000/ME/XP/CE, MacOS, Solaris, Linux, AIX, OS/2, IRIX, UnixWare, HP/UX, Digital Unix, AmigaOS, BeOS, OpenVMS, FreeBSD, SunOS, RiscOS

Cette liste n'est pas exhaustive et est donnée à titre d'exemple.

Mis à jour le 20 décembre 2009  par Clément Cunin

JRE :
Java Runtime Environement, c'est le kit destiné au client pour pouvoir exécuter un programme Java. Il se compose essentiellement d'une machine virtuelle Java (JVM) capable d'exécuter le byte-code et les bibliothèques standard de Java.

SDK :
Standard Development Kit, c'est le kit destiné au programmeur. Ce kit est composé d'un JRE, d'un compilateur et de nombreux programmes utiles, des exemples de programmes Java, les sources de toutes les classes de l'api.

JDK :
Java Development Kit, c'est l'ancien nom du SDK. Le JDK a été renommé SDK depuis la version 1.2.2.

Créé le 26 mars 2002  par Clément Cunin

Windows

Télécharger le JDK
Rendez-vous à cette page pour trouver les dernières versions disponibles.

Téléchargez celui intitulé "JDK 6 Update 5" (en date de cette FAQ). Il contient également le JRE de la même version (donc inutile de télécharger le JDK ET le JRE). Ce téléchargement conviendra à toute utilisation standard de Java : applet, application Desktop, application console.

Installer
Suivez les étapes d'installation. Je vous conseillerais sous Windows d'installer le JDK dans un répertoire C:\Java\jdk_1.6.0_05 (1.6.0_05 pouvant changer selon la version). Idem pour le JRE dans C:\Java\jre_1.6.0_05 . Ceci par commodité et d'éviter ainsi l'utilisation du classique "Program Files" pouvant être pénible à l'utilisation à cause de l'espace.

Il va falloir ensuite positionner la variable d'environnement PATH afin de pouvoir exécuter les programmes du JDK de n'importe où (javac, etc.) :

  • Ouvrez les propriétés du "Poste de travail" ("clic-droit/propriétés" sur l'icône OU "Panneau de configuration/Système").
  • Allez dans l'onglet "Avancé" puis cliquez sur le bouton "Variables d'environnement".
  • Créez une nouvelle variable utilisateur en cliquant sur le bouton "Nouveau".
  • Donnez le nom "Path" et comme valeur le chemin vers le répertoire bin de votre installation du JDK (n'oubliez pas le répertoire "bin").
  • Validez ces modifications en cliquant sur le bouton "OK".
  • Pour tester votre installation, lancez un terminal : Démarrer/Exécuter puis "cmd"
  • Tapez "javac -version", vous devriez avoir ce genre de résultat : "javac 1.6.0_05".

Linux (via apt-get ou synaptic)

Pour télécharger, installer et configurer le JDK, il vous suffit d'installer les derniers paquets proposés dans les dépôts de votre distribution.

Sous Ubuntu par exemple j'ai les paquets sun-java6-jdk, sun-java6-jre et sun-java6-source (sans oublier les dépendances proposées automatiquement). Le 3e, sun-java6-source, permet d'installer le src.zip du JDK contenant les sources. Livré séparément il permet d'avoir une autocomplétion détaillée dans les IDE modernes (à moins que vous ne connaissiez l'API par coeur).

Et voilà ! Vous pouvez compiler du code Java !

Créé le 1er mai 2008  par natha

Lien : Que sont le JRE, le JDK et le SDK ?

Il est possible de le télécharger sur le site suivant:

http://docs.oracle.com/javase/7/docs/webnotes/install/mac/mac-jre.html

Remarque: La dernière version disponible au moment de l'écriture de cette question est la 7.

Pour les versions précédentes, vous pourrez trouver plus d'information sur le site d'Apple.

Mis à jour le 6 août 2013  par bulbo, mlny84

Application :
Une application Java est un programme utilisant le langage de programmation Java et qui tourne généralement sur la machine où se trouve au départ le code. Il a le même but qu'un programme C ou d'un autre langage.

Applet :
L'applet est récupérée à distance à travers un navigateur Web et s'exécute sur celui-ci. En raison de ce téléchargement à distance, les règles de sécurité concernant les applets sont très strictes ( pour éviter notamment les virus ). Par exemple, une applet ( contrairement à une application ), ne permet pas forcément l'écriture sur le disque local ou l'impression.

Servlet :
Une servlet peut être considéré comme une applet coté serveur. Une servlet est destinée à ajouter des fonctionnalités à un serveur web.

Créé le 26 mars 2002  par Clément Cunin

Où ?
Sun distribue le code source de toutes les classes de l'API avec le JDK (installation de composant optionnel !). Vous pouvez donc retrouver les sources dans le fichier 'src.jar', dans le répertoire d'installation du JDK.

Pourquoi ?
Même si cette cette approche n'est pas à conseiller aux débutants, il peut parfois être très utile de consulter le code source des classes l'API. Cela peut permettre, par exemple, d'estimer la complexité de certains algorithmes, ou de mieux comprendre le fonctionnement d'un objet particulier (et ainsi le surcharger plus efficacement). En cherchant bien, on peut également trouver des classes non documentées...

Mis à jour le 6 mai 2002  par Clément Cunin

Lien : Que sont le JRE, le JDK et le SDK ?

JavaWebStart est l'implémentation de référence par Sun/Oracle de la spécification JNLP (JavaNetworkLaunchingProtocol) qui définit un mécanisme d'installation et de mise à jour supportant des fonctionnalités évoluées grâce à HTTP et XML.

L'idée de JWS est de "mimer" le comportement d'une applet pour une application Java. Un serveur héberge l'application ; le client Web Start se connecte au serveur, télécharge l'application et l'exécute. Les règles de sécurité sont semblables à celles des applets.

L'intérêt principal est la facilité de déploiement des applications. Lors d'une mise à jour, seul le serveur est à modifier, les clients téléchargeront la nouvelle application au prochain démarrage. Ce système est très intéressant pour les grosses entreprises qui ne peuvent pas se permettre d'aller mettre à jour une application sur les milliers de postes de leurs collaborateurs.

Les avantages :

  • Fonctionnement en mode déconnecté.
  • Exécution externe au browser -> intégration facile & large support.
  • Mise à jour incrémentale et modulaire des applications.
  • Support d'un exécution sécurisée dans un environnement de type sandbox.
  • Certains services avancés accessibles sans certificat (ouverture d'un flux fichier, sauvegarde d'un flux fichier, mécanisme de persistance entre sessions, impression, téléchargement de ressources, ...).
  • Migration facile depuis une application Java standard.
Mis à jour le 8 août 2013  par Ronan Le Gallo, Clément Cunin, Jean-Baptiste Bugeaud, mlny84

Lien : Tutoriel d'introduction à Java Web Start
Lien : Tutoriel Java Web Start
Lien : Support de cours d'introduction à Java Web Start
Lien : Tutoriel Java Web Start
Lien : Java Web Start Guide
Lien : FAQ Java Web Start
Lien : Forum Java Web Start

Depuis une console :

 
Sélectionnez
java -version

Depuis un programme : Lors de l'exécution, la version de la JVM est accessible via les propriétés système (Comment accéder aux valeurs des variables d'environnement ?).

 
Sélectionnez
String version = System.getProperty("java.vm.version");

Retourne le numéro de version complet de la JVM. Ce numéro peut comporter des informations spécifique. Par exemple : "1.5.0_06-b05"

 
Sélectionnez

String version = System.getProperty("java.version");

Retourne le numéro de version exacte, y compris les éventuelles updates, mais sans informations spécifiques. Par exemple : "1.5.0_06"

 
Sélectionnez

String version = System.getProperty("java.specification.version");

Retourne le numéro de version des spécifications, c'est à dire le numéro de version sans les versions de mises à jours. Par exemple : "1.5"

Créé le 27 janvier 2003  par Clément Cunin

Les variables :
Les noms variables sont écrits en minuscules sauf la première lettre de chaque de mot à partir du deuxième. Il est également recommandé de choisir un nom de variable court mais suffisamment explicite (garder à l'esprit qu'un autre programmeur sera peut-être obligé de comprendre votre code plus tard).

 
Sélectionnez
public int maVariableEntiere;

Note : Une variable peut commencer par le caractère '_' ou '$', mais c'est fortement déconseillé par SUN.

Les constantes :
Afin de bien les différencier des variables ; les constantes sont écrites en majuscule, les mots sont séparés par le caractère '_'.

 
Sélectionnez
public final static int MA_CONSTANTE

Les méthodes :
Le nom des méthodes suit les mêmes règles de construction que les variables, mais le premier mot devrait toujours être un verbe à l'infinitif, suivi éventuellement de mots pour qualifier l'action.

Les classes et interfaces :
Les noms de classes sont écrits en minuscule, chaque première lettre d'un mot est en majuscule.

 
Sélectionnez
public class MaClasse 

Les paquets :
Les noms de paquet sont intégralement écrits en minuscule, sans caractère de séparation. Afin d'éviter au maximum les risques de conflit de nommage, il est recommandé de placer son travail dans un paquet commençant par un nom de domaine internet (com, edu, gov, mil, en, fr, etc ...) suivit du nom de l'organisation ou du projet.

 
Sélectionnez
com.developpez.javaorg.w3c.domorg.xml.sax
Créé le 7 avril 2003  par Clément Cunin

Lien : JavaStyle - Les conventions de codage pour Java

Un décompilateur est un outil permettant de récupérer le code source d'une classe ou d'un ensemble de classes à partir d'un byte code. Sans aller aussi loin, des outils proposent tout simplement l'analyse d'une classe en affichant ses principales caractéristiques.
C'est le cas de javap, disponible dans le SDK.

 
Sélectionnez
E:\>javap java.lang.Object
Compiled from "Object.java"
public class java.lang.Object{
    public native int hashCode();
    static {};
    public java.lang.Object();
    protected void finalize();
       throws java/lang/Throwable
    public final native void notify();
    public final native void notifyAll();
    public final void wait();
       throws java/lang/InterruptedException
    public final native void wait(long);
       throws java/lang/InterruptedException
    public final void wait(long,int);
       throws java/lang/InterruptedException
    public final native java.lang.Class getClass();
    protected native java.lang.Object clone();
       throws java/lang/CloneNotSupportedException
    public boolean equals(java.lang.Object);
    public java.lang.String toString();
}

Pour plus d'informations sur la commande javap :

 
Sélectionnez
javap -help
Créé le 10 août 2004  par Ricky81

Lien : Qu'est qu'un obfuscateur ?

Qu'est que c'est, quel est le but ?
Pour assurer l'indépendance de la plate-forme, les programmes Java sont distribués sous forme de bytecode, cette forme est très proche du code source original. Le bytecode est donc très facile à décompiler ce qui augmente le risque d'une attaque par analyse du code source (reverse engineering). Cette attaque consiste à décompiler une application pour comprendre ce qu'elle fait exactement (dans le cas de la cryptographie) ou pour comprendre comment elle le fait (dans le cas d'espionnage industriel).
Pour se protéger de ce type d'attaque, on peut avoir recours à un "obfuscateur". Il s'agit d'un utilitaire qui transforme le bytecode en un bytecode équivalent mais plus difficile à décompiler.

Comment ça marche ?
Plusieurs techniques permettent de rendre plus difficile la décompilation du bytecode. La première se base sur les principes d'optimisation du code, en réordonnant les micro-instructions. D'autres techniques, plus radicales, changent l'organisation de la mémoire, le nom des identifiants, ajoute du code parasite ou des "goto" : le bytecode est souvent légèrement moins rapide mais surtout très difficile à comprendre.

Quel obfuscateur en Java ?

  • RetroGuard : un des meilleurs obfuscateurs Open Source.
Mis à jour le 3 mai 2002  par Clément Cunin

Lien : Qu'est ce qu'un décompilateur ?

Le PATH n'est pas une notion propre à Java, mais se retrouve dans la plupart (voir la totalité) des systèmes d'exploitations.
Il s'agit d'une variable d'environnement qui contient une liste de répertoires dans lesquels vont être recherchés les fichiers exécutables.

Attention, sous Unix/Linux et assimilé, les chemins sont séparés par deux-points (':'), alors que sous Windows le séparateur est un point-virgule (';').

Ainsi, afin de pouvoir utiliser les outils du JRE/JDK, il peut être nécessaire de modifier le PATH afin d'y ajouter le répertoire bin du JRE/JDK.

On peut modifier le PATH de manière temporaire avec les commandes suivantes (depuis une console) :

Sous Unix/Linux :

 
Sélectionnez

export PATH=$PATH:/_chemin_du_jdk_/bin

Sous Windows :

 
Sélectionnez

set PATH=%PATH%;C:\_chemin_du_jdk_\bin

Il est également possible de définir le PATH de manière définitive :

Sous Unix/Linux, en effectuant la manipulation ci-dessus dans le fichier de configuration de l'utilisateur (~/.bashrc).
Sous Windows via l'onglet "Avancé" des propriétés du poste de travail.

Créé le 16 décembre 2006  par adiGuba

Le CLASSPATH permet de spécifier à la machine virtuel Java les emplacements à partir desquels les resources (bytecode et autres) devront être recherché.
A l'instar de la variable d'environnement PATH, le CLASSPATH se présente sous la forme d'une liste d'éléments, qui peuvent correspondre à un répertoire ou à une archive (*.jar ou *.zip).

Lorsque la machine virtuelle a besoin de charger une resource ou une classe, elle le recherche dans les divers éléments du CLASSPATH dans l'ordre de leur déclaration.

Chaque élément du CLASSPATH correspond à une racine, et les classes sont recherchées dans les sous-répertoires correspondant au nom de leurs packages.

Par exemple, pour un CLASSPATH comportant les deux éléments suivants :

  • Le répertoire /projet/classes
  • L'archive /projet/lib/archive.jar

Lors du chargement de la classe com.monsite.MaClasse, la JVM recherchera d'abord le fichier /projet/classes/com/monsite/Maclasse.class.
Si ce dernier n'existe pas, la JVM recherchera alors le fichier com/monsite/Maclasse.class à l'intérieur de l'archive /projet/lib/archive.jar.

Créé le 16 décembre 2006  par adiGuba

Lien : Comment modifier le CLASSPATH ?

Il y a différentes manières de définir le CLASSPATH.

Lorsqu'on compile ou qu'on lance un programme Java, deux solutions s'offre à nous :

1) En créant une variable d'environnement CLASSPATH.

Exemple Unix/Linux :

 
Sélectionnez

export CLASSPATH=./lib/archive.jar:./classes
java ma.classe.Principale

Exemple Windows :

 
Sélectionnez

set CLASSPATH=./lib/archive.jar;./classes
java ma.classe.Principale

2) En utilisant les options -classpath ou -cp de java/javac.

Exemple Unix/Linux :

 
Sélectionnez

java -classpath ./lib/archive.jar:./classes ma.classe.Principale

Exemple Windows :

 
Sélectionnez

java -classpath ./lib/archive.jar;./classes ma.classe.Principale

Si la variable d'environnement CLASSPATH existe, elle est ignoré et écrasé par l'usage de ces options.

Lorsqu'on exécute un jar exécutable avec l'option -jar de java, les deux solutions précédentes ne fonctionnent pas.
La seule et unique solution consiste à renseigner l'attribut Class-Path de son fichier Manifest. A noter toutefois que le jar exécutable fera automatiquement partie du CLASSPATH.

Lorsqu'on exécute une application Java Web Start, les différents éléments du CLASSPATH sont défini dans le descripteur *.jnlp via l'élément resources.

Remarque : la plupart des EDIs permettent de configurer simplement le CLASSPATH depuis leur interface graphique.

Mis à jour le 2 juin 2007  par adiGuba

Lien : Qu'est-ce que le CLASSPATH ?
Lien : Qu'est-ce que Java Web Start ?
Lien : Comment créer un jar exécutable ?

Le BOOTCLASSPATH fonctionne de la même manière que le CLASSPATH, si ce n'est qu'il est prioritaire sur ce dernier : il est utilisé pour définir les classes standards de l'API. Il dépend donc fortement de la machine virtuelle et ne devrait donc pas être modifié

Il est toutefois possible de le remplacer ou d'y ajouter des éléments à la fin ou en tête de liste avec les options non-standard -Xbootclasspath, -Xbootclasspath/a et -Xbootclasspath/p de la JVM de Sun (reportez-vous à la documentation pour les autres JVM).

Attention toutefois : le fait d'utiliser cette technique pour remplacer une classe du fichier rt.jar (qui comporte toutes les classes standard de l'API) vient à l'encontre de la licence d'utilisation de la JVM de Sun.

Créé le 16 décembre 2006  par adiGuba

Bien que cela ne vienne pas à l'esprit, il existe une taille maximum pour le code d'une méthode sur certaines machines et qui est de 65535 octets. Cela peut sembler énorme et suffisant, ce qui est vrai pour la grande majorité des cas mais avec les editeurs graphiques qui générent du code cette limite peut étre dépassée assez aisément : vous obtientrez alors une erreur du type code too large.

Créé le 25 mars 2007  par afrikha

Lien : Lien sur le sujet

Selon le types des méthodes, Java dispose de quatre mode d'invocation, défini par les instructions invokevirtual, invokespecial, invokestatic et invokeinterface.

  • invokestatic permet d'invoquer les méthodes statiques, qui par définition ne sont lié à aucune instance de classe. La résolution de la méthode est donc effectué lors de la compilation.
  • invokespecial permet d'invoquer les méthodes d'instances qui peuvent être résolues dès la compilation et qui ne dépendent donc pas du type de l'instance, c'est à dire les méthodes privées (private), les appels de méthode de la classe parente (dont l'appel est préfixé par super), ou encore pour les appels de constructeur (ainsi que this() ou super()).
  • invokeinterface permet d'invoquer une méthode sur une référence dont le type est une interface. Etant donné qu'il ne s'agit pas d'un type concret, la résolution de la méthode est forcément effectué à l'exécution selon le type réel de l'instance.
  • Enfin, invokevirtual permet d'invoquer les méthodes d'instances virtuelles d'une classe. C'est à dire que la résolution de la méthode à appeler est effectué lors de l'exécution selon le type réel de l'instance.

Dans tous les cas, la présence, le nombre et le type des paramètres et des valeurs de retour sont vérifié à la compilation.

Ainsi, les méthodes invoqués avec invokeinterface et invokevirtual nécessitent un traitement supplémentaire lors de l'exécution afin de rechercher la bonne méthode selon le type exacte de la référence sur laquelle elles sont utilisées. Toutefois les JVMs modernes peuvent optimiser ce type d'appel de méthodes en se basant sur l'état de l'application (en particulier le nombre et le type des classes chargées).

A noter également l'existence de la JSR-292 pour Java SE 7, dont l'objectif est d'introduire l'instruction invokedynamic afin de mieux supporter les langages de scripts. Cette instruction serait nettement moins contraignante car elle ne vérifierait pas la présence de la signature de méthode dans la classe à la compilation mais seulement lors de l'exécution, et devrait introduire un mécanisme de gestion d'erreur (une méthode par défaut à appeler si la méthode demandée n'existe pas).

Il faut préciser que ces appels se font au niveau du bytecode et non au niveau Java.

Mis à jour le 1er mai 2008  par adiGuba

Lien : JSR 292

Dans le langage, on ne peut spécifier qu'un type pour un paramètre. Ainsi, si une méthode doit utiliser des objets qui implémentent deux interfaces, on ne peut en utiliser qu'un seul dans la définition de la méthode, ce qui oblige à un cast potentiellement dangereux à l'exécution :

 
Sélectionnez

public void method(Serializable data) {
	Comparable cData = (Comparable) data; // throw ClassCastException
	// Traitement ici
}

Ce type de code a le désavantage de provoquer une exception si le type passé en paramètre n'implémente pas la seconde interface.

Avec les Generics de Java 5.0 il est possible de reporter ce problème à la compilation. En effet les Generics ne se limitent pas seulement à paramétrer des classes, ils peuvent également s'appliquer aux méthodes, et ainsi permettent donc de spécifier plusieurs contraintes grâce à la covariance :

 
Sélectionnez

public <T extends Serializable & Comparable<T>> void method(T data) {
	// 'data' implémente les interfaces Serializable et Comparable
	// Traitement ici
}

Dans cet exemple, la méthode est paramétrée par un type T qui implémente à la fois les interfaces Serializable et Comparable<T>. Ainsi, si la méthode est utilisée avec un objet qui n'implémente pas ces deux interfaces, le compilateur génèrera une erreur à la compilation.

Mis à jour le 29 octobre 2008  par adiGuba

Bien que Sun prône une compatibilité ascendante, ce n'est pas toujours le cas.

Déjà il faut prendre en compte deux niveaux de compatibilité : binaire et source.

La compatibilité binaire est celle qui est le plus assuré. Elle permet à un code compilé avec un JDK plus ancien de fonctionner de la même manière sur une JVM plus récente. Toutefois il peut y avoir des exceptions à cela :

  • Un bug ou une régression (personne n'est à l'abri de cela).
  • A l'inverse une correction de bug peut avoir une influence sur les programmes existants et qui font avec.
  • Certain comportement apporté par les nouvelles fonctionnalités peuvent avoir des effets indésirables sur des fonctionnalitées existantes.

La migration d'une application n'est pas aussi simple, et peut poser quelques problèmes malgré la compatibilité ascendante. De ce fait la migration a un coût et elle est généralement retardée. Bien souvent on saute même des versions (je pense que beaucoup d'entreprise vont passer de Java 1.4.2 à la version 6 directement).

Par exemple, le passage à Java 5.0 avait introduit des lenteurs réseaux sur certaines machines, dont l'origine a été assez difficile à cibler. En fait au final il s'agissait d'un bug introduit par le support du protocol NetBIOS et sur la résolution des noms de machine, qui posait problème avec la résolution des adresses IP...

Bref une entreprise ne peut pas forcément se permettre de perdre un temps fou à débugger simplement pour une nouvelle fonctionnalité ! A noter que cela n'est pas propre à Java.

Ensuite, il faut prendre en compte la compatibilité des sources : c'est bien beau qu'un ancien programme fonctionne sur la nouvelle JVM, mais il faut que ce programme puisse être recompilé afin qu'il puisse éventuellement évoluer...

Or c'est déjà nettement plus complexe, car les évolutions du langages ou les modifications de l'API peuvent poser de nouveaux problèmes de compilation, par exemple :

  • L'introduction de nouveau mot-clef (assert, enum) peuvent poser problèlme s'ils étaient utilisé comme identifieur...
  • L'introduction de nouvelle méthode peuvent poser des problèmes de compilation (ambiguité sur la méthode a appelé ou autre problème si des méthodes du même nom existe déjà dans la classe ou les classes filles).
  • Nouveaux warning (en particulier en ce qui concerne les Generics), alors qu'un code "zéro-warning" peut être requis (par le client par exemple).

En bref tout n'est pas aussi simple que cela, même si c'a l'est bien plus que pour d'autre langage/plateforme...

On peut également noter qu'à chaque version, Sun met à disposition une liste des incompatibilitées connues (comprendre volontaire) par rapport à la version précédente :

Créé le 20 décembre 2009  par adiGuba
Les codes sources présentés sur cette page sont libres de droits, et vous pouvez les utiliser à votre convenance. Pour le reste, ce document constitue une oeuvre intellectuelle protégée par les droits d'auteurs. Ce document issu de http://www.developpez.com est soumis à deux licences, en fonction des contributeurs : - Les contributions de Clément Cunin et Johann Heymes sont soumises aux termes de la la licence GNU FDL traduite en français ici. Permission vous est donnée de distribuer, modifier des copies des contributions de Clément Cunin et Johann Heymes tant que cette note apparaît clairement : "Ce document issu de http://www.developpez.com est soumis à la licence GNU FDL traduite en français ici. Permission vous est donnée de distribuer, modifier des copies de cette page tant que cette note apparaît clairement". - Pour ce qui est des autres contributions : Copyright © 2014 Developpez LLC : Tous droits réservés Developpez LLC. Aucune reproduction, ne peut en être faite sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.