[Kotlin Release Notes] Kotlin 1.4-M2 Released

2020년 6월 4일

 

시간이 빨리 흘러오고 오늘은 Kotlin 1.4의 몇 가지 강력한 기능을 미리보기로 제공하려고 합니다. Kotlin 1.4-M2가 제공하는 기능을 알아보고, 공식적으로 Kotlin 1.4에서 공개되기 전에 미리 이용하고 즐기세요.

Kotlin 1.4의 첫 번째 미리보기를 시도해보고 피드백을 공유하고 Kotlin을 개선하는 데 도움을 주신 모든 분들께 진심으로 감사드립니다!

또한 이전 포스트에서 발표한 Kotlin 1.4-M2의 표준 라이브러리 개선 사항을 이미 시도해보신 분들께도 많은 감사를 드립니다.

이 글에서는 1.4-M2에서 제공하는 새로운 기능과 주요 개선 사항을 강조하겠습니다:

• 다중 플랫폼 프로젝트의 계층 구조를 통해 여러 대상에서 코드 공유 지원.
• 다양한 유형의 프로젝트를 쉽게 생성하고 구성하기 위한 새로운 유연한 Kotlin 프로젝트 마법사.
• 라이브러리 작성자를 위한 새로운 컴파일러 모드로 명시적 API 모드라는 것이 있으며 이 모드는 일관된 및 명확하게 설명된 API를 생성하는 데 도움을 줍니다.
• Kotlin/Native에서 Swift 및 Objective-C에서 suspending 함수를 사용할 수 있는 지원.
• Kotlin/JS의 개선된 Gradle DSL, 기본적으로 CSS 지원 및 공통 내보내기 주석이 있습니다.

 

변경 로그에서 변경 사항의 전체 목록을 찾을 수 있습니다. 항상 외부 기여자분들께 감사드립니다.

미리보기를 시도하고 피드백을 공유해 주시면 매우 감사하겠습니다.

 

계층적 프로젝트 구조를 사용하여 여러 대상 간에 코드를 공유

 

새로운 계층 구조 프로젝트 지원을 통해 다중 플랫폼 프로젝트에서 여러 대상 간에 코드를 공유할 수 있습니다. 이전에는 다중 플랫폼 프로젝트에 코드를 추가하면 해당 코드를 플랫폼별 소스 세트(하나의 대상에만 제한되며 다른 플랫폼에서 재사용할 수 없음) 또는 commonMain 또는 commonTest와 같은 공통 소스 세트에 배치할 수 있었습니다. 공통 소스 세트에서는 플랫폼별 API를 사용하기 위해 플랫폼별 구현이 필요한 expect 선언만 사용할 수 있었습니다.

이로 인해 모든 대상 간에 코드를 공유하기는 쉬웠지만 일부 대상 간에만 코드를 공유하기는 힘들었습니다. 특히 공통 로직과 서드파티 API를 재사용할 수 있는 유사한 대상이 많은 경우에 어려움이 있었습니다.

예를 들어 iOS를 대상으로 하는 전형적인 다중 플랫폼 프로젝트에서 iOS ARM64 기기를 위한 대상과 x64 시뮬레이터를 위한 대상 두 가지가 있습니다. 이들은 별도의 플랫폼별 소스 세트를 가지고 있지만 실제로는 기기와 시뮬레이터를 위한 다른 코드가 필요하지 않으며 의존성이 매우 유사합니다. 따라서 iOS 특정 코드를 이들 간에 공유하려면 좋을 것입니다.

이제 계층 구조 프로젝트 지원을 사용하여 이를 수행할 수 있습니다. 이 지원은 대상이 이를 사용하는 소스 세트마다 사용 가능한 API 및 언어 기능을 추론하고 적응시킵니다.

 

사용 방법:

계층 구조 프로젝트 지원이 있는 Kotlin 1.4 M2 플러그인을 설치합니다.

프로젝트의 gradle.properties 파일에 다음 플래그를 추가합니다.

kotlin.mpp.enableGranularSourceSetsMetadata=true

계층 구조 및 모든 다중 플랫폼 프로젝트에는 Kotlin 1.4-M2 이상을 사용하기 위해 Gradle 6.0 이상이 필요합니다.

