Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

`MemberResolver` misses members inherited via self-referential interface (`ResolvedRecursiveType` as implemented interface)

Chiusa
#132 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Una pull request collegata è già stata integrata.

  • #135 di @cowtowncoder — integrata

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java
Ambito
devtools

Direzione di ricerca

Start with MemberResolver and how it walks implemented interfaces, then look at ResolvedRecursiveType.getImplementedInterfaces(), which returns an empty list. Compare with the super-class handling in ResolvedObjectType.getParentClass() that #128 added. Done when the self-referential outerInMid from the reproduction yields the same member methods (get(), top()) as stand-alone OuterI.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

When an implemented interface of a type is a self-reference (ResolvedRecursiveType), it is returned as-is by getImplementedInterfaces(); and since ResolvedRecursiveType.getImplementedInterfaces() returns an empty list (to avoid infinite loops), MemberResolver silently drops all members inherited through that interface.

Reproduction
public interface Top { void top(); }
public interface BaseI<X> extends Top { X get(); }
public interface MidI<T> extends BaseI<OuterI> { }
public interface OuterI extends MidI<String> { }

TypeResolver r = new TypeResolver();
MemberResolver mr = new MemberResolver(r);
// `OuterI` as type parameter of `BaseI<OuterI>`, within `MidI<String>`:
ResolvedType outerInMid = r.resolve(MidI.class, String.class)
        .getImplementedInterfaces().get(0).getTypeParameters().get(0);
mr.resolve(outerInMid, null, null).getMemberMethods().length;          // 0
mr.resolve(r.resolve(OuterI.class), null, null).getMemberMethods().length; // 2 (`get()`, `top()`)

Here outerInMid implements MidI<String> via a self-reference (since MidI<String> was still being resolved), so BaseI and Top (and their methods) are not reachable.

(note: on 1.7 / current main, even stand-alone OuterI resolves to 0 member methods)

Expected

Same members as for stand-alone OuterI.

Notes

#128 handled the equivalent case for super classes: ResolvedObjectType.getParentClass() maps a self-referential super class to the type it represents (ResolvedRecursiveType.getActualType(), new in 1.8). Super interfaces would need similar handling: either in getImplementedInterfaces() of ResolvedObjectType / ResolvedInterfaceType, or in MemberResolver (HierarchicType construction) when traversing interfaces. Changing what getImplementedInterfaces() returns would be a (minor) behavioral change, so MemberResolver-side handling may be preferable.

Lingua principale
Java
Stelle
266
Fork
53
Merge medio
18h 46m
PR unite (30g)
8

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di FasterXML/java-classmate

Tutte le issue di FasterXML/java-classmate

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.