Refactor rename doesnt work with lambda subtype in different source

[enrdenti]

In Eclipse 2025-12 (Java+DSL edition), using the Refactor -> Rename command (or SHIFT+ALT+R) in a Java source file leads to an inconsistent behaviour: instead of applying the required rename, the older name is maintained after hitting ENTER, as if something failed behind the scenes. This is quite a problem, since renaming something is one of the most common refactoring actions.

Sometimes, applying the same command from another file works: I noticed that trying to do the rename in the class where the method is defined leads the command to fail, but doing the same from another class, where the method is used, tends to work.

This bug does not exist in Eclipse 2025-09, so this is a regression issue.

[trancexpress]

Please provide a minimal reproducer.

I downloaded: https://www.eclipse.org/downloads/packages/release/2025-12/r/eclipse-ide-java-and-dsl-developers

Eclipse DSL Tools (includes Incubating components)
Version: 2025-12 (4.38.0)
Build id: 20251204-0850

Created a new Java project in a new workspace and did a refactor rename in a minimal snippet. No issue.

[enrdenti]

Hello, in order to reproduce the issue, a specific situation needs to be set up.

1. First, other than the standard 'src' source folder, another 'test' source folder should be defined, where test cases will be put.

2. For each package in the source folder, a corresponding test package is defined in the 'test' source folder: the naming convention is that for source package "a.b.c", the corresponding test package be named 'a.b.c.test' - see attached image

3. Then, if you try to rename a method in a class, say the Campo class, sometimes it works, sometimes it doesn't, depending on the method you want to rename: for instance, renaming cella() in "casella()" and vice-versa tends not to work (but sometimes it does, especially if you rename something else in between), while renaming other methods mostly work.
   I also tried removing the corresponding CampoTest class from the test folder and, surprise!, that seems to fix the issue, at least at a first glance. Another way to partially fix the issues seems is reducing the class complexity, removing some methods from the class - but obviously, this is a nonsense. So, the feeling is that the renaming command gets confused by something, in some situations, that make it fail underneath.

Needless to say, in Eclipse 2025-09 everything works fine in each situation. Does this help?

[trancexpress]

Can you attach the project itself? In Eclipse, right-click on the project from the Package Explorer -> Export -> General -> Archive File, make sure to include everything, attach the export.

Also, do you see anything in the error log? Ctrl+3 -> Error Log -> Export Log (from the view menu toolbar, top right of the view), attach the exported file.

[enrdenti]

Here is the log. Just tried a rename using the full project (not the smaller one whose image I attached above), same issue.
exportlog.txt.

I cannot attach it here in public due to confidentiality reasons, but I can share it privately via PM -- just tell me how

[trancexpress]

Seems like JDT doesn't like the contents of CampoTest...

!ENTRY org.eclipse.jdt.ui 4 10001 2025-12-21 17:09:30.427
!MESSAGE Internal Error
!STACK 0
java.lang.reflect.InvocationTargetException
	at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:112)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:123)
Caused by: Java Model Exception: Error in Java Model (code 969): <anonymous eclipse-jdt/eclipse.jdt.ui#1> {key=Lcampominato/model/test/CampoTest$7089;} [in execute() [in <lambda eclipse-jdt/eclipse.jdt.ui#1> [in testKO_ctor() [in CampoTest [in CampoTest.java [in campominato.model.test [in test [in 2026-01-14-PROVA]]]]]]]] does not exist
	at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:812)
	at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:860)
	at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:811)
	at org.eclipse.jdt.internal.corext.refactoring.rename.MethodChecks.isDeclaredInInterface(MethodChecks.java:116)
	at org.eclipse.jdt.internal.corext.refactoring.rename.MethodChecks.getTopmostMethod(MethodChecks.java:160)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RenameVirtualMethodProcessor.checkInitialConditions(RenameVirtualMethodProcessor.java:131)
	at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkInitialConditions(ProcessorBasedRefactoring.java:210)
	at org.eclipse.ltk.core.refactoring.Refactoring.checkAllConditions(Refactoring.java:161)
	at org.eclipse.jdt.internal.ui.refactoring.RefactoringExecutionHelper$Operation.run(RefactoringExecutionHelper.java:84)
	at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:41)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:751)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2505)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2533)
	at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:6142)
	at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:108)
	... 1 more
Root exception:
Java Model Exception: Error in Java Model (code 969): <anonymous eclipse-jdt/eclipse.jdt.ui#1> {key=Lcampominato/model/test/CampoTest$7089;} [in execute() [in <lambda eclipse-jdt/eclipse.jdt.ui#1> [in testKO_ctor() [in CampoTest [in CampoTest.java [in campominato.model.test [in test [in 2026-01-14-PROVA]]]]]]]] does not exist
	at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:812)
	at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:860)
	at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:811)
	at org.eclipse.jdt.internal.corext.refactoring.rename.MethodChecks.isDeclaredInInterface(MethodChecks.java:116)
	at org.eclipse.jdt.internal.corext.refactoring.rename.MethodChecks.getTopmostMethod(MethodChecks.java:160)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RenameVirtualMethodProcessor.checkInitialConditions(RenameVirtualMethodProcessor.java:131)
	at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkInitialConditions(ProcessorBasedRefactoring.java:210)
	at org.eclipse.ltk.core.refactoring.Refactoring.checkAllConditions(Refactoring.java:161)
	at org.eclipse.jdt.internal.ui.refactoring.RefactoringExecutionHelper$Operation.run(RefactoringExecutionHelper.java:84)
	at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:41)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:751)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2505)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2533)
	at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:6142)
	at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:108)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:123)

CampoTest$7089 probably means a lot of inner classes... Is this class big?

I cannot attach it here in public due to confidentiality reasons, but I can share it privately via PM -- just tell me how

Best to not share anything confidential at all. Are the contents of the project from your screenshot also confidential? The screenshot in this comment: #4704 (comment)

If so, is it possible to strip the confidential parts? In particular, it might be enough to just have testKO_ctor()... I'm not sure.

One thing you could try is, from the main menu: Window -> Preferences -> Java -> Rebuild Index (under Search group)

Also clean building the workspace, just in case.

[enrdenti]

Are the contents of the project from your screenshot also confidential?

No, that dummy project was specifically made for this image, any confidential aspects were stripped off

CampoTest has one peculiarity in fact, i.e. it is the only one using a sort of anonymous class built on the fly for testing purposes, because Campo is abstract and therefore could not be instantiated for testing alone. But since it has actually no abstract methods, all is needed to instantiate the class is just a pair of extra braces -- please see below the code of testKO_ctor:

@Test
public void testKO_ctor() {
	assertThrows(IllegalArgumentException.class, () -> new Campo<Integer>(1, 3) {});
	assertThrows(IllegalArgumentException.class, () -> new Campo<Integer>(0, 3) {});
	assertThrows(IllegalArgumentException.class, () -> new Campo<Integer>(-1, 3) {});
}

I wondered whether this syntax might have confused the renaming code, but also removing the braces (and declaring Campo not abstract, of course), nothing changes.

One thing you could try is, from the main menu: Window -> Preferences -> Java -> Rebuild Index (under Search group)

Tried, but no effect.

Also clean building the workspace, just in case.

The project has been duplicated and reloaded on a fresh workspace, but again, no effect.

[trancexpress]

No, that dummy project was specifically made for this image, any confidential aspects were stripped off

Would be great if you can attach it, or did I miss it somewhere?

[trancexpress]

Example.zip

Refactor rename myproject.model.Campo.cella() into casella.

OK, I was able to reproduce with this and:

Eclipse DSL Tools (includes Incubating components)
Version: 2025-12 (4.38.0)
Build id: 20251204-0850

Seems like the problem is gone after I open the source with testKO_ctor() (I put the test method in myproject.model.test.CoordinateTest, I wasn't paying attention). Which is why I thought refactoring worked for me with 4.39 / latest master.

If I only import the example project from the archive and open Campo, then try to refactor rename, the exception above is seen and the refactor rename doesn't work. Oddly it also doesn't work after closing the Java editor with the test source...

I went as far as back as Eclipse 4.27 (2023) and I can reproduce the bug, at least with the attached reproducer: https://github.com/user-attachments/files/24280505/Example.zip

Eclipse SDK
Version: 2023-03 (4.27)
Build id: I20230302-0300

I reproduced the problem also in:

Eclipse DSL Tools (includes Incubating components)
Version: 2025-09 (4.37.0)
Build id: 20250905-1456

@enrdenti are you sure you don't see this also with Eclipse Java & DSL 2025-09?

[trancexpress]

Thank you for the report!

Reduced to:

package test;

public abstract class A<T> {

	public A(T a1, T a2) {}

	public void m() {}
}

package test;

public class B {

	public void t() {
		f(Exception.class, () -> new A<Integer>(1, 3) {});
		f(Exception.class, () -> new A<Integer>(0, 3) {});
		f(Exception.class, () -> new A<Integer>(-1, 3) {});
	}

	private static void f(Class<?> clazz, Runnable r) {

	}
}

A.m() cannot be refactor renamed unless B is also open in a Java editor.

See screen recording:

GH4704.mp4

Probably makes sense to start with adding a test...