Java Language
La commande Java - "java" et "javaw"

Syntaxe

• java [ <opt> ... ] <class-name> [ <argument> ... ]

• java [ <opt> ... ] -jar <jar-file-pathname> [ <argument> ... ]

Remarques

Exécution d'un fichier JAR exécutable

Les fichiers JAR exécutables sont le moyen le plus simple d'assembler du code Java en un seul fichier pouvant être exécuté. * (Note éditoriale: la création de fichiers JAR doit être couverte par une rubrique distincte.) *

En supposant que vous ayez un fichier JAR exécutable avec le chemin <jar-path> , vous devriez pouvoir l'exécuter comme suit:

java -jar <jar-path>

Si la commande nécessite des arguments de ligne de commande, ajoutez-les après le <jar-path> . Par exemple:

java -jar <jar-path> arg1 arg2 arg3

Si vous devez fournir des options de JVM supplémentaires sur la java ligne de commande, ils doivent aller avant la -jar option. Notez qu'un -cp / -classpath option sera ignorée si vous utilisez -jar . Le chemin de classe de l'application est déterminé par le manifeste du fichier JAR.

Exécution d'une application Java via une classe "principale"

Lorsqu'une application n'a pas été empaquetée en tant que fichier JAR exécutable, vous devez indiquer le nom d'une classe de point d'entrée sur la ligne de commande java .

Lancer la classe HelloWorld

L'exemple "HelloWorld" est décrit dans la section Création d'un nouveau programme Java . Il consiste en une classe unique appelée HelloWorld qui répond aux exigences d'un point d'entrée.

En supposant que le fichier (compilé) "HelloWorld.class" se trouve dans le répertoire actuel, il peut être lancé comme suit:

java HelloWorld

Certaines choses importantes à noter sont:

• Nous devons fournir le nom de la classe: pas le chemin d'accès du fichier ".class" ou du fichier ".java".
• Si la classe est déclarée dans un package (comme le sont la plupart des classes Java), le nom de classe que nous fournissons à la commande java doit être le nom de classe complet. Par exemple, si SomeClass est déclaré dans le package com.example , le nom de classe complet sera com.example.SomeClass .

Spécifier un classpath

À moins d'utiliser la syntaxe de la commande java -jar , la commande java recherche la classe à charger en effectuant une recherche dans le chemin de classe; voir le Classpath . La commande ci-dessus repose sur le chemin de classe par défaut étant (ou incluant) le répertoire en cours. Nous pouvons être plus explicites à ce sujet en spécifiant le classpath à utiliser avec l'option -cp .

java -cp . HelloWorld

Cela dit pour faire le répertoire courant (qui est ce que "." Se réfère à) la seule entrée sur le classpath.

Le -cp est une option qui est traitée par la commande java . Toutes les options destinées à la commande java doivent être avant le nom de classe. Tout ce qui suit la classe sera traité comme un argument de ligne de commande pour l'application Java et sera transmis à l'application dans la String[] transmise à la méthode main .

(Si aucune option -cp n'est fournie, le java utilisera le classpath qui est fourni par la CLASSPATH environnement CLASSPATH . Si cette variable n'est pas définie ou vide, java utilise "." Comme chemin de classe par défaut.)

Classes de points d'entrée

Une classe de point d’entrée Java possède une méthode main avec la signature et les modificateurs suivants:

public static void main(String[] args)

Sidenote: à cause du fonctionnement des tableaux, cela peut aussi être (String args[])

Lorsque la commande java démarre la machine virtuelle, elle charge les classes de points d'entrée spécifiées et tente de trouver la classe main . En cas de succès, les arguments de la ligne de commande sont convertis en objets Java String et assemblés en un tableau. Si main est appelée comme ceci, le tableau ne sera pas null et ne contiendra aucune entrée null .

Une méthode de classe de point d'entrée valide doit effectuer les opérations suivantes:

• Être nommé main (sensible à la casse)
• Être public et static
• Avoir un type de retour void
• Avoir un seul argument avec un tableau String[] . L'argument doit être présent et pas plus d'un argument est autorisé.
• Soyez générique: les paramètres de type ne sont pas autorisés.
• Avoir une classe englobante non générique, de premier niveau (non imbriquée ou interne)

Il est classique de déclarer la classe comme public mais ce n’est pas strictement nécessaire. A partir de Java 5, le type d'argument de la méthode main peut être un String varargs au lieu d'un tableau de chaînes. main peut éventuellement jeter des exceptions, et son paramètre peut être nommé n'importe quoi, mais conventionnellement, il est args .

Points d'entrée JavaFX

A partir de Java 8, la commande java peut également lancer directement une application JavaFX. JavaFX est documenté dans la balise JavaFX , mais un point d'entrée JavaFX doit effectuer les opérations suivantes:

• Étendre javafx.application.Application
• Être public et non abstract
• Ne pas être générique ou imbriqué
• Avoir un constructeur public explicite ou implicite no-args

Dépannage de la commande 'java'

Cet exemple couvre les erreurs courantes liées à l'utilisation de la commande 'java'.

"Commande non trouvée"

Si vous obtenez un message d'erreur tel que:

java: command not found

en essayant d'exécuter la commande java , cela signifie qu'il n'y a pas de commande java sur le chemin de recherche de commandes de votre shell. La cause pourrait être:

• vous n'avez pas de Java JRE ou JDK installé,
• vous n'avez pas mis à jour la variable d'environnement PATH (correctement) dans votre fichier d'initialisation de shell, ou
• vous n'avez pas "trouvé" le fichier d'initialisation correspondant dans le shell actuel.

Reportez-vous à la section "Installation de Java" pour connaître les étapes à suivre.

"Impossible de trouver ou de charger la classe principale"

Ce message d'erreur est généré par la commande java s'il n'a pas pu trouver / charger la classe de point d'entrée que vous avez spécifiée. En termes généraux, trois raisons principales peuvent expliquer ce phénomène:

• Vous avez spécifié une classe de point d'entrée qui n'existe pas.
• La classe existe, mais vous l'avez spécifiée de manière incorrecte.
• La classe existe et vous l'avez spécifiée correctement, mais Java ne peut pas la trouver car le classpath est incorrect.

Voici une procédure pour diagnostiquer et résoudre le problème:

1. Découvrez le nom complet de la classe de point d'entrée.

   • Si vous avez un code source pour une classe, le nom complet comprend le nom du package et le nom de la classe simple. L'instance dont la classe "Main" est déclarée dans le package "com.example.myapp", puis son nom complet est "com.example.myapp.Main".
   • Si vous avez un fichier de classe compilé, vous pouvez trouver le nom de la classe en lançant javap .
   • Si le fichier de classe se trouve dans un répertoire, vous pouvez déduire le nom complet de la classe des noms de répertoire.
   • Si le fichier de classe se trouve dans un fichier JAR ou ZIP, vous pouvez déduire le nom de classe complet du chemin du fichier JAR ou ZIP.

2. Regardez le message d'erreur de la commande java . Le message doit se terminer par le nom de classe complet que java essaie d’utiliser.

   • Vérifiez qu'il correspond exactement au nom de classe complet de la classe de point d'entrée.
   • Il ne devrait pas se terminer par ".java" ou ".class".
   • Il ne doit pas contenir de barres obliques ou d’autres caractères non légaux dans un identifiant Java ¹ .
   • L'enveloppe du nom doit correspondre exactement au nom complet de la classe.

3. Si vous utilisez le bon nom de classe, assurez-vous que la classe est bien sur le chemin de classe:

   • Examinez le chemin d'accès auquel le nom de classe correspond; voir Mappage des noms de classe sur les chemins d'accès
   • Examinez ce qu'est le classpath; voir cet exemple: Différentes manières de spécifier le classpath
   • Examinez chacun des fichiers JAR et ZIP du chemin de classe pour voir s'ils contiennent une classe avec le chemin d'accès requis.
   • Examinez chaque répertoire pour voir si le chemin d'accès se résout en un fichier dans le répertoire.

Si la vérification manuelle du -Xdiag -XshowSettings n'a pas trouvé le problème, vous pouvez ajouter les options -Xdiag et -XshowSettings . La première liste toutes les classes chargées et la seconde affiche les paramètres qui incluent le chemin de classe effectif pour la machine virtuelle Java.

Enfin, il existe des causes obscures à ce problème:

• Un fichier JAR exécutable avec un attribut Main-Class qui spécifie une classe qui n'existe pas.
• Un fichier JAR exécutable avec un attribut Class-Path incorrect.
• Si vous gâcher ² les options avant le nom de classe, la java commande peut tenter d'interpréter l' un d'entre eux comme le nom de classe.
• Si quelqu'un a ignoré les règles de style Java et utilisé des identifiants de classe ou de package qui ne diffèrent que par la casse des lettres et que vous utilisez une plate-forme qui considère les noms de fichiers des lettres comme non significatifs.
• Problèmes avec les homoglyphes dans les noms de classe dans le code ou sur la ligne de commande.

"Méthode principale introuvable dans la classe <nom>"

Ce problème se produit lorsque la commande java est capable de trouver et de charger la classe que vous avez nommée, mais est ensuite incapable de trouver une méthode de point d’entrée.

Il y a trois explications possibles:

• Si vous essayez d'exécuter un fichier JAR exécutable, le manifeste du fichier JAR a un attribut "Main-Class" incorrect qui spécifie une classe qui n'est pas une classe de point d'entrée valide.
• Vous avez dit à la commande java une classe qui n'est pas une classe de point d'entrée.
• La classe de point d'entrée est incorrecte. voir Classes de point d'entrée pour plus d'informations.

Autres ressources

• Que signifie "Impossible de trouver ou de charger la classe principale"?
• http://docs.oracle.com/javase/tutorial/getStarted/problems/index.html

^{1 - A partir de Java 8 et versions ultérieures, la commande java mappera utilement un séparateur de nom de fichier ("/" ou "") sur un point ("."). Toutefois, ce comportement n'est pas documenté dans les pages de manuel.}

^{2 - Si vous copiez et collez une commande à partir d'un document formaté dans lequel l'éditeur de texte a utilisé un "trait d'union long" au lieu d'un trait d'union régulier, cela est très obscur.}

Exécution d'une application Java avec des dépendances de bibliothèque

Ceci est une continuation des exemples "main class" et "executable JAR" .

Les applications Java classiques consistent en un code spécifique à l'application et en divers codes de bibliothèque réutilisables que vous avez implémentés ou mis en œuvre par des tiers. Ces derniers sont généralement appelés dépendances de bibliothèque et sont généralement regroupés sous forme de fichiers JAR.

Java est un langage lié dynamiquement. Lorsque vous exécutez une application Java avec des dépendances de bibliothèque, la machine virtuelle Java doit savoir où se trouvent les dépendances pour pouvoir charger les classes selon vos besoins. D'une manière générale, il y a deux manières de traiter cela:

• L'application et ses dépendances peuvent être regroupées en un seul fichier JAR contenant toutes les classes et ressources requises.

• On peut dire à la JVM où trouver les fichiers JAR dépendants via le classpath d’exécution.

Pour un fichier JAR exécutable, le chemin de classe d'exécution est spécifié par l'attribut de manifeste "Class-Path". (Note éditoriale: ceci doit être décrit dans une rubrique distincte sur la commande jar .) Sinon, le classpath d’exécution doit être fourni à l’aide de l’option -cp ou de la CLASSPATH environnement CLASSPATH .

Par exemple, supposons que nous ayons une application Java dans le fichier "myApp.jar" dont la classe de point d’entrée est com.example.MyApp . Supposons également que l'application dépend des fichiers JAR de la bibliothèque "lib / library1.jar" et "lib / library2.jar". Nous pourrions lancer l'application en utilisant la commande java comme suit dans une ligne de commande:

$ # Alternative 1 (preferred)
$ java -cp myApp.jar:lib/library1.jar:lib/library2.jar com.example.MyApp

$ # Alternative 2
$ export CLASSPATH=myApp.jar:lib/library1.jar:lib/library2.jar
$ java com.example.MyApp

(Sous Windows, vous utiliseriez ; au lieu de : tant que séparateur de chemin de classe, et vous CLASSPATH variable CLASSPATH (locale) à l'aide de set plutôt que d' export .)

Bien qu'un développeur Java soit à l'aise avec cela, il n'est pas "convivial". Il est donc courant d'écrire un script shell simple (ou un fichier de commandes Windows) pour masquer les détails que l'utilisateur n'a pas besoin de connaître. Par exemple, si vous placez le script shell suivant dans un fichier appelé "myApp", exécutez-le et placez-le dans un répertoire du chemin de recherche:

#!/bin/bash
# The 'myApp' wrapper script

export DIR=/usr/libexec/myApp
export CLASSPATH=$DIR/myApp.jar:$DIR/lib/library1.jar:$DIR/lib/library2.jar
java com.example.MyApp

alors vous pourriez l'exécuter comme suit:

$ myApp arg1 arg2 ...

Tous les arguments sur la ligne de commande seront transmis à l'application Java via l'extension "$@" . (Vous pouvez faire quelque chose de similaire avec un fichier de commandes Windows, bien que la syntaxe soit différente.)

Espaces et autres caractères spéciaux dans les arguments

Tout d'abord, le problème de la gestion des espaces dans les arguments n'est PAS un problème Java. Il s'agit plutôt d'un problème qui doit être traité par le shell de commandes que vous utilisez lorsque vous exécutez un programme Java.

À titre d'exemple, supposons que nous ayons le programme simple suivant qui imprime la taille d'un fichier:

import java.io.File;

public class PrintFileSizes {
    
    public static void main(String[] args) {
        for (String name: args) {
            File file = new File(name);
            System.out.println("Size of '" + file + "' is " + file.size());
        }
    }
}

Maintenant, supposons que nous voulions imprimer la taille d'un fichier dont le chemin contient des espaces; par exemple /home/steve/Test File.txt . Si nous exécutons la commande comme ceci:

$ java PrintFileSizes /home/steve/Test File.txt

le shell ne saura pas que /home/steve/Test File.txt est en fait un chemin d'accès. Au lieu de cela, il transmettra 2 arguments distincts à l'application Java, qui tentera de trouver leur taille de fichier respective, et échouera car les fichiers avec ces chemins (probablement) n'existent pas.

Solutions utilisant un shell POSIX

Coquilles comprennent POSIX sh sous forme de dérivés bien tels que bash et ksh . Si vous utilisez l'un de ces shells, vous pouvez résoudre le problème en citant l'argument.

$ java PrintFileSizes "/home/steve/Test File.txt"

Les guillemets autour du nom de chemin indiquent au shell qu'il doit être transmis en un seul argument. Les citations seront supprimées lorsque cela se produira. Il y a plusieurs autres façons de le faire:

$ java PrintFileSizes '/home/steve/Test File.txt'

Les guillemets simples (droits) sont traités comme des guillemets, sauf qu'ils suppriment également diverses extensions dans l'argument.

$ java PrintFileSizes /home/steve/Test\ File.txt

Une barre oblique inverse échappe à l'espace suivant et l'empêche d'être interprétée comme un séparateur d'arguments.

Pour une documentation plus complète, y compris des descriptions sur la manière de traiter d'autres caractères spéciaux dans les arguments, veuillez vous reporter à la rubrique de citation dans la documentation de Bash .

Solution pour Windows

Le problème fondamental de Windows est qu'au niveau du système d'exploitation, les arguments sont transmis à un processus enfant sous la forme d'une chaîne unique ( source ). Cela signifie que la responsabilité ultime de l'analyse (ou de la nouvelle analyse) de la ligne de commande incombe au programme ou à ses bibliothèques d'exécution. Il y a beaucoup d'incohérence.

Dans le cas de Java, pour faire court:

• Vous pouvez placer des guillemets doubles autour d'un argument dans une commande java , ce qui vous permettra de transmettre des arguments avec des espaces.

• Apparemment, la commande java elle-même analyse la chaîne de commande

• Cependant, lorsque vous essayez de combiner cela avec l'utilisation de SET et de la substitution de variables dans un fichier de commandes, il devient vraiment compliqué de savoir si les guillemets doubles sont supprimés.

• Le shell cmd.exe a apparemment d'autres mécanismes d'échappement; par exemple, doubler les guillemets doubles et utiliser ^ échappent.

Pour plus de détails, reportez-vous à la documentation de Batch-File .

Options Java

La commande java prend en charge un large éventail d'options:

• Toutes les options commencent par un seul trait d'union ou un signe moins ( - ): la convention GNU / Linux consistant à utiliser -- pour les options "long" n'est pas prise en charge.

• Les options doivent apparaître avant la <classname> ou le -jar <jarfile> argument pour être reconnu. Tous les arguments après ceux-ci seront traités comme des arguments à transmettre à l'application Java en cours d'exécution.

• Les options qui ne commencent pas par -X ou -XX sont des options standard. Vous pouvez compter sur toutes les implémentations Java ¹ pour prendre en charge toute option standard.

• Les options commençant par -X sont des options non standard et peuvent être retirées d'une version Java à l'autre.

• Les options commençant par -XX sont des options avancées et peuvent également être retirées.

Définition des propriétés du système avec -D

L'option -D<property>=<value> est utilisée pour définir une propriété dans l'objet Properties du système. Ce paramètre peut être répété pour définir différentes propriétés.

Options de mémoire, d'empilage et de récupération de mémoire

Les principales options de contrôle du tas et de la taille des piles sont documentées dans la section Définition des tailles de tas, PermGen et Stack . (Note de la rédaction: les options du récupérateur de place doivent être décrites dans le même sujet.)

Activation et désactivation des assertions

Les options -ea et -da activent et désactivent respectivement la vérification Java assert :

• Toute vérification des assertions est désactivée par défaut.
• L'option -ea permet de vérifier toutes les assertions
• Le -ea:<packagename>... permet de vérifier les assertions dans un package et tous les sous-packages .
• Le -ea:<classname>... permet de vérifier les assertions d'une classe.
• L'option -da désactive la vérification de toutes les assertions
• Le -da:<packagename>... désactive la vérification des assertions dans un paquet et dans tous les sous-paquets .
• -da:<classname>... désactive la vérification des assertions dans une classe.
• L'option -esa permet de vérifier toutes les classes de système.
• L'option -dsa désactive la vérification pour toutes les classes système.

Les options peuvent être combinées. Par exemple.

$ # Enable all assertion checking in non-system classes 
$ java -ea -dsa MyApp

$ # Enable assertions for all classes in a package except for one.
$ java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat MyApp

Notez que l'activation de la vérification d'assertion est susceptible de modifier le comportement d'une programmation Java.

• Il est responsable de rendre l'application plus lente en général.
• Cela peut entraîner des méthodes plus longues à exécuter, ce qui peut changer la synchronisation des threads dans une application multithread.
• Il peut introduire des relations entre événements par hasard et provoquer des anomalies de la mémoire.
• Une mauvaise application assert déclaration pourrait avoir des effets secondaires indésirables.

Sélection du type de machine virtuelle

Les options -client et -server vous permettent de sélectionner deux formes différentes de la machine virtuelle HotSpot:

• Le formulaire "client" est adapté aux applications utilisateur et offre un démarrage plus rapide.
• Le formulaire "serveur" est conçu pour des applications de longue durée. Il faut plus de temps pour capturer les statistiques pendant le "warm-up" de la JVM, ce qui permet au compilateur JIT d'optimiser le code natif.

Par défaut, la JVM fonctionnera en mode 64 bits si possible, en fonction des capacités de la plate-forme. Les options -d32 et -d64 vous permettent de sélectionner le mode explicitement.

^{1 - Consultez le manuel officiel de la commande java . Parfois, une option standard est décrite comme "susceptible de changer".}