JDK 28 - 값 객체 프리뷰와 AOT 코드 컴파일을 포함할 Java SE 28 참조 구현

Hacker News 의견들 다들 값 객체를 갈망하지만, 나는 JEP 542의 암호화 객체 PEM 인코딩과 JEP 543의 구조적 동시성이 가장 기대됨. 개발자는 인증서를 다루는 빈도가 낮아 형식 변환에 능숙해지기 어려운데, PEM을 직접 사용할 수 있으면 번거로움이 크게 줄어들 것임. 수년간 Java 동시성을 몇 차례 시도했지만 기존 기본 요소들은 마음에 들지 않는 건지, 어떻게 쓰라는 건지 이해가 안 되는 건지 모르겠음. 유일하게 와닿았던 라이브러리는 Awaitility인데, 어째서인지 운영용이 아닌 테스트용으로 설계됨. 구조적 동시성이 드디어 이해의 실마리를 열어줄지도 모르겠음. 최근 몇 년간 Java의 발전 속도가 빨라지는 모습을 보니 정말 반가움. 그동안 서버 개발에는 Kotlin을 썼지만, 현대 Java만으로도 언어에 바라는 거의 모든 것이 충족될 듯함. Kotlin으로 완전히 전환하지는 않았음. 좋은 언어지만 갈아탈 만큼은 아니며, 지난 10년간 Java가 발전해 온 방향도 마음에 듦. 이제는 JVM 서버가 Node.js 서버보다 가벼울 정도임. Android 외에는 Kotlin을 쓸 이유가 보이지 않음. Android 개발진은 과거에 머물러 현대 Java 지원에 소극적이며, Kotlin에서 활용할 수 있는 Android 호환 Java 라이브러리가 줄어들기 시작해야 움직이는 듯함. 오래전에 깨달았지만, 나타났다 사라지는 언어보다 플랫폼의 기반 언어를 숙달하는 편이 가치가 큼. 불평하면서도 C 지식을 계속 갱신하는 이유가 UNIX의 언어이기 때문임. 웹의 JavaScript, BEAM의 Erlang, JVM의 Java도 마찬가지이며, Scala와 Clojure가 훨씬 멋지더라도 이 점은 달라지지 않음. 개발 방식의 변화가 정말 반갑고 예전보다 훨씬 나아짐. Java를 좋아하는 입장에서 소유권을 둘러싼 온갖 혼란에도 꾸준히 개선되어 기쁨. 최근에야 발전 속도가 빨라졌다는 평가는 공정하지 않다고 봄. Java와 JVM은 지난 10~15년간 꾸준히 발전해 왔으며, 언어부터 JVM의 여러 부분까지 개선이 이어짐. HN과 소셜 미디어에서 다시 관심과 조회수가 늘어나니 개발이 빨라진 것처럼 느껴지는 것임. 최근 반영된 개선 중 상당수도 실제로는 5~10년에 걸쳐 개발된 결과임. 여전히 문법은 마음에 들지 않지만, AI 중심 개발 시대에도 그것이 문제가 될지는 잘 모르겠음. 그런데 왜 반가운 것인지 궁금함. AI...