[Java] Java 버전 선택에 관한 고찰

어떤 Java 버전을 고려해야할까?

• 8, 11, 17버전은 LTS 지원 버전
• 가장 많이 사용하는 자바 8, 11, 17은 3~4년 동안 모인 업데이트들을 토탈 지원하는 LTS
• Spring Boot 프로젝트를 생성 시 자바 8, 11, 17, 20 버전밖에 지원하지 않음

결론

8, 11, 17중에서 선택

Java 점유율(jetbrains - 개발자 2022 java 에코시스템 현황)

LTS 지원기간(Oracle JDK 기준)

• Java 8 : 2030년 12월까지
• Java 11 : 2026년 9월까지
• Java 17 : 2029년 9월까지

Java 8 VS Java 11

• Java 8
  • Java 8 버전이 점유율이 가장 높은 이유는?
    • 발표된 LTS 버전 중 가장 오랜 Support를 보장
    • 기존 서비스와의 호환(가장 오래된 버전인 만큼 많은 프로젝트가 Java 8로 개발되었고, 일부 유지중)
  • 오래된 버전인 만큼 점점 점유율이 떨어지는 추세(2021 → 2022 사용률 12% 감소)
• Java 11
  • LTS 지원기간이 가장 짧음.
  • Java 11에서는 람다 파라미터에서 좀 더 명시적으로 var를 사용할 수 있게 됨
  • 내부적으로 JVM은 모듈을 활용하여 클래스 로딩을 보다 효율적으로 만들 수 있어서 런타임이 더 가벼워져서 빠르게 시작할 수 있음
  • Java Flight Recorder(JFR) 및 Java Mission Control(JMC)는 Java 8에서는 유료지만, Java 11에서는 오픈소스로 제공
    • JFR 및 JMC를 사용하면 메모리 누수, GC 오버헤드, 핫 메서드, 스레드 병목 상태 및 I/O 블로킹과 같은 런타임 문제를 진단할 수 있음.
  • 다중 릴리스 jar 파일
    • Java 11에서 클래스 파일의 여러 Java 릴리스별 버전을 포함하는 jar 파일을 만들 수 있음
  • JVM 성능 향상
    • Segmented Code Cache
      • JVM 메모리 공간을 효율적으로 제어하고 컴파일된 메서드의 검색시간을 단축하고, 코드 캐시의 조각화를 줄여 성능 향상
    • Compact Strings
      • 문자열을 저장하는 데 필요한 공간이 효율적으로 변경
  • HTTP Client(Standard)
    • HTTP/2 및 WebSocket을 구현하고 레거시 HttpURLConnection API를 대체할 수 있는 새로운 HTTP 클라이언트 API를 제공
  • 이외에도 여러가지 성능 개신 및 업데이트 내용이 존재

결론

GC의 개선 및 추가, 성능 개선을 위한 도구들, 유용한 기능을 제공하는 11을 버리고 8을 선택할 이유가 없음

Java 11 VS Java 17

• Java 11
  • Spring Boot 2.xx를 사용
  • Spring Boot 2.7 is the last planned release in the 2.x line. We’ve extended our open source support for this release by an additional 6 months until November 2023. → 2023년 11월까지만 오픈소스 지원(Spring.io 공식)
    
  • 아직까지는 Java 11이 대세
  • Oracle JDK 유료
  • 많은 Spring Boot 레퍼런스가 Java 11을 기준으로 제공됨.
    • 러닝커브가 낮고, 익숙하기 때문에 빠른 개발이 가능
• Java 17
  • LTS 지원기간이 Java 11보다 긺
  • Spring Boot 3.xx는 Java 17 이상의 버전이 필수
  • Oracle JDK 무료 라이선스 제공
  • 추가 기능
    • 텍스트 블록
    • 람다식을 통한 Switch 구문 개선
    • Stream.toList() 간결화
    • NullPointerException의 원인 제공
      • 디버깅, 오류잡는데 시간단축 가능(이건 좋은데?)
    • GC 성능개선도 있었다함
  • 단, 호환성 문제가 발생할 수 있음
  • 레퍼런스가 상대적으로 적음
    • 러닝커브가 높다고 판단
  • 미래에는 Spring Boot 3.xx를 위해 Java 17을 사용하기 때문에 장기적으로 보면 마이그레이션 비용이 줄어들 수 있음.
    • 소규모 프로젝트에서는 고려X
  • “여기어때” JDK 17을 도입한 이유

결론

성능 및 확장성을 우선하면 Java 17을, 안정성 및 개발 속도를 우선하면 Java 11을 고려(Java 11 한표)

Spring Boot Support

Spring Boot 2.xx VS 3.xx

• 2.xx
  • 레퍼런스가 많음
    - 많은 자료들이 2.xx를 기준으로 제공
• 3.xx
  • Java 17 이상 지원
  • 변경 사항
    • Java EE를 jakarta EE 로 대체
      • javax. 에서 jakarta. 로 변경
    • 보안상 이슈로 /api/hello 와 /api/hello/ 는 더 이상 일치하지 않음.
  • GraalVM 기반의 Spring Native 공식 지원
    • MSA의 서버 실행 시간 및 메모리 사용률의 많은 비용 문제를 해결하기 위해 나온것인데 우리는 필요한가??
  • HTTP/RSocket Interface Client를 제공
  • Micrometer Observation API가 자동으로 구성되며, Observability 공식 지원
  • HTTP API 에러 처리를 위한 RFC 7807 스펙 지원
  • 이미 Spring Boot 2.xx로 개발된 서비스에서는 마이그레이션 비용을 감당하면서 까지 3.xx로 넘어갈 이유는 없다고 생각(시기상조)

결론

Spring Boot 2.xx 한표

최종 결론

Java 11, Spring Boot 2.xx