Kompilowanie i uruchamianie Java bez IDE

Pewnego razu na reddit.com w temacie Kompilowanie i uruchamianie Java bez IDE padło pytanie: Czy istnieje polecenie kompilujące grupę plików Java znajdujących się w pakiecie do osobnego folderu (nazwijmy to bin ) i jak mam rozpocząć tworzenie nowych plików klas? Autor tematu, kylolink , wyjaśnia: „Kiedy zaczynałem używać Java, polegałem na Eclipse, aby wykonać całą kompilację za mnie i po prostu martwiłem się pisaniem kodu.” Widziałem to pytanie wiele razy i rzeczywiście jest to to jest to, co skłoniło mnie do napisania wpisu na blogu o systemach GPS i IDE: dobre czy złe?Uwielbiam potężne, nowoczesne IDE Java, które ułatwiają mi życie na co dzień, ale wiedza o tym, jak budować i uruchamiać proste przykłady Java, ma też zalety bez nich. Ten post jest o tym, jak to zrobić. Na moim blogu poświęconym nauce Javy za pomocą prostych testów pisałem o tym, jak czasami lubię używać prostego edytora tekstu i narzędzi wiersza poleceń do pisania, budowania i uruchamiania prostych aplikacji. mam już całkiem niezłe pojęcie o tym, ile „narzutów” wymagają moje ulubione środowiska IDE Java i podejmuję wczesną decyzję, czy korzyści osiągnięte dzięki zastosowaniu frameworku wystarczą, aby uzasadnić „narzut”. W większości rzeczywistych zastosowań nie ma wątpliwości, że VL IDE jest dużo warte. Jednak w przypadku najprostszych przykładowych zastosowań nie zawsze tak jest. Pozostała część tego posta pokazuje, jak w takich sytuacjach zbudować i uruchomić kod Java bez IDE.

Pisanie i wykonywanie kodu Java

Aby uczynić przykład bardziej przejrzystym, użyję kilku bardzo prostych klas Java, które są ze sobą powiązane poprzez kompozycję lub dziedziczenie i znajdują się w tym samym pakiecie o nazwie Dustin.examples . W dwóch klasach brakuje funkcji main; trzecia klasa, Main.java, posiada funkcję main, która pozwala zademonstrować, jak uruchomić klasę bez IDE. Poniżej znajduje się kod tych trzech klas: Parent.java

package dustin.examples;

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

Dziecko.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);
   }
}

Poniższy zrzut ekranu przedstawia strukturę katalogów z tymi klasami .java . Zrzut ekranu pokazuje, że pliki źródłowe znajdują się w hierarchii katalogów reprezentującej nazwę pakietu ( dustin/examples , ponieważ informacje o pakiecie to dusin.examples ) i że ten pakiet odzwierciedla katalog hierarchia znajduje się w podkatalogu SRC. Utworzyłem także podkatalog klas (który jest obecnie pusty), aby pomieścić skompilowane pliki .class , więc Javac nie utworzy tego katalogu, jeśli nie istnieje.

Budowanie w JAVAC i uruchamianie w Javie

Bez względu na to, jakie podejście zastosuje się do tworzenia kodu Java (Ant, Maven, Gradle lub IDE), ostatecznie sprowadza się to do JAVAC. Standardowe opcje narzędzia wiersza poleceń JAVAC dostarczonego przez firmę Oracle/Sun można wyświetlić, uruchamiając polecenie JAVAC -help, a dodatkowe opcje rozszerzeń można wyświetlić, uruchamiając polecenie JAVAC -help -X. Więcej szczegółów na temat korzystania z tych opcji można znaleźć w dokumentacji narzędzia JAVAC dla systemów Windows lub Unix/Linux. Jak mówi dokumentacja Javaca, opcji -sourcepath można użyć do określenia katalogu, w którym znajdują się pliki źródłowe. W mojej strukturze katalogów pokazanej na powyższym zrzucie ekranu oznacza to, że zakładając, że uruchamiam polecenie JAVAC z katalogu C:\Java\examples\javacAndJava\ , musiałbym mieć w moim poleceniu coś takiego: Javac -sourcepath src SRC\Dustin\przykłady\*. Jawa . Poniższy zrzut ekranu pokazuje wyniki tego. Ponieważ nie określiliśmy katalogu dla plików .class , domyślnie zostały one umieszczone w tym samym katalogu, co źródłowe pliki .java , z których zostały utworzone. Możemy skorzystać z tej opcji -d, aby naprawić tę sytuację. Nasze polecenie można teraz uruchomić na przykład jako Javac -sourcepath src -dclasss src\Dustin\examples\*. Ja ty . Jak wspomniano wcześniej, wybrany folder (klasy) musi już istnieć. Gdy tak się stanie, polecenie umieści pliki .class w określonym folderze, jak pokazano na poniższym zrzucie ekranu. Po skompilowaniu plików źródłowych Java do odpowiednich plików .class w określonym katalogu możemy uruchomić aplikację za pomocą menu szybkiego uruchamiania Narzędzie wiersza poleceń Java. Można to zrobić po prostu postępując zgodnie z instrukcjami zawartymi w pomocy Java lub na stronach narzędzi Java i określając lokalizację plików .class za pomocą opcji -classpath( lub -cp). Poniższy zrzut ekranu przedstawia oba podejścia do określenia katalogu klas, w którym należy szukać plików .class . Ostatnim argumentem jest pełna (cały pakiet Java) nazwa klasy, w której znajduje się główna funkcja, która ma zostać wykonana. Polecenia pokazane na poniższym zrzucie ekranu to klasy Java -cp pyłin.przykłady.Main i klasy Java -ścieżka klasy kurzuin.przykłady.Main.

