Kotlin 1.3.70 출시되었습니다
오늘은 Kotlin의 최신 버전인 1.3.70에 대한 즐거운 소식을 전해 드리겠습니다.
이 추가 릴리스에서는 새로운 주요 기능을 제공하지 않습니다. 그러나 기존 기능을 개선하고 문제를 해결하며 사용자가 체험해볼 수 있는 실험적인 기능을 추가하기 위해 최선을 다했습니다. Kotlin 1.3.70의 주요 특징은 다음과 같습니다.
- 표준 라이브러리의 Kotlin 컬렉션에 대한 새로운 함수 및 클래스
- IntelliJ Kotlin 플러그인에 다양한 개선 사항 적용: 개선된
*.gradle.kts지원, 테스트, 디버그, 코드 완성 기능 등 - Kotlin/JVM 컴파일러가 이제 Java 8 이후 버전 대상의 바이트코드에서 유형 주석을 생성
- 번들 최적화, npm 종속 요소 선언 및 오랫동안 기다려온 Kotlin/JS에 대한 새로운 문서
- Kotlin/Native 컴파일 및 디버그 속도 향상
- IDE 및 명령줄 도구에서 스크립트 작성 시 제공되는 지원 향상
전체 변경 목록은 변경 로그에서 확인할 수 있습니다. 언제나 그렇듯이 외부 기여자들께 감사의 말씀을 전합니다.
그러면 지금부터 세부 사항에 대해 알아보겠습니다!
표준 라이브러리 변경 내용
모든 새로운 함수는 실험적 상태로 표준 라이브러리에 추가되니 유의해주세요.
공통 라이브러리에서 StringBuilder 확장
StringBuilder는 이미 kotlin.text 패키지의 일반 표준 라이브러리에 있었지만 수많은 중요한 멤버가 누락되거나 JVM에서만 사용 가능했습니다. 이제 모든 JVM StringBuilder 기능이 다양한 플랫폼에 대응하는 구현을 가진 공통 expect class에 추가되었습니다. 즉, 필요한 모든 멤버가 있으므로 공통 코드에서 StringBuilder를 효과적으로 사용할 수 있습니다.
KClass 작업
이제 KClass의 일부 유용한 기본 멤버에서 JVM에 대한 kotlin-reflect 종속 요소가 필요 없습니다.
import kotlin.reflect.cast
@OptIn(ExperimentalStdlibApi::class)
fun main() {
val kClass = String::class
println(kClass.simpleName) // String
println(kClass.qualifiedName) // kotlin.String
println(kClass.isInstance("abc")) // true
println(kClass.isInstance(10)) // false
println(kClass.cast("abc")) // abc
}
이전에는 런타임에서 Kotlin 리플렉션 구현을 제공해야 했지만, 이제 추가 종속 요소 없이 이러한 간단한 멤버를 사용할 수 있습니다.
실험적 주석 이름 변경(@Experimental 및 @UseExperimental)
아시다시피 Kotlin에는 실험적 기능을 사용하기 위한 메커니즘이 기본 제공됩니다. 이 메커니즘에는 다른 실험적 선언을 사용하거나 그 자체가 실험적인 선언을 표시하는 표준 라이브러리의 주석이 포함되어 있습니다. 이전 버전에서 이러한 주석은 @UseExperimental 및 @Experimental이었습니다.
그러나 실험적 상태라는 것이 API 사용 시 동의가 필요한 유일한 이유는 아니기에 이 메커니즘의 범위를 넓히기로 했습니다. 예를 들어 API가 내부용이거나 일부 제한이 있을 수 있습니다. 그래서 이를 반영하기 위해 @UseExperimental 및 @Experimental이라는 주석 이름을 @OptIn 및 @RequiresOptIn으로 변경했습니다. 컴파일러 인수 -Xuse-experimental의 이름은 -Xopt-in으로 변경되었습니다. -Xexperimental은 거의 사용되지 않고 복잡성을 증가시키기 때문에 없앴습니다. @Experimental 및 @UseExperimental의 이전 선언은 1.3.70에서 여전히 지원되지만 1.4에서는 없어집니다.
실험 시간 측정 API의 이름 변경
또 다른 이름 변경은 Duration and Time measurement API에 관한 것입니다. Clock 및 ClockMark의 이름이 TimeSource 및 TimeMark로 변경되었습니다. 이전 이름은 현재 더 이상 사용되지 않는 유형 별칭으로 유지됩니다.
양방향 큐 구현: ArrayDeque
Kotlin 표준 라이브러리에 양방향 큐의 구현인 kotlin.collections.ArrayDeque클래스가 드디어 추가되었습니다! 이는 커뮤니티에서 한동안 계속 요청했던 기능이었습니다. 이전에도 Java 표준 라이브러리의 java.util.ArrayDeque 클래스는 사용할 수 있었지만 Kotlin/JS, Kotlin/Native에서 뿐만 아니라 가장 중요한 공통 코드에서 사용할 수 있는 공통 구현이 없었습니다. 이제 실험적 상태이지만 그러한 구현을 사용할 수 있게 되었습니다.
양방향 큐를 사용하면 상각된 일정한 시간에 큐의 시작과 끝 모두에서 요소를 추가/제거할 수 있습니다.
@OptIn(ExperimentalStdlibApi::class)
fun main() {
val deque = ArrayDeque(listOf(1, 2, 3))
deque.addFirst(0)
deque.addLast(4)
println(deque) // [0, 1, 2, 3, 4]
println(deque.first()) // 0
println(deque.last()) // 4
deque.removeFirst()
deque.removeLast()
println(deque) // [1, 2, 3]
}
코드에 큐 또는 스택이 필요할 때 기본적으로 양방향 큐를 사용할 수 있습니다.
kotlin.collections.ArrayDeque 구현은 아래의 크기 조정 가능한 배열을 사용합니다. 내용은 순환 버퍼인 Array에 저장하고 이 Array가 가득 찰 때만 크기를 조정합니다.
개념적으로 ArrayDeque의 구현은 java.util.ArrayDeque의 구현과 매우 유사합니다. 그러나 이는 다른 구현이며 이 클래스가 Kotlin/JVM에서 사용될 때 이 새로운 구현이 사용됩니다. 이는 다른 컬렉션과 작동 방식이 다릅니다. ArrayList를 생성하고 이를 JVM으로 컴파일할 때 java.util.ArrayList 클래스가 내부에서 사용됩니다. Collection 인터페이스만 구현하는 Java의 ArrayDeque와 달리 Kotlin의 ArrayDeque는 MutableList를 구현합니다. 즉, 색인으로 모든 요소에 액세스할 수 있으며 이는 Java의 ArrayDeque에서는 불가능합니다.
현재 ArrayDeque 클래스는 실험적 상태로 출시되었으며 이에 대한 여러분의 의견을 기다리고 있습니다!
컬렉션 빌더
또 다른 중요한 새 기능은 컬렉션에 대한 빌더 함수인 buildList, buildSet, buildMap입니다. 이 빌더 함수를 사용하면 생성 단계에서 가변 컬렉션을 편리하게 조작하고 읽기 전용 컬렉션을 결과로 얻을 수 있습니다.
@OptIn(ExperimentalStdlibApi::class)
fun main() {
val needsZero = true
val initial = listOf(2, 6, 41)
val ints = buildList { // this: MutableList
if (needsZero) {
add(0)
}
initial.mapTo(this) { it + 1 }
}
println(ints) // [0, 3, 7, 42]
}
이 빌더 함수는 buildString과 유사하게 구현됩니다. buildList는 리시버가 있는 람다를 인수로 사용합니다. 람다 내부의 묵시적 “this” 리시버는 유형 MutableList를 가지지만 buildList는 읽기 전용 List를 결과로 반환합니다.
조건 사용, 여러 초기 컬렉션 수정 및 결과 병합 등과 같은 복잡한 조작을 수행해야 할 때 빌더 함수를 사용하면 가독성도 높아지고 성능 면에서 효과적인 경우가 많습니다. 이 새로운 함수는 실험적 상태로 표준 라이브러리에 추가되니 유의해주세요.
reduceOrNull() 와 randomOrNull() 대응 함수
Kotlin의 이 규칙을 다들 알고 계실 겁니다. 한 쌍의 함수가 있을 때 연산이 불가능하면 첫 번째 함수가 예외를 던지고 두 번째 함수는 string.toInt()나 string.toIntOrNull()과 같은 null을 반환합니다. 이제 동일한 규칙에 따라 새로운 randomOrNull() 및 reduceOrNull() 대응 함수가 추가되었습니다.
@OptIn(ExperimentalStdlibApi::class)
fun main() {
val list = listOf(1, 2, 3)
println(list.randomOrNull()) // 2
println(list.reduceOrNull { a, b -> a + b }) // 6
val emptyList = emptyList<Int>()
println(emptyList.randomOrNull()) // null
println(emptyList.reduceOrNull { a, b -> a + b }) // null
}
random() 또는 reduce()를 사용하면 컬렉션이 비어 있을 때 예외가 발생합니다.
scan() 함수
목록과 시퀀스 작업에 사용할 수 있는 새로운 함수가 추가됩니다. 이 함수는 “스캔”의 개념을 나타내며 이와 유사한 함수는 이미 다양한 라이브러리와 언어에 있습니다.
scan()은 fold()와 밀접한 관련이 있습니다. scan()과 fold() 모두 주어진 2진 연산을 값 시퀀스에 적용하지만 scan()은 중간 결과의 전체 시퀀스를 반환하는 반면 fold()는 최종 결과만 반환한다는 점이 다릅니다.
@OptIn(ExperimentalStdlibApi::class)
fun main() {
val ints = (1..4).asSequence()
println(ints.fold(0) { acc, elem -> acc + elem }) // 10
val sequence = ints.scan(0) { acc, elem -> acc + elem }
println(sequence.toList()) // [0, 1, 3, 6, 10]
}
fold와 마찬가지로, scan은 초기 누적자의 값을 취합니다.
결과 유형이 요소 유형과 동일하고 첫 번째 요소를 초기 값으로 사용할 수 있는 경우 reduce() 및 scanReduce() 함수를 사용할 수 있습니다.
시퀀스에서 scan() 및 scanReduce()를 사용하면 본질적으로 지연되는 시퀀스가 결과로 반환됩니다. 즉, 스캔 프로세스는 결과 시퀀스에서 데이터를 요청할 때, 특히 toList() 또는 max()와 같은 터미널 작업(다른 시퀀스 이외의 것을 반환하는 작업)을 호출할 때만 시작됩니다. 목록에서 scan() 및 scanReduce()를 사용하면 목록이 결과로 반환됩니다.
자세한 내용은 이 KEEP를 참조하세요.
IntelliJ IDEA 지원
이 릴리스에서는 IntelliJ IDEA의 Kotlin 지원이 몇가지 개선되었습니다. 지금부터 가장 흥미로운 개선 사항을 살펴보겠습니다.
*.gradle.kts 지원
1.3.70에서는 Gradle Kotlin DSL 스크립트(*.gradle.kts 파일)에 대한 IntelliJ IDEA의 지원을 개선하기 위해 노력했습니다. 그 결과 최신 버전의 Kotlin 플러그인은 구문 강조, 코드 완성, 검색 및 기타 Kotlin 빌드 스크립트 작업의 측면에서 더 나은 성능을 보여줍니다. 개선 사항에 대한 자세히 검토는 이 블로그 게시물에 나와 있습니다.
모든 변경 및 개선 사항을 사용해 보려면 Gradle 6.0 이후 버전과 함께 IntelliJ IDEA 2019.2 이후 버전을 사용해야 합니다.
코드 완성
1.3.70에서는 IntelliJ IDEA의 Kotlin 코드 완성 기능이 눈에 띄게 향상되었습니다. 이제 확장 함수, 객체 수준 재정의, 중첩된 객체에 선언된 함수 등 객체에서 선언된 함수가 코드 완성 제안에 포함됩니다.
또한 코드 완성 목록을 정렬하는 머신 러닝 모델 개선되어 가장 관련성이 높은 옵션이 맨 위에 표시됩니다.
새로운 색 구성표
에디터에서 Kotlin 코드 표시를 원하는 대로 변경할 수 있도록 새로운 사용자 지정 색 구성표가 추가되었습니다. 특히, 이제 suspend 함수 호출 및 속성 선언에 대해 고유한 색 구성표를 설정할 수 있습니다.
디버그 개선 사항
이전 버전에서 Kotlin/Native 디버거는 별도의 중단점 유형을 사용했습니다. 이 때문에 일부 사용자는 “여기에서 어떤 중단점 유형을 사용해야 할까?”와 같은 의문을 던지며 명확하지 않은 선택지에서 혼란스러워했습니다. 이제 단일한 중단점 유형인 Kotlin Line Breakpoint가 JVM 및 Native 타겟 모두에서 작동합니다.
Kotlin/JS 및 Kotlin/Native 테스트
이제 Kotlin/JS 및 Kotlin/Native의 테스트 결과가 Kotlin/JVM 테스트와 마찬가지로 IntelliJ IDEA에 바로 표시됩니다. 또한 Kotlin/JS에 대한 테스트 필터링이 수정되어 개별 테스트를 실행할 수 있으며 iOS 시뮬레이터를 대상으로 하는 Kotlin/Native 테스트를 “Play” 버튼을 눌러 바로 시작할 수도 있습니다.
또한 IntelliJ IDEA Ultimate에서는 테스트 선언 근처의 아이콘을 클릭하여 Kotlin/JS 디버그를 시작할 수 있습니다.
또는 Gradle 도구 창에서 nodeRun, nodeTest 또는 browserTest 작업을 수동으로 선택하여 디버그를 시작할 수 있습니다. browserRun의 경우 Attach to Node.js/Chrome 실행 설정을 사용하여 개발 서버를 시작한 후 디버거를 연결할 수 있습니다.
기타 주목할 만한 사항
이 밖에도 IntelliJ IDEA에서의 Kotlin 지원에서 개선된 사항이 있습니다. 몇 가지 주요한 항목은 다음과 같습니다.
- 파일 분석 및 복사/붙여넣기 액션의 성능이 향상되었습니다.
- 무의미한 단항 연산자에 대한 새로운 검사가 추가되었습니다. 무의미한 단항 연산자는 긴 표현식을 여러 줄로 나눌 때 생길 수 있습니다.
- 호출 체인, 줄 바꿈, 공백, 주석의 서식을 포함하여 다양한 서식 지정 기능이 개선되었습니다.
Kotlin/JVM
이제 Kotlin은 JVM 바이트코드(대상 버전 1.8 이후)에서 유형 주석을 생성할 수 있으므로 이러한 주석을 런타임에서 사용할 수 있게 되었습니다. 이 기능은 일부 기존 Java 라이브러리를 훨씬 쉽게 사용할 수 있도록 돕고 새 라이브러리 작성 시 강력한 지원을 제공하기 때문에 커뮤니티에서 한동안 요청되어 왔습니다.
다음의 예와 같이, String 유형에 관한 @Foo 주석은 바이트코드로 출력된 다음 라이브러리 코드에서 사용될 수 있습니다.
@Target(AnnotationTarget.TYPE)
annotation class Foo
class A {
fun foo(): @Foo String = "OK"
}
바이트코드에서 유형 주석을 출력하려면 다음 단계를 참고해주세요.
- 선언된 주석에 올바른 주석 대상(Java의
ElementType.TYPE_USE또는 Kotlin의AnnotationTarget.TYPE)과 보존 항목(AnnotationRetention.RUNTIME)이 있는지 확인합니다. - 주석 클래스 선언과 이 주석을 사용하는 코드(위 예시의 클래스 A)를 JVM 바이트코드 대상 버전 1.8 이후로 모두 컴파일합니다. 이는
-jvm-target=1.8컴파일러 옵션을 사용하여 지정할 수 있습니다. - 주석을 사용하는 코드를
-Xemit-jvm-type-annotations컴파일러 옵션을 사용해 컴파일합니다.
단, 표준 라이브러리의 유형 주석은 대상 버전 1.6으로 컴파일되므로 바이트코드로 출력되지 않습니다.
현재는 다음과 같은 기본 사례만 지원됩니다.
- 메소드 매개변수, 메소드 반환 유형, 속성 유형에 대한 유형 주석
- 유형 인수의 불변 프로젝션(예:
Smth<>,Array<@Ann Foo>
향후에는 공변성 및 반공변성 유형 프로젝션에 대한 유형 주석과 내부 유형에 대한 주석(예: Smth<@Ann Outer.Inner>)의 생성을 지원할 계획입니다. 지원되는 사례가 대부분의 실제 시나리오를 다루고 있다고 생각합니다만, 더 복잡한 사례에 대한 유형 주석이 필요한 경우 저희에게 알려주세요.
Kotlin/JS
Kotlin 1.3.70에서는 JavaScript 대상이 번들 크기 면에서 크게 최적화되고 종속 요소, 리소스, 테스트를 처리하는 방식에서 삶의 질을 높여주는 몇가지 변화가 추가됩니다. 또한 기쁘게도 대상 관련 문서도 개편되었습니다.
번들 최적화
Kotlin 1.3.70부터 DCE(Dead Code Elimination)를 org.jetbrains.kotlin.js Gradle 플러그인을 통해 쉽게 사용할 수 있으며 수동으로 추가할 필요가 없습니다. DCE는 JS 프로젝트 최적화 및 실행을 제어하는 데 사용할 수 있는 일련의 새로운 작업을 수신합니다.
개발하는 동안 browserDevelopmentRun을 사용하여 번들 개발 서버로 최적화되지 않은 애플리케이션 실행을 시작하고 browserDevelopmentWebpack을 사용하여 build/distributions 폴더에 최적화되지 않은 애플리케이션 번들을 생성하세요. 최적화를 실행하지 않으면 빌드 시간이 빨라지지만 컴파일된 프로그램의 파일 크기는 더 커집니다.
프로덕션을 준비할 때는 browserProductionRun을 사용하여 최적화된 애플리케이션 실행을 시작하고 browserProductionWebpack을 사용하여 프로덕션에서 배포하기에 적합한 최적화된 번들을 생성하세요. 프로덕션 빌드는 컴파일하는 데 시간이 조금 더 걸리지만 개발 빌드보다 상당히 최적화된 번들이 됩니다.
| 프로젝트 | 개발 빌드(gzip) | 프로덕션 빌드(gzip) |
|---|---|---|
| “Hello, World” | 963KiB | 14KiB |
| Kotlin/React 예시(“CodeQuiz”) | 4.1MiB | 345KiB |
이전 Gradle 작업인 browserRun(현재 browserDevelopmentRun의 별칭) 및 browserWebpack(현재 browserProductionWebpack의 별칭)을 지금도 계속 사용할 수 있지만 빌드 스크립트에서 새로 추가된 해당 항목으로 교체해야 합니다.
이러한 Gradle 작업은 multiplatform 또는 kotlin.js Gradle 플러그인을 사용하는 프로젝트에서 사용할 수 있습니다. kotlin.js의 경우 짧은 작업 별칭을 사용할 수도 있습니다(browserDevelopmentRun은 run, browserProductionWebpack은 build).
Kotlin/JS의 Dead Code Elimination 및 세세하게 구성하는 방법에 대한 자세한 내용을 알고 싶은 경우 문서를 확인하세요.
리소스 자동 복사
distributions 폴더에 번들을 생성하는 빌드 작업(예: browserProductionWebpack)에서 resources 폴더의 모든 애셋을 복사하므로 이제 배포 가능한 아티팩트 세트를 얻기 위해 이미지, 스타일시트 등을 일일이 복사할 필요가 없습니다.
npm 종속 요소 선언에 대한 원활한 지원
Kotlin/JS Gradle 플러그인을 사용하는 경우 이제 주요 소스 세트를 일일이 추가할 필요 없이 최상위 종속 요소 블록 내에 npm 종속 요소를 선언할 수 있습니다. 이는 이제 다음 조각이 유효함을 의미합니다.
dependencies {
implementation(npm("react", "16.12.0"))
}
Gradle을 통한 실험적 테스트 디버그
Kotlin/JS 브라우저 대상에 대해 IntelliJ IDEA 내에서 바로 테스트를 디버그할 수 있습니다. 실패한 테스트를 디버그하려면 IDE에서 중단점을 설정한 다음 디버그 모드에서 check Gradle 작업을 시작하거나 여백 아이콘을 사용해 테스트 세트를 디버그하세요. Gradle이 플랫폼에 대한 테스트 작업을 실행하면 디버거가 통합 중단점에서 멈춥니다. 디버거는 Gradle이 browserTest 작업을 콘솔에 표시하는 즉시 중단점에 도달합니다.
> Task :browserTest
이때 디버거에서 ::browserTest 세션으로 전환하고 “Debugger”(디버거)라는 탭을 선택하세요. 테스트 실행을 시작하려면 ‘Resume Program'(프로그램 재시작) 버튼을 클릭하세요.
현재 이 프로세스는 IntelliJ IDEA의 디버거를 JS 엔진과 동기화하기 위해 필요합니다. 그러나 디버그 세션을 시작하기 위해 이처럼 여러 단계를 거치기는 번거로운 것이 사실입니다. 훨씬 원활한 디버그 환경이 준비될 때까지 향후 버전을 계속 확인해 주세요!
또한 일부 남아 있는 문제를 해결한 후 Node.js를 대상으로하는 Kotlin 코드 디버그에도 동일한 환경을 제공할 계획입니다.
개선된 문서
Kotlin 1.3.70에서는 모두 오랫동안 기다려온 JavaScript 대상 관련 문서 및 튜토리얼을 변경했습니다. 이 변경으로 Kotlin/JS를 더 쉽게 시작할 수 있기를 바랍니다. 문서를 개편하면서 오래된 자료는 삭제했습니다. 또한 Kotlin/JS 작업 시 보게 되는 일반적인 작업을 간략히 설명해 놓은 일련의 짧은 튜토리얼을 웹사이트에 새로 추가했습니다. 이 튜토리얼은 Kotlin/JS Gradle 플러그인을 시작하는 데 도움이 되며 JavaScript 대상 애플리케이션을 빌드할 때 마주치게 되는 일반 작업을 다룹니다. 실습 교육 과정인 “Building Web Applications with React and Kotlin/JS”(React 및 Kotlin/JS를 사용하여 웹 애플리케이션 빌드하기)도 업데이트되어 이제 Gradle용 Kotlin/JS 플러그인을 사용하는 방법을 배울 수 있습니다.
이러한 변경이 특히 프런트엔드 개발에서 Kotlin/JS를 사용하려는 경우 더 쉽게 시작하고 작업하는 데 도움이 되기를 바랍니다. JetBrains는 Kotlin/JS 학습에 도움이 되는 문서 및 참조 자료를 지속적으로 개선하기 위해 노력하고 있습니다. 따라서 문서나 안내서에 누락된 정보가 있거나, 업데이트 되어야 하는 필수 정보가 있는 경우 댓글로 알려주세요.
Kotlin/Native
성능 최적화
1.3.70에서는 Kotlin/Native 개발 프로세스의 전반적인 성능을 최적화한 작업의 첫 번째 결과물을 보여 드리려 합니다. 컴파일 시간 성능은 Kotlin/Native 개발에서 알려진 약점 중 하나였기에 컴파일 시간을 단축하기 위한 두 가지 새로운 기능을 다음과 같이 준비했습니다.
- 이제 Kotlin/Native 컴파일러가 Gradle daemon에서 바로 실행되므로 새 프로세스를 시작하고 각 컴파일에 컴파일러를 프로세스로 로드하는 데 시간이 들지 않습니다.
- 디버그 모드에서 컴파일러가 프로젝트 종속 요소를 캐시합니다. 이에 따라 첫 번째 컴파일은 조금 더 오래 걸리지만 후속 컴파일은 더 빨리 완료됩니다. 단, 현재 이 기능은 iOS 시뮬레이터(iosX64) 및 macOS(macosX64)에서만 작동하며 여전히 작업 중입니다.
런타임과 디버그 성능도 빠뜨리지 않고 향상했습니다. 1.3.70에서는 객체 할당에 소요되는 시간을 줄여 이제 더 많은 객체가 스택에 할당되고(힙 할당보다 빠름) 컴파일 시 일부 싱글톤 객체가 생성됩니다. 디버그 프로세스도 빨라졌습니다.
단일 애플리케이션에서 여러 Kotlin 프레임워크 지원
이전에는 런타임에 정의된 Obj-C 클래스가 런타임 인스턴스 출처가 서로 달라 충돌을 일으켜 애플리케이션에서 2개 이상의 동적 Kotlin/Native 프레임워크를 사용할 수 없는 알려진 문제가 있었습니다. 1.3.70에서는 이 문제가 수정되어 이제 애플리케이션에서 여러 Kotlin/Native 프레임워크를 사용할 수 있습니다. 공통 종속 요소는 서로 다른 Swift 모듈에 있는 (그리고 서로 다른 Obj-C 접두어를 가진) 프레임워크에 표시됩니다.
벡터 유형 지원
1.3.70부터 Kotlin/Native는 SIMD 유형을 지원합니다. 이에 따라 더 다양한 제3자 API(예: 인기 Apple 프레임워크인 Accelerate 및 SpriteKit)를 Kotlin/Native에서 사용할 수 있게 되었습니다.
스크립트 작업
1.3.70 버전은 IntelliJ IDEA 및 Kotlin 명령줄 도구에서 Kotlin 스크립트를 더 효과적으로 사용할 수 있도록 일련의 개선 사항을 제공합니다.
여기에 더해 사용자가 Kotlin 스크립트 작업에 익숙해지도록 예시가 포함된 프로젝트도 준비했습니다. 여기에는 표준 스크립트 예시(*.main.kts)와 스크립팅 API 사용 및 사용자 지정 스크립트 정의의 예시가 포함됩니다. 프로젝트를 사용해 보고 이슈 트래커에서 여러분의 의견을 공유해 주세요.
컴파일러 및 IDE에서 kotlin-main-kts 지원
Kotlin 1.3에서는 기본 유틸리티 스크립트의 작성 및 사용을 단순화하는 kotlin-main-kts 아티팩트를 도입했습니다. 이 아티팩트는 기본적으로 Kotlin 컴파일러와 IntelliJ 플러그인으로 로드되므로 *.main.kts 스크립트가 바로 지원됩니다. 특히, 이제 kotlin-main-kts.jar을 클래스 경로에 추가하지 않고도 이러한 스크립트를 사용할 수 있습니다.
IntelliJ IDEA에서는 소스 디렉터리 외부에서도 *.main.kts 파일에 대한 동적 종속 요소 분석을 포함한 강조 표시 및 탐색 기능을 제공합니다.
또한 컴파일된 *.main.kts 스크립트 실행의 캐싱을 활성화하여 후속 실행을 훨씬 빠르게 수행할 수 있도록 성능을 개선했습니다.
명령줄 도구
명령줄 도구에도 Kotlin 스크립트 작성에 대한 지원을 확장했습니다.
이제 Kotlin 명령줄 컴파일러와 함께 배포되는 kotlin 러너는 스크립트 실행을 지원합니다. kotlin으로 스크립트를 실행하려면 다음과 같이 스크립트 파일 이름을 전달하기만 하면 됩니다.
이러한 호출은 -script 옵션을 사용하여 컴파일러를 호출하는 것과 동일한 방식으로 스크립트를 실행합니다. kotlin은 기본적으로 .main.kts 스크립트를 인식합니다.
또한 kotlin 러너는 표현식 평가에도 사용할 수 있습니다. 표현식을 평가하려면 다음과 같이 ––e/-expression 옵션의 값으로서 표현식을 전달하세요.
그러면 결과가 바로 나옵니다.
동일한 기능이 Kotlin 명령줄 컴파일러에 추가되어 있지만 옵션 이름이 다릅니다(-Xexpression).
업데이트 방법
언제나처럼 play.kotl.in에서 Kotlin을 온라인에서 사용해볼 수 있습니다.
- Gradle 및 Maven: 컴파일러 및 표준 라이브러리의 버전으로
1.3.70을 사용합니다. Gradle 및 Maven에 대한 문서를 참조하세요. - In IntelliJ IDEA 및 Android Studio: Kotlin 플러그인을 1.3.70 버전으로 업데이트합니다. Tools(도구) | Kotlin | Configure Kotlin Plugin Updates(Kotlin 플러그인 업데이트 설정)을 사용하여 ‘Check again'(다시 확인) 버튼을 클릭하세요.
- Eclipse: 마켓플레이스를 사용해서 플러그인을 설치합니다.
- 명령줄 컴파일러는 Github 릴리스 페이지에서 다운로드할 수 있습니다.
새 릴리스에서 문제가 발생한 경우 언제든지 Slack 포럼(여기에서 초대받기)에서 도움을 요청하거나 이슈 트래커에 문제를 보고해 주세요.
Let’s Kotlin!
외부 기여자
컬렉션용 빌더 함수 지원을 추가해 주신 Fleshgrinder와 reduceOrNull() 함수를 추가해 주신 adellibovi께 감사의 말씀을 전합니다.
이 릴리스에 포함된 pull 요청을 제공해 주신 모든 외부 기여자분들에게도 감사의 말씀을 전합니다.
- pyos
- Steven Schäfer
- Toshiaki Kameyama
- Mark Punzalan
- Mads Ager
- Kristoffer Andersen
- Ivan Gavrilovic
- Jiaxiang Chen
- Kevin Bierhoff
- Alfredo Delli Bovi
- Tillmann Berg
- Victor Turansky
- Alexander Shustanov
- Leonardo Colman Lopes
- Juan Chen
- Jordan Demeulenaere
- Jim Sproc
- Burak Eregar
- Dmitriy Jarosh
- Dat Trieu
- Dmitry Borodin
- Efeturi Money
- Miguel Serra
- Fleshgrinder
- Jens Klingenberg
- Louis CAD
본 게시물은 Pavel Semyonov의 Kotlin 1.3.70 Released를 번역한 글입니다.
Subscribe to JetBrains Blog updates
