FullyQualifiedType usage found by new checkstyle check

[ZaheerAhmadDev]

Checkstyle import package introduced a new check UnnecessaryFullyQualifiedTypeCheck currently in review checkstyle/checkstyle#21004, while running this check on spring-integration repo it flagged 150 violations in spring-integration

Diff report:https://checkstyle-diff-reports.s3.us-east-2.amazonaws.com/4bb42ce_2026073849/reports/diff/spring-integration/index.html

how the check work:
The check flags a fully qualified type reference like java.util.Map as unnecessary whenever it is the only type using that simple name in the file meaning it could safely be imported and written as just Map. It stays quiet whenever a second, different type with the same simple name also shows up via import, declaration, another qualified reference, or an on-demand import, since qualification is genuinely needed there to tell the two apart.

Since the check isn't merged yet, I'm not asking for any code changes just wondering if there's a specific reason behind using fully-qualified names here instead of importing?.any feedback on the approach how the check itself could be improved, would be great too.

check doc link:https://checkstyle-diff-reports.s3.us-east-2.amazonaws.com/4147d0d_20260808220533/checks/imports/unnecessaryfullyqualifiedtype.html#

[artembilan]

Thank you for doing this, @ZaheerAhmadDev !

I may answer for some reasons:

1. Avro classes are generated, so they could violate many Checkstyle rules. We cannot modify them, so they have to be excluded from checking. I thought we do that already or you fixed them blindly.
2. I prefer to use FQCN for deprecated to avoid warnings.
3. Another case (I might be wrong) is for optional API, so we use that inner class only when respective library is there. Might be the case that imports does not trigger anything being just syntax sugar.
4. and one more (like that AMQP case) when we use same class name from different packages, e.g. Message.

Might be other cases I’ll try to recall when you point to the specific case.

[ZaheerAhmadDev]

1. Avro classes are generated, so they could violate many Checkstyle rules. We cannot modify them, so they have to be excluded from checking. I thought we do that already or you fixed them blindly.

sorry my bad i didnot check the suppression, https://github.com/spring-projects/spring-integration/blob/main/src/checkstyle/checkstyle-suppressions.xml
I fixed those blindly will revert these in the PR. Once the check is in use it should ignore the Avro classes.

2. I prefer to use FQCN for deprecated to avoid warnings.

you can use https://checkstyle.sourceforge.io/filters/suppressionxpathfilter.html could exclude this check for this pattern.

3. Another case (I might be wrong) is for optional API, so we use that inner class only when respective library is there. Might be the case that imports does not trigger anything being just syntax sugar.

since imports don't actually trigger any loading at runtime, I think this one's likely genuinely redundant happy to take a look if you have a specific file/line in mind.

4. and one more (like that AMQP case) when we use same class name from different packages, e.g. `Message`.

check did ignore this secnario.