Java 버전업 (11->17) 후기 켁;

팀내 admin 프로젝트에 Java 버전업을 담당하였다. 비교적 다른 프로젝트에 비해 규모가 작은터라 부담은 없었지만 ... 

개인적으로 타팀에서 많이 조회되는 api를 가지고 있는지라 한편으로는 장애 날때마다 dev, alp 든 봐야한다는 부담감이 있어서 조심스러웠다. 

 

자바 버전업 얘기가 나온것은 팀에서도 소개를 하긴 했지만

아래와 같은 이유에서 도입을 하게 되었다.

---

자바 버전업 도입 목적

Java 17은 2021.10 공개한 LTS 버전으로 2029년 9월까지 지원을 하게 됩니다.

Java 11과 비교해서 70가지 이상의 JEP 가 추가되었습니다. (*JEP - JDK 개선 제안) 

• Java Support 기간이 길다.
  • LTS 버전의 장점은 기업과 개발자들이 안정적인 플랫폼에서 장기적인 개발 계획을 세울 수 있다는 것이 장점
• 신규 버전 대비
  • Java 17은 패턴 매칭, 레코드, 향상된 스위치 문 등의 새로운 언어 기능을 도입했습니다. 이러한 기능들은 코드의 가독성과 유지 보수성을 향상시킬 뿐만 아니라, 오류 발생 가능성을 줄일 수 있음 
• Spring Boot 다음 버전 대비 
  • 스프링 프레임워크와 스프링 부트는 지속적으로 업데이트되어 최신 자바 버전과의 호환성을 유지
  • Spring Boot 3.0 부터는 JDK 17 이상 지원

---

그런데 이렇게 자바 버전업을 도입했을 때 문제는 라이브러리 호환성하고 코드 호환성을 체크해야하는게 제일 번거로운데 가득이나 admin 쪽이여서 view 페이지까지 확인을 해야 하는 점이다. 

실제로 그런 문제도 발생하였다. 시리얼라이즈 할때 추가된 모듈이 있었는데 localdatetime 으로 string 타입으로 전달되어야 하는데 배열로 바껴서 내려가는 문제가 발생하기도 했다. (java 8 기능으로 추가된 모듈인데 java11, 17 동일한 문제)

퇴근시간 즈음에 alp 테스트 해보고 집가는 길에 발견해서 이날 3시간 더 근무한거 같다. 12월 연말이었는데 히잉;

버전업 방법은 다음 프로세스로 진행하였다. 

---

버전업 방법

1. admin에서 사용중인 라이브러리 표로 정리  
   1. 버전 수정 시 이전 버전에 대한 이력 관리
2. jdk17 버전 릴리즈 날짜 → 라이브러리 버전 사용 시 jdk 릴리즈 날짜 고려해서 정리 && 사용량 체크
3. Java, Spring Boot 버전업 해서 실행시켜보기 → 컴파일 오류 수정
4. 주요 API에 대한 통합 테스트 작성하기 & 기능 검증
5. 기능 수정된 코드에 대한 테스트 코드 추가

---

실제 여기 과정중에서 4번 과정을 유심히 살펴봤다. 주로 통합테스트가 많았기 때문에 public 열려있는 서비스들은 모두 체크해본거 같다. 그리고 버전 올리면서 기능 수정된거 코드에 대한 테스트 코드도 함께 추가하였다. 

그러면 이번에는 왜 버전업이 필요한지 생각이 들것같다. 우리가 버전업을 생각하게 된 계기는 가장 최우선으로 생각한 부분은 spring boot 버전이다. 3.0 이상을 쓰고 싶었기 때문이다. 보다 안정적인 서비스를 운영할 수 있다는 장점이 있다. 왜냐하면 기존에 쓰고 있던 구조가 fade-out 될 수도 있으니까? 

처음에 hystrix fade-out 되는걸 생각했는데 resilience4j 가 spring boot 2.x 에서도 지원되는것을 발견했다. (SW 개발자 현직자 정보 공유방 월요일-햅삐님 감사합니다.) 

-> https://resilience4j.readme.io/docs/getting-started-3 여기보면 spring boot2.x에서도 지원한다. 

