자바 런타임 환경

자바 가상 머신은 자바 런타임 환경의 핵심 구성 요소로, 자바 바이트코드를 실행하는 추상화된 컴퓨팅 장치이다. 썬 마이크로시스템즈의 제임스 고슬링을 중심으로 한 팀에 의해 설계되었으며, 1994년에 처음 발표되었다. 이 기술의 핵심 목적은 "한 번 작성하면 어디서나 실행된다"는 자바의 철학을 실현하기 위해, 특정 하드웨어나 운영 체제에 종속되지 않고 바이트코드를 해석하고 실행하는 가상의 플랫폼을 제공하는 것이다.

JVM의 아키텍처는 스택 기반의 가상 머신으로 설계되었다. 이는 대부분의 연산 명령어가 중앙 처리 장치의 레지스터가 아닌 메모리 상의 스택에서 피연산자를 꺼내고 결과를 다시 스택에 넣는 방식으로 동작함을 의미한다. JVM은 인터프리터 방식으로 바이트코드를 한 줄씩 실행하거나, 성능 최적화를 위해 JIT 컴파일 방식을 사용하여 자주 실행되는 바이트코드 구간을 네이티브 코드로 변환하여 실행 속도를 높인다.

자바 가상 머신은 자바 클래스 라이브러리와 긴밀하게 연동되어 동작한다. 클래스 로더가 컴파일된 .class 파일을 로드하면, JVM은 바이트코드 검증기를 통해 코드의 안전성을 검증한 후 실행한다. 또한 가비지 컬렉션이라는 자동 메모리 관리 기능을 통해 개발자가 명시적으로 메모리를 해제하지 않아도 사용되지 않는 객체를 정리하여 메모리 누수를 방지한다. 이러한 구조 덕분에 JVM은 다양한 운영 체제 위에서 동일한 자바 프로그램의 실행을 보장하는 플랫폼 독립성의 기반이 된다.

자바 클래스 라이브러리는 자바 런타임 환경의 핵심 구성 요소 중 하나로, 자바 가상 머신이 실행하는 자바 프로그램에 필수적인 기능을 제공하는 방대한 소프트웨어 라이브러리이다. 이 라이브러리는 자바 개발 키트에 포함되어 배포되며, 자바 애플리케이션이 운영 체제의 기본 기능에 직접 접근하지 않고도 표준화된 방식으로 시스템 리소스를 활용할 수 있게 한다. 이를 통해 플랫폼 독립성이 보장된다.

라이브러리는 수백 개의 클래스와 인터페이스로 구성되어 있으며, 크게 java.lang, java.util, java.io, java.net, java.awt 및 javax.swing 등의 패키지로 분류된다. 예를 들어, java.lang 패키지는 Object 클래스, String 클래스, 기본 데이터 타입의 래퍼 클래스 및 스레드 관리와 같은 언어의 기본 요소를 포함한다. java.io와 java.nio 패키지는 파일 시스템 입출력 및 네트워크 통신을 담당하며, java.util 패키지는 컬렉션 프레임워크, 날짜 및 시간 기능, 국제화 지원 등의 유틸리티를 제공한다.

이 라이브러리의 존재는 자바 프로그래머가 낮은 수준의 시스템 프로그래밍보다는 비즈니스 로직 구현에 집중할 수 있도록 한다. 또한, 라이브러리에 정의된 표준 API는 모든 호환 JVM 구현체에서 동일하게 동작함을 보장하여, 애플리케이션의 이식성을 극대화한다. 자바 클래스 라이브러리는 지속적으로 확장되어 자바 8의 람다 표현식 및 스트림 API 지원, 자바 9의 모듈 시스템 도입 등 새로운 언어 기능과 함께 발전해 왔다.

자바 개발 키트(JDK)는 자바 애플리케이션을 개발하는 데 필요한 모든 도구를 포함하는 소프트웨어 패키지이다. JDK의 핵심 구성 요소 중 하나가 바로 자바 런타임 환경(JRE)이며, JRE는 개발이 아닌 실행에 필요한 요소들로 구성된다. 따라서 JDK는 JRE를 포함하고 있으며, 여기에 컴파일러(javac), 디버거, 문서 생성기 등의 개발 도구가 추가된 형태이다.

