자바 기술 시스템 소개

• 자바는 프로그래밍 언어뿐 아니라 여걸 가지 소프트웨어와 명세로 구성된 기술 시스템을 통칭
• 자바 기술 시스템은 크로스 플랫폼 소프트웨어를 개발하고 배포하는 데 필요한 모든 것을 제공
• 분산데이터, 분석 플랫폼 등의 용도로 클라우드 시스템에서 구동 중인 자바 가상 머신은 380억 개 이상
  • 개인용 컴퓨터, 셋톱박스, 내비게이션 등을 포함하면 전 세계적으로 600억 개 이상의 자바 가상 머신 동작 중
• 하드웨어 플랫폼이라는 족쇄를 제거하여 '한 번 작성하면 어디서든 실행'라는 이상을 실현
• 상당히 안전한 메모리 관리 시스템을 갖춘 덕에 메모리 누수 문제와 엉뚱한 메모리를 가리키는 문제 대부분을 피할 수 있음
• 런타임에 핫 코드를 감지, 컴파일하고최적화하여 자바 애플리케이션이 최상의 성능을 내도록 도와 줌
• 표준 API 자체가 풍부할 뿐 아니라 수많은 기업과 오픈 소스 커뮤니티에서 제공 하는 다양한 기능의 서드 파티 라이브러리를 활용 할 수 있음 

자바 기술 시스템

• 자바 프로그래미 언어 (코틀린, 클로저, JRuby, 그루비 등)
• 다양한 하드웨어 플랫폼용 자바 가상 머신 구현
• 클래스 파일 포맷
• 자바 클래스 라이브러리 API(표준 API)
• 다른 기업과 오픈 소스 커뮤니티에서 제공하는 서드 파티 클래스 라이브러리 

자바 프로그램 개발에 필요한 최소한의 환경, "JDK" = 자바 프로그래밍 언어 + 자바 가상 머신 + 자바 클래스 라이브러리

JRE = 자바 SE API + 자바 가상 머신 + 배포 기술, JRE는 자바 프로그램을 실행 할 수 있는 표준 환경 제공

https://www.oracle.com/java/technologies/platform-glance.html

Java SE - Technologies | Oracle Technology Network | Oracle

https://developerntraveler.tistory.com/49

[ Java ] JDK, JRE 차이점(JDK란? JRE란?)

비즈니스 관점으로 본 자바 기술 시스템 요소

1. 자바 카드 (Java Card)

• 설명: 자바 카드는 메모리와 리소스가 제한된 스마트카드, 보안 토큰, 임베디드 장치에서 자바 애플리케이션(애플릿)을 실행할 수 있도록 설계된 플랫폼입니다.
• 특징:
  • 작은 메모리 공간에서도 동작하도록 경량화된 자바 가상 머신(Java Card Virtual Machine)을 사용.
  • 보안성이 뛰어나며, 금융 카드(NFC 결제), SIM 카드, 여권 등에서 활용.
  • 국제 표준 ISO 7816을 따르며, 플랫폼 간 코드 이식성과 보안성을 제공합니다.
• 용도:
  • NFC 결제, 개인 식별 카드(PKI), IoT 기기 보안 통신 등.

2. 자바 ME (Java Platform, Micro Edition)

• 설명: 제한된 리소스를 가진 모바일 기기, 임베디드 시스템(PDA, 세트톱박스 등)을 위해 설계된 경량화된 자바 플랫폼입니다.
• 특징:
  • Java SE를 기반으로 하지만 간소화된 API를 제공하며, 메모리와 CPU 사용량이 적음.
  • 네트워크 연결, 데이터 저장소, 사용자 인터페이스(UI) 관련 API 포함.
• 용도:
  • IoT 기기, 피처폰 및 임베디드 디바이스의 애플리케이션 개발.

3. 자바 SE (Java Platform, Standard Edition)

• 설명: 자바의 표준 플랫폼으로 데스크톱 애플리케이션과 서버 애플리케이션 개발을 위한 기본적인 API와 JVM(Java Virtual Machine)을 제공합니다.
• 특징:
  • 객체지향 프로그래밍(OOP), 기본 데이터 타입, 입출력(I/O), 네트워킹, 멀티스레딩 등 핵심 기능 포함.
  • Java EE와 Java ME는 Java SE를 기반으로 확장됨.
• 용도:
  • 데스크톱 애플리케이션 개발, 서버 애플리케이션의 기본 구성 요소.

4. 자바 EE (Java Platform, Enterprise Edition)

• 설명: 대규모 분산 시스템과 웹 애플리케이션 개발을 위한 플랫폼으로 Java SE를 기반으로 추가적인 API와 런타임 환경을 제공합니다.
• 특징:
  • JSP(Java Server Pages), 서블릿(Servlet), EJB(Enterprise Java Beans), JPA(Java Persistence API) 등 다양한 엔터프라이즈 기술 포함.
  • 확장성, 신뢰성, 보안성이 필요한 대규모 네트워크 및 클라이언트/서버 애플리케이션에 적합.
• 용도:
  • 웹 서버 및 애플리케이션 서버 개발(예: Tomcat, WildFly).
  • 기업용 소프트웨어(SaaS) 및 대규모 데이터 처리 시스템.

자바 SE 제외하고는 힘을 잃어가고 있다라고 하는데 사실인지 사실이면 이유가뭐지?

• perplexity AI에게 질문 후 답변

자바 SE를 제외한 다른 자바 플랫폼(Java Card, Java ME, Jakarta EE/Java EE)이 점차 힘을 잃어가고 있다는 주장은 어느 정도 사실로 보입니다. 이는 각 플랫폼이 직면한 기술적, 시장적 변화와 관련이 있습니다. 아래에서 그 이유를 상세히 설명합니다.

