Enable @Getter on a Java record

[mjaggard]

No description provided.

[mjaggard]

@rspilker @rzwitserloot

This fixes a common complaint in my team that @Getter doesn't work on a Java Record. The reason this is needed is to aid migration from an @Value class to a record because the latter creates getters without the get prefix.

[rzwitserloot]

We've been debating this. It steers dangerously close to the problem of 'suggesting' very bad programming practices. In basis, 'record'-izing an existing class that has getters is a bad idea. For starters, team OpenJDK themselves haven't done this: java.time.LocalDate remains not a record. Uglifying your API by having both a .getYear() and a .year() method, which javadoc explaining that this 2 methods are synonyms and exists only because your API was written before a new java feature, is a pretty sad state of affairs. You're yelling out clearly that you're outdated API. Painful.

There's no benefits to records. Just stay a class. The few benefits records have are either irrelevant for your scenario or can be easily added to your existing class / will soon be:

1. It's less typing. Irrelevant. You already wrote your code. And you have lombok. It's more typing to make a commit that replaces class with record, along with the other changes required.
2. I want to reap the benefits of having a deconstructable. Not an issue: You can write your own once java features roll out that really bites into what you can do when deconstructors are a thing.
3. No, I want it now - such as the switch-on-pattern feature: Just hold your horses, that deconstructor thing should soon come. And if not, [A] OpenJDK is making their own API look really bad (such as java.time.LocalDate), and [B] the correct remedy is to yell at the OpenJDK team to get their shit together, not to make a drastic and unfixable-without-breaking-backwards-compatibility hasty choice in 'adopting' a record where you probably should not.

Even if you disagree with all that (and you very well might, and that is of course fine!), it's not about your specific situation, it's more generally about the idea that lombok supporting @Getter on records has no point whatsoever other than to enable you to do what you are doing. We hold the opinion that if lombok releases a feature whose most obvious / only point is X, that this implies that lombok tacitly supports / suggests X is a good idea.

And this aint. Which is why we're still debating it and are likely to deny this PR.

[mjaggard]

Thanks for the reply and very logical point. I guess my only push back, and I know this is minor, is that it's surprising that it doesn't work - and surprise is something I do my best to avoid.

[Zubnix]

We've been debating this. It steers dangerously close to the problem of 'suggesting' very bad programming practices. In basis, 'record'-izing an existing class that has getters is a bad idea. For starters, team OpenJDK themselves haven't done this: java.time.LocalDate remains not a record. Uglifying your API by having both a .getYear() and a .year() method, which javadoc explaining that this 2 methods are synonyms and exists only because your API was written before a new java feature, is a pretty sad state of affairs. You're yelling out clearly that you're outdated API. Painful.

There's no benefits to records. Just stay a class. The few benefits records have are either irrelevant for your scenario or can be easily added to your existing class / will soon be:

1. It's less typing. Irrelevant. You already wrote your code. And you have lombok. It's more typing to make a commit that replaces class with record, along with the other changes required.
2. I want to reap the benefits of having a deconstructable. Not an issue: You can write your own once java features roll out that really bites into what you can do when deconstructors are a thing.
3. No, I want it now - such as the switch-on-pattern feature: Just hold your horses, that deconstructor thing should soon come. And if not, [A] OpenJDK is making their own API look really bad (such as java.time.LocalDate), and [B] the correct remedy is to yell at the OpenJDK team to get their shit together, not to make a drastic and unfixable-without-breaking-backwards-compatibility hasty choice in 'adopting' a record where you probably should not.

Even if you disagree with all that (and you very well might, and that is of course fine!), it's not about your specific situation, it's more generally about the idea that lombok supporting @Getter on records has no point whatsoever other than to enable you to do what you are doing. We hold the opinion that if lombok releases a feature whose most obvious / only point is X, that this implies that lombok tacitly supports / suggests X is a good idea.

And this aint. Which is why we're still debating it and are likely to deny this PR.

I agree with you but could you also convince the authors of JSF to drop the need for it? Or alternative be so kind to make legacy codebase maintainers of a multi million dollar codebase life a little less hellish and support @Getter on Java 17 records? ;)

[nealeu]

I see benefits, especially for libraries and large projects.

There's no benefits to records. Just stay a class. The few benefits records have are either irrelevant for your scenario or can be easily added to your existing class / will soon be:

4. @Getter would be the least effort way to allow a large codebase to localise the change rather than propagating getX() -> x() across an entire codebase. This sort of change would be far saner done across multiple iterations to avoid merge conflicts etc.
5. getX() may be on a public API - for which @Getter(deprecated=true) would be even more useful so that @Deprecated is added to the generated code. Users consuming the API then get to pattern switch etc, but without breaking API.
6. @Data generates class files that are double the size of the equivalent record. This makes a sane delombok to record quite beneficial, and I suspect has some performance benefits too, esp in the area of equals and hashCode around JIT, and would reduce the JIT code cache too.

Even if you disagree with all that (and you very well might, and that is of course fine!), it's not about your specific situation, it's more generally about the idea that lombok supporting @Getter on records has no point whatsoever other than to enable you to do what you are doing. We hold the opinion that if lombok releases a feature whose most obvious / only point is X, that this implies that lombok tacitly supports / suggests X is a good idea.

And this aint. Which is why we're still debating it and are likely to deny this PR.

So perhaps the answer is the same feature but without polluting @Getter as something in lombok.experimental.