Kotlin 1.4-M2가 출시되었습니다

Jessie Cho

시간이 빠르게 흘러, 드디어 오늘 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에서 일시 중지 함수를 사용할 수 있습니다.
• Kotlin/JS의 개선된 Gradle DSL, 별도 설정 없이 제공되는 CSS 지원, 일반적인 내보내기 어노테이션.

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

테스트 버전을 사용하고 피드백을 공유해주신다면 정말 감사하겠습니다.

계층적 프로젝트 구조를 통해 여러 대상에서 코드 공유

새로운 계층적 프로젝트 구조 지원을 통해 멀티플랫폼 프로젝트에서 여러 대상사이에서 코드를 공유할 수 있습니다.

기존의 경우 멀티플랫폼 프로젝트에 추가된 모든 코드는 한 가지 대상으로만 제한되는 특정 플랫폼 전용 소스 집합에만 배치되어 다른 플랫폼에서의 코드 재사용이 불가능하거나 프로젝트의 모든 플랫폼에서 공유된 commonMain 또는 commonTest와 같은 일반 소스 집합에만 배치되었습니다. 일반 소스 집합의 경우 특정 플랫폼 전용의 actual 구현을 필요로 하는 expect 선언을 사용하여 플랫폼 별 API만을 호출할 수 있습니다.

이러한 방식으로 모든 대상 간에 코드 공유는 간편하게 이루어졌지만 일부 대상 간의 코드 공유는 여전히 만만치 않은 작업이었습니다. 특히 많은 일반 로직과 타사 API 재사용이 필요할 수 있는 유사한 대상 간의 코드 공유는 더욱 어려웠습니다.

예를 들어 iOS를 대상으로 하는 일반적인 멀티플랫폼 프로젝트의 경우 iOS 관련 대상은 iOS ARM64 기기용 및 x64 시뮬레이터용으로 두 가지였습니다. 이 두 가지에 대한 별도의 플랫폼별 소스 집합이 있었지만 실제로는 기기와 시뮬레이터에 다른 코드가 필요한 상황은 극히 드물었고, 종속 요소 역시 매우 유사했습니다. 그러므로 두 플랫폼 간에 iOS 고유 코드 공유가 가능할 수 있었습니다.

분명히 이런 상황에서라면 iOS 기기 및 시뮬레이터 양쪽에서 일반적으로 사용되는 모든 API를 직접 호출할 수 있는 Kotlin/Native 코드로 두 iOS 대상에 공유된 소스 집합을 보유하는 것이 이상적이겠죠.

이제 계층 프로젝트 구조 지원을 통해서도 이 작업이 가능합니다. 해당 지원은 어떤 대상에서 소비하는지에 따라 각 소스 집합에서 이용 가능한 API 및 언어 기능을 추론하고 도입합니다.

사용 방법

지금 바로 계층 프로젝트 지원이 포함된 1.4 M2 Kotlin 플러그인을 설치하세요!

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

kotlin.mpp.enableGranularSourceSetsMetadata=true

Kotlin 1.4-M2부터는 계층 구조 및 모든 멀티플랫폼 프로젝트에 Gradle 6.0 이상의 버전이 필요합니다.

일반적인 멀티 대상 시나리오에서 지원되는 대상 단축키를 사용하거나 수동으로 소스 집합에 연결하여 계층 구조를 생성할 수 있습니다.

예를 들어, ios() 단축키로 2개의 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)
       }

       val linuxX64Main by getting {
           dependsOn(desktopMain)
       }

       val mingwX64Main by getting {
           dependsOn(desktopMain)
       }

       val macosX64Main by getting {
           dependsOn(desktopMain)
       }
   }
}

다음 대상 조합에 대한 공유 소스 집합을 생성할 수 있습니다.

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

현재로서는 다음 조합에 대한 소스 집합 공유는 지원되지 않습니다.

• 일부 JVM 대상
• JVM + Android 대상
• 일부 JS 대상

feedback@kotlinlang.org로 이메일을 보내 여러분의 대상 조합을 공유해 주세요. 여러분의 피드백은 더욱 자주 사용되는 조합을 우선적으로 개발하는 데 도움이 됩니다.

라이브러리에서 코드 공유

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

