C# 개발자로서 Microsoft와 상당히 다른 릴리스 방식이 놀라움. Oracle은 대략 두 배 빠른 주기로 버전을 내놓음. Microsoft는 베타에서 기능을 계속 다듬기는 해도, 정식 릴리스에 같은 기능을 두 차례나 미리보기로 넣는 일은 드문 편임. 아마 Java 사용자층이 훨씬 큰 탓인 듯함.
Microsoft는 플랫폼에 더 많은 기능을 묶어 넣고 커뮤니티에 맡기는 영역은 줄이는 느낌인데, 이것도 커뮤니티 규모 차이에서 비롯되는 듯함. 발표 페이지도 Microsoft의 화려한 홍보보다는 오픈 소스 프로젝트의 “끝냈으니 이제 좀 쉬자”에 가까운 분위기임.

출시 주기가 두 배 빠른 것이 정말 좋은 일일까?
Oracle은 좋든 나쁘든 언어 버전을 특정 런타임의 출시 일정에 묶는 방식을 택했음. 예를 들어 Java 27에는 언어 변경이 전혀 없고, TLS 라이브러리에 작은 기능 하나만 추가됨.
나머지는 모두 언어나 사용 방식에 영향을 주지 않는 OpenJDK 런타임 내부 변경임. 따라서 Oracle의 다른 런타임인 GraalVM처럼 OpenJDK가 아닌 것을 쓴다면 Java 27은 사실상 없는 셈임. 최근 C# 릴리스를 훑어보면 Microsoft는 이런 방식을 쓰지 않는 듯하니, 출시 주기가 다른 건 당연함.

플랫폼에 기능을 더 많이 내장하는 것은 좋은 일임. Java에서는 무엇을 하든 커뮤니티가 만든 여러 대안을 평가하고 골라야 함. 잘못 고르면 나중에 갈아타야 할 수도 있고, 그 과정도 고통스러울 수 있음.
이런 일이 너무 잦아 Java를 쓸 때는 평가와 비교에 대부분의 시간을 쓰게 됨. C#에서는 .NET에 내장된 것을 쓰면 되니 시간을 크게 절약할 수 있음.

Java가 .NET보다 빠르게 움직이는 대안이라고는 생각해 본 적이 없는데, 더 빠른 출시 일정으로 기능을 일찍 제공하고 있음.

발표가 짧고 간결하고, 자세한 내용을 볼 추가 자료도 있음. 나쁘지 않은 방식이라고 봄.

C#은 일부 영역에서 변화 속도를 좀 늦췄으면 함. 지난 1년간의 변경 중 마음에 들지 않는 것이 꽤 있음. 성능 개선과 소소한 기능 추가는 좋지만, 문법적 편의 기능이 늘어나는 건 점점 성가셔짐.

YouTube에 있는 CultRepo의 다큐멘터리 “The Java Story”가 꽤 훌륭함. 여기서도 화제가 된 출시 주기가 주요 주제 중 하나임.

진지하게 묻고 싶음. 2026년 신규 프로젝트에 Java를 선택해야 하는 때는 언제일까?

전혀 나쁜 선택이 아님. 지루할 정도로 안정적이고, 언어를 알고 활용할 수 있는 개발자도 많음. 최고 수준의 개발 도구와 수십 년간 축적된 성숙한 라이브러리도 갖췄음.
Java의 단점 대부분은 오래된 방식으로 작성한 기존 코드베이스에서 나오므로 신규 프로젝트와는 별 관련이 없음.

요즘 Java는 주로 높은 신뢰성·성능과 긴 수명이 필요한 신규 소프트웨어에 쓰임. 은행, 통신, 금융, 정부, 국방, 제조 제어, 물류·해운, 미디어 스트리밍, 소매, 숙박, 의료 등에서 흔히 우선 선택지가 됨.
Python 타입 검사기, JS 번들러, TUI 파일 관리자처럼 좀 더 흥미진진한 소프트웨어에서는 대개 첫 선택이 아님.

상당한 규모의 팀이 오래 운영할 평범한 웹 애플리케이션을 만들 때 적합함. 개발자가 많아 채용이 쉽고, 숨겨진 동작이 거의 없으며, 언어가 엄격하고 타입 안전성을 갖춰 큰 팀에서도 잘 맞음.
요즘은 그 팀에 AI 에이전트 여럿이 들어갈 수도 있음. 내 경험상 Claude Code는 프레임워크와 라이브러리가 풍부하고, 타입이 있으며 다소 지루한 언어에서 아주 잘 작동함. 잘못 작성하면 컴파일부터 실패하기 때문에, Claude가 항상 확인할 수는 없는 모호한 런타임 오류로 이어지지 않음.

프레임워크와 라이브러리 절반을 갈아엎지 않고 10년 뒤에도 작동하고 유지보수 가능한 애플리케이션을 원한다면 Java와 Spring이 좋은 선택임. 요즘 Java 대신 JavaScript·NodeJS처럼 생태계가 불안정한 것을 써야 할 타당한 이유는 별로 보이지 않음.

이미 Java에 익숙하거나 Java를 쓰는 회사에서 일할 때 적합함. 처음부터 시작한다면 더 나은 선택지가 있지만, Java 개발자 50명이 이미 있다면 모두에게 전환을 요구하기는 쉽지 않음.

Project Valhalla가 내년 Java 28에 미리보기로 들어갈 예정임. 살아 있는 동안 널 타입 안전성을 써 볼 수 있기를 바람.

아쉽게도 타입 특화 제네릭과 그에 따른 성능 향상은 빠진 채 들어감. Valhalla는 너무 늦어졌음.

내가 이해하기로는 보편적인 널 타입 안전성은 안타깝게도 Valhalla의 핵심 개념에서 제외됨. 다만 현재 제안들도 특정 조건에서는 부수적으로 널 안전성을 제공함.

정확히는 Valhalla의 첫 단계가 들어가는 것임.

잘못 알고 있는 게 아니라면 OpenJ9 런타임은 일종의 사전 컴파일과 빠른 시작을 지원함.