Kotlin 1.4.0-RC 릴리즈

Jessie Cho

2020년 8월 11일

Read this post in other languages:

• English
,
• 日本語
,
• Русский

Kotlin의 다음 버전까지 얼마 안 남았습니다! 다음 주요 버전으로 공개될 프로그래밍 언어의 릴리스 후보인 Kotlin 1.4.0-RC가 릴리즈 되었습니다. 아래 글에서 Kotlin 1.4.0-RC의 변경 사항을 확인하고 Kotlin 1.4.0 공식 출시 전 새로운 기능을 사용해 보세요.

주요 릴리스 버전(1.4-M1, 1.4-M2, 1.4-M3)을 사용하고 피드백을 공유하여 이번 Kotlin 버전이 향상될 수 있도록 지원해주신 모든 분들께 특별한 감사를 전합니다!

이번 게시물에서는 Kotlin 1.4.0-RC 신규 기능 및 핵심 개선 사항을 중점적으로 소개합니다.

• 향상된*.gradle.kts IDE 지원: 스크립트 구성의 명시적 로딩 및 오류 보고 기능이 추가되었습니다.
• 이제 기본적으로 표준 라이브러리 종속 요소를 포함하는 소스 집합: 멀티플랫폼 프로젝트 및 단일 플랫폼 대상의 프로젝트에서 모두 지원됩니다.
• 간소화된 CocoaPods 종속 요소 관리.
• 개선된 Kotlin/JS 통합: npm 종속 요소, CSS , Gradle의 Dukat, 디폴트 컴파일러 백엔드에서 @JsExport 어노테이션 사용 가능.
• Node.js API 바인딩 테스트 버전.
• 코루틴을 디버그하고 심층 재귀 함수를 정의하는 새로운 기능. 이 내용은 별도의 블로그 게시물에서 확인하실 수 있습니다

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 프로젝트를 다시 가져오는 방식으로 변경 사항을 구성에 명시적으로 적용해야 합니다.

Gradle 이전 버전의 경우 에디터에서 Load Configuration(구성 로드)를 클릭하여 스크립트 구성을 수동으로 로드해야 합니다.

Gradle 6.0+이 포함된 IntelliJ IDEA 2020.1에 Load Script Configurations(스크립트 구성 로드)라는 액션을 하나 더 추가하였습니다. 이 액션을 사용하면 전체 프로젝트를 업데이트하지 않고도 스크립트 구성에 변경 사항을 로드할 수 있습니다. 전체 프로젝트를 다시 가져오는 것보다 시간이 훨씬 단축됩니다.

이전에는 Gradle Daemon(백그라운드에서 실행되며 모든 Gradle 관련 작업 및 활동을 담당하는 프로세스) 오류는 별도의 로그 파일에서만 확인 가능했습니다. 이제 Gradle 6.0 이상을 사용하는 경우 Gradle Daemon에서 모든 오류 정보를 직접 반환하고 Build(빌드) 도구 창에 표시합니다. 따라서 시간이 단축되고 번거로움도 줄었습니다.

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")
        }
    }
}

...

xxxxxxxxxx

...

​

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")

        }

    }

}

​

...

이제 표준 라이브러리 종속 요소를 명시적으로 선언할 필요가 없습니다. 또한 Kotlin 1.4-M2에서 공개된 계층 프로젝트 구조 지원이 있으므로 기타 종속 요소를 한 번만 지정하면 됩니다. 따라서 Gradle 빌드 파일이 훨씬 간결하고 읽기 쉬워 집니다.

...

android()
ios()
js()

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

...

xxxxxxxxxx

...

​

android()

ios()

js()

​

sourceSets {

    commonMain {

        dependencies {

            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.6")

        }

    }

}

​

...

플랫폼 소스 집합 및 백엔드 공유 소스 집합에 해당 표준 라이브러리가 추가되고, 남은 부분에 일반 표준 라이브러리가 추가될 예정입니다. Kotlin Gradle 플러그인은 kotlinOptions.jvmTarget 설정에 따라 적합한 JVM 표준 라이브러리를 선택할 것입니다.

