자바 (소프트웨어 플랫폼)

섬네일|자바 기반 프로그램인 턱스기타

자바(Java)는 응용 소프트웨어를 개발하고 멀티 플랫폼 컴퓨팅 환경에서 배포하기 위한 소프트웨어 플랫폼을 제공하는 컴퓨터 소프트웨어 및 사양의 집합이다. 자바는 임베디드 시스템과 휴대 전화부터 기업용 서버 및 슈퍼컴퓨터에 이르기까지 매우 다양한 컴퓨팅 플랫폼에서 사용된다. 독립형 자바 애플리케이션보다 덜 일반적이었던 자바 애플릿은 일반적으로 안전한 샌드박스 환경에서 실행되어 HTML 페이지에 포함됨으로써 네이티브 애플리케이션의 많은 기능을 제공했다.

자바 프로그래밍 언어로 작성하는 것은 자바 가상 머신(JVM)에서 바이트코드로 배포될 코드를 생성하는 주된 방법이다. 에이다, 자바스크립트, 코틀린(구글이 선호하는 안드로이드 언어), 파이썬, 루비 등 다른 언어를 위한 바이트코드 컴파일러도 사용할 수 있다. 또한 클로저, 그루비, 스칼라를 포함하여 JVM에서 네이티브로 실행되도록 설계된 여러 언어가 있다. 자바 구문은 C와 C++에서 많은 부분을 차용했지만, 객체 지향 기능은 스몰토크와 오브젝티브-C를 모델로 삼았다. 자바는 포인터와 같은 특정 저급 구조를 피하고, 객체가 힙에 할당되며(일부 구현, 예를 들어 현재 오라클이 지원하는 모든 구현은 대신 스택에 할당하기 위해 이스케이프 분석 최적화를 사용할 수 있음) 객체 유형의 모든 변수가 참조인 매우 단순한 메모리 모델을 가지고 있다. 메모리 관리는 JVM에 의해 수행되는 통합된 자동 쓰레기 수집을 통해 처리된다.

 최신 버전 
최신 버전은 2025년 9월에 출시된 자바 25로, 최신 장기 지원 버전(LTS)이다. 이는 자바 8 LTS까지 이어지는 여전히 지원되는 몇 안 되는 LTS 버전 중 하나이다. 자바 6에 대한 오라클의 연장 지원은 2018년 12월에 종료되었다. 오픈 소스 플랫폼으로서 자바는 아마존, IBM, 아줄 시스템즈(Azul Systems), AdoptOpenJDK를 포함한 많은 배포처를 가지고 있다. 배포판에는 아마존 코레토(Amazon Corretto), 줄루(Zulu), AdoptOpenJDK, 리베리카(Liberica)가 포함된다. 오라클의 경우 자바 8을 배포하며 자바 11 등도 제공하는데, 이 둘은 모두 현재 지원되는 LTS 버전이다. 오라클(및 기타 업체)은 해결되지 않은 보안 문제로 인한 심각한 위험 때문에 자바 8보다 오래된 버전은 "시스템에서 제거할 것을 강력히 권장"한다. 자바 9(및 버전 10, 12~16, 18~20, 22~24)는 더 이상 지원되지 않으므로 오라클은 사용자에게 지원되는 버전으로 "즉시 전환"할 것을 조언한다. 오라클은 2019년 1월에 레거시 자바 8 LTS에 대한 마지막 상업용 무료 공개 업데이트를 발표했으며, 개인용 자바 8에 대한 공개 업데이트 지원은 무기한 계속할 예정이다.

 플랫폼 
자바 플랫폼은 자바 프로그래밍 언어로 작성된 프로그램의 개발과 실행을 용이하게 하는 프로그램 모음이다. 자바 플랫폼에는 실행 엔진(가상 머신이라고 함), 컴파일러 및 라이브러리 세트가 포함된다. 요구 사항에 따라 추가 서버 및 대체 라이브러리가 있을 수도 있다. 자바 플랫폼은 자바 프로그램이 모든 하드웨어 및 운영체제에서 동일하게 실행될 수 있도록 하기 위해 매우 다양한 하드웨어와 운영체제용으로 구현되었다.

자바 플랫폼은 여러 프로그램으로 구성되며, 각 프로그램은 전체 기능의 일부를 제공한다. 예를 들어, 자바 소스 코드를 자바 바이트코드(JVM을 위한 중간 언어)로 변환하는 자바 컴파일러는 자바 개발 키트(JDK)의 일부로 제공된다. JVM을 실시간(JIT) 컴파일러로 보완하는 자바 런타임 환경(JRE)은 중간 바이트코드를 즉석에서 네이티브 기계어로 변환한다. 자바 플랫폼에는 광범위한 라이브러리 세트도 포함되어 있다.

플랫폼의 핵심 구성 요소는 자바 언어 컴파일러, 라이브러리, 그리고 가상 머신 사양에 명시된 규칙에 따라 자바 중간 바이트코드가 실행되는 런타임 환경이다.

 애플리케이션 영역 
서로 다른 플랫폼은 서로 다른 등급의 장치와 애플리케이션 영역을 대상으로 한다.
 자바 카드: 작은 자바 기반 애플리케이션(애플릿)이 스마트카드 및 이와 유사한 메모리가 적은 장치에서 안전하게 실행될 수 있도록 하는 기술이다.
 자바 ME (Micro Edition): 저장 공간, 디스플레이 및 전력 용량이 제한된 장치를 위해 (프로파일로 알려진) 여러 라이브러리 세트를 지정한다. 모바일 장치, PDA, TV 셋톱박스, 프린터용 애플리케이션 개발에 자주 사용된다.
 자바 SE (Standard Edition): 데스크톱 PC, 서버 및 유사 장치에서의 범용 용도이다.
 자카르타 EE (Enterprise Edition): 자바 SE에 다계층 클라이언트-서버 기업용 애플리케이션에 유용한 다양한 API를 추가한 것이다.

 Java SE 

 Jakarta EE 

 자바 가상 머신 

