Inline Method changes behavior for polymorphic method call

[EngTes1]

Description

When using Inline Method on a method that is overridden in a subclass, VS Code Java performs the refactoring successfully, but the refactored program changes its runtime behavior.

The original program relies on dynamic dispatch. After inlining the superclass method body, the polymorphic method call is replaced with a fixed value, which breaks the original behavior.

Steps to reproduce

1. Create the following Java code.
2. Place the caret on method f in class A.
3. Invoke Refactor -> Inline Method.
4. Apply the inline refactoring.
5. Run the program before and after refactoring.

Original code

package org.example;

public class Main {
    public static void main(String[] args) {
        A a1 = new A();
        A a2 = new B();

        a1.test();
        a2.test();
    }
}

class A {

    int f() {
        return 1;
    }

    void test() {
        int x = f(); // Inline target
        System.out.println(x);
    }
}

class B extends A {
    @Override
    int f() {
        return 2;
    }
}

Actual behavior

VS Code Java performs the inline refactoring. The refactored program still compiles, but its runtime behavior changes.

Original output:

1
2

Refactored output:

1
1

Refactored code generated by VS Code Java:

package org.example;

public class Main {
    public static void main(String[] args) {
        A a1 = new A();
        A a2 = new B();

        a1.test();
        a2.test();
    }
}

class A {

    void test() {
        int x = 1;
        System.out.println(x);
    }
}

class B extends A {
    @Override
    int f() {
        return 2;
    }
}

The inline refactoring replaces the polymorphic method call f() with the body of A.f(). However, the call inside A.test() is dynamically dispatched at runtime. When test() is invoked on an instance of B, the original program calls B.f() and prints 2.

After refactoring, this dynamic dispatch is removed, so both calls print 1.

Expected behavior

Inline Method should preserve the runtime behavior of the original program.

The refactoring should either:

1. reject the inline operation, or
2. report a warning/error indicating that inlining this method may change behavior because the method is overridden and the call is dynamically dispatched.

It should not silently generate behavior-changing code.

[chagong]

Thanks for the clear repro. I looked into the JDT LS inline-method path, and the behavior appears to come from how InlineMethodRefactoring condition results are handled when JDT LS turns the refactoring into a code action edit.

JDT LS offers Inline Method by creating an Eclipse JDT InlineMethodRefactoring here:

• RefactorProcessor.java#L477-L497

The underlying JDT refactoring already has logic to detect this class of problem. During final condition checking, InlineMethodRefactoring calls checkOverridden(...), walks the type hierarchy, and reports an error when the method to inline is overridden, overrides another method, or implements an interface method:

• InlineMethodRefactoring.java#L268-L343
• InlineMethodRefactoring.java#L423-L456
• The related messages are defined in refactoring.properties#L244-L250.

So the issue is not that JDT cannot recognize the polymorphic hazard. It can. The problem is that JDT LS can still produce a workspace edit while those non-fatal refactoring status entries are not surfaced to the user. In RefactorProcessor, the change is created with RefactoringStatus.FATAL as the failure threshold, so a RefactoringStatus.ERROR such as "Type B overrides method to be inlined" may not prevent a change from being created:

• RefactorProcessor.java#L486-L493

From a refactoring UX perspective, silently applying this edit is risky because Inline Method is expected to preserve behavior. In this example, replacing f() inside A.test() removes a virtual dispatch point. Before inlining, a2.test() dispatches f() to B.f() at runtime. After inlining A.f() directly, that dispatch no longer exists, so behavior changes.

A potential fix would be:

1. JDT LS should not silently ignore InlineMethodRefactoring condition errors when creating the inline-method edit.
2. For Inline Method, JDT LS should likely treat RefactoringStatus.ERROR as blocking, at least for the overridden/overriding/implements cases reported by InlineMethodRefactoring.checkOverridden(...).
3. Add a regression test for single-call inline where a superclass method call is dynamically dispatched to an override in a subclass. The expected behavior should be either no Inline Method edit/action, or an explicit failure explaining that inlining may change behavior because the method participates in dynamic dispatch.
4. Longer term, the safest fix may also be in org.eclipse.jdt.core.manipulation: single-call inline should not create a behavior-changing edit after detecting overridden methods. JDT LS should still guard this path because the code-action flow does not provide Eclipse IDE refactoring wizard UX for reviewing such status entries before applying the edit.