Don't drop Record attribute for records with no components

[Gegy]

Although they are not strictly required by the JVM specification, Record attributes are usually preserved by Proguard. When determining which attributes are used, NonEmptyAttributeFilter is chained with AttributeUsageMarker in order to mark all non-empty attributes as used. This includes Record attributes: however, they are additionally filtered based on the number of components of the record. This means that any record with no components will not have its Record attribute marked as used, and it will be dropped.

This is a fairly low-impact issue; it seems inconsistent and unexpected, though I can see that it may also be intentional.

Related issue: MC-264564.

Thanks!

[rubenpieters]

Hi @Gegy , thanks for sharing this related issue. We haven't heard of any similar reports like this. Can you provide a scenario or show an example of a case where it is problematic that these empty Record attributes are dropped?
You mention in the linked issue that it is needed for both the JDK's libraries and modding utilities , can you show an example of what you are trying to do and how it is resulting in issues?

[Gegy]

Hi! This primarily affects modding toolchains, particularly where these toolchains are built around applying patches to decompiled source and recompiling from that patched source. A non-record class that extends the Record type is not valid, and the generated indy instructions are generally not handled very well by decompilers without the attribute.

This is of course however an issue that can be resolved rather trivially in modding toolchains (e.g. this PR which adds the attribute back based on the superclass) - so I can see that this might not be considered an issue worth addressing here. (I don't imagine making decompilers happy to be a goal of Proguard 😄) It mostly seems inconsistent, as these record attributes are generally not strictly required anyway.

I have also set up a simple example repository demonstrating this case:

public record EmptyRecord() {
}

public record NormalRecord(String foo) {
}

After obfuscation, these decompile with FernFlower to:

// Missing Record attribute, decompiles as a normal class that extends Record
public final class a extends Record {
    public a() {
    }

    public final String toString() {
        return this.toString<invokedynamic>(this);
    }

    public final int hashCode() {
        return this.hashCode<invokedynamic>(this);
    }

    public final boolean equals(Object o) {
        return this.equals<invokedynamic>(this, o);
    }
}

// Record attribute is preserved with 1 or more components
public record b(String a) {
    public b(String foo) {
        this.a = foo;
    }

    public String a() {
        return this.a;
    }
}

[rubenpieters]

Thanks for the explanation.

It mostly seems inconsistent, as these record attributes are generally not strictly required anyway.

Indeed. Note that if you disable the dontshrink and -keepattributes '*' options that you have enabled in your config, then all Record attributes are removed from the class files in a consistent manner, which is the default behavior for ProGuard.
Given this, it does make sense that empty record attributes are kept if these attributes are requested to be kept. Since an empty record attribute still indicates different information than no record attribute at all.