Biên dịch và chạy Java không cần IDE

Có một lần trên reddit.com , trong chủ đề Biên dịch và chạy Java không cần IDE , có một câu hỏi được đặt ra: Có lệnh nào biên dịch một nhóm tệp Java bên trong một gói vào một thư mục riêng (hãy gọi nó là bin ) và tôi sẽ khởi chạy các tệp lớp mới bằng cách nào? " Tác giả chủ đề, kylolink , giải thích: "Khi tôi bắt đầu sử dụng Java, tôi đã dựa vào Eclipse để thực hiện tất cả việc biên dịch cho tôi và chỉ lo lắng về việc viết mã." Tôi đã thấy câu hỏi này nhiều lần, và thực sự, câu hỏi này là điều đã thúc đẩy tôi đăng bài viết về hệ thống GPS và IDE: tốt hay xấu? Tôi yêu các IDE Java hiện đại mạnh mẽ và chúng giúp cuộc sống hàng ngày của tôi dễ dàng hơn nhưng cũng có những lợi ích khi biết cách xây dựng và chạy các ví dụ Java đơn giản mà không cần họ. Bài đăng này nói về cách thực hiện điều đó. Trong blog về học Java với các bài kiểm tra đơn giản, tôi đã viết về việc đôi khi tôi thích sử dụng một trình soạn thảo văn bản đơn giản và các công cụ dòng lệnh để viết, xây dựng và chạy các ứng dụng đơn giản. Tôi có hiện tại, một ý tưởng khá hay về mức độ "chi phí chung" mà các IDE Java yêu thích của tôi yêu cầu và đưa ra quyết định sớm về việc liệu lợi ích đạt được khi sử dụng khung có đủ để biện minh cho "chi phí chung" hay không. Trong hầu hết các ứng dụng thực tế, không còn nghi ngờ gì nữa, VL IDE có giá trị rất lớn. Tuy nhiên, đối với các ứng dụng ví dụ đơn giản nhất, điều này không phải lúc nào cũng đúng. Phần còn lại của bài đăng này trình bày cách xây dựng và chạy mã Java mà không cần IDE cho những tình huống này.

Viết và thực thi mã Java

Để làm cho ví dụ rõ ràng hơn, tôi sẽ sử dụng một số lớp Java rất đơn giản có liên quan với nhau thông qua thành phần hoặc kế thừa và nằm trong cùng một gói có tên là dustin.examples . Hai lớp thiếu một hàm main; lớp thứ ba, Main.java, có một hàm maincho phép bạn minh họa cách chạy lớp mà không cần IDE. Dưới đây là mã cho ba lớp này: Parent.java

package dustin.examples;

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

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

Ảnh chụp màn hình sau đây hiển thị cấu trúc thư mục với các lớp .java này . Ảnh chụp màn hình cho thấy các tệp nguồn nằm trong hệ thống phân cấp thư mục đại diện cho tên gói ( dustin/examples , vì thông tin gói là dustin.examples ) và gói này phản ánh thư mục hệ thống phân cấp nằm dưới thư mục con SRC. Tôi cũng đã tạo một thư mục con lớp (hiện trống) để chứa các tệp .class đã biên dịch để Javac sẽ không tạo thư mục này khi nó không tồn tại.

Xây dựng với JAVAC và chạy với Java

Bất kể người ta sử dụng cách tiếp cận nào để tạo mã Java (Ant, Maven, Gradle hoặc IDE), cuối cùng thì nó đều thuộc về JAVAC. Có thể xem các tùy chọn tiêu chuẩn trong công cụ dòng lệnh JAVAC do Oracle/Sun cung cấp bằng cách chạy JAVAC -help và các tùy chọn mở rộng bổ sung có thể được xem bằng cách chạy JAVAC -help -X. Bạn có thể tìm thêm chi tiết về cách sử dụng các tùy chọn này trong tài liệu công cụ JAVAC dành cho Windows hoặc Unix/Linux. Như tài liệu Javac nói, tùy chọn -sourcepath có thể được sử dụng để thể hiện thư mục chứa các tệp nguồn. Trong cấu trúc thư mục của tôi được hiển thị trong ảnh chụp màn hình ở trên, điều này có nghĩa là, giả sử tôi đang chạy lệnh JAVAC từ thư mục C:\Java\examples\javacAndJava\ , tôi sẽ phải có nội dung như thế này trong lệnh của mình: Javac -sourcepath src SRC\Dustin\examples\*. Java . Ảnh chụp màn hình sau đây cho thấy kết quả của việc này. Vì chúng tôi không chỉ định thư mục cho các tệp .class nên chúng được đặt theo mặc định trong cùng thư mục với các tệp .java nguồn mà chúng được tạo ra. Chúng ta có thể sử dụng tùy chọn -dđể khắc phục tình trạng này. Lệnh của chúng tôi có thể được chạy ngay bây giờ, chẳng hạn như Javac -sourcepath src -dclass src\Dustin\examples\*. Tôi bạn . Như đã lưu ý trước đó, thư mục (các lớp) đã chọn phải tồn tại. Khi điều này xảy ra, lệnh sẽ đặt các tệp .class vào thư mục đã chỉ định như trong ảnh chụp màn hình sau. Với các tệp nguồn Java được biên dịch thành các tệp .class tương ứng trong thư mục đã chỉ định, chúng ta có thể khởi chạy ứng dụng bằng menu khởi chạy nhanh của Công cụ dòng lệnh Java. Điều này được thực hiện đơn giản bằng cách làm theo các hướng dẫn được cung cấp trên các trang Java -help hoặc công cụ Java và chỉ định vị trí của các tệp .class bằng tùy chọn -classpath( hoặc -cp). Việc sử dụng cả hai cách tiếp cận để chỉ định thư mục lớp nơi tìm tệp .class được minh họa trong ảnh chụp màn hình sau. Đối số cuối cùng là tên đầy đủ (toàn bộ gói Java) của lớp có chức năng chính được thực thi. Các lệnh được minh họa trong ảnh chụp màn hình sau đây là các lớp java -cp dustin.examples.Main và các lớp java -classpath dustin.examples.Main.

Xây dựng và chạy với Ant

Đối với các ứng dụng Java đơn giản nhất, việc sử dụng JAVAC và Java để tạo và chạy ứng dụng tương ứng là khá dễ dàng, như vừa trình bày. Khi các ứng dụng trở nên phức tạp hơn một chút (ví dụ: mã tồn tại trong nhiều gói/thư mục hoặc các lớp phụ thuộc phức tạp hơn trên các thư viện và khung công tác của bên thứ ba), cách tiếp cận này có thể trở nên khó sử dụng. Apache Ant là công cụ xây dựng Java "bộ ba lớn" lâu đời nhất và đã được sử dụng trong hàng nghìn ứng dụng và hoạt động triển khai. Như tôi đã nói trong bài đăng trên blog trước đây, rất dễ tạo một tệp xây dựng Ant rất đơn giản, đặc biệt nếu nó bắt đầu bằng một mẫu như tôi đã nêu trong bài đăng này. Danh sách mã sau đây dành cho tệp build.xml của Ant , có thể được sử dụng để soạn các tệp .java thành các tệp .class và sau đó chạy lớp dustin.examples.Main như đã được thực hiện ở trên với JAVAC và Java. xây dựng.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>

Tôi đã không sử dụng các thuộc tính Ant và không bao gồm các mục tiêu chung mà tôi thường đưa vào (chẳng hạn như "thuần túy" và "Javadoc") để giữ cho ví dụ này đơn giản nhất có thể và giữ nó sát với ví dụ trước bằng cách sử dụng JAVAC và Java . Cũng lưu ý rằng tôi đã bật "gỡ lỗi" được đặt thành "true" cho tác vụ JAVAC Ant vì điều này không đúng trong trường hợp Ant bị lỗi, nhưng đúng với mặc định của JAVAC. Không có gì ngạc nhiên khi tác vụ Javac và tác vụ Java Ant giống với các công cụ lệnh JAVAC và Java. Bởi vì tôi đã sử dụng tên mặc định Ant mong đợi một tệp xây dựng khi nó không được chỉ định rõ ràng (build.xml) và vì tôi đã cung cấp mục tiêu "Chạy" làm "mặc định" cho bản dựng này và vì tôi đã bao gồm "biên dịch" làm lần chạy phụ thuộc mục tiêu "Chạy" và vì Ant nằm trên đường dẫn của môi trường của tôi nên tất cả những gì tôi phải làm trên dòng lệnh là yêu cầu Ant biên dịch và chạy ví dụ về kiến ​​trong thư mục có tệp build.xml . Điều này được thể hiện trong ảnh chụp màn hình sau. Mặc dù tôi đã trình diễn việc biên dịch và chạy một ứng dụng Java đơn giản với Ant, nhưng tôi có xu hướng chỉ biên dịch với Ant và chạy bằng Java (hoặc một tập lệnh gọi Java nếu đường dẫn lớp nặng).

Xây dựng và chạy với Maven

Mặc dù Ant là công cụ xây dựng Java cốt lõi đầu tiên, Apache Maven cuối cùng đã nổi tiếng phần lớn nhờ việc áp dụng cấu hình dựa trên quy ước và hỗ trợ cho các kho thư viện dùng chung. Maven rất dễ sử dụng khi mã và các đối tượng được tạo tuân theo bố cục thư mục tiêu chuẩn của nó. Thật không may, ví dụ của tôi không tuân theo cấu trúc thư mục này, nhưng Maven cho phép chúng tôi ghi đè cấu trúc thư mục mặc định dự kiến. Danh sách sau đây là mã cho tệp Maven POM được sử dụng thay cho thư mục nguồn và đích, đồng thời cung cấp các thành phần bắt buộc tối thiểu khác cho bản dựng Maven bằng 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>

Vì tệp pom.xml ở trên xác định "defaultGoal" của "biên dịch" và vì tệp pom.xml là tùy chỉnh POM mặc định mà tệp thực thi Maven (MVN) tìm kiếm và vì thư mục bin cài đặt Maven nằm trên đường dẫn của tôi nên chỉ Tôi cần chạy "MVN" để biên dịch các tệp .class như được đề cập trong ảnh chụp màn hình sau. Tôi cũng có thể chạy ứng dụng đã biên dịch từ Maven bằng lệnh Mvn Exec: Java -Dexec.mainClass = dustin.examples.Main , được thấy trong ảnh chụp màn hình sau. Như với Ant, tôi có xu hướng không sử dụng Maven để chạy ứng dụng Java đơn giản của mình mà thay vào đó sử dụng Java trên mã được biên dịch (hoặc sử dụng tập lệnh gọi Java trực tiếp trên các lớp dài).

Xây dựng và chạy với Gradle

Gradle là công cụ mới nhất, hợp thời nhất và phong cách nhất trong ba công cụ xây dựng Java chính. Đôi khi tôi hoài nghi về bản chất của xu hướng, nhưng tôi đã tìm thấy rất nhiều điều thích về Gradle (được viết bằng Groovy thay vì XML, hỗ trợ Ant tích hợp, hỗ trợ Ivy tích hợp, cấu hình theo quy ước thật dễ dàng để cấu hình lại, hỗ trợ kho lưu trữ Maven, v.v.). Ví dụ sau đây cho thấy bản dựng Gradle có thể dùng để biên dịch và chạy một ứng dụng đơn giản. Đây là mã mẫu chính cho bài đăng này. Tôi đã trình bày ví dụ được điều chỉnh này trên blog Tùy chỉnh plugin Java cho Gradle đơn giản. 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'

Hai dòng đầu tiên của tệp build.gradle cho biết việc sử dụng plugin Java và plugin Ứng dụng, dẫn đến một loạt chức năng tự động được tích hợp vào bản dựng này. Việc xác định "sourceSets" và "sourceSets.main.output.classesDir" cho phép bạn ghi đè các thư mục Java mặc định của plugin Gradle cho mã nguồn Java và các lớp nhị phân được biên dịch tương ứng. "MainClassName" cho phép bạn chỉ định rõ ràng lớp nào sẽ được chạy trong Plugin ứng dụng. Dòng "defaultTasks" xác định các tác vụ sẽ chạy bằng cách chỉ cần nhập "Gradle" trên dòng lệnh: 'compileJava' là tác vụ mặc định do plugin Java cung cấp và 'Run' là tác vụ mặc định do plugin Ứng dụng cung cấp. Bởi vì tôi đã đặt tên cho các tập hợp là build.gradle và đó là lý do tại sao tôi đã chỉ định các tác vụ mặc định là 'compileJava' và 'Run' và vì tôi có thư mục bin cài đặt Gradle trong đường dẫn của mình nên tất cả những gì tôi phải làm để xây dựng và chạy các ví dụ là gõ 'Gradle' và điều này được thể hiện trong ảnh chụp màn hình sau. Ngay cả những người hoài nghi nhất cũng phải thừa nhận rằng các bản dựng Gradle rất khó thực hiện đối với ví dụ đơn giản này. Nó kết hợp tính ngắn gọn của việc dựa vào các quy ước và giả định nhất định với một cơ chế rất dễ dàng để ghi đè các giá trị mặc định khi cần thiết. Thực tế là nó ở dạng Groovy thay vì XML cũng rất hấp dẫn! Như với Ant và Maven, tôi có xu hướng chỉ xây dựng bằng các công cụ này và có xu hướng chạy các tệp .class đã biên dịch trực tiếp từ Java hoặc một tập lệnh gọi Java. Nhân tiện, tôi cũng có xu hướng lưu trữ các .class này trong một cái bình để khởi chạy, nhưng điều đó nằm ngoài phạm vi của bài viết này.

Phần kết luận

IDE thường không cần thiết để xây dựng các ứng dụng và ví dụ đơn giản và thậm chí có thể đắt hơn chi phí để xây dựng các ví dụ đơn giản. Trong trường hợp như vậy, khá dễ dàng để sử dụng JAVAC và Java để trực tiếp xây dựng và chạy các ví dụ. Ví dụ về việc tham gia nhiều hơn, một công cụ xây dựng như Ant, Maven hoặc Gradle trở nên hấp dẫn hơn. Thực tế là nhiều môi trường phát triển hỗ trợ các tiện ích xây dựng này có nghĩa là nhà phát triển có thể di chuyển sang IDE bằng cách sử dụng công cụ tích hợp được tạo trước đó trong quy trình nếu xác định rằng cần hỗ trợ IDE khi một ứng dụng đơn giản phát triển thành một dự án chính thức .