IDE 지원
Kotlin 2.1.0-RC를 지원하는 Kotlin 플러그인은 최신 IntelliJ IDEA와 Android Studio에 번들로 포함되어 있습니다. IDE에서 Kotlin 플러그인을 별도로 업데이트할 필요는 없습니다. 프로젝트의 빌드 스크립트에서 Kotlin 버전을 2.1.0-RC로 변경하기만 하면 됩니다.
자세한 내용은 “새 릴리스로 업데이트”를 참조하세요.
언어
K2 컴파일러가 포함된 Kotlin 2.0.0 릴리스 이후, JetBrains의 Kotlin 팀은 새로운 기능을 통해 언어를 개선하는 데 집중하고 있습니다. 이번 릴리스에서는 여러 새로운 언어 디자인 기능을 발표하게 되어 기쁩니다.
이 기능들은 미리보기로 제공되며, 사용해보고 피드백을 공유해 주시기를 권장합니다.
• 주제가 있는 when에서의 Guard 조건. 자세한 내용은 KEEP 문서를 참조하세요.
• 비지역적 break와 continue
• 다중 달러 인터폴레이션: 문자열 리터럴에서 $ 처리 개선. 자세한 내용은 KEEP 문서를 참조하세요.
모든 기능은 K2 모드가 활성화된 최신 IntelliJ IDEA EAP 버전에서 IDE 지원을 받습니다.
자세한 내용은 IntelliJ IDEA 2024.3 EAP 블로그 게시물에서 확인하세요.
Kotlin 언어 디자인 기능과 제안의 전체 목록을 참조하세요.
비지역적 break와 continue
Kotlin 2.1.0-RC는 새로운 기능인 비지역적 break와 continue의 미리보기를 제공합니다. 이를 통해 인라인 함수 작업 시 보일러플레이트 코드를 줄이고 유연성을 높입니다.
이전에는 프로젝트에서 비지역적 반환만 사용할 수 있었습니다. 이제 Kotlin은 break와 continue 점프 표현식도 비지역적으로 지원합니다. 즉, 루프를 둘러싸는 인라인 함수에 인수로 전달된 람다 내에서도 이를 사용할 수 있습니다.
이전 코드
fun processList(elements: List<Int>): Boolean {
for (element in elements) {
val variable = element.nullableMethod()
if (variable == null) {
log.warning("Element is null or invalid, continuing...")
continue
}
if (variable == 0) return true
}
return false
}
변경 후 코드
fun processList(elements: List<Int>): Boolean {
for (element in elements) {
val variable = element.nullableMethod() ?: run {
log.warning("Element is null or invalid, continuing...")
continue
}
if (variable == 0) return true
}
return false
}
이 기능은 현재 실험 단계입니다. 프로젝트에서 사용해 보려면 명령줄에 -Xnon-local-break-continue 컴파일러 옵션을 사용하세요.
kotlinc -Xnon-local-break-continue main.kt
또는 Gradle 빌드 파일의 compilerOptions {} 블록에서 설정할 수 있습니다.
kotlin {
compilerOptions {
freeCompilerArgs.add("-Xnon-local-break-continue")
}
}
앞으로 이 기능을 안정화할 예정입니다. 비지역적 break와 continue 사용 시 문제가 발생하면 이슈 트래커에 보고해 주세요.
API 확장을 위한 옵트인 요구 지원
Kotlin 2.1.0-RC는 @SubclassOptInRequired 애노테이션을 도입하여, 사용자들이 실험적 인터페이스를 구현하거나 실험적 클래스를 확장하기 전에 명시적으로 옵트인을 요구할 수 있습니다.
이 기능은 API가 사용할 만큼 안정적이지만, 새 추상 함수를 추가하여 상속에 불안정할 수 있는 경우 유용합니다.
API 요소에 옵트인 요구를 추가하려면, @SubclassOptInRequired 애노테이션과 참조할 애노테이션 클래스를 사용하세요.
@RequiresOptIn(
level = RequiresOptIn.Level.WARNING,
message = "Interfaces in this library are experimental"
)
annotation class UnstableApi()
@SubclassOptInRequired(UnstableApi::class)
interface CoreLibraryApi
이 예제에서, CoreLibraryApi 인터페이스는 사용자가 이를 구현하기 전에 옵트인을 요구합니다. 사용자는 아래와 같이 옵트인할 수 있습니다.
@OptIn(UnstableApi::class)
interface MyImplementation : CoreLibraryApi
@SubclassOptInRequired 애노테이션을 사용하여 옵트인을 요구할 때, 해당 요구 사항은 내부 또는 중첩 클래스에는 전파되지 않습니다.
실제 예로, kotlinx.coroutines 라이브러리의 SharedFlow 인터페이스에서 @SubclassOptInRequired 애노테이션을 사용하는 방법을 확인해 보세요.
제네릭 타입을 가진 함수의 오버로드 해상도 개선
이전에는 함수의 오버로드 중 일부가 제네릭 타입의 값 매개변수를 가지거나 동일한 위치에서 함수 타입을 가질 때, 해상도 동작이 일관되지 않은 경우가 있었습니다.
이로 인해 멤버 함수와 확장 함수의 오버로드 동작이 달라질 수 있었습니다. 예를 들어:
class KeyValueStore<K, V> {
fun store(key: K, value: V) {} // 1
fun store(key: K, lazyValue: () -> V) {} // 2
}
fun <K, V> KeyValueStore<K, V>.storeExtension(key: K, value: V) {} // 1
fun <K, V> KeyValueStore<K, V>.storeExtension(key: K, lazyValue: () -> V) {} // 2
fun test(kvs: KeyValueStore<String, Int>) {
// 멤버 함수
kvs.store("", 1) // 1로 해석
kvs.store("") { 1 } // 2로 해석
// 확장 함수
kvs.storeExtension("", 1) // 1로 해석
kvs.storeExtension("") { 1 } // 해석되지 않음
}
이 예제에서 KeyValueStore 클래스는 store() 함수에 두 가지 오버로드를 가지고 있으며, 하나는 제네릭 타입의 함수 매개변수를, 다른 하나는 람다 함수를 가집니다. 비슷하게, 확장 함수 storeExtension()에도 두 가지 오버로드가 있습니다.
이제 컴파일러가 특정 인수에서 얻은 정보를 바탕으로 람다 함수를 허용할 수 없는 경우 가능한 오버로드를 배제할 수 있도록 새로운 휴리스틱이 추가되었습니다. 이를 통해 멤버 함수와 확장 함수의 동작이 일관되게 되었으며, Kotlin 2.1.0-RC에서 기본으로 활성화되어 있습니다.
sealed 클래스와 함께 when 표현식의 철저성 검사 개선
이전 Kotlin 버전에서는 when 표현식의 타입 매개변수가 sealed 상위 클래스일 때, 모든 경우를 다루더라도 else 분기를 요구했습니다. Kotlin 2.1.0-RC에서는 이 문제가 해결되어 when 표현식이 더 간결하고 직관적이 되었습니다.
다음은 변경 사항을 보여주는 예제입니다.
sealed class Result
object Error : Result()
class Success(val value: String) : Result()
fun <T : Result> render(result: T) = when (result) {
Error -> "Error!"
is Success -> result.value
// else 분기가 필요하지 않음
}
Kotlin K2 컴파일러
Kotlin 2.1.0-RC 버전에서 K2 컴파일러는 컴파일러의 검사와 경고에 대한 유연성을 높였으며, kapt 플러그인에 대한 개선된 지원을 제공합니다.
추가 컴파일러 검사
Kotlin 2.1.0-RC에서 이제 K2 컴파일러에서 추가 검사를 활성화할 수 있습니다. 이 검사들은 필수적인 컴파일 요소는 아니지만, 다음과 같은 상황을 확인하는 데 유용할 수 있습니다:
| 체크 타입 | 코멘트 |
| REDUNDANT_NULLABLE | Boolean?? is used instead of Boolean? |
| PLATFORM_CLASS_MAPPED_TO_KOTLIN | java.lang.String is used instead of kotlin.String |
| ARRAY_EQUALITY_OPERATOR_CAN_BE_REPLACED_WITH_EQUALS | arrayOf("") == arrayOf("") is used instead of arrayOf("").contentEquals(arrayOf("")) |
| REDUNDANT_CALL_OF_CONVERSION_METHOD | 42.toInt() is used instead of 42 |
| USELESS_CALL_ON_NOT_NULL | "".orEmpty() is used instead of "" |
| REDUNDANT_SINGLE_EXPRESSION_STRING_TEMPLATE | "$string" is used instead of string |
| UNUSED_ANONYMOUS_PARAMETER | A parameter is passed in the lambda expression but never used |
| REDUNDANT_VISIBILITY_MODIFIER | public class Klass is used instead of class Klass |
| REDUNDANT_MODALITY_MODIFIER | final class Klass is used instead of class Klass |
| REDUNDANT_SETTER_PARAMETER_TYPE | set(value: Int) is used instead of set(value) |
| CAN_BE_VAL | var local = 0 is defined, but never reassigned, can be val local = 42 instead |
| ASSIGNED_VALUE_IS_NEVER_READ | val local = 42 is defined, but never used afterward in the code |
| UNUSED_VARIABLE | val local = 0 is defined, but never used in the code |
| REDUNDANT_RETURN_UNIT_TYPE | fun foo(): Unit {} is used instead of fun foo() {} |
| UNREACHABLE_CODE | Code statement is present, but can never been executed |
이 검사들은 기본적으로 비활성화되어 있습니다. 이를 활성화하려면 -Wextra 컴파일러 옵션을 사용하거나 Gradle 빌드 파일의 compilerOptions {} 블록에 extraWarnings 설정을 추가하세요:
kotlin {
compilerOptions {
extraWarnings.set(true)
}
}
글로벌 경고 억제
Kotlin 2.1.0-RC에서는 프로젝트 전체에서 특정 경고를 억제할 수 있는 기능이 추가되었습니다. 예를 들어, CAN_BE_VAL 경고를 억제하려면 다음과 같이 설정할 수 있습니다:
kotlin {
compilerOptions {
extraWarnings.set(true)
freeCompilerArgs.add("-Xsuppress-warning=CAN_BE_VAL")
}
}
이 새로운 컴파일러 옵션은 실험적 기능이며, 에러 억제는 허용되지 않습니다. 잘못된 경고 이름을 사용하면 컴파일 오류가 발생합니다.
개선된 K2 kapt 구현
K2 컴파일러용 kapt 플러그인(K2 kapt)은 현재 Alpha 단계이며, 기술 및 성능 문제를 완화하기 위해 내부 구현이 개선되었습니다. 향후 K2 kapt 구현이 기본값으로 활성화될 예정이며, 현재 gradle.properties 파일에 다음 플래그를 추가하여 수동으로 활성화할 수 있습니다:
kapt.use.k2=true
새로운 K2 kapt 구현이 안정화되기 전까지 피드백을 주시면 감사하겠습니다.
Kotlin 멀티플랫폼
Kotlin 2.1.0-RC는 Gradle과 관련된 기능을 개선하며, 멀티플랫폼 프로젝트의 컴파일러 옵션을 구성하기 위한 새로운 DSL을 안정화하고, Isolated Projects 기능의 프리뷰를 제공합니다.
멀티플랫폼 프로젝트에서 새로운 Gradle DSL로 컴파일러 옵션 안정화
Kotlin 2.0.0에서는 멀티플랫폼 프로젝트에서 컴파일러 옵션 구성을 단순화하기 위해 새로운 Experimental Gradle DSL을 도입했습니다. Kotlin 2.1.0-RC에서 이 DSL이 Stable로 승격되었습니다.
이 새로운 DSL을 통해 모든 타겟과 공통 소스 셋(예: commonMain)에 대해 확장 수준에서 컴파일러 옵션을 구성할 수 있고, 특정 타겟에 대해 타겟 수준에서도 설정할 수 있습니다.
kotlin {
compilerOptions {
// 모든 타겟과 공유 소스 셋에 대한 확장 수준의 공통 컴파일러 옵션
allWarningsAsErrors.set(true)
}
jvm {
compilerOptions {
// 이 타겟의 모든 컴파일에 대해 사용되는 JVM 타겟 수준의 컴파일러 옵션
noJdk.set(true)
}
}
}
Kotlin 컴파일러 옵션의 레벨
프로젝트 구성에는 세 가지 레벨이 있습니다. 가장 높은 수준은 확장 수준, 그다음은 타겟 수준, 마지막은 컴파일 단위(일반적으로 컴파일 작업)입니다.
• 확장 수준의 컴파일러 옵션은 타겟 수준 및 공유 소스 셋의 기본값으로 사용됩니다.
• 타겟 수준의 컴파일러 옵션은 컴파일 단위 작업(예: compileKotlinJvm, compileTestKotlinJvm)의 기본값으로 사용됩니다.
• 컴파일 단위 작업 수준의 설정은 관련된 상위 수준의 설정을 재정의할 수 있습니다.
프로젝트를 구성할 때, 이전 방식으로 컴파일러 옵션을 설정하는 일부 방법은 더 이상 지원되지 않음을 유의하세요.
Kotlin 멀티플랫폼에서 Gradle의 Isolated Projects 기능 미리보기
이 기능은 실험적이며, Gradle 8.10 버전에서만 평가 목적으로 사용할 수 있는 Pre-alpha 상태입니다. 기능은 언제든지 변경되거나 삭제될 수 있으니, 피드백은 YouTrack을 통해 부탁드립니다. 이 기능을 사용하려면 옵트인이 필요합니다.
Gradle의 Isolated Projects 기능은 개별 Gradle 프로젝트를 서로 격리하여 빌드 성능을 개선합니다. 각 프로젝트의 빌드 로직은 다른 프로젝트의 변경 가능한 상태에 직접 접근할 수 없으므로 병렬로 안전하게 실행할 수 있습니다. 이를 지원하기 위해 Kotlin Gradle 플러그인 모델에 일부 변경 사항을 적용했습니다.
Isolated Projects 기능을 활성화하는 방법에는 두 가지가 있습니다:
1. Isolated Projects 비활성화 상태에서 새로운 모델과의 호환성 확인: 프로젝트의 build.gradle.kts 파일에 다음 속성을 추가하여 새로운 Kotlin Gradle 플러그인 모델과의 호환성을 확인할 수 있습니다.
kotlin.kmp.isolated-projects.support=enable
2. Isolated Projects 기능을 활성화하여 테스트: Gradle에서 Isolated Projects 기능을 활성화하면 Kotlin Gradle 플러그인의 새로운 모델이 자동으로 구성됩니다. 이 경우, 프로젝트에 Gradle 속성을 추가할 필요가 없습니다.
이 기능에 대한 피드백을 부탁드립니다.
Kotlin Native
Kotlin 2.1.0-RC는 iosArm64 타겟 지원의 업그레이드, cinterop 캐싱 프로세스 개선 및 기타 업데이트를 포함하고 있습니다.
iosArm64가 Tier 1로 승격됨
Kotlin Multiplatform 개발에 중요한 iosArm64 타겟이 Tier 1로 승격되었습니다. 이는 Kotlin/Native 컴파일러에서 가장 높은 수준의 지원을 의미합니다.
이제 이 타겟은 CI에서 정기적으로 테스트되어 컴파일과 실행이 가능함을 보장하며, 컴파일러 릴리스 간의 소스 및 바이너리 호환성을 제공합니다.
타겟 계층에 대한 자세한 내용은 Kotlin/Native 타겟 지원을 참조하십시오.
LLVM 업데이트 (11.1.0에서 16.0.0으로)
Kotlin 2.1.0-RC에서는 LLVM을 버전 11.1.0에서 16.0.0으로 업데이트했습니다. 새 버전은 LLVM 버그 수정과 보안 업데이트를 포함하고 있으며, 일부 경우에는 컴파일러 최적화와 더 빠른 컴파일 속도를 제공합니다.
리눅스 타겟이 있는 프로젝트의 경우, Kotlin/Native 컴파일러는 이제 모든 리눅스 타겟에 대해 기본적으로 lld 링커를 사용합니다.
이 업데이트는 코드에 영향을 미치지 않아야 하지만, 문제가 발생하면 이슈 트래커에 보고해 주시기 바랍니다.
cinterop 캐싱 변경 사항
Kotlin 2.1.0-RC에서는 cinterop 캐싱 프로세스에 변경 사항이 있습니다. 이제 CacheableTask 주석 타입이 더 이상 사용되지 않으며, 결과를 캐시하려면 cacheIf 출력 타입을 사용하는 것이 권장됩니다.
이 변경 사항은 정의 파일에 지정된 헤더 파일의 변경 사항이 UP-TO-DATE 체크에서 인식되지 않아 빌드 시스템이 코드를 다시 컴파일하지 않는 문제를 해결합니다.
Kotlin/Wasm
증분 컴파일 지원
이전에는 Kotlin 코드를 변경할 때마다 Kotlin/Wasm 툴체인이 전체 코드베이스를 다시 컴파일해야 했습니다.
하지만 Kotlin 2.1.0-RC부터는 Wasm 타겟에 대해 증분 컴파일이 지원됩니다. 이제 컴파일러는 마지막 컴파일 이후 변경된 파일만 다시 컴파일하여 컴파일 시간을 현저하게 단축시킵니다.
이 변경은 현재 개발 속도를 두 배로 증가시키며, 향후 릴리스에서 더 개선될 예정입니다.
현재 설정에서는 Wasm 타겟의 증분 컴파일이 기본적으로 비활성화되어 있습니다. 증분 컴파일을 활성화하려면 프로젝트의 local.properties 또는 gradle.properties 파일에 다음 줄을 추가하십시오:
kotlin.incremental.wasm=true
Kotlin/Wasm 증분 컴파일을 사용해보고 피드백을 공유해 주세요! 여러분의 의견이 이 기능을 안정화시키고 기본값으로 설정하는 데 도움이 될 것입니다.
브라우저 API가 kotlinx-browser 독립형 라이브러리로 이동
이전에는 웹 API와 관련된 타겟 유틸리티 선언이 Kotlin/Wasm 표준 라이브러리의 일부였습니다.
이번 릴리스에서는 org.w3c.* 선언이 Kotlin/Wasm 표준 라이브러리에서 새로운 kotlinx-browser 라이브러리로 이동되었습니다. 이 라이브러리에는 org.khronos.webgl, kotlin.dom, kotlin.browser와 같은 웹 관련 패키지도 포함됩니다.
이 분리는 모듈화된 구조를 제공하여 웹 관련 API를 Kotlin의 릴리스 주기 외부에서 독립적으로 업데이트할 수 있게 합니다. 또한 Kotlin/Wasm 표준 라이브러리는 이제 모든 JavaScript 환경에서 사용할 수 있는 선언만 포함하고 있습니다.
이동된 패키지의 선언을 사용하려면 프로젝트의 빌드 구성 파일에 kotlinx-browser 의존성을 추가해야 합니다:
val wasmJsMain by getting {
dependencies {
implementation("org.jetbrains.kotlinx:kotlinx-browser:0.2")
}
}
Kotlin/Wasm의 개선된 디버깅 경험
이전에는 웹 브라우저에서 Kotlin/Wasm 코드를 디버깅할 때 변수 값이 저수준 형태로 표시되어 애플리케이션의 현재 상태를 추적하기 어려운 경우가 있었습니다.
이 경험을 개선하기 위해 변수 뷰에 사용자 지정 포맷터가 추가되었습니다. 이 구현은 Firefox와 Chromium 기반 브라우저와 같은 주요 브라우저에서 지원되는 사용자 지정 포맷터 API를 사용합니다.
이 변경으로 이제 변수 값을 더 사용자 친화적이고 이해하기 쉬운 방식으로 표시하고 추적할 수 있습니다.
새로운 디버깅 경험을 시도하려면:
wasmJs 컴파일러 옵션에 다음 컴파일러 인수를 추가하세요:
kotlin {
wasmJs {
…
compilerOptions {
freeCompilerArgs.add("-Xwasm-debugger-custom-formatters")
}
}
}
브라우저에서 사용자 지정 포맷터 기능을 활성화하십시오.
• Chrome DevTools에서는 설정 | 환경 설정 | 콘솔에서 사용자 지정 포맷터를 활성화할 수 있습니다.
• Firefox Developer Tools에서는 설정 | 고급 설정에서 사용자 지정 포맷터를 활성화할 수 있습니다.
Kotlin/Wasm 업데이트
Kotlin/Wasm 바이너리 크기 감소
프로덕션 빌드에서 생성된 Kotlin/Wasm 바이너리의 크기가 최대 30%까지 줄어들었으며, 일부 성능 개선도 이루어졌습니다. 이는 Binaryen 옵션인 --closed-world, --type-ssa, --type-merging이 이제 모든 Kotlin/Wasm 프로젝트에서 안전하게 사용될 수 있다고 판단되어 기본적으로 활성화되었기 때문입니다.
Kotlin/Wasm에서 JavaScript 배열 상호 운용성 개선
Kotlin/Wasm의 표준 라이브러리는 JavaScript 배열을 위한 JsArray<T> 타입을 제공하지만, JsArray<T>를 Kotlin의 기본 Array나 List 타입으로 변환하는 직접적인 방법은 없었습니다. 이로 인해 배열 변환을 위한 사용자 정의 함수가 필요했고, Kotlin과 JavaScript 간의 상호 운용성을 복잡하게 만들었습니다.
이번 릴리스에서는 JsArray<T>를 Array<T>로 변환하거나 그 반대로 변환하는 어댑터 함수가 도입되어 배열 작업이 간소화되었습니다.
예를 들어, 제네릭 타입을 변환하는 방법은 다음과 같습니다:
val list: List<JsString> = listOf("Kotlin", "Wasm").map { it.toJsString() }
// List 또는 Array를 JsArray로 변환
val jsArray: JsArray<JsString> = list.toJsArray()
// 다시 Kotlin 타입으로 변환
val kotlinArray: Array<JsString> = jsArray.toArray()
val kotlinList: List<JsString> = jsArray.toList()
타입 배열을 변환하는 예제도 지원됩니다. 예를 들어, Kotlin IntArray를 JavaScript Int32Array로 변환하는 방법은 다음과 같습니다:
import org.khronos.webgl.*
val intArray: IntArray = intArrayOf(1, 2, 3)
// Kotlin IntArray를 JavaScript Int32Array로 변환
val jsInt32Array: Int32Array = intArray.toInt32Array()
// JavaScript Int32Array를 Kotlin IntArray로 변환
val kotlinIntArray: IntArray = jsInt32Array.toIntArray()
Kotlin/Wasm에서 JavaScript 예외 세부 정보 접근 지원
이전에는 Kotlin/Wasm에서 JavaScript 예외가 발생할 때 JsException 타입이 원래의 JavaScript 오류 메시지 없이 일반적인 메시지만 제공했습니다.
Kotlin 2.1.0-RC부터는 JsException을 구성하여 원래의 오류 메시지와 스택 추적 정보를 포함할 수 있게 되었습니다. 이는 JavaScript에서 발생한 문제를 진단하는 데 더 많은 컨텍스트를 제공하는데 도움이 됩니다.
이 기능은 WebAssembly.JSTag API에 의존하며, 일부 브라우저에서만 지원됩니다:
• Chrome: 버전 115부터 지원
• Firefox: 버전 129부터 지원
• Safari: 아직 지원되지 않음
기본적으로 이 기능은 비활성화되어 있으며, 활성화하려면 build.gradle.kts 파일에 다음 컴파일러 플래그를 추가해야 합니다:
kotlin {
wasmJs {
compilerOptions {
freeCompilerArgs.add("-Xwasm-attach-js-exception")
}
}
}
이제 JsException에서 JavaScript 오류에 대한 구체적인 세부 사항을 확인할 수 있습니다. 예를 들어, 잘못된 JSON 파싱에서 발생한 오류를 처리할 때, 구체적인 오류 메시지와 스택 트레이스를 확인할 수 있습니다.
external object JSON {
fun <T: JsAny> parse(json: String): T
}
fun main() {
try {
JSON.parse("an invalid JSON")
} catch (e: JsException) {
println("Thrown value is: ${e.thrownValue}")
// SyntaxError: Unexpected token 'a', "an invalid JSON" is not valid JSON
println("Message: ${e.message}")
// Message: Unexpected token 'a', "an invalid JSON" is not valid JSON
println("Stacktrace:")
// Stacktrace:
e.printStackTrace()
}
}
-Xwasm-attach-js-exception 플래그를 활성화하면 JsException은 JavaScript 오류의 세부 정보를 제공하고, 플래그가 없으면 일반적인 메시지만 표시됩니다.
기본 내보내기 기능의 사용 중단
Kotlin/Wasm에서의 기본 내보내기를 사용 중단하는 과정의 일환으로, JavaScript에서 Kotlin/Wasm 내보내기를 기본으로 가져올 때 콘솔에 오류가 출력되었습니다.
2.1.0-RC에서는 기본 내보내기가 완전히 제거되어 이제는 명명된 내보내기만 지원됩니다.
JavaScript에서 Kotlin/Wasm 타겟을 사용할 때는 더 이상 기본 내보내기를 사용하지 않고, 해당하는 명명된 내보내기를 사용해야 합니다.
이 변경은 명명된 내보내기로의 전환을 위한 마지막 단계입니다:
• 2.0.0 버전: 기본 내보내기를 사용하는 것이 더 이상 권장되지 않음을 설명하는 경고 메시지가 콘솔에 출력되었습니다.
• 2.0.20 버전: 기본 내보내기를 사용하면 오류가 발생하며, 명명된 내보내기를 사용해야 한다는 메시지가 출력되었습니다.
• 2.1.0 버전: 기본 내보내기의 사용이 완전히 제거되었습니다.
Kotlin/JS에서 비식별자 문자를 사용하는 속성 지원
이전에는 Kotlin/JS에서 테스트 메소드 이름에 공백을 사용할 수 없었고, 하이픈이나 공백 같은 Kotlin 식별자에 허용되지 않는 문자를 포함한 JavaScript 객체 속성에 접근할 수 없었습니다. 예를 들어:
external interface Headers {
var accept: String?
// 하이픈 때문에 유효하지 않은 Kotlin 식별자
var `content-length`: String?
}
val headers: Headers = TODO("value provided by a JS library")
val accept = headers.accept
// 하이픈 때문에 오류 발생
val length = headers.`content-length`
이 동작은 JavaScript와 TypeScript에서는 비식별자 문자가 포함된 속성에 접근할 수 있었던 것과 달랐습니다.
Kotlin 2.1.0-RC부터는 이 기능이 기본적으로 활성화되었습니다. 이제 Kotlin/JS는 백틱 구문(```)과 @JsName 어노테이션을 사용하여 비식별자 문자가 포함된 JavaScript 속성에 접근할 수 있도록 지원합니다. 또한, 테스트 메소드 이름에도 백틱 구문을 사용할 수 있습니다.
이제 속성 이름을 백틱(```)으로 감싸서 비식별자 문자를 포함한 속성을 참조할 수 있습니다. 또한, @JsName과 `@JsQualifier` 어노테이션을 사용하여 Kotlin 속성 이름을 JavaScript의 해당 속성 이름으로 매핑할 수 있습니다:
object Bar {
val `property example`: String = "bar"
}
@JsQualifier("fooNamespace")
external object Foo {
val `property example`: String
}
@JsExport
object Baz {
val `property example`: String = "bar"
}
fun main() {
// JS에서는 Bar.property_example_HASH로 컴파일됨
println(Bar.`property example`)
// JS에서는 fooNamespace["property example"]로 컴파일됨
println(Foo.`property example`)
// JS에서는 Baz["property example"]로 컴파일됨
println(Baz.`property example`)
}
이렇게 하면 이제 JavaScript에서 property example 같은 속성에 접근할 수 있으며, Kotlin 코드 내에서 비식별자 문자가 포함된 속성을 처리하는데 더 유연하게 대응할 수 있습니다.
Gradle 개선 사항
Kotlin 2.1.0-RC는 Gradle 7.6.3부터 8.6까지 완벽하게 호환됩니다. Gradle 8.7에서 8.10까지도 지원되지만, 단 하나의 예외가 있습니다: Kotlin Multiplatform Gradle 플러그인을 사용하는 경우, JVM 타겟에서 withJava() 함수를 호출할 때 다중 플랫폼 프로젝트에서 deprecation 경고가 발생할 수 있습니다. 이 문제는 가능한 한 빨리 수정될 예정입니다. 자세한 정보는 YouTrack에서 확인할 수 있습니다.
또한 최신 Gradle 버전까지 사용할 수 있지만, 이를 사용할 경우 deprecation 경고가 발생하거나 새로운 Gradle 기능이 제대로 작동하지 않을 수 있습니다.
최소 지원 AGP 버전 7.3.1로 업데이트
Kotlin 2.1.0-RC부터는 최소 지원되는 Android Gradle 플러그인(AGP) 버전이 7.3.1로 업데이트되었습니다.
최소 지원 Gradle 버전 7.6.3으로 업데이트
Kotlin 2.1.0-RC부터는 최소 지원되는 Gradle 버전이 7.6.3으로 업데이트되었습니다.
Compose 컴파일러 업데이트
여러 개의 안정성 구성 파일 지원
Compose 컴파일러는 이제 여러 개의 안정성 구성 파일을 해석할 수 있습니다. 그러나 Compose Compiler Gradle 플러그인의 stabilityConfigurationFile 옵션은 한 번에 하나의 파일만 지정할 수 있었습니다.
Kotlin 2.1.0-RC에서는 이 기능이 재작업되어, 이제 단일 모듈에 대해 여러 개의 안정성 구성 파일을 사용할 수 있게 되었습니다:
• stabilityConfigurationFile 옵션은 더 이상 사용되지 않음(Deprecated).
• 대신 **stabilityConfigurationFiles**라는 새로운 옵션이 추가되었으며, 이는 ListProperty<RegularFile> 타입입니다.
여러 파일을 Compose 컴파일러에 전달하는 방법은 다음과 같습니다:
composeCompiler {
stabilityConfigurationFiles.addAll(
project.layout.projectDirectory.file("configuration-file1.conf"),
project.layout.projectDirectory.file("configuration-file2.conf"),
)
}
이제 여러 안정성 구성 파일을 사용할 수 있어 더욱 유연하게 설정을 관리할 수 있습니다.
2.1.0-RC로 업데이트하는 방법
Kotlin 2.1.0-RC로 업데이트하는 방법은 다음과 같습니다:
IntelliJ IDEA 2023.3과 Android Studio Iguana (2023.2.1) Canary 15부터 Kotlin 플러그인이 IDE에 번들로 포함되어 배포됩니다. 즉, 더 이상 JetBrains Marketplace에서 플러그인을 설치할 수 없습니다. 번들된 플러그인은 다가오는 Kotlin EAP 릴리스를 지원합니다.
새로운 Kotlin EAP 버전으로 업데이트하려면 빌드 스크립트에서 Kotlin 버전을 2.1.0-RC로 변경하면 됩니다.
원문
https://kotlinlang.org/docs/whatsnew-eap.html#how-to-update-to-kotlin-kotlineapversion
'Gradle' 카테고리의 다른 글
| [Gradle] Dependency Configuration 종류 및 기능 (0) | 2023.02.14 |
|---|---|
| Lombok 사용 시 error: cannot find symbol 에러가 발생한다면? Gradle 버전 변경을!! (0) | 2020.12.08 |
댓글