[Kotlin Release Notes] Kotlin 1.4.0-RC Released

2020년 7월 27일

 

거의 다 왔어요! 우리는 Kotlin 1.4.0-RC를 공개하게 된 것에 기쁘게 생각합니다. 이것은 우리 프로그래밍 언어의 다음 주요 버전을 위한 릴리스 후보입니다. Kotlin 1.4.0-RC에서 무엇이 변경되었는지 알아보고, Kotlin 1.4.0이 공식 릴리스되기 전에 새로운 기능을 시도해 보기 바랍니다.

 

1.4-M1, 1.4-M2 및 1.4-M3와 같은 마일스톤 릴리스를 시도하고 피드백을 공유하고 이 버전을 개선하는 데 도움을 주신 모든 분들에게 특별한 감사의 말씀을 드립니다!

이 게시물은 Kotlin 1.4.0-RC에서 사용 가능한 새로운 기능과 주요 개선 사항을 강조합니다:

• *.gradle.kts IDE 지원 개선: 스크립트 구성의 명시적 로딩과 더 나은 오류 보고를 통한 Gradle Kotlin DSL 스크립트 지원 개선되었습니다.
• 모든 소스 세트에서 기본적으로 표준 라이브러리 종속성 포함: 멀티플랫폼 프로젝트 및 단일 플랫폼 프로젝트 모두에서 이제 모든 소스 세트에 대해 기본적으로 표준 라이브러리 종속성이 포함됩니다.
• CocoaPods 종속성 간소화 관리: CocoaPods 종속성 관리가 간소화되었습니다.
• Kotlin/JS 통합 개선: npm 종속성, CSS 및 dukat에 대한 Kotlin/JS 통합이 개선되었으며, 기본 컴파일러 백엔드에서 @JsExport 주석을 사용할 수 있습니다.
• Node.js API 바인딩 미리보기: Node.js API 바인딩에 대한 미리보기 기능이 추가되었습니다.
• 코루틴 디버깅 및 깊은 재귀 함수 정의를 위한 새로운 기능: 이러한 주제는 별도의 블로그 게시물에서 다루고 있습니다.

 

.gradle.kts IDE 지원 개선

우리는 Kotlin 1.3.70에서 Gradle Kotlin DSL 스크립트 (.gradle.kts 파일)의 IDE 지원을 크게 개선했으며, Kotlin 1.4.0-RC에서도 이를 계속 개선하고 있습니다. 새로운 버전에서 제공하는 내용은 다음과 같습니다:

성능 향상을 위해 스크립트 구성을 명시적으로 로드

이전에는 build.gradle.kts의 buildscript 또는 plugins 블록에 새 플러그인을 추가하면 새 스크립트 구성이 자동으로 백그라운드에서 로드되었습니다. 그런 다음 적용된 후에 새로 추가된 플러그인에 대한 코드 지원을 사용할 수 있었습니다.

성능을 개선하기 위해 타이핑 시 스크립트 구성에 변경 사항을 자동으로 적용하는 이 자동 동작을 제거했습니다. Gradle 6.0 이상 버전을 사용하는 경우 구성에 변경 사항을 명시적으로 적용해야 합니다. 이를 위해 Load Gradle Changes를 클릭하거나 Gradle 프로젝트를 다시 가져와야 합니다.

이전 버전의 Gradle에서는 에디터에서 Load Configuration을 클릭하여 스크립트 구성을 수동으로 로드해야 했습니다.

우리는 IntelliJ IDEA 2020.1에서 Gradle 6.0+와 함께 추가된 또 다른 작업인 Load Script Configurations을 추가했습니다. 이 작업을 통해 전체 프로젝트를 다시 가져오지 않고도 스크립트 구성에 대한 변경 사항을 로드할 수 있습니다. 이는 전체 프로젝트를 다시 가져오는 것보다 훨씬 더 빠릅니다.

더 나은 오류 보고

이전에는 Gradle Daemon(백그라운드에서 실행되며 모든 Gradle 관련 작업 및 활동을 담당하는 프로세스)에서 발생한 오류를 별도의 로그 파일에서만 볼 수 있었습니다. 이제 Gradle 6.0 이상 버전을 사용하는 경우 Gradle Daemon이 오류에 관한 모든 정보를 직접 반환하고 빌드 도구 창에 표시합니다. 이렇게 하면 시간과 노력을 절약할 수 있습니다.

 

 