표준 라이브러리 종속 요소를 명시적으로 선언한 경우(예: 다른 버전이 필요한 경우), Kotlin Gradle 플러그인에서 재정의하거나 두 번째 표준 라이브러리를 추가하지 않습니다. 또한 표준 라이브러리가 전혀 필요하지 않은 경우 Gradle 속성에 선택 해제 플래그를 추가할 수 있습니다.

kotlin.stdlib.default.dependency=false

xxxxxxxxxx

kotlin.stdlib.default.dependency=false

이전에는 프로젝트를 종속 요소 관리자 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 문서는 모든 시나리오를 지원합니다.

1. cocoapods 종속 요소 관리자를 설치합니다(sudo gem으로 cocoapods 설치).
2. cocoapods-generate 플러그인 설치(sudo gem으로 cocoapods-generate 설치).
3. 프로젝트의 build.gradle(.kts) 파일에 kotlin("native.cocoapods")을 사용해서 CocoaPods 플러그인을 적용합니다.

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

   xxxxxxxxxx

    

   plugins {

      kotlin("multiplatform") version "1.4.0-rc"

      kotlin("native.cocoapods") version "1.4.0-rc"

   }

1. pod()을 사용하여 CocoaPods 저장소에서 사용하고자 하는 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")
       }
   }
   

   xxxxxxxxxx

    

   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.*
   

   xxxxxxxxxx

    

   import cocoapods.AFNetworking.*

   import cocoapods.SDWebImage.*

공유한 샘플 프로젝트를 사용해서 원격 CocoaPods 저장소에 그리고 로컬에 저장된 Pod 라이브러리에 종속 요소를 추가하는 방법을 확인해 보세요.

많은 경우 iOS 애플리케이션 충돌 디버그 과정에는 충돌 보고서 분석이 포함됩니다. 일반적으로 충돌 보고서가 적절한 가독성을 갖추려면 심볼화 과정이 필요합니다. Kotlin으로 작성된 주소를 심볼화하려면 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}"
        }
    }
}

xxxxxxxxxx

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 Daemon의 컴파일러 실행 기능입니다. 여러분의 피드백을 바탕으로 여러 이슈를 수정하였으며 해당 기능의 전반적인 안정성도 개선했습니다. 앞으로도 지속적으로 노력해 가겠습니다.
• 또한 런타임 성능과 관련한 개선 사항도 있습니다. GC(가비지 컬렉션) 최적화로 전반적인 런타임 성능이 향상되었습니다. 장기간 존재하는 객체가 많은 프로젝트에서 확실히 이러한 성능 향상을 느끼실 수 있을 겁니다. 이제 중복 박싱을 이스케이프하여 HashMap 및 HashSet 컬렉션이 더 빠르게 작동합니다.

Kotlin 1.4.0-RC에서는 @JsExport 어노테이션이 디폴트 컴파일러 백엔드와 호환됩니다. 또한 npm 종속 요소 관리 및 Gradle 프로젝트의 Dukat 통합을 더 강력하고 세분화하여 제공하고 CSS 지원을 개선하였습니다. 더불어 Node.js API와 통합을 처음으로 도입하는 등 다양한 기능이 추가되었습니다.

Kotlin 1.4 이전 릴리스에서 @JsExport 어노테이션을 도입하였습니다. 이 기능은 새 IR 컴파일러 백엔드를 사용할 경우 JavaScript 또는 TypeScript에서 지원되는 최상위 선언을 생성하는 데 사용됩니다. Kotlin 1.4-M3 버전부터는 해당 어노테이션을 최신 디폴트 컴파일러 백엔드에서도 사용할 수 있습니다. 현재 디폴트 컴파일러 백엔드를 사용할 때 @JsExport로 최상위 선언에 어노테이션을 추가하면 선언의 이름 맹글링이 비활성화됩니다. 컴파일러 백엔드 양쪽에 해당 어노테이션이 포함될 경우 최상위 선언을 내보내기 위해 로직을 변경하지 않고도 백엔드 간 전환이 가능합니다. 단, TypeScript 정의 생성은 새 IR 컴파일러 백엔드를 사용할 때만 사용할 수 있습니다.

버전 번호를 지정하지 않고 npm 패키지 종속 요소를 선언하면 사용하는 패키지를 안정적으로 관리하기가 어렵습니다. 그렇기에 앞으로는 종속 요소에 대한 npm의 semver 구문을 기반으로 버전 또는 버전 범위를 명시적으로 지정해야 합니다. 이제 Gradle DSL에서 여러 종속 요소 범위를 지원하므로 프로젝트에서 허용하려는 버전을 정확하게 찾아낼 수 있습니다. 예시는 다음과 같습니다.

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