일반적인 다중 대상 시나리오에 대한 대상 바로 가기로 사용 가능한 계층 구조를 만들 수 있습니다. 예를 들어 iOS 기기 및 시뮬레이터 대상 및 iosMain 및 iosTest 소스 세트와 함께 다음과 같이 두 가지 iOS 대상을 만들 수 있습니다.

 

kotlin {
    ios() // iOS device and simulator targets; iosMain and iosTest source sets
}

다른 대상 조합의 경우, 소스 세트를 dependsOn 관계로 수동으로 연결하여 계층 구조를 만들 수 있습니다.

 

 

kotlin {
    linuxX64()
    mingwX64()
    macosX64()

    sourceSets {
        // ... 다른 소스 세트 정의 ...

        // 공통 코드를 사용하는 데스크톱 메인 소스 세트
        val desktopMain by creating {
            dependsOn(commonMain)
        }

        // 리눅스 x64 메인 소스 세트는 공통 코드에 의존
        val linuxX64Main by getting {
            dependsOn(desktopMain)
        }

        // 윈도우 x64 메인 소스 세트도 공통 코드에 의존
        val mingwX64Main by getting {
            dependsOn(desktopMain)
        }

        // macOS x64 메인 소스 세트도 공통 코드에 의존
        val macosX64Main by getting {
            dependsOn(desktopMain)
        }
    }
}

다음 대상 조합에 대한 공유 소스 세트를 가질 수 있습니다.

• JVM + JS + Native
• JVM + Native
• JS + Native
• JVM + JS
• Native

일부 조합에 대한 소스 세트를 공유하는 것은 아직 지원되지 않습니다.

계층 구조 프로젝트 지원을 사용하여 코드를 공유하면 프로젝트 구조 정보와 함께 라이브러리 아티팩트에 공유 소스 세트의 API가 포함됩니다. 이 라이브러리를 사용하면 프로젝트의 공유 소스 세트가 해당 소스 세트의 대상에 사용 가능한 라이브러리의 API에 정확히 액세스할 수 있습니다.

계층 구조 기능에 대한 피드백을 공유할 때 계층 구조 프로젝트는 아직 기술 미리보기 상태이며 개발 중입니다. 알려진 문제를 확인하고 이를 수정할 예정이며 이 중 일부는 해결책이 있습니다.

이 기능을 사용하면 플랫폼에 따라 다르지 않고 공통적으로 사용 가능한 코드를 더 쉽게 공유할 수 있습니다.

 

현재로서 다음과 같은 조합에 대한 소스 세트 공유를 지원하지 않습니다:

• 여러 JVM 대상
• JVM + Android 대상
• 여러 JS 대상

이러한 대상 조합을 공유하려면 feedback@kotlinlang.org로 이메일을 보내 주십시오. 일반적으로 사용되는 조합을 우선적으로 처리하는 데 도움이 될 것입니다.

라이브러리에서 코드 공유

계층 구조 프로젝트 구조 덕분에 라이브러리도 대상의 하위 집합을 위한 공통 API를 제공할 수 있습니다.

라이브러리가 게시되면 공유 소스 세트의 API는 프로젝트 구조에 대한 정보와 함께 라이브러리 아티팩트에 포함됩니다. 이 라이브러리를 사용할 때 프로젝트의 공유 소스 세트는 각 소스 세트의 대상에 사용 가능한 라이브러리의 API에 정확하게 액세스합니다.

예를 들어 kotlinx.coroutines 저장소의 native-mt 브랜치에서 다음 소스 세트 계층 구조를 살펴보세요:

 

concurrent 소스 세트는 JVM 및 네이티브 대상을 위해 runBlocking 함수를 선언하고 컴파일합니다. 이를 의존할 수 있으며, JVM 대상 및 네이티브 대상 사이에서 공유되는 소스 세트에서 runBlocking()을 호출할 수 있습니다. 이는 라이브러리의 concurrent 소스 세트의 "대상 서명"과 일치하기 때문입니다.

의존성을 한 번만 지정
이제 사용 중인 라이브러리의 다른 변형에 대한 의존성을 공유 및 플랫폼별 소스 세트에서 여러 번 지정하는 대신 공유 소스 세트에서 의존성을 한 번만 지정해야 합니다.

 