프로젝트 구성의 보일러플레이트 감소

Kotlin Gradle 플러그인의 개선으로 Gradle 빌드 파일에서 더 적은 코드를 작성할 수 있게 되었습니다. 이제 가장 일반적인 시나리오 중 하나가 기본적으로 활성화되었습니다.

표준 라이브러리를 기본 종속성으로 설정

대다수의 프로젝트에서는 Kotlin 표준 라이브러리가 필요합니다. 1.4.0-RC부터는 각 소스 세트에서 stdlib에 대한 종속성을 수동으로 선언할 필요가 없어집니다. 이제 기본적으로 자동으로 추가됩니다. 자동으로 추가되는 표준 라이브러리의 버전은 Kotlin Gradle 플러그인의 버전과 동일합니다.

다음은 1.4 이전에 Android, iOS 및 JavaScript 대상을 가진 전형적인 멀티플랫폼 프로젝트 구성 예시입니다:

 

...
android()
ios()
js()
​
sourceSets {
    commonMain {
        dependencies {
            implementation("org.jetbrains.kotlin:kotlin-stdlib-common")
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-common:1.3.6")
        }
    }
   
    androidMain {
        dependencies {
            implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8")
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.6")
        }
    }
​
    jsMain {
        dependencies {
            implementation("org.jetbrains.kotlin:kotlin-stdlib-js")
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-js:1.3.6")
        }
    }
​
    iosMain {
        dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-native:1.3.6")
        }
    }
}
...

이제 더 이상 표준 라이브러리에 대한 종속성을 명시적으로 선언할 필요가 없으며, 1.4-M2에서 소개된 계층적 프로젝트 구조 지원으로 다른 종속성을 한 번만 지정하면 됩니다. 따라서 Gradle 빌드 파일은 훨씬 간결하고 읽기 쉬워집니다:

 

...

android()
ios()
js()

sourceSets {
    commonMain {
        dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.6")
        }
    }
}

...

플랫폼 소스 세트 및 백엔드 공유 소스 세트에는 해당 표준 라이브러리가 추가되고, 나머지에는 공통 표준 라이브러리가 추가됩니다. Kotlin Gradle 플러그인은 kotlinOptions.jvmTarget 설정에 따라 적절한 JVM 표준 라이브러리를 선택합니다.

표준 라이브러리 종속성을 명시적으로 선언하면(다른 버전이 필요한 경우 등), Kotlin Gradle 플러그인은 이를 덮어쓰거나 두 번째 표준 라이브러리를 추가하지 않습니다. 그리고 표준 라이브러리가 전혀 필요하지 않은 경우 Gradle 속성에 opt-out 플래그를 추가할 수 있습니다:

kotlin.stdlib.default.dependency=false

 

Kotlin/Native

CocoaPods 종속성 관리 간소화

이전에는 CocoaPods 의존성 관리자를 프로젝트에 통합한 후, iOS, macOS, watchOS 또는 tvOS 부분을 Xcode에서만 빌드할 수 있었습니다. 이것은 멀티플랫폼 프로젝트의 다른 부분과 분리되어 작동하게 했습니다. IntelliJ IDEA에서 다른 부분을 빌드할 수 있었습니다.

또한 CocoaPods(Pod 라이브러리)에 저장된 Objective-C 라이브러리에 대한 종속성을 추가할 때마다 IntelliJ IDEA에서 Xcode로 전환하여 pod install 작업을 실행하고 Xcode에서 빌드해야 했습니다.

이제 IntelliJ IDEA에서 바로 Pod 종속성을 관리할 수 있으며 코드 하이라이팅 및 완성과 같은 코드 작업에 대한 이점을 누릴 수 있습니다. 또한 Xcode로 전환하지 않고도 Gradle을 사용하여 전체 Kotlin 프로젝트를 빌드할 수 있습니다. 이는 Swift/Objective-C 코드를 작성하거나 시뮬레이터 또는 기기에서 응용 프로그램을 실행해야 할 때만 Xcode로 이동해야 하는 것을 의미합니다.

