▲

Java 25 / JDK 25 정식 출시

 (openjdk.org)
5P by GN⁺ 1일전 | ★ favorite | 댓글 3개
  • Java 25와 그 참조 구현체 JDK 25가 공식적으로 출시됨
  • 이번 버전은 새로운 18개 JEP(Java Enhancement Proposal) 기능을 포함
  • x86 32비트 포트 제거, Scoped Values, Structured Concurrency, Primitive Types 개선 등 주요 변화가 적용됨

Java 25 / JDK 25: 공식 출시

  • JDK 25, 즉 Java 25의 참조 구현체가 공식적으로 제품용 배포 버전으로 출시됨
  • 2025년 8월 15일에 두 번째 릴리즈 후보인 build 36이 제공되었으며, 그 이후로 심각한(P1) 버그 보고 없음.
  • build 36은 최종 GA(General Availability) 버전으로, 운영 환경에도 사용 가능함
  • GPL 라이선스 기반 OpenJDK 빌드는 Oracle에서 공식적으로 제공되고 있으며, 기타 여러 벤더의 빌드 버전도 곧 배포될 예정임

OpenJDK 공식 다운로드 링크

주요 기능 및 개선 사항

이번 릴리즈에는 18개의 JEP(Java Enhancement Proposal) 가 포함되어 있음

  • 470: PEM 기반 암호화 객체 인코딩(미리보기)
  • 502: Stable Values (미리보기)
  • 503: x86 32비트 포트 제거
  • 505: Structured Concurrency (5번째 미리보기)
  • 506: Scoped Values
  • 507: 패턴, instanceof, switch에서의 Primitive Types 지원(3번째 미리보기)
  • 508: Vector API (10번째 인큐베이터 버전)
  • 509: JFR CPU 시간 프로파일링 (실험적 기능)
  • 510: Key Derivation Function API
  • 511: Module Import 선언
  • 512: Compact Source Files 및 인스턴스 main 메소드
  • 513: Flexible Constructor Bodies
  • 514: Ahead-of-Time 커맨드라인 최적화
  • 515: Ahead-of-Time 메소드 프로파일링
  • 518: JFR 협력 샘플링
  • 519: Compact Object Headers
  • 520: JFR 메소드 타이밍 및 추적
  • 521: Generational Shenandoah

이 릴리즈에는 위의 JEP 외에도, 수백 건의 소규모 기능 개선과 수천 건의 버그 수정이 반영됨

자세한 릴리즈 관련 정보 및 JEP 세부 내용은
OpenJDK JDK 25 프로젝트 페이지에서 확인 가능

▲
ahwjdekf 4시간전  [-]

작년에 왔던 각설이 죽지도않고 또왔네 어얼씨구시구 들어간다 .. 넌 자꾸 왜 나와?

답변달기
▲
click 14시간전  [-]