kotlin {
    sourceSets {
        val desktopMain by creating {
            dependencies {
                implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.7-1.4-M2")
            }
        }
    }
}

플랫폼을 지정하는 접미사가 있는 kotlinx 라이브러리 아티팩트 이름을 더 이상 사용하지 말아야 합니다. 예를 들어 -common, -native 또는 유사한 접미사를 사용하지 마십시오. 대신 예제에서 보여준 것처럼 라이브러리의 기본 아티팩트 이름을 사용하십시오 (kotlinx-coroutines-core). 그러나 이 변경은 현재로서 stdlib 및 kotlin.test 라이브러리(stdlib-common 및 test-common)에는 영향을 주지 않습니다. 이에 대한 수정은 나중에 이루어질 것입니다.

특정 플랫폼에 대한 종속성이 필요한 경우, -jvm 또는 -js와 같은 플랫폼별 변형을 사용할 수 있습니다. 예를 들어 kotlinx-coroutines-core-jvm과 같이 사용할 수 있습니다.

계층 구조에서 네이티브 라이브러리 활용

여러 네이티브 대상에서 공유되는 Foundation, UIKit 및 posix와 같은 플랫폼 종속 라이브러리를 사용할 수 있습니다. 이를 통해 플랫폼별 종속성에 제한받지 않고 더 많은 네이티브 코드를 공유할 수 있습니다.

추가 단계가 필요하지 않습니다. IntelliJ IDEA는 공유 코드에서 사용할 수 있는 일반 선언을 감지하는 데 도움을 줄 것입니다.

그러나 몇 가지 제한 사항이 있습니다:

• 이 접근 방식은 플랫폼별 소스 세트와 공유되는 네이티브 소스 세트에만 작동합니다. 소스 세트 계층 구조의 더 높은 수준에서 공유되는 네이티브 소스 세트에는 작동하지 않습니다.
  예를 들어 nativeDarwinMain이 watchosMain 및 iosMain의 상위 부모이며, iosMain에는 iosArm64Main 및 iosX64Main 두 개의 하위 소스 세트가 있는 경우, 플랫폼 종속 라이브러리를 iosMain에서만 사용할 수 있으며 nativeDarwinMain에서는 사용할 수 없습니다.
• 이 접근 방식은 Kotlin/Native와 함께 제공되는 interop 라이브러리에만 작동합니다. 자세한 내용은 기술적 세부 사항을 확인하십시오.

사용 방법

공유 소스 세트에서 플랫폼 종속 라이브러리 사용을 활성화하려면 다음을 gradle.properties에 추가하십시오:

 

kotlin.mpp.enableGranularSourceSetsMetadata=true
kotlin.native.enableDependencyPropagation=false

계층 구조 프로젝트 구조에 대한 피드백 공유

계층 구조 프로젝트 구조는 현재 기술 미리보기 단계에 있으며 아직 개발 중입니다. 고칠 알려진 문제를 확인할 수 있습니다. 그 중 일부에는 해결 방법이 있습니다.

Kotlin Slack의 #multiplatform 채널에서 도움을 요청하고 문제를 YouTrack 이슈 트래커에 보고하십시오. 이것은 복잡하고 중요한 기능이므로 피드백은 특히 유용할 것입니다.

 

Gradle 6.0 이상이 필요한 멀티플랫폼 프로젝트

Kotlin 1.4-M2부터 모든 멀티플랫폼 프로젝트는 Gradle 6.0 이상이 필요합니다. kotlin-multiplatform 플러그인을 사용하는 프로젝트의 Gradle을 업그레이드해야 합니다.

새로운 유연한 프로젝트 마법사

새로운 유연한 Kotlin 프로젝트 마법사를 사용하면 멀티플랫폼 프로젝트를 구성하는 것이 어려울 수 있는 여러 유형의 Kotlin 프로젝트를 쉽게 만들고 구성할 수 있는 단일 장소가 제공됩니다.

 

이전에는 다른 구성 옵션을 제공하는 다른 위치에서 Kotlin 프로젝트를 생성할 수 있었습니다. 이제 이것을 수행하는 단일한 위치가 있으며 이는 단순함과 유연성을 제공합니다.

1. 하려는 작업에 따라 프로젝트 템플릿을 선택합니다.