1. Java Card

• 현황: Java Card는 스마트카드와 같은 제한된 리소스 환경에서 여전히 사용되고 있지만, IoT 기기와 보안 기술의 발전으로 인해 그 시장이 점차 축소되고 있습니다.
• 이유:
  • 스마트카드의 주요 활용처였던 금융 및 통신 분야에서 새로운 보안 기술(예: 하드웨어 보안 모듈, 블록체인 기반 인증 등)이 등장.
  • IoT 장치에서 더 강력한 프로세서와 메모리를 사용할 수 있게 되면서 Java Card의 필요성이 감소.

2. Java ME

• 현황: Java ME는 과거 피처폰과 같은 제한된 리소스를 가진 디바이스에서 널리 사용되었으나, 스마트폰의 대중화와 Android/iOS 플랫폼의 부상으로 인해 거의 사장되었습니다.
• 이유:
  • Android는 Java SE를 기반으로 한 Dalvik/ART 런타임을 사용하며, Java ME보다 훨씬 강력한 기능을 제공합니다.
  • 모바일 애플리케이션 개발은 현재 Android와 iOS가 주도하고 있으며, Java ME는 더 이상 경쟁력이 없습니다.

3. Jakarta EE (Java EE)

• 현황: Jakarta EE는 대규모 엔터프라이즈 애플리케이션 개발에 여전히 사용되지만, Spring Boot와 같은 경량화된 프레임워크에 밀려 점유율이 감소하고 있습니다.
• 이유:
  • 복잡성과 무거움: Jakarta EE는 전통적으로 대규모 애플리케이션 서버(WebLogic, WebSphere 등)를 기반으로 동작하여 설정과 유지보수가 복잡합니다24.
  • 경쟁 프레임워크의 부상: Spring Boot, Quarkus, Micronaut와 같은 경량화된 프레임워크가 클라우드 네이티브 환경과 마이크로서비스 아키텍처에 더 적합하다는 평가를 받고 있습니다228.
  • 느린 업데이트 주기: Jakarta EE는 과거 Java EE 시절부터 업데이트 주기가 느렸고, 이는 개발자 커뮤니티의 관심을 잃게 만든 주요 요인 중 하나입니다24.
  • 클라우드 네이티브로의 전환: 현대 애플리케이션은 컨테이너(Kubernetes) 및 서버리스 환경에서 동작하는 경향이 강하며, 이는 Jakarta EE의 기존 구조와 잘 맞지 않습니다7.

Java SE가 여전히 강력한 이유

• 자바 SE는 데스크톱 애플리케이션뿐만 아니라 서버 측 애플리케이션의 기본 구성 요소로 사용됩니다.
• 지속적인 업데이트(6개월 주기)와 새로운 기능 도입으로 현대적인 요구사항을 충족하고 있습니다3.
• 클라우드 네이티브 개발과 마이크로서비스 아키텍처에서도 여전히 중요한 역할을 하고 있습니다36.

SE를 제외한 다른 자바 플랫폼들이 힘을 잃어가는 것은 기술 환경과 시장 요구의 변화 때문입니다. 특히 Java ME와 Java Card는 시대적 요구에 뒤처졌고, Jakarta EE는 복잡성과 경쟁 프레임워크의 부상으로 인해 점유율이 감소하고 있습니다. 반면 자바 SE는 지속적인 발전과 다양한 응용 가능성 덕분에 여전히 강력한 위치를 유지

 

https://betterprojectsfaster.com/guide/java-tech-popularity-index-2023-q4/be/

Java Tech Popularity Index Q4/2023: Back-End Frameworks | Better Projects Faster

• 챗gpt 답변

네, 자바 플랫폼 중 Java Card, Java ME, 그리고 일부 엔터프라이즈 솔루션인 **Jakarta EE(Java EE)**는 예전에 비해 영향력이 약해지고 있는 것이 사실입니다. 각각의 사례에서 감소하는 원인들을 살펴보면 다음과 같습니다.

---

1. Java Card (자바 카드)

• 설명: 스마트카드, SIM 카드와 같은 제한된 환경에서 실행되는 자바 플랫폼
• 쇠퇴 원인:
  • IoT 기기와 보안 인증 방식의 발전으로 더 유연한 보안 솔루션(예: TPM, HSM)이 주목받음
  • 칩 제조업체들이 자사 전용 솔루션으로 전환
  • 새로운 보안 표준(예: 생체 인식 기술)의 등장

---

2. Java ME (Micro Edition)

• 설명: 임베디드 기기와 저성능 기기(피처폰 등)용 자바 플랫폼
• 쇠퇴 원인:
  • 스마트폰의 대중화로 피처폰 시장이 급격히 축소됨
  • Android와 iOS가 표준이 되며 Java ME의 필요성 감소
  • 보다 현대적이고 성능이 좋은 임베디드 개발 환경(예: Python, C++) 선호

---

3. Jakarta EE (이전 Java EE)

• 설명: 대규모 엔터프라이즈 애플리케이션을 위한 자바 플랫폼
• 쇠퇴 원인:
  • 마이크로서비스 아키텍처의 확산으로 경량 프레임워크(Spring Boot 등)가 선호됨
  • 클라우드 네이티브 개발 방식의 성장
  • Jakarta EE는 여전히 일부 금융 시스템이나 대형 레거시 시스템에서 사용되지만, 새로운 프로젝트에서는 Spring 생태계가 주도

---

결론

