Kotlin 1.4-M1 출시되었습니다

Jessie Cho

새 주요 릴리스의 첫 번째 테스트 버전인 Kotlin 1.4-M1 소식을 전해드립니다.

몇달 전 저희는 Kotlin 1.4에서 기대할 사항에 관해 알려 드렸었습니다. 이제 출시가 다가옴에 따라 사용자가 일부 새로운 기능을 직접 사용해 볼 수 있는 테스트 버전을 제공하려 합니다.

이 글에서는 1.4-M1에 제공되는 다음의 새로운 기능 및 주요 개선 사항을 주요 내용으로 소개합니다.

• 더 강력하고 새로운 유형 추론 알고리즘이 기본적으로 활성화됩니다.
• 이제 final 멤버 함수에서 Contracts를 사용할 수 있습니다.
• Kotlin/JVM 컴파일러가 Java 8 이후 버전 대상의 바이트코드에서 유형 어노테이션을 생성합니다.
• Kotlin/JS용 백엔드가 새로 추가되어, 아티팩트 결과가 크게 개선됩니다.
• 표준 라이브러리의 혁신적인 변경 사항: 사용 중단 주기를 종료하고 일부 추가적 부분을 사용 중단했습니다.

전체 변경 목록은 변경 로그에서 확인할 수 있습니다. 언제나 그렇듯이 외부 기여자들께 진심으로 감사의 말씀을 전합니다.

여러분들이 테스트 버전을 사용해 보시기를 적극 권장하며 이슈 트래커에서 의견을 남겨주시면 감사하겠습니다.

더 강력해진 유형 추론 알고리즘

Kotlin 1.4는 더 강력해진 새로운 유형 추론 알고리즘을 사용합니다. Kotlin 1.3에서는 이 새로운 알고리즘을 사용하기 위해 컴파일러 옵션을 지정해야 했지만 이제는 기본적으로 사용 설정됩니다. 새 알고리즘에서 수정된 문제의 전체 목록은 YouTrack에서 확인하실 수 있습니다. 이 블로그 게시물에서는 가장 눈에 띄는 개선 사항 중 일부를 주요 내용으로 소개하겠습니다.

Kotlin 함수 및 인터페이스에 대한 SAM 변환

하나의 “단일 추상 메소드”가 있는 인터페이스가 예상될 때 SAM 변환을 통해 람다를 전달할 수 있습니다. 이전에는 Kotlin의 Java 메소드 및 Java 인터페이스를 작업할 때만 SAM 변환을 적용할 수 있었지만 이제 Kotlin 함수 및 인터페이스에서도 SAM 변환을 사용할 수 있습니다.

Kotlin은 Kotlin 인터페이스에 대한 SAM 변환을 지원합니다. 단, Java에서와 달리 함수 인터페이스를 명시적으로 표시해야 합니다. 다음과 같이 fun 키워드로 인터페이스를 표시한 후 인터페이스가 매개변수로 예상될 때마다 람다를 인수로 전달할 수 있습니다.

fun interface Action {
    fun run()
}

fun runAction(a: Action) = a.run()

fun main() {
    runAction {
        println("Hello, Kotlin 1.4!")
    }
}

이에 대한 자세한 내용은 이전 블로그 글에서 확인할 수 있습니다.

사실 Kotlin은 처음부터 Java 인터페이스에 대한 SAM 변환을 지원했지만 지원되지 않는 한 가지 경우가 있었기 때문에 기존 Java 라이브러리로 작업할 때 성가실 때가 때때로 있었습니다. 2개의 SAM 인터페이스를 매개변수로 사용하는 Java 메소드를 호출한 경우 두 인수는 모두 람다이거나 일반 객체여야 합니다. 즉, 하나의 인수를 람다로 전달하고 다른 인수를 객체로 전달할 수 없었습니다. 새로운 알고리즘에서는 이 문제를 해결하여, 어떠한 경우에도 SAM 인터페이스 대신 람다를 전달할 수 있으며 이는 여러분들이 자연스럽게 작동할 것이라고 기대하는 방식일 것입니다.

다양한 사용 사례에서 자동으로 유형 추론

