Kotlin: a memberless stub the Java side makes for a missing kotlin.* type is used by K2 (Function1.invoke unresolved)
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 28/100
調査の方向性
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
- 平均マージ
- 2時間 51分
- マージ済み PR（30日）
- 3
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
CodeLaser/maddi のほかの issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
build/ci good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 58/100
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 65/100
CodeLaser/maddi の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
Netcracker/qubership-integration-platform#1046 ·
メンテナーはふだん 2 日以内に返信
-
`check_java_version()` fails when Java path contains spaces (Windows / Git Bash, `C:\Program Files`)オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
Fix Math.ceilDiv wrong result for exact positive divisions対応中かも @pamod-madubashana が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
scala-native/scala-native#5094 ·
メンテナーはふだん 1 日以内に返信
-
NullPointerException in blocking command completion callback when the command succeeds (3.52.0)オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 2 日以内に返信