자바 설계 똥치운다.

암묵적 null 때문에 프로덕션에서 NullPointerException이 남.

최신 인텔리제이에도 코드보다 JSpecify 우선




Spring 전반에 걸친 Null 안전성 지원 현황에 대한 업데이트 공유

  • "10억 달러짜리 실수" 해결 중임

    • JSpecify 참여 조직들, Spring 팀, 그리고 Spring Boot 4로 업그레이드하는 개발자들이 함께 null 문제 해결 중임.

    • 진짜 실수는 null 참조 자체가 아니라, null 가능성을 타입 시스템에서 명시하지 않은 것이라고 봄.

    • 암묵적 null 때문에 프로덕션에서 NullPointerException이 남.

    • null 가능성을 타입에 명시하면, 값 부재를 표현하는 “제로 코스트 추상화”가 됨.

    • 기존 API와도 호환되면서 null 여부를 표현할 수 있음.

  • JSpecify 소개

    • JSpecify는 Java 코드베이스가 API의 null 가능 여부를 명시적으로 표시할 수 있는 어노테이션 세트를 제공함.

    • 상세한 스펙과 문서를 제공해서, 여러 도구가 일관되게 구현할 수 있게 설계됨.

    • 특정 IDE나 도구에 종속되지 않는 것이 핵심임.

  • 대규모 코드베이스에 null-safety 도입은 큰 작업임

    • 아무 데나 @Nullable 조금 다는 건 쉬움.

    • 하지만 전체 코드베이스를 어노테이션하고, 빌드할 때 null 불일치를 컴파일 에러로 취급하게 만드는 건 매우 어려운 작업임.

    • Spring 팀은 이 작업을 몇 달 전부터 진행해 왔음.

    • 지금은 Spring 포트폴리오의 대부분 API를 null-safe로 만드는 목표를 달성했다고 밝힘.

    • 목표는 Spring 개발자가 프로덕션에서 NullPointerException 위험을 줄이거나 제거하도록 돕는 것임.



      희망사항


      - 개발자는 이 기능을 얼마나 활용할지 스스로 결정할 수 있음:

      관련 경고를 꺼버릴 수도 있음.

      IDE에서 경고 나는 부분만 고쳐서 NPE 위험을 줄일 수도 있음

      아예 애플리케이션 전체를 null-safe하게 만들 수도 있음.

      이 작업은 기존 API를 깨뜨리지 않고도 진행 가능함.

      기존 타입에 “null 가능/불가능” 정보를 개념적으로 덧붙이는 작업이라 봄.

      더 많은 오픈소스 라이브러리가 JSpecify를 채택하길 기대함.

      JSpecify 도입이 JVM 생태계와 애플리케이션이 미래의 Null-Restricted / Nullable Types 기능을 받아들일 준비를 하는 데 도움이 될 거라 봄.

      이런 언어 기능이 정식(비-프리뷰) 기능이 되고, 라이브러리와 애플리케이션 베이스라인이 옮겨가는 데는 수년이 걸릴 수 있음.

      그 과정에서 런타임 효율성도 같이 좋아질 수 있다고 전망함


       https://spring.io/blog/2025/11/12/null-safe-applications-with-spring-boot-4