JDK24에서 들어온 기능이긴 한데 자바는 LTS만 쓰는 경향이 크니 JEP 491: Synchronize Virtual Threads without Pinning 로 synchronized 키워드를 쓸 때
가상 스레드 pinning 현상이 없어졌다는 점도 주목할만 합니다.
가상 스레드 리얼 월드 벤치마크가 더 느린 경우가 종종 있었는데 대부분 pinning이 원인인 경우가 많았습니다.

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • 더 많은 신규 프로그램이 Java나 JVM 위에서 작성되어야 한다고 봄, 과거 Java의 인기 하락 이유들이 이제 거의 없어졌고, 지금은 매우 안정적이고 성숙한 생태계임, 10년 전에 썼던 Clojure 프로그램도 문제 없이 잘 돌아가는데 TypeScript로 작성한 프로그램은 6개월 만에 유지보수와 업데이트가 필요함
    • Oracle이 신경 쓰이는 부분이 큼, Java를 쓰면서 Oracle의 EULA를 위반하지 않도록 신경 써야 하는 게 불편함, openjdk를 사용하면 괜찮을 것 같지만, 차라리 걱정 없이 다른 언어를 쓰고 싶음, C#도 java와 비슷한 환경을 제공하면서 Oracle 걱정 없이 쓸 수 있음, Java를 안전하게 쓰는 방법을 공부하는 것보다 그냥 다른 언어를 선택하는 것이 낫다고 생각함, Java가 반드시 필요한 것도 아니기 때문에 대안이 많음
    • Java는 대규모 백엔드 시스템에서 여전히 엄청나게 인기 있고 널리 사용됨, 이곳에서는 그런 시스템을 다루는 사람이 별로 없는 것 같아서 놀람, 내 경험상 Java는 거의 빠지지 않고 접함
    • Kotlin과 Compose가 JVM에서 데스크톱 앱을 다시 부활시켜주길 은근히 기대하고 있음
    • Java가 채택률 면에서 계속해서 위험한 부분은 관련 문화라고 봄, 오래된 Java 개발자들과 기존 Java 프로그램들이 불필요하게 장황하게 쓰여 있고, 언어 자체는 이미 다른 현대 언어처럼 간결하게 쓸 수 있는 기능이 있음에도 그렇다고 생각함, 그래도 Java는 워낙 큰 존재라서 변화 가능성이 있다고 봄
    • 10년 전에 썼던 Clojure 프로그램이 잘 돌아가는 게 JVM 덕분인지 아니면 Clojure 특유의 방식 때문인지 궁금함, 나도 ClojureScript 프로젝트에서 비슷한 경험이 있음, 예전 nbb 스크립트도 별문제 없이 바로 잘 동작함(가끔 npm 의존성만 조금 손봐주면 됨), 반면에 Python에서는 의존성 문제와 venv 관리로 반나절을 고생하기도 함
  • Java는 오랫동안 놀라울 정도로 견고한 기술적 기반이 되어줌, 가장 매력적인 언어는 아니지만 항상 안정성을 보여줌, Java 1.4로 만든 앱이 Java 21 LTS에서도 잘 동작하고, 곧 Java 25로 업그레이드할 계획임, Java 최고임
    • JetBrains의 뛰어난 툴과 스마트한 학생 프로그램이 없었다면 Java가 지금 어디쯤에 있을지 궁금함
    • 팔 길이만큼은 떨어져 있지만, 2009년에 내 터치 Symbian 폰에서 돌아가던 Java로 만든 Gmail 앱이 아직 기억에 남음, 정말 귀엽고 기능도 잘 썼음
    • 내 경험상 전적으로 동의하지 못함, 여러 회사에서 JVM 버전을 올릴 때마다 항상 큰 문제와 많은 재작업, 재테스트가 필요했음, Java 17~18쯤에서 중단했지만 나와 함께 일하는 사람들은 새로운 버전을 거의 사용하지 않았음, 2022년 한 프로젝트에서 JVM 1.5를 업데이트해야 했는데, 중요한 서드파티 라이브러리들이 Java 1.7 이전 버전까지만 지원해서 어려움이 많았음, 소스 코드를 구해 직접 컴파일해보려 했으나 점점 범위가 커져버렸음, 관리자들과 의견이 맞지 않아 힘들었고 결국 Fortune 10의 최상위 클라이언트를 그만두기로 결정함, 아직도 그 시스템은 업데이트되지 못했다고 들음
    • 예전에 작성한 swing 앱을 다시 써보고 싶었는데 큰 수정 없이 부활시켜볼 수 있을 것 같아서 시도해볼 생각임
    • JVM과 그 생태계는 Scala, Clojure 등 다른 언어와도 함께 쓸 수 있어서 다양하고 매력적인 활용이 가능함
  • 생성자에서 super 호출 전에 파라미터 유효성 검사와 변환이 허용되는 데 이렇게까지 오래 걸렸다는 게 신기함, 예전부터 직관에 반한다고 생각했던 부분임
    • JDK 1.0 이전부터 Java를 써왔는데, 이 부분이 예전부터 거슬렸지만 이제는 적응해서 우회 방법에 익숙해짐
    • static 함수로 validate 과정을 super 파라미터에 활용해왔다면 실제로는 super 이전에 호출이 돼서 컴파일러도 문제 없었음
  • Java 개발자는 아니지만, 모듈 import 시스템이 개인적으로 별로 마음에 들지 않음, import *와 같은 구문은 코드를 작성할 땐 쉽지만 읽기는 훨씬 어려움, 특히 언어나 코드베이스가 낯선 개발자에게 더 그러함, C#과 Nim도 그런 스타일인데 IDE 없이는 거의 못 읽겠음, 그래서 Python처럼 짧은 별칭 예시(import torch.nn.functional as F)가 더 좋다고 생각함
    • 큰 코드베이스에서 import의 주요 문제점은 "저게 어디서 왔지?"임, 명시적 import가 꼭 필요함, 빌드가 깨지거나 의존성 버전이 헷갈릴 때 특히 더 그러함, 작은 코드베이스에서는 뭐든 상관없음, 어차피 요즘 에디터는 import 구문을 가려주니까 직접 볼 일이 거의 없고, 코드를 클릭하거나 단축키로 바로 따라가니까 import는 잘 신경 안 씀
    • C# 경험이 별로 안 좋은 것은 제대로 된 Visual Studio를 쓰지 않아서라고 생각함, VSCode도 좋긴 하지만 csproj나 sln 파일은 절대 VSCode로는 안 열음, 참고로 Visual Studio는 여기서 $500에 퍼페츄얼 라이선스를 구매할 수 있고, 별도의 구독 없이 쓸 수 있음
    • IDE 없이 이해하기 어려운 언어 구성에 불평하는 것을 이해하지 못하겠음, 코드를 IDE에서 보고 있으니 문제 없다고 생각함, IDE를 안 쓰는 사람이 불편을 자초하는 것이고, GitHub에서 코드를 보는 건 보통 참조를 깊게 분석하는 게 아니므로 그 정도 간결성의 불편은 감수할 만함
    • 내가 알기로 이 스타일은 단일 소스 파일 프로그램 작성이 더 쉬워지도록 의도됨
  • 새로운 기능은 OpenJDK 25 공식 페이지에 잘 정리되어 있음, Java 25는 LTS 릴리스임
    • 10년 뒤에 17에서 25로 마이그레이션하는 일을 할 날이 빨리 왔으면 함
  • 개인적인 느낌이지만, Java는 오래된 언어임에도 지난 10년간 꾸준히 발전해온 반면, C++는 오히려 어려워졌다고 느낌
  • 아쉽게도 아직 structured concurrency가 완전히 릴리즈 되지는 않음, 이 기능을 정말 기대 중임, 대신 Scoped Values 추가는 반가움, 이것만으로도 Java에서 "rails-like" 스타일로 코드 구조를 만들 때 god-class나 god-object를 남발하지 않아도 된다고 생각함
    • C++가 현재 구현 없이 표준화된 기능들로 혼란스러운 상황임에 비해 Java는 프리뷰로 점진적으로 가는 현 상황이 훨씬 좋다고 봄
    • structured concurrency가 async/await처럼 너무 설탕투성이가 아니라 실질적인 발전으로 느껴졌으면 좋겠음, 예제들만 봤을 땐 아직 확신이 안 들지만 좀 더 지켜볼 생각임
  • 최근에 JDK8에서 마이그레이션을 결심해서 JDK21로 바로 넘어갔음, 25가 코앞이라서 17 넘기는 대신 21로 정함, 내가 보기엔 8에서 11로 마이그레이션할 때(new module 시스템 등장)가 가장 힘들었고, 그 이후엔 쉽다고 생각함, Proof-of-Concept은 jdk17로 했는데 거의 그대로 jdk21에서도 작동했음(guice만 메이저 버전 업 필요), 참고로 Java 대신 다른 JVM 언어를 사용한 것도 도움이 된 것 같음
    • 우리 팀은 8에서 17로 넘어가는 게 힘들었음, sun 패키지처럼 공식이 아닌 것들도 많이 썼고, javax에서 jakarta로 이동하는 것도 부담이었음, 그 단계를 넘기면 21이나 25로 가는 건 쉽다고 느낌, 앞으로 최신 버전을 꾸준히 따라가는 것이 예전보다 수월해질 것으로 기대함
    • Java 9가 생태계의 Python 3 모먼트였지만, 이제는 문제 없이 정리됐다고 느낌
    • 참고로, 최근에 17에서 21로 마이그레이션했는데 아무런 문제도 없었음, minor 이슈는 Gradle을 함께 올릴 때 약간 있었음(이건 본질적으로 다른 문제임)
  • Java 25의 새로운 기능을 baeldung 포스트에서 잘 정리해둠
  • 법적인 관점에서 현재 Java를 사용하는 상황이 어떠한지 궁금함, 오픈소스와 상업적 용도 모두에서, Oracle은 Truffle 같은 훌륭한 기술을 Java에 묶어두고 있는데 새 프로젝트에 사용하는 것이 얼마나 합리적인지 알고 싶음
    • OpenJDK는 사실상 Oracle에서 바로 가져온 오픈 라이선스임, Oracle이 싫으면 Eclipse Foundation, Microsoft, Amazon 등 다른 곳에서 만든 버전을 써도 됨, Java의 생명력은 오래 가서 8/11처럼 구버전을 여전히 쓰는 이유도 됨, 작성만 하면 정말 오래동안 돌아감, 기능 면에서는 경쟁자에 비해 느리지만 중요한 개발에는 충분함, JVM에 의존한다면 Kotlin을 추천(특히 Java는 아직도 nullable type이 없어서 NullPointerException이 흔함), Kotlin이 싫으면 C#도 좋음, 그래도 Java는 충분히 쓸 만함
    • 현재 기준으로 Oracle 배포판의 경우 최신 LTS만 마음껏 쓸 수 있다고 보면 됨, 그 이하 버전은 OTN 라이선스라 개인/개발 용도만 가능하고, 프로덕션에는 불가함, Oracle 마크가 꼭 필요하지 않다면 OpenJDK나 타사의 JDK는 라이선스 걱정이 없음
    • 오픈JDK는 완전히 오픈소스라서 전혀 걱정할 필요가 없음
    • OpenJDK 같은 걸 쓰면 Oracle 이슈에서 완전히 자유로움
    • 직접 Java 구현체를 만들어 배포할 게 아니라면 법적인 이슈는 거의 고려 대상이 아님
답변달기