Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Fechada
  • Algo errado?
#132 0 comentários 0 reações 0 responsáveis Ver no GitHub

Um pull request relacionado já foi integrado.

  • #135 de @cowtowncoder — integrado

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
35/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
java
Domínio
devtools

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Java
Estrelas
266
Forks
53
Merge médio
18h 46min
PRs com merge (30d)
8

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de FasterXML/java-classmate

Todas as issues de FasterXML/java-classmate

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.