Java 가상 머신

Java virtual machine
Java 가상 머신
디자이너Sun Microsystems
비트32비트
소개했다1994
버전15.0.3[1]
유형스택 등록-레지스터
부호화변수
분기비교 및 분기
엔디안니스큰.
열다.네.
레지스터
범용메서드 단위 오퍼랜드스택(최대 65535 오퍼랜드)과 메서드 단위 로컬 변수(최대 65535)
Java Virtual Machine Specification Java SE 7 Edition 기반의 Java Virtual Machine(JVM) 아키텍처 개요

Java Virtual Machine(JVM; Java 가상 머신)은 컴퓨터가 Java 프로그램뿐만 아니라 Java 바이트 코드로 컴파일된 다른 언어로 작성된 프로그램도 실행할 수 있도록 하는 가상 머신입니다.JVM은 JVM 구현에 필요한 사항을 공식적으로 설명하는 사양에 따라 자세히 설명되어 있습니다.사양을 갖추면 Java 프로그램의 상호 운용성이 보증되므로 Java Development Kit(JDK; Java 개발 키트)를 사용하는 프로그램 작성자는 기본 하드웨어 플랫폼의 특성에 대해 걱정할 필요가 없습니다.

JVM 참조 구현OpenJDK 프로젝트에서 오픈 소스 코드로 개발되며 HotSpot이라는 JIT 컴파일러를 포함합니다.Oracle에서 상업적으로 지원되는 Java 릴리스는 OpenJDK 런타임에 기반합니다.Eclipse OpenJ9은 OpenJDK용 또 다른 오픈 소스 JVM입니다.

JVM 사양

Java 가상 시스템은 규격에 따라 정의된 추상(가상) 컴퓨터입니다.Java 런타임 환경의 일부입니다.사용된 가비지 수집 알고리즘과 Java 가상 시스템 명령의 내부 최적화(기계 코드로 변환)는 지정되지 않았습니다.이러한 누락의 주된 이유는 시행자를 불필요하게 구속하지 않기 위해서이다.Java 애플리케이션은 Java 가상 [2]머신의 추상 사양의 구체적인 구현 내에서만 실행할 수 있습니다.

Java Platform Standard Edition(J2SE) 5.0 이후 JVM 사양의 변경은 Java Community Process에서 JSR 924로 [3]개발되었습니다.2006년 현재 JSR 924의 유지보수 릴리스로서 클래스 파일 형식(JSR 202)[4]에 제안된 변경을 지원하기 위한 사양 변경이 이루어지고 있습니다.JVM의 사양은 파란색 [5]책으로 출판되었습니다.서문에 다음과 같이 기술되어 있습니다.

이 사양은 호환성이 있는 클린룸 구현을 가능하게 하기 위해 Java Virtual Machine을 충분히 문서화할 것을 의도하고 있습니다.Oracle은 Java Virtual Machine 구현이 제대로 작동하는지 확인하는 테스트를 제공합니다.

Oracle의 JVM 중 하나는 HotSpot이고 다른 하나는 BEA Systems에서 상속받은 JRockit입니다.Oracle은 Java 상표를 소유하고 있으며, 이 상표를 사용하여 구현 스위트가 Oracle 사양과 완전히 호환된다는 것을 인증할 수 있습니다.

클래스 로더

JVM 바이트 코드의 조직 단위 중 하나는 클래스입니다.클래스 로더 구현은 Java 클래스 파일 형식을 준수하는 모든 것을 인식하고 로드할 수 있어야 합니다.구현은 클래스 파일 이외의 다른 바이너리 형식을 자유롭게 인식할 수 있지만 클래스 파일을 인식해야 합니다.

클래스 로더는 다음 세 가지 기본 액티비티를 엄격한 순서로 수행합니다.

  1. 로드: 유형에 대한 이진 데이터를 찾아서 가져옵니다.
  2. 링크: 검증, 준비 및 (옵션) 해결을 수행합니다.
    • 검증: Import된 유형이 올바른지 확인합니다.
    • 준비: 클래스 변수에 메모리를 할당하고 메모리를 기본값으로 초기화합니다.
    • 해결 방법: 기호 참조를 유형에서 직접 참조로 변환합니다.
  3. 초기화: 클래스 변수를 적절한 시작 값으로 초기화하는 Java 코드를 호출합니다.