이제 로컬로 저장된 Pod 라이브러리와도 작업할 수 있습니다.

귀하의 요구에 따라 다음과 같은 종속성을 추가할 수 있습니다:

• Kotlin 프로젝트와 CocoaPods 저장소에서의 Pod 라이브러리 간의 종속성.
• Kotlin 프로젝트와 로컬로 저장된 Pod 라이브러리 간의 종속성.
• Kotlin Pod (CocoaPods 종속성으로 사용되는 Kotlin 프로젝트)과 하나 이상의 타겟이 있는 Xcode 프로젝트 간의 종속성.

 

초기 구성을 완료하고 CocoaPods에 새로운 종속성을 추가할 때 IntelliJ IDEA에서 프로젝트를 다시 가져오기만 하면 새 종속성이 자동으로 추가됩니다. 추가 단계는 필요하지 않습니다.

아래에서 CocoaPods 저장소에서 Pod 라이브러리에 종속성을 추가하는 방법에 대한 지침을 찾을 수 있습니다. Kotlin 1.4 문서에서는 모든 시나리오를 다룰 것입니다.

CocoaPods 통합 사용 방법

CocoaPods 의존성 관리자 및 플러그인 설치

 

1. cocoapods 의존성 관리자 설치 (sudo gem install cocoapods).

2. cocoapods-generate 플러그인 설치 (sudo gem install cocoapods-generate).

3. 프로젝트의 build.gradle(.kts) 파일에서 CocoaPods 플러그인을 적용합니다. kotlin("native.cocoapods")로 CocoaPods 플러그인을 적용합니다:

 

plugins {
   kotlin("multiplatform") version "1.4.0-rc"
   kotlin("native.cocoapods") version "1.4.0-rc"
}

CocoaPods 저장소에서 Pod 라이브러리에 종속성 추가

1. CocoaPods 저장소에서 사용하려는 Pod 라이브러리에 대한 종속성을 pod() 함수로 추가합니다. subspecs로 종속성도 추가할 수 있습니다.

 

kotlin {
    ios()
​
    cocoapods {
        summary = "CocoaPods test library"
        homepage = "https://github.com/JetBrains/kotlin"
        pod("AFNetworking", "~> 4.0.0")
​
        //Remote Pod added as a subspec
        pod("SDWebImage/MapKit")
    }
}

2. 프로젝트를 다시 가져옵니다.
Kotlin 코드에서 종속성을 사용하려면 다음 패키지를 가져옵니다:

 

import cocoapods.AFNetworking.*
import cocoapods.SDWebImage.*

또한 CocoaPods 저장소 및 로컬로 저장된 Pod 라이브러리에 대한 종속성을 추가하는 방법을 보여주는 샘플 프로젝트를 공유해 드릴 수 있습니다.

Apple 타겟에 대한 릴리스 .dSYM 생성

iOS 응용 프로그램 충돌의 디버깅은 때로는 충돌 보고서를 분석해야하며, 일반적으로 충돌 보고서는 올바르게 읽을 수 있도록 symbolication이 필요합니다. Kotlin에서 주소를 symbolicate하려면 Kotlin 코드의 .dSYM 번들이 필요합니다. 1.4-M3부터 Kotlin/Native 컴파일러는 Darwin 플랫폼에서 릴리스 바이너리용으로 기본적으로 .dSYM을 생성합니다. 이 기능은 -Xadd-light-debug=disable 컴파일러 플래그로 비활성화할 수 있습니다. 다른 플랫폼에서는 기본적으로 이 옵션이 비활성화됩니다. Gradle에서 이 옵션을 전환하려면 다음과 같이 사용합니다:

 

kotlin {
    targets.withType<org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTarget> {
        binaries.all {
            freeCompilerArgs += "-Xadd-light-debug={enable|disable}"
        }
    }
}

성능 개선

Kotlin/Native 개발 프로세스의 전반적인 성능을 최적화하는 데 계속 집중하고 있습니다.

