Immutables were introduced in this library when Java Records were not available or popular. Most of the GH models in the library can be converted to use Records.

Advantages

• Conciseness: Records reduce boilerplate code significantly. They automatically generate constructors, accessors, equals(), hashCode(), and toString() methods, making the code more concise and readable. Additionally, no more Builder classes to worry about.
• Built-in Immutability: Records are inherently immutable, ensuring that once an instance is created, its state cannot be changed. This aligns with the immutability provided by libraries like Immutables.
• Standardization: Records are a standard feature of the Java language (introduced in Java 14 as a preview and standardized in Java 16), meaning they are supported natively by the Java compiler and runtime. This can lead to better performance and integration compared to third-party libraries.
• Maintenance: Using records reduces dependency on external libraries (immutables here), simplifying project maintenance and reducing potential issues with library updates, compatibility, or security vulnerabilities.

Disadvantages

• Breaking change - This is going to introduce a breaking change, as these immutable classes/models are part of the public API of this library and will break a lot of integration. Hence it should be considered whenever we decide to introduce a major breaking change.
• Unavailability in older Java versions - Older Java versions like Java 11 will not be supported once we decide to use Records. TBH we should have dropped support for it much earlier.

Please share your opinion on whether this is a good move or not.