자바 버전별 한국 도입 예상 년도

오라클 기준 자바 8부터 시작하도록 하겠다.
반박한다 한들 근거는 네 말이 맞을 수 있지만 정착 년수에 대해선 네 말은 절대 맞을 수가 없다.
그리고 늬들이 꼴도보기 싫은 IT 시장의 반절 아직도 차지하고 있는 좀비같은 SI 산업 기준이다.
LTS 버전 기준으로만 설명한다.
안드로이드는 고려하지 않는다.

자바 8

2014년 + 1.8년 = 2016년

썬 마이크로시스템즈가 오라클에 인수되기 전 준비한 마지막 버전이다. 물론 출시는 오라클이 했지만.
오라클은 자바 버전 체계를 기존 썬처럼 1.x가 아닌 x로 가기로 했지만, 우리 마음속에 자바는 1.8이다.
자바 1.8은 2014년에 출시했다. 다행히도 대한민국에 생각보다 빠르게 안착했는데, 이때가 바로 1.8년 뒤인 2016년 되시겠다.
이렇게 빨리 안착했던 이유는 의외로 오라클에 있었는데, 뭐 지금도 그렇지만 당시에도 산업용 데이터베이스 시장 1위가 오라클인 건 부정할수 없는 사실이고, 왠만한 대기업들이나 금융기업들, 심지어 중견까지 개나소나 오라클. 아무리 비싸도 검증됐고, 미션 크리티컬에 친숙하게 대응이 가능하니 비싸더라도 오라클은 당연했던 시절이었으니까.
비슷한 시기에 오라클 12c가 출시했는데, 이녀석을 쓰려면 자바 1.8을 쓰라는 메뉴얼이 떡하니 박혀 있다. 물론 자바 1.6에도 쓸 수 있긴 한데, JDBC 드라이버가 아예 버전별로 나눠서 배포하기 때문에, 자바 1.8 기반의 JDBC 드라이버는 자바나 DB나 별다른 세팅 없이 연동이 가능한 덕분에 오라클의 이런 정책이 본의아니게 자바 8의 산업 도입이 생각보다 빨리 이루어졌다.

물론 자바 8의 신규 기능인 람다와 동시성 프로그래밍 향상은... 진짜 8년 뒤에서나 시작했다고 봐도 과언이 아닐 정도. 왜냐면 속도보다는 무결성이 최우선 순위다 보니 순차적(Procedural) 패턴이 당연시 여기기 때문이다. 근데 그러면서 스케줄은 빠듯하게, 속도와 최적화까지 하라는 이기적인 프로젝트도 일부 있었다.

그리고 또 하나, 자바 1.8에 생각보다 많이들 모르는 향상점이 있는데, 바로 PermGen 이라고 들어봤는가? 1.7버전까지 자바 실행 시 문자열 등 영구적인 개체 메모리를 얼마나 사용할건지 명시해야 했었어서 명시 안 하면 OS 제공 메모리 비해 너무 적은 메모리가지고 놀려다 보니 이런 오류를 많이 봤던 개발자도 있을 것이다.

OutOfMemoryError: PermGen space

하지만 1.8부터는 OS에서 할당받은 메모리에 따라 유동적으로 사용하도록 기본 세팅했기 때문에 -XX:PermSize=256M 같은 개같은 파라미터가 필요 없어졌다.
물론 Heap Size는 여전히 많이 사용해야 한다면 개발자가 -Xms -Xmx 명시해야 한다.

자바 11

2018년 + 11년 = 2029년

물론 네카라쿠배 같은 대표적인 IT 업체처럼 선도하는 시장 답게 자바 11을 빨리 도입한 업체도 있지만... 이들이 도입하면 뭐하리 한국 산업 전반에 정착하려면 아직도 7년이 모자르다. 왜인지 정리하자면,

• 좆같은 전자정부표준프레임워크
• var 구문에 대한 반발 (아니 시발 자바스크립트의 var 구문 아니라고! 컴파일러 이론 안쳐배웠나?)
• 우리 마음속에 있는 1.8에 비해 11은 너무 머나먼 심적인 버전 차이
• 어쩔 수 없는 팩트지만 산업적으로 편리해지거나 생산성에 도움되는 API 및 구문이 없음...