2. 빌드 시스템을 선택합니다 - Gradle (Kotlin 또는 Groovy DSL), Maven 또는 IntelliJ. 마법사는 선택한 프로젝트 템플릿에 대한 지원 빌드 시스템만 표시합니다.
3. 주 화면에서 프로젝트 구조를 미리 보기합니다.

 

그런 다음 프로젝트 생성을 완료하거나 선택적으로 다음 화면에서 프로젝트를 구성할 수 있습니다.

4. 이 프로젝트 템플릿에 대해 지원되는 모듈 및 타겟을 추가/제거합니다.
5. 모듈 및 타겟 설정을 구성합니다. 예를 들어, 대상 JVM 버전, 대상 템플릿 및 테스트 프레임워크를 설정할 수 있습니다.

6. 모듈 간의 종속성 설정 방법은 다음과 같습니다:

• iOS와 멀티플랫폼 모듈 간의 종속성 설정
• Android와 멀티플랫폼 모듈 간의 종속성 설정
• JVM 모듈 간의 종속성 설정

미래에는 Kotlin 프로젝트 마법사를 더 유연하게 만들기 위해 추가 구성 옵션과 템플릿을 추가할 예정입니다.

사용 방법

 

1. 1.4-M2 Kotlin 플러그인을 설치합니다.
2. IntelliJ IDEA에서 File | New | Project를 클릭합니다.
3. 왼쪽 패널에서 Kotlin (실험적인 마법사)를 선택합니다.
4. 새로운 Kotlin 프로젝트를 생성합니다.

 

일관되고 명확한 API와 명시적 API 모드를 통한 향상

라이브러리 작성자가 일관되고 명확한 API를 생성하는 데 도움이 되는 새로운 컴파일러 모드를 소개합니다. 이 명시적 API 모드에서 컴파일러는 라이브러리의 공개 API로 노출되는 선언에 대한 추가적인 검사를 수행합니다:

• 디폴트 가시성이 이러한 선언을 공개 API로 노출시키는 경우 가시성 수정자가 필요합니다. 이를 통해 선언이 공개 API로 무심코 노출되지 않도록 보장합니다.
• 공개 API로 노출되는 속성과 함수에 대한 명시적인 유형 명세가 필요합니다. 이는 API 사용자가 사용하는 API 멤버의 유형을 인식하도록 보장합니다.

 

이러한 검사는 구성에 따라 오류(엄격한 모드) 또는 경고(경고 모드)를 생성할 수 있습니다.

우리는 미래에 라이브러리 작성 경험을 더 개선하기 위해 더 많은 검사를 추가할 계획이 있습니다. 이미 명시적 API 모드를 시도하고 피드백을 공유할 수 있습니다.

명시적 API 모드에서 모듈을 컴파일하려면 Gradle 빌드 스크립트에 다음중 하나를 추가하십시오:

 

kotlin {
    explicitApi() // 엄격한 모드
    // 또는
    explicitApiWarning() // 경고 모드
}

Groovy를 사용하는 경우 대안 구문을 사용할 수 있습니다:

 

kotlin {
    explicitApi = 'strict'
    // 또는
    explicitApi = 'warning'
}

명령 줄 컴파일러를 사용하는 경우 다음과 같이 엄격하거나 경고 모드와 함께 -Xexplicit-api 컴파일러 옵션을 사용합니다:

 

-Xexplicit-api={strict|warning}

Kotlin/Native에서 서스펜딩 함수 지원과 기타 개선 사항

이 미리보기에서는 Swift 및 Objective-C에서 Kotlin의 서스펜딩 함수를 지원하는 것을 드디어 추가하고 있으며, 현재는 기본적인 경우만 지원합니다. 우리는 더 많은 코루틴의 기능을 Swift 및 Objective-C 애플리케이션에서 제공하기 위해 계속 노력하고 있습니다. 또한 Kotlin/Native의 성능 및 안정성에 대한 몇 가지 결과를 제공할 준비가 되었습니다.

Swift 및 Objective-C에서 Kotlin의 서스펜딩 함수 지원

우리는 Swift 및 Objective-C 코드에서 Kotlin 기능을 사용하는 지원을 계속 확대하고 있습니다. 이전 버전에서 알려진 단점 중 하나는 Kotlin 코루틴의 불완전한 지원이었습니다. 이전에는 Swift 또는 Objective-C 코드에서 Kotlin 코루틴을 사용할 수 없었습니다.

