* 이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
(자바 버전 여행 ㉓)
여기까지 8에서 21까지 한 계단씩 밟아 왔다. 이번 편은 그 여정을 한 장의 표로 압축한다. 어떤 기능이 어느 버전부터 되는지 헷갈릴 때 다시 펴 보라고 만드는, 시리즈의 지도다.
버전별 대표 기능
| Java 8 (2014) | Java 11 (2018) | Java 17 (2021) | Java 21 (2023) | |
|---|---|---|---|---|
| 함수형 | 람다·스트림·Optional | (계승) | (계승) | (계승) |
| 문자열 | – | strip·repeat·lines | 텍스트 블록 | (계승) |
| 타입 | – | var | record·sealed | record 패턴 |
| 분기 | – | – | switch 표현식·instanceof 패턴 | switch 패턴·when |
| 동시성 | CompletableFuture | – | – | 가상 스레드 |
| 컬렉션 | – | List.of(9) | – | Sequenced |
| HTTP | – | 표준 HttpClient | – | – |
| 기본 GC | Parallel | G1 | G1 | G1(ZGC 성숙) |
무엇이 사라졌나 · 지원은 언제까지
| 버전 | 주의(제거/변화) | 무료 지원(대략) |
|---|---|---|
| 8 | (현역이나 오래됨) | 배포판별 상이, 장기 |
| 11 | Java EE·CORBA 제거 | 2020년대 중반+ |
| 17 | 강한 캡슐화(내부 봉인) | 2020년대 후반+ |
| 21 | (최신) | 2030년대 초반+ |
지원 기간은 배포판마다 다르다. Temurin·Corretto 같은 OpenJDK 배포판은 대체로 LTS를 길게 봐 준다. 정확한 종료 시점은 쓰는 배포판의 공지를 확인하는 게 안전하다.
지원 기간(EOL)은 어디서 확인하나
‘언제까지 안전한가’는 이 표에 연도를 박아두는 것보다 확인처를 아는 게 오래 간다 — 배포판마다, 그리고 시간이 지나며 정책이 갱신되기 때문이다.
- Temurin: adoptium.net의 support/릴리스 로드맵 페이지 — LTS별 지원 종료 시점 표가 정본.
- Corretto(AWS)·Zulu(Azul): 각 벤더의 support roadmap 문서. Corretto는 LTS를 상당히 길게 끌고 가는 편이다.
- Oracle JDK: Oracle Java SE Support Roadmap — 라이선스 조건과 함께 본다.
공통 경향만 기억하자: LTS는 최소 수년 단위로 지원되고, 비-LTS는 다음 릴리스가 나오면 끝(6개월)이다. 그래서 ‘어느 LTS든 지원이 살아 있는 동안 다음 LTS로 계단을 밟는’ 운영이 기본이 된다.
한 줄 요약
- 8 — 함수형의 시작. 여전히 많지만 새 프로젝트 기준은 아니다.
- 11 — 8 이후 첫 정착 LTS. 표준 API를 채웠다.
- 17 — 문법 현대화의 집합. 오늘날의 ‘최소 기준’.
- 21 — 가상 스레드와 패턴 매칭 완성. 최신 선택지.
직접 해보기 — 내 코드는 어느 버전이 필요한가
표를 거꾸로 써먹어 보자. 코드 조각을 보고 최소 버전을 맞히는 연습이다.
- 아래 조각들이 각각 최소 몇 버전이 필요한지 표를 보며 판별한다.
- 실제로
sdk use로 그 버전보다 낮은 자바에서 컴파일해 에러를 확인한다.
// A
var list = List.of(1, 2, 3);
// B
record User(String name) {}
// C
String s = switch (x) { case 1 -> "a"; default -> "b"; };
// D
try (var ex = Executors.newVirtualThreadPerTaskExecutor()) { }실행해 보면 이렇게 나온다.
A: Java 10(var)+9(List.of) → 최소 10
B: record → 최소 16(정식) / 17 LTS
C: switch 표현식 → 최소 14 / 17 LTS
D: 가상 스레드 → 최소 21여기서 조금씩 바꿔 보자.
- 각 조각을
sdk use java 11에서 컴파일해, 어떤 게 통과하고 어떤 게 막히는지 본다. - B의 record를 자바 8 스타일 클래스로 되돌리면 몇 줄이 되는지 세어 본다.
한 걸음 더 — 내 실제 프로젝트에서 가장 높은 버전을 요구하는 문법이 무엇인지 찾아, 그게 곧 이 프로젝트의 ‘최소 자바’임을 확인하자.
✅ 확인 — 네 LTS의 대표 기능을 각각 한둘씩 짚고, 코드를 보고 최소 버전을 가늠할 수 있으면 통과다.
8 → 최신, 옮길 때 주의점
가장 흔한 마이그레이션은 ‘8에서 벗어나기’다. 함정 셋을 기억하자. ① 제거된 모듈(Java EE·CORBA는 11에서 빠짐) → jakarta 등 별도 의존성 추가 ② 강한 캡슐화(17+)로 내부 API(sun.*) 리플렉션 접근이 막힘 ③ 빌드 도구·라이브러리 버전 올리기. 한 번에 21로 건너뛰기보다 11이나 17을 경유하며 테스트하는 게 안전하다.
어떤 버전을 고를까 — 상황별
새 프로젝트라면 최신 LTS인 21이 정석이다 — 가상 스레드·패턴 매칭 같은 최신 문법을 다 쓸 수 있다. 반면 기존 8 레거시는 라이브러리 호환을 보며 17로 먼저 올리는 게 현실적이다. ‘무조건 최신’이 아니라 ‘내 라이브러리·런타임이 지원하는 가장 높은 LTS’가 답이다.
이 표를 언제 다시 펴나
‘이 기능 몇부터 되지?’가 헷갈릴 때다. record는 16, 텍스트 블록은 15, 가상 스레드는 21 — 이런 걸 외우기보다 이 지도를 북마크해 두고 필요할 때 펴 보면 된다. 다음(마지막) 편은 이걸 바탕으로 ‘무엇을 고를까’를 실무 관점에서 정리한다.
지도까지 완성했다. 시리즈의 마지막 편은 가장 현실적인 질문에 답한다 — 그래서 나는 어떤 버전을 써야 하나.
자주 묻는 질문 (FAQ)
자바 8·11·17·21 중 뭘 고를까요?
새 프로젝트는 최신 LTS(21) 또는 안정적인 17을 권합니다. 레거시는 라이브러리·프레임워크 지원 버전을 먼저 확인하세요.
각 버전의 대표 기능은요?
8은 람다·스트림, 11은 표준 HttpClient, 17은 record·sealed, 21은 가상 스레드·패턴 매칭입니다.
답글 남기기