자바 플랫폼의 핵심은 자바 바이트코드 프로그램을 실행하는 "가상 머신"이다. 이 바이트코드는 프로그램이 실행되는 하드웨어나 운영체제에 관계없이 동일하다. 그러나 자바 10(및 이전 버전)과 같은 새로운 버전에서 작은 변경 사항이 생겼으며, 이는 바이트코드가 일반적으로 전방 호환만 됨을 의미한다. 자바 가상 머신(JVM) 내에는 JIT(Just In Time) 컴파일러가 있다. JIT 컴파일러는 실행 시점에 자바 바이트코드를 네이티브 프로세서 명령어로 번역하고 실행 중에 네이티브 코드를 메모리에 캐싱한다.

중간 언어로 바이트코드를 사용함으로써 가상 머신을 사용할 수 있는 모든 플랫폼에서 자바 프로그램이 실행될 수 있다. JIT 컴파일러를 사용한다는 것은 자바 애플리케이션이 로딩 중의 짧은 지연 후, 그리고 모든 또는 대부분이 JIT 컴파일되어 "예열"되면 네이티브 프로그램만큼 빠르게 실행되는 경향이 있음을 의미한다.
JRE 버전 1.2부터 썬의 JVM 구현에는 인터프리터 대신 실시간 컴파일러가 포함되었다.

자바 프로그램은 플랫폼 독립적이지만, 이 프로그램을 실행하는 자바 가상 머신(JVM)의 코드는 그렇지 않다. 지원되는 모든 운영 플랫폼은 고유한 JVM을 가지고 있다.

 자바 개발 키트 

 자바 런타임 환경 

오라클이 배포하는 자바 런타임 환경(JRE)은 독립형 JVM(HotSpot), 자바 표준 라이브러리(자바 클래스 라이브러리), 구성 도구, 그리고 JDK 9에서 중단되기 전까지 브라우저 플러그인을 포함하는 무료 소프트웨어 배포판이다. 노트북 및 데스크톱 폼 팩터의 개인용 컴퓨터에 설치되는 가장 일반적인 자바 환경이다. JVM이 탑재되어 출시되는 피처폰 및 초기 스마트폰을 포함한 휴대 전화에는 자바 플랫폼의 마이크로 에디션을 대상으로 하는 애플리케이션을 실행하기 위한 JVM이 포함되었을 가능성이 높다. 한편, 자바 앱을 실행하는 대부분의 현대적 스마트폰, 태블릿 컴퓨터 및 기타 핸드헬드 PC는 JVM 사양과 호환되지 않는 오픈 소스 가상 머신을 포함하는 안드로이드 운영체제 지원을 통해 실행될 가능성이 높다. (대신 구글의 안드로이드 개발 도구는 자바 프로그램을 입력으로 받아 안드로이드 장치의 가상 머신용 네이티브 입력 형식인 달빅 바이트코드를 출력한다.)
오라클 BCL 계약이 적용된 JRE의 마지막 주요 보안 업데이트(CPU) 버전은 8u201이었고, 동일한 라이선스가 적용된 마지막 패치 세트 업데이트(PSU) 버전은 8u202였다. 라이선스 체계에 관계없이 마지막 오라클 JRE 구현은 9.0.4였다. 자바 플랫폼 SE 9부터 전체 플랫폼은 모듈로 그룹화되었다. Java SE 구현의 모듈화 덕분에 개발자는 사용자 장치에 적절한 Java SE 구현이 존재하는지에만 의존하는 대신, 애플리케이션을 사용하는 모든 모듈과 함께 묶을 수 있게 되었다.

 클래스 라이브러리 

대부분의 현대적 운영체제(OS)에서는 프로그래머의 작업을 단순화하기 위해 방대한 양의 재사용 가능한 코드가 제공된다. 이 코드는 일반적으로 애플리케이션이 런타임에 호출할 수 있는 동적 로드 라이브러리 세트로 제공된다. 자바 플랫폼은 특정 운영체제에 종속되지 않기 때문에 애플리케이션은 기존의 OS 라이브러리에 의존할 수 없다. 대신 자바 플랫폼은 현대 운영체제에서 흔히 볼 수 있는 것과 동일한 재사용 가능한 기능을 많이 포함하는 자체 표준 클래스 라이브러리 세트를 제공한다. 시스템 라이브러리의 대부분은 자바로 작성되어 있다. 예를 들어 스윙 라이브러리는 사용자 인터페이스를 그리고 이벤트를 직접 처리하여, 서로 다른 플랫폼이 구성 요소를 처리하는 방식 사이의 미묘한 차이를 제거한다.

자바 클래스 라이브러리는 자바 플랫폼 내에서 세 가지 목적을 수행한다. 첫째, 다른 표준 코드 라이브러리와 마찬가지로 자바 라이브러리는 프로그래머에게 항목 목록 유지 관리나 복잡한 문자열 파싱과 같은 일반적인 작업을 수행하기 위한 잘 알려진 함수 세트를 제공한다. 둘째, 클래스 라이브러리는 일반적으로 하드웨어와 운영체제에 크게 의존하는 작업에 대해 추상 인터페이스를 제공한다. 네트워크 액세스 및 파일 액세스와 같은 작업은 종종 각 플랫폼의 고유한 구현과 밀접하게 얽혀 있다. java.net 및 java.io 라이브러리는 네이티브 OS 코드에 추상화 계층을 구현한 다음, 자바 애플리케이션이 해당 작업을 수행할 수 있도록 표준 인터페이스를 제공한다. 마지막으로, 일부 기본 플랫폼이 자바 애플리케이션이 기대하는 모든 기능을 지원하지 않는 경우 클래스 라이브러리는 대체물을 제공하기 위해 에뮬레이션을 하거나 최소한 특정 기능의 존재 여부를 확인하는 일관된 방법을 제공함으로써 누락된 구성 요소를 우아하게 처리하도록 작동한다.

 언어 

"자바"라는 단어 자체는 대개 자바 플랫폼에서 사용하도록 설계된 자바 프로그래밍 언어를 가리킨다. 프로그래밍 언어는 일반적으로 "플랫폼"이라는 문구의 범위를 벗어나지만, 자바 프로그래밍 언어는 자바 7 이전에 자바 플랫폼의 핵심 부분으로 등재되었다. 따라서 언어와 런타임은 흔히 하나의 단위로 간주되었다. 그러나 자바 7 사양에서는 자바 언어와 자바 가상 머신을 별개의 독립체로 더 명확하게 취급하려는 노력이 이루어져 더 이상 단일 단위로 간주되지 않는다.

제3자들은 JVM을 대상으로 하는 많은 컴파일러나 인터프리터를 제작했다. 이들 중 일부는 기존 언어를 위한 것이고, 다른 것들은 자바 언어의 확장을 위한 것이다. 여기에는 다음이 포함된다:
 BeanShell – 자바를 위한 경량 스크립팅 언어 (JShell 참고)
 Ceylon – 불변성을 강조하는 객체 지향적이고 강한 정적 타입 프로그래밍 언어 (2023년부터 더 이상 유지 관리되지 않음)
 클로저 – 자바 플랫폼상의 현대적이고 동적인 함수형 프로그래밍 리스프 방언
 Gosu – 아파치 라이선스 2.0으로 출시된 범용 JVM 기반 프로그래밍 언어
 그루비 – 파이썬, 루비, 펄, 스몰토크의 기능을 갖춘, 자바와 완벽하게 상호 운용 가능하고 자바 구문과 호환되는 정적 및 동적 언어
 JRuby – 루비 인터프리터
 자이썬 – 파이썬 인터프리터
 코틀린 – 자바와 완벽한 상호 운용성을 갖춘 JVM(및 데스크톱, iOS 등 비 JVM)용 프로그래밍 언어 (구글이 안드로이드와 그 JVM을 위해 자바보다 선호하는 언어)
 라이노 – 자바스크립트 인터프리터
 스칼라 – "더 나은 자바"로 설계된, 자바와 호환되지 않는 구문을 가진 멀티 패러다임 프로그래밍 언어

 유사 플랫폼 

자바의 성공과 Write once, run anywhere 개념은 2002년부터 등장한 닷넷 프레임워크와 같은 다른 유사한 노력으로 이어졌으며, 이는 자바의 성공적인 측면을 많이 통합했다. 닷넷은 처음부터 여러 프로그래밍 언어를 지원하도록 구축된 반면, 자바 플랫폼은 처음에 자바 언어만 지원하도록 구축되었다(비록 그 이후로 많은 다른 언어가 JVM용으로 만들어졌지만). 자바와 마찬가지로 닷넷 언어는 바이트코드로 컴파일되고 JVM과 목적이 유사한 공통 언어 런타임(CLR)에 의해 실행된다. JVM과 마찬가지로 CLR은 자동 쓰레기 수집을 통해 메모리 관리를 제공하고 닷넷 바이트코드가 여러 운영체제에서 실행될 수 있도록 한다.

닷넷에는 처음에 J++로 불렸고 나중에 비주얼 J#으로 불린 자바와 유사한 언어가 포함되었으나 자바 사양과 호환되지 않았다. 이는 2007년에 단종되었으며 지원은 2015년에 종료되었다.

 성능 

JVM 사양은 구현 세부 사항과 관련하여 구현자에게 많은 자유를 준다. 자바 1.3부터 오라클의 JRE에는 핫스팟이라는 JVM이 포함되어 있다. 이는 고성능 JVM으로 설계되었다.

코드 실행 속도를 높이기 위해 핫스팟은 실시간 컴파일에 의존한다. 객체 할당 및 쓰레기 수집 속도를 높이기 위해 핫스팟은 세대별 힙(generational heap)을 사용한다.

 세대별 힙 
자바 가상 머신 힙은 동적 메모리 할당을 위해 JVM이 사용하는 메모리 영역이다.

핫스팟에서 힙은 세대로 나뉜다.
 Young generation은 생성되고 즉시 쓰레기 수집되는 수명이 짧은 객체를 저장한다.
 더 오래 지속되는 객체는 Old generation(tenured generation이라고도 함)으로 이동된다. 이 메모리는 첫 번째 및 다음 쓰레기 수집에서 살아남은 객체가 저장되는 (두 개의) Survivor 공간으로 세분화된다.

Permanent generation(또는 permgen)은 자바 8 이전까지 클래스 정의 및 관련 메타데이터에 사용되었다. Permanent generation은 힙의 일부가 아니었다. Permanent generation은 자바 8에서 제거되었다.

원래는 permanent generation이 없었으며 객체와 클래스가 같은 영역에 함께 저장되었다. 그러나 클래스 언로드(class unloading)는 객체 수집보다 훨씬 드물게 발생하기 때문에 클래스 구조를 특정 영역으로 이동하면 상당한 성능 향상을 이룰 수 있었다.

 보안 
자바 JRE는 수많은 컴퓨터에 설치되어 있다. 따라서 구 버전의 JRE를 사용하는 최종 사용자는 알려진 많은 공격에 취약하다. 이로 인해 자바가 본질적으로 안전하지 않다는 믿음이 널리 퍼졌다. 자바 1.7부터 윈도우용 오라클 JRE에는 자동 업데이트 기능이 포함되어 있다.

자바 브라우저 플러그인이 중단되기 전에는 모든 웹 페이지가 잠재적으로 자바 애플릿을 실행할 수 있었으며, 이는 악성 웹 사이트에 쉽게 접근 가능한 공격 표면을 제공했다. 2013년에 카스퍼스키 랩은 자바 플러그인이 컴퓨터 범죄자들이 가장 선호하는 수단이라고 보고했다. 자바 취약점 공격은 해커들이 해킹된 웹 사이트에 배포하는 많은 익스플로잇 팩에 포함되어 있다. 자바 애플릿은 2018년 9월 25일에 출시된 자바 11에서 제거되었다.

 자바 버전 

 역사 
섬네일|제임스 고슬링
자바 플랫폼과 언어는 1990년 12월 썬 마이크로시스템즈의 내부 프로젝트로 시작되었으며, C++/C 프로그래밍 언어의 대안을 제공했다. 엔지니어 패트릭 노턴은 썬의 C++ 및 C API와 도구의 상태, 그리고 조직에서 NeWS 프로젝트를 처리하는 방식에 대해 점점 더 불만을 갖게 되었다. 노턴은 스콧 맥닐리에게 썬을 떠나 NeXT로 옮길 계획임을 알렸다. 맥닐리는 그에게 자신이 신이라고 가정하고 회사를 고칠 방법을 설명하는 이메일을 보내달라고 요청했다. 노턴은 다른 썬 프로젝트를 지연시키는 관료주의 없이 자율적으로 일할 수 있는 소규모 팀의 창설을 구상했다. 맥닐리는 이 메시지를 썬의 다른 중요 인물들에게 전달했고 스텔스 프로젝트(Stealth Project)가 시작되었다.

