Spring 프레임워크 6.1, 이제 Virtual Threads 및 JDK 21과 호환
(github.com/spring-projects)- Virtual Threads (OpenJDK's Project Loom) 지원 및 JDK 21과 전반적인 호환을 제공
- 전용 VirtualThreadTaskExecutor 추가
- 기존 SimpleAsyncTaskExecutor, SimpleAsyncTaskScheduler 에도 가상 쓰레드 모드 제공
- JVM Checkpoint Restore(Project CRaC) 연동
한국에서 스프링 사용 용도가 postgREST 수준의 DB 미들웨어 취급이 대부분이라 당장 저 스레드를 활용한 병렬처리니 동시성 처리니 뭐니 다 ACID 궁합이 최악이다 보니 네임드 업체 말고는 절대 안쓰는게 현실입니다. 왜 절대냐고요? 함부로 말하지 말라고들 하죠. 하지만 SI SM 경험해 보신 분이라면 왜 절대인지 알게 될 겁니다. 절대 못 써요... 당장 비즈니스 로직을 DB에서 어떻게든 해결하려는 것부터가 틀렸죠.
HN 에도 이런 댓글이 있군요
https://news.ycombinator.com/item?id=37147996
"JDK의 이러한 모든 훌륭한 기능에도 불구하고 대부분의 포춘 500대 기업은 여전히 JDK8 또는 9를 사용하고 있을 겁니다"
Java를 쓰는 많은 곳이 비슷한 상황일듯 합니다. 하지만 바뀌어 가겠죠
다른 나라는 몰라도 한국은 100년 지나도 절대 안바뀝니다. 젯브레인에서 자바를 많이 사용하는 국가 인증까지 해주고 정부부터 무조건 개발가이드를 자바와 C만 제공하고 있으며(자스는 커녕 파이선 시큐어코딩 메뉴얼 없음) 전자정부프레임워크를 위시한 스프링을 네키라쿠배부터 애용하고 있는 시스템을 해까닥 갈아엎기도 어려울 정도의 독점적인 인력풀 현실인 데다가 아직도 공공에서는 자바 11로 만든 복시스템 장애 때문에 자기 입장에서 검증이 안됐으니 자바 1.6을 주니어에게 강요까지 하면서 아직도 국내 자바 대표 커뮤니티에서 자바 17 교육도 시기상조라는 목소리가 지지받는 한국 에서요? 푸하하핳하...
제가 좀 조롱하는듯한 말투라면 사과드리죠. 하지만 제가 말한 사실은 바뀌지 않는게 현실입니다. 당장 제가 그 산 증인이거든요. 10여년간 일하면서 점점 암울해지는 현실을요... SI SM이 아직도 개발인력시장의 7할입니다...