No Gradle toolchain is declared, so the build silently uses whatever JAVA_HOME provides

未关闭
#5 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
1-2 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
java, kotlin

调研方向

Read maddi-kotlin-k2/build.gradle.kts, which already documents using the daemon JDK instead of a provisioned toolchain because Kotlin 2.4 targets JVM 25 while development uses JDK 26. Add a Gradle toolchain that still allows that split so local and CI builds match. Cross-check docs/landing-surface-checklist.md §3. Done when ./gradlew build uses a declared toolchain without breaking the openjdk/k2 compiler path.

由索引模型根据 Issue 内容生成。

描述

build/ci

There is no Gradle toolchain declaration anywhere, so the build compiles against whatever
JAVA_HOME happens to be. This is the same class of latent portability bug as the missing daemon
heap, which made git clone && ./gradlew build fail on any machine without a user-level
~/.gradle/gradle.properties — it passed locally only because that file supplied one, and CI was
the first environment honest enough not to have it.

Declaring a toolchain would make CI and local builds agree by construction rather than by
convention.

The complication, which is why this is not a one-liner. The openjdk front end reaches into
jdk.compiler internals, and maddi-kotlin-k2/build.gradle.kts already notes that it deliberately
uses the daemon JDK rather than a provisioned toolchain, because Kotlin 2.4 caps its target at JVM
25 while development happens on JDK 26. Any toolchain declaration has to accommodate that split.

Recorded in docs/landing-surface-checklist.md §3.

主要语言
Java
星标
1
派生
1
平均合并
1 小时 44 分钟
30 天内合并 PR
6

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

CodeLaser/maddi 的其他 Issue

查看 CodeLaser/maddi 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。