스텔스 프로젝트는 곧 그린 프로젝트(Green Project)로 이름이 바뀌었고, 제임스 고슬링과 마이크 셰리던(Mike Sheridan)이 노턴과 합류했다. 다른 엔지니어들과 함께 그들은 캘리포니아주 멘로파크의 샌 힐 로드에 있는 작은 사무실에서 작업을 시작했다. 그들은 썬이 큰 새로운 기회를 제공할 것으로 기대했던 차세대 스마트 가전용 프로그래밍을 위한 새로운 기술 개발을 목표로 했다.

팀은 원래 C++ 사용을 고려했지만 여러 가지 이유로 거절했다. 자원이 제한된 임베디드 시스템을 개발하고 있었기 때문에, C++은 메모리를 너무 많이 사용하고 복잡성으로 인해 개발자 오류가 발생한다고 판단했다. 언어에 쓰레기 수집 기능이 없다는 것은 프로그래머가 시스템 메모리를 수동으로 관리해야 함을 의미했으며, 이는 까다롭고 오류가 발생하기 쉬운 작업이었다. 팀은 또한 보안, 분산 컴퓨팅, 스레딩을 위한 C++ 언어의 이식 가능한 시설 부족에 대해 우려했다. 마지막으로 그들은 모든 유형의 장치에 쉽게 이식될 수 있는 플랫폼을 원했다.

빌 조이는 메사와 C를 결합한 새로운 언어를 구상했다. 'Further'라는 논문에서 그는 썬의 엔지니어들이 C++ 기반의 객체 지향 프로그래밍 환경을 만들어야 한다고 제안했다. 처음에 고슬링은 C++을 수정하고 확장하려고 시도했지만(그가 "C++ ++ --"라고 지칭한 제안된 개발), 곧 자신의 사무실 바로 밖에 서 있던 나무의 이름을 따서 오크(Oak)라고 부르는 새로운 언어를 만드는 쪽으로 방향을 틀었다.

1992년 여름까지 팀은 그린 운영체제, 오크 언어, 라이브러리 및 하드웨어를 포함한 새로운 플랫폼의 일부를 시연할 수 있었다. 1992년 9월 3일의 첫 번째 시연은 그래픽 인터페이스와 사용자를 돕기 위한 "Duke"라는 스마트 에이전트를 갖춘 Star7이라는 개인 정보 단말기(PDA) 장치를 만드는 데 중점을 두었다. 그해 11월 그린 프로젝트는 썬 마이크로시스템즈의 완전 소유 자회사인 퍼스트퍼슨(Firstperson)으로 분사되었고 팀은 캘리포니아주 팰로앨토로 이전했다. 퍼스트퍼슨 팀은 고도의 대화형 장치 구축에 관심이 있었고, 타임 워너가 셋톱박스에 대한 제안요청서(RFP)를 발행했을 때 퍼스트퍼슨은 대상을 변경하여 셋톱박스 플랫폼에 대한 제안으로 응답했다. 그러나 케이블 TV 업계는 그들의 플랫폼이 사용자에게 너무 많은 제어권을 준다고 느꼈고, 퍼스트퍼슨은 SGI에 입찰에서 졌다. 3DO와의 셋톱박스에 대한 추가 거래도 결실을 맺지 못했다. 텔레비전 업계의 관심을 끌지 못하자 회사는 다시 썬으로 흡수되었다.

 자바와 웹의 만남 
섬네일|upright|존 게이지
1994년 6월과 7월 썬의 과학 책임자인 존 게이지, 고슬링, 조이, 노턴, 웨인 로징(Wayne Rosing), 에릭 슈밋이 사흘간 브레인스토밍을 한 후 팀은 플랫폼의 대상을 월드 와이드 웹으로 재설정했다. 그들은 모자이크와 같은 그래픽 웹 브라우저의 출현과 함께 인터넷이 케이블 TV를 위해 구상했던 것과 동일한 고도의 대화형 매체로 진화할 수 있다고 느꼈다. 노턴은 프로토타입으로 영화 블래이드 러너의 이름을 딴 작은 브라우저인 웹러너(WebRunner)를 썼으며, 이는 1995년에 핫자바로 이름이 바뀌었다.

썬은 상표권 검색 결과 오크 테크놀로지가 '오크'라는 이름을 사용하고 있다는 사실이 밝혀지자 오크 언어의 이름을 자바로 변경했다. 썬은 시장 점유율을 확보하기 위해 자바 라이선스 가격을 원가 이하로 책정했다. 자바 1.0a는 1994년에 다운로드할 수 있게 되었지만, 핫자바 브라우저를 포함한 자바의 첫 번째 공개 릴리스인 자바 1.0a2는 1995년 5월 23일 선월드(SunWorld) 컨퍼런스에서 게이지에 의해 발표되었다. 게이지의 발표와 더불어 넷스케이프의 부사장 마크 앤드리슨은 넷스케이프 브라우저가 자바를 지원할 것이라고 예기치 않게 발표했다. 1996년 1월 9일, 썬 마이크로시스템즈는 기술 개발을 위해 자바소프트(JavaSoft) 그룹을 결성했다.

웹 브라우저를 위한 소위 자바 애플릿은 더 이상 자바의 가장 대중적인 용도가 아니며(예를 들어 서버 측에서 더 많이 사용됨), 클라이언트 측에서 코드를 실행하는 가장 대중적인 방법(자바스크립트가 더 대중적으로 자리 잡음)도 아니지만, TeaVM 등을 사용하여 브라우저에서 JVM 지원이 중단된 후에도 여전히 웹 브라우저에서 자바(또는 코틀린과 같은 다른 JVM 언어)를 실행하는 것이 가능하다.

 GNU 일반 공중 사용 허가서 
2006년 11월 13일, 썬 마이크로시스템즈는 자바 구현의 대부분을 GNU 일반 공중 사용 허가서(GPL)에 따라 사용할 수 있게 했다.

 버전 역사 

