Compiler et exécuter Java sans IDE

À un moment donné sur reddit.com , dans la rubrique Compilation et exécution de Java sans IDE , la question a été posée : existe-t-il une commande qui compile un groupe de fichiers Java contenus dans un package dans un dossier séparé (appelons-le bin ) , et comment puis-je démarrer de nouveaux fichiers de classe ? " L'auteur du sujet, kylolink , explique : "Quand j'ai commencé à utiliser Java, je comptais sur Eclipse pour faire toute la compilation à ma place et j'étais juste inquiet d'écrire le code." J'ai vu cette question plusieurs fois, et, en effet, ceci C'est ce qui m'a incité à publier un article sur le blog Systèmes GPS et IDE : bons ou mauvais ? J'adore les IDE Java modernes et puissants et ils me facilitent la vie au quotidien, mais il y a aussi des avantages à savoir comment créer et exécuter des exemples simples Java sans Cet article explique comment procéder. Dans mon blog sur l'apprentissage de Java avec des tests simples, j'ai expliqué comment j'aime parfois utiliser un simple éditeur de texte et des outils de ligne de commande pour écrire, créer et exécuter des applications simples. J'ai J'ai maintenant une assez bonne idée de la quantité de "surcharge" requise par mes IDE Java préférés et je prends une décision rapide quant à savoir si les avantages obtenus grâce à l'utilisation du framework sont suffisants pour justifier la "surcharge". Dans la plupart des applications réelles, il ne fait aucun doute que l'IDE VL vaut beaucoup. Cependant, pour les exemples d’applications les plus simples, ce n’est pas toujours le cas. Le reste de cet article montre comment créer et exécuter du code Java sans IDE pour ces situations.

Écrire et exécuter du code Java

Pour rendre l'exemple plus clair, j'utiliserai des classes Java très simples qui sont liées les unes aux autres par composition ou héritage et qui se trouvent dans le même package appelé dustin.examples . Il manque une fonction à deux classesmain ; la troisième classe, Main.java, a une fonction mainqui vous permet de démontrer comment exécuter la classe sans IDE. Ci-dessous le code de ces trois classes : Parent.java

package dustin.examples;

public class Parent
{
   @Override
   public String toString()
   {
      return "I'm the Parent.";
   }
}

Enfant.java

package dustin.examples;

public class Child extends Parent
{
   @Override
   public String toString()
   {
      return "I'm the Child.";
   }
}

Main.java

package dustin.examples;

import static java.lang.System.out;

public class Main
{
   private final Parent parent = new Parent();
   private final Child child = new Child();

   public static void main(final String[] arguments)
   {
      final Main instance = new Main();
      out.println(instance.parent);
      out.println(instance.child);
   }
}

La capture d'écran suivante montre la structure des répertoires avec ces classes .java . La capture d'écran montre que les fichiers sources se trouvent dans la hiérarchie de répertoires représentant le nom du package ( dustin/examples , car les informations sur le package sont dustin.examples ) et que ce package reflète le répertoire La hiérarchie se trouve sous le sous-répertoire SRC. J'ai également créé un sous-répertoire classes (actuellement vide) pour héberger les fichiers .class compilés afin que Javac ne crée pas ce répertoire s'il n'existe pas.

Construire avec JAVAC et exécuter avec Java

Quelle que soit l'approche utilisée pour créer du code Java (Ant, Maven, Gradle ou IDE), cela revient finalement à JAVAC. Les options standard de l'outil de ligne de commande JAVAC fourni par Oracle/Sun peuvent être visualisées en exécutant JAVAC -help et les options d'extension supplémentaires peuvent être visualisées en exécutant JAVAC -help -X. Plus d'informations sur la façon d'utiliser ces options peuvent être trouvées dans la documentation de l'outil JAVAC pour Windows ou Unix/Linux. Comme le dit la documentation Javac, l'option -sourcepath peut être utilisée pour exprimer le répertoire dans lequel existent les fichiers source. Dans ma structure de répertoires illustrée dans la capture d'écran ci-dessus, cela signifie que, en supposant que j'exécute la commande JAVAC à partir du répertoire C:\Java\examples\javacAndJava\ , je devrais avoir quelque chose comme ceci dans ma commande : Javac -sourcepath src SRC\Dustin\exemples\*. Java . La capture d'écran suivante montre les résultats. Comme nous n'avons pas spécifié de répertoire pour les fichiers .class , ils ont été placés par défaut dans le même répertoire que les fichiers .java source à partir desquels ils ont été composés. Nous pouvons utiliser l’option -dpour résoudre cette situation. Notre commande peut être exécutée maintenant, par exemple, sous la forme Javac -sourcepath src -d classes src\Dustin\examples\*. Moi toi . Comme indiqué précédemment, le dossier sélectionné (classes) doit déjà exister. Lorsque cela se produit, la commande placera les fichiers .class dans le dossier spécifié, comme indiqué dans la capture d'écran suivante. Avec les fichiers sources Java compilés dans les fichiers .class correspondants dans le répertoire spécifié, nous pouvons lancer l'application en utilisant le menu de lancement rapide du Outil de ligne de commande Java. Cela se fait simplement en suivant les instructions fournies sur les pages d'aide Java ou d'outils Java et en spécifiant l'emplacement des fichiers .class avec l' option -classpath( ou -cp). L'utilisation des deux approches pour spécifier le répertoire de classes dans lequel rechercher les fichiers .class est illustrée dans la capture d'écran suivante. Le dernier argument est le nom complet (intégralité du package Java) de la classe qui possède la fonction principale à exécuter. Les commandes illustrées dans la capture d'écran suivante sont les classes Java -cp Dustin.examples.Main et les classes Java -classpath Dustin.examples.Main.