개발자는 자바 프로그램을 작성하고 컴파일하기 위해 JDK를 설치해야 한다. 반면, 최종 사용자가 개발된 자바 애플리케이션을 실행하기 위해서는 JRE만 설치하면 된다. 이 관계는 JDK가 개발 환경을, JRE가 실행 환경을 제공한다는 점에서 명확히 구분된다. 역사적으로 오라클과 OpenJDK 프로젝트는 JDK와 JRE를 별도의 배포판으로 제공했으나, 최근 자바 버전에서는 이러한 구분이 모호해지는 경향이 있다.

JDK 내의 JRE는 일반적으로 독립 설치형 JRE와 동일한 자바 가상 머신(JVM)과 자바 클래스 라이브러리를 공유한다. 이는 JDK로 개발된 프로그램이 동일한 시스템의 JRE에서도 정상적으로 실행될 수 있도록 호환성을 보장한다. 결국, JDK와 JRE의 관계는 포괄적인 개발 도구 세트와 그 하위 집합인 런타임 실행 환경의 관계로 이해할 수 있다.

자바 런타임 환경의 핵심 특징 중 하나는 플랫폼 독립성이다. 이는 "한 번 작성하면, 어디서나 실행된다"는 자바의 기본 철학을 구현한 것이다. 자바 컴파일러는 소스 코드를 특정 운영 체제나 CPU 아키텍처에 종속된 기계어가 아닌, 중간 형태인 자바 바이트코드로 변환한다. 이 바이트코드는 JVM이 이해할 수 있는 표준화된 명령어 집합으로 구성되어 있다.

각 플랫폼에 맞게 구현된 자바 가상 머신은 이 바이트코드를 해석하고 실행하는 역할을 담당한다. 즉, 개발자는 윈도우, 리눅스, macOS 등 서로 다른 환경을 위해 프로그램을 재작성하거나 재컴파일할 필요가 없다. 동일한 바이트코드 파일을 각 플랫폼에 설치된 JRE 위에서 실행하면 된다. 이 구조는 이식성을 극대화하여 웹 애플리케이션부터 엔터프라이즈 시스템까지 광범위한 배포를 가능하게 했다.

그러나 완벽한 독립성을 위해서는 JVM 구현체가 표준 자바 가상 머신 규격을 준수해야 하며, 자바 클래스 라이브러리 역시 각 플랫폼에서 동일하게 동작하도록 네이티브 코드로 구현되어 제공된다. 이러한 계층적 구조 덕분에 자바 프로그램은 하드웨어와 운영 체제의 차이에서 자유로울 수 있다.

자바 런타임 환경의 핵심 구성 요소인 자바 가상 머신은 메모리 관리를 개발자로부터 자동화하여 중요한 기능을 제공한다. 이 자동 메모리 관리 시스템을 가비지 컬렉션이라고 부르며, C나 C++와 같은 언어에서 수동으로 처리해야 했던 메모리 할당과 해제의 복잡성과 오류 가능성을 크게 줄여준다.

가비지 컬렉션의 주요 목적은 프로그램이 더 이상 사용하지 않는 객체가 차지하고 있는 힙 메모리를 자동으로 회수하는 것이다. JVM은 프로그램 실행 중 지속적으로 객체들을 모니터링하며, 어떤 객체도 참조하지 않는, 즉 '도달 불가능한' 객체를 가비지로 판단한다. 이 과정은 일반적으로 애플리케이션의 실행 스레드와 별도로 백그라운드에서 수행되어 개발자의 직접적인 개입 없이 메모리 누수를 방지한다.

다양한 가비지 컬렉터 알고리즘이 존재하며, 각각 다른 성능 특성을 가진다. 예를 들어, Serial GC, Parallel GC, G1 GC 등이 있으며, 이들은 처리량, 지연 시간, 메모리 오버헤드 사이의 트레이드오프를 다르게 설계했다. 애플리케이션의 성격에 따라 적절한 가비지 컬렉터를 선택하거나 JVM의 매개변수를 튜닝할 수 있다.

이러한 자동화된 메모리 관리는 개발 생산성을 극대화하는 자바의 주요 장점 중 하나이다. 개발자는 명시적으로 메모리를 해제하는 코드를 작성할 필요 없이 비즈니스 로직에 집중할 수 있으며, 이는 더 안정적이고 유지보수하기 쉬운 소프트웨어 개발로 이어진다.