자바 언어는 1996년 1월 23일 JDK 1.0이 출시된 이후 여러 번의 변화를 거쳤으며, 표준 라이브러리에 수많은 클래스와 패키지가 추가되었다. J2SE 1.4부터 자바 커뮤니티 프로세스(JCP)가 자바 언어의 발전을 관리해 왔다. JCP는 자바 사양 요청(JSR)을 사용하여 자바 플랫폼에 대한 추가 및 변경 사항을 제안하고 명시한다. 자바 언어 사양(JLS)은 언어를 규정하며, JLS의 변경 사항은 JSR 901에 따라 관리된다.

썬은 1997년 2월 19일에 JDK 1.1을 출시했다. 주요 추가 사항으로는 애브스트랙트 윈도 툴킷(AWT) 이벤트 모델의 대대적인 재정비, 언어에 추가된 내부 클래스, 자바 빈즈, JDBC가 포함되었다.

J2SE 1.2 (1998년 12월 8일) – 코드명 Playground. 이 버전과 J2SE 5.0까지의 후속 릴리스는 자바 2로 브랜드가 변경되었으며, 기본 플랫폼을 J2EE(자바 2 플랫폼, 엔터프라이즈 에디션) 및 J2ME(자바 2 플랫폼, 마이크로 에디션)와 구별하기 위해 버전 이름 "J2SE"(자바 2 플랫폼, 스탠더드 에디션)가 JDK를 대체했다. 주요 추가 사항으로는 리플렉션, 컬렉션 프레임워크, 자바 IDL(CORBA 상호 운용성을 위한 인터페이스 정의 언어 구현), 그리고 스윙 그래픽 API를 핵심 클래스에 통합한 것이 포함되었다. 자바 플러그인이 출시되었으며(그 후 웹 브라우저 업체들은 지원을 제거했고, 현재 자바 코드베이스에서 제거되도록 구식화되었으며 2026년 자바 26에서 제거될 예정이다), 썬의 JVM에 처음으로 JIT 컴파일러가 탑재되었다.

J2SE 1.3 (2000년 5월 8일) – 코드명 Kestrel. 주목할 만한 변경 사항으로는 핫스팟 JVM의 번들링(핫스팟 JVM은 1999년 4월 J2SE 1.2 JVM용으로 처음 출시됨), JavaSound, JNDI, 자바 플랫폼 디버거 아키텍처(JPDA)가 포함되었다.

J2SE 1.4 (2002년 2월 6일) – 코드명 Merlin. 이는 JSR 59에 따라 자바 커뮤니티 프로세스에서 개발된 자바 플랫폼의 첫 번째 릴리스가 되었다. 주요 변경 사항으로는 펄을 모델로 한 정규 표현식, 예외 체이닝, 통합 XML 파서 및 XSLT 프로세서(JAXP), 자바 웹 스타트가 포함되었다.

J2SE 5.0 (2004년 9월 30일) – 코드명 Tiger. 원래는 1.5로 번호가 매겨졌으며, 이는 여전히 내부 버전 번호로 사용된다. JSR 176에 따라 개발된 Tiger는 foreach 루프, 제네릭, 오토박싱, 가변 인자를 포함하여 몇 가지 중요한 새로운 언어 기능을 추가했다.

Java SE 6 (2006년 12월 11일) – 코드명 Mustang. 데이터베이스 관리자와 함께 번들로 제공되었으며 모질라의 라이노 엔진을 사용한 자바스크립트와 같이 JVM에서 스크립팅 언어를 쉽게 사용할 수 있게 했다. 이 버전부터 썬은 "J2SE"라는 이름을 Java SE로 바꾸고 버전 번호에서 ".0"을 뺐다. 다른 주요 변경 사항으로는 플러그형 자바 애너테이션(JSR 269) 지원, 윈도우 비스타의 룩앤필을 지원하기 위한 네이티브 UI 개선을 포함한 많은 GUI 개선, 더 나은 모니터링 및 문제 해결을 위한 자바 플랫폼 디버거 아키텍처(JPDA) 및 JVM 도구 인터페이스 개선이 포함되었다.

Java SE 7 (2011년 7월 28일) – 코드명 Dolphin. 이 버전은 JSR 336에 따라 개발되었다. switch 문에서의 문자열 사용, try-with-resources, 제네릭 인스턴스 생성을 위한 자료형 추론 등 많은 작은 언어 변화를 추가했다. JVM은 동적 언어 지원이 확장되었으며, 클래스 라이브러리는 포크/조인(join/fork) 프레임워크, 개선된 새로운 파일 I/O 라이브러리 및 SCTP와 같은 새로운 네트워크 프로토콜 지원 등이 확장되었다. 자바 7 업데이트 76은 2015년 1월에 출시되었으며 만료일은 2015년 4월 14일이었다.

자바 7의 마지막 공개 업데이트 이후인 2016년 6월, 자바 6, 7, 8에서 "원격 공격이 가능한" 보안 버그가 발표되었다.

Java SE 8 (2014년 3월 18일) 코드명 Kenai. 주목할 만한 변경 사항으로는 람다 표현식 및 디폴트 메서드에 대한 언어 수준의 지원, 프로젝트 나스혼(Nashorn) 자바스크립트 런타임, Joda Time에서 영감을 받은 새로운 날짜 및 시간 API, PermGen 제거가 포함되었다. 이 버전은 윈도우 XP 플랫폼에서 공식적으로 지원되지 않지만, 작동하는 것으로 알려져 있다. 따라서 자바 7의 수명 주기 종료로 인해 XP 사용자에게 권장되는 버전이다. 이전에는 윈도우 XP SP3에 대해 비공식적인 수동 설치 방법만 설명되었다. 이는 자바를 위한 개발 플랫폼이자 완벽하게 작동하는 자바 런타임 환경을 포함하는 JDK 8을 가리킨다. 자바 8은 윈도우 서버 2008 R2 SP1, 윈도우 비스타 SP2 및 윈도우 7 SP1, 우분투 12.04 LTS 이상(및 일부 다른 OS)에서 지원된다.

Java SE 9 및 10은 더 높은 시스템 요구 사항, 즉 윈도우 7 또는 서버 2012를 필요로 하며(웹 브라우저는 최소 인터넷 익스플로러 11 또는 기타 브라우저로 상향됨), 오라클은 모든 플랫폼에 대해 32비트 호환성을 중단했다. 즉, 오라클의 "64비트 자바 가상 머신(JVM)만 인증된다".

Java SE 11 LTS는 2018년 9월에 출시되었으며, 버전 9부터 시작된 빠른 릴리스 모델이 채택된 이후 첫 번째 LTS 릴리스이다. 처음으로 OpenJDK 11은 GNU 일반 공중 사용 허가서에 따라 자바 플랫폼의 완전한 소스 코드를 대표하며, 오라클은 여전히 선택적 사유 라이선스로 이중 라이선스를 부여하지만, 사유 라이선스 버전과 코드 차이나 고유한 모듈은 없다. 자바 11의 기능으로는 두 가지 새로운 쓰레기 수집기 구현, 심층적인 문제를 디버깅하기 위한 플라이트 레코더(Flight Recorder), 웹소켓 지원을 포함한 새로운 HTTP 클라이언트가 있다.

Java SE 12는 2019년 3월에 출시되었다.

Java SE 13은 2019년 9월에 출시되었다.

Java SE 14는 2020년 3월에 출시되었다.

Java SE 15는 2020년 9월에 출시되었다.

Java SE 16는 2021년 3월에 출시되었다.

Java SE 17 LTS는 2021년 9월에 출시되었다.

Java SE 18는 2022년 3월에 출시되었다.

Java SE 19는 2022년 9월에 출시되었다.

Java SE 20는 2023년 3월에 출시되었다.

Java SE 21 LTS는 2023년 9월에 출시되었다.

Java SE 22는 2024년 3월에 출시되었다.

언어의 변화 외에도 자바 클래스 라이브러리에도 수년 동안 상당한 변화가 있었으며, JDK 1.0의 수백 개 클래스에서 J2SE 5.0의 3,000개 이상으로 성장했다. 스윙 및 자바 2D와 같은 완전히 새로운 API가 진화했으며, 원래 JDK 1.0의 많은 클래스와 메서드는 구식화(그중 일부는 "최종적으로 구식화")되었다. 예를 들어 파이널라이제이션(finalization) 관련 항목들이 그러하다.

자바 22에서 거의 사용되지 않는 최소 하나 이상의 API(스레딩용)가 제거되었다.

 사용 

 데스크톱 사용 
섬네일|윈도우 비스타 데스크톱에서 실행 중인 자바 프로그램(자바 8에서 지원되지만, 자바 11과 같은 이후 버전에서는 공식적으로 지원되지 않음)

현재 자바는 64비트 윈도우 10(및 서버 2016) 이상, 64비트 macOS 13.x 이상, 64비트 리눅스(예: 오라클 엔터프라이즈 리눅스)에서 지원된다. 그 외의 운영체제는 오라클에 의해 지원되지 않지만(빌드용), IBM, SAP 등에 의해 지원되거나 AIX, 우분투, RHEL, Alphine/musl 등에서 작동하는 것으로 알려져 있다. 32비트 윈도우 지원은 자바 22부터 구식화되었다.

2010년 오라클에 따르면 자바 런타임 환경은 8억 5천만 대 이상의 PC에 설치되어 있었다. 마이크로소프트는 썬 마이크로시스템즈가 윈도우 전용 클래스를 자바 런타임 환경에 추가하고 비주얼 J++를 통해 새로운 클래스를 사용할 수 있게 한 것에 대해 소송을 제기한 이후 운영체제에 자바 런타임 환경(JRE)을 번들로 제공하지 않았다. 애플은 버전 10.7부터 OS X에 자바 런타임을 포함하지 않지만, JRE가 필요한 애플리케이션이 처음 실행될 때 사용자에게 다운로드 및 설치를 요청한다. 많은 리눅스 배포판은 OpenJDK 런타임을 기본 가상 머신으로 포함하여 사유 오라클 JRE를 다운로드할 필요를 없앴다.

넷빈즈, Eclipse, 젯브레인즈 통합 개발 환경, 그리고 라임와이어 및 Vuze와 같은 파일 공유 클라이언트를 포함하여 일부 자바 애플리케이션은 데스크톱에서 상당히 널리 사용되고 있다. 자바는 매트랩 수학 프로그래밍 환경에서도 사용자 인터페이스 렌더링과 핵심 시스템의 일부로 사용된다. 자바는 IBM 로터스 노츠(Lotus Notes)와 같은 일부 고급 협업 애플리케이션을 위해 크로스 플랫폼 사용자 인터페이스를 제공한다.

오라클은 JDK 9에서 자바 런타임 환경의 별도 설치 가능한 자바 브라우저 플러그인을 구식화한 후 향후 릴리스에서 완전히 제거할 계획이며, 웹 개발자가 대체 기술을 사용하도록 강제하고 있다.

 마스코트 
섬네일|80px|자바의 마스코트 듀크

듀크(Duke)는 자바의 마스코트이다.

썬이 자바 SE와 자바 ME를 자유 소프트웨어 라이선스(GNU 일반 공중 사용 허가서)에 따라 출시한다고 발표했을 때, 동시에 듀크 그래픽을 자유 BSD 허가서에 따라 공개했다. 매년 새로운 듀크 캐릭터가 생성된다. 예를 들어 2011년 7월 "Future Tech Duke"는 더 큰 코, 제트팩, 파란색 날개를 포함했다.

 라이선스 
썬의 자바 구현(즉, 사실상의 참조 구현)에 대한 소스 코드는 한동안 공개되어 왔지만, 최근까지 라이선스 조건은 썬과 계약을 체결하지 않고(일반적으로 비용 지불) 할 수 있는 작업을 엄격히 제한했다. 따라서 이러한 조건은 오픈 소스 이니셔티브나 자유 소프트웨어 재단이 오픈 소스 또는 자유 소프트웨어로 간주하기 위한 요구 사항을 충족하지 못했으며, 썬 자바는 따라서 사유 소프트웨어 플랫폼이었다.

여러 제3자 프로젝트(예: GNU 클래스패스 및 아파치 하모니)가 자유 소프트웨어 부분 자바 구현을 만들었지만, 클린 룸 설계 방식의 사용과 결합된 썬 라이브러리의 방대한 크기는 자바 라이브러리(컴파일러와 VM은 상대적으로 작고 잘 정의됨)의 구현이 불완전하고 완전히 호환되지 않음을 의미했다. 이러한 구현은 또한 썬의 것보다 훨씬 덜 최적화되는 경향이 있었다.

 자유 소프트웨어 

섬네일|upright|조너선 슈워츠 
썬은 자바원 2006에서 자바가 자유 및 오픈 소스 소프트웨어가 될 것이라고 발표했으며, 2006년 10월 25일 오라클 오픈월드 컨퍼런스에서 조너선 슈워츠는 회사가 30~60일 이내에 핵심 자바 플랫폼을 자유 및 오픈 소스 소프트웨어로 출시할 것이라고 발표할 예정이라고 말했다.

썬은 2006년 11월 13일에 자바 핫스팟 가상 머신과 컴파일러를 GNU 일반 공중 사용 허가서에 따라 자유 소프트웨어로 출시했으며, 2007년 3월까지 JDK의 나머지 부분(JRE 포함)을 GPL로 전환하겠다고 약속했다("썬이 GPL에 따라 배포 가능한 소스 형태로 게시할 권리가 없는 몇 가지 구성 요소 제외"). 리처드 스톨먼에 따르면 이것은 "자바 함정"의 종말을 의미했다. 마크 셔틀워스는 초기 언론 발표를 "자유 소프트웨어 커뮤니티를 위한 진정한 이정표"라고 불렀다.

썬은 2007년 5월 8일에 클래스 라이브러리의 소스 코드를 GPL로 출시했다. 단, 자신의 코드가 자유 소프트웨어 및 오픈 소스 라이선스로 출시되는 것을 원하지 않는 제3자로부터 썬이 라이선스를 받은 일부 제한된 부분은 제외되었다. 제약이 있는 부분 중 일부는 폰트 렌더링 및 2D 래스터라이징과 같이 플랫폼의 상당히 핵심적인 부분인 것으로 드러났지만, 이들은 나중에 썬에 의해 오픈 소스로 출시되었다(OpenJDK 클래스 라이브러리 참고).

썬의 목표는 사유 및 폐쇄 소스로 남아 있는 부분을 대체 구현으로 바꾸고 클래스 라이브러리를 완전히 자유롭고 오픈 소스로 만드는 것이었다. 그 사이에 IcedTea라는 제3자 프로젝트는 제약이 있는 코드를 스텁(stub)이나 GNU 클래스패스의 코드로 교체하여 완전히 자유롭고 사용성이 높은 JDK를 만들었다. 그러나 OpenJDK는 그 이후로 제약이 있는 부분 없이 빌드할 수 있게 되었으며(OpenJDK 6 b10부터), 대부분의 리눅스 배포판에서 기본 런타임 환경이 되었다.

2008년 6월, IcedTea6(페도라 9의 OpenJDK 패키지 버전)가 Technology Compatibility Kit 테스트를 통과했으며 완전히 호환되는 자바 6 구현임을 주장할 수 있다고 발표되었다.

OpenJDK는 GPL 하에 있기 때문에, 최종 사용자(또는 시스템 관리자)가 각자의 시스템에 직접 올바른 버전의 사유 오라클 JRE를 다운로드하여 설치하도록 요구하는 대신, 소프트웨어 애플리케이션과 함께 맞춤형 버전의 JRE를 직접 재배포하는 것이 가능하다.

 비판 

대부분의 경우 웹 브라우저에서 자바 지원은 불필요하며 보안 전문가들은 꼭 필요한 경우가 아니면 브라우저에서 실행하지 말 것을 권장한다. 몇몇 웹 사이트에서 자바가 필요한 경우 사용자는 해당 사이트 전용으로 별도의 브라우저를 설치하여 사용해야 한다는 의견도 있다.

 제네릭 

자바 5.0에 제네릭이 추가되었을 때 이미 방대한 클래스 프레임워크가 있었고(그중 다수는 이미 구식화됨), 마이그레이션 호환성과 이러한 기존 클래스의 재사용을 허용하기 위해 타입 이레이저(type erasure)를 사용하여 구현하도록 선택되었다. 이는 다른 일부 언어와 비교했을 때 이 기능이 제공할 수 있는 가능성을 제한했다. 타입 와일드카드의 추가는 자바를 불완전하게 만들었다.

 부호 없는 정수형 
자바에는 네이티브 부호 없는 정수형이 부족하다. 부호 없는 데이터는 C로 작성된 프로그램에서 자주 생성되며 이러한 유형의 부재는 C와 자바 간의 직접적인 데이터 교환을 방해한다. 부호 없는 큰 수는 암호학을 포함한 많은 수치 처리 분야에서도 사용되며, 이는 이러한 작업에 자바를 사용하는 것을 덜 편리하게 만들 수 있다.
변환 코드와 더 큰 데이터 유형을 사용하여 이 문제를 부분적으로 우회할 수 있지만, 자바를 사용하여 부호 없는 데이터를 처리하는 것을 번거롭게 만든다. 32비트 부호 있는 정수를 사용하여 16비트 부호 없는 값을 상대적으로 쉽게 보유할 수 있지만, 32비트 부호 없는 값은 64비트 부호 있는 정수가 필요하다. 또한 64비트 부호 없는 값은 자바 언어에 64비트보다 큰 유형이 존재하지 않기 때문에 자바의 어떤 정수 유형을 사용해도 저장할 수 없다. 함수를 사용하여 추상화하는 경우, 다른 일부 언어에서는 네이티브인 많은 작업에 함수 호출이 필요하게 된다. 대안으로 자바의 부호 있는 정수를 사용하여 동일한 크기의 부호 없는 정수를 에뮬레이션할 수 있지만, 이를 위해서는 복잡한 비트 연산에 대한 세부적인 지식이 필요하다.

 부동소수점 산술 
자바의 부동소수점 산술은 대체로 IEEE 754(이진 부동소수점 산술 표준)를 기반으로 하지만, IEEE 표준 754에서 요구하는 예외 플래그 및 지정 반올림(Directed Roundings)과 같은 특정 기능은 strictfp 제어자를 사용하더라도 지원되지 않는다. 또한 754에서 허용되고 많은 프로세서에 존재하는 확장 정밀도 부동소수점 유형은 자바에서 허용되지 않는다.

 성능 