새로운 추론 알고리즘은 예전 추론에서 사용자가 명시적으로 유형을 지정해야 했던 다양한 사례에서 유형을 추론합니다. 예를 들어 다음 예시에서 람다 매개변수 it의 유형은 String?으로 올바르게 추론됩니다.

//sampleStart
val rulesMap: Map<String, (String?) -> Boolean> = mapOf(
    "weak" to { it != null },
    "medium" to { !it.isNullOrBlank() },
    "strong" to { it != null && "^[a-zA-Z0-9]+$".toRegex().matches(it) }
)
//sampleEnd

fun main() {
    println(rulesMap.getValue("weak")("abc!"))
    println(rulesMap.getValue("strong")("abc"))
    println(rulesMap.getValue("strong")("abc!"))
}

Kotlin 1.3에서는 명시적인 람다 매개변수를 삽입하거나 to를 명시적인 제네릭 인수가 있는 Pair 생성자로 교체해야 추론되었습니다.

람다의 마지막 표현식을 위한 스마트 형 변환 (Smart casts)

Kotlin 1.3에서 람다 내부의 마지막 표현식은 기대 유형을 지정하지 않으면 스마트 형 변환이 되지 않습니다. 따라서 다음 예시에서 Kotlin 1.3은 String?을 result 변수의 유형으로 추론합니다.

val result = run {
    var str = currentValue()
    if (str == null) {
        str = "test"
    }
    str // the Kotlin compiler knows that str is not null here
}
// The type of 'result' is String? Kotlin 1.3의 경우 및 Kotlin 1.4의 String

Kotlin 1.4에서는 새로운 추론 알고리즘 덕분에 람다 내부의 마지막 표현식이 스마트 형 변환되고 이 더 정확한 새 유형이 결과 람다 유형을 추론하는 데 사용됩니다. 따라서 result 변수의 유형은 String이 됩니다.

Kotlin 1.3에서는 이러한 경우 형 변환이 작동하도록 명시적 형 변환(!! 또는 as String과 같은 형 변환)을 종종 추가해야 했지만 이제 이러한 형 변환이 필요 없어졌습니다.

호출 가능한 참조에 대한 스마트 형 변환

Kotlin 1.3에서는 스마트 형 변환 유형의 멤버 참조에 액세스할 수 없었습니다. 이제 다음을 수행할 수 있습니다.

sealed class Animal
class Cat : Animal() {
    fun meow() {
        println("meow")
    }
}

class Dog : Animal() {
    fun woof() {
        println("woof")
    }
}

//sampleStart
fun perform(animal: Animal) {
    val kFunction: KFunction<*> = when (animal) {
        is Cat -> animal::meow
        is Dog -> animal::woof
    }
    kFunction.call()
}
//sampleEnd

fun main() {
    perform(Cat())
}

동물 변수가 특정 유형, Cat 및 Dog로 스마트 형 변환되면 다른 멤버 참조인 animal::meow 및 animal::woof를 사용할 수 있습니다. 그리고 유형 검사가 끝나면 하위 유형에 해당하는 멤버 참조에 액세스할 수 있습니다.

호출 가능한 참조에 대한 추론 향상

기본 인수값을 가진 함수에 대한 호출 가능한 참조를 더 편리하게 사용할 수 있게 되었습니다. 예를 들어 다음 foo 함수에 대해 호출 가능한 참조는 하나의 Int 인수를 사용하거나 인수를 사용하지 않는 것으로 해석할 수 있습니다.

fun foo(i: Int = 0): String = "$i!"

fun apply1(func: () -> String): String = func()
fun apply2(func: (Int) -> String): String = func(42)

fun main() {
    println(apply1(::foo))
    println(apply2(::foo))
}

위임된 속성에 대한 추론 향상

위임된 속성의 유형은 by 키워드를 따르는 위임 표현식을 분석하는 동안에는 고려되지 않았습니다. 예를 들어 다음 코드는 이전에 컴파일되지 않았지만 이제 컴파일러가 old 및 new 매개변수의 유형을 String?으로 올바르게 추론합니다.

import kotlin.properties.Delegates

fun main() {
    var prop: String? by Delegates.observable(null) { p, old, new ->
        println("$old → $new")
    }
    prop = "abc"
    prop = "xyz"
}