라이브러리를 게시하면 공유 소스 집합의 API 및 프로젝트 구조와 관련한 정보가 라이브러리 아티팩트에 삽입됩니다. 그 후 해당 라이브러리를 사용할 때 ,프로젝트의 공유 소스 집합이 각 소스 집합의 대상에 사용 가능한 라이브러리 API에 정확하게 액세스할 수 있습니다.

예를 들어 kotlinx.coroutines 저장소의 native-mt 브랜치에서 다음 소스 집합 계층을 확인해 보세요.

동시 실행 소스 집합은 runBlocking 함수를 선언하고 JVM 및 네이티브 대상에 컴파일됩니다. 이에 따라 JVM 대상과 네티이브 대상 간에 공유된 소스 집합의 runBlocking() 함수를 호출할 수 있습다. 그 이유는 해당 함수가 라이브러리 concurrent소스 집합에 포함된 “대상 시그니처”에 부합하기 때문입니다.

단 한 번의 종속 요소 지정

이제 종속 요소가 사용되는 공유 및 플랫폼별 소스 집합의 동일한 라이브러리에서 여러 변형으로 종속 요소를 지정하는 대신 공유 소스 집합에서 종속요소를 단 한 번만 지정할 수 있습니다.

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

-common, -native와 같이 플랫폼을 지정하는 접미어가 포함된 kotlinx 라이브러리 아티팩트 이름은 이제 지원되지 않으므로 사용하지 마십시오. 위 사례에도 나와있듯이, kotlinx-coroutines-core처럼 라이브러리 기반 아티팩트 이름을 대신 사용하세요. 하지만 현재 이 변경 사항이 stdlib 및 kotlin.test 라이브러리(stdlib-common 및 test-common)에 영향을 미치는 것은 아니며, 이는 향후 다뤄질 예정입니다.

특정 플랫폼 전용의 종속 요소가 필요한 경우 표준의 플랫폼별 변형 또는 -jvm나 -js, 예시의 kotlinx-coroutines-core-jvm과 같은 접미어를 포함한 kotlinx 라이브러리를 사용할 수 있습니다.

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

여러 네이티브 대상에 공유된 소스 집합에서 Foundation, UIKit 및 posix와 같은 플랫폼 종속적 라이브러리를 사용할 수 있습니다. 이를 통해 특정 플랫폼 전용 종속 요소의 제한 없이 더 많은 네이티브 코드를 공유할 수 있는 것이죠.

모든 것이 자동으로 처리되므므로 추가 단계는 필요하지 않습니다. IntelliJ IDEA는 공유 코드에서 사용 가능한 일반적인 선언을 감지하는 데 도움을 줍니다.

하지만 다음과 같은 일부 제한사항을 염두에 두시길 바랍니다.

• 이 방식은 플랫폼별 소스 집합에 공유된 네이티브 소스 집합에만 적합합니다. 더 높은 수준의 소스 집합 계층에서 공유되는 기본 소스 집합에는 작동하지 않습니다.
  예를 들어 watchosMain 및 iosMain의 상위 수준에 nativeDarwinMain이 있고, iosMain에 대한 하위 수준에 iosArm64Main 및 iosX64Main이 존재할 경우 iosMain에 대한 플랫폼 종속적 라이브러리만 사용 가능하며, nativeDarwinMain에 대한 라이브러리는 지원되지 않습니다.
• 이 방식은 Kotlin/Native로 지원되는 상호 운용성 라이브러리에만 적합합니다.

자세한 내용은 기술적 세부 사항을 참조하세요.

사용 방법

공유된 소스 집합에서 플랫폼 종속적 라이브러리 사용을 활성화하려면 다음 코드를 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 프로젝트를 더욱 간편하게 생성하고 구성할 수 있습니다. UI 없이는 구성이 까다로운 멀티플랫폼 프로젝트도 지원됩니다.

기존에는 여러 구성 옵션을 제공하는 여러 위치에서 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(Experimental Wizard)를 선택합니다.
4. 신규 Kotlin 프로젝트를 생성합니다.

명시적 API 모드로 일관성 있고 상세히 설명된 API

라이브러리 작성자가 일관성 있고 상세히 설명된 API를 생성하도록 지원하는 새로운 컴파일러를 도입하였습니다. 명시적 API 모드는, 컴파일러가 라이브러리 공용 API에 노출된 선언에 대한 추가 검사를 실행합니다.

• 기본 가시성이 선언을 공용 API에 노출할 경우 가시성 한정자가 필요합니다. 이를 사용하면 의도치 않게 선언을 공용으로 노출하는 일을 방지할 수 있습니다.
• 공용 API에 노출된 속성과 함수에는 명시적 유형 지정자가 필요합니다. 이를 통해 API 사용자는 본인이 사용하는 API 멤버를 인식할 수 있습니다.

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

앞으로도 라이브러리 작성 경험을 개선하기 위해 더 많은 검사를 추가할 계획입니다. 자세한 내용은 다음 KEEP에서 확인하시고, 이미 명시적 API 모드를 사용하고 있다면 피드백을 공유해 주세요.

명시적 API 모드에서 모듈을 컴파일하려면 다음 줄을 Gradle 빌드 스크립트에 추가하세요.

kotlin {   
   explicitApi() // for strict mode
   // or
   explicitApiWarning() // for warning mode
}

Groovy의 경우 다음 구문을 대신 사용할 수 있습니다.

kotlin {   
   explicitApi = 'strict'
   // or
   explicitApi = 'warning'
}

명령줄 컴파일러를 사용하신다면 strict 또는 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 코드에서 지원되지 않았던 것이죠.

한편, 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 코드 실행

기존에는 터미널에서 혹은 IntelliJ IDEA의 Gradle 작업 실행을 통해서만 Kotlin/Native 코드를 실행할 수 있었습니다. 이제 다른 Kotlin 코드와 마찬가지로 여백 아이콘을 활용해 간편하게 실행하세요.

C 상호 운용성 성능 개선

Kotlin/Native 성능 개선의 일환으로 C interop 라이브러리 빌드 방식을 개편했습니다. (해당 라이브러리는 Kotlin 코드에서 C 및 Objective-C 라이브러리에서 선언을 사용하는 데 필요한 아티팩트입니다) 변경 사항은 내부적으로 구현되었지만 향상된 성능 및 축소된 아티팩트 크기는 확연히 눈에 띕니다. 새로운 툴링은 기존보다 최대 4배 빠르게 interop 라이브러리를 생성하고 아티팩트는 이전 크기의 25% ~ 30%로 감소했습니다!

Kotlin 1.4-M2에서는 C 상호 운용성을 갖춘 Kotlin 프로젝트 컴파일링 시간이 단축되어 interop 라이브러리를 더욱 빠르게 사용할 수 있습니다.

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

1.3.70 버전에서는 Kotlin/Native 컴파일 성능을 개선하기 위한 두 가지 신규 기능을 도입하였습니다. 바로 프로젝트 종속 요소 캐싱 및 Gradle 데몬의 컴파일러 실행 기능입니다. 이 기능은 아직 개발 중이므로 일부 사용자는 이슈나 안정성 부족을 경험했을 수도 있습니다.

여러분의 피드백을 바탕으로 여러 이슈를 수정하였으며 해당 기능의 전반적인 안정성도 개선했습니다. 그렇기에 문제를 겪으셨거나 아직 최신 Kotlin/Native 버전을 사용할 기회가 없었다면 지금 사용해보시는 것도 좋을 것 같습니다.

Kotlin/JS 개선 사항

1.4-M2 버전에서는 Kotlin용 JavaScript 대상이 Gradle 이름 생성 규칙을 다른 Kotlin 대상과 더욱 긴밀하게 조율합니다. 기타 개선 사항으로는 컴파일 설정의 더욱 세밀한 제어, @JsExport 어노테이션의 일반화 및 기본적으로 webpack을 통해 지원되는 CSS 등이 있습니다.

Gradle DSL 변경 사항

이름 변경

다른 Kotlin 대상과 더욱 긴밀한 조율을 위해 Kotlin/JS Gradle 구성에서 자주 사용되는 부분의 이름을 변경했습니다. 1.4-M2에서는 이러한 변경 사항을 Kotlin/JS Gradle 프로젝트용 기본 구성 블록으로 생각해 주세요. 다음과 같이 두 가지 이름 변동이 있습니다.

kotlin {
    js {
        nodejs() // and/or browser()
        binaries.executable()
    }
}

