close
본문으로 이동

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

위키백과, 우리 모두의 백과사전.
자바 (소프트웨어 플랫폼)
원저자제임스 고슬링, 썬 마이크로시스템즈
개발자오라클
발표일1996년 1월 23일(30년 전)(1996-01-23)[1][2]
프로그래밍 언어자바, C++, C, 어셈블리어[3]
운영 체제마이크로소프트 윈도우 10+, 리눅스, macOS,[4] 구 버전: 솔라리스
플랫폼x64, ARMv8, 구 버전: ARMv7, IA-32, SPARC (자바 14까지) (자바 8은 윈도우32비트 지원을 포함하지만  더 이상 오라클에서 상업적 용도로 무료 지원하지 않는다)[4]
언어영어, 중국어, 프랑스어, 독일어, 이탈리아어, 일본어, 한국어, 포르투갈어, 스페인어, 스웨덴어[5]
종류소프트웨어 플랫폼
라이선스이중 라이선스: classpath 예외가 포함된 GNU 일반 공중 사용 허가서 버전 2,[6]사유 소프트웨어 라이선스.[7]
웹사이트
Image
자바 기반 프로그램인 턱스기타

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

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

최신 버전

[편집]

최신 버전은 2025년 9월에 출시된 자바 25로, 최신 장기 지원 버전(LTS)이다. 이는 자바 8 LTS까지 이어지는 여전히 지원되는 몇 안 되는 LTS 버전 중 하나이다. 자바 6에 대한 오라클의 연장 지원은 2018년 12월에 종료되었다.[9] 오픈 소스 플랫폼으로서 자바는 아마존, IBM, 아줄 시스템즈(Azul Systems), AdoptOpenJDK를 포함한 많은 배포처를 가지고 있다. 배포판에는 아마존 코레토(Amazon Corretto), 줄루(Zulu), AdoptOpenJDK, 리베리카(Liberica)가 포함된다. 오라클의 경우 자바 8을 배포하며 자바 11 등도 제공하는데, 이 둘은 모두 현재 지원되는 LTS 버전이다. 오라클(및 기타 업체)은 해결되지 않은 보안 문제로 인한 심각한 위험 때문에 자바 8보다 오래된 버전은 "시스템에서 제거할 것을 강력히 권장"한다.[10][11][12][13] 자바 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

[편집]

자바 플랫폼 스탠더드 에디션(Java Platform, Standard Edition, 약자 Java SE)는 데스크톱서버, 최근의 고사양 임베디드 시스템을 위한 표준 자바 플랫폼으로 표준적인 컴퓨팅 환경을 지원하기 위한 자바 가상 머신 규격 및 API 집합을 포함한다. 따라서 자바 EE, 자바 ME 등 다른 플랫폼은 구체적인 목적에 따라 자바 SE를 기반으로 API를 추가하거나 자바 가상 머신 규격 및 API의 일부를 택해서 정의된다.

자바 플랫폼에 에디션 분류가 도입된 것은 자바 1.2부터로 이전 1.1.x 버전과의 큰 차이를 감안해 자바 2로 부르고 서버 시스템을 위한 API를 추가한 엔터프라이즈 에디션(자바 2 EE), 그 때까지 임베디드 시스템을 위해 만들어진 퍼스널자바(PersonalJava) 및 임베디드자바EmbeddedJava)를 계승한 임베디드 에디션(자바 2 ME) 브랜드를 추가했다. 이후 1.4.x 버전까지 자바 2 SE 1.4.x 혹은 J2SE 1.4.x식으로 명명하다가 1.5 버전에서 J2SE 5.0 식으로 바뀌었다가 1.6 버전부터 자바 SE 6 형태로 명명하게 되었다. 하지만 내부 버전 표기인 1.x.x 형태는 계속 유지되고 있다. 현재 최신 버전 라인은 Java SE 8(1.8.x)와 Java SE JDK(Java Development Kit) 11(11.0.x)이며 Java SE 9부터는 내부 버전도 x.x의 형태로 바뀌었다.

1.4 버전 이전에는 썬 마이크로시스템즈에서 임의로 API를 설계하고 구현해서 공개했으나 J2SE 1.4 이후는 JCP 주도 하에 JSR(Java Specification Request, 자바 명세 작성 요청)을 만들어 포함될 API를 결정하고 각 API는 별도의 JSR를 통해 규격이 제정되고 있다. J2SE 1.4는 JSR 59 하에, J2SE 5.0(프로젝트명 타이거)는 JSR 176, Java SE 6 (프로젝트명 무스탕)은 JSR 170 하에 개발되었다.

Jakarta EE

[편집]

자카르타 EE(Jakarta EE, 이전 명칭: 자바 플랫폼, 엔터프라이즈 에디션(Java Platform, Enterprise Edition; Java EE)은 자바를 이용한 서버측 개발을 위한 플랫폼이다. 자카르타 EE 플랫폼은 PC에서 동작하는 표준 플랫폼인 Java SE를 확장하여, 웹 애플리케이션 서버에서 동작하는 장애복구 및 분산 멀티티어를 제공하는 자바 소프트웨어의 기능을 추가한 서버를 위한 플랫폼이다. 이전에는 J2EE라 불리었으나 버전 5.0 이후로 Java EE로 개칭되었으며 2017년 프로젝트가 이클립스 재단으로 이관됨에 따라 자카르타EE로 변경되었다.

자바 가상 머신

[편집]

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

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

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

자바 개발 키트

[편집]
자바 개발 키트
Java Development Kit (JDK)
개발자오라클
안정화 버전
24.0.2 / 2025년 7월 15일(9개월 전)(2025-07-15)[17]
운영 체제크로스 플랫폼
종류소프트웨어 개발 키트
라이선스Oracle No-Fee Terms and Conditions (NFTC)[18] with third party components[19]
웹사이트oracle.com/java/technologies/

자바 개발 키트(Java Development Kit, JDK)는 자바 SE, 자바 EE, 또는 자바 ME 플랫폼 중 하나를 구현한 것으로[20] 솔라리스, 리눅스, 맥 OS X, 또는 윈도우 자바 개발자를 대상으로 오라클에 의해 바이너리 제품으로 제공된다. 자바 플랫폼의 등장 이래 지금까지 가장 널리 사용되는 소프트웨어 개발 키트(SDK)다. 2006년 11월 17일 GNU 일반 공중 사용 허가서 (GPL)하에 출시될 것이라고 발표했고, 이에 따라 자유 소프트웨어가 되었다. 이는 썬이 2007년 5월 8일 소스 코드를 오픈 JDK에 기부함에 따라 이루어졌다.[21]

오라클 자바 테크놀로지가 제공하는 자바 개발 키트(Java™ Platform, Standard Edition Development Kit (JDK™))는 자바 어플리케이션을 위한 자바 언어 스펙(JLS), 자바 가상 머신 스펙 (JVMS)을 구현하고 있으며, 자바의 표준 에디션(SE)을 제공한다. 또한 컴파일러, 디버깅, 테스팅, 모니터링, 문서화작업, 자바 라이브러리 등 자바 플랫폼에서 운영되는 소프트웨어 개발에 필요한 모든 것들을 포함하고 있다.

오라클이 현재 배포하는 자바 개발 키트는 최신버젼으로 JDK 20, 장기지원버젼으로 JDK 17 (2024년 9월까지 업데이트보장됨)가 있으며, 무료 사용 및 재배포가 가능한 No-Fee Terms and Conditions (NFTC)[3 https://www.oracle.com/downloads/licenses/no-fee-license.html] 라이선스로 윈도즈와 리눅스 환경으로 x64 바이너리 아키텍쳐를, 맥 OS와 리눅스를 대상으로 aarch64 바이너리 아키텍쳐를 제공한다.

자바 런타임 환경

[편집]

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

클래스 라이브러리

[편집]

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

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

언어

[편집]

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

제3자들은 JVM을 대상으로 하는 많은 컴파일러인터프리터를 제작했다. 이들 중 일부는 기존 언어를 위한 것이고, 다른 것들은 자바 언어의 확장을 위한 것이다. 여기에는 다음이 포함된다:

  • BeanShell – 자바를 위한 경량 스크립팅 언어[32] (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이 사용하는 메모리 영역이다.[33]

핫스팟에서 힙은 세대로 나뉜다.

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

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

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

보안

[편집]

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

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

자바 버전

[편집]
자바
버전
연도 변경 사항
252025장기 지원(LTS) 릴리스
212023장기 지원(LTS) 릴리스
172021LTS 릴리스, 여러 향상 기능 포함, switch 문에 대한 패턴 매칭 및 봉인 클래스(sealed classes) 제공
162021데이터 모델링 능력 향상을 위해 레코드 클래스, 패턴 매칭, 봉인 클래스 도입
152020문자열 및 클래스 처리를 향상시키는 텍스트 블록, 봉인 클래스를 미리 보기 기능으로 도입
142020레코드 클래스와 instanceof에 대한 패턴 매칭을 미리 보기 기능으로 도입
132019향상된 기능, 텍스트 블록, 레거시 Socket API의 재구현 포함
122019switch 표현식, 새로운 Shenandoah 쓰레기 수집기 도입
112018LTS 릴리스, 새로운 HTTP 클라이언트 도입, 자바 EE 및 CORBA 모듈 제거
102018지역 변수 자료형 추론(var) 도입, 유형을 지정하지 않고 지역 변수 선언 가능
92017애플리케이션 모듈화를 위한 자바 플랫폼 모듈 시스템(JPMS) 도입, 대화형 자바 REPL인 JShell 도입
82014주요 릴리스, 람다 표현식 도입, 생산성 향상을 위한 새로운 날짜 및 시간 API 도입
72011try-with-resources, 문자열 switch, 다이아몬드 연산자 도입, 확장된 예외 처리 및 새로운 파일 I/O 라이브러리(NIO.2) 포함
62006스크립팅 언어 지원(JSR 223), 웹 서비스 개선 도입, SQL XML을 지원하는 JDBC 4.0 제공
52004중요한 릴리스, 제네릭, 향상된 for 루프, 오토박싱/언박싱, 정적 임포트, 가변 인자, 열거형, 애너테이션 포함
42002정규 표현식, 예외 체이닝, NIO(New Input/Output)라는 새로운 I/O API 세트, 새로운 로깅 API 도입
32000핫스팟이라는 이름의 새로운 썬 JVM 포함, JNDI 및 자바 플랫폼 디버거 아키텍처(JPDA) 도입
21998컬렉션 프레임워크, 상수를 위한 자바 문자열 메모리 맵, JIT 컴파일러, GUI를 위한 스윙 API 도입
1.11997내부 클래스, 리플렉션, 자바 빈즈, 데이터베이스 액세스를 위한 JDBC API 도입
1.01996자바 프로그래밍 언어의 첫 번째 버전, 자바에 객체 지향 프로그래밍과 바이트코드를 도입하여 자바를 플랫폼 독립적으로 만듦

역사

[편집]
Image
제임스 고슬링

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

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

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

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

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

자바와 웹의 만남

[편집]
Image
존 게이지

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

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

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

GNU 일반 공중 사용 허가서

[편집]

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

버전 역사

[편집]

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

썬은 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에서 제거될 예정이다[49]), 썬의 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에 따라 자바 커뮤니티 프로세스에서 개발된 자바 플랫폼의 첫 번째 릴리스가 되었다.[50] 주요 변경 사항으로는 을 모델로 한 정규 표현식, 예외 체이닝, 통합 XML 파서 및 XSLT 프로세서(JAXP), 자바 웹 스타트가 포함되었다.

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

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

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

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

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

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

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

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

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

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

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) 관련 항목들이 그러하다.[67]

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

사용

[편집]

데스크톱 사용

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

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

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

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

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

마스코트

[편집]
Image
자바의 마스코트 듀크

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

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

라이선스

[편집]

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

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

자유 소프트웨어

[편집]
Image
조너선 슈워츠

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

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

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

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

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

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

비판

[편집]

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

제네릭

[편집]

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

부호 없는 정수형

[편집]

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

부동소수점 산술

[편집]

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

성능

[편집]

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

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

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

보안

[편집]

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

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

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

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

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

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

애드웨어

[편집]

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

업데이트 시스템

[편집]

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

같이 보기

[편집]

각주

[편집]
  1. JavaSoft ships Java 1.0 (보도 자료). 2008년 2월 5일에 원본 문서에서 보존된 문서. 2016년 2월 9일에 확인함.
  2. Ortiz, C. Enrique; Giguère, Éric (2001). Mobile Information Device Profile for Java 2 Micro Edition: Developer's Guide (PDF). John Wiley & Sons. ISBN 978-0471034650. 2012년 5월 30일에 확인함.
  3. HotSpot Group. Openjdk.java.net. 2016년 2월 9일에 확인함.
  4. 1 2 Oracle JDK 8 and JRE 8 Certified System Configurations Contents. Oracle.com. 2014년 4월 8일. 2016년 2월 9일에 확인함.
  5. Java SE 7 Supported Locales. Oracle.com. 2016년 2월 9일에 확인함.
  6. OpenJDK: GPLv2 + Classpath Exception. Openjdk.java.net. 1989년 4월 1일. 2016년 2월 9일에 확인함.
  7. BCL For Java SE. Oracle.com. 2013년 4월 2일. 2016년 2월 9일에 확인함.
  8. Naughton, Patrick. Java Was Strongly Influenced by Objective-C. Virtual School. 2012년 8월 13일에 원본 문서에서 보존된 문서.
  9. Alexander, Christopher. Java SE 6 Advanced. www.oracle.com. 2018년 5월 20일에 확인함.
  10. Why should I uninstall older versions of Java from my system?. www.java.com. February 12, 2018에 원본 문서에서 보존된 문서. February 6, 2018에 확인함.
  11. Why should I uninstall older versions of Java from my system?. Oracle. 2016년 9월 9일에 확인함.
  12. 1 2 Oracle Critical Patch Update - July 2016. www.oracle.com.
  13. 1 2 Whittaker, Zack (2013년 1월 11일). Homeland Security warns to disable Java amid zero-day flaw. ZDNet. 2016년 2월 9일에 확인함.
  14. 1 2 3 Lewis, J. P.; Neumann, Ulrich. Performance of Java versus C++. Graphics and Immersive Technology Lab, 서던캘리포니아 대학교.
  15. 1 2 The Java Faster than C++ Benchmark. Kano.net. 2003년 11월 14일. 2016년 2월 9일에 확인함.
  16. 1 2 FreeTTS – A Performance Case Study 보관됨 2009-03-25 - 웨이백 머신, Willie Walker, Paul Lamere, Philip Kwok
  17. Consolidated JDK 24 Release Notes. Oracle Corporation. 7 sep 2025에 확인함.
  18. Oracle No-Fee Terms and Conditions License. Oracle Corporation. 2021년 10월 23일에 확인함.
  19. Licensing Information User Manual (PDF). Oracle Corporation. 2021년 10월 23일에 확인함.
  20. Java SE 7 Features and Enhancements. Oracle Corporation. 2013년 1월 1일에 확인함.
  21. Sun's May 8th announcement of source code for JDK. 2012년 9월 12일에 원본 문서에서 보존된 문서. 2019년 12월 13일에 확인함.
  22. BCL for Java SE. 2022년 8월 14일에 원본 문서에서 보존된 문서. 2022년 8월 14일에 확인함.
  23. Java CPU and PSU Releases Explained. 2014년 11월 3일에 원본 문서에서 보존된 문서.
  24. Archived copy. 2022년 8월 14일에 원본 문서에서 보존된 문서. 2022년 8월 14일에 확인함.
  25. Archived copy. 2022년 8월 10일에 원본 문서에서 보존된 문서. 2022년 8월 14일에 확인함.
  26. Understanding Java 9 Modules. 2022년 8월 14일에 원본 문서에서 보존된 문서. 2022년 8월 14일에 확인함.
  27. Java Modules.
  28. Java 9 Structural Changes in the JDK and JRE. 2017년 10월 30일. 2024년 4월 20일에 원본 문서에서 보존된 문서. 2025년 12월 25일에 확인함.
  29. IBM Developer.
  30. A Guide to Java 9 Modularity | Baeldung. 2018년 4월 18일.
  31. Chapter 1. Introduction. docs.oracle.com.
  32. www.beanshell.org
  33. Frequently Asked Questions about Garbage Collection in the Hotspot Java Virtual Machine. 썬 마이크로시스템즈. 2003년 2월 6일. 2009년 2월 7일에 확인함.
  34. 1 2 Masamitsu, Jon (2006년 11월 28일). Presenting the Permanent Generation. 2016년 8월 25일에 원본 문서에서 보존된 문서. 2009년 2월 7일에 확인함.
  35. Nutter, Charles (2008년 9월 11일). A First Taste of InvokeDynamic. 2009년 2월 7일에 확인함.
  36. JEP 122: Remove the Permanent Generation. 오라클. 2012년 12월 4일. 2014년 3월 23일에 확인함.
  37. What Is Java, Is It Insecure, and Should I Use It?. Lifehacker.com. 2013년 1월 14일. 2015년 6월 26일에 확인함.
  38. Is there any protection against Java exploits? | Kaspersky Lab. Kaspersky.com. 2013년 9월 9일. 2015년 4월 4일에 원본 문서에서 보존된 문서. 2015년 6월 26일에 확인함.
  39. Southwick, Karen (1999). High Noon: the inside story of Scott McNealy and the rise of Sun Microsystems. New York [u.a.]: Wiley. 120–122쪽. ISBN 0471297135.
  40. 1 2 Byous, Jon (April 2003). Java Technology: The Early Years. 썬 마이크로시스템즈. 2008년 5월 30일에 원본 문서에서 보존된 문서. 2009년 8월 2일에 확인함.
  41. Southwick, Karen (1999). High Noon: the inside story of Scott McNealy and the rise of Sun Microsystems. New York [u.a.]: Wiley. 124쪽. ISBN 0471297135.
  42. Walrath, Kathy (2001년 12월 21일). Foreword. 썬 마이크로시스템즈. 2009년 8월 2일에 확인함.
  43. Murphy, Kieron ( 4 October 1996). So why did they decide to call it Java?. JavaWorld. 2020년 7월 15일에 확인함. 'The lawyers had told us that we couldn't use the name "OAK" because [it was already trademarked by] Oak Technologies,' said Frank Yellin, a senior engineer at Sun. 'So a brainstorming session was held to come up with ideas for a new name.'
  44. Bank, David (1995년 12월 1일). The Java Saga. Wired. 2022년 10월 4일에 확인함. 'It's priced below our cost,' Schmidt says. 'This loses money in the licensing business for the foreseeable future. It's a strategic investment in market share.'
  45. Sun Microsystems announces formation of JavaSoft (보도 자료). Sun Microsystems. 9 January 1996. 2008년 2월 10일에 원본 문서에서 보존된 문서.
  46. Sun Opens Java. Sun Microsystems. 2006년 11월 13일. 2008년 5월 13일에 원본 문서에서 보존된 문서.
  47. O'Hair, Kelly (December 2010). OpenJDK7 and OpenJDK6 Binary Plugs Logic Removed. 오라클. 2011년 11월 25일에 확인함.
  48. The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 63. Jcp.org. 2016년 2월 9일에 확인함.
  49. JEP 504: Remove the Applet API. openjdk.org. 2025년 10월 31일에 확인함.
  50. The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 59. Jcp.org. 2016년 2월 9일에 확인함.
  51. Version 1.5.0 or 5.0?. Java.sun.com. 2016년 2월 9일에 확인함.
  52. The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 176. Jcp.org. 2016년 2월 9일에 확인함.
  53. Java Naming. Java.com. Oracle. 2011년 8월 25일에 확인함.
  54. The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 336. Jcp.org. 2016년 2월 9일에 확인함.
  55. Lea, Doug (2004년 9월 13일). JSRs: Java Specification Requests: JSR 166: Concurrency Utilities. Java Community Process. Oracle Corp.
  56. Java™ SE Development Kit 7 Update 76 Release Notes. Oracle.com. 2016년 2월 9일에 확인함.
  57. Java 7 and Java 8 Releases by Date. www.java.com.
  58. Windows XP and Java. Java.com. 2014년 4월 8일. 2016년 2월 9일에 확인함.
  59. java - installing JDK8 on Windows XP - advapi32.dll error. Stack Overflow.
  60. Oracle JDK 8 and JRE 8 Certified System Configurations. www.oracle.com.
  61. Oracle JDK 10 Certified System Configurations. www.oracle.com. 2018년 3월 27일에 확인함. Only X.org Mode supported. Wayland mode is unsupported.
  62. Oracle Java SE Support Roadmap. 오라클. 2018년 9월 25일. 2018년 9월 25일에 확인함.
  63. JDK 11. 오라클. 2018년 9월 25일. 2018년 9월 26일에 확인함.
  64. JDK 12. OpenJDK. 2019년 3월 22일에 확인함.
  65. JDK 13. OpenJDK. 2019년 9월 17일에 확인함.
  66. JDK 14. OpenJDK. 2020년 3월 25일에 확인함.
  67. Deprecated List (Java SE 22). cr.openjdk.org. 2024년 4월 16일에 확인함.
  68. Remove Thread.countStackFrames. bugs.openjdk.org. 2024년 4월 16일에 확인함.
  69. Java SE 22 ( JSR 397). cr.openjdk.org. 2024년 4월 16일에 확인함.
  70. What is Java technology and why do I need it?. 2010년 9월 25일에 원본 문서에서 보존된 문서. 2011년 12월 15일에 확인함. Java runs on more than 850 million personal computers worldwide, and on billions of devices worldwide, including mobile and TV devices.
  71. Java - Fedora Project Wiki. fedoraproject.org.
  72. IntelliJ Platform.
  73. Topic, Dalibor (2016년 1월 27일). Moving to a plugin-free web. Oracle.
  74. Duke, the Java Mascot. 오라클. 2019년 3월 18일에 확인함.
  75. duke: Project Home Page. 썬 마이크로시스템즈. 2007년 6월 18일에 원본 문서에서 보존된 문서. 2007년 3월 18일에 확인함.
  76. Duke, the Java Mascot.
  77. Future Tech Duke (The Java Source). Tori Wieldt. 2011년 8월 20일에 원본 문서에서 보존된 문서. 2011년 8월 17일에 확인함.
  78. Smith, Donald (2018년 9월 11일). Oracle JDK Releases for Java 11 and Later.
  79. Stallman, Richard (2006년 5월 24일). The Curious Incident of Sun in the Night-Time. Groklaw. 2010년 5월 5일에 원본 문서에서 보존된 문서.
  80. Schwartz, Jonathan. ?. Jonathan Schwartz's Blog. Sun Microsystems. 2006년 7월 15일에 원본 문서에서 보존된 문서.
  81. Oracle OpenWorld: UnBreakable Linux / 5015.2 not on the horizon | Formtek Blog. Formtek.com. 2006년 10월 26일. 2016년 2월 9일에 확인함.
  82. Oracle and Sun Microsystems | Strategic Acquisitions | Oracle. Sun.com. 2016년 2월 9일에 확인함.
  83. Free but Shackled – The Java Trap – GNU Project – Free Software Foundation. Gnu.org. 2004년 4월 12일. 2016년 2월 9일에 확인함.
  84. Sun 'releases' Java to the World. BBC News. 2006년 11월 13일. 2010년 5월 6일에 확인함.
  85. Open JDK is here!. Sun Microsystems. 2007년 5월 8일. 2007년 5월 9일에 확인함.
  86. Wielaard, Mark (2007년 5월 30일). OpenJDK6 b10 source posted. 2008년 7월 12일에 확인함.
  87. Redhat Java.
  88. Fedora Java.
  89. Debian Java.
  90. Ubuntu Java.
  91. Sharples, Rich (2008년 6월 19일). Java is finally Free and Open. 2008년 6월 20일에 원본 문서에서 보존된 문서.
  92. libgdx (2013년 12월 9일). Bundling a jre · libgdx/libgdx Wiki · GitHub. Github.com. 2016년 2월 9일에 확인함.
  93. Question about bundling custom OpenJDK. Java-Gaming.org. 2016년 3월 4일에 원본 문서에서 보존된 문서. 2016년 2월 9일에 확인함.
  94. Cluley, Graham (2013년 1월 15일). "Unless it is absolutely necessary to run Java in web browsers, disable it", DHS-sponsored CERT team says – Naked Security. Nakedsecurity.sophos.com. 2023년 5월 21일에 원본 문서에서 보존된 문서. 2016년 2월 9일에 확인함.
  95. Generics in Java. Object Computing, Inc. 2007년 1월 2일에 원본 문서에서 보존된 문서. 2006년 12월 9일에 확인함.
  96. What's Wrong With Java: Type Erasure. 2006년 12월 6일. 2012년 7월 22일에 원본 문서에서 보존된 문서. 2006년 12월 9일에 확인함.
  97. Java and Scala's Type Systems are Unsound (PDF).
  98. Java libraries should provide support for unsigned integer arithmetic. Bug Database, Sun Developer Network. Oracle. 2011년 1월 18일에 확인함.
  99. Owens, Sean R. (2009년 11월 5일). Java and unsigned int, unsigned short, unsigned byte, unsigned long, etc. (Or rather, the lack thereof). darksleep.com. 2010년 10월 9일에 확인함.
  100. Kahan, W.; Darcy, Joseph D. (1998년 3월 1일). How Java's Floating-Point Hurts Everyone Everywhere (PDF). 2006년 12월 9일에 확인함.
  101. Types, Values, and Variables. Sun Microsystems. 2006년 12월 9일에 확인함.
  102. Which programming languages are fastest?. Computer Language Benchmarks Game. 2011년 8월 14일에 원본 문서에서 보존된 문서.
  103. speed ÷ C++ GNU g++ speed. Computer Language Benchmarks Game. 2011년 9월 26일에 원본 문서에서 보존된 문서.
  104. C++ vs Java performance; It's a tie! | Blog of Christian Felde. Blog.cfelde.com. 2010년 6월 27일. 2016년 2월 9일에 확인함.
  105. Java Security Architecture: Contents. Docs.oracle.com. 1998년 10월 2일. 2016년 2월 9일에 확인함.
  106. Horowitz, Michael (2012년 8월 31일). Java security flaw: yada yada yada | Computerworld. Blogs.computerworld.com. 2014년 7월 24일에 원본 문서에서 보존된 문서. 2016년 2월 9일에 확인함.
  107. Brook, Chris. The first stop for security news. Threatpost. 2013년 3월 8일에 원본 문서에서 보존된 문서. 2016년 2월 9일에 확인함.
  108. Why and How to Disable Java on Your Computer Now - Technology & science - Innovation. NBC News. 2013년 1월 12일. 2014년 2월 21일에 원본 문서에서 보존된 문서. 2016년 2월 9일에 확인함.
  109. Brook, Chris. The first stop for security news. Threatpost. 2013년 4월 9일에 원본 문서에서 보존된 문서. 2016년 2월 9일에 확인함.
  110. Critical Patch Updates and Security Alerts. Oracle.com. 2016년 2월 9일에 확인함.
  111. Finkle, Jim (2013년 1월 14일). Emergency patch for Java fails to fix cybercrime holes, warn experts. Independent.ie. 2016년 2월 9일에 확인함.
  112. Kelly, Meghan (2013년 1월 14일). Oracle issues fix for Java exploit after DHS warns of its holes. VentureBeat. 2016년 2월 9일에 확인함.
  113. Krebs, Brian (2016년 2월 16일). Good Riddance to Oracle's Java Plugin. KrebsOnSecurity.
  114. Gonsalves, A. (2012년 9월 5일). Java Is No Longer Needed. Pull The Plug-In. ReadWrite. Wearable World. 2012년 10월 28일에 원본 문서에서 보존된 문서.
  115. Java: should you remove it?. 가디언. 2013년 2월 8일.
  116. Bott, Ed. A close look at how Oracle installs deceptive software with Java updates. ZDNet.com. ZDNet. 2014년 12월 14일에 확인함.
  117. windows 7 - How do I update Java from a non-admin account?. Super User.
  118. Update Google Chrome - Computer - Google Chrome Help. support.google.com.
  119. Adobe Security Bulletin. helpx.adobe.com.

외부 링크

[편집]