자바의 초기 시절(2000년 자바 1.3에서 핫스팟 VM이 구현되기 전)에는 성능에 대한 몇 가지 비판이 있었다. 벤치마크에서는 일반적으로 자바가 (네이티브 코드로 컴파일되는 언어인) C보다 약 50% 느린 것으로 보고되었다.

자바의 성능은 초기 버전 이후 실질적으로 향상되었다. 네이티브 컴파일러와 비교한 JIT 컴파일러의 성능은 일부 최적화된 테스트에서 상당히 유사한 것으로 나타났다.

자바 바이트코드는 가상 머신에 의해 런타임에 해석될 수도 있고, 로드 시점이나 런타임에 컴퓨터 하드웨어에서 직접 실행되는 네이티브 코드로 컴파일될 수도 있다. 해석(Interpretation)은 네이티브 실행보다 느리며, 로드 시점이나 런타임의 컴파일은 컴파일을 위한 초기 성능 저하가 발생한다. 현대의 고성능 JVM 구현은 모두 컴파일 방식을 사용하므로 초기 스타트업 시간 이후의 성능은 네이티브 코드와 동등하다.

 보안 

자바 플랫폼은 사용자가 악성 소프트웨어나 잘못 작성된 소프트웨어로부터 보호하기 위해 "샌드박스" 방식으로 신뢰할 수 없는 바이트코드를 실행할 수 있도록 설계된 보안 아키텍처를 제공한다. 이 "샌드박스" 기능은 로컬 파일 시스템 액세스, 임의 명령 실행 또는 통신 네트워크 액세스와 같이 악성 소프트웨어에 의해 악용될 수 있는 특정 플랫폼 기능 및 API에 대한 액세스를 제한함으로써 사용자를 보호하기 위한 것이다.

최근 몇 년 동안 연구원들은 오라클의 구현을 포함하여 널리 사용되는 일부 자바 구현에서 신뢰할 수 없는 코드가 샌드박스 메커니즘을 우회하여 사용자를 악성 공격에 노출시킬 수 있는 수많은 보안 결함을 발견했다. 이러한 결함은 공용 웹 사이트에서 다운로드한 자바 애플릿을 실행하는 웹 브라우저 플러그인과 같이 임의의 신뢰할 수 없는 바이트코드를 실행하는 자바 애플리케이션에만 영향을 미친다. 사용자가 실행 중인 모든 코드를 신뢰하고 완전히 제어하는 애플리케이션은 영향을 받지 않는다.

2012년 8월 31일, 마이크로소프트 윈도우, OS X 및 리눅스에서 자바 6 및 7(당시 모두 지원됨)은 악성 웹 페이지를 로드하는 것만으로 원격 공격이 가능하게 하는 심각한 보안 결함이 있는 것으로 나타났다. 나중에 자바 5에서도 결함이 발견되었다.

2013년 1월 10일, 세 명의 컴퓨터 전문가가 자바에 대해 반대 의견을 표하며 로이터에 자바가 안전하지 않으며 사람들이 자바를 비활성화해야 한다고 말했다. 에일리언볼트 랩(AlienVault Labs)의 랩 매니저인 하이메 블라스코(Jaime Blasco)는 "자바는 엉망이다. 안전하지 않다. 비활성화해야 한다"고 밝혔다.
이 취약점은 자바 7에 영향을 미치며 자바 6에 영향을 미치는지 여부는 불분명하므로 소비자가 이를 비활성화할 것을 제안한다. 오라클의 보안 경고는 자바에 대한 중요한 보안 관련 패치 일정을 발표한다.

2013년 1월 14일, 보안 전문가들은 업데이트가 여전히 공격으로부터 PC를 보호하지 못한다고 말했다. 이 보안 구멍은 미국 국토안보부가 사용자들에게 자바를 비활성화하거나 제거하도록 권장하는 반응을 불러일으켰다. 애플은 바이러스 보호 프로그램을 통해 OS X 운영체제를 실행하는 모든 컴퓨터에 대해 한정된 명령으로 자바를 블랙리스트에 올렸다.

2014년, 당시의 자바 보안 및 취약점 문제에 대응하여 보안 블로거 브라이언 크렙스(Brian Krebs)는 사용자들에게 최소한 자바 브라우저 플러그인을 제거하고 소프트웨어 전체도 제거할 것을 요구했다. "나는 자바 플러그인이 없는 세상을 고대하며(그리고 독자들에게 분기별 패치 업데이트에 대해 상기시키지 않아도 되기를 고대하며), 전 세계 최종 사용자 시스템에서 이 플러그인의 다양한 버전이 대부분 제거되기까지는 아마 수년이 걸릴 것이다." "한때 유망했던 그것은 브라우저에서의 유용성을 다했으며, 컴퓨터 사용자를 희생시켜 사이버 범죄자들을 즐겁게 하는 악몽이 되었다." "나는 모든 사람이 모든 PC와 맥에서 자바를 제거한 다음, 다시 추가할 필요가 있는지 신중하게 생각해야 한다고 생각한다. 일반적인 홈 사용자라면 아마 그것 없이도 지낼 수 있을 것이다. 비즈니스 사용자라면 선택의 여지가 없을 수도 있다."

 애드웨어 
오라클이 배포하는 자바 런타임 환경은 설치 중이나 매달 정도마다 배포되는 업데이트 중에 기본적으로 설치되도록 후원 소프트웨어를 번들로 제공한 역사가 있다. 여기에는 브라우저 검색을 광고로 리디렉션하는 "Ask.com 툴바"와 "맥아피 시큐리티 스캔 플러스(McAfee Security Scan Plus)"가 포함된다. 이러한 제안은 자바 제어판의 설정(비록 이것이 명확하지는 않지만)을 통해 차단할 수 있다. 이 설정은 자바 제어판의 "고급" 탭 아래 "기타" 항목에 있으며, 옵션은 "스폰서 제안"을 억제하는 옵션으로 표시되어 있다.

 업데이트 시스템 
자바는 구글 크롬 및 플래시 플레이어와 달리 사용자 개입과 관리자 권한이 필요하지 않은 자동 업데이트 프로그램을 아직 출시하지 않았다.

 같이 보기 
 자바 API
 자바FX
 자바 가상 머신 지원 언어

 각주 

 외부 링크