IDE 없이 Java 컴파일 및 실행

한때 reddit.com 의 IDE 없이 Java 컴파일 및 실행 주제에서 다음과 같은 질문이 있었습니다. 패키지 내부에 있는 Java 파일 그룹을 별도의 폴더로 컴파일하는 명령이 있습니까( bin 이라고 부르겠습니다 ) , 새 클래스 파일을 시작하려면 어떻게 해야 합니까? " 주제 작성자인 kylolink 는 다음과 같이 설명합니다. "Java를 사용하기 시작했을 때 Eclipse에 의존하여 모든 컴파일을 대신 수행했고 코드 작성에만 걱정이 있었습니다." 저는 이 질문을 여러 번 보았고 실제로 이 질문은 다음과 같습니다. GPS 시스템 및 IDE: 좋은지 나쁜지를 블로그에 게시하게 된 계기는 무엇입니까? 저는 강력하고 현대적인 Java IDE를 좋아하고 일상 생활을 더 쉽게 만들어 주지만, Java 없이 간단한 예제 Java를 구축하고 실행하는 방법을 아는 것도 이점이 있습니다. 이 게시물은 그것을 수행하는 방법에 대한 것입니다. 간단한 테스트로 Java를 배우는 것에 대한 내 블로그에서 나는 때때로 간단한 텍스트 편집기와 명령줄 도구를 사용하여 간단한 애플리케이션을 작성, 구축 및 실행하는 것을 좋아하는 방법에 대해 썼습니다. 이제 내가 선호하는 Java IDE에 얼마나 많은 "오버헤드"가 필요한지에 대해 꽤 좋은 아이디어를 얻었으며 프레임워크를 사용하여 얻은 이점이 "오버헤드"를 정당화하기에 충분한지 여부에 대해 초기 결정을 내렸습니다. 대부분의 실제 응용 프로그램에서 VL IDE가 많은 가치가 있다는 것은 의심의 여지가 없습니다. 그러나 가장 간단한 예제 애플리케이션의 경우 항상 그런 것은 아닙니다. 이 게시물의 나머지 부분에서는 이러한 상황에 대해 IDE 없이 Java 코드를 빌드하고 실행하는 방법을 보여줍니다.

Java 코드 작성 및 실행

예제를 더 명확하게 하기 위해 구성 또는 상속을 통해 서로 관련되고 Dustin.examples 라는 동일한 패키지에 있는 몇 가지 매우 간단한 Java 클래스를 사용하겠습니다 . 두 클래스에는 함수가 없습니다 main. 세 번째 클래스인 Main.java에는 mainIDE 없이 클래스를 실행하는 방법을 보여줄 수 있는 함수가 있습니다. 다음은 이 세 가지 클래스에 대한 코드입니다. 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 하위 디렉터리 아래에 있습니다. 또한 Javac이 존재하지 않는 경우 이 디렉토리를 생성하지 않도록 컴파일된 .class 파일을 보관하기 위해 클래스 하위 디렉토리(현재 비어 있음)를 만들었습니다.

JAVAC로 빌드하고 Java로 실행하기

Java 코드(Ant, Maven, Gradle 또는 IDE)를 작성하는 데 어떤 접근 방식을 사용하든 결국 JAVAC로 귀결됩니다. Oracle/Sun에서 제공하는 JAVAC 명령줄 ​​도구의 표준 옵션은 JAVAC -help를 실행하여 볼 수 있으며 추가 확장 옵션은 JAVAC -help -X를 실행하여 볼 수 있습니다. 이러한 옵션을 사용하는 방법에 대한 자세한 내용은 Windows 또는 Unix/Linux용 JAVAC 도구 설명서에서 확인할 수 있습니다. Javac 문서에 나와 있듯이 -sourcepath 옵션을 사용하여 소스 파일이 존재하는 디렉터리를 표현할 수 있습니다. 위 스크린샷에 표시된 디렉터리 구조에서 이는 C:\Java\examples\javacAndJava\ 디렉터리 에서 JAVAC 명령을 실행한다고 가정할 때 내 명령에 다음과 같은 내용이 있어야 함을 의미합니다. Javac -sourcepath src SRC\Dustin\examples\*. 자바 . 다음 스크린샷은 이에 대한 결과를 보여줍니다. .class 파일 에 대한 디렉토리를 지정하지 않았기 때문에 해당 파일 은 기본적으로 해당 파일이 구성된 소스 .java 파일 과 동일한 디렉토리에 배치되었습니다 . 옵션을 사용하여 이 상황을 해결할 수 있습니다. 이제 명령을 실행할 수 있습니다(예: Javac -sourcepath src -d 클래스 src\Dustin\examples\*). 나 당신 . 앞에서 설명한 것처럼 선택한 폴더(클래스)가 이미 존재해야 합니다. 이 경우 명령은 다음 스크린샷과 같이 지정된 폴더에 .class 파일을 배치합니다 . Java 소스 파일을 지정된 디렉터리의 해당 .class 파일로 컴파일하면 빠른 실행 메뉴를 사용하여 애플리케이션을 시작할 수 있습니다. 자바 명령줄 도구. 이는 Java 도움말 또는 Java 도구 페이지에 제공된 지침을 따르고 ( 또는 ) 옵션을 사용 하여 .class 파일의 위치를 ​​지정하면 됩니다 . 다음 스크린샷에서는 두 가지 접근 방식을 모두 사용하여 .class 파일을 찾을 클래스 디렉터리를 지정하는 방법을 보여줍니다. 마지막 인수는 실행할 기본 기능이 있는 클래스의 전체(전체 Java 패키지) 이름입니다. 다음 스크린샷에 표시된 명령은 Java 클래스 -cp Dustin.examples.Main 및 Java 클래스 -classpath Dustin.examples.Main입니다. -d-classpath-cp

Ant를 사용한 빌드 및 실행

가장 간단한 Java 애플리케이션의 경우 앞서 설명한 것처럼 JAVAC 및 Java를 사용하여 각각 애플리케이션을 생성하고 실행하는 것이 매우 쉽습니다. 애플리케이션이 좀 더 복잡해지면(예: 둘 이상의 패키지/디렉토리에 존재하는 코드 또는 타사 라이브러리 및 프레임워크의 더 복잡한 종속성 클래스) 이 접근 방식이 다루기 어려워질 수 있습니다. Apache Ant는 "3대" Java 빌드 도구 중 가장 오래된 것이며 수천 개의 애플리케이션과 배포에 사용되었습니다. 이전 블로그 게시물에서 말했듯이 매우 간단한 Ant 빌드 파일은 생성하기 쉽습니다. 특히 이 게시물에서 설명한 것과 같은 템플릿으로 시작하는 경우 더욱 그렇습니다. 다음 코드 목록은 Ant의 build.xml 파일에 대한 것입니다. 이 파일은 .java 파일을 .class 파일로 구성한 다음 위에서 JAVAC 및 Java로 수행한 것처럼 Dustin.examples.Main 클래스를 실행하는 데 사용할 수 있습니다 . 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>

나는 이 예제를 최대한 단순하게 유지하고 JAVAC 및 Java를 사용하여 이전 예제에 가깝게 유지하기 위해 Ant 속성을 사용하지 않았고 일반적으로 포함하는 공통 목표(예: "순수" 및 "Javadoc")를 포함하지 않았습니다. . 또한 JAVAC Ant 작업에 대해 "true"로 설정된 "debug"를 활성화했습니다. Ant 실패의 경우에는 true가 아니지만 JAVAC의 기본값에서는 true이기 때문입니다. 당연히 Javac 작업과 Java Ant 작업은 JAVAC 명령 도구 및 Java와 유사합니다. 기본 이름을 사용했기 때문에 Ant는 명시적으로 지정되지 않은 경우 빌드 파일(build.xml)을 예상하고 "실행" 대상을 이 빌드의 "기본값"으로 제공했으며 "컴파일"을 종속성 실행으로 포함했기 때문에 "실행" 대상이 있고 Ant가 내 환경 경로에 있었기 때문에 명령줄에서 내가 해야 할 일은 Ant가 build.xml 파일 이 있는 디렉토리에서 Ant 예제를 컴파일하고 실행하도록 하는 것뿐이었습니다 . 이는 다음 스크린샷에 나와 있습니다. Ant를 사용하여 간단한 Java 애플리케이션을 컴파일하고 실행하는 것을 시연했지만 Ant로만 컴파일하고 Java(또는 클래스 경로가 무거운 경우 Java를 호출하는 스크립트)를 사용하여 실행하는 경향이 있습니다.

Maven을 사용한 빌드 및 실행

Ant는 최초의 핵심 Java 빌드 도구였지만 Apache Maven은 결국 컨벤션 기반 구성 채택과 공유 라이브러리 저장소 지원으로 인해 명성을 얻었습니다. Maven은 코드와 생성된 객체가 표준 디렉터리 레이아웃을 따를 때 사용하기 쉽습니다. 불행히도 내 예제는 이 디렉터리 구조를 따르지 않지만 Maven을 사용하면 예상되는 기본 디렉터리 구조를 재정의할 수 있습니다. 다음 목록은 소스 및 대상 디렉터리 대신 사용되며 Maven 3.2.1을 사용하는 Maven 빌드에 필요한 기타 최소 필수 요소를 제공하는 Maven POM 파일용 코드입니다. 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 파일은 "compile"의 "defaultGoal"을 정의하고 있고 pom.xml 파일은 Maven 실행 파일(MVN)이 찾는 기본 POM 사용자 정의이고 Maven 설치 bin 디렉터리가 내 경로에 있기 때문에 다음 스크린샷에 언급된 대로 .class 파일을 컴파일하려면 "MVN"을 실행해야 합니다. 또한 Mvn Exec 명령인 Java -Dexec.mainClass = Dustin.examples.Main을 사용하여 Maven에서 컴파일된 애플리케이션을 실행할 수도 있습니다 . 이는 다음 스크린샷에서 확인할 수 있습니다. Ant와 마찬가지로 저는 간단한 Java 애플리케이션을 실행하기 위해 Maven을 사용하지 않고 대신 컴파일된 코드에서 Java를 사용합니다(또는 장기 실행 클래스에서 Java를 직접 호출하는 스크립트를 사용합니다).

Gradle을 사용한 빌드 및 실행

Gradle은 세 가지 주요 Java 빌드 도구 중 가장 최신이고 가장 트렌디하며 세련된 도구입니다. 나는 때때로 유행의 본질에 대해 회의적이지만 Gradle에 대해 좋아할 점을 많이 발견했습니다(XML 대신 Groovy로 작성, 내장 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 플러그인과 애플리케이션 플러그인의 사용을 나타내며, 결과적으로 이 빌드에 여러 기능이 자동으로 구축됩니다. "sourceSets" 및 "sourceSets.main.output.classesDir"을 정의하면 Java 소스 코드 및 컴파일된 바이너리 클래스에 대한 Gradle 플러그인의 기본 Java 디렉터리를 각각 재정의할 수 있습니다. "MainClassName"을 사용하면 해당 클래스 내에서 실행되어야 하는 클래스를 명시적으로 지정할 수 있습니다. 응용 프로그램 플러그인 "defaultTasks" 줄은 명령줄에 "Gradle"을 입력하여 실행할 작업을 정의합니다. 'compileJava'는 Java 플러그인에서 제공하는 기본 작업이고 'Run'은 응용 프로그램 플러그인에서 제공하는 기본 작업입니다. 어셈블리 이름을 build.gradle로 지정하고 기본 작업을 'compileJava' 및 'Run'으로 지정했으며 경로에 Gradle 설치 bin 디렉터리가 있으므로 예제를 빌드하고 실행하기 위해 해야 할 일은 다음과 같습니다. 'Gradle'은 다음 스크린샷에 나와 있습니다. 가장 큰 회의론자라도 이 간단한 예에서는 Gradle 빌드가 매우 미끄럽다는 점을 인정해야 합니다. 이는 특정 규칙 및 가정에 의존하는 간결함과 필요할 때 기본값을 재정의하는 매우 쉬운 메커니즘을 결합합니다. XML이 아닌 Groovy로 되어 있다는 점도 매력적이네요! Ant 및 Maven과 마찬가지로 저는 이러한 도구로만 빌드하는 경향이 있으며 Java 또는 Java를 호출하는 스크립트에서 직접 컴파일된 .class 파일을 실행하는 경향이 있습니다. 그건 그렇고, 나는 이러한 .class를 실행을 위해 jar에 보관하는 경향이 있지만 이는 이 기사의 범위를 벗어납니다.

결론

간단한 애플리케이션과 예제를 작성하는 데 IDE가 필요하지 않은 경우가 많으며 간단한 예제를 작성하는 데 드는 비용보다 훨씬 더 비쌀 수 있습니다. 이러한 경우 JAVAC 및 Java를 사용하여 예제를 직접 빌드하고 실행하는 것은 매우 쉽습니다. 참여도가 높아지는 예로 Ant, Maven 또는 Gradle과 같은 빌드 도구가 더욱 매력적입니다. 많은 개발 환경이 이러한 빌드 유틸리티를 지원한다는 것은 개발자가 간단한 애플리케이션이 본격적인 프로젝트로 성장함에 따라 IDE 지원이 필요하다고 판단한 경우 프로세스 초기에 생성된 내장 도구를 사용하여 IDE로 마이그레이션할 수 있음을 의미합니다. .