자바 런타임 환경의 핵심 기능 중 하나는 자바 바이트코드를 실행하는 것이다. 자바 컴파일러는 자바 소스 코드를 플랫폼에 독립적인 중간 형태인 바이트코드(.class 파일)로 변환한다. 이 바이트코드는 CPU나 운영 체제의 기계어가 아닌, 자바 가상 머신이 이해할 수 있는 명령어 집합으로 구성되어 있다.

바이트코드 실행은 주로 자바 가상 머신 내부에서 이루어진다. JVM은 이 바이트코드를 읽어들여 실제 시스템에서 실행 가능한 형태로 변환하고 수행한다. 초기 JVM 구현체들은 주로 인터프리터 방식을 사용하여 바이트코드를 한 줄씩 읽고 즉시 실행하는 방식을 취했다. 이 방식은 구현이 비교적 간단하고 메모리 사용량이 적다는 장점이 있지만, 반복적으로 해석해야 하는 코드의 경우 실행 속도가 느리다는 단점을 가진다.

성능 개선을 위해 현대의 JVM은 JIT 컴파일 방식을 적극적으로 활용한다. JIT 컴파일러는 프로그램 실행 중에 자주 사용되는 바이트코드 부분(핫스팟)을 감지하여, 해당 부분을 해당 플랫폼의 네이티브 기계어로 실시간 컴파일한다. 컴파일된 기계어 코드는 캐시에 저장되어, 이후 동일한 코드가 호출될 때는 인터프리트 과정 없이 직접 실행될 수 있게 되어 전체적인 실행 속도를 크게 향상시킨다.

이러한 바이트코드 실행 구조는 플랫폼 독립성이라는 자바의 주요 특징을 실현하는 기반이 된다. 개발자는 특정 운영 체제를 위한 코드를 작성할 필요 없이, 한 번 작성된 바이트코드를 어떠한 JVM이 설치된 환경에서도 동일하게 실행할 수 있다. 이는 웹 애플리케이션과 엔터프라이즈 소프트웨어 개발 및 배포에 큰 장점으로 작용해 왔다.

자바 런타임 환경의 보안 모델은 자바 가상 머신과 자바 클래스 라이브러리의 협력으로 구축된다. 이 모델의 핵심은 바이트코드 검증기를 통한 사전 검증과 샌드박스 실행 환경이다. 모든 자바 바이트코드는 실행 전에 검증 단계를 거쳐 메모리 접근 위반, 타입 규칙 위반, 스택 오버플로우 등 잠재적 위험을 차단한다. 이는 C나 C++ 같은 언어에서 발생할 수 있는 버퍼 오버런 같은 취약점을 원천적으로 방지하는 역할을 한다.

실행 시 보안은 클래스 로더와 보안 관리자가 담당한다. 클래스 로더는 계층적 구조를 통해 신뢰할 수 있는 자바 API와 사용자 클래스를 분리하고, 보안 관리자는 파일 시스템 접근, 네트워크 연결, 시스템 속성 읽기 등 중요한 작업에 대한 접근 권한을 통제한다. 특히 초기 자바 애플릿은 이 샌드박스 모델에 의해 웹 브라우저 내에서 제한된 권한만으로 실행되었다. 이러한 다층적 접근 방식을 통해 자바 애플리케이션은 플랫폼 독립성과 함께 높은 보안성을 유지한다.

클래스 로딩은 자바 가상 머신이 프로그램을 실행할 때 필요한 자바 클래스 파일을 찾아 메모리에 적재하고 연결하는 과정이다. 이 과정은 런타임 시 동적으로 이루어지며, 자바의 핵심적인 특징인 플랫폼 독립성과 동적 로딩을 가능하게 한다.

클래스 로딩은 주로 부트스트랩 클래스 로더, 확장 클래스 로더, 그리고 시스템 클래스 로더 (또는 애플리케이션 클래스 로더)라는 계층 구조를 가진 클래스 로더에 의해 수행된다. 각 클래스 로더는 부모 클래스 로더에게 클래스 로딩 요청을 위임하는 위임 모델을 따르며, 이는 보안과 이름 공간의 분리를 보장한다. 클래스 로딩 과정은 크게 로딩, 링크, 초기화의 세 단계로 나뉜다.

