자바 14 가 발표 되 었 습 니 다.더 이상 NullPointer Exception 을 두려워 하지 않 습 니 다.

자 바 는 2020 년 3 월 17 일 발표 한 JDK 14 를 공식 발표 해 현재 다운 로드 를 개방 할 수 있다.JDK 14 에서 모두 16 개의 새로운 특성 이 있 는데 본 고 는 그 중의 한 가지 특성 을 소개 한다.JEP 358:Helpful NullPointer Exceptions
null 무슨 잘못 이 있 습 니까?
자바 프로그래머 에 게 null 은 골 치 아 픈 것 이다.빈 포인터 이상(NullPointer Exception)에 시 달 리 는 경우 가 많다.많은 프로그래머 들 이 프로그램 에 NPE 가 나타 나 는 것 을 특히 두려워한다 고 믿는다.왜냐하면 이런 이상 은 종종 코드 의 예상 치 못 한 운행 과 수반 되 기 때문이다.
프로 그래 밍 언어 에서 빈 인용(Null Reference)은 빈 포인터 와 유사 한 개념 으로 선언 되 었 으 나 유효한 대상 에 인용 되 지 않 은 변수 입 니 다.
자바 1 에는 Null 인용 과 NPE 가 포 함 돼 있 었 지만,사실 Null 인용 은 위대 한 컴퓨터 과학자 인 Tony Hoare 가 1965 년 에 발명 한 것 으로,최초 로 프로 그래 밍 언어 인 ALGOL W 의 일부분 이 었 다.
1965 년 영국의 토 니 호 어(Tony Hoare)라 는 컴퓨터 과학자 가 ALGOL W 언어 를 설계 하면 서 null 인용 아 이 디 어 를 내 놓 았 다.ALGOL W 는 쌓 아 올 리 기 에 기 록 된 최초의 유형 언어 중 하나 이다.Hoare 는"단지 이런 방법 이 실현 되 기 가 매우 쉽 기 때 문"이 라 며 null 을 인용 했다.비록 그의 디자인 취 지 는'컴 파일 러 의 자동 검색 체 제 를 통 해 인용 을 사용 하 는 모든 곳 이 절대적 으로 안전 하도록 확보 하 는 것'이 었 지만 그 는 null 인용 에 파란 불 을 켜 기로 결정 했다.왜냐하면 그 는 이것 이'존재 하지 않 는 값'을 위해 모델 링 을 하 는 가장 쉬 운 방식 이 라 고 생각 하기 때문이다.
그러나 2009 년,몇 년 후 그 는 자신 이 이런 결정 을 한 적 이 있다 는 것 을 후회 하기 시작 했다.이 를'10 억 달러 짜 리 잘못'이 라 고 부 르 기 시작 했다.실제로 호 어 스 의 이 말 은 지난 50 년 간 수백 만 명의 프로그래머 들 이 빈 인용 을 복구 하 는 데 쓴 대 가 를 과소평가 했다.ALGOL W 이후 등장 한 대부분의 현대 프로 그래 밍 언어 는 자바 를 포함 하여 똑 같은 디자인 방식 을 사 용 했 기 때문이다.그 이 유 는 더 오래된 언어 와 호 환 되 거나 Hoare 가 진술 한 것 처럼'단지 이렇게 실현 되 기 때문에 더욱 용이 하 다'는 것 이다.

