Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[BUG] @Bean factory method with a type variable (<T> Foo<T>) is not a candidate for a parameterized injection point

Open
  • Is something wrong?
#816 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
java, kotlin, spring
Domain
developer-experience, tooling

Research direction

Read SpringCoreUtil.kt functions isEqualOrInheritorBeanType, filterByExactMatch, and filterByBeanPsiType, then trace their use from NativeSearchService.kt in findActiveBeanDeclarations. Compare the plugin lookup with Spring’s fallback behavior for unresolvable generics. Done means tests cover the generic field and the case with a typed bean, with the strict match taking precedence.

Written by the indexing model from the issue text.

Description

in:spring-core navigation
Component

Navigation gutter

Problem details

A @Bean factory method with its own type parameter is not found for a parameterized injection point, while Spring injects it.

public class TestGeneric<T> {}

@Configuration
public class DemoConfig {
    @Bean
    public <T> TestGeneric<T> foo() {
        return new TestGeneric<>();
    }
}

@Component
public class DemoService {
    @Autowired TestGeneric<String> generic;   // Spring injects foo
}
  • Spring (AnnotationConfigApplicationContext, spring-context 6.2.14) injects foo.
  • The plugin shows no target for the generic field: the bean-dependencies gutter is empty, and the autowiring inspection reads the same lookup (NativeSearchService.findActiveBeans).

Measured with a gutter probe test on main and on both versions of PR #800 (filterByExactMatch + isAssignableFrom): the result is [] everywhere. This is not a regression of #800, the gap is older.

Cause: Spring matches the candidate in its fallback pass. When the strict generic match finds nothing for a single-valued injection point, GenericTypeAwareAutowireCandidateResolver accepts a candidate whose type has unresolvable generics (ResolvableType.hasUnresolvableGenerics()): a raw type or a type variable such as TestGeneric<T>. The plugin has no such pass:

  • SpringCoreUtil.isEqualOrInheritorBeanType / equalParamsWithBound compare T with String and reject it;
  • PsiType.isAssignableFrom rejects it too, because TestGeneric<T> is not assignable to TestGeneric<String> in Java.
Steps to reproduce
  1. Open the snippet above in a project with Spring Context on the classpath.
  2. Look at the bean-dependencies gutter of the generic field.
  3. Expected: a target foo(). Actual: no target.
Additional information

Expected behaviour, following Spring:

  • run the fallback only when the strict pass finds no candidate;
  • accept only candidates with unresolvable generics (type variable or raw return type);
  • the strict pass must keep winning: with an additional @Bean TestGeneric<String> typed(), only typed is a candidate.

A test should cover the single field, plus the case where typed() exists next to foo().

Plugin version

main at 65ccf517c (generation 35, unreleased)

IDE name and build

IntelliJ IDEA 2026.2.3 (IU-262)

Build system

IntelliJ

Additional context
  • Found during the review of PR #800 (#799). The Spring oracle and the probe test are rows H and X4 of its empirical matrix.
  • Related: #799 (generic @Bean subclass for a parameterized injection point), #749 (inherited generic @Bean factory in the abstract-component gutter).
  • Code: modules/spring-core/.../util/SpringCoreUtil.kt (isEqualOrInheritorBeanType, filterByExactMatch, filterByBeanPsiType), modules/spring-core/.../service/NativeSearchService.kt (findActiveBeanDeclarations).

Created automatically by github-issue-manager skill.

Dominant language
Kotlin
Stars
163
Forks
16
Avg merge
5h 35m
Merged PRs (30d)
183

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from explyt/spring-plugin

All issues in explyt/spring-plugin

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.