Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Unintuitive information about member methods wrt return type covariance

オープン
#57 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
java
領域
devtools

調査の方向性

まず issue の C/MemberResolver/TypeResolver の例を再現し、次に MemberResolver.getMemberMethods と、それが使用するメンバー解決の経路を調べてください。継承された共変戻り値がどのように選択されるかを確認し、解決されたメソッドが Foo を返す A.doSomething() だけでなく、Bar を返す B.doSomething() を公開していることを検証してください。

索引モデルが issue の本文から書いたものです。

説明

I've recently come across a surprising behaviour regarding MemberResolver's getMemberMethods. Consider the following classes:

interface Foo {}

class Bar implements Foo {}

interface A {
    Foo doSomething();
}

class B {
    public Bar doSomething() {
        return null;
    }
}

class C extends B implements A {}

Notice that C implements A.doSomething() through B.doSomething().

When inspecting the members of C like this:

var typeResolver = new TypeResolver();
var methods = new MemberResolver(typeResolver).resolve(typeResolver.resolve(C.class), null, null).getMemberMethods();

methods will contain a single method - public abstract Foo A.doSomething(). However, this doesn't tell the whole story - notice that B.doSomething actually returns a Bar instead of a Foo. Therefore, in this case I'd expect methods to contain public Bar B.doSomething(), which gives me more information than A.doSomething() does.

主要言語
Java
スター
266
フォーク
47
平均マージ
1時間 42分
マージ済み PR（30日）
1

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

FasterXML/java-classmate のほかの issue

FasterXML/java-classmate の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。