• Kotlin 멀티플랫폼 플러그인에서 사용되는 구문과 일치하도록 target이 js로 변경되었습니다.
• Kotlin 1.4-M1에 도입된 produceExecutable()의 경우 Kotlin/Native 이름과 일치하는 binaries.executable()로 변경되었습니다.

binaries.executable()의 기능에 대해 자세히 알아보시려면 1.4-M1 블로그 게시물의 “Kotlin/JS | Gradle DSL 변경 사항” 섹션을 참조하세요.

프로젝트별 컴파일러 설정

Kotlin 1.4-M1에서 최초로 IR 컴파일러 백엔드를 도입했습니다. 이에 따라 최적화된 DCE, TypeScript 선언 미리보기, 기본, IR 및 두 컴파일러 모드 양쪽에서 전환 가능한 gradle.properties 설정까지 이르는 다양한 기능이 지원되었습니다. M2는 Gradle 구성에서 직접 프로젝트별로 사용 된 컴파일러 모드를 보다 세밀하게 제어할 수 있도록 지원합니다.

다른 컴파일러 모드 간 전환이 필요한 경우 컴파일러 유형을 Gradle 빌드 스크립트의 js 함수로 전달하세요. 다음은 예시입니다.

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

이처럼 프로젝트의 컴파일러 유형을 설정하면 gradle.properties에서 지정된 기본 설정이 재정의됩니다.

Gradle에서 webpack의 css-loader 지원

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

Kotlin 1.4-M2에서는 브라우저를 대상으로 하는 프로젝트에 webpack의 css-loader가 기본적으로 활성화됩니다. 따라서 프로젝트에 CSS 및 스타일시트가 포함된 종속 요소를 추가하면 대부분의 경우 별도의 설정이나 추가 구성 없이 원활히 작동합니다. 기존에는 이런 상황에서 모듈 구문 분석 실패: 예기치 않은 문자 '@' (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 목록을 지정하세요. 각 목록은 모드 및 포함, 제외 패턴을 정의합니다. 패턴에 대한 자세한 내용을 알아보시려면 포함 및 제외 규칙에 관한 webpack 문서를 참조하세요.

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

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

js {
   moduleName = "myModuleName"
}

이 코드는 해당하는 .js, .d.ts 파일 이름을 포함하여 build/js/packages/myModuleName에서 생성된 모듈 이름을 변경합니다. 단, 빌드/배포에서 webpack으로 설정된 출력에는 영향을 미치지 않습니다. webpack으로 설정된 파일 이름을 변경하려면 js.browser.webpackTask.outputFileName을 사용하세요.

일반 코드 @JsExport 어노테이션

IR 컴파일러 백엔드 사용 시 JavaScript 또는 TypeScript에서 지원되는 최상위 선언을 생성하는 데 활용 가능한 @JsExport 어노테이션이 이제 일반 코드에서도 제공됩니다. 해당 어노테이션을 활용하면 사용자 지정 어노테이션 및 유형 별칭 도입할 필요가 없고, 멀티플랫폼 Kotlin 프로젝트에서 편리하게 JavaScript 라이브러리를 빌드할 수 있습니다.

삶의 질을 높이는 추가 개선 사항 및 주요 수정 사항

• 브라우저 및 nodejs 대상으로 하는 일반 연산에 사용되는 Gradle 작업이 별도의 작업 그룹으로 지정됩니다. kotlin browser 및 kotlin node 그룹이 IntelliJ IDEA의 Gradle 창에 표시되거나 ./gradlew tasks --all를 통해 작업 목록에 표시됩니다.
• node.js 대상 테스트를 실행할 때 디버거가 중단점에서 적절히 멈춥니다.
• 컴파일 중 both 모드를 사용하는 프로젝트 및 라이브러리에 대한 klib 종속 요소가 적절히 해결되었습니다.

호환성

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

사전 릴리스 노트

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

최신 기능 사용 방법

언제나처럼 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 채널에 참여하여 질문하고 토론에 참여하거나 새로운 테스트 버전 빌드에 관한 알림을 받아보세요.

Let’s 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

이 게시물은 Ekaterina Volodko가 작성한 Kotlin 1.4-M2 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

감사합니다!