קומפילציה והרצה של Java ללא IDE

פעם ב- reddit.com , בנושא קומפילציה והרצה של Java ללא IDE , נשאלה השאלה: האם יש פקודה שמרכיבה קבוצה של קבצי Java שנמצאים בתוך חבילה לתיקיה נפרדת (בואו נקרא לזה bin ) , וכיצד עליי להשיק קבצי מחלקה חדשים? " מחבר הנושא, kylolink , מסביר: "כשהתחלתי להשתמש ב-Java, סמכתי על Eclipse שיעשה עבורי את כל הקומפילציה ורק דאגתי לכתוב את הקוד." ראיתי את השאלה הזו פעמים רבות, ואכן, זו זה מה שהניע אותי לכתוב בבלוג על מערכות GPS ו-IDE: טוב או רע? אני אוהב IDEs מודרניים חזקים של Java והם מקלים על חיי על בסיס יומיומי, אבל יש גם יתרונות לדעת איך לבנות ולהפעיל דוגמאות פשוטות של Java בלעדיהם. הפוסט הזה עוסק איך לעשות בדיוק את זה. בבלוג שלי על לימוד ג'אווה עם מבחנים פשוטים, כתבתי על איך לפעמים אני אוהב להשתמש בעורך טקסט פשוט ובכלי שורת הפקודה כדי לכתוב, לבנות ולהפעיל יישומים פשוטים. יש לך מושג די טוב עכשיו לגבי כמה "תקורה" דורשים ה-Java IDEs האהובים עלי וקבל החלטה מוקדמת האם היתרונות שהושגו באמצעות המסגרת מספיקים כדי להצדיק את ה"תקורה". ברוב היישומים האמיתיים, אין ספק שה-VL IDE שווה הרבה. עם זאת, עבור יישומים לדוגמה הפשוטים ביותר, זה לא תמיד המקרה. שאר הפוסט הזה מראה כיצד לבנות ולהפעיל קוד Java ללא IDE עבור מצבים אלה.

כתיבה והפעלה של קוד Java

כדי להבהיר את הדוגמה יותר, אשתמש בכמה מחלקות Java פשוטות מאוד שקשורות זו לזו באמצעות קומפוזיציה או ירושה ונמצאות באותה חבילה שנקראת dustin.examples . לשתי מחלקות חסרה פונקציה main; למחלקה השלישית, Main.java, יש פונקציה mainהמאפשרת לך להדגים כיצד להפעיל את המחלקה ללא IDE. להלן הקוד לשלושת הכיתות הללו: Parent.java

package dustin.examples;

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

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

צילום המסך הבא מציג את מבנה הספריות עם מחלקות .java אלה . צילום המסך מראה שקובצי המקור נמצאים בהיררכיית הספריות המייצגת את שם החבילה ( dustin/examples כי פרטי החבילה הם dustin.examples ) ושחבילה זו משקפת את היררכיית הספריות. נמצא תחת ספריית המשנה SRC. יצרתי גם תת-ספריית מחלקות (שהיא ריקה כרגע) כדי לאחסן את קבצי ה- .class הקומפילציה כך ש- Javac לא יצור את הספרייה הזו כשהיא לא קיימת.

בנייה עם JAVAC והפעלה עם Java

לא משנה באיזו גישה משתמשים כדי ליצור קוד Java (Ant, Maven, Gradle או IDE), זה מסתכם בסופו של דבר ב-JAVAC. ניתן לראות את האפשרויות הסטנדרטיות בכלי שורת הפקודה JAVAC המסופק ב-Oracle/Sun על ידי הפעלת JAVAC -help וניתן להציג אפשרויות הרחבה נוספות על ידי הפעלת JAVAC -help -X. פרטים נוספים על אופן השימוש באפשרויות אלו ניתן למצוא בתיעוד כלי JAVAC עבור Windows או Unix/Linux. כפי שאומר התיעוד של Javac, ניתן להשתמש באפשרות -sourcepath כדי לבטא את הספרייה שבה קיימים קבצי מקור. במבנה הספריות שלי המוצג בצילום המסך למעלה, זה אומר שבהנחה שאני מריץ את הפקודה JAVAC מהספרייה C:\Java\examples\javacAndJava\ , אצטרך להיות משהו כזה בפקודה שלי: Javac -sourcepath src SRC\Dustin\examples\*. Java . צילום המסך הבא מציג את התוצאות של זה. מכיוון שלא ציינו ספרייה עבור קבצי ה-.class , הם הוצבו כברירת מחדל באותה ספרייה כמו קובצי ה- Java המקור שמהם הם הורכבו. אנחנו יכולים להשתמש באפשרות -dכדי לתקן את המצב הזה. ניתן להפעיל את הפקודה שלנו כעת, למשל, בתור Javac -sourcepath src -d classes src\Dustin\examples\*. אני אתה . כפי שצוין קודם לכן, התיקיה שנבחרה (מחלקות) חייבת כבר להתקיים. כאשר זה קורה, הפקודה תמקם את קבצי ה-.class בתיקייה שצוינה כפי שמוצג בצילום המסך הבא כאשר קובצי המקור של Java מורכבים לקבצי .class תואמים בספריה שצוינה, נוכל להפעיל את האפליקציה באמצעות תפריט ההשקה המהירה של כלי שורת הפקודה של Java. זה נעשה פשוט על ידי ביצוע ההוראות המופיעות בדפי Java -help או Java tools וציון המיקום של קבצי ה-.class עם האפשרות -classpath( או -cp). שימוש בשתי הגישות כדי לציין את ספריית המחלקות היכן לחפש קבצי .class מודגם בצילום המסך הבא. הארגומנט האחרון הוא השם המלא (כל חבילת ה-Java) של המחלקה שיש לה את הפונקציה הראשית לביצוע. הפקודות המוצגות בצילום המסך הבא הן מחלקות java -cp dustin.examples.Main ומחלקות java -classpath dustin.examples.Main.

בונים ורצים עם נמלה

עבור יישומי Java הפשוטים ביותר, די קל להשתמש ב-JAVAC וב-Java כדי ליצור ולהפעיל את האפליקציה, בהתאמה, כפי שהוכח זה עתה. ככל שיישומים הופכים קצת יותר מורכבים (לדוגמה, קוד הקיים ביותר מחבילה/ספרייה אחת או מחלקות תלות מורכבות יותר בספריות ובמסגרות של צד שלישי), גישה זו עלולה להפוך למסורבלת. Apache Ant הוא הוותיק ביותר מבין "שלושת הגדולים" כלי בנייה של Java ונעשה בו שימוש באלפי יישומים ופריסות. כפי שאמרתי בפוסט הקודם בבלוג, קל מאוד ליצור קובץ בנייה פשוט מאוד של Ant, במיוחד אם הוא מתחיל בתבנית כמו שתיארתי בפוסט הזה. רשימת הקודים הבאה מיועדת לקובץ build.xml של Ant , שניתן להשתמש בו כדי לחבר קבצי .java לקבצי .class ולאחר מכן להפעיל את המחלקה dustin.examples.Main כפי שנעשה לעיל עם JAVAC ו-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>

לא השתמשתי במאפייני הנמלה ולא כללתי את המטרות הנפוצות שאני כולל בדרך כלל (כגון "טהור" ו"Javadoc") כדי שהדוגמה הזו תהיה פשוטה ככל האפשר ולשמור אותה קרובה לדוגמא הקודמת באמצעות JAVAC ו-Java . שימו לב גם שהפעלתי את "debug" מוגדר ל"true" עבור משימת ה-JAVAC Ant כי זה לא נכון במקרה של כשל Ant, אלא נכון עם ברירת המחדל של JAVAC. באופן לא מפתיע, משימת Javac ומשימת Java Ant דומות לכלי הפקודה של JAVAC ול-Java. בגלל שהשתמשתי בשם ברירת המחדל Ant מצפה לקובץ build כשהוא לא מצוין במפורש (build.xml) ומכיוון שסיפקתי את יעד ה-"Run" בתור "ברירת המחדל" ל-build הזה ומכיוון שכללתי "קומפילציה" כריצת תלות מטרת ה-"Run" ומכיוון ש-Ant הייתה בנתיב של הסביבה שלי, כל מה שהייתי צריך לעשות בשורת הפקודה היה לגרום לאנט להדר ולהריץ את דוגמה הנמלה בספרייה עם הקובץ build.xml . זה מוצג בצילום המסך הבא. למרות שהדגמתי קומפילציה והרצה של יישום Java פשוט עם Ant, אני נוטה להדר רק עם Ant ולהפעיל עם Java (או סקריפט שקורא ל-Java אם ה-classpath כבד).

בנייה והפעלה עם מייבן

למרות ש-Ant היה כלי בניית הליבה הראשון של Java, Apache Maven זכתה בסופו של דבר לתהילתה בעיקר בזכות אימוץ תצורה מבוססת מוסכמות ותמיכה במאגרי ספריות משותפים. Maven קל לשימוש כאשר הקוד והאובייקטים שנוצרו עוקבים אחר פריסת הספרייה הסטנדרטית שלו. למרבה הצער, הדוגמה שלי לא עוקבת אחר מבנה הספריות הזה, אבל Maven כן מאפשרת לנו לעקוף את מבנה ספריות ברירת המחדל הצפוי. הרשימה הבאה היא קוד עבור קובץ Maven POM המשמש במקום ספריות המקור והיעד ומספקת את שאר הרכיבים המינימליים הנדרשים עבור בניית Maven באמצעות 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>

מכיוון שהקובץ pom.xml לעיל מגדיר את "defaultGoal" של "compile" ומכיוון שקובצי pom.xml הם מותאם אישית POM ברירת המחדל שקובץ ההפעלה של Maven (MVN) מחפש ומכיוון שספריית ההתקנה של Maven נמצאת בנתיב שלי, רק אני צריך להריץ את "MVN" כדי לקמפל קבצי .class כפי שהוזכר בצילום המסך הבא. אני יכול גם להריץ את היישום המהודר מ-Maven באמצעות הפקודה Mvn Exec: Java -Dexec.mainClass = dustin.examples.Main , הנצפה בצילום המסך הבא. כמו עם Ant, אני נוטה לא להשתמש ב-Maven כדי להפעיל את אפליקציית הג'אווה הפשוטה שלי, אלא להשתמש ב-Java על קוד קומפילציה (או להשתמש בסקריפט שקורא ל-Java ישירות בשיעורים ארוכים).

בנייה והפעלה עם Gradle

Gradle הוא החדש, האופנתי והמסוגנן מבין שלושת כלי הבנייה העיקריים של Java. לפעמים אני סקפטי לגבי המהות של מה שאופנתי, אבל מצאתי הרבה דברים לאהוב ב-Gradle (כתוב ב-Groovy במקום ב-XML, תמיכה מובנית ב-Ant, תמיכה מובנית ב-Ivy, תצורה לפי מוסכמה זה קל להגדרה מחדש, תמיכה במאגר של Maven וכו'). הדוגמה הבאה מציגה מבנה Gradle שניתן להשתמש בו כדי להדר ולהפעיל יישום פשוט, שהוא קוד הדוגמה העיקרי לפוסט זה. הצגתי את הדוגמה המותאמת הזו בבלוג 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'

שתי השורות הראשונות מהקובץ build.gradle מציינות את השימוש בתוסף Java ובתוסף Application, וכתוצאה מכך מובנית אוסף של פונקציונליות אוטומטית ב-build הזה. הגדרת "sourceSets" ו-"sourceSets.main.output.classesDir" מאפשרת לך לעקוף את ספריות ה-Java ברירת המחדל של התוסף Gradle עבור קוד מקור Java ומחלקות בינאריות מהידור, בהתאמה. "MainClassName" מאפשר לך לציין במפורש איזו מחלקה אמורה להיות מופעלת בתוך תוסף יישום. שורת "defaultTasks" מגדירה את המשימות שיפעלו על ידי הקלדת "Gradle" בשורת הפקודה: 'compileJava' היא משימת ברירת המחדל המסופקת על ידי תוסף Java ו'Run' היא משימת ברירת המחדל המסופקת על ידי תוסף היישום. מכיוון שקראתי למכלולים build.gradle ובגלל זה ציינתי את משימות ברירת המחדל כ'compileJava' ו-'Run' ומכיוון שיש לי את ספריית ההתקנה של Gradle בנתיב, כל מה שהייתי צריך לעשות כדי לבנות ולהפעיל את הדוגמאות היה להקליד 'Gradle' וזה מודגם בצילום המסך הבא. אפילו הספקן הגדול ביותר חייב להודות שהמבנה של Gradle הוא חלקלק מאוד עבור הדוגמה הפשוטה הזו. הוא משלב את התמציתיות של הסתמכות על מוסכמות והנחות מסוימות עם מנגנון קל מאוד לעקוף ברירות מחדל בעת הצורך. גם העובדה שזה ב-Groovy במקום ב-XML מאוד אטרקטיבי! כמו ב-Ant ומייבן, אני נוטה לבנות רק עם הכלים האלה ונוטה להריץ קבצי .class קומפילים ישירות מג'אווה או סקריפט שקורא ל-Java. אגב, אני נוטה גם לאחסן את ה-.classes האלה לתוך צנצנת לצורך השקה, אבל זה מעבר לתחום המאמר הזה.

סיכום

לעתים קרובות אין צורך ב-IDE כדי לבנות יישומים ודוגמאות פשוטות והוא יכול להיות אפילו יקר יותר ממה שעלותו לבנות דוגמאות פשוטות. במקרה כזה, די קל להשתמש ב-JAVAC וב-Java כדי לבנות ולהפעיל ישירות את הדוגמאות. כדוגמאות ליצירת מעורבות רבה יותר, כלי בנייה כגון Ant, Maven או Gradle הופך לאטרקטיבי יותר. העובדה שסביבות פיתוח רבות תומכות בכלי הבנייה הללו פירושה שמפתח יכול לעבור ל-IDE באמצעות כלי מובנה שנוצר מוקדם יותר בתהליך, אם נקבע שיש צורך בתמיכה ב-IDE מכיוון שאפליקציה פשוטה גדלה לפרויקט מלא. .