Kotlin: a memberless stub the Java side makes for a missing kotlin.* type is used by K2 (Function1.invoke unresolved)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Reproduce with a Java source set that lacks kotlin-stdlib and mentions kotlin.jvm.functions.Function1, plus Kotlin that calls through Function1; the Java side logs ClassSymbolScanner stub creation. Existing kotlin-package tests in maddi-modification-prepwork and maddi-modification-link put the stdlib on both sides and will not catch this. Done is K2 preferring its own library model over a Java-created stub, or the mixed inspector refusing that classpath mismatch.
由索引模型根据 Issue 内容生成。
描述
Corrected 2026-09-28, the same day it was filed. The first version said that any Java mention of Function1 breaks Kotlin calls. It does not. It happens only when the Java source set does not have kotlin-stdlib on its class path. Then the Java front end creates a memberless stub for kotlin.jvm.functions.Function1, and K2 resolves against that stub. With the stdlib jar as a dependency of the Java source set, the same fixture parses cleanly. The original trigger came from a test harness that put the stdlib on K2's path only.
What remains is a robustness issue, not a correctness one on a buildable project: a stub made by one front end is used by the other.
package k
class X { fun apply(f: (String) -> Unit, s: String) { f(s) } }
| Java source beside it, Java source set WITHOUT kotlin-stdlib | Kotlin apply |
|---|---|
class X { } |
{f.invoke(s);} |
class X { void unrelated(kotlin.jvm.functions.Function1<String, String> g) { } } |
k2-unresolved-call:f at 2:55 |
class X { void unrelated(kotlin.jvm.functions.Function0<String> g) { } } |
fine |
The Java side logs WARN ClassSymbolScanner -- Creating stub type for …, and a Java file that calls a stubbed type is dropped (Dropping compilation unit … (unresolved symbol)). Both are visible. What is not visible is that the Kotlin half then silently loses every call through the stubbed type.
When it matters. It matters when a configuration is incomplete, for example a hand-assembled source-set configuration (as coil needs) that forgets the stdlib on the Java side. The failure lands in Kotlin code that is correct, far from the missing class-path entry.
Options. K2 could prefer its own library model over a stub the Java side created (a stub is marked as such), or the mixed inspector could refuse to run when a Java source set lacks the stdlib while a Kotlin source set in the same project has it.
Not pinned by a test: the tiers in maddi-modification-prepwork and maddi-modification-link (package kotlin) put the stdlib on both sides, as a real build does.
- 主要语言
- Java
- 星标
- 1
- 派生
- 1
- 平均合并
- 1 小时 44 分钟
- 30 天内合并 PR
- 6
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
CodeLaser/maddi 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
build/ci good first issue
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 14/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
维护者通常 1 天内回复
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 72/100
liberation-data/drivine4j#547 ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 70/100
-
BindingServiceProperties.bindings regressed to a non-thread-safe TreeMap in GH-3158: concurrent first use of binding names corrupts it可能已有人在做 @AkashB23 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 62/100
spring-cloud/spring-cloud-stream#3321 ·
维护者通常 1 天内回复
-
[Bug] 资源包列表 与 模组/数据包/世界 列表排列顺序不一致可能已有人在做 @fishdry1000 于 4 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
ai-driven-fuzzing bug claude Minor
难度 2/5 1-3 小时 新手友好度 72/100
linagora/twake-calendar-side-service#1333 ·
维护者通常 1 天内回复