언어 관련 변경 내용

다음과 같은 대부분의 언어 변경 내용은 이전 블로그 글에서 설명했습니다.

• Kotlin 클래스의 SAM 변환
• 명명된 인수 및 포지셔널 인수의 혼합
• 최적화된 위임된 속성
• Trailing Commas
• when 내의 break 및 continue
• 꼬리 재귀적(tail-recursive) 함수의 변경

이 글에서는 소소한 몇가지 개선 사항을 중점적으로 소개하겠습니다.

Contracts 지원

사용자 지정 contracts를 정의하는 구문은 여전히 실험적 상태이지만 contracts가 도움이 될 수 있는 몇가지 새로운 사례를 지원해 왔습니다.

이제는 구체화된 제네릭 유형 매개변수를 사용하여 contract를 정의할 수 있습니다. 예를 들어 assertIsInstance 함수에 대해 다음 contract를 구현할 수 있습니다.

@OptIn(ExperimentalContracts::class)
inline fun <reified T> assertIsInstance(value: Any?) {
    contract {
        returns() implies (value is T)
    }

    assertTrue(value is T)
}

T 유형 매개변수가 구체화되었으므로 함수 본문에서 해당 유형을 확인할 수 있습니다. 이는 이제 contract 내에서도 가능합니다. 어설션 메시지가 있는 유사한 함수는 추후 kotlin.test 라이브러리에 추가될 예정입니다.

또한 final 멤버에 대한 사용자 지정 contract도 정의할 수 있습니다. 이전에는 계층 구조의 일부 멤버에 대한 contract을 정의하면 해당 contract의 계층 구조를 암시하게 되어, 멤버 함수에 대한 계약을 정의하는 것이 완전히 금지되었고 이 문제에 관해서는 여전히 설계와 논의가 진행 중입니다. 그러나 멤버 함수가 final이고 다른 함수를 재정의하지 않으면 해당 함수에 대한 contract을 정의해도 안전합니다.

표준 라이브러리 변경 내용

사용 중지된 실험적 코루틴 제외

kotlin.coroutines.experimental API는 kotlin.coroutines를 우선함에 따라 1.3.0에서 중단되었습니다. 1.4-M1에서는 kotlin.coroutines.experimental을 표준 라이브러리에서 제거하여 사용 중단 주기를 종료하려 합니다. 여전히 JVM에서 이 API를 사용하는 사용자를 위해서는 모든 실험적 코루틴 API에 호환성 아티팩트 kotlin-coroutines-experimental-compat.jar을 제공합니다. 이 아티팩트는 Maven에 게시되고, 표준 라이브러리와 별도로 Kotlin 배포에 포함될 예정입니다. 지금은 1.4-M1 아티팩트와 함께 bintray 저장소에 게시되어 있습니다.

사용 중단된 mod 연산자 제거

또 하나의 사용 중단된 함수는 나누기 연산 후 나머지를 계산하는 숫자 유형의 mod 연산자입니다. 이 함수는 Kotlin 1.1에서 rem() 함수로 교체되었다가 이제 표준 라이브러리에서 완전히 제거되었습니다.

부동 소수점 유형에서 Byte 및 Short로의 변환 사용 중지

표준 라이브러리에는 부동 소수점 숫자를 정수 유형으로 변환하는 함수인 toInt(), toShort(), toByte()가 있습니다. 부동 소수점 숫자를 Short 및 Byte로 변환하면 값 범위가 좁고 가변 크기가 작아 예기치 않은 결과가 발생할 수 있습니다. 이러한 문제를 피하기 위해 1.4-M1부터는 Double과 Float에서 함수 toShort()와 toByte()를 더 이상 사용하지 않습니다. 여전히 부동 소수점 숫자를 Byte나 Short로 변환해야 하는 경우, Int로 변환한 다음 대상 유형으로 변환하는 2단계 변환을 사용하세요.

공통 리플렉션 API

공통 리플렉션 API가 수정되었습니다. 이제 이 API에 3가지 대상 플랫폼(JVM, JS, Native) 모두에서 사용할 수 있는 멤버만 포함되기 때문에 동일한 코드가 어느 플랫폼에서나 작동할 것임을 확신할 수 있습니다.