자바 SE는 여전히 데스크톱, 서버, 클라우드 및 모바일 애플리케이션에서 중심적인 역할을 하고 있지만, 위의 플랫폼들은 시대적 요구에 맞지 않는 점 때문에 점차 축소되고 있습니다.

---

자바의 과거와 현재

https://unstop.com/blog/history-of-java

History Of Java | Detailed Timeline (Infographic) & Versions // Unstop

자바의 탄생

• 1991년 4월
  • 제임스 고슬링 박사는 그린 프로젝트를 이끌고 있었다. 셋톱박스, 냉장고, 라디오 같은 다양한 가전제품에서 구동되는 프로그램을 개발하는 것이 목표. 이 프로젝트는 오크를 사용함. 당시 목표한 시장에서는 성공하지 못함
  • 1995년 인터넷이 급부상하면서 오크에 어울리는 토양 탄생
  • 오크에서 자바 언어로 진화
• 1995년 5월 
  • 오크 언어는 이름을 자바로 변경
  • 썬월드 콘퍼런스에서 자바 1.0 정식 데뷔
  • 자바 구호 : 한 번 작성하면 어디서든 실행된다 제시
• 1996년 1월 23일 
  • jdk 1.0 출시
  • 자바 언어는 첫 번째 정식 런타임 환경 
  • JDK 1.0의 자바 가상 머신은 순수한 인터프리트 방식
  • 1.0 버전의 대표 기술 : 자바 가상 머신, 애플릿, AWT 등
• 1996년 4월
  • 10개 주요 운영 체제와 컴퓨터 업에가 자사 제품에 자바 기술을 탑재 발표
  • 웹 페이지 8만 3000개가 자바 기술로 제작
• 1996년 5월
  • 썬이 샌프란시스코에서 처음으로 개최한 자바원 콘퍼런스는 그 후 자바 개발자가 참여하는 행사로 거듭남

유년기

• 1997년 2월
  • JDK 1.1 출시
  • JDBC 등 자바의 가장 기본이 되는 기술 상당수가 이때 출시
  • JDK 1.1 대표 기술은 JAR 파일 포맷, JDBC, 자바빈스, RMI 등
  • 자바 언어 문법도 개선
  • 내부 클래스와 리플렉션 등장
  • JDK 1.1은 1999년 1.1.8까지 아홉 가지 버전 발표
    • 1.1.4 스파클러
    • 1.1.5 펌프킨
    • 1.1.6 아비가일
    • 1.1.7 브루투스
    • 1.1.8 첼시 
• 1998년 12월
  • JDK 1.2 발표, 플레이그라운드 코드명
  • 자바 기술 시스템을 세 개로 나눔
    • 데스크톱 애플리케이션 개발 중심 J2SE
    • 기업용 시스템 위한 J2EE
    • 모바일 단말을 위한 J2ME
  • EJB, 자바 플러그인, 자바 IDL, 스윙 등
  • JIT 컴파일러 탑재 
  • 클래식 VM, 핫스팟 VM, 이그잭트 VM 이라는 세 가지 가상 머신 공존
  • 컬렉션 API 처음 등장
• 1999년 3월과 7월
  • JDK 1.2.1과 JDK 11.2.2 출시
• 2000년 5월
  • 코드명 케스트럴의 JDK 1.3 출시
  • 수학 연산, 새로운 타이머 API 등 자바 클래스 라이브러리 주로 개선
  • JNDI 서비스가 플랫폼 수준 서비스로 제공
  • CORBA, IIOP를 이용해 RMI 커뮤니케이션 프로토콜을 구현
    • **RMI (Remote Method Invocation)**는 자바에서 제공하는 기술로, 네트워크 상에서 서로 다른 Java Virtual Machine(JVM)에 존재하는 객체 간의 메서드 호출을 가능하게 합니다. 이는 분산 컴퓨팅 환경에서 자바 객체를 사용하여 원격 프로시저 호출(RPC)을 수행할 수 있도록 설계되었습니다.
  • 자바 2D 기술 개선
  • JavaSound 클래스 라이브러리 추가
• 2001년 5월
  • 레이디버드 1.3.1 출시
• 2002년 2월
  • 코드명 머린 JDK 1.4 출시
  • 컴팩, 후지쯔, SAS, 심비안, IBM 같은 유명 횟하가 기능 정의에 참여하고, JDK 1.4를 구현하기에 이름
  • 정규 표현식, 예외 연쇄, NIO, 로그 클래스, XML 파서, XSLT 변환기 등 다수의 신기술 선보임
• 2002년 9월, 2003년 6월
  • 1.4.1, 1.4.2 출시
  • 2002년 닷넷 프레임워크 등장
• 2004년 9월
  • 코드명 타이거 JDK 5 출시
  • JDK 1.x 방식 이름 버리고 JDK x 형태 사용
  • 코딩 편의성을 개선
  • 오토박싱, 제네릭스, 동적 애너테이션, 열거형, 가변 길이 매개 변수, foreach 순환문 등 문법 변화
  • 자바 메모리 모델, java.util.concurrent 패키지가 도입
  • JDK 5는 윈도우 9x 운영 체제를 공식 지원하는 마지막 JDK

오픈 소스의 세계로

• 2006년 12월
  • JDK 6 출시, 코드명 무스탕
  • 스크립트 언어 지원, 컴파일타임 애너테이션 처리기, 마이크로 HTTP 서버 API 제공 등
  • 락과 동기화 구현, 가비지 컬렉션, 클래스 로딩 등 개선
• 2006년 11월
  • 자바를 오픈 소스로 전환 계획 발표
  • JDK의 여러 요소를 GPL V2로 공개 시작
  • OpenJDK 조직 설립