• 1.3.70에서 Kotlin/Native 컴파일 성능을 향상하기 위해 프로젝트 종속성 캐싱 및 Gradle 데몬에서 컴파일러를 실행하는 두 가지 새로운 기능을 도입했습니다. 여러분의 피드백 덕분에 이러한 기능의 안정성을 향상시키고 다양한 문제를 수정했으며, 이에 계속해서 집중할 것입니다.
• 런타임 성능 개선도 있습니다. 전반적인 런타임 성능은 GC 최적화 덕분에 개선되었습니다. HashMap 및 HashSet 컬렉션도 중복된 boxing을 피하도록 작동하여 더 빠릅니다. 이 개선은 장기간 살아 있는 객체가 많은 프로젝트에서 특히 두드러집니다.

 

Kotlin/JS

Kotlin 1.4.0-RC에서는 @JsExport 주석을 기본 컴파일러 백엔드와 호환되도록 만들었습니다. 또한 npm 의존성 관리와 Gradle 프로젝트용 Dukat 통합을 보다 견고하고 세밀하게 제어할 수 있도록 개선했으며, CSS 지원을 개선하고 Node.js API 통합을 미리 살펴볼 수 있는 기회를 제공합니다.

@JsExport 주석을 사용한 기본 컴파일러 백엔드

이전 Kotlin 1.4 마일스톤에서는 @JsExport 주석을 도입했는데, 이 주석은 새로운 IR 컴파일러 백엔드를 사용할 때 JavaScript 또는 TypeScript에서 최상위 선언을 사용할 수 있게 합니다. Kotlin 1.4-M3부터는 현재 기본 컴파일러 백엔드와도 이 주석을 사용할 수 있습니다. 현재 기본 컴파일러 백엔드를 사용할 때 최상위 선언에 @JsExport 주석을 추가하면 선언에 대한 이름 맹글링이 해제됩니다. 두 컴파일러 백엔드에서 이 주석을 가지고 있으면 최상위 선언 내보내기에 대한 논리를 조정할 필요 없이 두 백엔드 간 전환할 수 있습니다. TypeScript 정의 생성은 여전히 새로운 IR 컴파일러 백엔드를 사용할 때만 가능합니다.

npm 의존성 관리 변경 사항

의존성 선언을 명시적으로 지정해야 함

버전 번호를 지정하지 않고 npm 패키지에 대한 의존성을 선언하는 것은 패키지를 신뢰성 있게 관리하기 어렵게 만들 수 있습니다. 이제부터는 npm의 semver 구문을 기반으로 버전 또는 버전 범위를 명시적으로 지정해야 합니다. Gradle DSL은 이제 의존성에 대한 여러 범위를 지원하여 프로젝트에서 허용할 버전을 정확하게 지정할 수 있습니다. 예를 들어:

 

dependencies {
    implementation(npm("react", "> 14.0.0 <=16.9.0"))
}

추가 npm 의존성 유형

dependencies 블록 내에서 npm(...)을 사용하여 지정할 수 있는 일반적인 npm 의존성 외에도 세 가지 추가 유형의 의존성을 사용할 수 있습니다:

• devDependencies: devNpm(...)
• optionalDependencies: optionalNpm(...)
• peerDependencies: peerNpm(...).

각 유형의 의존성이 언제 사용되는지에 대한 자세한 내용은 npm에서 제공하는 공식 문서를 참조하십시오.

트랜지티브 npm 의존성의 자동 포함 및 해결

이전에는 패키지.json 파일을 수동으로 아티팩트에 추가하지 않은 라이브러리에 의존할 경우 때로는 해당 npm 의존성을 수동으로 가져와야 하는 경우가 있었습니다. 이런 경우에는 kotlinx.serialization과 같은 경우에 Gradle 빌드 파일에 text-encoding 및 abort-controller를 의존성으로 수동으로 추가해야 했습니다.

이제 Gradle 플러그인은 라이브러리에 대한 자동으로 package.json 파일을 생성하고 jar 또는 klib 아티팩트에 포함시킵니다. 이런 종류의 라이브러리를 포함할 때 파일이 자동으로 구문 분석되며 필요한 의존성이 자동으로 포함되므로 Gradle 빌드 파일에 수동으로 추가할 필요가 없어집니다.

CSS 지원 조정