use() 및 시간 측정 함수에 대한 새로운 Contract

표준 라이브러리에서 contracts의 활용 범위가 넓어집니다. 1.4-M1에서는 use() 함수와 시간 측정 함수 measureTimeMillis() 및 measureNanoTime()에 대한 코드 블록의 단일 실행을 선언하는 contract이 추가되었습니다.

Kotlin 리플렉션용 Proguard 구성

1.4-M1부터 kotlin-reflect.jar에 Kotlin Reflection용 Proguard/R8 구성이 포함됩니다. 그 덕에 R8 또는 Proguard를 사용하는 대부분의 Android 프로젝트에서 추가 구성 없이 kotlin-reflect를 사용할 수 있습니다. 즉, 이제 kotlin-reflect 내부에 Proguard 규칙을 복사하여 붙여넣을 필요가 없습니다. 단, 여전히 반영하려는 API는 모두 명시적으로 나열해야 합니다.

Kotlin/JVM

1.3.70 버전부터 Kotlin은 JVM 바이트코드(대상 버전 1.8 이후)에서 유형 어노테이션을 생성할 수 있으므로 이러한 주석을 런타임에서 사용할 수 있게 되었습니다. 이 기능은 일부 기존 Java 라이브러리를 훨씬 쉽게 사용할 수 있도록 돕고 새 라이브러리를 작성하는 사용자에게 강력한 지원을 제공하기 때문에 커뮤니티에서 한동안 요청되어 왔습니다.

다음 예시에서 String 유형에 관한 @Foo 어노테이션은 바이트코드로 출력된 다음 라이브러리 코드에서 사용될 수 있습니다.

@Target(AnnotationTarget.TYPE)
annotation class Foo

class A {
    fun foo(): @Foo String = "OK"
}

유형 어노테이션을 바이트코드로 출력하는 방법에 관한 자세한 내용은 Kotlin 1.3.70 릴리스 관련 블로그 글에서 해당 섹션을 참조하세요.

Kotlin/JS

Kotlin/JS의 경우, 이번 버전에서 Gradle DSL이 몇가지 변경되었으며, 최적화 및 새로운 기능을 지원하는 새로운 IR 컴파일러 백엔드가 최초로 포함되었습니다.

Gradle DSL 변경 내용

kotlin.js 및 multiplatform Gradle 플러그인에 중요한 설정이 새로 도입되었습니다. build.gradle.kts 파일의 대상 블록 내에서 이제 produceExecutable() 설정을 사용할 수 있으며 이 설정은 빌드 중에 .js 아티팩트를 생성하려는 경우 필요합니다.

kotlin {
    target {
        useCommonJs()

        produceExecutable()
        
        browser {}
    }
}

Kotlin/JS 라이브러리를 작성할 때 produceExecutable()을 생략할 수 있습니다. 새로운 IR 컴파일러 백엔드를 사용할 때(이에 대한 자세한 내용은 아래 참조) 이 설정을 생략하면 실행 가능한 JS 파일이 생성되지 않으며 이에 따라 빌드 프로세스가 더 빨리 실행됩니다. klib 파일은 build/libs 폴더에 생성되며 다른 Kotlin/JS 프로젝트에서 사용하거나 동일한 프로젝트의 종속 요소로 사용할 수 있습니다. produceExecutable()을 명시적으로 지정하지 않으면 이 동작이 기본적으로 발생합니다.

produceExecutable()을 사용하면 자체 진입점이 있거나 JavaScript 라이브러리로서 JavaScript 에코시스템에서 실행 가능한 코드가 생성됩니다. 이렇게 생성된 실제 JavaScript 파일은 노드 인터프리터에서 실행되거나 HTML 페이지에 포함되거나 브라우저에서 실행되거나 JavaScript 프로젝트의 종속 요소로 사용될 수 있습니다.

단, 새로운 IR 컴파일러 백엔드를 대상으로 할 때(자세한 내용은 아래 참조) produceExecutable()은 항상 대상당 하나의 독립실행형 .js 파일을 생성합니다. 지금은 생성된 여러 아티팩트 간 코드 중복 제거 또는 코드 분할이 지원되지 않습니다. produceExecutable()의 이 동작은 후속 이정표에서 변경될 예정입니다. 옵션의 이름도 추후 변경될 수 있습니다.