• JDK6 이후
  • 복잡도 증가, 자바의 오픈 소스화, 자바FX 개발, 세계 경제 위기, 오라클에 썬 매각 등 자바 연구 소홀히 됨
  • 211 패치가 이루어 지고 2018년 10월이 211이 출시된 날

오라클의 품으로

• 2009년 2월
  • 코드명 돌핀인 JDK 7 출시
  • 람다 프로젝트
  • 직소 르포젝트
  • 동적 언어 지원
  • G1 컬렉터
  • 코인 프로젝트 
• 2009년 4월
  • 오라클 썬을 인수

모던 자바의 시작

• 2014년 3월
  • JDK8 출시
  • 람다식 지원
  • 나스혼 자바스크립트 엔진 내장
  • 새로운 시간 및 날짜 API
  • 핫스팟에서 영구 세대 완전 제거 
  • 직소 JDK9으로 연기
    • 모듈화 프로젝트는 모듈 지옥 딜레마에 빠지기 쉬움 
• 2017년 9월
  • JDK 9 출시
  • JShell, JLink, JHSDB 도구 개선, 핫스팟을 구성하는 모듈들의 로깅 시스템 수정, HTTP2 단일 TCP 연결 API 등 총 9개의 JEP를 포함해 출시

기민하게

2018년 JDK 10 출시 이후부터 현재까지의 자바(JDK) 역사와 주요 변화를 요약하면 다음과 같습니다. 이 시기는 새로운 6개월 출시 주기 도입과 함께 자바 플랫폼이 지속적으로 발전해온 시기로, 각 버전마다 새로운 기능과 개선 사항이 추가되었습니다.

1. JDK 10 (2018년 3월 20일 출시)

• 주요 변화:
  • 로컬 변수 타입 추론(var): var 키워드를 도입하여 지역 변수 선언 시 타입을 컴파일러가 추론하도록 지원.
  • G1 가비지 컬렉터 개선: G1 GC의 전체 GC를 병렬화하여 성능 개선.
  • 애플리케이션 클래스 데이터 공유(CDS): 클래스 데이터를 공유하여 JVM 시작 시간을 단축하고 메모리 사용량 감소.
  • 시간 기반 릴리스 버전 관리: 새로운 6개월 주기 릴리스 모델 도입.
• 기타 개선: Unicode 언어 태그 확장, Thread-Local Handshakes, Graal JIT 컴파일러 실험적 지원 등135.

2. JDK 11 (2018년 9월 25일 출시, LTS)

• 주요 변화:
  • HTTP Client API 표준화: 현대적인 HTTP/2 통신 지원.
  • Epsilon GC: "No-Op" 가비지 컬렉터로 메모리 관리 없이 성능 테스트 가능.
  • Java EE 및 CORBA 모듈 제거: 더 이상 사용되지 않는 기술 제거.
  • 단일 파일 실행 지원: 단일 소스 파일을 컴파일 없이 실행 가능.
• LTS(Long-Term Support): 장기 지원(LTS) 버전으로 안정성과 장기적인 유지보수가 보장됨56.

3. JDK 12~15 (2019~2020년)

• 새로운 기능들이 점진적으로 추가되었으며, 대부분은 실험적(preview) 기능으로 제공됨:
  • JDK 12:
    • Switch Expressions (Preview): switch 문법을 간결하게 개선.
    • Shenandoah GC: 낮은 지연 시간의 가비지 컬렉터 추가.
  • JDK 13:
    • Text Blocks (Preview): 멀티라인 문자열 리터럴 지원.
    • 소켓 API 재구현으로 성능 및 유지보수성 향상.
  • JDK 14:
    • Records (Preview): 데이터 클래스 정의를 간결하게 작성할 수 있는 문법 도입.
    • NullPointerException 디버깅 메시지 개선.

4. JDK 17 (2021년 9월 출시, LTS)

• 주요 변화:
  • Pattern Matching for switch (Preview): switch 문에서 패턴 매칭 사용 가능.
  • Sealed Classes: 상속 구조를 제한할 수 있는 클래스 도입.
  • ZGC(Z Garbage Collector): 낮은 지연 시간 GC가 정식 기능으로 채택.
• LTS 버전으로 안정성과 장기적인 유지보수 제공.

5. JDK 18~20 (2022~2023년)

• 비-LTS 릴리스로 실험적 기능 및 성능 최적화에 초점:
  • Vector API, Foreign Function & Memory API 등 고성능 컴퓨팅 지원 강화.
  • Virtual Threads(가상 스레드): 동시성 프로그래밍 모델 개선.

6. JDK 21 (2023년 9월 출시, LTS)

• 가장 최신의 LTS 버전으로 다양한 기능이 정식 채택됨:
  • Virtual Threads 정식 채택: 경량 스레드로 대규모 동시성 처리 가능.
  • Pattern Matching for switch, Record Patterns 등 언어 기능 강화.
  • 새로운 GC 최적화 및 메모리 관리 개선.

7. JDK의 발전 방향

• 자바는 새로운 기능을 빠르게 제공하기 위해 6개월 릴리스 주기를 유지하며, LTS 버전(현재는 JDK 11, JDK 17, JDK 21)을 통해 안정성과 장기 지원을 제공합니다.
• 클라우드 네이티브 환경과 고성능 컴퓨팅을 위한 가비지 컬렉션(GC), 가상 스레드 등 현대적인 요구사항에 맞춘 지속적인 발전이 이루어지고 있습니다.

결론

JDK는 JDK 10 이후부터 빠른 릴리스 주기를 통해 자바 언어와 JVM의 기능을 지속적으로 확장해왔습니다. 특히 LTS 버전(JDK 11, JDK 17, JDK 21)은 안정성과 장기적인 유지보수를 제공하며, 비-LTS 릴리스는 실험적이고 혁신적인 기능을 도입하는 역할을 하고 있습니다. 이는 자바가 현대 개발 환경에서도 경쟁력을 유지하도록 돕고 있습니다.

 

https://brunch.co.kr/@wegra/36

[탄생 비화] JVM 밑바닥까지 파헤치기

---

자바 가상 머신(JVM)의 역사는 자바의 발전과 함께 시작되었으며, 플랫폼 독립성과 성능 최적화를 중심으로 진화해왔습니다. 아래는 JVM의 역사와 주요 발전 사항을 요약한 내용입니다.

1. 초기 개념과 탄생 (1990년대 초반)

• 배경:
  • Sun Microsystems의 "Green Project"에서 시작된 자바는 "Write Once, Run Anywhere(WORA)"라는 철학을 기반으로 설계되었습니다.
  • 이 철학을 실현하기 위해 JVM(Java Virtual Machine)이 개발되었습니다. JVM은 자바 바이트코드를 실행하는 가상 환경으로, 운영 체제나 하드웨어에 독립적으로 작동할 수 있습니다.
• JVM의 초기 역할:
  • 자바 바이트코드를 해석(interpretation)하여 실행.
  • 플랫폼 독립성 제공: 다양한 운영 체제에서 동일한 자바 프로그램 실행 가능.
  • 자동 메모리 관리(가비지 컬렉션) 도입.

2. JVM의 발전과 표준화 (1996~2000년대 초반)

• Java 1.0 (1996):
  • JVM이 공식적으로 도입되었으며, 자바 프로그램을 실행하기 위한 기본 런타임 환경으로 자리 잡음.
  • 초기 JVM은 주로 인터프리터 방식으로 작동하여 성능이 제한적이었음.
• Java 1.2 (1998):
  • Java 2 Platform(J2SE) 도입과 함께 JVM이 개선됨.
  • HotSpot 기술 도입:
    • Just-In-Time(JIT) 컴파일러 추가로 바이트코드를 네이티브 코드로 변환하여 실행 속도 향상.
    • 런타임 최적화 기술로 성능 개선.
• 표준화:
  • Java Community Process(JCP)를 통해 JVM의 사양이 표준화되기 시작.
  • JVM은 단순히 자바만 지원하는 것이 아니라, 다른 언어(Scala, Kotlin 등)도 실행할 수 있는 범용 플랫폼으로 발전.

3. 성능 최적화와 새로운 기술 도입 (2000~2010년대 초반)

• Garbage Collection(GC):
  • 다양한 GC 알고리즘 추가: Serial GC, Parallel GC, Concurrent Mark-Sweep(CMS) GC 등.
  • 가비지 컬렉션의 효율성을 높여 메모리 관리 성능 개선.
• 멀티스레딩 및 동시성:
  • 멀티코어 프로세서 지원 강화.
  • Fork/Join Framework(Java 7)를 통해 병렬 프로그래밍 성능 향상.
• Java Virtual Machine Tool Interface(JVM TI):
  • 디버깅 및 모니터링을 위한 인터페이스 제공.

4. 현대 JVM의 발전 (2010년 이후)

Java SE 8 (2014):

• 람다 표현식과 스트림 API 도입으로 함수형 프로그래밍 지원.
• 새로운 GC 알고리즘(G1 Garbage Collector) 추가로 대규모 애플리케이션에 적합한 메모리 관리 제공.

Java SE 9 (2017):

• 모듈 시스템(Project Jigsaw) 도입으로 대규모 애플리케이션 구조 개선.
• JVM 내부 구조 최적화 및 성능 향상.

Java SE 이후 버전:

• JDK 10~21에서 JVM은 지속적으로 개선되었습니다.
  • Z Garbage Collector(ZGC): 낮은 지연 시간의 GC 제공.
  • Shenandoah GC: 빠른 가비지 컬렉션을 통한 응답성 향상.
  • Graal JIT 컴파일러: 고성능 JIT 컴파일러로 대체 가능성 제공.
  • Virtual Threads(가상 스레드): 동시성 프로그래밍 모델 혁신.

5. JVM의 현재와 미래

• 다양한 언어 지원:
  • Kotlin, Scala, Groovy 등 여러 언어가 JVM 위에서 실행 가능하며, 이는 JVM을 단순한 자바 런타임 환경에서 다중 언어 플랫폼으로 확장시켰습니다.
• 클라우드 및 컨테이너 환경:
  • 경량화된 JVM 구현(OpenJ9 등)이 컨테이너 환경에서 사용되며 클라우드 네이티브 애플리케이션에 적합한 성능 제공.
• 미래 전망:
  • 지속적인 GC 최적화와 네이티브 이미지(AOT 컴파일)를 통한 성능 향상.
  • 머신러닝 및 빅데이터와 같은 현대적인 워크로드를 지원하기 위한 개선.

---

1. JIT (Just-In-Time) 컴파일러

JIT 컴파일러는 자바 프로그램이 실행되는 동안(런타임)에 바이트코드(Bytecode)를 기계어(Machine Code)로 변환하는 컴파일러입니다.
자바는 일반적으로 소스 코드를 바이트코드로 먼저 컴파일한 후, 이 바이트코드를 JVM이 해석합니다. 하지만 바이트코드를 해석하는 방식은 속도가 느릴 수 있기 때문에 JIT 컴파일러가 등장했습니다.

JIT 컴파일러의 작동 방식

