Skip to content

Private members are never inherited, and package-private members are only sometimes inherited, the Java import analysis needs to account for that. - #8752

Merged
lahodaj merged 1 commit into
apache:masterfrom
lahodaj:proper-inheritance
Oct 10, 2025
Merged

lahodaj merged 1 commit into
apache:masterfrom
lahodaj:proper-inheritance

Conversation

@lahodaj

@lahodaj lahodaj commented Aug 22, 2025 •

Copy link
Copy Markdown
Contributor

Consider these files:

package api;
public class A {
    public static void test() {}
    public static void test(int i) {}
}

package hierbas.del.litoral;
import static api.A.*;
public class Test extends Base {
    public static void t() {
    }
}
class Base {
    private static void test() {}
    private static void test(int i) {}
}

And now consider a piece of code that tries to add (using QualIdents) calls to A.test()/A.test(0) inside Test.t(). Given the methods are accessible using simple names, this should produce just:

test();
test(0);

But import analysis sees the test methods in the superclass, thinks there's a clash and uses A.test()/A.test(0). There's no clash, of course, as the private members are not inherited.

This PR tries to resolve that, but considering the modifiers of the members from supertypes.


^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

  • are all your own work, and you have the right to contribute them.
  • are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

  1. Was this PR correctly labeled, did the right tests run? When did they run?
  2. Is this PR squashed?
  3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
  4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

@lahodaj lahodaj added this to the NB28 milestone Aug 22, 2025
@lahodaj lahodaj added the Java [ci] enable extra Java tests (java.completion, java.source.base, java.hints, refactoring.java, form) label Aug 22, 2025
…only sometimes inherited, the Java import analysis needs to account for that.
@lahodaj
lahodaj force-pushed the proper-inheritance branch from ab596f3 to f6aa4d7 Compare October 9, 2025 07:20

@mbien mbien left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code makes sense to me, thanks!

@lahodaj
lahodaj merged commit 2e80f29 into apache:master Oct 10, 2025
35 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Java [ci] enable extra Java tests (java.completion, java.source.base, java.hints, refactoring.java, form)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants