FAQ Langage JavaConsultez toutes les FAQ

Java est un langage orienté objet développé initialement par la société Sun Microsystems puis par Oracle. La syntaxe générale est très proche de celle du C, mais Java n'est pas une surcouche du C et sa 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^e 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èmes disposant d'une implémentation de Java : Microsoft Windows, MacOS, Solaris, Linux, AIX, OS/2, IRIX, UnixWare, HP/UX, Digital Unix, AmigaOS, BeOS, OpenVMS, FreeBSD, SunOS, RiscOS. Java est également supporté par des familles de processeurs différents Intel 32 et 64 bits, ARM...

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

Il existe plusieurs distributions de Java.

Java SE
Java SE (Standard Edition ou « édition standard ») est la version de Java destinée aux ordinateurs de bureau, portables et certaines plateformes embarquées ou smartphones disposant des capacités de calcul, de mémoire et de stockage suffisantes pour la faire fonctionner. Cette version de Java définit une API standard présente à l'identique sur toutes les plateformes et permettant ainsi de créer des applications en ligne de commande ou graphiques qui peuvent s’exécuter sur un grand nombre de machines. Lorsque nous parlerons de JDK, JVM, JRE dans cette FAQ, nous ferons principalement référence à Java SE.

Cette FAQ se concentre donc principalement sur Java SE ; cependant, beaucoup de concepts abordés ici sont également applicables aux autres versions de Java. Des concepts avancés de Java SE ou nécessitant des extensions tierces telles que le graphisme ou les interfaces graphiques, les accès aux bases de données, etc. sont présentés dans des FAQ plus spécialisées.

Java ME
Java ME (Micro Édition ou « édition micro ») est la version de Java destinée aux plateformes embarquées, cartes de paiement, consoles et lecteurs de disques, téléphones et autres périphériques disposant de capacités de calcul, de mémoire ou de stockage limitées. Cette plateforme définit un grand nombre de configurations et de profils pour prendre en compte un large panel d'appareils aux capacités très différentes les unes des autres. Pour les questions spécifiques à la plateforme Java ME, veuillez vous référer à la FAQ Java ME sur Développez.

Java EE
Java EE (Enterprise Edition ou « édition entreprise ») est la version de Java destinée aux serveurs d'entreprises et serveurs web pour implémenter des services réseau et web. Elle inclut Java SE, mais dispose également d'API supplémentaires pour définir des mapping objet-relationnel, des architectures multicouches ou distribuées et des web services. Pour les questions spécifiques à la plateforme Java EE, veuillez vous référer à la FAQ Java EE sur Développez. Des FAQ plus spécialisées sont également disponibles pour certains frameworks de développement.

Android
Android est une version spéciale de Java conçue par Google pour tourner sur sa propre machine virtuelle Dalvik tournant sur Linux sur des périphériques embarqués, téléphones, tablettes, montres, bracelets de course, etc. Google a repris une partie de l'API JavaSE et y a ajouté une API Android propre à la plateforme. Pratiquement tous les concepts abordés dans cette FAQ sont applicables à Android sous réserve du niveau de compatibilité entre la version du JDK mentionnée dans les QR et la version du SDK Android que vous utilisez. Pour les questions spécifiques à la plateforme Android, veuillez vous référer à la FAQ Android sur Développez.

La notion de profil est déjà connue par les utilisateurs de Java ME. Nous venons de dire que l'API Java SE était identique sur toutes les plateformes, mais, en fait, ce n'est pas tout à fait vrai. À partir du JDK 8, Oracle a défini plusieurs sous-profils de manière à pouvoir utiliser Java SE sur des plateformes dites Embedded (mobiles et embarquées) aux capacités limitées (calcul, mémoire, stockage, etc.) :

• compact1 - classes centrales + classes utilitaires (collections, sérialisation, concurrence, expressions régulières et manipulation du texte, temps et dates, etc.) + IO (fichiers, entrées/sorties, archives et réseau) + NIO + cryptographie + internationalisation + JNI + scripting + journalisation + sécurité (X500) ;
• compact2 - compact1 + RMI + JDBC (basique) + XML JAXP (SAX et DOM) ;
• compact3 - compact2 + console de gestion + instrumentation + JDBC (rowset) + XML JAXP (cryptographie) + sécurité (ACL) ;
• Full SE API - compact3 + préférences utilisateur + beans + CORBA + RMI-IIOP + AWT + Swing + Java2D + JavaSound + ImageIO + accessibilité + print services + toutes les extensions habituellement distribuées avec le JDK de JavaSE.
  

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.

JDK : Java 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 du langage.

Vous avez plusieurs façons d'installer le JDK. Vous pouvez récupérer un installeur ou une archive contenant un JDK précompilé ou encore vous pouvez tenter de compiler les sources disponibles dans le cadre de l'OpenJDK.

Disponibilité
Oracle
Oracle fournit sur la page téléchargements Java des installeurs ainsi que des archives contenant un JDK précompilé pour Linux (x86, x64 et ARM), Windows (x86 et x64), Mac OS X ainsi que Solaris (x64 et SPARC 64). Oracle fournit également un JDK précompilé pour les plateformes ARM tournant sous Linux.

OpenJDK
Vous pouvez tenter de récupérer et de compiler les sources disponibles sur le Mercurial de l'OpenJDK.

Pour les utilisateurs de Linux, il est également possible d'installer des paquets précompilés via le service de mises à jour de la plupart des distributions (yum, apt-get, etc.) en suivant les instructions disponibles sur cet article.

Installation
Windows
Si vous utilisez un installeur, suivez les étapes d'installation. L'installeur du JDK vous proposera également d'installer le JRE équivalent sur votre système.

Si vous utilisez une archive, décompressez-la dans un répertoire vide.

Dans les deux cas, il va vous falloir ensuite positionner la variable d'environnement PATH afin de pouvoir invoquer les programmes du JDK (javac, etc.) depuis la ligne de commande.

• Ouvrez les propriétés du Poste de travail (clic-droit -> Propriétés sur l'icône) ou allez dans 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 :

  Code cmd :

  Sélectionner tout

  %PATH%;<Chemin d'installation du JDK>\bin

  Si le chemin d'installation du JDK contient des espaces (ex. : Program Files), n'oubliez pas de mettre des guillemets autour. Par exemple :

  Code cmd :

  Sélectionner tout

  %PATH%;"C:\Program Files\jdk1.8.0_40\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 voir s'afficher le numéro de version du JDK que vous venez d'installer.
  

Vous avez plusieurs façons d'installer le JRE.Vous pouvez récupérer un installeur ou une archive contenant un JRE précompilé ou encore vous pouvez tenter de compiler les sources disponibles dans le cadre de l'OpenJDK.

Disponibilité
Oracle
Oracle fournit sur la page téléchargements Java des installeurs ainsi que des archives contenant un JRE précompilé pour Linux (x86, x64 et ARM), Windows (x86 et x64), Mac OS X ainsi que Solaris (x64 et SPARC 64).

OpenJDK
Vous pouvez tenter de récupérer et de compiler les sources disponibles sur le Mercurial de l'OpenJDK.

Pour les utilisateurs de Linux, il est également possible d'installer des paquets précompilés via le service de mises à jour de la plupart des distributions (yum, apt-get, etc.). La plupart des distributions Linux fournissent des JRE précompilés basés sur l'OpenJDK.

Installation
Windows
Si vous utilisez un installeur, suivez les étapes d'installation. Sur les versions 64 bits de Windows, il est recommandé d'installer à la fois les versions 32 bits et 64 bits du JRE.

• La version 64 bits sera utilisée par le système d'exploitation et les navigateurs web 64 bits.
• La version 32 bits sera utilisée par les navigateurs web 32 bits. Elle sera utilisée par le système d'exploitation si la version 64 bits est absente.
  

• Ouvrez les propriétés du Poste de travail (clic-droit -> Propriétés sur l'icône) ou allez dans 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 :

  Code cmd :

  Sélectionner tout

  %PATH%;<Chemin d'installation du JRE>\bin

  Si le chemin d'installation du JDK contient des espaces (ex. : Program Files), n'oubliez pas de mettre des guillemets autour. Par exemple :

  Code cmd :

  Sélectionner tout

  %PATH%;"C:\Program Files\jre1.8.0_40\bin"

• Validez ces modifications en cliquant sur le bouton OK.
• Pour tester votre installation, lancez un terminal : Démarrer -> Exécuter puis cmd
• Tapez « java -version », vous devriez voir s'afficher le numéro de version du JRE que vous venez d'installer.
  

Le PATH n'est pas une notion propre à Java, mais se retrouve dans la plupart (voire la totalité) des systèmes d'exploitation. 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és, les chemins sont séparés par un 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 ou Mac OS X ou n'importe quel système disposant de Bash :
  

  Code bash :

  Sélectionner tout

  export PATH=$PATH:/_chemin_du_jdk_/bin

• sous Windows :
  

  Code cmd :

  Sélectionner tout

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

• sous Unix/Linux, en effectuant la manipulation ci-dessus dans le fichier de configuration de l'utilisateur (ex. : ~/.bashrc ou ~/.bash_profile).
• sous Windows via l'onglet Avancé des propriétés du Poste de travail.
  

Oui, Java est open source.

Depuis 2006, Sun Microsystems a mis en place l'initiative OpenJDK pour gérer et gouverner les évolutions du langage et de son API de manière collaborative et ouverte. Il faut noter toutefois que les sources du JDK étaient déjà disponibles ouvertement auparavant, mais sous licence Sun.

Outre Oracle Corporation, qui a pris la relève de Sun Microsystems, d'autres grandes compagnies de l'informatique telles qu'IBM et Apple participent activement à l'OpenJDK.

Depuis la mise en place de l'OpenJDK, les sources de Java sont disponibles sous licence GPL avec exception de liaison (GNU General Public License with a linking exception), ce qui fait qu'un programme, une bibliothèque ou une API Java tierce qui utilisent l'API Java n'ont pas obligation d’être eux-mêmes sous licence GPL.

Depuis Java SE 7, l'OpenJDK sert d’implémentation de référence de la JVM.

La version OpenJDK de Java est intégralement open source et sous licence GPL avec exception de liaison. Les bibliothèques tierces sur lesquelles se repose l’implémentation de la JVM sont également sous licence open source.

Oracle fournit, dans ses paquets précompilés, des binaires et des codes source sous licence Oracle. De plus, ces distributions peuvent contenir des bibliothèques tierces sur lesquelles se repose l’implémentation de la JVM qui ont été licenciées par Oracle auprès d’éditeurs externes. Le code source de ces bibliothèques est donc propriétaire et n'est pas disponible. Oracle peut également intégrer dans sa JVM des optimisations ou des options destinées à ses clients payants.

Il peut en être de même pour tout éditeur qui fournit une JVM propriétaire pour un système particulier.

Ainsi, bien que l’implémentation de l'API Java soit à la base identique (puisque l'OpenJDK sert d’implémentation de référence), outre des optimisations du garbage collector ou des API internes, il peut y avoir quelques différences notables de comportement entre la version OpenJDK et une version propriétaire. Par exemple, pendant longtemps, le rasteriser des polices de caractères ne produisait pas des résultats similaires sur les plateformes Linux.

Oracle distribue le code source des classes de l'API publique Java avec le JDK. Vous pouvez donc retrouver les sources dans le fichier src.zip, dans le répertoire d'installation du JDK.

Ce fichier peut contenir également une partie de l’implémentation de l'API privée Java. Attention cependant, les sources de l'API privée peuvent être lourdement modifiées, devenir obsolètes ou dépréciées ou même être retirées d'une version à l'autre du JDK. Vous ne devez donc pas vous reposer sur ces classes.

Vous pouvez également accéder au code source des classes Java en accédant au projet OpenJDK qui est l'implémentation libre et open source de Java Platform Standard Edition.

Même si cette approche n'est pas à conseiller aux débutants, il peut parfois être très utile de consulter le code source des classes de 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...

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ée comme une Applet côté serveur. Une servlet est destinée à ajouter des fonctionnalités à un serveur web.

Java Web Start est l'implémentation de référence par Oracle de la spécification JNLP (Java Network Launching Protocol) 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 navigateur -> intégration facile et large support.
• Mise à jour incrémentale et modulaire des applications.
• Support d'une exécution sécurisée dans un environnement de type sandbox (bac à sable).
• 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.
  

Depuis une console :

java -version

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

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

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

Les variables
Les noms de variables sont écrits en minuscules sauf la première lettre de chacun des mots à 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).