1. 초기 단계: JVM은 바이트코드를 해석(Interpretation)하며 실행합니다.
2. 최적화: 특정 코드가 자주 실행될 경우 JIT 컴파일러가 기계어로 변환하여 성능을 개선합니다.
3. 결과: 프로그램이 더 빠르게 실행됨

장점:

• 반복적으로 실행되는 코드에 대해 빠른 성능 제공
• JVM 최적화 기법(인라이닝, 루프 언롤링 등)을 활용하여 최적 코드 생성

단점:

• 초기에는 JIT 컴파일 단계가 추가되므로 성능 저하가 있을 수 있음

---

2. JEP (JDK Enhancement Proposal)

**JEP(JDK Enhancement Proposal)**은 자바 개발 키트(JDK)의 새로운 기능이나 개선 사항을 제안하는 공식 문서입니다.
이 문서는 새로운 기능을 도입하기 위해 제안 배경, 설계, 구현 계획 등을 상세히 설명합니다.

JEP의 역할:

• JDK 발전 방향을 결정하는 중요한 프로세스
• 자바 개발 커뮤니티가 참여하여 개선 사항 논의

예시 JEP:

• JEP 378: 텍스트 블록(Text Blocks) 도입
• JEP 425: Virtual Threads 도입
• JEP 409: Sealed Classes

JEP 상태:

• Proposed: 제안 단계
• Candidate: 후보 단계
• Delivered: JDK에 정식 포함

---

JEP (JDK Enhancement Proposal)

JEP는 JDK Enhancement Proposal의 약자로, Java Development Kit(JDK)의 새로운 기능이나 개선 사항을 제안하고 관리하는 공식적인 프로세스입니다. Oracle과 OpenJDK 커뮤니티에서 JDK의 발전을 위해 사용됩니다.

특징

• 목적: JDK의 장기적인 로드맵을 정의하고, 새로운 기능이나 개선 사항을 체계적으로 기록 및 관리.
• 프로세스 단계:
  • Draft: 초기 아이디어를 작성하여 리뷰를 받는 단계.
  • Posted: JEP 아카이브에 등록되어 공개 리뷰 진행.
  • Submitted: 평가 준비가 완료된 상태.
  • Candidate: JDK 로드맵에 포함될 후보로 선정.
  • Funded: 개발 자원이 할당됨.
  • Completed: 구현 및 릴리스 완료.
• 활용 사례:
  • 새로운 언어 기능(예: Switch Expressions, Pattern Matching).
  • JVM 개선(예: 새로운 GC 알고리즘, Virtual Threads).
  • JDK 내부 구조 변경 및 최적화.

장점

• 개발자와 커뮤니티가 JDK의 발전 방향에 대해 투명하게 논의할 수 있음.
• JCP(Java Community Process)보다 가벼운 프로세스로 빠른 피드백과 실행 가능.

JIT (Just-In-Time Compiler)

JIT 컴파일러는 Java Virtual Machine(JVM)의 핵심 구성 요소로, 프로그램 실행 중 바이트코드를 네이티브 머신 코드로 컴파일하여 성능을 최적화합니다.

작동 원리

1. JVM은 처음에는 바이트코드를 해석(interpretation)하여 실행.
2. 특정 메서드가 자주 호출되면 JIT 컴파일러가 활성화되어 해당 메서드를 네이티브 코드로 변환(컴파일).
3. 이후 JVM은 해석 단계를 건너뛰고 네이티브 코드를 직접 실행하여 성능 향상.

특징

• 동적 컴파일(Dynamic Compilation):
  • 런타임 중에 코드가 컴파일되므로, 애플리케이션 실행 시 동작 정보를 기반으로 최적화 가능.
• Hot Spot Detection:
  • 자주 호출되는 "핫스팟(hotspot)" 메서드만 선택적으로 컴파일하여 효율성 극대화.
• 최적화 기법:
  • 함수 인라인(inlining), 루프 최적화(loop unrolling), 동적 재컴파일(dynamic recompilation) 등.

장점

• 플랫폼 독립적인 바이트코드를 네이티브 코드로 변환해 실행 속도를 네이티브 애플리케이션 수준으로 향상.
• 런타임 정보를 활용한 최적화를 통해 성능 극대화.

단점

• 초기 실행 시 컴파일 오버헤드로 인해 "워밍업(warm-up)" 시간이 필요.
• 런타임 중 추가 메모리와 CPU 리소스를 소비.

결론

• JEP는 Java의 미래를 설계하고 발전시키는 로드맵 역할을 하며, 새로운 기능과 개선 사항을 체계적으로 도입하는 데 기여합니다.
• JIT는 JVM에서 런타임 성능을 최적화하는 핵심 기술로, Java 애플리케이션의 실행 속도를 크게 향상시킵니다.

---

**그랄VM(GraalVM)**은 자바 프로그램과 다른 프로그래밍 언어를 더 빠르고 효율적으로 실행할 수 있게 만들어진 슈퍼 똑똑한 컴퓨터 프로그램이라고 생각하면 돼요. 자바를 포함한 여러 언어를 실행할 수 있고, 기존 자바보다 더 빠르게 작동하도록 도와주는 특별한 도구예요.

쉽게 설명하면:

1. "멀티언어 통역사":
   • 우리가 영어, 한국어, 일본어 등 여러 언어를 통역해주는 사람처럼, 그랄VM은 자바, 파이썬, 루비, 그리고 다른 언어들을 동시에 실행할 수 있어요.
   • 그래서 여러 언어로 만들어진 프로그램들이 서로 잘 협력할 수 있게 도와줘요.