로딩 단계에서는 클래스 파일을 바이너리 데이터로 읽어와 자바 가상 머신 내부의 메서드 영역에 해당 클래스의 런타임 데이터 구조를 생성한다. 링크 단계는 다시 검증, 준비, 분석의 하위 단계를 포함한다. 검증에서는 읽어온 바이트코드가 자바 가상 머신 사양을 준수하는지 확인하고, 준비 단계에서는 클래스에 필요한 정적 필드에 메모리를 할당하며, 분석은 상수 풀 내의 심볼릭 레퍼런스를 실제 참조로 변환한다. 마지막으로 초기화 단계에서는 클래스의 정적 변수를 정의된 값으로 할당하고 정적 초기화 블록을 실행한다.

이러한 클래스 로딩 메커니즘 덕분에 자바 애플리케이션은 실행 중에 필요한 클래스를 필요할 때마다 동적으로 불러올 수 있다. 또한, 서로 다른 클래스 로더를 사용하면 동일한 클래스의 다른 버전을 별도의 이름 공간으로 분리하여 로딩할 수 있어, 애플리케이션 서버나 OSGi와 같은 모듈 시스템에서 유용하게 활용된다.

바이트코드 검증은 자바 가상 머신이 자바 바이트코드를 실행하기 전에 수행하는 안전 검사 과정이다. 이 과정은 클래스 로더에 의해 메모리에 로드된 클래스 파일의 바이트코드가 자바 가상 머신 규격을 준수하는지, 그리고 안전하게 실행될 수 있는지를 분석한다. 검증기의 주요 목적은 악의적이거나 잘못된 컴파일러에 의해 생성된 유해한 바이트코드가 시스템을 손상시키는 것을 방지하여 플랫폼의 보안과 안정성을 보장하는 것이다.

검증 과정은 주로 데이터 흐름 분석을 기반으로 이루어진다. 검증기는 바이트코드 명령어의 피연산자 타입, 스택 오버플로우 또는 언더플로우 가능성, 지역 변수의 초기화 여부, 메서드 접근 권한 등을 철저히 점검한다. 예를 들어, 정수 연산 명령어인 iadd가 실행될 때 스택 상단에 두 개의 정수형 값이 존재하는지 확인한다. 이러한 정적 분석을 통해 많은 잠재적 오류를 프로그램 실행 전에 걸러낼 수 있다.

검증이 성공적으로 완료된 바이트코드만이 이후 인터프리터나 JIT 컴파일 단계로 넘어가 실행된다. 이 메커니즘은 자바 런타임 환경이 제공하는 핵심 보안 모델의 기반이 되며, 네트워크를 통해 다운로드된 자바 애플릿이나 웹 스타트 애플리케이션과 같은 신뢰할 수 없는 코드의 실행을 안전하게 만든다. 따라서 바이트코드 검증은 자바의 "안전한 실행 환경"이라는 특성을 실현하는 데 필수적인 절차이다.

자바 가상 머신은 자바 바이트코드를 실행하는 주체이다. 초기 JVM은 바이트코드를 한 줄씩 읽고 해석하여 실행하는 인터프리터 방식을 주로 사용했다. 이 방식은 코드를 실행하기 전에 별도의 컴파일 과정이 필요 없다는 장점이 있지만, 같은 코드를 반복해서 실행할 때마다 매번 해석해야 하므로 성능상의 한계가 있었다.

이러한 성능 문제를 해결하기 위해 등장한 기술이 JIT 컴파일(Just-In-Time Compilation)이다. JIT 컴파일러는 프로그램 실행 중에 자주 사용되는 바이트코드 부분(예: 반복문, 메서드)을 감지하여, 해당 부분을 해당 플랫폼의 네이티브 코드로 실시간 컴파일한다. 이후에는 컴파일된 네이티브 코드를 직접 실행하여 인터프리터 방식보다 훨씬 빠른 실행 속도를 제공한다. 대표적인 JVM 구현체인 핫스팟 VM은 이 방식을 채택하고 있다.

JVM의 실행 방식은 인터프리터와 JIT 컴파일을 혼용한다. 일반적으로 프로그램 실행 초기에는 인터프리터 방식으로 빠르게 시작하고, 런타임 중에 성능 분석을 통해 핫스팟(자주 실행되는 코드 영역)을 식별하여 JIT 컴파일을 수행한다. 이 두 기술의 조합은 플랫폼 독립성을 유지하면서도 높은 실행 성능을 달성하는 자바 런타임 환경의 핵심 원리이다.

Oracle JRE는 오라클이 제공하는 자바 런타임 환경의 공식 구현체이다. 이는 자바 애플리케이션을 실행하는 데 필요한 핵심 구성 요소인 자바 가상 머신과 자바 클래스 라이브러리를 포함한다. 오라클은 썬 마이크로시스템즈를 인수한 후 자바 플랫폼의 주요 관리자 및 공급자 역할을 맡았으며, Oracle JRE는 데스크톱 및 서버 환경에서 가장 널리 사용되는 JRE 배포판 중 하나가 되었다.

Oracle JRE는 자바 SE 플랫폼 사양을 준수하며, 안정성과 성능에 중점을 둔다. 오라클은 정기적인 업데이트를 통해 보안 패치, 버그 수정 및 성능 개선을 제공한다. 이 배포판은 주로 기업 환경 및 상용 소프트웨어에서 사용되며, 오라클의 상업적 지원을 받을 수 있다는 점이 특징이다.

2019년 자바 11 릴리스 이후, 오라클은 무료 공개 업데이트를 중단하고 상용 라이선스 모델로 전환하였다. 이에 따라 생산 환경에서 Oracle JRE를 사용하려면 오라클로부터 유료 구독을 해야 한다. 이 정책 변화는 많은 사용자와 조직이 OpenJDK나 아마존 코레토와 같은 다른 무료 배포판으로 전환하는 계기가 되었다.

OpenJDK(Open Java Development Kit)는 자바 플랫폼, 표준 에디션(Java SE)의 공식적인 오픈 소스 구현체이다. 이 프로젝트는 2006년에 썬 마이크로시스템즈에 의해 시작되었으며, 현재는 오라클이 주도적으로 관리하고 있다. OpenJDK는 자바 개발 키트(JDK)의 참조 구현체 역할을 하며, 여기에는 자바 컴파일러, 자바 가상 머신(JVM), 자바 클래스 라이브러리 등 자바 애플리케이션을 개발하고 실행하는 데 필요한 모든 핵심 구성 요소가 포함되어 있다.

OpenJDK의 가장 큰 특징은 GNU 일반 공중 사용 허가서(GPL) 버전 2에 부속된 클래스패스 예외 조항 하에 공개된 자유 소프트웨어라는 점이다. 이 라이선스는 누구나 소스 코드를 자유롭게 사용, 수정, 배포할 수 있도록 보장한다. 이러한 개방성 덕분에 OpenJDK는 다양한 벤더와 커뮤니티가 자체 자바 런타임 환경(JRE) 및 JDK 배포판을 생성하는 기반이 되었다.

주요 상용 자바 런타임 환경인 Oracle JDK는 OpenJDK를 기반으로 구축되어 있으며, 몇 가지 상용 기능과 지원이 추가된 형태이다. 반면, 아마존 코레토(Amazon Corretto), 이클립스 아도푸툼(Eclipse Adoptium), 아즈룬 Zulu(Microsoft), 레드햇(Red Hat)의 빌드 등 다른 많은 무료 JDK 배포판들도 모두 OpenJDK 소스 코드를 그 근간으로 삼고 있다. 이는 자바 생태계의 표준과 호환성을 유지하는 데 기여한다.

OpenJDK 프로젝트는 자바 기술의 지속적인 진화를 위한 협업의 장이다. 새로운 기능 제안, 즉 자바 스펙 요청(JSR)이 자바 커뮤니티 프로세스(JCP)를 통해 표준으로 채택된 후, 그 구현 작업은 주로 OpenJDK 내에서 이루어진다. 예를 들어, 자바 9의 모듈 시스템(프로젝트 재규어), 자바 11의 새로운 릴리스 주기, 최신 자바 17의 기능들 대부분이 OpenJDK에서 개발되었다.

오라클 외에도 여러 기업과 커뮤니티에서 자체적인 자바 런타임 환경 구현체를 제공한다. 이러한 구현체들은 오픈소스 라이선스를 따르거나, 특정 하드웨어 플랫폼에 최적화되어 있으며, 라이선스 정책이나 지원 모델에서 차별점을 가진다.

가장 대표적인 예는 OpenJDK 프로젝트를 기반으로 한 배포판들이다. 아마존은 자체 관리형 OpenJDK 빌드인 아마존 코레토를 제공하며, 이클립스 재단에서는 이클립스 테무린을 개발하고 있다. Azul Systems는 저지연 가비지 컬렉션으로 유명한 자체 JVM인 주루(Zulu)와 주링(Zing)을 공개했다. IBM은 자사의 J9 가상 머신을 기반으로 한 IBM 세머루런타임을 제공한다. 또한 레드햇, SAP, 마이크로소프트 등 주요 기업들도 각자의 OpenJDK 배포판을 유지 관리하고 있다.

이러한 다양한 벤더의 존재는 개발자와 기업에게 선택의 폭을 넓혀준다. 특정 운영 체제나 클라우드 환경에 더 잘 통합된 버전을 선택하거나, 향상된 성능이나 보안 패치를 더 빠르게 제공하는 배포판을 채택할 수 있다. 특히 OpenJDK를 기반으로 한 구현체들은 오라클의 상용 라이선스 정책 변경 이후 그 중요성이 더욱 커졌다. 이는 자바 생태계가 단일 공급업체에 의존하지 않는 건강한 다원화 구조를 유지하고 있음을 보여준다.

자바 런타임 환경을 설치하고 실행하기 위해서는 기본적인 시스템 요구사항을 충족해야 한다. 요구사항은 설치하려는 JRE의 버전, 배포판(예: 오라클 JRE, OpenJDK), 그리고 대상 운영 체제에 따라 달라진다. 일반적으로 최신 버전의 JRE는 이전 버전보다 더 많은 시스템 자원을 필요로 하는 경향이 있다.

기본적으로 JRE는 x86 또는 x86-64 아키텍처의 CPU를 갖춘 시스템을 지원하며, ARM 아키텍처용 버전도 제공된다. 필요한 메모리(RAM) 용량은 실행할 자바 애플리케이션의 규모에 따라 크게 좌우되지만, JRE 자체를 실행하기 위한 최소 메모리는 일반적으로 128MB 정도이다. 그러나 현실적인 애플리케이션 실행을 위해서는 1GB 이상의 메모리를 권장한다. 디스크 공간은 JRE 설치본의 크기에 따라 보통 150MB에서 400MB 사이를 필요로 한다.

주요 운영 체제별로 공식적으로 지원되는 버전이 존재한다. 예를 들어, 윈도우의 경우 특정 버전 이상(예: 윈도우 10)을 요구할 수 있으며, 리눅스는 주요 배포판의 최신 버전을, macOS 역시 특정 버전 이상을 필요로 한다. 사용자는 공식 홈페이지나 배포판의 문서에서 자신의 시스템에 맞는 정확한 요구사항을 확인하는 것이 좋다. 또한, 64비트 운영 체제에서는 대응하는 64비트 JRE를 설치해야 최적의 성능을 얻을 수 있다.

자바 런타임 환경을 시스템에서 올바르게 사용하려면 환경 변수를 설정해야 한다. 주요하게 설정하는 환경 변수는 JAVA_HOME과 PATH이다.

JAVA_HOME 변수는 자바 개발 키트나 자바 런타임 환경이 설치된 최상위 디렉토리 경로를 가리킨다. 이 경로는 일반적으로 bin 디렉토리의 상위 디렉토리이다. 많은 자바 기반 애플리케이션과 서버 도구(예: 아파치 톰캣, 메이븐, 그레이들)는 이 변수를 참조하여 필요한 자바 실행 파일과 라이브러리를 찾는다. 올바른 JAVA_HOME 설정은 이러한 도구들이 정상적으로 동작하는 데 필수적이다.

PATH 변수는 운영 체제가 명령을 실행할 때 검색하는 디렉토리 목록을 포함한다. 여기에 JAVA_HOME의 bin 디렉토리 경로(예: %JAVA_HOME%\bin 또는 $JAVA_HOME/bin)를 추가하면, 터미널이나 명령 프롬프트에서 java, javac 등의 명령어를 경로 전체를 입력하지 않고도 직접 실행할 수 있게 된다. 이는 개발 및 작업 효율성을 크게 높여준다.

이러한 환경 변수 설정은 윈도우, 리눅스, macOS 등 모든 주요 운영 체제에서 필요하며, 설정 방법은 각 시스템의 관리 도구나 셸 설정 파일을 통해 이루어진다. 설정 후에는 새로운 터미널 세션을 시작하거나 시스템을 재부팅하여 변경 사항을 적용해야 한다.

자바 애플릿은 자바 프로그램이 웹 브라우저 내에서 실행될 수 있도록 설계된 오래된 기술이다. 애플릿은 HTML 문서에 <applet> 태그를 사용하여 삽입되었으며, 사용자의 컴퓨터에 설치된 자바 런타임 환경을 통해 실행되었다. 이 기술은 1990년대 중후반 웹에 풍부한 상호작용 기능과 멀티미디어 콘텐츠를 제공하는 주요 수단 중 하나였다.

그러나 자바 애플릿은 여러 심각한 보안 취약점을 노출시켰다. 악성 코드가 사용자의 시스템에 접근하거나 중요한 데이터를 유출할 수 있는 보안 문제가 지속적으로 보고되었다. 또한 애플릿을 실행하려면 별도의 브라우저 플러그인이 필요했고, 로딩 시간이 길어 사용자 경험을 저해하는 단점이 있었다.

이러한 보안 문제와 유지보수의 어려움, 그리고 HTML5, 자바스크립트, CSS3 등 최신 웹 표준 기술의 급속한 발전으로 인해 애플릿의 사용은 급격히 줄어들었다. 주요 웹 브라우저들은 보안을 이유로 점차 애플릿 지원을 중단하기 시작했고, 결국 모던 브라우저에서는 완전히 지원이 중단되었다.

결과적으로 자바 애플릿은 현재는 구식 기술로 분류되며, 현대적인 웹 개발에서는 사용되지 않는다. 애플릿 기반의 레거시 시스템을 유지보수하거나 마이그레이션해야 하는 경우를 제외하면, 새로운 프로젝트에서 애플릿을 고려하는 경우는 거의 없다.

자바 웹 스타트는 네트워크를 통해 자바 애플리케이션을 배포하고 실행하기 위한 애플리케이션 배포 기술이다. 사용자가 웹 브라우저에서 링크를 클릭하면 애플리케이션을 자동 다운로드하여 자바 런타임 환경 위에서 실행할 수 있게 해준다. 이 기술은 자바 애플릿의 한계를 보완하여 더 풍부한 기능을 가진 독립형 클라이언트 애플리케이션을 웹에서 쉽게 제공할 목적으로 개발되었다.

웹 스타트의 핵심은 JNLP 파일이다. 이 XML 기반의 기술은 애플리케이션에 필요한 JAR 파일, 필요한 자바 버전, 메모리 할당 등의 정보를 담고 있다. 자바 네트워크 런치 프로토콜을 사용하는 클라이언트 측 자바 웹 스타트는 이 기술을 다운로드하여 캐시에 저장하고, 지정된 자바 가상 머신으로 애플리케이션을 실행한다. 이를 통해 사용자는 항상 최신 버전의 애플리케이션을 실행할 수 있으며, 오프라인 모드에서도 캐시된 버전을 사용할 수 있다는 장점이 있었다.

그러나 보안 문제와 웹 기술의 발전으로 인해 웹 스타트의 사용은 점차 줄어들었다. 최신 웹 브라우저들이 NPAPI 같은 레거시 플러그인 지원을 중단하면서 실행 환경이 제한되었고, HTML5와 JavaScript 기반의 웹 애플리케이션이 더 보편적인 솔루션으로 자리 잡았다. 결국 오라클은 자바 9를 기점으로 웹 스타트를 자바 개발 키트와 자바 런타임 환경에서 제거했으며, 자바 11 이후 공식 배포판에서는 완전히 지원이 중단되었다.