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

shortenFullyQualifiedTypes can change type resolution for inherited nested types

Open
  • Is something wrong?
#3,117 0 comments 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
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
java
Domain
tooling

Research direction

Start with the shortenFullyQualifiedTypes() implementation and reproduce the issue using the linked Gradle project and ./gradlew spotlessApply. Trace how inherited nested types affect shortening decisions, then verify that the qualified external.Type reference remains safe and the formatted project still compiles.

Written by the indexing model from the issue text.

Description

Summary

shortenFullyQualifiedTypes can change the meaning of a qualified type when the simple name is also an inherited nested type.

The formatter avoids some collisions with types declared in the same compilation unit, but does not appear to account for member types inherited from a superclass or interface.

Reproducer

Spotless Gradle plugin 8.10.3, with shortenFullyQualifiedTypes() as the only configured Java step:

The complete Gradle project is available here:

https://gist.github.com/MattAlp/a50100bc9d712c470ded424c36e8f315

The reproducer contains:

  • Base, which declares nested type Type
  • Child, which extends Base
  • external.Type, which is referenced by fully qualified name

Before formatting, Child contains:

public static String use(external.Type value) {
    return value.externalOnly();
}

The project compiles successfully. After running:

./gradlew spotlessApply

Spotless adds import external.Type; and changes the code to:

public static String use(Type value) {
    return value.externalOnly();
}

The unqualified Type resolves to the inherited Base.Type, not external.Type. Compilation then fails:

cannot find symbol
  method externalOnly()
  location: variable value of type Type

Suggested behavior

Leave a qualified reference alone when its simple name can resolve to an inherited member type. If this cannot be determined without a classpath, the conservative behavior should be to leave the qualification intact.

Related work

This appears related to:

  • #3033 — same-compilation-unit type collisions
  • #3031 — collisions with types declared in the same file
  • #3037 — preserving existing unqualified type resolution
Dominant language
Java
Stars
5.7k
Forks
563
Avg merge
1d 7h
Merged PRs (30d)
51

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 diffplug/spotless

All issues in diffplug/spotless

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.