2. "빠른 번역기":
   • 컴퓨터는 사람이 작성한 코드를 바로 이해하지 못해요. 그래서 코드를 컴퓨터가 이해할 수 있는 언어로 번역해야 해요.
   • 그랄VM은 이 번역을 정말 빨리 하고, 동시에 프로그램이 더 빠르게 실행되도록 최적화해줘요.
3. "작고 가벼운 실행기":
   • 그랄VM은 프로그램을 실행하기 위해 필요한 부분만 가져와서 작고 빠르게 실행할 수 있어요. 이걸 "네이티브 이미지(Native Image)"라고 불러요.
   • 예를 들어, 큰 가방 대신 필요한 물건만 챙겨서 가볍게 여행하는 것과 비슷해요.

왜 좋은가?

1. 다양한 언어 지원:
   • 자바뿐만 아니라 파이썬, 루비 같은 다른 언어도 실행할 수 있어서 개발자들이 다양한 도구를 자유롭게 사용할 수 있어요.
2. 빠른 속도:
   • 기존 자바보다 더 빠르고 효율적으로 작동해서 프로그램이 빨리 실행돼요.
3. 작은 크기:
   • 프로그램을 작게 만들어서 클라우드나 작은 컴퓨터에서도 쉽게 사용할 수 있어요.

비유로 설명하면:

그랄VM은 마치 초능력을 가진 번역사예요. 여러 나라 말을 동시에 이해하고, 번역도 엄청 빨리 하면서, 필요한 말만 골라서 간단하고 효율적으로 전달해주는 역할을 해요. 그래서 개발자들이 다양한 언어로 만든 프로그램을 한꺼번에 잘 사용할 수 있도록 도와주는 거예요.

결론

그랄VM은 자바를 포함한 여러 프로그래밍 언어를 더 빠르고 효율적으로 실행하게 만들어주는 똑똑한 도구예요. 다양한 언어를 사용할 때나, 프로그램을 작고 빠르게 만들고 싶을 때 아주 유용해요!

https://rieckpil.de/whatis-graalvm/

GraalVM - An Introduction to the Next Level JVM - rieckpil

 

https://ojm1484.tistory.com/50

최신 오픈소스 기술 트렌드(GraalVM)

 

https://www.youtube.com/watch?v=9fbq3umnSeA&t=18s

Native Image?

Native Image는 GraalVM에서 제공하는 기능으로, 자바 애플리케이션을 JVM 없이 실행 가능한 독립 실행 파일로 변환하는 기술

Native Image의 특징

1. JVM 없이 실행 가능:
   • 일반적인 자바 애플리케이션은 JVM(Java Virtual Machine) 위에서 실행되지만, Native Image는 JVM 없이도 실행됩니다.
   • 즉, 자바 바이트코드(.class 파일)를 네이티브 코드(운영 체제에 맞는 실행 파일)로 변환합니다.
2. 빠른 시작 시간:
   • Native Image는 애플리케이션 시작 시 JVM 초기화 과정이 없기 때문에 매우 빠르게 실행됩니다.
   • 이는 서버리스(Serverless) 환경이나 클라우드 네이티브 애플리케이션에서 중요한 장점입니다.
3. 낮은 메모리 사용량:
   • JVM에서 사용하는 런타임 메모리와 GC(가비지 컬렉션) 오버헤드가 없거나 최소화됩니다.
   • 따라서 메모리가 제한된 환경(예: IoT 디바이스, 컨테이너)에서 유용합니다.
4. Ahead-of-Time (AOT) 컴파일:
   • Native Image는 바이트코드를 런타임 중(JIT 컴파일) 변환하지 않고, 빌드 시점에 미리 네이티브 코드로 변환합니다.
   • 이 과정을 "Ahead-of-Time 컴파일"이라고 합니다.

Native Image의 동작 원리

1. 애플리케이션 분석:
   • Native Image 빌드 도구는 애플리케이션의 모든 코드와 의존성을 분석합니다.
   • 사용되지 않는 코드는 제거(dead code elimination)하여 실행 파일 크기를 줄입니다.
2. AOT 컴파일:
   • 자바 바이트코드를 네이티브 코드로 변환하여 특정 운영 체제와 아키텍처에서 실행 가능한 바이너리를 생성합니다.
3. 런타임 포함:
   • 생성된 네이티브 바이너리는 필요한 런타임 요소(예: 가비지 컬렉터, 스레드 관리 등)를 포함하고 있어 JVM 없이도 독립적으로 동작합니다.

Native Image의 장점

1. 빠른 시작 시간:
   • JVM 초기화가 필요 없으므로 애플리케이션 시작 속도가 매우 빠릅니다.
   • 서버리스 환경(AWS Lambda 등)에서 특히 유용합니다.
2. 낮은 메모리 사용량:
   • JVM 런타임 오버헤드가 제거되어 메모리를 효율적으로 사용할 수 있습니다.
   • 컨테이너 기반 환경(Kubernetes 등)에서 리소스 절약 가능.
3. 작은 크기:
   • 사용하지 않는 코드를 제거함으로써 애플리케이션 크기를 최소화할 수 있습니다.
4. 운영 체제 종속성 제거:
   • 운영 체제에 맞는 바이너리를 생성하므로, 특정 플랫폼에서 바로 실행 가능합니다.

Native Image의 단점 및 한계

1. 빌드 시간 증가:
   • AOT 컴파일 과정은 JIT 컴파일보다 시간이 오래 걸립니다.
   • 대규모 애플리케이션에서는 빌드 시간이 더 길어질 수 있습니다.