xxxxxxxxxx

dependencies {

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

}

dependencies 블록 내부에 npm(...)을 사용하여 지정할 수 있는 일반적인 npm 종속 요소 외에도 사용 가능한 세 가지 이상의 종속 요소 유형이 있습니다.

• devDependencies, devNpm(...) 사용
• optionalDependencies, optionalNpm(...) 사용
• peerDependencies, peerNpm(...) 사용

각 유형의 종속 요소가 가장 적합하게 사용되는 경우를 자세히 알아보려면 npm에서 연결된 공식 문서를 확인해 주세요.

이전에는 작성자가 아티팩트에 package.json 파일을 수동으로 추가하지 않은 라이브러리에 의존해야 할 경우 npm 종속 요소를 수동으로 가져와야 했습니다. 예를 들어, kotlinx.serialization의 경우 패키지가 Kotlin/JS에서 작동할 수 있도록 Gradle 빌드 파일에 종속 요소로 text-encoding 및 abort-controller를 포함해야 했죠.

이제 Gradle 플러그인은 라이브러리에 package.json 파일을 자동으로 생성하고 해당 파일을 jar 또는 klib 아티팩트에 포함합니다. 이러한 유형의 라이브러리를 포함할 경우 자동으로 파일 구문 분석 및 필요한 종속 요소가 자동으로 포함되므로 Gradle 빌드 파일에 종속성을 수동으로 추가할 필요가 없습니다.

Kotlin 1.4-M2 버전은 cssSettings를 통해 Gradle에서 webpack의 CSS 및 스타일 로더를 바로 지원합니다. 실제 작업 및 효과를 더욱 엄밀히 반영하고자 구성 매개변수 이름을 cssSupport으로 변경하였습니다. 앞으로는 1.4-M2의 실험적 설정과 달리 Gradle 플러그인에서 CSS 지원이 기본적으로 활성화되지 않습니다. 이번 변경을 통해 스타일 시트가 처리되는 방식에 자체 설정을 포함했던 분들의 혼란을 방지할 수 있기를 기대합니다(예: Sass 또는 Less 로더 사용). 이러한 상황에서는 프로젝트의 디폴트 구성에서 충돌을 야기할 수 있는 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
   }
}

xxxxxxxxxx

webpackTask {

   cssSupport.enabled = true

}

runTask {

   cssSupport.enabled = true

}

testTask {

   useKarma {

      // . . .

      webpackConfig.cssSupport.enabled = true

   }

}

저희 팀은 각각의 작업마다 개별적인 설정 조정이 필요하다는 점이 별로 편리하지 않다는 것을 알게 되었습니다. 따라서 플러그인 DSL에 cssSupport 구성 중앙 포인트를 추가할 예정입니다(진행 상황을 여기에서 확인하실 수 있습니다).

Kotlin/JS Gradle 플러그인은 Dukat 통합에 보다 세분화된 제어 기능을 추가했습니다. Dukat은 TypeScript 선언 파일(.d.ts)을 Kotlin 외부 선언으로 자동 변환하는 도구입니다. 이제 두 가지 방식으로 Dukat의 선언을 생성하는 경우 및 시점을 선택할 수 있습니다.

이제 npm 종속 요소 함수에서 패키지 이름 및 버전 뒤에 세 번째 매개변수인 generateExternals가 추가됩니다. 따라서 Dukat이 특정 종속 요소에 대한 선언을 생성할지 여부를 개별적으로 제어할 수 있습니다. 예시는 다음과 같습니다.

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

xxxxxxxxxx

dependencies {

  implementation(npm("decamelize", "4.0.0", generateExternals = true))

}

또한 gradle.properties 파일에서 kotlin.js.generate.externals flag(실험적으로 제공되었을 시 기존 이름은 kotlin.js.experimental.generateKotlinExternals)를 활용하여 모든 npm 종속 요소에 필요한 생성기 동작을 동시에 설정할 수 있습니다. 언제나처럼 개별적인 명시적 설정이 일반 플래그보다 우선합니다.

Dukat에서 생성된 선언을 완전히 제어하려는 경우, 수동 조정을 적용하려는 경우 또는 자동 생성된 외부 선언 실행 시 문제가 발생한 경우에는 generateExternals Gradle 작업을 사용하여 모든 npm 종속 요소에 대한 선언 생성을 수동으로 트리거할 수도 있습니다. 이러한 방식을 사용하면 프로젝트 루트에서 이름이 externals로 지정된 디렉토리에 선언이 생성됩니다. 이때 생성된 코드를 검토하고 사용하고자 하는 모든 부분을 소스 디렉토리에 복사할 수 있습니다. (단, 소스 폴더에 외부 선언을 수동으로 제공하고 동일한 종속 요소에 대한 외부 선언을 빌드 시점에 생성하도록 활성화하면 해결 이슈가 발생할 수 있음에 유의하세요)

Kotlin/JS용 브라우저 및 DOM 바인딩의 속도를 개선하고 언어 자체의 릴리스 주기와 분리하기 위해 kotlin.dom 및 kotlin.browser 패키지에 위치한 현재의 API를 중단하였습니다. kotlinx.dom 및 kotlinx.browser 패키지에서 이러한 API에 대한 대체 항목을 제공하고 있습니다만, 향후 릴리스에서 별도의 아티팩트로 추출할 예정입니다. 새로운 API로의 마이그레이션은 매우 직관적이며 프로젝트에 사용된 import 문을 조정하여 새 kotlinx 패키지에 지정하면 됩니다. IntelliJ IDEA에서 Alt-Enter를 눌러서 사용할 수 있는 Quick-fixes(빠른 수정) 기능이 이 마이그레이션에 도움이 될 것입니다.

Node.js API에 대한 공식 바인딩인 kotlinx-nodejs 테스트 버전이 출시되었다는 기쁜 소식을 전해드립니다. 오랫동안 Kotlin을 통해 Node.js를 대상으로 지정할 수 있었지만, 대상의 모든 기능은 API에 타입 안정적인 액세스를 보유할 때 사용 가능합니다. GitHub에서 kotlinx-nodejs 바인딩을 체크아웃할 수 있습니다.

kotlinx-nodejs를 프로젝트에 추가하려면 jcenter ()가 저장소에 추가되었는지 확인하세요. 다음으로 간단히 아티팩트에 종속 요소를 추가하면 됩니다.

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

xxxxxxxxxx

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")
    }
}

xxxxxxxxxx

fun main() {

    dns.lookup("example.org") { err, address, family ->

        console.log("address: $address, family IPv$family")

    }

}

아직 테스트 버전에 불과하므로 kotlinx-nodejs를 사용해 보고, 문제가 발견된 경우 저장소의 이슈 트래커에 보고해 주시면 감사하겠습니다.

Kotlin 1.4부터 Kotlin/JavaScript를 대상으로 하는 기존의 Gradle 플러그인(kotlin2js 및 kotlin-dce-js)은 공식적으로 사용이 중단되었으며 kotlin.js Gradle 플러그인이 대신 사용됩니다.
(이미 사용이 중단된) kotlin-frontend-plugin과 더불어 해당 플러그인에서 지원하던 주요 기능은 새 플러그인으로 압축되었습니다. 따라서 Kotlin/Multiplatform 프로젝트와 호환 가능한 통합 DSL을 사용하여 Kotlin/JS 대상을 구성할 수 있습니다.

Kotlin 1.3.70 버전부터는 최적화된 프로그램 번들을 실행 및 생성하는browserProductionRun 및 browserProductionWebpack 작업을 사용할 경우에도 불필요한 코드 제거(DCE) 기능이 자동으로 적용됩니다. (현재 불필요한 코드 제거는 Node.js 또는 테스트가 아닌 생성 출력 브라우저가 대상인 경우에만 지원됩니다. 하지만 처리되길 바라는 기타 사용 사례가 있는 경우 언제든 저희 팀에 알려주세요.)

• @JsExport 어노테이션이 금지된 사용 위치에 더 많은 컴파일러 오류가 추가되어 이러한 문제가 강조 표시됩니다.
• IR 컴파일러 백엔드를 사용할 때 klib에 대한 증분 컴파일을 포함하는 새로운 전략략이 활성화 됩니다. 이러한 조치는 컴파일 시간 개선을 위한 여러 단계 중 하나 입니다.
• webpack 개발 서버 구성을 수정하여 Hot Reload 기능을 사용할 때 ENOENT: 해당 파일 또는 디렉토리 없음 와 같은 오류를 방지할 수 있게 되었습니다.

Kotlin 발전의 관점에서 Kotlin 1.4는 기능 릴리스입니다. 그렇기에 이전 블로그 게시물에서 이미 소개해드린 다양한 신규 기능이 포함됩니다. 하지만 기능 릴리스의 다른 중요 측면은 기존 API에 중요하고 혁신적인 변경 사항이 포함된다는 점입니다. 1.4 릴리스에서 기대할 수 있는 변경 사항의 간략한 설명을 확인해 보세요.

사용자가 Kotlin 라이브러리에 기대하는 기능을 최대한 빨리 제공하고자 실험적 버전을 제공하고 있습니다. 이러한 상태는 API 개발이 아직 진행 중이며 향후 호환성을 고려하지 않고 향후에 변경될 수 있음을 의미합니다. 실험적 API를 사용할 경우 컴파일러에서 해당 상태를 경고하고 사전 동의를 요청합니다(@OptIn 어노테이션).

기능 릴리스에서 실험적 API는 안정 상태로 개선될 수 있습니다. 안정 상태에 이르면 예기치 않게 형식과 동작이 변경될 일은 없습니다(변경 사항은 적절한 사용 중단 주기에 따라서만 적용됩니다). API가 공식적으로 안정화되면 경고나 사전 동의 없이 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: 컬렉션 연산 MutableList; ArrayDeque 클래스의 randomOrNull(), reduceOrNull(), scan(); remove*() 함수
• 1.4-M2: 컬렉션 연산 onEachIndexed() 및 reduceIndexedOrNull(), runningFold() 및 runningReduce()

1.4 버전에서 더 많은 함수 및 클래스가 안정 상태로 변경될 예정입니다. 이번 버전(1.4.0-RC)부터 프로젝트에서 해당 기능을 사용할 시 @OptIn 어노테이션이 필요하지 않습니다.

기능 릴리스에는 기존 사용 중단 주기에 대한 개선 사항도 포함됩니다. 증분 릴리스에서 WARNING 수준의 새로운 사용 중단 주기로 시작되었지만 기능 릴리스에서는 ERROR 수준으로 한층 강화되었습니다. 따라서 이미 ERROR 수준으로 지정된 API 요소는 코드의 신규 사용 위치에서 완전히 숨김 처리되며 이미 컴파일된 코드와 호환성을 유지하기 위해 2진 형식으로만 제공됩니다. 이와 같은 단계가 결합되어 사용 중단된 API 요소가 점진적으로 제거 됩니다.

코드에서 사용 중단 수준이 WARNING인 API 요소가 사용될 경우 컴파일러는 이러한 사용에 대해 경고합니다. Kotlin 1.4.0-RC로 업데이트할 경우 일부 경고가 오류 수준으로 변경됩니다. IDE에서 표시되는 메시지를 활용하여 오류가 있는 코드 사용을 제공된 대안 요소로 대체하고 코드가 다시 컴파일되는지 확인합니다.

Kotlin 표준 라이브러리 API의 호환성 손상 변경과 관련한 자세한 내용은 Kotlin 1.4 호환성 가이드에서 확인하실 수 있습니다.

이전 블로그 게시물 몇 개에서 이 섹션이 생략되었지만 1.4 버전의 Kotlin 스크립트 작업을 더욱 안정적이고 빠르고 사용이 간편하게 개선하려는 노력은 지속되었습니다. 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에 종속된 아티팩트가 필요한 경우 kotlin-scripting-jsr223-unshaded와 같이 -unshaded 접미어가 포함된 아티팩트 버전을 사용하세요. 이름 변경이 직접 사용되어야 하는 스크립트 작업 아티팩트에만 영향을 미친다는 점에 유의하세요. 다른 아티팩트 이름은 변경되지 않은 상태로 유지됩니다.

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

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

이 게시물은 Sebastian Aigner가 작성한 Kotlin 1.4.0-RC Released를 번역한 글입니다.

Subscribe to Kotlin 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

감사합니다!