public int maVariableEntiere;

public final static int MA_CONSTANTE = 2;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// Un getter commence par le verbe get (obtenir). 
public int getValue() { 
   [...] 
} 
  
// Un setter commence par le verbe set (définir). 
public void setValue(final int value) { 
   [...] 
} 
  
// Une méthode d'ajout commence par le verbe add (ajouter) 
public void addMouseListener(final MouseListener listener) { 
   [...] 
} 
  
// Une méthode de retrait commence par le verbe remove (retirer) 
public void removeMouseListener(final MouseListener listener) { 
   [...] 
} 
  
// Une méthode d'action peut commencer par le verbe do (faire, agir) 
public void doClick() { 
   [...] 
} 
  
// Une méthode factory (de construction) peut commencer par le verbe create (créer) 
public Car createNewCar(final Color color, final int doorNumber, final boolan driverOnLeft, final CarOption... options) { 
   [...] 
}

public class MaClasse

1
2
3
com.developpez.java 
org.w3c.dom 
org.xml.sax

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ javap java.lang.Object 
Compiled from "Object.java" 
public class java.lang.Object { 
  public java.lang.Object(); 
  public final native java.lang.Class<?> getClass(); 
  public native int hashCode(); 
  public boolean equals(java.lang.Object); 
  protected native java.lang.Object clone() throws java.lang.CloneNotSupportedException; 
  public java.lang.String toString(); 
  public final native void notify(); 
  public final native void notifyAll(); 
  public final native void wait(long) throws java.lang.InterruptedException; 
  public final void wait(long, int) throws java.lang.InterruptedException; 
  public final void wait() throws java.lang.InterruptedException; 
  protected void finalize() throws java.lang.Throwable; 
  static {}; 
}

$ javap -help

• Procyon ;
• CFR ;
• Candle ;
• Krakatau ;
• JBVD ;
• EDJC ;
• JD ;
• FernFlower ;
• DCompiler ;
• JDec.
  

Qu'est-ce que c'est, quel est le but ?
Pour assurer l'indépendance de la plateforme, 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 ?

• ProGuard
• yGuard - Java™ Bytecode Obfuscator and Shrinker
  

Le CLASSPATH permet de spécifier à la machine virtuelle Java les emplacements à partir desquels les ressources (bytecode et autres) devront être recherchées.
À 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 ressource ou une classe, elle la 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.
  

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

Lorsqu'on compile ou qu'on lance un programme Java, plusieurs solutions s'offrent à nous.

• En créant une variable d'environnement CLASSPATH.
  
  • Exemple Unix, Linux, Mac OS X ou n'importe quel système disposant de Bash :
    

    Code bash :

    Sélectionner tout

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

  • Exemple Windows :
    
    

    Code cnd :

    Sélectionner tout

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

• En utilisant les options -classpath ou [/c]-cp[/c] des outils java, javac, etc.
  
  • Exemple Unix, Linux, Mac OS X ou n'importe quel système disposant de Bash :
    
    

    Code bash :

    Sélectionner tout

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

  • Exemple Windows :
    
    

    Code cmd :

    Sélectionner tout

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

  
  Si la variable d'environnement CLASSPATH existe, elle est ignorée et écrasée par l'usage de ces options.
• En utilisant l'option -jar et le fichier manifeste pour une archive jar exécutable.
  
  Lorsqu'on exécute un jar exécutable avec l'option -jar de java, les options -classpath ou -cp et la variable d'environnement CLASSPATH sont ignorées.
  La seule et unique solution consiste à renseigner l'attribut Class-Path de son fichier META-INF/MANIFEST.MF. À noter également que le jar exécutable fera automatiquement partie du CLASSPATH.
  
  

  Code texte :

  Sélectionner tout

  1
  2
  3
  Manifest-Version: 1.0 
  Main-Class: com.toto.monappli.MaClasseMain 
  Class-Path: libtoto.jar lib/truc.jar lib/machin.jar

  
  Les éléments du Class-Path du fichier manifeste représentent un chemin relatif dépendant de l'emplacement du jar principal (attention : le métacaractère « * » ne peut pas être utilisé ici).