새로운 백엔드

Kotlin 1.4-M1은 Kotlin/JS 대상에 대한 새로운 IR 컴파일러 백엔드를 포함하는 첫 번째 버전입니다. 이 백엔드는 크게 개선된 최적화의 기반이자, Kotlin/JS가 JavaScript 및 TypeScript와 상호작용하는 방식이 변한 것을 명확히 보여주는 요소입니다. 아래에 강조 표시된 기능은 모두 새로운 IR 컴파일러 백엔드에 관한 것입니다. 이 백엔드는 아직 기본적으로 활성화되어 있지는 않지만 프로젝트에서 사용해보고 새 백엔드에서 라이브러리 준비를 시작해볼 것을 권장합니다. 물론 여러분의 의견도 보내주시고 어떤 문제든 발생하면 로그에 기록해 주시기 바랍니다.

새로운 백엔드 사용 방법

새 백엔드 사용하려면 gradle.properties 파일에서 다음 플래그를 설정하세요.

kotlin.js.compiler=ir

IR 컴파일러 백엔드 및 기본 백엔드에 대한 라이브러리를 생성해야 하는 경우, 이 플래그를 both로 설정할 수 있습니다. 플래그 기능에 관한 자세한 내용은 이 블로그 글의 “both 모드” 섹션에 나와 있습니다. 새 컴파일러 백엔드와 기본 컴파일러 백엔드는 2진 호환되지 않으므로 플래그가 필요합니다.

2진 호환되지 않음

새로운 IR 컴파일러 백엔드의 주요 변경 내용은 기본 백엔드와 2진 호환되지 않는다는 것입니다. Kotlin/JS의 두 백엔드 간 호환성이 없으면 새로운 IR 컴파일러 백엔드로 만든 라이브러리를 기본 백엔드에서 사용할 수 없으며 그 반대도 마찬가지입니다.

프로젝트에서 IR 컴파일러 백엔드를 사용하려면 모든 Kotlin 종속 요소를 이 새로운 백엔드가 지원되는 버전으로 업데이트해야 합니다. Kotlin 1.4-M1용으로 JetBrains에서 게시한 Kotlin/JS 대상 라이브러리에는 이미 새로운 IR 컴파일러 백엔드와 함께 사용하는 데 필요한 모든 아티팩트가 포함되어 있습니다. 이러한 라이브러리를 사용하는 경우 Gradle에서 올바른 아티팩트를 자동으로 선택합니다(즉, IR별 좌표를 지정할 필요가 없음). 단, kotlin-wrappers와 같은 일부 라이브러리는 기본 백엔드의 특정 특성에 의존하기 때문에 새 IR 컴파일러 백엔드 사용 시 다소 문제가 있을 수 있습니다. 저희 역시 이를 인지하고 있으며 향후 이 기능을 개선하기 위해 작업하고 있습니다.

현재 컴파일러 백엔드 및 새로운 IR 컴파일러 백엔드와의 호환성을 제공하려는 라이브러리 작성자 인 경우 이 블로그 글의 “both 모드” 섹션을 추가로 확인해주세요.

다음 섹션에서는 새 컴파일러에서 기대할 수 있는 몇가지 이점과 차이점에 관해 자세히 살펴보겠습니다.

최적화된 DCE

새로운 IR 컴파일러 백엔드는 기본 백엔드보다 훨씬 더 적극적인 최적화를 수행할 수 있습니다. 생성된 코드는 정적 분석기와 함께 더 잘 작동하며 Google의 Closure Compiler를 통해 새로운 IR 컴파일러 백엔드에서 생성된 코드를 실행하고 고급 모드 최적화를 사용할 수도 있습니다(단, Kotlin/JS Gradle 플러그인은 이에 대한 특정 지원을 제공하지 않음).