많은 자바 프로그래머 들 이 똑 같이 null 과 NPE 에 대해 극도로 증오 한다 고 믿는다.왜냐하면 그 는 확실히 여러 가지 문 제 를 가 져 올 것 이기 때문이다.예:
4.567917.그것 은 잘못된 근원 이다.NullPointer Exception 은 현재 자바 프로그램 개발 에서 가장 전형 적 인 이상 이다.그것 은 너의 코드 를 팽창 시 킬 것 이다4.567917.코드 를 깊이 있 게 포 함 된 null 검사 로 가득 채 우 고 코드 의 가 독성 이 매우 엉망 입 니 다4.567917.그 자체 가 무의미 하 다.null 자체 에는 어떠한 의미 도 없습니다.특히 정적 유형 언어 에서 잘못된 방식 으로 변수 값 이 부족 한 모델 링 을 대표 합 니 다자바 의 철학 을 파괴 했다.자바 는 프로그래머 에 게 지침 의 존 재 를 의식 하 게 하지 않 으 려 고 노력 해 왔 다.유일한 예 외 는 null 지침 이다4.567917.자바 의 유형 시스템 에 구멍 을 냈 다.null 은 어떠한 유형 에 도 속 하지 않 습 니 다.이것 은 임의의 인용 형식의 변 수 를 할당 할 수 있 음 을 의미 합 니 다.이것 은 문 제 를 일 으 킬 수 있 습 니 다.이 변 수 는 시스템 의 다른 부분 에 전 달 된 후에 이 null 변수 가 최초 로 할당 한 값 이 어떤 유형 인지 알 수 없 기 때 문 입 니 다다른 언어 는 NPE 문 제 를 어떻게 해결 합 니까?
자바 언어 외 에 도 다른 대상 언어 가 많다 는 것 을 잘 알 고 있 습 니 다.그러면 다른 일부 언어 에서 NPE 문 제 를 어떻게 해결 합 니까?
Groovy 에서 보안 네 비게 이 션 연산 자(Safe Navigation Operator)를 사용 하면 null 의 변수 에 접근 할 수 있 습 니 다.

def carInsuranceName = person?.car?.insurance?.name

Groovy 의 보안 네 비게 이 션 조작 자 는 null 이 참조 할 수 있 는 변 수 를 방문 할 때 NullPointer Exception 이 발생 하 는 것 을 피 할 수 있 습 니 다.호출 체인 의 변수 가 null 에 부 딪 혔 을 때 null 인용 을 호출 체인 을 따라 전달 하고 null 로 되 돌려 줍 니 다.
사실 이 기능 은 비슷 한 기능 을 추가 하 는 것 을 고려 한 적 이 있 으 나 나중에 버 려 졌 다.
또한 Haskell 과 Scala 에 도 Haskell 의 Maybe 유형,Scala 의 Option[T]과 같은 유사 한 대체 품 이 있다.
Kotlin 에서 그 유형 시스템 은 null 을 수용 할 수 있 는 지,수용 할 수 없 는 지 를 엄 격 히 구분 합 니 다.즉,하나의 변수 가 비어 있 는 지 여 부 는 성명 을 표시 해 야 합 니 다.비어 있 는 변수 에 대해 서 는 구성원 에 게 접근 할 때 빈 처 리 를 해 야 합 니 다.그렇지 않 으 면 컴 파일 이 통 과 될 수 없습니다.

var a: String = "abc"
a = null //     

비어 있 으 면 빈 문자열 을 설명 할 수 있 습 니 다.String 을 작성 하 시 겠 습 니까?:

var b: String? = "abc" //String?     String        
b = null //     

이거 봤 어?라 고 말 하면 서 Groovy 와 비슷 하 다 는 것 을 알 게 되 지 않 았 나 요?그래도 어느 정도 차이 가 있 으 니 여 기 는 펼 치지 않 겠 습 니 다.
자,책 은 본론 으로 들 어 갑 니 다.TOIBE 프로 그래 밍 언어 순위 1 위 언어 로 서 자바 언어 가 NPE 에 어떤 노력 을 했 는 지 살 펴 보 겠 습 니 다!
자바 가 어떤 노력 을 했 는 지.
그동안 null 과 NPE 의 개선 에 노력 해 왔 습 니 다.
먼저 자바 8 에서 optional 을 제 공 했 습 니 다.사실은 자바 8 이 출시 되 기 전에 구 글 의 Guava 라 이브 러 리 에서 먼저 optional 인 터 페 이 스 를 제공 하여 null 을 빠르게 실패 시 켰 습 니 다.
optional 은 null 의 대상 에 대해 한 층 의 패 키 징 을 했 습 니 다.optional 대상 은 특정한 값 이 존재 하 는 지,부족 한 지 를 명시 적 으로 처리 하 는 방법 을 포함 하고 있 습 니 다.optional 류 는 사고 값 이 존재 하지 않 는 상황 을 강제로 처리 하면 잠재 적 인 빈 포인터 이상 을 피 할 수 있 습 니 다.
그러나 디자인 optional 류 의 목적 은 null 을 완전히 대체 하 는 것 이 아니 라 더 이해 하기 쉬 운 API 를 디자인 하 는 것 이다.optional 을 통 해 방법 서명 을 통 해 이 함수 가 부족 한 값 을 되 돌려 줄 수 있다 는 것 을 알 수 있 습 니 다.이렇게 하면 이러한 부족 한 값 을 강제로 처리 할 수 있 습 니 다.
Optional 의 용법 에 대해 본 고의 중점 이 아니 라 여기 서 상세 하 게 소개 하지 않 겠 습 니 다.필 자 는 일상적인 개발 에서 Stream 과 함께 Optional 을 자주 사용 하 는 것 이 좋 습 니 다.
또 하 나 는 최근(2020 년 03 월 17 일)발 표 된 JDK 14 에서 NPE 에 대한 증강 이 있 었 다 는 점 이다.바로 JEP 358 입 니 다.Helpful NullPointer Exceptions.
더 도움 이 되 는 NPE
JDK 14 에서 NEP 에 대한 강화 가 있 었 습 니 다.NPE 가 잠시 피 할 수 없 는 이상 개발 자 에 게 도움 이 되 었 습 니 다.