• Lorsqu'on exécute une application Java Web Start, les différents éléments du CLASSPATH sont définis dans le descripteur *.jnlp via l'élément resources .
  

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 standard 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 d'Oracle (reportez-vous à la documentation pour les autres JVM).

Attention : 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 d'Oracle.

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 65 535 octets. Cela peut sembler énorme et suffisant, ce qui est vrai pour la grande majorité des cas, mais avec les éditeurs graphiques qui génèrent du code, cette limite peut être dépassée assez aisément : vous obtiendrez alors une erreur du type code too large.

Selon le type des méthodes, Java dispose de cinq modes d'invocation définis par les instructions invokevirtual, invokespecial, invokestatic, invokeinterface et invokedynamic :

• invokestatic - permet d'invoquer les méthodes statiques, qui par définition ne sont liées à aucune instance de classe. La résolution de la méthode est donc effectuée 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. Étant donné qu'il ne s'agit pas d'un type concret, la résolution de la méthode est forcément effectuée à l'exécution selon le type réel de l'instance ;
• 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ée lors de l'exécution selon le type réel de l'instance ;
• invokedynamic - défini depuis Java SE 7 et détaillé dans la JSR-292 permet de mieux supporter les langages de scripts. Cette instruction est nettement moins contraignante, car elle ne vérifie pas la présence de la signature de méthode dans la classe à la compilation, mais seulement lors de l'exécution, et introduit un mécanisme de gestion d'erreurs (une méthode par défaut à appeler si la méthode demandée n'existe pas).
  

Bien que Oracle 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.

Compatibilité binaire
La compatibilité binaire est celle qui est le plus assurée. 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 bogue ou une régression (personne n'est à l'abri de cela) ;
• à l'inverse, une correction de bogue peut avoir une influence sur les programmes existants et qui font avec ;
• certains comportements apportés par les nouvelles fonctionnalités peuvent avoir des effets indésirables sur des fonctionnalités existantes.
  

• l'introduction de nouveaux mots-clés (assert, enum, etc.) peut poser problème s'ils étaient utilisés comme identifieurs ;
• l'introduction de nouvelles méthodes peut poser des problèmes de compilation (ambigüité sur la méthode à appeler ou autre problème si des méthodes du même nom existent déjà dans la classe ou les classes filles) ;
• nouveaux warnings (en particulier en ce qui concerne les Generics), alors qu'un code « zero-warning » peut être requis (par le client par exemple).
  

• J2SE 1.3 ;
• J2SE 1.4 ;
• J2SE 1.4.1 ;
• J2SE 1.4.2 ;
• J2SE 5.0 ;
• Java SE 6 ;
• Java SE 7 ;
• Java SE 8.
  

Les versions antérieures des JDK, JRE, JEE et plus encore sont disponibles sur le site des archives Java chez Oracle.

Lancement via l’interpréteur
Lorsque l'on exécute une application Java sous Microsoft Windows avec la commande java.exe, un terminal de commande permet d'afficher les entrées/sorties de l'application. Fermer ce terminal mettra également fin à votre application. Si vous souhaitez exécuter votre application sans le terminal, il suffit d'utiliser la commande javaw.exe à la place de java.exe.

javaw <options> monPackage.monAppli

La liste de toutes les options pour les versions de la Java HotSpot VM (plateforme SPARC/Solaris) est disponible sur le site de Oracle : A Collection of JVM Options

D'autres éléments relatifs aux options de la JVM sont disponibles aux adresses suivantes :

• Java HotSpot VM Options ;
• Java HotSpot Equivalents of Exact VM Flags.
  

• <répertoire du JDk>\bin\javac ;
• <répertoire du JDk>\bin\javap ;
• <répertoire du JDk>\bin\jconsole ;
• <répertoire du JDk>\bin\keytool ;
• <répertoire du JDk>\bin\rmic ;
• etc.
  

1
2
3
4
$ javadoc -J-version 
java version "1.8.0_45" 
Java(TM) SE Runtime Environment (build 1.8.0_45-b14) 
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)