Budowanie i bieganie z Antem

W przypadku najprostszych aplikacji Java dość łatwo jest użyć JAVAC i Java do utworzenia i uruchomienia aplikacji, jak właśnie pokazano. Ponieważ aplikacje stają się nieco bardziej złożone (na przykład kod istniejący w więcej niż jednym pakiecie/katalogu lub bardziej złożone klasy zależności w bibliotekach i frameworkach stron trzecich), takie podejście może stać się nieporęczne. Apache Ant jest najstarszym z „wielkiej trójki” narzędzi do budowania Java i był używany w tysiącach aplikacji i wdrożeń. Jak wspomniałem w poprzednim poście na blogu, bardzo prosty plik kompilacji Anta można łatwo utworzyć, zwłaszcza jeśli zaczyna się od szablonu, jaki opisałem w tym poście. Poniższa lista kodów dotyczy pliku build.xml firmy Ant , którego można użyć do złożenia plików .java w pliki .class, a następnie uruchomienia klasy Dustin.examples.Main , tak jak to zrobiono powyżej w JAVAC i Javie. kompilacja.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>

Nie użyłem właściwości Ant i nie uwzględniłem typowych celów, które zwykle uwzględniam (takich jak „pure” i „Javadoc”), aby maksymalnie uprościć ten przykład i zachować go blisko poprzedniego przykładu przy użyciu JAVAC i Java . Zauważ także, że dla zadania JAVAC Ant włączyłem opcję „debugowanie” ustawioną na „true”, ponieważ nie jest to prawdą w przypadku awarii Anta, ale ma to miejsce w przypadku ustawień domyślnych JAVAC. Nic dziwnego, że zadania Javac i zadania Java Ant przypominają narzędzia poleceń JAVAC i Javę. Ponieważ użyłem nazwy domyślnej, Ant oczekuje pliku kompilacji, jeśli nie jest on określony jawnie (build.xml) i ponieważ podałem cel „Uruchom” jako „domyślny” dla tej kompilacji oraz ponieważ uwzględniłem „kompilację” jako uruchomienie zależności element docelowy „Uruchom”, a ponieważ Ant znajdował się na ścieżce mojego środowiska, jedyne, co musiałem zrobić w wierszu poleceń, to zmusić Anta do skompilowania i uruchomienia przykładowego mrówki w katalogu z plikiem build.xml . Pokazano to na poniższym zrzucie ekranu. Chociaż pokazałem, jak skompilować i uruchomić prostą aplikację Java za pomocą Anta, zwykle kompiluję tylko za pomocą Anta i uruchamiam za pomocą Javy (lub skryptu wywołującego Javę, jeśli ścieżka klas jest obszerna).

Budowanie i uruchamianie z Mavenem

Chociaż Ant był pierwszym podstawowym narzędziem do budowania Java, Apache Maven ostatecznie zyskał sławę głównie dzięki przyjęciu konfiguracji opartej na konwencji i obsłudze repozytoriów bibliotek współdzielonych. Maven jest łatwy w użyciu, jeśli kod i wygenerowane obiekty mają standardowy układ katalogów. Niestety mój przykład nie jest zgodny z tą strukturą katalogów, ale Maven pozwala nam zastąpić oczekiwaną domyślną strukturę katalogów. Poniżej znajduje się lista kodu pliku POM Mavena, który jest używany zamiast katalogów źródłowych i docelowych i zapewnia inne minimalne elementy wymagane do kompilacji Mavena przy użyciu Mavena 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>

Ponieważ powyższy plik pom.xml definiuje „defaultGoal” „compile” i ponieważ pliki pom.xml są domyślnym niestandardowym POM, którego szuka plik wykonywalny Maven (MVN), a także ponieważ katalog bin instalacyjny Mavena znajduje się na mojej ścieżce, tylko Muszę uruchomić „MVN”, aby skompilować pliki .class, jak pokazano na poniższym zrzucie ekranu. Mogę także uruchomić skompilowaną aplikację z Mavena za pomocą polecenia Mvn Exec: Java -Dexec.mainClass = Dusin.examples.Main , co widać na poniższym zrzucie ekranu. Podobnie jak w przypadku Anta, zwykle nie używam Mavena do uruchamiania mojej prostej aplikacji Java, ale zamiast tego używam Java na skompilowanym kodzie (lub używam skryptu, który wywołuje Javę bezpośrednio w długo działających klasach).

Budowanie i uruchamianie z Gradle

Gradle to najnowsze, najmodniejsze i stylowe z trzech głównych narzędzi do budowania Java. Czasami jestem sceptyczny co do istoty tego, co jest modne, ale znalazłem wiele rzeczy, które lubię w Gradle (napisanym w Groovy zamiast XML, wbudowaną obsługą Ant, wbudowaną obsługą Ivy, łatwą konfiguracją według konwencji do rekonfiguracji, obsługa repozytorium Maven itp.). Poniższy przykład pokazuje kompilację Gradle, której można użyć do skompilowania i uruchomienia prostej aplikacji, która jest głównym przykładowym kodem dla tego wpisu. Ten dostosowany przykład przedstawiłem na blogu Simple Gradle Java Plugin Customization. kompilacja.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'

Pierwsze dwie linie pliku build.gradle wskazują użycie wtyczki Java i wtyczki aplikacji, co powoduje automatyczne wbudowanie szeregu funkcji w tę kompilację. Zdefiniowanie „sourceSets” i „sourceSets.main.output.classesDir” pozwala na nadpisanie domyślnych katalogów Java wtyczki Gradle dla odpowiednio kodu źródłowego Java i skompilowanych klas binarnych. „MainClassName” pozwala jawnie określić, która klasa powinna być uruchamiana w obrębie Wtyczka aplikacji Wiersz „defaultTasks” definiuje zadania, które zostaną uruchomione po wpisaniu „Gradle” w wierszu poleceń: „compileJava” jest domyślnym zadaniem udostępnianym przez wtyczkę Java, a „Uruchom” jest domyślnym zadaniem udostępnianym przez wtyczkę aplikacji. Ponieważ nazwałem zespoły build.gradle i dlatego określiłem domyślne zadania jako „compileJava” i „Uruchom”, a także ponieważ mam na ścieżce katalog bin instalacji Gradle, wszystko, co musiałem zrobić, aby zbudować i uruchomić przykłady, to wpisać „Gradle”, co pokazano na poniższym zrzucie ekranu. Nawet największy sceptyk musi przyznać, że kompilacje Gradle są bardzo śliskie w tym prostym przykładzie. Łączy w sobie zwięzłość polegania na pewnych konwencjach i założeniach z bardzo łatwym mechanizmem obchodzenia domyślnych ustawień, gdy jest to konieczne. Fakt, że jest w Groovy, a nie w XML, również jest bardzo atrakcyjny! Podobnie jak w przypadku Anta i Mavena, zwykle tworzę tylko przy użyciu tych narzędzi i uruchamiam skompilowane pliki .class bezpośrednio z języka Java lub skryptu wywołującego język Java. Nawiasem mówiąc, zwykle archiwizuję te klasy .class w słoiku w celu ich uruchomienia, ale to wykracza poza zakres tego artykułu.

Wniosek

IDE często nie jest konieczne do budowania prostych aplikacji i przykładów, a może być nawet droższe niż kosztuje budowanie prostych przykładów. W takim przypadku dość łatwo jest użyć JAVAC i Java do bezpośredniego zbudowania i uruchomienia przykładów. Jako przykłady większego zaangażowania, bardziej atrakcyjne stają się narzędzia do budowania, takie jak Ant, Maven lub Gradle. Fakt, że wiele środowisk programistycznych obsługuje te narzędzia do kompilacji, oznacza, że ​​programista może przeprowadzić migrację do IDE za pomocą wbudowanego narzędzia utworzonego wcześniej w procesie, jeśli okaże się, że wsparcie IDE jest potrzebne, gdy prosta aplikacja przekształci się w pełnoprawny projekt .