M2 미리보기에서는 Swift 및 Objective-C에서 서스펜딩 함수를 기본적으로 지원하는 기본 지원을 제공하게 되어 기쁩니다. 이제 Kotlin 모듈을 Apple 프레임워크로 컴파일할 때, 서스펜딩 함수는 Swift/Objective-C 용어로는 콜백 함수(completionHandler)로 사용할 수 있습니다. 생성된 프레임워크의 헤더에 이러한 함수가 포함되어 있으면 Swift 또는 Objective-C 코드에서 이를 호출하고 오버라이드할 수 있습니다.

예를 들어, 다음과 같은 Kotlin 함수를 작성하면:

 

suspend fun queryData(id: Int): String = ...

Swift에서 이렇게 호출할 수 있습니다:

 

queryData(id: 17) { result, error in
    if let e = error {
        print("ERROR: \(e)")
    } else {
        print(result!)
    }
}

다만, M2 미리보기에서는 서스펜딩 함수를 주 스레드에서만 호출할 수 있습니다.

거터 아이콘을 사용하여 Kotlin/Native 코드 실행

이전에는 Kotlin/Native 코드를 터미널에서 실행하거나 IntelliJ IDEA에서 Gradle 작업을 실행하여만 실행할 수 있었습니다. 이제 다른 Kotlin 코드와 유사하게 거터 아이콘을 사용하여 쉽게 실행할 수 있습니다.

 

C 인터옵의 성능 개선

Kotlin/Native의 성능을 향상하기 위해 C 인터옵 라이브러리 빌드 방식을 재작업했습니다. (이러한 라이브러리는 Kotlin 코드에서 C 및 Objective-C 라이브러리의 선언을 사용할 수 있게 하는 아티팩트입니다.) 이 변경 사항은 내부적으로 이루어졌지만, 보이는 것은 성능 향상과 이전보다 작은 아티팩트입니다. 새로운 도구는 이전보다 최대 4배 빠르게 인터옵 라이브러리를 생성하며, 아티팩트 크기는 이전보다 25%에서 30%로 줄었습니다!

이제 C 인터옵 라이브러리를 사용하는 것도 더 빨라졌으며, Kotlin 1.4-M2로 C 인터옵을 사용하는 Kotlin 프로젝트를 컴파일하는 데 걸리는 시간이 감소했습니다.

컴파일러 캐싱 및 Gradle 데몬 사용의 안정화

1.3.70에서는 Kotlin/Native 컴파일의 성능을 향상시키기 위해 두 가지 새로운 기능을 도입했습니다. 프로젝트 종속성 캐싱 및 Gradle 데몬에서 컴파일러 실행입니다. 이러한 기능은 아직 진행 중인 작업이었으므로 일부 사용자는 특정 경우에 안정성 문제와 안정성 부족을 경험했을 수 있습니다.

여러분의 피드백 덕분에 이러한 기능의 문제를 해결하고 전반적인 안정성을 향상시켰습니다. 따라서 이러한 기능에 문제가 있었거나 Kotlin/Native의 최근 버전을 시도할 기회가 없었다면 지금이 시도해보기에 좋은 시기입니다.

 

Kotlin/JS 개선사항

1.4-M2 버전에서 Kotlin의 JavaScript 타겟은 다른 Kotlin 타겟의 Gradle 네이밍 규칙과 더 밀접하게 맞추고 있습니다. 또한 컴파일러 설정에 대한 더 세분화된 제어를 추가하며 @JsExport 어노테이션을 통합하고 기본적으로 웹팩을 통해 CSS 지원을 활성화합니다.

Gradle DSL 변경

네이밍 변경

다른 Kotlin 타겟과 더 일치하도록하기 위해 Kotlin/JS Gradle 구성에서 일반적으로 사용되는 몇 가지 부분의 이름을 변경했습니다. Kotlin/JS Gradle 프로젝트의 기본 구성 블록을 1.4-M2에서 고려하면 두 가지 이름 변경 사항이 나타납니다.

 

kotlin {
    js {
        nodejs() // 그리고/또는 browser()
        binaries.executable()
    }
}

 