2. 동적 기능 제한:
   • 리플렉션(reflection), 동적 클래스 로딩, 프록시 생성 등 일부 자바 기능은 제한될 수 있습니다.
   • 이를 해결하려면 추가 설정이나 구성 파일을 제공해야 합니다.
3. 최적화 제한:
   • JIT 컴파일러는 런타임 정보를 기반으로 최적화를 수행하지만, Native Image는 빌드 시점에 최적화가 고정되므로 런타임 최적화가 불가능합니다.
4. 호환성 문제:
   • 모든 자바 라이브러리가 Native Image와 호환되지 않을 수 있습니다.
   • 예를 들어, 일부 라이브러리는 리플렉션이나 동적 로딩을 많이 사용하기 때문에 호환성 문제가 발생할 수 있습니다.

Native Image의 활용 사례

1. 서버리스 환경:
   • 빠른 시작 속도가 필요한 AWS Lambda 같은 서버리스 플랫폼에 적합합니다.
2. 클라우드 네이티브 애플리케이션:
   • 컨테이너 기반 환경(Kubernetes, Docker)에서 리소스를 절약하고 배포 효율성을 높일 수 있습니다.
3. IoT 및 엣지 디바이스:
   • 메모리가 제한된 IoT 디바이스나 엣지 컴퓨팅 환경에서 경량화된 애플리케이션을 실행할 때 유용합니다.
4. 마이크로서비스 아키텍처:
   • 작은 크기와 빠른 시작 속도로 마이크로서비스 개발에 적합합니다.

AOT?

• AOT(Ahead-of-Time) 컴파일은 프로그램 실행 전에 소스 코드나 바이트코드를 **미리 네이티브 코드(기계어)**로 변환하는 컴파일 방식
• 이는 프로그램 실행 중에 코드를 변환하는 JIT(Just-In-Time) 컴파일과 대비되는 개념
• AOT 컴파일은 주로 성능 최적화와 빠른 실행 속도를 위해 사용

AOT 컴파일의 작동 방식

1. 소스 코드 작성:
   • 개발자가 작성한 자바 코드(.java 파일)를 일반적으로 바이트코드(.class 파일)로 컴파일합니다.
   • 자바에서는 이 과정이 javac 컴파일러에 의해 수행됩니다.
2. AOT 컴파일:
   • AOT 컴파일러는 바이트코드를 분석하여 특정 플랫폼(운영 체제 및 하드웨어)에 맞는 네이티브 코드로 변환합니다.
   • 변환된 네이티브 코드는 실행 가능한 바이너리 파일 형태로 저장됩니다.
3. 실행:
   • 생성된 네이티브 바이너리는 JVM 없이도 바로 실행할 수 있습니다.
   • 이 과정에서 런타임 중의 추가적인 컴파일 과정이 필요하지 않습니다.

특징	AOT (C 컴파일러)	JIT (인터프리터 + 동적 컴파일)
컴파일 시점	프로그램 실행 전에 미리 컴파일.	프로그램 실행 중 실시간으로 컴파일.
실행 파일 형태	운영 체제에서 바로 실행 가능한 바이너리 생성.	바이트코드가 JVM에서 해석 및 동적으로 네이티브 코드로 변환.
속도	빠른 시작 속도.	초기에는 느릴 수 있지만, 점진적으로 빠르게 최적화.
플랫폼 독립성	플랫폼 종속적(운영 체제 및 아키텍처에 맞게 생성).	플랫폼 독립적(Write Once, Run Anywhere).
최적화 가능성	빌드 시점에 고정된 최적화만 가능.	런타임 정보를 활용한 동적 최적화 가능.

---

JDK 컴파일

https://github.com/openjdk/jdk

GitHub - openjdk/jdk: JDK main-line development https://openjdk.org/projects/jdk

https://github.com/openjdk/jdk/blob/master/doc/building.md

jdk/doc/building.md at master · openjdk/jdk

• 위에 문서에서 컴파일 방법에대한 문서를 자세히 보고 실해하면 된다
• 보통 우분투에서 하는게 편하다
• JDK를 컴파일하기 위해선 부트 JDK가 필요하고, 부트 JDK는 직전 메이저 버전이나 같은 버전을 사용한다. 

# GCC or Clang 및 build도구 설치
sudo apt-get update

sudo apt-get install -y build-essential \
libfontconfig1-dev \
libfreetype6-dev \
libcups2-dev \
libx11-dev \
libxext-dev \
libxrender-dev \
libxrandr-dev \
libxtst-dev \
libxt-dev \
libasound2-dev \
libffi-dev \
autoconf


# 부트 jdk 설치
sudo apt-get install openjdk-17-jdk

명령어 설명

1. build-essential: C/C++ 컴파일러 및 빌드 도구(예: gcc, g++, make)를 설치합니다.
2. libfontconfig1-dev: 폰트 설정을 위한 라이브러리 개발 패키지.
3. libfreetype6-dev: 폰트 렌더링을 위한 FreeType 라이브러리 개발 패키지.
4. libcups2-dev: CUPS(Common UNIX Printing System) 개발 패키지.
5. libx11-dev, libxext-dev, libxrender-dev, libxrandr-dev, libxtst-dev, libxt-dev:
   • X11 윈도우 시스템 관련 개발 라이브러리들로, GUI 애플리케이션 개발에 필요합니다.
6. libasound2-dev: ALSA(Advanced Linux Sound Architecture) 오디오 라이브러리 개발 패키지.
7. libffi-dev: 외부 함수 호출(Foreign Function Interface)을 지원하는 라이브러리 개발 패키지.
8. autoconf: 소프트웨어 빌드를 위한 구성 스크립트를 생성하는 도구.

컴파일단계

• bash configure 
• make
• make images
• ./java --version