Kotlin 1.4-M2에서는 Gradle을 통해 webpack의 CSS 및 스타일 로더를 지원하기 시작했습니다. 작업 및 효과를 더 정확하게 반영하기 위해 구성 매개변수의 이름을 cssSettings에서 cssSupport로 변경했습니다. 앞으로 Gradle 플러그인은 CSS 지원을 기본적으로 활성화하지 않습니다. 이전 버전에서 실험한 설정에서 이로 인한 혼란을 방지하기 위한 변경입니다. 이런 상황에서는 스타일 시트 처리 방법을 자체적으로 포함하는 사람들에게 프로젝트의 기본 구성이 일부 CSS 설정을 이미 주입했을 수 있다는 것이 즉각적으로 명확하지 않을 수 있습니다.

프로젝트에서 CSS 지원을 활성화하려면 webpackTask, runTask 및 testTask용 Gradle 빌드 파일에서 cssSupport.enabled 플래그를 설정하십시오. IntelliJ IDEA의 포함된 마법사를 사용하여 새 프로젝트를 생성할 때는 이러한 설정이 자동으로 생성된 build.gradle(.kts) 파일에 포함됩니다:

 

webpackTask {
   cssSupport.enabled = true
}
runTask {
   cssSupport.enabled = true
}
testTask {
   useKarma {
      // . . .
      webpackConfig.cssSupport.enabled = true
   }
}

각 작업에 대해 이러한 설정을 개별적으로 조정해야 하는 것은 매우 불편합니다. 플러그인 DSL의 cssSupport에 대한 중앙 구성 지점을 추가하는 방법을 검토 중입니다 (진행 상황은 여기에서 확인할 수 있습니다).

 

Dukat 통합 개선 사항

Kotlin/JS Gradle 플러그인은 Dukat이라는 TypeScript 선언 파일 (.d.ts)을 Kotlin 외부 선언으로 자동 변환하는 도구와의 통합을 보다 세밀하게 제어할 수 있도록 개선했습니다. 이제 Dukat이 선언을 생성할 때 언제 생성해야 하는지를 선택할 수 있는 두 가지 다른 방법이 있습니다.

빌드 시간에 외부 선언 생성

npm 의존성 함수는 패키지 이름과 버전 다음에 세 번째 매개변수를 가져옵니다: generateExternals. 이를 사용하면 특정 의존성에 대한 Dukat 선언 생성을 개별적으로 제어할 수 있습니다. 예를 들어:

 

dependencies {
  implementation(npm("decamelize", "4.0.0", generateExternals = true))
}

gradle.properties 파일에서 kotlin.js.generate.externals 플래그 (이전에는 kotlin.js.experimental.generateKotlinExternals로 이름이 지정되었습니다)를 사용하여 모든 npm 의존성에 대한 생성기 동작을 일괄 설정할 수 있습니다. 일반적인 플래그보다 개별적인 명시적인 설정이 우선합니다.

Gradle 작업을 통해 수동으로 외부 선언 생성

Dukat에 의해 생성된 선언을 완전히 제어하거나 수동으로 조정하려는 경우 또는 자동 생성된 외부 선언에 문제가 있는 경우에는 generateExternals Gradle 작업을 사용하여 모든 npm 의존성에 대한 선언 생성을 수동으로 트리거할 수도 있습니다. 이렇게 하면 프로젝트 루트에 externals라는 디렉토리에 선언이 생성되며 생성된 코드를 검토하고 사용할 부분을 소스 디렉토리로 복사할 수 있습니다. (소스 폴더에 수동으로 외부 선언을 제공하고 동일한 의존성에 대한 빌드 시간 외부 선언 생성을 활성화하는 경우 해결 문제가 발생할 수 있음에 유의하십시오.)

kotlin.dom 및 kotlin.browser를 별도 아티팩트로 마이그레이션 준비

Kotlin/JS의 브라우저 및 DOM 바인딩을 언어 자체의 릴리스 주기와 분리하고 더 빠르게 발전시키기 위해 kotlin.dom 및 kotlin.browser 패키지에 현재 API를 사용하지 않도록 하고 있습니다. 이러한 API에 대한 대체 제공 합니다. 이러한 새로운 kotlinx 패키지로 포인트하는 프로젝트에서 사용하는 가져오기(import)를 조정하기만 하면 됩니다. IntelliJ IDEA에서 Alt-Enter를 통해 접근할 수 있는 빠른 수정 기능이 마이그레이션을 돕습니다.

