Kotlin 1.4.0-RC!

触手可及!我们很高兴地宣布Kotlin 1.4.0-RC,它将是我们的编程语言下一个主要版本的候选,请继续阅读以了解Kotlin 1.4.0中的变化,并确保在Kotlin 1.4.0正式发布前尝试了这些新特性。

img

特别感谢所有尝试过(1.4-M1, 1.4-M2, 和1.4-M3)里程碑版本,并分享了反馈,有助于我们对该Kotlin版本改进的用户。

这篇博客着重介绍Kotlin 1.4.0-RC中可用的新特性及关键改进:

提升IDE对*.gradle.kts的支持

我们在Kotlin 1.3.70中显着改善了IDE对Gradle Kotlin DSL脚本(* .gradle.kts文件的支持,改进在Kotlin 1.4.0-RC中仍在持续。以下新版本带来的功能:

显式加载脚本配置性能更加优异

在之前,当你向build.gradle.ktsbuildscriptplugins块添加插件后,新的脚本配置将在后台自动加载。在脚本被应用后,你将能使用新插件的代码提示功能。

为了提高性能,我们删除了这种自动的行为,在输入时变更将应用到脚本配置。对于Gradle 6.0及更高版本,你需要点击显式地将变动应用到配置上,或通过Load Gradle Changes重新导入Gradle项目。

在Gradle的早期版本中,你需要在编辑器中手动点击Load Configuration加载脚本配置。

我们在Gradle 6.0+的IntelliJ IDEA 2020.1中增加了另一个action, Load Script Configurations,只加载了脚本配置的变动,而非更新整个项目。这比重新导入整个项目所需的时间少得多。

更好的错误报告

以前只能在独立的日志文件中看到Gradle Daemon(后台运行的进程,该进程负责所有与Gradle相关的任务和活动)的报错。现在,如果你用Gradle 6.0及更高的版本,则Gradle守护程序将直接返回有关错误的所有信息,并将其显示在Build工具窗口中。这样省时又省力。

img

项目配置中更少的样板代码

通过改进Kotlin Gradle插件,你可以在Gradle build文件中编写更少的代码:默认启用了最通用的方案。

标准库成为了默认依赖

绝大多数项目都需要依赖Kotlin标准库。从1.4.0-RC开始,不再需要在每个源集中手动加入stdlib的依赖-现在会默认添加。自动添加的标准库版本取决于所使用Kotlin Gradle插件,因为它们版本相同。

这是1.4前Android,iOS和JavaScript目标的多平台项目配置示例:

现在,你完全不需要显式声明对标准库的依赖,并且支持在1.4-M2中公布的分层架构项目了,你只需声明一次依赖项。因此Gradle build文件将更加简洁和易读:

对于平台及后端共享的代码源集,会添加相应的标准库,而余下部分将添加通用的标准库。Kotlin Gradle插件将根据kotlinOptions.jvmTarget配置选择恰当的JVM标准库。

如果你明确指定了标准库依赖(例如需要其他版本),Kotlin Gradle插件则不会覆盖或增加第二个标准库。而如果你根本不需要标准库,则可以向Gradle配置添加opt-out标记:

Kotlin/Native

简化CocoaPods的依赖管理

之前,一旦你在项目中集成了依赖管理器CocoaPods,便可以只在Xcode中构建多平台项目中的iOS,macOS,watchOS,或tvOS部分。而其余部分则可在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仓库中添加对Pod库的依赖

  1. 在CocoaPods存储库中通过pod()添加要使用的Pod库依赖。 你还可以将依赖以子模块方式添加。
  1. 重新导入项目。 要在Kotlin能访问依赖,请导入以下包:

我们也很乐意向你共享一个示例项目,示例演示了如何向CocoaPods远程仓库及本地的Pod库添加依赖。

默认在Apple目标上生成正式的.dSYM

iOS应用程序调试崩溃时会需要分析崩溃报告,而崩溃报告通常需要符号映射才能正常阅读。要在Kotlin中进行地址映射,需要Kotlin代码的.dSYM包。从1.4-M3开始,Kotlin/Native编译器会默认在Darwin平台上为发行版二进制文件生成.dSYM。它可以被-Xadd-light-debug = disable编译器配置来禁用。在其他平台上是默认禁用的。要在Gradle中切换该配置,请使用:

性能改进

我们将继续专注于优化Kotlin/Native开发流程的整体性能:

  • 在1.3.70中,我们引入了两个新特性来提高Kotlin/Native的编译性能:项目依赖缓存和运行在Gradle守护进程的编译器。同时感谢你的反馈,让我们设法解决了许多问题并提高了这些功能的整体稳定性,我们会继续努力。
  • 运行时性能也得到了一些改进。由于GC的优化,整体运行时性能得到了提高。改进在有大量长生命周期对象的项目中尤其明显。 HashMapHashSet集合现在会通过避免多余的装箱来提高性能。

Kotlin/JS

在Kotlin 1.4.0-RC中,我们让默认的编译器后端兼容@ JsExport注解。除此之外,我们还为npm依赖管理和集成Dukat的Gradle项目提供更健壮和更细粒度的控制,进一步完善了对CSS的支持,并首次展示Node.js API的集成。

默认编译器后端的@JsExport注解

之前Kotlin 1.4的里程碑版本中,我们引入了@JsExport注解,在使用新的IR编译器后端时,该注解用于从JavaScript或TypeScript中提供顶层声明。Kotlin 1.4-M3开始,已允许在当前默认的编译器后端中使用该注解了。若配合当前默认的编译器后端时,@JsExport注释的顶层声明将被禁止名字调整。两个编译器后端都具有该注解,使得你可以在其中随意切换,而不必调整顶层声明的导出逻辑。请注意,仅在使用新的IR编译器后端时,才可以使用TypeScript定义

npm依赖管理的变动

依赖要求显式指定版本

在不指定版本号的情况下声明npm包依赖会让其管理变得困难。这就是为什么从现在开始,需要根据npm的semver语法明确指定版本或版本范围的原因。 Gradle DSL还支持多个范围的依赖,从而可以精准确定项目所接受的版本,例如:

NPM依赖的其他依赖类型

除了你在dependencies块中使用npm(...)指定的常规依赖外,现在还可以使用三种依赖:

要了解何时该使用何种依赖类型,请查阅npm链接的官方文档。

Automatic inclusion and resolution of transitive npm dependencies

以前,如果你所依赖库的作者没有将package.json文件手动添加到工件中,则有时需要手动导入其npm依赖项。例如kotlinx.serialization就是这种情况,它要求在Gradle build文件中包含text-encodingabort-controller依赖,以使该软件包在Kotlin/JS上可以使用。

现在,Gradle插件会自动为库生成package.json文件,并将其包含在jarklib构件中。当包含该种类库时,将会自动分析文件并引入必要的依赖项,从而无需手动将其添加到Gradle build文件中。

CSS支持的调整

Kotlin 1.4-M2,我们直接通过cssSettings从Gradle引入了对webpack CSS和样式加载器的支持。为了更准确地表现其实际功能和效果,此后我们将配置参数重命名为cssSupport。未来Gradle插件将默认不再启用CSS支持——我们在1.4-M2中尝试过的设置。我们希望这个变动能避免对那些自行处理样式表的方式造成混淆(例如使用Sass或Less加载器)。在这种情况下,项目的默认配置已经注入了一些CSS设置,这可能会导致冲突,但并不是马上可见的。

要在你的项目中启用CSS支持,请将Gradle build文件的cssSupport.enabled设置到webpackTaskrunTasktestTask中。使用IntelliJ IDEA中的向导创建新项目时,这些设置将自动包含在生成的build.gradle(.kts)文件中:

我们意识到每个任务都需要单独设置很不方便。我们考虑在插件的DSL中添加cssSupport的中心配置处(你可以在这里了解我们的进度)。

Dukat集成的改进

Kotlin/JS Gradle插件为其与Dukat的集成添加了更多细粒度的控件,该工具可将TypeScript声明文件(.d.ts)自动转换为Kotlin的外部声明。现在,你有两种不同的方案来选择是否以及何时生成Dukat:

构建时生成外部声明

npm依赖函数在包名称和版本之后添加了第三个参数:generateExternals。这让你能单独控制Dukat是否该为特定依赖项生成声明,如下所示:

你可以在gradle.properties文件中通过kotlin.js.generate.externals配置(旧版本名为kotlin.js.experimental.generateKotlinExternals,当时它仍处于实验状态),同时为所有npm依赖项设置生成器的行为。像往常一样,独立的显式设置优先于通用配置。

通过Gradle任务手动生成外部声明

如果要完全控制Dukat生成的声明,应用手动配置,或者自动生成的外部对象遇到问题,还可以通过generateExternalsGradle任务手动为所有npm依赖生成声明。将在项目根目录名为externals的目录生成声明文件。你可以查看生成的代码,并将想要的部分复制到源目录中。(请注意,在源文件夹中手动提供外部声明,并为同一依赖启用构建时外部声明生成会引发问题。(原文:”result in resolution issues”))

kotlin.dom和kotlin.browser工件分离的迁移预备

为了Kotlin/JS的browser和DOM bindings的快速发展,并让它们与语言本身的发布周期脱钩,我们不赞成使用当前kotlin.domkotlin.browser包中的API。我们在kotlinx.domkotlinx.browser包提供了这些API的替代品,这些包将在未来版本中提取出来以分离工件。迁移到这些新的API很简单。只需将项目中的导入指向到新的kotlinx软件包。可通过IntelliJ IDEA的Alt-Enter访问快速修复以辅助迁移。

预览:kotlinx-nodejs

我们很高兴地分享Node.js APIkotlinx-nodejs的正式bindings的预览。虽然一直以来都可以使用Kotlin来定位Node.js,但是当你可以通过类型安全的方式访问其API时,就可以充分释放该目标的全部潜能。可以在GitHub上查看kotlinx-nodejsbindings。

要将kotlinx-nodejs添加到你的项目,请确保将jcenter()已添加到仓库中。然后便可以轻松地在工件上添加依赖:

Gradle的变更被加载后,你可以使用Node.js提供的API进行试验,例如通过使用其DNS解析程序包:

尤其因为它是预览版,我们建议你尝试一下kotlinx-nodejs并向问题跟踪器报告在仓库遇到的任何问题。

弃用kotlin2js和kotlin-dce-js Gradle插件

从Kotlin 1.4开始,Kotlin面向JavaScript的旧Gradle插件将被正式弃用(kotlin2jskotlin-dce-js),取而代之的是kotlin.jsGradle插件。 这些插件中的关键功能以及kotlin-frontend-plugin(早前已被弃用)已被提炼到新插件中,从而允许兼容Kotlin/Multiplatform项目,使用统一的DSL配置Kotlin/JS目标。

Kotlin 1.3.70起,当执行browserProductionRunbrowserProductionWebpack任务时,无效代码消除(DCE)会自动应用,创建并优化程序的捆绑包。 (请注意,当前只有在面向浏览器并输出为生产,而非Node.js或测试的情况下才可使用无效代码消除功能。但如果你有其他用例也需要去解决,请随时在YouTrack上)我们分享。

其他用户体验改善和重要修复

  • 我们为禁止使用@ JsExport注解添加了更多的编译器错误,以凸显此类问题。
  • 使用IR编译器后端时,我们启用了一项新策略,其中包括对klib进行增量编译,这是我们为缩短编译时间而采取的许多步骤之一。
  • webpack服务器开发的配置已经得到调整,以防止使用热重载功能时出现类似ENOENT:无此类文件或目录之类的错误。

不断发展的Kotlin标准库API

就Kotlin的发展阶段而言,Kotlin 1.4是一个功能发布版,因此它带来了很多你已从以前的博客中了解的新功能。但是,功能发布的另一个重要方面是它包括对现有API的重大改进。下面简要概述1.4版本可能带来的变化。

实验性API趋于稳定

为了尽快交付你希望能在Kotlin库中看到的新内容,我们提供了实验版本。这个状态表明API的功能仍在开发中,未来可能会有无法兼容的变动。当你使用实验性API时,编译器会根据API的状态向你发出警告,并要求opt-in(@ OptIn注解)。

在功能发布版中,实验性API会提升为稳定版本。在这一点上,我们保证其形式和行为不会突然发生变化(只在合适的弃用周期内才会变动)。一旦API稳定发布,你就可以安全使用API,不会有警告或opt-ins了。

在1.4,我们将Kotlin库中的许多实验功能提升到稳定版。以下是部分示例以及它们引入的版本:

更多的API函数和类在1.4稳定。从这个版本(1.4.0-RC)开始,在项目中使用它们将不需要@OptIn注解。

弃用周期

功能发布版还涉及当前弃用周期中采取的下一步措施。在增量版本中,我们以WARNING级别开始的新弃用周期,在功能版本中,我们将其收紧到ERROR。同样,已是ERROR级别的API将在新的代码中完全隐藏,仅保留其二进制形式,以保持与已编译代码的兼容性。这些流程一同确保弃用的API会逐步被移除。

如果你代码所使用的API弃用等级为WARNING,则编译器会针对该用法发出警告。当你更新到Kotlin 1.4.0-RC,则其中一些警告将变成错误。使用IDE提示的正确用法替换错误的用法,并确保你的代码已再次编译。

有关Kotlin标准库API中重大更改的详细信息,请参见Kotlin 1.4兼容性指南

脚本

我们在之前几篇博客中都跳过了本节,但是我们并没有停止致力于Kotlin脚本的工作,以使其在1.4中更稳定,更快,更容易使用。在RC版本中,更好的性能,大量的问题修复及功能改善,都是肉眼可见的。

工件重命名

为了避免工件名称混淆,我们将kotlin-scripting-jsr223-embeddablekotlin-scripting-jvm-host-embeddable重命名为kotlin-scripting-jsr223kotlin-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]((https://youtrack.jetbrains.com/issues/KT?q=Tag: language-committee-approved Target versions: 1.4-RC, 1.4-M3, 1.4-M2, 1.4-M1, 1.4.0)查看。

候选发行版备注

现在我们已到达了Kotlin 1.4的最终发布候选版本了,是时候开始编译和发布!与之前的里程碑版本不同,可以保证Kotlin 1.4.0-RC创建的二进制文件能与Kotlin 1.4.0兼容。

如何尝试最新版本

同样的,你可以在play.kotl.in在线使用Kotlin。

在IntelliJ IDEA和Android Studio,你可以更新Kotlin插件到1.4-M2版本。操作指南

如果要在现有项目使用预览版,则需要在Gradle或Maven中为预览版本配置构建

你可以在Github发行页下载命令行编译器。

你可以使用随版本发行的库的以下版本:

这里查看有关发行版的更多细节和兼容库列表。

分享你的反馈

如果你发现错误并向我们的问题跟踪器进行报告,我们表示非常感谢。我们尝试在最终发行版前解决所有重要问题,这意味着无需等到下一个Kotlin发行版你的问题便能得到解决。

如果你有任何疑问并想参与讨论,欢迎加入Kotlin Slack(在这里获得邀请)的#eap channel频道。在该频道中,你还可以获取有关新预览版的通知。

Let’s Kotlin!

其他贡献者

同样感谢提交的PR合并到该版本中的所有其他贡献者:

此条目发表在官方分类目录。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。 必填项已用*标注