It appears a certain tool is changing the visibility of record fields from private to package-private if the record is a nested class and the field is accessed from an enclosing or other nested class. I assume the source code looked similar to this:
class RecordTest {
public static void main(R r) {
System.out.println(r.value);
}
record R(String value) {
}
}
The class file for R has the backing field value with package-private visibility.
Unfortunately I have not found out which tool is causing this (any hints appreciated), because javac uses nest mates and even the .class file with changed field visibility still has nest mate information. It appears ProGuard was used for this class file, but when I tried to use ProGuard, it did not modify the field visibility.
Feature description
Relax the instance field requirements imposed by CFR's RecordRewriter, maybe as opt-in feature controlled by an option. Maybe there would also be other situations where such an option to in general relax the strict requirements imposed by CFR would be useful, because there have also been cases where CFR has been too strict. When the user knows that the decompiled JAR file has not been maliciously modified (to deceive decompilers), then such relaxed handling might be acceptable.
Considerations
Adding a command line option just for this specific situation might not be justified.
Problem solved by this feature
It appears a certain tool is changing the visibility of record fields from private to package-private if the record is a nested class and the field is accessed from an enclosing or other nested class. I assume the source code looked similar to this:
The class file for
R
has the backing fieldvalue
with package-private visibility.Unfortunately I have not found out which tool is causing this (any hints appreciated), because
javac
uses nest mates and even the.class
file with changed field visibility still has nest mate information. It appears ProGuard was used for this class file, but when I tried to use ProGuard, it did not modify the field visibility.Feature description
Relax the instance field requirements imposed by CFR's
RecordRewriter
, maybe as opt-in feature controlled by an option. Maybe there would also be other situations where such an option to in general relax the strict requirements imposed by CFR would be useful, because there have also been cases where CFR has been too strict. When the user knows that the decompiled JAR file has not been maliciously modified (to deceive decompilers), then such relaxed handling might be acceptable.Considerations
Adding a command line option just for this specific situation might not be justified.
Alternatives
None?