그래서 장단점을 정리해봤다. 

---

버전업 장, 단점

장점

• 성능 향상 
• 새로운 기능 제공 - 레코드, 패턴 매칭
• 보안 강화 - 과거 자바 버전에서 발견된 실행 취약점등을 최신 버전에서 패치
• 장기 지원(LTS 버전)
• 커뮤니티 지원

단점

• 업그레이드 리소스 비용
• 호환성 문제 - 라이브러리 업데이트 및 전수조사가 요구
• 러닝 커브
• 버전 관리 - 대규모 시스템에서 여러 자바 버전을 관리해야 할 수 있습니다. 
  • 배포 운영중인 환경에서 발생할 수 있는 문제를 예측하고 관리 해야 합니다. 
• 코드 호환성 검사 - 리팩토링 진행 리소스 소비

---

이렇게 내용 정리를 끝내두고 Java 11에서 17 호환성 검사에 대해 찾아봤다. 

공식문서를 찾아보면 12-16은 고려할 필요가 없었다. non-LTS라는 점에서 장기지원이 아니기 때문에 우리는 그냥 바로 17로 건너뛰어갔다. 

우오오

아래는 참고 자료

 

---

진행 프로세스

• 의존성 검사
  • 프로젝트에 사용된 모든 라이브러리와 프레임워크의 최신 버전이 Java 17과 호환되는지 확인 
    • 필요한 경우 업그레이드 or 삭제 
• 프로젝트의 코드를 검토하여 deprecated 된 기능을 사용하는 경우, 제거된 기능이 있는지 확인
  • Java 17에서 제거된 기능을 사용하는 경우 해당 기능의 대체 방안을 찾기
  • https://docs.oracle.com/en/java/javase/17/migrate/removed-apis.html#GUID-9EF06707-9441-433E-BA50-9DD99F1C07F4 - removed api 
  • https://docs.oracle.com/en/java/javase/17/docs/api/deprecated-list.html - deprecated api 
• 컴파일 및 테스트
  • Java 17 JDK를 설치한 후 프로젝트를 컴파일하고 실행, 컴파일 오류가 발생하면 수정하고, 프로젝트의 모든 단위 테스트와 통합 테스트를 실행하여 예상치 못한 문제를 찾아 수정

---

여기서 주의해야할것은 회사에서 자체적으로 사용중인 내부 라이브러리가 있다면 gradle 호환성 같은것도 꼭 점검해야 한다. 

어찌 어찌 여기까지 검사가 완료됐다면 표 같은걸 하나 만들어서 어드민 프로젝트에서 사용중인 라이브러리 버전들을 몽땅 전수조사 하였다. 그리고 이거 조사할때 해당 라이브러리에 대한 github readme 같은것을 참고하면 좋다. 공식 페이지에도 수록되어있다. 

하나 예시를 들면 mybatis-spring-boot 버전에 대한 조사를 할때 아래와 같이 변경사항에 대해 알려준다. 어떤 라이브러리들은 직접적으로 자바 몇 버전은 호환이 됩니다. 라는것을 알려준다! 

---

이렇게 라이브러리 점검도 다 끝났으면 기존 코드에서 리팩토링할건 없는지 체크해본다. 컴파일 에러나 주로 사용중인 API 들에 대한 기능이슈는 없는지 확인해봐야 한다. 

개인적으로 욕심이 나서 java 17 feature 몇개를 일부러 도입해봐다. 패턴 매칭이라던지 record 라든지 결합도가 비교적 낮은 로그인 피처에 도입해보기도 했다. 

테스트 코드는 물론 추가하고... 

로컬에서 잘 동작한다고 안심해서는 안된다. jenkins 서버도 동일하게 맞춰줘야 한다. 

jenkins는 여기서는 다루지 않겠지만 master-slave 모두 17 을 설치하고 JAVA_HOME 도 역시 맞춰주었다. 

이걸 안맞추면 빌드하고 배포 시 java 버전이 안맞는다는 에러가 뿜뿜한다.. ㅠㅠ 

아무튼 자바 버전업 하시는 분들 모두 고생하세요..

아마... 이걸 메인 프로젝트에서 하라고 했으면 12월은 집에 못갔을듯..