미리보기: kotlinx-nodejs

우리는 Node.js API에 대한 공식 바인딩인 kotlinx-nodejs의 미리보기 버전을 공유하게 되어 기쁩니다. Kotlin으로 Node.js를 대상으로 하는 것은 오랫동안 가능했지만 해당 API에 안전한 형식의 액세스가 가능할 때 이를 활용하는 것이 중요합니다. kotlinx-nodejs 바인딩은 GitHub에서 확인할 수 있습니다.

프로젝트에 kotlinx-nodejs를 추가하려면 리포지토리에 jcenter()가 추가되어 있는지 확인하십시오. 그런 다음 아래와 같이 아티팩트에 대한 의존성을 간단히 추가할 수 있습니다:

 

dependencies {
    // . . .
    implementation("org.jetbrains.kotlinx:kotlinx-nodejs:0.0.4")
}

Gradle 변경 사항을 로드한 후에는 Node.js에서 제공하는 API를 사용하여 실험해 볼 수 있습니다. DNS 해결 패키지를 사용하는 예제입니다:

 

fun main() {
    dns.lookup("example.org") { err, address, family ->
        console.log("address: $address, family IPv$family")
    }
}

특히 이것이 여전히 미리보기 버전인 것을 감안할 때, kotlinx-nodejs를 사용해 보고 만난 문제를 리포지토리의 이슈 트래커에 보고하는 것을 권장합니다.

kotlin2js 및 kotlin-dce-js Gradle 플러그인의 폐기

Kotlin 1.4부터 Kotlin으로 JavaScript를 대상으로 하는 구버전 Gradle 플러그인 (kotlin2js 및 kotlin-dce-js)은 kotlin.js Gradle 플러그인으로 공식적으로 폐기될 예정입니다. 이러한 플러그인과 함께 사용 가능한 주요 기능은 새 플러그인으로 통합되어 Kotlin/JS 대상을 통일된 DSL을 사용하여 구성할 수 있도록 되었습니다.

Kotlin 1.3.70부터는 browserProductionRun 및 browserProductionWebpack 작업을 사용할 때 자동으로 dead code elimination (DCE)이 적용되었습니다. 이 작업은 프로그램의 최적화된 번들을 실행하고 생성합니다. (DCE는 현재 브라우저를 대상으로 하는 프로덕션 출력을 위해 사용할 수 있으며 Node.js 또는 테스트를 대상으로 하는 경우에는 사용할 수 없습니다. 그러나 해결해야 할 다른 사용 사례가 있다면 YouTrack에서 공유해 주시기 바랍니다.)

기타 사용 편의성 개선 및 주목할 만한 수정 사항

 

• @JsExport 주석의 금지된 사용에 대한 더 많은 컴파일러 오류를 추가하여 해당 문제를 강조했습니다.
• IR 컴파일러 백엔드를 사용할 때 klibs의 증분 컴파일을 포함하는 새로운 전략을 활성화하여 컴파일 시간을 개선하기 위한 많은 단계 중 하나를 수행했습니다.
• webpack 개발 서버 구성이 조정되어 핫 리로드 기능을 사용할 때 ENOENT: no such file or directory와 같은 오류가 발생하지 않도록 했습니다.

 

Kotlin 표준 라이브러리 API의 진화

 

Kotlin 1.4은 Kotlin의 진화 관점에서의 기능 릴리스입니다. 따라서 이전 블로그 게시물에서 이미 알고 있는 새로운 기능을 많이 가져옵니다. 그러나 기능 릴리스의 중요한 측면 중 하나는 기존 API에서 중요한 진화적인 변경 사항을 포함한다는 것입니다. 1.4 릴리스에서 기대할 수 있는 변경 사항을 간략히 살펴보겠습니다.

실험적 API의 안정화

새로운 Kotlin 라이브러리에서 보고 싶은 새로운 기능을 가능한 빨리 배포하기 위해 해당 기능의 실험 버전을 제공합니다. 이 상태는 API 작업이 아직 진행 중이며 나중에 호환되지 않게 변경될 수 있음을 나타냅니다. 실험적 API를 사용하려고 할 때 컴파일러는 해당 상태에 대해 경고하고 @OptIn 주석을 필요로 합니다.

