You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
abstract class A {
private void foo() {
[...]
}
}
interface B {
void foo();
}
class C extends A implements B {
public void foo() {
[...]
}
}
I want to remap these classes using the following mapping set:
A.foo()V -> A.methodA()V
B.foo()V -> B.methodB()V
Problem
Expected result: C.foo()V is overriding B.foo() and should therefore be remapped to C.methodB()V
Actual result: C.foo()V gets remapped to C.methodA()V even though A.foo()V is private and can't be overriden.
Note that the erronous result is also ordering dependent, so it might not occur in all situations.
Origin
The reason for this happening are the changes in commit 2a7c0b6.
The changes were made in response to issue CadixDev/Mercury#14.
The argument made in the code comments doesn't make sense to me:
Check if there are any methods here that override the return type of a parent method.
While the issue in Mercury is correct in saying that
Java allows overriding methods with different return types, if the type is a subclass of the OG return type.
, the same is not applicable to the JVM, as the spec says:
An instance method mC can override another instance method mA iff all of the following are true:
mC has the same name and descriptor as mA.
[...]
Suggested Solution
The minimum fix would be to add accessibility checks to the erronous code, preventing it from inheriting a name from a private method. However, keep in mind that the JVM requires strictly identical method descriptors, so this solution could still cause issues (A method String foo()can not override the method Object foo() in the JVM, and inferring the names that way is still erronous).
My preferred fix would be to revert the referenced commit in Lorenz and instead fix the issue in a tool specifically made for source remapping if possible (e.g. Mercury).
If separating asm remapping from source remapping is too difficult, maybe there could be a flag of some sort to change that behaviour.
The text was updated successfully, but these errors were encountered:
Context
I have three classes:
I want to remap these classes using the following mapping set:
Problem
Expected result:
C.foo()V
is overridingB.foo()
and should therefore be remapped toC.methodB()V
Actual result:
C.foo()V
gets remapped toC.methodA()V
even thoughA.foo()V
is private and can't be overriden.Note that the erronous result is also ordering dependent, so it might not occur in all situations.
Origin
The reason for this happening are the changes in commit 2a7c0b6.
The changes were made in response to issue CadixDev/Mercury#14.
The argument made in the code comments doesn't make sense to me:
While the issue in Mercury is correct in saying that
, the same is not applicable to the JVM, as the spec says:
Suggested Solution
The minimum fix would be to add accessibility checks to the erronous code, preventing it from inheriting a name from a private method. However, keep in mind that the JVM requires strictly identical method descriptors, so this solution could still cause issues (A method
String foo()
can not override the methodObject foo()
in the JVM, and inferring the names that way is still erronous).My preferred fix would be to revert the referenced commit in Lorenz and instead fix the issue in a tool specifically made for source remapping if possible (e.g. Mercury).
If separating asm remapping from source remapping is too difficult, maybe there could be a flag of some sort to change that behaviour.
The text was updated successfully, but these errors were encountered: