JRE

JRE 는 다 만들어진 자바 프로그램을 돌리기만 하는 꾸러미입니다. 소스를 컴파일하는 도구는 없습니다. 프로그램을 켜서 끝까지 굴리는 데 드는 것만 담았습니다. 서버에 자바 애플리케이션을 올려 돌리기만 할 생각이라면 이 꾸러미 하나로 충분합니다.

쉽고 빠른 이해

JRE 는 다 만들어진 자바 프로그램을 실행만 시켜 주는 꾸러미입니다. 자바로 짠 서버를 올릴 기계에 이것을 설치하면 프로그램이 돕니다.

자바 프로그램은 기계가 바로 알아듣는 명령이 아니라 자바 전용 명령어로 컴파일됩니다. 그 명령어를 읽어 지금 기계의 명령으로 옮겨 줄 물건이 없으면 프로그램이 한 줄도 안 돕니다. 그 물건과, 프로그램이 불러 쓰는 기본 기능 묶음을 한데 담아 놓은 것이 JRE 입니다.

어떻게 도는가:

자바 가상 머신을 띄우고 프로그램의 시작 클래스를 찾습니다
클래스를 읽어 들이면서 그 안의 명령어가 규칙에 맞는지 검사합니다
명령어를 지금 기계의 명령으로 옮겨 가며 실행하고, 안 쓰는 메모리를 알아서 회수합니다

대가가 있습니다. 프로그램 파일만으로는 못 돕니다. 돌릴 기계마다 이 꾸러미가 설치돼 있어야 합니다. 컴파일러가 빠져 있어 이것만으로는 소스를 고쳐 다시 빌드할 수 없습니다.

상세

JRE 는 Java Runtime Environment 의 줄임말입니다. 우리말로는 자바 실행 환경이라고 부르고, 다 만들어진 자바 프로그램을 켜서 돌리는 데 드는 것만 모아 놓은 꾸러미입니다. 자바로 짠 결제 서버를 기계 한 대에 올려 돌리려 할 때 그 기계에 설치하는 것이 이 꾸러미입니다.

「돌린다」가 무슨 일인지부터 갈라야 이 꾸러미가 왜 있는지 보입니다. javac 같은 컴파일러가 자바 소스를 클래스 파일로 옮겨 놓아도, 그 파일 안에는 기계가 바로 알아듣는 명령이 들어 있지 않습니다. 바이트코드라고 부르는 자바 전용 명령어가 들어 있습니다. 이 명령어를 읽어 지금 기계의 명령으로 옮겨 주는 물건이 따로 있어야 프로그램이 돕니다.

안에 들어 있는 것

옮겨 주는 물건이 JVM(Java Virtual Machine, 자바 가상 머신)입니다. JRE 는 이 JVM 과, 프로그램이 불러 쓰는 자바 표준 라이브러리를 함께 담습니다. 표준 라이브러리는 문자열 다루기, 목록, 파일 읽기, 네트워크 연결처럼 거의 모든 프로그램이 쓰는 기능을 미리 만들어 둔 클래스 묶음입니다.

컴파일된 클래스 파일은 이 라이브러리를 부르는 이름만 담고 있지 그 코드까지 품고 있지는 않습니다. 그래서 프로그램을 돌리는 기계에도 같은 라이브러리가 있어야 합니다. JRE 가 JVM 하나로 끝나지 않고 라이브러리를 같이 담는 까닭이 이것입니다.

JDK 와 갈리는 대목

JDK(Java Development Kit, 자바 개발 도구 모음)는 프로그램을 만드는 사람이 쓰는 꾸러미입니다. JRE 가 담는 것을 다 담습니다. 거기에 컴파일러와 개발용 도구를 더 얹습니다.

아래 그림이 둘의 포함 관계를 보입니다. 만드는 쪽인 JDK 안에 돌리는 쪽인 JRE 가 들어 있습니다.

flowchart TD
    subgraph JDK["JDK · 만드는 쪽"]
        C["javac 같은 개발 도구"]
        subgraph JRE["JRE · 돌리는 쪽"]
            V["JVM"]
            L["자바 표준 라이브러리"]
        end
    end

쓰임이 어디서 갈리는지는 아래 표가 보입니다.

	JRE	JDK
누구의 기계에 설치하나	프로그램을 돌리기만 하는 기계	프로그램을 만드는 사람의 기계
무엇이 들어 있나	JVM · 자바 표준 라이브러리	JRE 가 담는 것 전부 · 컴파일러 · 개발 도구
이것만으로 되는 일	이미 만들어진 클래스 파일 실행	소스 컴파일 · 실행 · 디버깅
이것만으로 안 되는 일	소스를 클래스 파일로 옮기기	—