기능 릴리스에서 실험적 API를 안정 버전으로 승격할 수 있습니다. 이 단계에서 해당 API의 형태와 동작이 갑자기 변경되지 않음을 보장합니다 (변경 사항은 적절한 폐기 주기로만 가능합니다). 한 번 API가 공식적으로 안정화되면 @OptIn 주석이나 경고없이 해당 API를 안전하게 사용할 수 있습니다.

1.4에서는 Kotlin 라이브러리에서 여러 실험적 함수를 안정 버전으로 승격합니다. 몇 가지 예시와 도입된 버전은 다음과 같습니다.

• 1.3.40: CharArray/ByteArray와 String 간의 변환 함수:
  
  • ByteArray.decodeToString 및 String.encodeToByteArray
  • CharArray.concatToString 및 String.toCharArray
• 1.3.50: 비트 연산 countOneBits(), countLeadingZeroBits(), countTrailingZeroBits(), takeHighestOneBit(), takeLowestOneBit()
• 1.3.70: 컬렉션 연산 randomOrNull(), reduceOrNull(), scan(); MutableList의 remove*() 함수; ArrayDeque 클래스
• 1.4-M2: 컬렉션 연산 onEachIndexed() 및 reduceIndexedOrNull(), runningFold() 및 runningReduce()

 

1.4 버전부터 (1.4.0-RC) 이후에는 이러한 함수와 클래스를 사용하는 데 @OptIn 주석이 필요하지 않습니다.

폐기 주기

기능 릴리스에서는 기존 폐기 주기의 다음 단계를 진행하기도 합니다. 증분 릴리스에서는 WARNING 레벨로만 새로운 폐기 주기를 시작하지만, 기능 릴리스에서는 이를 ERROR로 강화합니다. 마찬가지로 이미 ERROR 레벨을 갖는 API 요소는 코드에서의 새로운 사용에서 완전히 숨길 수 있으며 이미 컴파일된 코드의 호환성을 보존하기 위해 이진 형태로만 남습니다. 이러한 단계를 통해 폐기된 API 요소를 점진적으로 제거할 수 있습니다.

코드가 경고 수준이 WARNING인 API 요소를 사용하면 컴파일러가 해당 사용에 대해 경고합니다. Kotlin 1.4.0-RC로 업데이트하면 이러한 경고 중 일부가 오류로 전환됩니다. IDE 프롬프트를 사용하여 잘못된 사용을 적절히 대체하고 코드가 다시 컴파일되도록 해야 합니다.

Kotlin 표준 라이브러리 API의 호환성 가이드에서 Kotlin 1.4의 호환성에 관한 자세한 정보를 찾을 수 있습니다.

스크립팅

이전 블로그 게시물에서는 Kotlin 스크립팅을 건너 뛰었지만, 1.4에서는 스크립팅을 더 안정적으로, 빠르게, 사용하기 쉽게 만들기 위해 계속 작업 중입니다. RC 버전에서는 성능이 향상되었으며 여러 개의 수정 및 기능 개선이 있습니다.

아티팩트 이름 변경

아티팩트 이름에 대한 혼란을 피하기 위해 kotlin-scripting-jsr223-embeddable 및 kotlin-scripting-jvm-host-embeddable을 kotlin-scripting-jsr223 및 kotlin-scripting-jvm-host로 변경했습니다 (-embeddable 제외). 이러한 아티팩트는 kotlin-compiler-embeddable 아티팩트에 종속되어 있으며 충돌 사용을 피하기 위해 번들화된 서드파티 라이브러리를 가립니다. 이러한 이름 변경으로 인해 일반적으로 더 안전한 kotlin-compiler-embeddable 사용이 스크립팅 아티팩트의 기본값이 됩니다.
어떤 이유로든 kotlin-compiler에 종속되는 아티팩트가 필요한 경우 -unshaded 접미사가 있는 아티팩트 버전을 사용하세요. 예를 들어 kotlin-scripting-jsr223-unshaded와 같은 아티팩트 버전입니다. 이 이름 변경은 직접 사용하는 스크립팅 아티팩트에만 영향을 미치며 다른 아티팩트 이름은 변경되지 않습니다.

CLion IDE 플러그인은 현재 폐기됨