일반적으로 클래스 로더에는 부트스트랩클래스 로더와 사용자 정의 클래스 로더의 두 가지 유형이 있습니다.

모든 Java 가상 시스템 구현에는 신뢰할 수 있는 클래스를 로드할 수 있는 부트스트랩 클래스 로더와 확장 클래스 로더 또는 애플리케이션 클래스 로더가 있어야 합니다.Java 가상 시스템 규격은 클래스 로더가 클래스를 찾는 방법을 지정하지 않았습니다.

가상 머신의 아키텍처

JVM은 Java Virtual Machine 사양에 지정된 특정 유형의 데이터에 대해 작동합니다.데이터 유형은 원시[6] 유형(정수, 부동 소수점, 롱 등)과 참조 유형으로 나눌 수 있습니다.이전의 JVM은 32비트 머신에 불과했습니다. long그리고.double64비트 타입은 네이티브로 지원되지만 각 유닛이 32비트이기 때문에 프레임의 로컬 변수 또는 오퍼랜드 스택에서 두 유닛의 스토리지를 소비합니다. boolean,byte,short,그리고.char타입은 모두 부호화됩니다(제외).char은 0-소수점)이며 32비트 정수는 다음과 같습니다.int작은 유형은 로드, 저장 및 유형 변환에 대한 몇 가지 유형별 지시만 있습니다. boolean8비트로 동작합니다.byte값, 0은 값을 나타냅니다.false및 1은 다음을 나타냅니다.true(단,booleanJava Virtual Machine Specification, Second Edition에서 이 문제를 명확히 한 이후 유형으로 취급되어 왔습니다.컴파일 및 실행 코드에서는 컴파일 및 실행 코드와 거의 차이가 없습니다.boolean및 abyte메서드 시그니처의 이름 망글링과 부울 배열 유형을 제외합니다. boolean메서드 시그니처의 s는 다음과 같이 뭉개집니다.Z하는 동안에byte는 로서 뭉개져 있다.B. 부울 배열은 유형을 전송합니다.boolean[]그러나 요소당 8비트를 사용하며 JVM에는 부울란을 비트 배열로 패킹하는 기능이 내장되어 있지 않기 때문에 부울란은 다음과 같이 동작합니다.byte어레이.기타 모든 용도에서는boolean타입은 JVM에 의해 효과적으로 알려져 있지 않습니다.부울란에서 동작하는 모든 명령도 동작하기 위해 사용되기 때문입니다.bytes.) 단, 새로운 JVM 릴리즈(OpenJDK HotSpot JVM)는 64비트를 지원하므로 64비트 OS 상에서 32비트/64비트 JVM을 사용할 수 있습니다.64비트 환경에서 Java를 실행하는 주된 장점은 주소 공간이 넓다는 것입니다.이것에 의해, Java 힙 사이즈를 크게 해, Java 스레드의 최대수를 늘릴 수 있습니다.이것은 특정 종류의 대규모 애플리케이션에 필요하지만, 32비트 JVM에 비해 64비트 JVM을 사용하면 퍼포먼스가 저하됩니다.

JVM에는 개체 및 어레이를 저장하기 위한 가비지 수집 힙이 있습니다.코드, 상수 및 기타 클래스 데이터는 "방법 영역"에 저장됩니다.메서드 영역은 논리적으로는 힙의 일부이지만 구현에서는 메서드 영역을 힙과 별도로 취급하거나 가비지 수집을 하지 않을 수 있습니다.각 JVM 스레드에는 프레임을 저장하는 자체 콜스택(명확성을 위해 "Java Virtual Machine 스택"이라고도 함)도 있습니다.메서드가 호출될 때마다 새 프레임이 생성되고 해당 메서드가 종료되면 프레임이 파기됩니다.

각 프레임은 "operand stack"과 "local variables" 배열을 제공합니다.오퍼랜드 스택은 오퍼랜드에서 계산 및 호출된 메서드의 반환값 수신에 사용되며 로컬 변수는 레지스터와 동일한 목적으로 사용되며 메서드 인수를 전달하기 위해서도 사용됩니다.따라서 JVM은 스택머신이자 레지스터 머신입니다.(실제로 HotSpot은 원어민 스레드/콜 스택을 제외한 모든 스택을 인터프리터 모드로 실행해도 완전히 제거합니다.템플릿 인터프리터는 엄밀히 말하면 컴파일러로 위장되어 있기 때문입니다.

바이트 코드 명령

JVM에는 다음 작업 그룹에 대한 지침이 있습니다.

목적은 바이너리 호환성입니다.각 특정 호스트 운영 체제에는 JVM 및 런타임의 자체 구현이 필요합니다.이러한 JVM은 바이트 코드를 의미적으로 같은 방식으로 해석하지만 실제 구현은 다를 수 있습니다.단순히 바이트 코드를 에뮬레이트하는 것보다 더 복잡한 것은 각 호스트 운영 체제에 매핑되어야 하는 Java 코어 API를 호환되고 효율적으로 구현하는 것입니다.

이러한 지침은 일련의 공통 사항에 따라 작동합니다.특정 명령어 집합 아키텍처의 네이티브 데이터 유형보다는 추상화된 데이터 유형입니다.

JVM 언어

JVM 언어는 Java Virtual Machine에서 호스팅할 수 있는 유효한 클래스 파일로 표현할 수 있는 기능을 가진 언어입니다.클래스 파일에는 Java Virtual Machine 명령(Java 바이트 코드)과 기호 테이블 및 기타 보조 정보가 포함됩니다.클래스 파일 형식은 컴파일된 클래스 및 인터페이스를 [7]나타내기 위해 사용되는 하드웨어 및 운영 체제 독립 바이너리 형식입니다.

JVM에는 몇 가지 JVM 언어가 있으며, 둘 다 JVM에 포팅된 오래된 언어와 완전히 새로운 언어입니다.JRubyJython은 아마도 현존하는 언어 중 가장 잘 알려진 항구일 것입니다.Ruby와 Python은 각각.Java 바이트 코드로 컴파일하기 위해 처음부터 작성된 새로운 언어 중 Clojure, Apache Groovy, Scala Kotlin이 가장 인기 있는 언어일 수 있습니다.JVM 언어에서 주목할 만한 기능은 서로 호환된다는 것입니다. 예를 들어, 스칼라 라이브러리는 Java 프로그램과 함께 사용할 수 있고 [8]그 반대도 가능합니다.

Java 7 JVM은 JSR 292: Java Platform에서 동적으로 입력된 언어를 지원하는 새로운 기능인 Supporting Dynamic Type[9] Languages를 구현합니다.이 기능은 JVM이 [10][11]자바 이외의 언어를 지원하도록 확장하는 것을 임무로 하는 다빈치 머신 프로젝트 내에서 개발되었습니다.

바이트 코드 검증자

Java의 기본 철학은 어떤 사용자 프로그램도 호스트 머신을 크래시하거나 호스트 머신의 다른 조작에 부적절하게 간섭할 수 없다는 점, 그리고 신뢰할 수 없는 코드에 의해 액세스 또는 손상으로부터 신뢰할 수 있는 코드에 속하는 특정 방법 및 데이터 구조를 보호할 수 있다는 점입니다.같은 JVM 내에서 에코하고 있습니다.또, 데이터 파손이나, 어레이의 끝부분에서 액세스 하거나, 초기화되지 않은 포인터를 사용하는 등 예측할 수 없는 동작을 일으키는 일반적인 프로그래머 에러는 발생하지 않습니다.클래스 모델, 가비지 수집 힙, 검증자 등 Java의 여러 기능이 결합되어 이러한 안전성을 제공합니다.

JVM은 실행하기 전에 모든 바이트 코드를 확인합니다.이 검증은 주로 다음 3가지 유형의 체크로 구성됩니다.

  • 브랜치는 항상 유효한 위치에 있습니다.
  • 데이터는 항상 초기화되며 참조는 항상 안전합니다.
  • 개인 데이터 또는 패키지 개인 데이터에 대한 액세스와 방법은 엄격하게 제어됩니다.

이러한 체크 중 처음 2개는 주로 클래스가 로드되어 사용 가능 상태가 되었을 때 발생하는 검증 단계에서 수행됩니다.세 번째는 주로 클래스의 데이터 항목 또는 메서드에 다른 클래스가 처음 액세스할 때 동적으로 수행됩니다.

검증자는 유효한 프로그램에서 일부 바이트 코드 시퀀스만 허용합니다. 예를 들어 점프(브런치) 명령동일한 메서드 내의 명령만 대상으로 할 수 있습니다.또한 검증자는 지정된 명령이 고정 스택 [12]위치에서 작동함을 보장하며, JIT 컴파일러는 스택 액세스를 고정 레지스터 액세스로 변환할 수 있습니다.따라서 JVM이 스택아키텍처라고 해서 JIT 컴파일러를 사용할 때 레지스터 기반 아키텍처에서의 에뮬레이션 속도가 저하되는 것은 아닙니다.그code-verified 자바 가상 머신 지원 구조의 얼굴에서, JIT컴파일러는 어느 쪽이든 간에 대상 구조의 등록에 할당되어야 한다 상상의 레지스터 또는 상상의 스택 위치의 이름을.사실, 코드 검증은 JVM을 활용한 Just-In-Time컴파일러로 효율적인 모방은 일반적으로 더 느린 통역관에 의해 수행한 복잡한는 전형적인 스택 구조에서 다르게 합니다.또한 통역사 기본 포장 및 충전기에 사용되는 특별한 형식이 템플릿 통역사는 원어민에 바이트 코드 변환합니다로 알려진, 레지스터 기반 기계 언어라기보다 전형적인 interpreter[13]( 많은 측면에서 HotSpot 통역사 고려할 수 있는 Just-In-Time컴파일러보다는 진정한 통역사), m 같은 스택을 모방하ean잉 감독이 변경 대상에는 스택 구조를 실제로 구현에 있지만, 사용하지 않는다 잘 등록을 바탕으로 구조( 스택 구조의 또 다른 인스턴스를 단지 내역과 등록을 바탕으로 가상 머신에서 구현된에서 구현될 수 있는 중간 대리를 위해 단순히 사양입니다.있나 공용 언어 런타임 cm이다.[14]

바이트 코드 검증자의 원래 사양은 불완전하거나 일부 점에서 잘못된 자연 언어를 사용했습니다.JVM을 정식 시스템으로 지정하기 위한 여러 시도가 이루어지고 있습니다.이를 통해 현재 JVM 구현의 보안을 보다 철저하게 분석하고 잠재적인 보안 공격을 방지할 수 있습니다.또한 실행 중인 애플리케이션이 [15]안전하다는 것이 입증되면 불필요한 안전 검사를 건너뛰어 JVM을 최적화할 수도 있습니다.

리모트 코드의 안전한 실행

가상 시스템 아키텍처를 사용하면 시스템 내에서 코드가 수행할 수 있는 작업을 매우 세밀하게 제어할 수 있습니다.이 경우 코드가 "의미적으로" 올바르다고 가정합니다. 즉, 툴에 의해 구현되는 (공식) 바이트 코드 검증 프로세스를 성공적으로 통과했으며, 가상 머신을 오프보드(Off-board)할 수 있습니다.이는 원격 소스에서 신뢰할 수 없는 코드, Java 애플릿에서 사용되는 모델 및 기타 안전한 코드 다운로드를 안전하게 실행할 수 있도록 설계되었습니다.바이트 코드가 확인되면 다운로드된 코드는 제한된 "샌드박스"에서 실행됩니다.이 샌드박스는 사용자를 잘못된 동작이나 악의적인 코드로부터 보호하기 위해 설계되었습니다.바이트코드 검증 프로세스와 더불어 퍼블리셔는 사용자에게 샌드박스에서 벗어나 로컬 파일 시스템, 클립보드, 외부 소프트웨어 또는 네트워크에 액세스하도록 허용함으로써 애플릿에 디지털 서명하기 위한 인증서를 안전하게 구입할 수 있습니다.

바이트 코드 검증의 정식 증명은 Javacard 업계에 의해 행해지고 있습니다(Java Card Byte[16] Code용 Embedded Verifier의 정식 개발).

바이트 코드 인터프리터 및 저스트 인 타임 컴파일러

하드웨어 아키텍처마다 다른 Java 바이트 코드인터프리터가 필요합니다컴퓨터에 Java 바이트 코드 인터프리터가 있으면 임의의 Java 바이트 코드 프로그램을 실행할 수 있으며, 이러한 인터프리터가 있는 모든 컴퓨터에서도 동일한 프로그램을 실행할 수 있습니다.

Java 바이트 코드가 인터프리터에 의해 실행되는 경우, 실행은 항상 네이티브 머신 언어로 컴파일된 동일한 프로그램의 실행보다 느려집니다.이 문제는 Java 바이트 코드를 실행하기 위한 JIT(Just-in-Time) 컴파일러에 의해 완화됩니다.JIT 컴파일러는 프로그램을 실행하는 동안 Java 바이트 코드를 네이티브 머신 언어로 변환할 수 있습니다.그러면 프로그램의 번역된 부분이 해석 가능한 것보다 훨씬 더 빨리 실행될 수 있습니다.이 기술은 자주 실행되는 프로그램의 이러한 부분에 적용됩니다.이렇게 하면 JIT 컴파일러는 전체 실행 시간을 대폭 단축할 수 있습니다.

Java 프로그래밍 언어와 Java 바이트 코드 사이에 필요한 연결은 없습니다.Java로 작성된 프로그램은 실제 컴퓨터의 기계어로 직접 컴파일할 수 있고 Java 이외의 언어로 작성된 프로그램은 Java 바이트코드로 컴파일할 수 있다.

Java 바이트 코드는 플랫폼에 의존하지 않고 안전한 [17]것을 목적으로 합니다.일부 JVM 구현에는 인터프리터가 포함되어 있지 않지만 Just-in-Time [18]컴파일러로만 구성되어 있습니다.

웹 브라우저의 JVM

Java 플랫폼의 수명 초기에 JVM은 리치애플리케이션을 만들기 위한 웹 기술로 마케팅되었습니다.2018년 현재 웹 브라우저를 번들하는 대부분의 웹 브라우저와 운영 체제에는 Java 플러그인이 포함되어 있지 않으며 플래시 이외의 플러그인도 사이드 로딩할 수 없습니다.Java 브라우저 플러그인은 JDK [19]9에서 사용되지 않습니다.

NPAPI Java 브라우저 플러그인은 JVM이 HTML 페이지에 내장된 이른바 Java 애플릿을 실행할 수 있도록 설계되었습니다.플러그인이 설치된 브라우저의 경우 애플릿은 할당된 페이지의 직사각형 영역에 그릴 수 있습니다.플러그인은 JVM을 포함하므로 Java 애플릿은 Java 프로그래밍 언어로 제한되지 않습니다. JVM을 대상으로 하는 언어는 플러그인에서 실행될 수 있습니다.제한된 API 세트를 통해 애플릿은 사용자의 마이크 또는 3D 가속에 액세스할 수 있지만 애플릿은 직사각형 영역 밖에서 페이지를 수정할 수 없습니다.주요 경쟁 기술인 Adobe Flash Player도 이와 동일한 방식으로 작동합니다.

W3Techs에 따르면 2015년 6월 현재 모든 웹사이트에서 Java 애플릿과 Silverlight의 사용률은 각각 0.1%로 떨어졌고 Flash는 10.8%[20]로 떨어졌다.

JavaScript JVM 및 인터프리터

2016년 5월 현재, JavaPoly는 수정되지 않은 Java 라이브러리를 가져오고 JavaScript에서 직접 호출할 수 있습니다.JavaPoly를 사용하면 [21]웹 사이트에서 수정되지 않은 Java 라이브러리를 사용할 수 있습니다. 이는 사용자가 컴퓨터에 Java를 설치하지 않은 경우에도 마찬가지입니다.

JavaScript로 컴파일

자바스크립트 실행속도가 지속적으로 향상되고 웹브라우저가 플러그인 지원을 구현하지 않는 모바일 디바이스의 사용이 증가함에 따라 자바스크립트로 컴파일하여 사용자를 공략하려는 노력이 이루어지고 있다.소스 코드 또는 JVM 바이트 코드를 JavaScript로 컴파일할 수 있습니다.

JVM 바이트 코드를 컴파일하면 언어의 기존 컴파일러를 기반으로 바이트 코드를 만들 수 있습니다.JavaScript 컴파일러의 주요 JVM 바이트 코드는 Dragome Web SDK,[23] Bck2Brwsr [24]및 j2js-compiler에 포함된 컴파일러인 [22][25]TeaVM입니다.

JVM 언어에서 JavaScript로 이어지는 주요 컴파일러에는 Google Web Toolkit에 포함된 Java-to-JavaScript 컴파일러(Clojure), GrooScript(Apache Groovy), Scala.js(Scala) [26]등이 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "jdk-updates/jdk15u: 1055f2102e6e". Oracle Corporation. Retrieved 2021-04-20.
  2. ^ Bill Venners, Java Virtual Machine 내부,
  3. ^ "The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 924". Jcp.org. Retrieved 2015-06-26.
  4. ^ "The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 202". Jcp.org. Retrieved 2015-06-26.
  5. ^ Java Virtual Machine Specification ( 번째 에디션과 두 번째 에디션도 온라인으로 이용 가능)
  6. ^ "Chapter 2. The Structure of the Java Virtual Machine".
  7. ^ "The Java Virtual Machine Specification : Java SE 7 Edition" (PDF). Docs.oracle.com. Retrieved 2015-06-26.
  8. ^ "Frequently Asked Questions - Java Interoperability". scala-lang.org. Retrieved 2015-11-18.
  9. ^ "The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 292". Jcp.org. Retrieved 2015-06-26.
  10. ^ "Da Vinci Machine project". Openjdk.java.net. Retrieved 2015-06-26.
  11. ^ "New JDK 7 Feature: Support for Dynamically Typed Languages in the Java Virtual Machine". Oracle.com. Retrieved 2015-06-26.
  12. ^ "The Verification process". The Java Virtual Machine Specification. Sun Microsystems. 1999. Retrieved 2009-05-31.
  13. ^ "Archived copy". Archived from the original on 2021-06-08. Retrieved 2021-05-24.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  14. ^ "Why not make CLR register-based? · Issue #4775 · dotnet/runtime". GitHub.
  15. ^ Freund, Stephen N.; Mitchell, John C. (1999). "A formal framework for the Java bytecode language and verifier". Proceedings of the 14th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications - OOPSLA '99. pp. 147–166. CiteSeerX 10.1.1.2.4663. doi:10.1145/320384.320397. ISBN 978-1581132380. S2CID 14302964.
  16. ^ http://www-sop.inria.fr/everest/Lilian.Burdy/CBR02dsn.pdf[베어 URL PDF]
  17. ^ David J. Eck, Java를 사용프로그래밍 소개, 제7판, 버전 7.0, 2014년 8월 섹션 1.3 "자바 가상 머신"
  18. ^ Oracle JRockit 인트로덕션 2015-09-06 Wayback Machine Release R28에서 아카이브 2. "Just-In-Time 컴파일 및 최적화 이해"
  19. ^ "Oracle deprecates the Java browser plugin, prepares for its demise". Ars Technica. 28 January 2016. Retrieved 15 April 2016.
  20. ^ "Historical yearly trends in the usage of client-side programming languages, June 2015". W3techs.com. Retrieved 2015-06-26.
  21. ^ Krill, Paul (13 May 2016). "JavaPoly.js imports existing Java code and invokes it directly from JavaScript". InfoWorld. Retrieved 18 July 2016.
  22. ^ "TeaVM project home page". Teavm.org. Retrieved 2015-06-26.
  23. ^ "Dragome Web SDK". Dragome.com. Retrieved 2015-06-26.
  24. ^ "Bck2Brwsr - APIDesign". Wiki.apidesign.org. Retrieved 2015-06-26.
  25. ^ 볼프강 쿤(디케이터).j2js-compiler GitHub
  26. ^ "List of languages that compile to JS · jashkenas/coffeescript Wiki · GitHub". Github.com. 2015-06-19. Retrieved 2015-06-26.
  • Java Virtual Machine 사양에 대한 설명 및 수정, Second Edition에는 J2SE 5.0 및 JSR 45를 지원하기 위한 변경 사항 목록이 포함되어 있습니다.
  • JSR 45, Java로 변환되는 JavaServer Pages(JSP)나 SQLJ 등의 언어의 소스 레벨 디버깅을 지원하기 위해 클래스 파일 형식의 변경을 지정합니다.