Amper 正式转正 Kotlin Toolchain ,Gradle 未来何去何从

最近 Amper 发布了Kotlin Toolchain 0.11: The Next Step for Amper ,核心就是 Amper has evolved into the Kotlin Toolchain and is now Alpha也就是 JetBrains 正式把 Amper 并入 Kotlin Toolchain,并且从实验阶段推进到 Alpha

感觉就是,JetBrains 想给 Kotlin 生态做一个类似 cargo / dotnet / go 那种统一入口。

从 Kotlin Toolchain 0.11 开始,Amper 这个名字在产品定位上就被降级了,核心能力降被整体迁移进 Kotlin Toolchain,以后也没有 amper 命令入口了,全部统一 kotlin

原来的 amper / amper.bat wrapper 要替换成新的 kotlin / kotlin.bat wrapper,IDE 插件也从 Amper 插件切换为 Kotlin Toolchain 插件

从产品上看,以前 Amper 的定位是「帮你用 YAML 配置 Kotlin/KMP 工程」,而现在变成了 Kotlin Toolchain 的一部分,成了 Kotlin 项目的统一入口, 可以通过一个 kotlin 命令创建、构建、运行、测试、发布项目。

JetBrains 之所以这么做,主要是觉得现在的 Kotlin 生态太割裂了,现在做一个 Kotlin 项目需要处理一堆东西:

Kotlin compiler、Gradle、Kotlin Gradle Plugin、Android Gradle Plugin、Kotlin/Native、Xcode/iOS 产物、Maven 发布、Maven Central 签名、source set、平台差异配置......

而现在 Kotlin Toolchain 把 Kotlin 的工程入口从 Gradle 脚本、插件版本、模板碎片,收敛成一个统一的 Kotlin 官方入口,目的就是:

Kotlin 语言很现代,但工程体验还是 JVM 清朝那一套,改变变了

所以 0.11 开始 kotlin 就是统一入口了,比如 kotlin build / kotlin run / kotlin test / kotlin publish ,同时全局 kotlin 命令不会强行让所有项目使用同一个工具链版本,它会自动找到项目里的 wrapper,然后运行匹配版本。

另外 0.11 也终于支持发布 JVM library 到 Maven 仓库,包括 Maven Central, Maven Central 之前发布很麻烦:

sources jar、javadoc jar、PGP 签名、POM 元数据、checksum、deployment bundle 等等,这些东西 Kotlin Toolchain 现在会把这些自动处理掉,你在 module.yaml 里声明 publishing 配置,然后执行 kotlin publish mavenCentral,它就会构建、签名、打包、上传并等待 Maven Central 校验。

不过目前 Kotlin Multiplatform library 还不能发布 ,KMP library publishing 还在做,暂时只能用在 product: jvm/lib

yaml 复制代码
product: jvm/lib
​
description: A meaningful description for this specific module
​
settings:
  publishing:
    enabled: true
    group: com.example # the group has to match your Maven Central namespace
    version: 1.0.0
    # artifactId is optional, and defaults to your module's name
    mavenCentral: enabled
    signArtifacts: true # automatically sign your artifacts, no external GPG binary required
    publishSources: true
    pom:
      url: https://example.com
      scm: https://github.com/my-org/example.git # the SCM connection and dev connection are automatically derived from this
      developers:
        - name: John Doe
      licenses:
        - name: MIT
          url: https://opensource.org/license/mit

其次还有 Cinterop 支持增强 ,Kotlin Toolchain 现在可以根据模块里 cinterop 文件夹下的 .def 文件生成 C library binding,同时 IDE sync 阶段也会生成绑定并提供辅助。

这个对 KMP / Kotlin Native 很关键,因为 Cinterop 如果能被 Toolchain 统一管理,就能减少 Kotlin/Native 工程里大量手动配置。

同时 0.11 还改善了终端输出和 IDE 同步,比如:

  • library sources 会在 sync 后自动后台下载,这样 sync 完你可以先开始写代码,不用等 sources 下载完成
  • IDE 插件的依赖解析从"项目级"对齐为"模块级",和 CLI 行为一致,以前 IDE 可能给某个模块解析出错误依赖版本,或者编辑器警告和 CLI 不一致,现在每个 module 有自己的 resolution scope

核心就是 CLI 和 IDE 行为一致,这也是 Amper / Kotlin Toolchain 的核心价值之一,因为 Gradle 生态长期痛点就是各种:

  • 命令行能过,IDE 红
  • IDE 不红,CI 挂
  • 同步慢
  • 依赖解析不一致
  • source set / target / variant 组合复杂

所以现在 Kotlin Toolchain 如果能把 IDE model 和 build model 做成同一套声明式结构,对 KMP 会很有价值。

最后 0.11 还增加了几个插件开发能力

  • checks:插件可以注册质量检查,比如 lint,然后通过 kotlin check 执行
yaml 复制代码
# my-lint-plugin/plugin.yaml
tasks:
  runLinter:
    action: !kotlinJavaLint
      sources: ${module.kotlinJavaSources}
​
checks:
  - name: lint
    performedBy: runLinter
  • commands:插件可以暴露公开命令,例如 kotlin do updateBaseline
yaml 复制代码
# my-lint-plugin/plugin.yaml
tasks:
  updateBaseline:
    action: !runDetektForBaseline
      sources: ${module.kotlinJavaSources}
      outputFile: ${module.rootDir}/detekt/baseline.xml
​
commands:
  # shorthand when the name of the command matches that of the task
  - updateBaseline
  • generated:统一声明 generated sources、resources、classes、cinterop definitions,替代旧的 markOutputAs
yaml 复制代码
tasks:
  generateStuff:
    action: !myGenerateStuffAction
      outputSources: ${taskOutputDir}/src
      outputResources: ${taskOutputDir}/res
      outputDefFiles: ${taskOutputDir}/cinterop
​
generated:
  sources:
    - directory: ${tasks.generateStuff.action.outputSources}
      language: kotlin
  resources:
    - directory: ${tasks.generateStuff.action.outputResources}
  cinteropDefinitions:
    - directory: ${tasks.generateStuff.action.outputDefFiles}

关于这个 JetBrains 还特别强调,这样的生成物可以被人、AI agent 和其他工具更容易识别

这一点很有意思,也就是 Kotlin Toolchain 明显不是只给人写配置用的,它还在给 AI coding / agent 场景做准备,而YAML 声明式配置明显比 Gradle Kotlin DSL 更容易被工具理解。

Gradle 脚本本质上是可执行代码,里面可以有条件判断、函数调用、动态任务注册、插件魔法吗,这些对 IDE、CI、AI agent 来说都很难静态分析。

从目前看, Amper 进入 Kotlin Toolchain 之后,也代表着它正式成为未来的主角,kotlin 统一入口也意味着未来 gradlew 等命令会慢慢边缘化

短期看 gradle 还会在,但是现在在 Kotlin-first / KMP-first 的新项目里,Gradle 的"直接可见度"会被逐步降低

想想,JetBrains 2023 年介绍 Amper 时还说, Amper 是作为 Gradle plugin 实现的,使用 YAML 做项目配置,目的是先验证用户体验,同时也强调他们会承诺支持 Maven 和 Gradle,不会改变对这些技术的支持。

但是 2026 之后,Amper 就不再和 Gradle 有关系,更多强调的是 "ecosystem doesn't just need another build tool -- it needs a unified entry point into all of Kotlin",也就是 JetBrains 的已经从"改善 Gradle 配置体验"的目标,升级成了"建立 Kotlin 官方工具链入口"。

所以 0.11 这次不是一个小版本,它同时也是一个信号: JetBrains 在告诉社区:

Kotlin 不想再只是"语言 + Gradle 插件",它已经变成一个完整的工具链生态。

链接

blog.jetbrains.com/amper/2026/...

相关推荐
敲代码的彭于晏1 小时前
Bean 生命周期完全图解:前端同学也能看懂的 Spring 核心机制
java·前端·后端
IT_陈寒1 小时前
Redis内存飙升的锅,原来是我没搞懂这个过期策略
前端·人工智能·后端
云浪1 小时前
前端二进制数组完全指南:ArrayBuffer、TypedArray、DataView 一次讲透
前端·javascript
张风捷特烈1 小时前
Flutter 类库大揭秘#02 | path_provider 各平台实现
前端·flutter
铁皮饭盒2 小时前
26年bunjs, elysia+pg一把梭, redis都省了
前端·javascript·后端
plainGeekDev2 小时前
ButterKnife → ViewBinding
android·java·kotlin
lichenyang45315 小时前
Docker 学习笔记(一):为什么需要镜像、容器和仓库?
前端
kyriewen15 小时前
别再对着 TypeScript 报错发呆了:我把 10 个最常见的红色波浪线翻译成了人话
前端·javascript·typescript