Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wish: makeFinal parameter for Getter/Setter annotations #1456

Closed
o-pikozh opened this issue Aug 14, 2017 · 38 comments
Closed

Wish: makeFinal parameter for Getter/Setter annotations #1456

o-pikozh opened this issue Aug 14, 2017 · 38 comments
Milestone

Comments

@o-pikozh
Copy link

o-pikozh commented Aug 14, 2017

Add boolean makeFinal() default false to Getter and Setter.

Though it's already discussed here (discusstion start is here) and will, probably, be "won't fix" anyway — but I consider it useful in some rare cases when getter and/or setter is needed to be explicitly final (not for marking most of getters/setters as final).

As I haven't found this wish in this issue-tracker, I took the liberty to repost it here (at least: to group all requests in one place) — please, feel free to close it immediately, if it's still a no-way.

@grimly
Copy link

grimly commented Aug 23, 2017

What would be the added value to final getters/setters over public members ?

@Maaartinus
Copy link
Contributor

@grimly The obvious ones: 1. They (can't be overridden but they) still can override a method. 2. They are methods (my rule is: no non-private non-constant fields).

@o-pikozh
Copy link
Author

@grimly, do you mean: over the public fields?

Well:

  1. Consistent (unbroken) API.

    Right now you have properties getX/setX and getY/setY backed directly into the fields x and y. Then you add calculated getPhi/setPhi and getRho/setRho properties. Then you decide that it's better to store getPhi/setPhi and getRho/setRho as phi and rho fields, with making getX/setX and getY/setY calculated instead.

  2. Don't forget that nobody forces you to use both lombok.Getter and lombok.Setter at once. You can use trivial (lombok-generated) getter with more complex setter (e.g. this.value = value; repaint()). Or a trivial (lombok-generated) getter with more complex getter (e.g. return this.value != null ? this.value : parent.value). Or only trivial getter with no setter; or trivial getter with other ways to set (like T getValue() + void setValue(T value, String changeReason)).

@grimly
Copy link

grimly commented Aug 23, 2017

I think you misunderstood my comment. I asked what would be the added value from final getter and setter over a public field (as I wrote member, my bad).

If you mark your getter and setter final and they are as the dummy ones, they are no differents to public fields

I personally forbid myself the use of final modifier from the countless errors I encountered with container environments (jee, spring), and overriding might be useful at times, so I can't see the use of it but since the discussion is open I want to know what would be your use of it.

@o-pikozh
Copy link
Author

o-pikozh commented Aug 23, 2017

@grimly:

I asked what would be the added value from final getter and setter over a public field (as I wrote member, my bad).

I answered exactly that question. Do I write clear enough in 1 and 2 — or should I describe in more details?

@grimly
Copy link

grimly commented Aug 23, 2017

Hmmmm. Fine to me. I thought there was more.
We have not the same problems or solutions in mind to solve them.
I see locked APIs as an issue since you may not extend them.

Nevertheless , to be able to generate final getters and setters do not alter current usages of lombok. If the cost is low, what do we lose ?

@o-pikozh
Copy link
Author

o-pikozh commented Aug 23, 2017

I see locked APIs as an issue since you may not extend them.

Locked only for incompatible changes. E.g. you can add new method, but not turn method into field or field into method.

Nevertheless , to be able to generate final getters and setters do not alter current usages of lombok. If the cost is low, what do we lose ?

Sorry, I haven't got the question. What do we lose from what?

@simakmi
Copy link

simakmi commented Oct 11, 2017

makeFinal will be a useful attribute, because sometimes I need to create final getter/setter to exclude overriding.

@andrebrait
Copy link
Contributor

andrebrait commented May 7, 2018

I stumbled upon this one myself today. Had to refactor a non-Lombok project to use Lombok but it has simple getter/setter which are final.

I can try and implement this myself if I can get some agreement that it would be useful/doable. I've browsed the source code for Lombok and I believe adding a boolean makeFinal() default false; to the Getterand Setterclasses plus handling the method generation in the Getter and Setter handlers should suffice (for both javac and eclipse compilers). Am I correct? Are there any complications I'm not aware of?

@fsilkswan
Copy link

No plans on supporting creating final getters/setters by Lombok?

@rspilker
Copy link
Collaborator

rspilker commented Oct 1, 2019

Can someone please explain why having a final getX() is better than just getX() ?

I'm looking for an actual use-case, not a "because I want to have sub-classes, but they are not allowed to override my getter/setter."

@rspilker rspilker added the parked Without further feedback this bug cannot be processed. If no feedback is provided, we close these. label Oct 1, 2019
@o-pikozh
Copy link
Author

o-pikozh commented Oct 2, 2019

I'm looking for an actual use-case, not a "because I want to have sub-classes, but they are not allowed to override my getter/setter."

@rspilker, sorry, maybe I ask something stupid, but why don't you consider "I want to have sub-classes, but they are not allowed to override my getter/setter" to be an actual use case? (What do you mean by actual use case then?)

@rspilker
Copy link
Collaborator

rspilker commented Oct 3, 2019

Can you describe a common, real world (non-hypothetical) scenario where the class in not final, but the getters and setter must be final, and that that's the best solution for the problem.

In my experience, lots of code bases are favoring composition over inheritance. Most data classes don't have sub-classes. And if they do, there is no requirement that the getters/setters need to be final. I mean, that invariants are fundamentally broken.

One could always argue that it help reasoning about the code in case you want to execute a refactoring. But that alone is not good enough to add additional parameters and complications to @Getter and @Setter.

We're really interested. Maybe there is a good reason we don't know about. But so far, we haven't heard compelling arguments. The best argument so far was "It speeds up introducing Lombok in legacy code bases". And, although compelling, that alone not good enough.

@o-pikozh
Copy link
Author

o-pikozh commented Oct 3, 2019

@rspilker, for me "I want to have sub-classes, but they are not allowed to override my getter/setter" is a real-world every-day (every day when I use Java) scenario.

In my experience, lots of code bases are favoring composition over inheritance.

Exactly. That's why I tend to have things final by default. Usually I make the whole class final (therefore making all members implicitly final).

But in some cases we allow class to be inherited. In that cases usually specific methods are allowed to be overridden but not all methods. I.e. in such classes I by default mark all methods as final and then unmark those of them that are allowed to be overridden by design.

I.e. almost every class that I allow to be inherited has at least some final methods (though for most of the classes I forbid inheritance at all). And if such (non-final) class has some trivial getter and/or setter methods, they're most certainly final — because they're usually not the part of the stuff that is by design allowed to be overridden.

Maybe it matters that I use Java not for my work but for my hobby projects. Never-the-less for me it's a usual thing: I make everything final by default and then consciously "unfinalize" some small parts. Getters and setters almost never get "unfinallized". (If I were a Lombok designer, I'd made getter and setters final by default, but I understand that now it might be too incompatible change.)

