null 가능성과 자바

개요

• 자바의 타입 시스템은 코틀린의 null 가능성을 지원하지 않음
• 모든 값을 쓸 때마다 null 검사를 해줘야 하는가?

---

어노테이션을 통한 null 가능성

• @Nullable 어노테이션이 붙은 코드 == 코틀린의 null이 될 수 있는 타입

널 가능성 어노테이션이 없는 경우 자바의 타입은 코틀린의 플랫폼 타입이 됨

---

플랫폼 타입

• 코틀린의 null 관련 정보를 알 수 없는 타입
  • null이 될 수 있는 타입으로 처리해도 되고
  • null이 될 수 없는 타입으로 처리해도 됨
• 플랫폼 타입을 사용할 경우 null 가능성에 대한 처리를 사용자가 판단해야 함

public class Person {
    private final String name;
    
    public Person(String name) {
        this.name = name;
    }
    
    public String getName() {
        return this.name;
    }
}

• 코틀린 컴파일러는 getName에 대한 String null 가능성을 알 수 없음
  • null 가능성을 직접 처리해야 함

fun yellAt(person: Person){
    println(person.name.uppercase()+ "!!!")
}

fun main() {
    yellAt(Person(null))
    // java.lang.NullPointException: person.name must not be null
}

• getName()의 반환 타입을 null이 될 수 있는 타입으로 해석해 null 안전성 연산을 활용할 수 있음

fun yellAt(person: Person){
    println((person.name ?: "Anyone").uppercase()+ "!!!")
}

fun main() {
    yellAt(Person(null))
    // ANYONE!!!
}

• null 값에 대한 엘비스 연산 제공 → 예외가 발생하지 않음

대부분의 자바 라이브러리 → null 관련 어노테이션을 쓰지 않음

• 오든 타입을 null이 아닌 것처럼 다룰 수 있지만 오류가 발생할 수 있음

📌코틀린의 플랫폼 타입 도입 이유

• 모든 자바 타입을 null이 될 수 있는 타입으로 다루면 불필요한 null 검사가 많아짐
• 리스트를 다룰 경우 각 원소에 접근할 때마다 null 검사 또는 안전한 캐스트를 수행해야 해 검사에 드는 비용이 너무 큼
• 모든 타입에 대한 null 검사를 작성하는건 비효율적임

코틀린에서 플랫폼 타입을 선언할 수 없음

• 자바 코드에서 가져온 타입만 플랫폼 타입이 됨
• 플랫폼 타입은 타입명 뒤에 느낌표 ( ! )가 표시됨
  • String!

---

상속

• 코틀린에서 자바 메서드를 오버라이드 할 때 그 메서드의 파라미터와 반환 타입의 null 가능성을 지정해줘야 함

interface StringProcessor {
    void process(String value);
}

위 자바 인터페이스에 대해 코틀린 컴파일러는 두 구현을 다 받아들임

class StringPrinter: StringProcessor {
    override fun process(value: String) {
        println(value)
    }
}

class NullableStringPrinter: StringProcessor {
    override fun process(value: String?) {
        if(value != null)
            println(value)
    }
}

• null 가능성을 제대로 처리하는 것이 중요함