GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Do not strip a used `java.lang.X` import: it may be the only thing that picks the right class · Issue #149 · openjavaformat/open-java-format

Do not strip a used java.lang.X import: it may be the only thing that picks the right class #149

New issue
Copy link
New issue
Copy link
Closed
#174
Closed
Do not strip a used java.lang.X import: it may be the only thing that picks the right class#149
#174
Copy link
Labels
bugSomething isn't workingSomething isn't working

Description

@abashev
abashev
opened on Oct 23, 2026
Issue body actions

Upstream: palantir#1778
Kind: bug | Priority: medium

palantir-java-format#1778 (closed without merging on 2026-10-17, by an outside contributor; it fixes palantir-java-format issue 1334) points out that unused-import removal deletes every single-type import whose qualifier is java.lang. That is unsound: a single-type import shadows both a same-package class and a class pulled in by a wildcard import. If the file also sees another Byte (in its own package or via import some.pkg.*), removing import java.lang.Byte; either makes the name ambiguous or silently rebinds it to the other class, and the build breaks. The proposed fix removes a java.lang single-type import only when its simple name is not referenced anywhere in the file (code or Javadoc); import java.lang.*; and unused java.lang.X imports are still removed.

Why it matters to us: our RemoveUnusedImports still has the unconditional java.lang branch (around line 330), so we have the same defect. A formatter that changes which class a name binds to is a correctness problem, not a cosmetic one, even though the trigger is rare. Upstream did not accept the change, so we would be adopting it on our own.

Affected files: open-java-format/src/main/java/com/palantir/javaformat/java/RemoveUnusedImports.java and its unit test.

Before (how it is formatted today; derived from our code, not run):

package bar;

import foo.*;
import java.lang.Byte;

class Test {
    Byte b;
}

becomes

package bar;

import foo.*;

class Test {
    Byte b;
}

After (with the change): the java.lang.Byte import stays, because Byte is used in the file.

Suggested action: port the idea (small change in one method; check that the existing test which expects a used java.lang import to disappear is updated). The PR also adds an agent-instructions file to the repo root; do not take that over.


Filed from an upstream-watch ticket after manual review.

Activity

  1. abashev
    added
    bugSomething isn't workingSomething isn't working
    on Oct 30, 2026
  2. abashev
    closed this as completedin #174on Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.