Move members broken

[aldobrucale]

Apache NetBeans version

Apache NetBeans 15

What happened

The "Move Members" refactoring is broken since a few versions. The "To Class" field is not being populated, so it is impossible to move members.

How to reproduce

In a Java project with at least two classes, select a method and hit ctrl+m. The "To Class" item is empty.

Did this work correctly in an earlier version?

Apache NetBeans 13

Operating System

Ubuntu 22.04.1

JDK

OpenJDK Runtime Environment Temurin-17.0.4.1+1 (build 17.0.4.1+1)

Apache NetBeans packaging

Apache NetBeans Snap Package

Anything else

No response

Are you willing to submit a pull request?

Yes

Code of Conduct

Yes

[ebarboni]

Hi, do you have exception in the log ?

[mbien]

can reproduce with NB 15. Haven't tested on master which has a newer javac from JDK 19 in it.

java.lang.AssertionError
	at com.sun.tools.javac.util.Assert.error(Assert.java:155)
	at com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
	at com.sun.tools.javac.comp.Modules.allModules(Modules.java:1216)
	at com.sun.tools.javac.model.JavacElements.getAllModuleElements(JavacElements.java:127)
	at org.netbeans.modules.java.source.ElementUtils.getTypeElementByBinaryName(ElementUtils.java:49)
	at org.netbeans.api.java.source.ElementHandle.getTypeElementByBinaryName(ElementHandle.java:663)
	at org.netbeans.api.java.source.ElementHandle.resolveImpl(ElementHandle.java:162)
	at org.netbeans.api.java.source.ElementHandle.resolve(ElementHandle.java:131)
	at org.netbeans.modules.refactoring.java.ui.MoveMembersPanel$4$2.run(MoveMembersPanel.java:316)
	at org.netbeans.modules.refactoring.java.ui.MoveMembersPanel$4$2.run(MoveMembersPanel.java:304)
	at org.netbeans.modules.java.source.parsing.MimeTask.run(MimeTask.java:60)
	at org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
	at org.netbeans.modules.parsing.api.ParserManager$MimeTaskAction.run(ParserManager.java:364)
	at org.netbeans.modules.parsing.api.ParserManager$MimeTaskAction.run(ParserManager.java:347)
	at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
	at org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
	at org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
	at org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
	at org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
	at org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
	at org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
	at org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:318)
	at org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:433)
	at org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:425)
	at org.netbeans.modules.refactoring.java.ui.MoveMembersPanel$4.run(MoveMembersPanel.java:304)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
	at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)

[aldobrucale]

I don't see any exception in the log in corrispondence of the attempt to move methods

[neilcsmith-net]

Marking this high priority. Be good to see fixed by NB16 release.

[mbien]

I'll take a look if I can fix this.

[neilcsmith-net]

@mbien sorry, should have assigned myself. Just opening a PR now.

[mbien]

@mbien sorry, should have assigned myself. Just opening a PR now.

do worries. I just started looking into it while walking through the stack backwards and the code looked all correct so far.

[neilcsmith-net]

Same here. Code in javac fails because Modules not initialised, so now making sure it is. Seems to be build system specific though (possibly to do with classpath) - works fine with NetBeans' own sources. :shrug:

[mbien]

I am wondering if the NB utilities like ElementHandle should/could check the phase (compilationInfo.getPhase()) so that they can throw better exceptions in future. But I lack the experience of all the edge cases, maybe sometimes a different phase is ok.

[neilcsmith-net]

I wondered that too, or even moving to the required state in there if necessary, possibly logging an error, but working. Phase.PARSED seemed to be enough to fix this issue, but other code across that module has Phase.RESOLVED so used that. Keeping it localised for NB16 anyway.

[neilcsmith-net]

@aldobrucale thanks for the report. This should be fixed in 16-rc3, which should be available next week. Please check once it's available and comment here if you still see an issue.