Construire et exécuter avec Ant

Pour les applications Java les plus simples, il est assez simple d'utiliser JAVAC et Java pour créer et exécuter l'application, respectivement, comme nous venons de le démontrer. À mesure que les applications deviennent un peu plus complexes (par exemple, du code existant dans plusieurs packages/répertoires ou des classes de dépendances plus complexes sur des bibliothèques et des frameworks tiers), cette approche peut devenir lourde. Apache Ant est le plus ancien des « trois grands » outils de construction Java et a été utilisé dans des milliers d'applications et de déploiements. Comme je l'ai dit dans un article de blog précédent, un fichier de construction Ant très simple est facile à créer, surtout s'il commence par un modèle comme celui que j'ai décrit dans cet article. La liste de codes suivante concerne le fichier build.xml d'Ant , qui peut être utilisé pour composer des fichiers .java en fichiers .class, puis exécuter la classe dustin.examples.Main comme cela a été fait ci-dessus avec JAVAC et Java. build.xml

<?xml version="1.0" encoding="UTF-8"?>
<project name="BuildingSansIDE" default="run" basedir=".">
   <description>Building Simple Java Applications Without An IDE</description>

   <target name="compile"
           description="Compile the Java code.">
      <javac srcdir="src"
             destdir="classes"
             debug="true"
      includeantruntime="false" />
   </target>

   <target name="run" depends="compile"
           description="Run the Java application.">
      <java classname="dustin.examples.Main" fork="true">
         <classpath>
           <pathelement path="classes"/>
         </classpath>
      </java>
   </target>
</project>

Je n'ai pas utilisé les propriétés Ant et je n'ai pas inclus les objectifs communs que j'inclus habituellement (tels que "pure" et "Javadoc") pour garder cet exemple aussi simple que possible et le garder proche de l'exemple précédent utilisant JAVAC et Java. . Notez également que j'ai activé "debug" défini sur "true" pour la tâche JAVAC Ant car ce n'est pas vrai en cas d'échec Ant, mais c'est vrai avec la valeur par défaut de JAVAC. Sans surprise, les tâches Javac et Java Ant ressemblent aux outils de commande JAVAC et Java. Parce que j'ai utilisé le nom par défaut, Ant attend un fichier de build lorsqu'il n'est pas spécifié explicitement (build.xml) et parce que j'ai fourni la cible "Exécuter" comme "par défaut" pour cette build et parce que j'ai inclus "compile" comme exécution de dépendance la cible "Exécuter" et comme Ant était sur le chemin de mon environnement, tout ce que j'avais à faire sur la ligne de commande était de demander à Ant de compiler et d'exécuter l'exemple ant dans le répertoire avec le fichier build.xml . Ceci est montré dans la capture d’écran suivante. Bien que j'aie démontré la compilation et l'exécution d'une application Java simple avec Ant, j'ai tendance à compiler uniquement avec Ant et à l'exécuter avec Java (ou un script qui appelle Java si le chemin de classe est lourd).

Construire et exécuter avec Maven

Bien qu'Ant ait été le premier outil de construction Java de base, Apache Maven a finalement acquis sa renommée en grande partie grâce à son adoption d'une configuration basée sur des conventions et à la prise en charge des référentiels de bibliothèques partagées. Maven est facile à utiliser lorsque le code et les objets générés suivent sa disposition de répertoire standard. Malheureusement, mon exemple ne suit pas cette structure de répertoires, mais Maven nous permet de remplacer la structure de répertoires par défaut attendue. La liste suivante est le code d'un fichier POM Maven qui est utilisé à la place des répertoires source et cible et fournit les autres éléments minimaux requis pour une build Maven utilisant Maven 3.2.1. pom.xml

<project>
   <modelVersion>4.0.0</modelVersion>
   <groupId>dustin.examples</groupId>
   <artifactId>CompilingAndRunningWithoutIDE</artifactId>
   <version>1</version>

   <build>
      <defaultGoal>compile</defaultGoal>
      <sourceDirectory>src</sourceDirectory>
      <outputDirectory>classes</outputDirectory>
      <finalName>${project.artifactId}-${project.version}</finalName>
   </build>
</project>

Étant donné que le fichier pom.xml ci-dessus définit le "defaultGoal" de "compile" et que les fichiers pom.xml sont le POM personnalisé par défaut recherché par l'exécutable Maven (MVN) et que le répertoire bin d'installation de Maven se trouve sur mon chemin, uniquement Je dois exécuter "MVN" pour compiler les fichiers .class comme mentionné dans la capture d'écran suivante. Je peux également exécuter l'application compilée à partir de Maven à l'aide de la commande Mvn Exec : Java -Dexec.mainClass = dustin.examples.Main , ce qui est observé dans la capture d'écran suivante. Comme avec Ant, j'ai tendance à ne pas utiliser Maven pour exécuter ma simple application Java, mais plutôt à utiliser Java sur du code compilé (ou à utiliser un script qui appelle Java directement sur des classes longues).

Construire et exécuter avec Gradle

Gradle est le plus récent, le plus tendance et le plus élégant des trois principaux outils de construction Java. Je suis parfois sceptique quant à l'essence de ce qui est à la mode, mais j'ai trouvé beaucoup de choses à aimer chez Gradle (écrit en Groovy au lieu de XML, support Ant intégré, support Ivy intégré, configuration par convention facile à reconfigurer, prise en charge du référentiel Maven, etc.). L'exemple suivant montre une version Gradle qui peut être utilisée pour compiler et exécuter une application simple, qui est l'exemple de code principal de cet article. J'ai présenté cet exemple adapté sur le blog Simple Gradle Java Plugin Customization. build.gradle

apply plugin: 'java'
apply plugin: 'application'

// Redefine where Gradle should expect Java source files (*.java)
sourceSets {
    main {
        java {
            srcDirs 'src'
        }
    }
}

// Redefine where .class files are written
sourceSets.main.output.classesDir = file("classes")

// Specify main class to be executed
mainClassName = "dustin.examples.Main"

defaultTasks 'compileJava', 'run'

Les deux premières lignes du fichier build.gradle indiquent l'utilisation du plugin Java et du plugin Application, ce qui entraîne l'intégration automatique d'un ensemble de fonctionnalités dans cette version. La définition de "sourceSets" et "sourceSets.main.output.classesDir" vous permet de remplacer les répertoires Java par défaut du plugin Gradle pour le code source Java et les classes binaires compilées, respectivement. "MainClassName" vous permet de spécifier explicitement quelle classe doit être exécutée dans le Plugin d'application. La ligne « defaultTasks » définit les tâches qui seront exécutées en tapant simplement « Gradle » sur la ligne de commande : « compileJava » est la tâche par défaut fournie par le plugin Java et « Run » est la tâche par défaut fournie par le plugin d'application. Parce que j'ai nommé les assemblys build.gradle et c'est pourquoi j'ai spécifié les tâches par défaut comme « compileJava » et « Exécuter » et parce que j'ai le répertoire bin d'installation de Gradle sur mon chemin, tout ce que j'avais à faire pour créer et exécuter les exemples était de taper 'Gradle' et ceci est démontré dans la capture d'écran suivante. Même les plus sceptiques doivent admettre que les builds Gradle sont très glissantes pour cet exemple simple. Il combine la concision de s'appuyer sur certaines conventions et hypothèses avec un mécanisme très simple pour remplacer les valeurs par défaut lorsque cela est nécessaire. Le fait qu’il soit en Groovy au lieu de XML est également très attractif ! Comme avec Ant et Maven, j'ai tendance à construire uniquement avec ces outils et à exécuter des fichiers .class compilés directement à partir de Java ou d'un script qui appelle Java. Soit dit en passant, j'ai également tendance à archiver ces .classes dans un pot pour le lancement, mais cela dépasse le cadre de cet article.

Conclusion

Un IDE n’est souvent pas nécessaire pour créer des applications et des exemples simples et peut être encore plus coûteux que ce qu’il en coûte pour créer des exemples simples. Dans un tel cas, il est assez simple d’utiliser JAVAC et Java pour créer et exécuter directement les exemples. À titre d'exemple d'implication accrue, un outil de construction tel que Ant, Maven ou Gradle devient plus attrayant. Le fait que de nombreux environnements de développement prennent en charge ces utilitaires de build signifie qu'un développeur peut migrer vers l'IDE à l'aide d'un outil intégré créé plus tôt dans le processus s'il a été déterminé que la prise en charge de l'IDE était nécessaire lorsqu'une simple application se transformait en un projet à part entière. .