옆동네 닷넷의 버전 향상을 보면 이젠 아예 뇌절 수준만큼 CLR 기반의 언어 스펙이 향상되는 게 눈에 보이는데,
자바는 애초에 보수적인 언어고, 보수적으로 설계하기 때문에 폴리글랏 등 다른 언어에 비하면 좀 답답하게 느껴질 수 있다.
사실 내가 봐도 자바 11보다는 차라리 익숙하게 8로 가든가, 자바 17로 신규 프로젝트하는게 나아 보일것 같다.
해외에서도 사정은 마찬가지. 자바 11을 써야 하는 필연성을 못 느끼고 있다. 왜냐,

• 먼저 9부터 생긴 자바 모듈화, Project Jigsaw로 알려진 이 기능은 데스크탑 등의 응용 프로그램의 경량화에는 효율적이지만 자바를 쓰는 가장 많은 이유인 웹 어플리케이션의 경우 서버리스같은 극단적인 경량화가 요구되는 환경이 아니고서야 보통 환경이라면 아무리 MSA 구축해도 효과 별로 없다.
• 산업에서 표준으로 쓰다시피 하는 스프링 프레임워크 5의 최소 자바 요구 버전이 8이다.
• 자바 버전 더럽게 따지는 오라클 JDBC 드라이버는 18c 부터는 자바 11을 권장하지만, 자바 8 기반의 JDBC 드라이버를 써도 지장이 하나도 없다. 오라클도 그냥 손 놓은 듯 하다.
• 자바 10부터 생긴 var 구문은 여전히 씨잘대기 없는 논란이 있다.
• 병렬 가비지 콜렉터가 생겼다지만... 정말 좋기는 하지만... 업계에서는 별로 느낀 점도 없다.

지금 17 LTS가 나왔으니 더 이상 할 말이 없다. 이만 마치도록 하겠다.

자바 17

2021년 + 17년 = 2038년

이번 LTS는 참 기나긴 세월이었던 것 같다. 년수만 따지면 3년인데, 11부터 17까지 버전 6개나 뛰었다. 하지만 그만큼 자바도 이제 슬슬 진보되기 시작한다... 랄까?
자바 11은 정말 이걸 도입해야 할 명분이 없다시피 했는데, 이번에 자바 17은 도입할 명분이 조금씩 생기기 시작했다. 정리하자면,

• 자바 12부터 지원하는 switch문 간결화
• 자바 13부터 지원하는 switch형 변수 할당 (yield 구문 추가)
• 자바 14부터 지원하는 Record 타입 지원을 통한 VO(Value Object) 지원 향상
• 자바 15부터 지원하는 클래스 봉인(닷넷의 sealed class는 자바의 final class와 동일한 개념으로 자바에서 말하는 봉인은 상속 한정자를 지정하는 것)
• 자바 15부터 문단 블록 지원 (""" ... """)
• 자바 11부터 시작한 병렬 가비지 콜렉터 안정화
• Alpine Linux 지원으로 한층 더 가벼워진 환경
• 자바 8부터 권장하지 않는 PermGen 이 완전히 사라지고 metaspace로 대체하여 영구 보관 메모리 관리 효율성 향상
• NullPointerException 예외가 너무나 친절해져서 더욱 용이해진 문제 해결
• EdDSA, 의사난수(Pseudo-Random Number) 추가를 통한 보안성 향상
• jpackage 프로그램을 통한 자바 어플리케이션 패키징 프로그램 추가
• MacOS M1(aach64) 정식 지원
• 스프링 프레임워크 6.x 최소 요구 사항

많이 건너뛴 만큼 자바 커뮤니티가 노력한 흔적이 많이 엿보이는데, 언어적 향상도 많아졌고, 모던 컴퓨팅 환경 지원이 넓어져서 클라우드 도입 시에 대한 명분이 생겼다. 특히 Docker 도입 시 Alpine Linux 지원 덕에 더 가벼운 컨테이너를 들 수 있고...

하지만 자바 웹, 특히 Spring MVC를 많이 사용하는 한국에는 뭐 그다지 의미가 없을 것이다.
왜냐면, 당장에 스프링 6.0의 신규 기능을 보면... 패턴 기능 향상 말고 없다.
당연하다. 서블릿 표준부터 향상될 게 없는데.

그리고 자바를 네이티브로 돌려주는 GraalVM 정식 버전에는 자바 17을 기본으로 하는데, 아직도 산업 표준의 성공 사례가 없다. 11 나올때부터 나와서 네이티브를 통한 장점이 극대화된다는 특징에 비해 뭐가 없다. 다행히도 오라클은 포기하지 않고 계속 관리를 하고 있기는 한데...

빨리 결론 짓겠다. 당분간 자바 8이 주류일 것이다. 위의 기능적, 환경적인 향상은 한국에 의미 없다. 그놈의 레거시 인프라...