여기서 가장 눈에 띄는 변화는 생성된 아티팩트의 코드 크기입니다. 불필요한 코드(dead code) 제거 방법이 개선된 덕에 아티팩트 크기가 크게 줄었습니다. 예를 들어 “Hello, World!” Kotlin/JS 프로그램의 크기는 1.7KiB 미만이 됩니다. kotlinx.coroutines를 사용하는 이 예시 프로젝트처럼 더 복잡한 (데모) 프로젝트인 경우 크기가 대폭 변하였으며 이는 다음에서 명확히 확인됩니다.

아직 와닿지 않으신다면 직접 사용해 보세요. DCE 및 번들 작업은 Kotlin 1.4-M1의 두 백엔드에서 기본적으로 사용할 수 있습니다.

선언을 JavaScript로 내보내기

IR 컴파일러 백엔드를 사용할 때 public으로 표시된 선언이 더 이상 자동으로 내보내기 되지 않습니다(이름이 엉킨 버전이라도 마찬가지). IR 컴파일러의 closed-world 모델에서는 내보낸 선언에 특별히 주석이 달린 것으로 가정하기 때문입니다. 이는 위에서 언급된 기능처럼 최적화에 도움이 되는 요소 중 하나입니다.

JavaScript 또는 TypeScript 외부에서 최상위 선언을 사용할 수 있게 하려면 @JsExport 어노테이션을 사용하세요. 다음 예시에서는 KotlinGreeter(해당 메소드 포함) 및 farewell()을 JavaScript에서 사용 가능하게 하면서 secretGreeting()을 Kotlin 전용으로 유지합니다.

package blogpost

@JsExport
class KotlinGreeter(private val who: String) {
    fun greet() = "Hello, $who!"
}

@JsExport
fun farewell(who: String) = "Bye, $who!"

fun secretGreeting(who: String) = "Sup, $who!" // only from Kotlin!

테스트 버전: TypeScript 정의

야심차게 선보이는 Kotlin/JS IR 컴파일러의 또 다른 기능은 Kotlin 코드에서 TypeScript 정의를 생성하는 것입니다. 이러한 정의는 자동 완성 기능을 제공하고 정적 분석기를 지원하며 JS 및 TS 프로젝트에 Kotlin 코드를 쉽게 포함시키기 위해 하이브리드 앱에서 작업할 때 JavaScript 도구 및 IDE에서 사용됩니다.

produceExecutable()을 사용하도록 구성된 프로젝트에서 @JsExport(위 참조)로 표시된 최상위 선언의 경우 TypeScript 정의가 있는 .d.ts 파일이 생성됩니다. 위의 조각은 다음과 같이 표시됩니다.

// [...]
namespace blogpost {
    class KotlinGreeter {
        constructor(who: string)
        greet(): string
    }
    function farewell(who: string): string
}
// [...]

Kotlin 1.4-M1에서 이러한 선언은 웹 패키지되지 않은 해당 JavaScript 코드와 함께 build/js/packages/<package_name>/kotlin에서 찾을 수 있습니다. 단, 이는 테스트 버전일 뿐이므로 현재 기본적으로 distributions 폴더에 추가되어 있지 않습니다. 이 동작은 향후 변경될 예정입니다.

Both 모드

라이브러리 관리자가 새로운 IR 컴파일러 백엔드로 쉽게 이동할 수 있도록 gradle.properties의 kotlin.js.compiler 플래그에 대한 추가 설정이 도입되었습니다.

kotlin.js.compiler=both

both 모드에서는 소스에서 라이브러리를 빌드할 때 IR 컴파일러 백엔드와 기본 컴파일러 백엔드가 모두 사용됩니다(모드 이름이 both인 이유). 이는 Kotlin IR이 있는 klib 파일과 기본 컴파일러의 js 파일이 모두 생성됨을 의미합니다. 동일한 Maven 좌표로 게시되면 Gradle은 사용 사례에 따라 올바른 아티팩트를 자동으로 선택합니다(이전 컴파일러의 경우 js, 새 컴파일러의 경우 klib). 즉, 이미 Kotlin 1.4-M1로 업그레이드되고 두 컴파일러 백엔드 중 하나를 사용하는 프로젝트에서 라이브러리를 새로운 IR 컴파일러 백엔드로 컴파일하고 게시할 수 있습니다. 따라서 프로젝트를 1.4-M1로 업그레이드한 경우에도 여전히 기본 백엔드를 사용하는 사용자의 환경을 변함 없이 유지할 수 있습니다.

그러나 종속 요소 및 현재 프로젝트가 both 모드로 빌드될 때 IDE가 라이브러리 참조를 올바르게 해석하지 못하는 문제가 여전히 있습니다. 저희도 이를 인지하고 있으며 곧 해결하겠습니다.

Kotlin/Native

Objective-C 제네릭 기본 지원

Kotlin의 이전 버전에서는 Objective-C 상호 운용성에 제네릭에 대한 실험적 지원을 제공했습니다. 이때 Kotlin 코드에서 제네릭으로 프레임워크 헤더를 생성하려면 -Xobjc-generics 컴파일러 옵션을 사용해야 했습니다. 이제 1.4-M1에서는 이 동작이 기본값이 됩니다. 경우에 따라 이 때문에 Kotlin 프레임워크를 호출하는 기존 Objective-C 또는 Swift 코드가 손상될 수 있습니다. 제네릭 없이 프레임워크 헤더를 작성하려면 -Xno-objc-generics 컴파일러 옵션을 추가하세요.

binaries.framework {
     freeCompilerArgs += "-Xno-objc-generics"
}

문서에 나열된 모든 세부 사항 및 제한 사항은 여전히 ​​유효합니다.

Objective-C/Swift 상호 운용성의 예외 처리 변경

1.4에서는 예외 해석 방식과 관련하여 Kotlin에서 생성된 Swift API가 약간 변경됩니다. Kotlin과 Swift의 오류 처리 방식에는 근본적인 차이가 있습니다. 모든 Kotlin 예외는 확인되지 않는 반면 Swift는 오류만 확인합니다. 따라서 Swift 코드가 예상되는 예외를 인식하게 하려면 Kotlin 함수에 잠재적 예외 클래스 목록을 명시하는 @Throws 어노테이션을 표시해야 합니다.
Swift 또는 Objective-C 프레임워크로 컴파일할 때 @Throws 어노테이션을 포함하거나 상속하는 함수는 Objective-C에서 NSError* 생성 메소드로, Swift에서 throws 메소드로 표시됩니다.
이전에 RuntimeException 및 Error 이외의 예외는 NSError로 전달되었습니다. 1.4-M1에서는 이 동작이 변경되어, 이제 NSError는 예외가 @Throws 어노테이션(또는 해당 하위 클래스)의 매개변수로 지정된 클래스의 인스턴스인 경우에만 던져집니다. Swift/Objective-C에 도달하는 기타 Kotlin 예외는 처리되지 않은 것으로 간주되어 프로그램이 종료됩니다.

성능 개선 사항

JetBrains는 Kotlin/Native 컴파일 및 실행의 전반적인 성능을 향상시키기 위해 계속 노력하고 있습니다. 1.4-M1에서는 일부 벤치마크 기준 최대 2배 더 빠르게 작동하는 새로운 객체 할당자를 제공합니다. 현재 새 할당자는 실험적이며 기본적으로 사용되지 않습니다. 이 할당자로 전환하려면 -Xallocator=mimalloc 컴파일러 옵션을 사용하면 됩니다.

호환성

Kotlin 1.4는 일부 사례에서 1.3과 역호환되지 않습니다. 이러한 사례는 언어 위원회에서 모두 신중하게 검토한 후 “호환성 가이드”에 목록을 나열합니다(이 양식과 유사). 현재 이 목록은 YouTrack에서 확인할 수 있습니다.

오버로드 해결 규칙이 약간 변경될 수 있습니다. 이름은 동일하지만 시그너처가 다른 여러 함수가 있는 경우 Kotlin 1.4에서 호출되는 함수가 Kotlin 1.3에서 선택된 함수와 다를 수 있습니다. 그러나 이는 일부 코너 케이스에서만 발생하며 실제로는 거의 발생하지 않을 것으로 예상됩니다. 또한 실제로 오버로드된 함수는 유사하게 작동하고 결국 서로를 호출한다고 가정하므로 이러한 변경이 프로그램 동작에 영향을 미치지 않을 것입니다. 그러나 다양한 수준의 제네릭과 수많은 오버로드가 있는 까다로운 코드를 작성하는 경우 주의해 주세요. 이러한 종류의 모든 사례는 위에서 언급한 호환성 가이드에 나열될 예정입니다.

사전 릴리스 노트

이전 버전과의 호환성은 사전 릴리스 버전에는 적용되지 않습니다. 기능 및 API는 후속 릴리스에서 변경될 수 있습니다. 최종 RC에 도달하면 사전 릴리스 버전에서 생성된 모든 2진 파일이 컴파일러에서 사용 금지되며 1.4Mx로 컴파일된 모든 파일을 다시 컴파일해야 합니다.

체험 방법

언제나처럼 play.kotl.in에서 Kotlin을 온라인에서 사용해볼 수 있습니다.

IntelliJ IDEA 및 Android Studio에서 Kotlin 플러그인을 1.4-M1 버전으로 업데이트하세요. 업데이트 방법 보기

테스트 버전을 설치하기 전에 생성된 기존 프로젝트를 작업하려면 Gradle 또는 Maven에서 테스트 버전에 대한 빌드를 구성해야 합니다.

명령줄 컴파일러는 Github 릴리스 페이지에서 다운로드할 수 있습니다.

이 릴리스와 함께 게시된 다음 버전의 라이브러리를 사용할 수 있습니다.

• kotlinx.atomicfu 버전: 0.14.2-1.4-M1
• kotlinx.coroutines 버전: 1.3.5-1.4-M1
• kotlinx.serialization 버전: 0.20.0-1.4-M1
• ktor 버전: 1.3.2-1.4-M1

릴리스에 관한 세부 정보 및 호환되는 라이브러리 목록은 여기에 나와 있습니다.

의견을 공유해 주세요

버그를 발견하신 경우 이슈 트래커 YouTrack으로 보고해 주시면 대단히 감사하겠습니다. 저희는 최종 릴리스 전에 모든 중요한 문제를 해결하려고 노력하고 있으므로 다음 Kotlin 릴리스까지 문제가 해결되기를 기다리실 필요가 없습니다.

궁금한 점이 있거나 토론에 참여하고 싶은 경우 Kotlin Slack의 #eap 채널에 언제든지 참여하세요(여기에서 초대받기). 이 채널에서 새로운 테스트 버전 빌드에 대한 알림을 받을 수도 있습니다.

Let’s Kotlin!

외부 기여자

Koclin-reflect에 Proguard 구성을 포함시키는 데 기여해주신 Zac Sweers께 특히 감사의 말씀을 전합니다.

이 릴리스에 포함된 pull 요청을 제공해 주신 모든 외부 기여자분들도 고맙습니다.

• Steven Schäfer
• Toshiaki Kameyama
• pyos
• Mads Ager
• Mark Punzalan
• Juan Chen
• Kristoffer Andersen
• Alfredo Delli Bovi
• Jinseong Jeon
• Jonathan Leitschuh
• Sebastian Schuberth
• Ivan Gavrilovic
• David Schreiber-Ranner
• Miguel Serra
• Alex Chmyr
• Fleshgrinder
• Aleksey Kladov
• Will Boyd
• Dominic Fischer
• Kenji Tomita
• Stéphane Nicolas
• Tillmann Berg
• Kevin Bierhoff
• Tsvetan

이 게시물은 Sebastian Aigner의 Kotlin 1.4-M1 Released를 번역한 글입니다.

Subscribe to JetBrains Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

이 양식을 제출함으로써 본인은 JetBrains s.r.o.("JetBrains"가 본인의 이름, 이메일 주소 및 위치 데이터를 사용하여 상업적 커뮤니케이션을 포함한 뉴스레터를 보내고 이러한 목적으로 개인 데이터를 처리할 수 있음에 동의합니다. 본인은 JetBrains가 JetBrains 개인정보보호정책에 따라 이러한 목적으로 제3자 서비스를 사용하여 해당 데이터를 처리할 수 있음에 동의합니다. 본인은 내 프로필에서 언제든지 이 동의를 철회할 수 있음을 이해합니다. 또한 각 이메일에는 수신 거부 링크가 포함됩니다.

Submit

감사합니다!