자바 개발 자 마다 NullPointer Exceptions(NPE)를 만난 적 이 있다.NPE 는 프로그램의 거의 모든 곳 에서 발생 할 수 있 기 때문에 포획 하고 복원 하려 는 시 도 는 일반적으로 현실 에 맞지 않 는 다.따라서 개발 자 들 은 NPE 가 실제로 발생 했 을 때의 출처 를 확인 하기 위해 JVM 에 의존 하 는 경우 가 많다.예 를 들 어 이 코드 에 NPE 가 나 타 났 다 고 가정 하면:

a.i = 99;

JVM 은 NPE 를 만 드 는 방법,파일 이름과 줄 번 호 를 출력 합 니 다.
Exception in thread "main" java.lang.NullPointerException
at Prog.main(Prog.java:5)
상기 스 택 정 보 를 통 해 개발 자 는 a.i=99 줄 을 찾 을 수 있 고 a 는 반드시 null 로 추정 할 수 있 습 니 다.
그러나 더 복잡 한 코드 에 대해 서 는 디 버 거 를 사용 하지 않 으 면 어떤 변수 가 null 인지 확인 할 수 없습니다.이 코드 에 NPE 가 나 타 났 다 고 가정 하면:

a.b.c.i = 99;

우 리 는 a 인지 b 인지 c 가 실 행 될 때 null 값 인지 전혀 확실 하지 않다.
하지만 JDK 14 이후 이런 곤경 은 풀 렸 다.
JDK 14 에서 실행 기간 에 bull 대상 을 응용 하려 고 할 때 JVM 은 NullPointer Exception(NPE)을 던 집 니 다.그 밖 에 분석 프로그램의 바이트 코드 명령 을 통 해 JVM 은 어떤 변수 가 null 인지 정확하게 확인 하고 스 택 정보 에 명확 하 게 알려 줍 니 다.
JDK 14 에서 위의 a.i=99 에 NPE 가 발생 하면 다음 스 택 을 인쇄 합 니 다.
Exception in thread "main" java.lang.NullPointerException:
Cannot assign field "i" because "a" is null
at Prog.main(Prog.java:5)
a.b.c.i=99 라면;중 b 가 null 로 빈 지침 을 만 들 면 다음 스 택 정 보 를 인쇄 합 니 다.
Exception in thread "main" java.lang.NullPointerException:
Cannot read field "c" because "a.b" is null
at Prog.main(Prog.java:5)
이 를 통 해 알 수 있 듯 이 스 택 에서 어떤 대상 이 null 인지 명확 하 게 지적 하여 NPE 를 초래 했 습 니 다.그러면 응용 프로그램 에서 NPE 가 발생 하면 개발 자 는 스 택 정 보 를 통 해 코드 중의 그 대상 이 null 로 인 한 것 인지 가장 먼저 찾 을 수 있 습 니 다.
이것 은 JDK 의 작은 개선 이 라 고 할 수 있 지만 이 개선 은 개발 자 에 게 매우 우호 적 입 니 다.이런 작고 아름 다운 변화 가 JDK 에서 점점 더 많아 졌 으 면 좋 겠 습 니 다.
참고 자료:
https://openjdk.java.net/jeps/358
《Java 8 In Action》
자바 14 에 관 한 이 글 은 더 이상 NullPointer Exception 이 두 렵 지 않 습 니 다.더 많은 자바 14 NullPointer Exception 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 조회 하 시기 바 랍 니 다.앞으로 많은 응원 바 랍 니 다!