CLion IDE 플러그인에 대한 폐기 주기를 시작했습니다. 원래 이 플러그인은 Kotlin/Native 실행 파일을 디버깅하기 위해 사용되었습니다. 이제 이 기능은 IntelliJ IDEA Ultimate에서 사용할 수 있습니다. 1.4 릴리스 이후에 CLion IDE 플러그인을 게시하지 않을 것입니다. 이 폐기가 문제를 발생시키면 문의해 주세요. 문제를 해결하는 데 도움을 드리겠습니다.

호환성

모든 주요 릴리스와 마찬가지로 Kotlin 1.4에서 이전에 발표한 변경 사항의 폐기 주기 중 일부가 끝나고 있습니다. 이러한 경우 모두 언어 위원회에서 신중하게 검토했으며 Kotlin 1.4의 호환성 가이드에 나열되어 있습니다. 이러한 변경 사항을 YouTrack에서 탐색할 수도 있습니다.

릴리스 후보자 노트

Kotlin 1.4의 최종 릴리스 후보에 도달했으므로 컴파일 및 게시를 시작할 시간입니다! 이전 마일스톤 릴리스와 달리 Kotlin 1.4.0-RC로 생성된 이진 파일은 Kotlin 1.4.0과 호환되는 것이 보장됩니다.

최신 기능을 시도하는 방법

항상 play.kotl.in에서 Kotlin을 온라인으로 시도할 수 있습니다.

IntelliJ IDEA 및 Android Studio에서 Kotlin 플러그인을 버전 1.4.0-RC로 업데이트할 수 있습니다. 업데이트하는 방법은 여기에서 확인할 수 있습니다.

미리보기 버전을 설치하기 전에 생성된 기존 프로젝트에서 작업하려면 Gradle 또는 Maven에서 미리보기 버전을 사용하도록 빌드를 구성해야 합니다. 이전 미리보기 버전과 달리 Kotlin 1.4.0-RC는 Maven Central에서 직접 사용할 수 있습니다. 이것은 빌드 파일에 kotlin-eap 리포지토리를 수동으로 추가할 필요가 없다는 것을 의미합니다.

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

이 릴리스와 함께 게시된 라이브러리 버전은 다음과 같이 사용할 수 있습니다:

• kotlinx.atomicfu 버전: 0.14.3-1.4.0-rc
• kotlinx.coroutines 버전: 1.3.8-1.4.0-rc
• kotlinx.serialization 버전: 1.0-M1-1.4.0-rc
• ktor 버전: 1.3.2-1.4.0-rc

릴리스 세부 정보 및 호환되는 라이브러리 목록은 여기에서도 확인할 수 있습니다.

피드백 공유

버그를 찾아서 이슈 트래커에 보고해 주시면 감사하겠습니다. 중요한 문제를 모두 해결하기 위해 최선을 다하겠으며, 여러분의 문제가 해결되기 위해 다음 Kotlin 릴리스를 기다릴 필요가 없을 것입니다.

또한 Kotlin Slack의 #eap 채널에 참여하실 것을 환영합니다 (여기에서 초대를 받을 수 있습니다). 이 채널에서 질문을 하고 토론에 참여하며 새로운 미리보기 빌드에 대한 알림을 받을 수 있습니다.

자 Kotlin으로!

외부 기여

이 릴리스에 포함된 외부 기여자들의 풀 리퀘스트를 모두 감사하게 생각합니다:

• Toshiaki Kameyama
• Steven Schäfer
• Jinseong Jeon
• pyos
• Mark Punzalan
• rapturemain
• Vitaly
• Mads Ager
• Subroh Nishikori
• Juan Chen
• gcx11
• rbares
• Henrik Tunedal
• Efeturi Money
• Yuku Kotani
• Dmitry Borodin
• Mikhail Likholetov
• Mike Samuel
• Matthew Gharrity
• Jim Sproch
• Raluca Sauciuc
• Martin Petrov
• Segun Famisa
• Sinan Kozak
• Kristoffer Andersen
• Anastasiya Krasnoryadtseva
• Vadim Semenov
• Kevin Most
• Valeriy Vyrva
• Victor Turansky

 

원문

 

https://blog.jetbrains.com/kotlin/2020/07/kotlin-1-4-rc-released/