Skip to content

Conversation

@lahodaj
Copy link
Contributor

@lahodaj lahodaj commented Dec 5, 2025

The Java refactoring is sometimes using class path (ClasspathInfo) that is, to me, extremely weird. In the specific case of #9056, the ClasspathInfo used to process GspIndenter does not in some cases contain the lexer module, while the groovy/groovy.gsp definitely lists it as a dependency.

The consequence of that is that there are compile-time errors in the file(s) with this broken class path. Sometimes, it may lead to "catastrophic" failures like:
https://bugs.openjdk.org/browse/JDK-8373094

but even if it does not, wrong class path is likely to lead to weird effects. Like, in the test for the PR, testComplexRename1, inside main.Main, not only test(Side) will be renamed, but also test(String) will be renamed with the current state, as the classpath when analyzing main.main does not contain side.

The goal of this PR is to use class path that is more sensible for the rename refactoring.


^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 the Java [ci] enable extra Java tests (java.completion, java.source.base, java.hints, refactoring.java, form) label Dec 5, 2025
@mbien mbien linked an issue Dec 6, 2025 that may be closed by this pull request
@mbien mbien added the ci:dev-build [ci] produce a dev-build zip artifact (7 days expiration, see link on workflow summary page) label Dec 6, 2025
@lahodaj lahodaj added this to the NB29 milestone Dec 10, 2025
@lahodaj lahodaj marked this pull request as ready for review December 10, 2025 10:01
@mbien
Copy link
Member

mbien commented Dec 10, 2025

can confirm that this fixes the issue, I could rename the (heavily used) utility method with all projects open.

Comment on lines -370 to +371
switch (p) {
case PRECHECK:
case FASTCHECKPARAMETERS:
return JavaSource.forFileObject(docTreePathHandle != null? docTreePathHandle.getTreePathHandle().getFileObject()
: treePathHandle.getFileObject());
case PREPARE:
case CHECKPARAMETERS:
if(treePathHandle != null && treePathHandle.getKind() == Tree.Kind.LABELED_STATEMENT) {
return JavaSource.forFileObject(treePathHandle.getFileObject());
}
ClasspathInfo cpInfo = getClasspathInfo(refactoring);
JavaSource source = JavaSource.create(cpInfo, docTreePathHandle != null? docTreePathHandle.getTreePathHandle().getFileObject()
: treePathHandle.getFileObject());
return source;

}
throw new IllegalStateException();
return JavaSource.forFileObject(docTreePathHandle != null? docTreePathHandle.getTreePathHandle().getFileObject()
: treePathHandle.getFileObject());
Copy link
Member

Choose a reason for hiding this comment

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

i suppose this used to be an optimization to create a smaller CP for inline rename?

i tried to look through history and the switch slowly grew over time
emilianbold/netbeans-releases@0a558e4
emilianbold/netbeans-releases@f2d147e

Copy link
Contributor Author

Choose a reason for hiding this comment

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

TBH, I am not sure what was the idea. I see the label rename refactoring probably does not have tests, I'll see if there's a meaningful way to add some.

Copy link
Member

@mbien mbien left a comment

Choose a reason for hiding this comment

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

tested various rename scenarios in large projects and i wasn't able to break this PR.

since it is fixing an issue I am willing to take the risk and merge it for NB 29 - we can still add more tests later if needed.

@lahodaj
Copy link
Contributor Author

lahodaj commented Jan 21, 2026

Ok. If there are no objections, I'll merge.

Of course, if something breaks (too much) anyone should feel free to revert.

Thanks!!

@lahodaj lahodaj merged commit 46c5ee3 into apache:master Jan 22, 2026
69 of 70 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci:dev-build [ci] produce a dev-build zip artifact (7 days expiration, see link on workflow summary page) 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.

javac assertion error during method rename

2 participants