[mbien]

first commit as preparation:

• Add TreeMaker.Record and record support to pretty printer and diff engine
• this might unlock more fixes now, e.g. thinking on the code generator for class files when src is not available

second commit:

• Add Class To Record and Record To Class hints
• both hints are kept minimal. They don't check field usage or things like that
• class -> record is a global hint by default, record -> class is current-line only

Assisted-by: qwen3.8-27b

fixes #7762

[jtulach]

• I am glad to see this "backwards conversion"
• often I start with record and then need to "open up"
• this kind of conversion will be useful

[mbien]

there is a chance that java will have compact constructors for regular classes too one day. Transition would be more fluent then.

[jtulach]

Record is more, I guess:

• there is a special java.io.Serializable support (usually I don't care)
  • who needs Java serialization these days? Maybe Enso ;-?
  • moreover it is probably quite complicated to implement
• there is special handling of equals and hashCode (I guess I do care often)
• there is default toString() implementation (useful I

Shall the conversion add compatible equals, hashCode and toString implementations?

[mbien]

It certainly is part of the convenience of a record to have good automated impls for hash/identity/tostring. I thought about removing those in the class -> record direction at the very least. But this might be overreach if the class has well thought out methods of that kind already. The other direction could call the pre-existing generator actions.. but dev can do that too in a second pass so nothing is really lost.

This is already 1.4k lines for the minimal impl, smarter solutions often get complex quick. Maybe it is better to use this a release or two first before doing a followup. (when something is too-smart, it can also lead to bad UX since it becomes unpredictable. e.g "why did it not remove the toString here when it removed it over there").

[mbien]

i actually thought about a second entry point for the action. "force record conversion". That one would lead to error badges in many cases. E.g remove default constructors, boilerplate methods and things like that.

[lahodaj]

First, thank you for looking into this!

Regarding the class -> record conversion, unless I misread the code, it will convert classes with mutable fields, but it won't convert classes that have any explicit constructor. To me, personally, it feels like a class that is conceptually very far from a record: it basically relies on being constructed "empty" and then the fields are set later. Which cannot be done with records. E.g., I didn't try, but I think the code will convert this:

class Mutable {
     private int i;
     public int getI() { return i; }
     public void setI() { this.i = i; }
}

to me, this class is very unsuitable to become a record.

OTOH, for classes that would be very suitable to become records, like:

class RecordLike {
    private final int i;
    public RecordLike(int i) {
        this.i = i;
    }
    public int i() {
        return i;
    }
    //possibly equals, hashCode, toString
}

will not be converted, as they have the constructor and accessor (despite neither the constructor, nor the accessor do anything funny).

Do I miss something?

For the record->class conversion, I think I would second to Jaroslav's sentiment around equals/hashCode/toString - those methods are part of the backbone of records. I think doing the conversion and ignore those is not ideal.

(I think I am mostly fine with ignoring the serialization aspect - in the worst case, denying the conversion or warning the user serialization may change for serializable records. I hope truly (binary) serializable records are/will be rare, and we can't detect other kinds of "serialization" anyway.)

[mbien]

i can do this but this, in fact i already did start with it but stopped since this would end up being a lot more code. Probably 2x for the hint. But I agree it should be able to convert the snippet above.

[mbien]

• performance pass: remembered to avoid TreePath.getPath() Fix performance scaling problem in JS-embedder annotation scanner #8423
• added checkbox to the hint options (default off): it will remove hash/string/equals on conversion when checked (useful but risky)
• it can now convert more record-like classes, like the example posted by @lahodaj

(rebased, changes are in tmp third commit - since i want to test this all in one with git and osgi changes)