• target은 js로 변경되며 이로써 Kotlin 멀티플랫폼 플러그인과 구문이 일치하게 되었습니다.
• Kotlin 1.4-M1에서 도입된 produceExecutable()은 binaries.executable()로 변경되어 Kotlin/Native의 네이밍과 일관성을 갖게 되었습니다.

binaries.executable()이 무엇을 하는지 자세히 알고 싶다면 1.4-M1 블로그 포스트의 "Kotlin/JS | Gradle DSL 변경" 섹션을 참조하세요.

프로젝트별 컴파일러 설정

Kotlin 1.4-M1에서 최적화된 DCE, TypeScript 선언 미리보기 등을 갖춘 새로운 IR 컴파일러 백엔드를 처음 도입했습니다. 이 백엔드 모드를 기본, IR 또는 둘 다 컴파일러 모드로 전환하기 위한 설정을 gradle.properties에서 지정하는 것이었습니다. M2에서는 Gradle 구성에서 직접 프로젝트 단위로 사용되는 컴파일러 모드를 더 세분화된 제어를 도입했습니다.

다른 컴파일러 모드로 전환하려면 Gradle 빌드 스크립트의 js 함수에 컴파일러 유형을 전달하십시오. 예를 들어:

 

kotlin {
    js(IR) { // 또는: LEGACY, BOTH
        // . . .
    }
}

이렇게 프로젝트에 대한 컴파일러 유형을 설정하면 gradle.properties에서 지정한 기본 설정을 재정의합니다.

Gradle을 통한 webpack에서 css-loader 지원

Kotlin/JS Gradle 플러그인은 기본적으로 브라우저를 대상으로 아티팩트를 생성하기 위해 웹팩을 사용합니다. 이로 인해 프로젝트를 사용자 지정할 수 있는 많은 설정이 있습니다. 모든 옵션은 프로젝트를 빌드하는 데 사용되는 웹팩 구성 파일을 직접 수정하여 변경할 수 있지만, 가장 일반적으로 사용되는 설정에 대한 액세스를 Gradle DSL을 통해 직접 제공하려고 합니다.

Kotlin 1.4-M2에서는 브라우저를 대상으로하는 프로젝트에서 기본적으로 웹팩의 css-loader를 활성화합니다. 이는 CSS를 프로젝트에 추가하고 스타일 시트를 포함하는 종속성을 추가할 때 추가 구성 없이 대부분의 경우 작동합니다. 이전에는 이러한 상황에서 "Module parse failed: Unexpected character '@' (14:0)"와 같은 오류가 발생할 수 있었습니다.

이 CSS 통합의 동작을 조정하려면 js.browser.webpackTask.cssSettings를 사용하여 변경할 수 있습니다.

cssSettings.enabled를 사용하여 프로젝트에서 css-loader를 사용할지 여부를 변경할 수 있습니다 (기본적으로 활성화됨).

cssSettings.mode를 사용하여 만난 CSS를 어떻게 처리할지 지정할 수 있습니다. 다음 값이 사용 가능합니다.

• "inline" (기본값): 스타일은 전역 <style> 태그에 추가됩니다.
• "extract": 스타일은 별도의 파일로 추출됩니다. 그런 다음 HTML 페이지에서 포함할 수 있습니다.
• "import": 스타일은 문자열로 처리됩니다. 이것은 코드에서 CSS에 액세스해야 하는 경우에 유용할 수 있습니다 (예: val styles = require("main.css")).

 

같은 프로젝트에 대해 서로 다른 모드를 사용하려면 cssSettings.rules를 사용할 수 있습니다. 여기에서 각각 모드와 포함 및 제외 패턴을 정의하는 KotlinWebpackCssRules 목록을 지정할 수 있습니다. 이러한 패턴에 대해 더 알고 싶다면 웹팩 문서의 include 및 exclude 규칙에 대한 섹션을 참조하십시오.

사용자 지정 가능한 모듈 이름

Gradle 빌드 스크립트에서 직접 JavaScript 모듈 이름을 변경할 수 있습니다.

 

js {
    moduleName = "myModuleName"
}

이렇게 하면 build/js/packages/myModuleName에 생성되는 모듈의 이름이 변경되며 해당 .js 및 .d.ts 파일 이름도 변경됩니다. 이는 build/distributions의 웹팩 출력에 영향을 주지 않습니다. 웹팩 파일의 이름을 변경하려면 js.browser.webpackTask.outputFileName을 사용할 수 있습니다.

공통 코드 @JsExport 어노테이션

IR 컴파일러 백엔드를 사용할 때 JavaScript 또는 TypeScript에서 최상위 선언을 사용할 수 있도록 하는 @JsExport 어노테이션이 이제 공통 코드에서 사용할 수 있습니다. 이것은 사용자 정의 어노테이션과 typealias를 도입할 필요 없게 하며 멀티플랫폼 Kotlin 프로젝트에서 편리하게 JavaScript 라이브러리를 빌드하는 방법을 열어줍니다.

추가적인 사용 편의성 개선 사항 및 주목할만한 수정 사항

 

• 브라우저와 노드js 대상의 일반 작업에 사용되는 Gradle 작업은 이제 별도의 작업 그룹으로 그룹화됩니다. kotlin browser 및 kotlin node 그룹은 IntelliJ IDEA의 Gradle 도구 창에서 또는 ./gradlew tasks --all을 통해 작업을 나열할 때 나타납니다.
• 노드.js 대상의 테스트를 실행할 때 디버거가 이제 중단점에서 제대로 중지됩니다.
• 컴파일에 모두 모드를 사용하는 프로젝트와 라이브러리의 경우 klib 종속성이 이제 제대로 해결됩니다.

 

호환성

Kotlin 1.4는 일부 특정 케이스에서 1.3과 역호환되지 않음에 유의하십시오. 이러한 모든 케이스는 언어 위원회에서 주의 깊게 검토되었으며 "호환성 가이드"에 나열될 것입니다(이와 유사한 것). 현재 이 목록은 YouTrack에서 찾을 수 있습니다.

프리릴리스 노트

역호환성 보장은 프리릴리스 버전을 포함하지 않습니다. 기능 및 API는 후속 릴리스에서 변경될 수 있습니다. 최종 RC에 도달하면 프리릴리스 버전에서 생성된 모든 이진 파일이 컴파일러에 의해 금지될 것이며, 1.4-Mx로 컴파일된 모든 것을 다시 컴파일해야 합니다.

최신 기능을 시도하는 방법

항상 온라인에서 play.kotl.in을 통해 Kotlin을 시도해 볼 수 있습니다.

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

미리 보기 버전을 설치하기 전에 만들어진 기존 프로젝트에서 작업하려면 Gradle 또는 Maven에서 미리보기 버전을 위한 빌드를 구성해야 합니다.

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

이 릴리스와 함께 발표된 라이브러리의 다음 버전을 사용할 수 있습니다:

• kotlinx.atomicfu 버전: 0.14.3-1.4-M2
• kotlinx.coroutines 버전: 1.3.7-1.4-M2
• kotlinx.serialization 버전: 0.20.0-1.4-M2
• ktor 버전: 1.3.2-1.4-M2

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

 

피드백 공유

버그를 발견하고 이슈 트래커에 보고해 주시면 매우 감사하겠습니다. 중요한 문제들을 최종 릴리스 이전에 수정하려고 노력할 것이므로 문제가 해결되기를 기다리지 않고 다음 Kotlin 릴리스를 기다릴 필요가 없을 것입니다.

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

Kotlin으로 함께하십시오!

외부 기여

외부 기여자들의 풀 리퀘스트가 이 릴리스에 포함된 것에 대해 모든 외부 기여자들에게 감사드립니다.

 

• Toshiaki Kameyama
• Victor Turansky
• Jinseong Jeon
• Steven Schäfer
• Juan Chen
• Mark Punzalan
• Kristoffer Andersen
• Mads Ager
• Nick
• Polina Koval
• Konstantin Virolainen
• n-p-s
• Jiaxiang Chen
• Matthew Gharrity
• Martynas Sateika
• Nadezhda Petelimova
• Philippe Ombredanne
• Pierre-Luc Carmel Biron
• Kevin Bierhoff
• Scott Weber
• Miguel Serra
• Ivan Gavrilovic
• Irene Dea
• Harry
• Stanislav Ruban
• Brian Plummer
• Adam McNeilly

 

원문

 

https://blog.jetbrains.com/kotlin/2020/06/kotlin-1-4-m2-released/