개발 기계에는 JDK 를, 배포할 서버에는 JRE 를 설치하던 것이 오래된 관행입니다. 서버에는 컴파일러가 필요 없으니 설치본을 작게 가져가려는 선택이었습니다.

프로그램이 켜질 때 벌어지는 일

프로그램을 실행하면 JRE 는 먼저 JVM 을 띄우고 시작 클래스부터 찾습니다. 클래스를 찾아 읽는 일은 클래스로더가 맡습니다. 어느 디렉터리와, 클래스 파일을 여럿 묶어 놓은 JAR(Java Archive, 자바 묶음)을 뒤져야 하는지는 클래스패스가 알려 줍니다. 클래스 파일이 놓인 곳을 적어 둔 목록입니다. 클래스로더는 그 목록을 따라가며 프로그램이 쓰겠다고 한 클래스를 찾아 메모리에 올립니다.

읽어 온 클래스는 곧바로 실행되지 않고 검증을 한 번 거칩니다. 바이트코드가 형식에 맞는지, 없는 메모리를 건드리는 명령이 섞여 있지 않은지를 보는 검사입니다. 밖에서 받아 온 클래스 파일이 기계를 망가뜨리지 못하게 막는 관문입니다.

검사를 통과하면 JVM 이 바이트코드를 한 줄씩 읽어 지금 기계의 명령으로 옮겨 가며 실행합니다. 같은 부분이 자꾸 돌면 그때마다 옮기는 대신 기계어로 미리 옮겨 두고 그것을 씁니다. 이 일을 하는 것이 JIT(Just-In-Time, 실행 도중 컴파일) 컴파일러입니다.

실행 중에 또 하나 도는 것이 있습니다. 프로그램이 돌면서 안 쓰게 된 객체를 찾아 메모리를 되돌려 놓는 가비지 컬렉터입니다. 프로그램이 자기 손으로 메모리를 반납하지 않아도 되는 것이 가비지 컬렉터 덕분입니다.

지금까지의 순서를 한 장으로 보면 이렇습니다.

flowchart TD
    A["클래스 파일 · 바이트코드"] --> B["클래스로더 · 필요한 클래스를 찾아 읽는다"]
    B --> C["검증 · 명령어가 규칙에 맞나"]
    C --> D["실행 · 명령어를 기계의 명령으로 옮긴다"]
    D --> E["자주 도는 부분은 기계어로 미리 옮겨 둔다"]
    D --> F["안 쓰는 객체는 메모리에서 회수한다"]

이 과정 어디에도 원래 소스가 무슨 언어였는지는 나오지 않습니다. JRE 는 클래스 파일 안의 바이트코드만 봅니다. kotlinc 가 코틀린 소스를 같은 형식의 클래스 파일로 옮겨 주면, 그 파일도 자바로 짠 것과 똑같이 이 꾸러미 위에서 돕니다.

JRE 를 대신하는 실행 이미지

한동안은 자바 프로그램을 돌릴 기계마다 JRE 를 따로 내려받아 설치하는 것이 보통이었습니다. 요즘 자바 배포판은 JRE 에 해당하는 것을 JDK 안에 함께 넣어 둡니다. JRE 만 따로 내려받는 설치본을 내주지 않는 쪽이 많습니다.

대신 프로그램이 쓰는 부분만 골라 담은 실행 이미지를 만들어 프로그램과 같이 내보냅니다. jlink 같은 도구가 이 이미지를 만듭니다. 컨테이너에 자바 애플리케이션을 담을 때도 이 방식이 흔합니다.

이름은 그래도 남아 있습니다. 따로 내려받아 설치하는 JRE 가 없어졌어도, 실무에서 JRE 라고 하면 대개 이 실행 이미지, 곧 프로그램을 돌리는 데 필요한 것만 담은 묶음을 가리킵니다.

상세

안에 들어 있는 것

JDK 와 갈리는 대목

프로그램이 켜질 때 벌어지는 일

JRE 를 대신하는 실행 이미지

관련 항목

JRE 안에 들어 있는 구성 요소

JRE 를 담고 있거나 대신 만들어 내는 배포 꾸러미

JRE 가 읽어 들이는 실행 파일과 그 형식

클래스 파일을 만들어 JRE 에 넘기는 컴파일러

JRE 가 프로그램을 돌리며 쓰는 메모리 영역

JRE 를 켤 때 넘기는 실행 설정

JRE 를 안에 넣어 함께 배포하는 실행 환경

JRE 에서 자주 나는 오류

JRE 와 같은 역할을 맡는 다른 언어의 실행 환경

JRE 가 속하는 상위 분류