@Maaartinus
Copy link
Contributor

@o-pikozh This sounds pretty convincing. Actually, this is just like what I always do concerning visibility (everything is as much private as possible). I don't do this w.r.t. finality as I never really thought about it, but I'd love when it was the default in Java - I mean everything is final unless marked as non-final (or there's a corresponding annotation on the whole class). But that train has sailed years ago.

I'm rather sure that being restrictive is a (very) good thing, but I'm unsure if in this particular case it's good enough to warrant the effort. If there was a lombok.config option for making all etters final, I'd surely switch it on. Unfortunately, such an option requires a possibility to override it, which means an additional annotation parameter or a new annotation or alike... even more effort (implementation, maintenance and learning curve).

Disclaimer: I'm not a lombok team member.

@fsilkswan
Copy link

fsilkswan commented Oct 3, 2019

Consider abstract base classes (for e.g. database objects => my use-case) as a real-world scenario.

@janrieke
Copy link
Contributor

janrieke commented Oct 4, 2019

We also had that use case (database mapping classes for JCR). JCR also has a (very special) notion of inheritance. Thus, it becomes even more important to design the inheritance in Java well, especially as we allow plugins with customer-specific database sub-classes (i.e. code that we do not control).

Joshua Bloch also says "Design for inheritance or else prohibit it" (Effective Java). Getter and setters are a typical example where you do not want any subclass to mess around with. Imagine a subclass overriding the getter for the unique ID.

@Maaartinus
Copy link
Contributor

Agreed. Whenever possible, all methods should be either abstract or final.

I'm just moving some fields up in the hierarchy. By making the getters final, I could ensure that there'll be no leftovers.

@canemacchina
Copy link

Can someone please explain why having a final getX() is better than just getX() ?

I'm looking for an actual use-case, not a "because I want to have sub-classes, but they are not allowed to override my getter/setter."

"because I want to have sub-classes, but they are not allowed to override my getter/setter" it's an actual use-case. Just because you don't think so doesn't make it less important.

I agree that a final getter that simply returns the property seems useless. And I agree with the concept of composition over inheritance.
But this doesn't mean that inheritance is useless or should not be used.
So many times I start writing some classes and then I realize that all those classes share something that is better expressed with inheritance and not composition.
In those cases, I refactor my classes extracting a base abstract one, and at that moment I often realized that those commons behaviours must not be overridden. So I need to add the final keyword on base class methods.
And sometimes those base class methods are just simple getters... And all is good, because the important thing is that this method, regarding its complexity, it's something that subclasses should not be able to override, so I want to enforce this behaviour.

The final keyword in simple getter often appears in my value objects. Those value object often have a value and I want to be sure that value object subclasses don't return whatever they want. I want they initialize the value calling super(value), maybe adding some validation logic, but I don't want they change what the value object return as the value. So I need the final keyword in my getter method.

You can argue that I can simply declare my field public final and all works fine.
Not at all. I want to be open to change how the value is provided through the getter in my base class, so to avoid a "huge" refactor in my codebase I always use a getter method instead of letting access the raw property.

Everything would be better if Java had properties like Kotlin, and getters and setters for those properties.
But Java doesn't have class properties, so I need the final keyword in my getter

@haelix888
Copy link

Can you describe a common, real world (non-hypothetical) scenario where the class in not final, but the getters and setter must be final, and that that's the best solution for the problem.

In my experience, lots of code bases are favoring composition over inheritance. Most data classes don't have sub-classes. And if they do, there is no requirement that the getters/setters need to be final. I mean, that invariants are fundamentally broken.

One could always argue that it help reasoning about the code in case you want to execute a refactoring. But that alone is not good enough to add additional parameters and complications to @Getter and @Setter.

We're really interested. Maybe there is a good reason we don't know about. But so far, we haven't heard compelling arguments. The best argument so far was "It speeds up introducing Lombok in legacy code bases". And, although compelling, that alone not good enough.

Real use-case for you:
Mockito will mock all methods of an object if they're not final.
So I have a custom mock class which e.g. counts something and I'm incrementing a counter, I say @Getter long x; but at runtime I get org.mockito.exceptions.verification.NoInteractionsWanted, why? because the non-final getX() was mocked. I google and end up here.

@marcioggs
Copy link

This would be useful on Spring applications to autowire a field on an abstract class.
See https://www.baeldung.com/spring-autowired-abstract-class#setter-injection

@jennierose
Copy link

Why on earth is this marked as parked instead of low hanging fruit? Surely, adding a single optional parameter to @Getter and @Setter, one that's already being used in other parts of Lombok, couldn't be that complicated! Could it? Plenty of people have given actual real-world use cases for this feature request, so there's not a lot of weight in the claim that it wouldn't be useful. And honestly it's kind of silly to develop annotations for generating Java getters and setters, but arbitrarily decide not to make them feature complete with Java's method declaration syntax, just because you think that keyword isn't important enough.

@rzwitserloot
Copy link
Collaborator

Why on earth is this marked as parked instead of low hanging fruit?

We asked for a use case and so far nothing that convinced us has been stated, except for the mockito one which isn't good enough. Hence, it's not low hanging fruit.

Surely, adding a single optional parameter to @getter and @Setter, one that's already being used in other parts of Lombok, couldn't be that complicated!

It's trivial. The PR would take us, what, 2 hours?

And that mindset of yours ("just add everything that seems easy when a few folks ask for it!") means that 5 years from now, you type @Getter( and ask your IDE about what parameters there are, and you get a list of 50 parameters. Also, our test code which should optimally also test combinations of features, will consist of the combinatory explosion which has ballooned to 15 million different combinations.

We've maintained this project for 12 years. We believe that our hesitance at introducing features 'just cuz it seems easy' plaus a significant role in this.

Thus, whilst 'this is really easy to add' certainly helps, it's not, by any means, the most important consideration.

Plenty of people have given actual real-world use cases for this feature request

Where? I see the one about mockito, and a lot of abstract use cases which don't count.

And honestly it's kind of silly

And you think getting uppity with the core maintainers is going to make us go: "Oh, right, sorry about that, no problem, we'll get right on that?" You're not helping.

We need use cases.

Evidently that sentence is not obvious, I'll try to explain in a followup comment.

@rzwitserloot
Copy link
Collaborator

We need use cases. I'll bat down a bunch of stuff stated as use cases in this issue which either aren't use cases or aren't convincing.

@canemacchina wrote:

"because I want to have sub-classes, but they are not allowed to override my getter/setter" it's an actual use-case. Just because you don't think so doesn't make it less important.

No, it's not an actual use case. Nobody sets out to say: "I wish to fasten this plate to this other plate by drilling holes through both and using a screw and bolt getup". That's completely pointless. Someone sets out to build a table, and as part of making the table, they run into the issue of needing to fasten two metal plates together. We need to hear about the table. If we have no experience with tables, we may even need to hear about the concept of 'serving dinner to big groups'. We'll keep asking for more details until we can fill in the rest of the 'chain' so to speak, and the above is so close to the 'how' and so far removed from the 'why', it is completely useless. We don't use everything you use, so we may come across as a bit dense. It's partly because we very well might be (case in point: Neither roel nor I use spring or mockito, coincidentally). And partly because we want everybody to understand why a feature is adding to lombok.*. If we're adding this feature solely to satisfy, say, spring autowired, it should be in lombok.extern.spring - that's the place for features that cannot be understood without first understanding spring.

WHY do you need to make subclasses that 'cannot override the getter'? If you simply intend to prevent overriding because you're aware that in general that is not a good idea, we're right there with you. But java is what it is, the solution is not to pepper final on every method you ever write. Or at least, we do not agree with that as a solution, and the vast majority of the community is on 'our' side on this: Just open random java projects on github and you'll find very few that have marked all but a handful of methods/classes as final. The solution lies elsewhere: A java programmer is supposed to know that you can't just start overriding random bits and bobs without at least trying to understand what you're doing, and overriding a lombok-generated getter/setter is real easy to understand. Hence, I just want to make them final! is not a use-case, or if it is for you, then it holds absolutely no convincing power at all for us. Go to the next level: WHY do you want it to be final?

@marcioggs wrote:

This would be useful on Spring applications to autowire a field on an abstract class.

See, this is helping. A little bit: Now 'overwriting' the setter breaks auto-wiring and I can see how that may be non-obvious enough that the one doing the overriding just misses this. But this isn't even remotely close to good enough.

This is good work though: Link to reputable tutorials (I consider baeldung reputable, I'd think most would) helps. Links to the web-hosted source control of major projects engaging in a certain style helps. To convince us something is universal boilerplate, you need to hit both beats in that sentence: The boilerplate part tends to be easy enough to show, the universal part - therein lies the rub.

We may not use the frameworks you use daily. Even if we do, many lombok users won't. The feature needs to make sense either without mentioning those frameworks at all, or by mentioning such a varied batch of different frameworks where this comes up that it's effectively universal.

@haelix888 wrote:

Mockito will mock all methods of an object if they're not final.

You bet. That counts and is helping push this request towards feasibility. I think I want more. I don't like mockito, but I'm pretty sure the java community has embraced it with gusto, but the problem here isn't motivating me, roel, or anyone else to write the PR (that is the easy part). Hence, the only thing that matters is community understanding.

@andrebrait
Copy link
Contributor

@rzwitserloot I think someone also mentioned abstract classes when used with DI frameworks and whatnot, or just when proving things for external usage and the like.

TBH, I understand that these might not be soooooo compelling use-cases, but I see there is already other things of the same sort on Lombok (makeFinal in FieldDefaults for example) which are arguably more useful, but may end up not so useful of you can override the getters or something.

So I think we could consider this a low-hanging fruit by that token?

I'm only following this issue because I once thought I needed something like that, so I guess people are running into use-cases?

(This other person's attitude is totally not acceptable, but I decided to address your other points regarding not considering adding this feature).

I can provide a PR for this if it makes it easier to justify adding it? (I never bothered to make it happen after I moved in from the project where I needed it, but I can find some time this weekend or the next, I think)

@rzwitserloot
Copy link
Collaborator

rzwitserloot commented Feb 5, 2022

@andrebrait wrote:

but I see there is already other things of the same sort on Lombok (makeFinal in FieldDefaults for example) which are arguably more useful, but may end up not so useful of you can override the getters or something.

@FieldDefaults gets the benefit of not cluttering up e.g. @Data or @Getter. FieldDefaults just makes fields final and/or private, that is all it does. Hence its of a different echelon versus adding a bolt-on setting to e.g. @Getter to say: Please make final. It also adds complications - currently @Getter just does what it does. Hence, the question of what happens here:

@Getter(access = AccessLevel.PACKAGE) class Example {
  @Getter String foo;
  int bar;
}

is mostly irrelevant. Why would you write that? I'm not even usre what happens if you do this, but hopefully it is clear that one can plausibly say: That field-level annotation does nothing, and one can also plausibly say: That field level annotation pushes the access level back to the default, which is public - the above code makes public String getFoo() and /* package private */ int getBar().

Add makeFinal in the 'settings' of @Getter and all of a sudden the above code is no longer trivially discardable as malicious/obviously silly. What if that field-level getter is there simply to set the makeFinal property just for that one getter?

This isn't a showstopper. Of course not. Merely a complication; we'll find some acceptable answer and move on if we decide to add this feature. But it is exactly that kind of thing that makes me so very miffed at folks like @jennierose who act like we owe them something. No, we don't, and no, this stuff is much, much, much more complicated than you can evidently comprehend, so please stop suggesting we're not implementing this out of spite or laziness. We're hesitant to keep lombok easy to use, and we feel keeping such 'what-ifs' to a minimum is an important aspect of keeping it easy to use.

Point is, this is by no means low hanging fruit, and isn't comparable to @FieldDefaults.

I think someone also mentioned abstract classes when used with DI frameworks and whatnot, or just when proving things for external usage and the like.

I'd like to specifically know which ones and what it looks like. If it's just about preventing your own programming team from making an obvious mistake, that wouldn't be very convincing. If the final property actively modifies what the DI framework does, that'd be much more convincing. But I'd like a link to docs and/or tutorials and/or samples first.

I can provide a PR for this if it makes it easier to justify adding it?

Much appreciated! But this one is a bit of niche issue - it's so easy to make, virtually all the work lies in writing the docs, the tests, and signing up to the adjustment in lombok's learning curve, which new committers probably can't help us with. If you'd like to in order to have a few lines in the code base, by all means. But wait for sign-off. I'm not convinced yet, it's something @rspilker and I will need to discuss (Unless @rspilker is quite opposed to this, an endorsement from a major contributor would push this over the line).

@andrebrait
Copy link
Contributor

@rzwitserloot got your points.

As for the code sample, I would assume the field-level one has precendence over the class-level one, IIRC. I think I've done that sort of thing before and it's what I remember seeing when I did #2513.

@rzwitserloot
Copy link
Collaborator

Yes, field-level annotations have precedence, I think that's what almost everybody would assume, but do they act like annotations and thus, @Getter with nothing else 'overwrites' access to PUBLIC, or do they act more like language features, and there's a difference between not mentioning it (meaning: Do something sane, a good default - not neccessarily PUBLIC). It's not about what lombok currently does. It's about the simple point that it's hopelessly confusing.

I would optimally want to rewrite AccessLevel to include some sort of INHERIT or CHAINING or whatever option, and rewrite the default to that, defined as: "Inherit from parent type, if the parent type doesn't mention it, PUBLIC" - now confusion has been eliminated. But I'm not sure if that's entirely backwards compatible.

@fsilkswan
Copy link

Nice to see some "progress" for this feature request. :)

I must admint I don't understand the confusion.
Field-level annotations have precedence. That's it. And it is what I would expect.
And why is this discussion suddenly about access level?

I get your point with "50 parameters" for the @Getter/@Setter annotations, but I think it is a bit exaggerated.
Keeping the API intuitive is not always an easy job. We all know that.
But at the point where intuition ends, the documentation will provide clarification I dare say.
And there's also the IDE.
"Eclipse" for instance shows the details of all methods (incl. the Lombok generated ones) in the class outline view.
So there's no need for guessing what will happen: The IDE (incl. "Intellij IDEA" and many others) will tell you right away.

I still think support for the "final" keyword in the byte code for getters/setters generated by Lombok would be a great addition.
It is a language feature and people like me tend to use such things. ;)

In my case I use final methods (incl. getters/setters) in abstract classes in order to point out that those methods are not safe/destined for overriding. Even in non-abstract classes this approach is useful.
Inheritance in Java is tricky sometimes and I think it is good practice to design classes with inheritance in mind.
The "final" keyword is very helpful in this context.

Thanks for your patience and keep being "cautious" regarding change requests.
I think you're handling these things very well!

Cheers!
-Ferdinand-

@haelix888
Copy link

@rzwitserloot

You bet. That counts and is helping push this request towards feasibility. I think I want more. I don't like mockito, but I'm pretty sure the java community has embraced it with gusto

Happy to see some action here and also that my "use case" with Mockito is deemed the most material so far (albeit not reaching critical mass).

FWIW I though I might add that final also has (almost surely) an bearing on performance also and Getters being so widespread and conveniently generated with Lombok, this fact is not without significance.

@rzwitserloot
Copy link
Collaborator

Field-level annotations have precedence. That's it. And it is what I would expect.

It's about this situation:

@Getter(access = AccessLevel.PROTECTED)
class Example {
  @Getter(makeFinal = true) String foo;
  String bar;
}

If you don't see how it this snippet is non-obvious about what that does (is it public final String getFoo() or protected final String getFoo()?) I have nothing more to say. It is to me, which means it needs to become un-confusing or this feature isn't happening. That's why we're talking about it.

but I think it is a bit exaggerated.

We are in this to make a nice tool that our users love. But when it comes to opining about maintainability, the only opinions that matter are those of contributors that earned the right to talk. You haven't. That's okay - feedback is welcome and I don't expect you to know which kinds of feedback are more useful than others. Hopefully you'll allow me the freedom to state that certain feedback ends up not being actionable!

I though I might add that final also has (almost surely) an bearing on performance

Hotspot probably makes this point moot. If someone shows me JMH measurements that indicate it isn't, that would be another solid use case and would push this over the edge.

@rspilker
Copy link
Collaborator

rspilker commented Feb 7, 2022

Please consider (benefits/downsides) @Accessors as a home for makeFinal.

If it's part of @Accessors, I think a config key would actually make sense, because than it's a style for "all your DTO's" or something like that.

@o-pikozh
Copy link
Author

o-pikozh commented Feb 7, 2022

@Getter(access = AccessLevel.PROTECTED)
class Example {
  @Getter(makeFinal = true) String foo;
  String bar;
}

If you don't see how it this snippet is non-obvious about what that does (is it public final String getFoo() or protected final String getFoo()?)

I would clearly expect this to be protected final String getFoo().

@rzwitserloot
Copy link
Collaborator

rzwitserloot commented Feb 7, 2022

@o-pikozh Yes, and someone else in this thread indicated they clearly expect that to be PUBLIC, and thus you see why this is a blocking issue (which can be solved, but, explains why I'm mentioning it, and why I'm slightly miffed at the cavalcade of 'why have you not added this already it is so simple!'). I'm liking @rspilker 's idea of shifting this to @Accessors, that makes this issue entirely moot.

@andrebrait
Copy link
Contributor

andrebrait commented Feb 7, 2022

@Getter(access = AccessLevel.PROTECTED)
class Example {
  @Getter(makeFinal = true) String foo;
  String bar;
}

If you don't see how it this snippet is non-obvious about what that does (is it public final String getFoo() or protected final String getFoo()?)

I would clearly expect this to be protected final String getFoo().

I would expect it to be public.

The reason being that it's what acess is set to in the field-level annotation. Default values are still values. I wouldn't expect a cascade effect here.

So this is clearly an issue, like @rzwitserloot is demonstrating. As for moving that to @Accessors, sounds like a natural place for it.

I'd think a final getter but non-final setter (or vice-versa) to be an extremely rare use-case. Though I guess we'd still have the same issue of "expected behavior" when using that with class and field-level annotations. The only alleviating thing is a note on the documentation for Accessors which states that field-level doesn't cascade with the class-level annotation. Otherwise, it could look just as confusing?

E.g.:

@Accessors(makeFinal = true)
public class Foo {

    @Accessors(prefix="f")
    @Getter
    private final int Bar;

}

Would that be a problem @rzwitserloot @rspilker?

@andrebrait
Copy link
Contributor

The result there would be a non-final getter, according to the documentation. Just commenting on the fact it could be confusing the same way adding it to Getter would.

@rspilker
Copy link
Collaborator

rspilker commented Feb 7, 2022

From the documentation:

@Accessors currently does not 'cascade' from field @Accessors annotation to the class-level @Accessors annotation, but it does 'cascade' to lombok.config. Changing this is not difficult but backwards incompatible. It's not likely to break much existing code, but this needs to be decided on before the feature can move out of experimental status.

@rzwitserloot rzwitserloot removed the parked Without further feedback this bug cannot be processed. If no feedback is provided, we close these. label Feb 8, 2022
@rzwitserloot
Copy link
Collaborator

Have at it: https://projectlombok.org/download-edge

@rzwitserloot rzwitserloot added this to the next-version milestone Mar 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests