자바 클래스로더

Java Classloader

Java Class Loader는 Java Virtual Machine에 Java 클래스를 동적으로 로드하는 Java Runtime Environment의 일부분이다.[1]대개 클래스는 요구 시에만 로딩된다.자바 실행 시간 시스템은 파일 및 파일 시스템에 대해 알 필요가 없다. 이는 클래스 로더에 위임되기 때문이다.

소프트웨어 라이브러리는 관련 개체 코드의 모음입니다.자바 언어에서 라이브러리는 일반적으로 JAR 파일로 포장된다.라이브러리는 다른 유형의 개체를 포함할 수 있다.Jar 파일에 포함된 가장 중요한 유형의 객체는 Java 클래스다.클래스는 코드의 명명된 단위로 생각할 수 있다.클래스 로더는 라이브러리를 찾고, 라이브러리의 내용을 읽고, 라이브러리에 포함된 클래스를 로드할 책임이 있다.이 로딩은 일반적으로 프로그램에 의해 클래스가 호출될 때까지 발생하지 않는다는 점에서 "온디맨드"로 수행된다.지정된 이름의 클래스는 지정된 클래스 로더에 의해 한 번만 로드할 수 있다.

각 Java 클래스는 클래스 로더가 로드해야 한다.[2]또한, Java 프로그램은 외부 라이브러리(즉, 프로그램의 작성자가 아닌 다른 사람이 쓰고 제공하는 라이브러리)를 사용하거나, 적어도 일부의 라이브러리를 구성할 수 있다.

JVM이 시작되면 다음과 같은 3가지 클래스 로더가 사용된다.[3][4]

  1. 부트스트랩 클래스 로더
  2. 확장 클래스 로더
  3. 시스템 클래스 로더

부트스트랩 클래스 로더가 에 위치한 핵심 Java 라이브러리를[fn 1] 로드함<JAVA_HOME>/jre/lib디렉토리코어 JVM의 일부인 이 클래스 로더는 네이티브 코드로 작성된다.

확장 클래스 로더가 확장 디렉토리에 코드를 로드하는 경우(<JAVA_HOME>/jre/lib/ext,[3] 또는 에 의해 지정된 다른 디렉터리java.ext.dirs시스템 속성).

시스템 클래스 로더 로드 코드는 다음에서 발견됨java.class.path, 어느것이 지도에 있는가?CLASSPATH 환경 변수

사용자 정의 클래스 로더

Java 클래스 로더는 Java로 작성된다.따라서 Java Virtual Machine의 세부 정보를 이해하지 않고도 자신만의 클래스 로더를 만들 수 있다.모든 Java 클래스 로더는 새 클래스 로더가 인스턴스화되거나 가상 시스템의 시스템 기본 클래스 로더로 설정될 때 정의된 상위 클래스 로더를 가지고 있다.

이를 통해 다음을 실현할 수 있다(예:

  • 런타임에 클래스를 로드하거나 언로드합니다(예: HTTP 리소스에서도 런타임에 라이브러리를 동적으로 로드하는 경우).이것은 다음에 대한 중요한 기능이다.
    • Jython과 같은 스크립팅 언어 구현
    • 콩을 심는 사람을 써서.
    • 사용자 정의 확장 허용
    • 여러 네임스페이스가 통신할 수 있도록 허용.예를 들어 CORBA/RMI 프로토콜의 기초 중 하나이다.
  • 바이트 코드가 로드되는 방식을 변경한다(예를 들어, 암호화된 Java 클래스 바이트 코드를[5] 사용할 수 있음).
  • 로드된 바이트 코드를 수정한다(예: 가로 방향 프로그래밍 사용 시 측면의 로드 타임 짜임).

자카르타 EE의 클래스 로더

자카르타 EE(이전의 Java EE 및 J2EE) 애플리케이션 서버는 일반적으로 클래스 로더 트리에 의해 배치된 WAR 또는 EAR 아카이브에서 클래스를 로드하여 애플리케이션을 다른 애플리케이션과 분리하지만 배치된 모듈 간에 클래스를 공유한다.이른바 "서블릿 컨테이너"는 일반적으로 다중 클래스 로더 측면에서 구현된다.[2][6]

JAR 지옥

JAR hell은 DLL hell과 유사한 용어로, 분류 과정이 결국 작동하지 않게 될 수 있는 모든 다양한 방법을 설명할 때 사용된다.[7]JAR 지옥이 발생할 수 있는 세 가지 방법은 다음과 같다.

  • 시스템에 설치된 두 가지 버전의 라이브러리가 실수로 존재함.이것은 시스템에서 오류로 간주되지 않을 것이다.오히려, 이 시스템은 한 도서관이나 다른 도서관에서 클래스를 로드할 것이다.새 라이브러리를 사용 가능한 라이브러리 목록에 추가하는 대신 새 라이브러리를 추가하면 이전 라이브러리가 사용 중인 것처럼 애플리케이션이 계속 작동하게 될 수 있으며, 이는 당연히 해당될 수 있다.
  • 여러 라이브러리 또는 애플리케이션에는 서로 다른 버전의 라이브러리 foo가 필요하다.라이브러리 foo 버전이 동일한 클래스 이름을 사용하는 경우, 동일한 클래스 로더로 라이브러리 foo 버전을 로드할 방법이 없다.
  • 가장 복잡한 JAR 지옥 문제는 클래스 로딩 시스템의 전체 복잡성을 이용하는 상황에서 발생한다.Java 프로그램은 단일 "평평한" 클래스 로더만 사용할 필요는 없지만, 대신 여러 개의 (잠재적으로 매우 많은) 내포된 협력 클래스 로더로 구성될 수 있다.서로 다른 클래스 로더가 적재한 클래스는 개발자가 완전히 이해하지 못하는 복잡한 방식으로 상호작용할 수 있으며, 분석, 설명 및 해결이 어려운 오류나 버그로 이어질 수 있다.[8]

OSGi Alliance는 널리 채택되고 있는 ME, SE, EE의 현재 및 미래의 VM에 대해 JAR 지옥을 해결하는 것을 목표로 하는 모듈형 프레임워크를 명시했다(1998년 JSR 8로 시작).JAR 매니페스트의 메타데이터를 사용하여 JAR 파일(다발이라고 함)을 패키지 단위로 배선한다.번들은 패키지를 내보내고, 패키지를 가져오고, 패키지를 비공개로 유지할 수 있으며, 모듈화 및 버전 의존성 관리의 기본 구조를 제공한다.

JAR 지옥 문제를 해결하기 위해 Java Community Process — JSR 277이 2005년에 시작되었다.해상도 - Java Platform Module System - 새로운 배포 형식, 모듈 버전 관리 체계 및 공통 모듈 저장소(Microsoft와 유사함)를 도입하기 위한 것이다.NET의 글로벌 어셈블리 캐시).2008년 12월, 선은 JSR 277이 보류되었다고 발표했다.[9]자바 모듈 시스템은 나중에 자바 9에 포함된 "프로젝트 지그소"[10]로 재부팅되었다.2017년 출시된 모듈형 소프트웨어에 대한 지원도 포함하고 있는데, 모듈-info.java 파일로 소스 레벨에서 제어되는 '자바 플랫폼 모듈 시스템'이다.JRE가 제공하는 클래스 로딩의 기본 메커니즘을 사용하는 역호환성 방식으로 자바 런타임 환경을 위한 모듈화를 제공하는 것을 목표로 하는 OSGi 아키텍처와는 다른 철학을 따른다.그러나 버전이 다른 도서관의 통제된 공존 능력을 제공하지 않기 때문에 JAR 헬 문제를 해결하는 데는 적합하지 않다.[11]

참고 항목

각주

  1. ^ 이러한 라이브러리는 rt.jar, core.jar, server.jar 등으로 불리는 Jar 파일에 저장된다.

참조

  1. ^ Mcmanis, Chuck (October 1, 1996). "The basics of Java class loaders". JavaWorld. Retrieved 2020-07-13.
  2. ^ a b Christudas, Binildas (January 26, 2005). "Internals of Java Class Loading". onjava.com. Archived from the original on 2018-05-10.
  3. ^ a b "Understanding Extension Class Loading". The Java Tutorials. docs.oracle.com. Retrieved 2020-07-13.
  4. ^ Sosnoski, Dennis (April 29, 2003). "Classes and class loading". IBM DeveloperWorks. Retrieved 2008-01-26.
  5. ^ Roubtsov, Vladimir (May 9, 2003). "Cracking Java byte-code encryption". JavaWorld. Retrieved 2020-07-13.
  6. ^ deBoer, Tim; Karasiuk, Gary (August 21, 2002). "J2EE Class Loading Demystified". IBM DeveloperWorks. Retrieved 2008-01-26.
  7. ^ "Depot - Apache Incubator". Archived from the original on 2013-06-01.
  8. ^ "Taxonomy of class loader problems with Jakarta Commons Logging".
  9. ^ Mark Reinhold (September 20, 2010). "Project Jigsaw". Oracle Corporation. Archived from the original on 2015-12-08.
  10. ^ "Project Jigsaw". Oracle Corporation. Retrieved 2015-11-29.
  11. ^ Bartlett, Neil; Hackbarth, Kai (2016-09-22). "Java 9, OSGi and the Future of Modularity (Part 1)". InfoQ.

외부 링크