자바 21

2023년 + 21년 = 2044년

이제 좀 한국 정착 년도의 격차가 줄고 있다는 점에서 다행이겠지만...
이제 Project Loom에 대해 언급할 건데...
이게 뭐냐고? 자바의 병렬 처리에 대한 비약적 향상을 위한 프로젝트로, 2017년에 시작했다.
즉, 자바 10 시절부터 거론된 프로젝트지만 꽤 많은 시간이 흘렀다. 이런 병렬 처리 자체가 구현이 매우 빡세기 때문에 뭐 잘 되길 바라거나 참여하는 수밖에 없을 것이다.
일단, Project Loom의 첫번째 산물인 가상 스레드가 자바 19에 나온다. 올해 하반기네. 하지만 아직 Preview feature. 미리 보기다. 어자피 자바 19는 LTS가 아니니 실험적인 프로젝트에 많이 쓰고 피드백에 오겠지만.
가상 스레드를 간단히 설명하자면, 기존 스레드에 비해 스레드가 가지는 장점을 약간 희생하는 대신, 저렴한 비용을 통해 더 많은 스레드를 통한 동시 처리의 향상을 꾀하는 기능이다.
그다음 두번째 산물은 구조적 동시성(Structured concurrency)인데, 이 또한 자바 19부터 인큐베이팅으로 선보였다.
이 기능은 병렬 처리할 때에 대한 여러 경우를 대비하고 대응하기 위한 기능으로, 가장 많이 쓸 부분이 바로 예외 발생 시 어플리케이션 종료 시나리오, 취소 처리에 대한 전파성, 관점 지향성을 통해 더 다양하고 편리한 병렬 처리를 도모하는 기능 되시겠다.

그밖에 RISC-V 지원, 아직도 정식 출시 못한 패턴 매칭, 향상된 벡터 API, 외부 메모리 API 기능이 추가될 예정이다.

자바 20은 아직 그럴싸한 정보가 없기에 내년 상반기에 기다려 보자.

...라고 안해도 한국은 이미 답 나왔다. 이 버전도 쓰려면 한참 멀었다.
이유를 들자면,

• 한국 자바의 병렬 처리 활용은 시장성에 비해 너무 빈약하다. 네카라쿠배나 신생기업 아니면 볼 일 없다. 8부터 동시성 기능 정말 강력한데 SI 시장에서 쓰는 꼴을 보기 힘들다.
• SI에서 많이 쓰는 Spring MVC는 여전히 스프링 3 버전에서 못 벗어나고 있다. 여전히 스레드에 의존적인 서블릿 구조가 안정성을 좀먹는건 많이 알려져 스프링조차 비동기 방식 사용을 권장하고 있지만, 그딴건 모른다. 일단 돌아가기만 하면 된다. 병렬 처리에 대한 각종 시나리오 구현할 시간도 없거니와, 특히 JDBC와의 ACID 궁합은 최악이다 보니 꺼려지는 부분도 있다.
• 자바 데스크탑 활용도가 POS같은 경량 기기 사용에서부터 늘어나고 있지만 말이 경량화지 사실 아무리 경량화 됐다 해도 지금의 10~20만원짜리 컴퓨터 성능을 봐도 많이 좋아졌기에 자바 돌리지 그거 말고 이유를 댈 게 없다. 자바 모듈화도 안쓰는데 말 다했지. 오라클의 살인적인 라이선스도 있고.
• 안드로이드는 여전히 자바 11 지원도 못한다. 당연하겠지만 오라클과 법적 문제도 있고, 환경에 대한 충격도 크다. 한국에서 경량화 장비에 안드로이드 도입 사례가 늘어나고 있지만 안드로이드가 자바 최신 버전을 지원하지 않는 이상 이런 현상은 계속될 수밖에. 물론 구글이 대안으로 코틀린 네이티브를 젯브레인과 연구하고는 있지만... 아직은 감감무소식이지만 그래도 좋은 소식을 기대해도 좋다. 탈자바는 환영이다.

따라서, 한국의 자바를 통한 병렬 처리 활용도가 처참하여 가상 스레드가 나와봤자 빛좋은 개살구다.
뭐? 스프링 차기 버전에 Spring MVC에서 가상 스레드의 효과로 인한 코드 변경 없이 비동기 처리가 가능하다고? 그래봤자 한국엔 소 귀에 경읽기.

결론

오라클 망해도 한국은 자바 8 포에버!
반박시 오라클(예언자).

끗.