Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Using @Setter and @Accessors(fluent = true) together

675 views
Skip to first unread message

Vassili Jakovlev

unread,
Feb 4, 2016, 4:34:45 PM2/4/16
to Project Lombok
Hi,

Are there any technical limitations in Lombok that prohibit generating two types of setters in a class?

For example,

@Setter
@Accessors(fluent = true)
public class A {

private int a;

}

would result in:

public class A {

private int a;

public void setA(int a) {
this.a = a;
}

public A a(int a) {
this.a = a;
return this;
}
}

In that case class A would be POJO compatible (setters will have void return type) and also it would be possible to use fluent chained setter.
Probably, additional attribute for @Accessors annotation is required (for example, keepPojoSetter = true)

Best regards,
Vassili

Roel Spilker

unread,
Feb 8, 2016, 5:55:01 AM2/8/16
to Project Lombok
Although it might technically be possible, I think this is not a common pattern and I would not like to add the added complexity to lombok unless there is a very strong argument to support this.

Vassili Jakovlev

unread,
Feb 8, 2016, 4:00:23 PM2/8/16
to Project Lombok
Real world scenario:
We would like to use fluent setters and in some cases we need to use reflection to set values to a bean's fields.
As an example, BeanUtils.setProperty() from Apache Commons expects setter method to be with a void return type.
There could be more cases, for example, some ORM tools could also expect void setters.

Vassili

Lenny Primak

unread,
Feb 8, 2016, 5:41:35 PM2/8/16
to Project Lombok
+1
We have exactly such a scenario as well, I think it would be a great addition to Lombok
Thank you for considering

Bernhard Streit

unread,
Apr 6, 2017, 2:16:02 PM4/6/17
to Project Lombok
I would say it is turning into a common pattern nowadays, swagger for example also generates the models this way (normal and fluent setters).

And it's really useful, as pointed out below, you don't break the bean standard but you can still use the fluent setters.

Dennis

unread,
Apr 9, 2018, 7:54:25 PM4/9/18
to Project Lombok

I'd like to upvote this request as well, because it's so easy to chain methods this way while the code remains compatible with "the EJB way".
Currently we are using @builder for this but technically we are allying a builder pattern where one isn't required (the props are not immutable).
Besides, with this trick we can set superclass props from a subclass with no drama, unlike the builder pattern which is somewhat limited in this respect.
It would be a cool experimental feature to start with!

Reinier Zwitserloot

unread,
Apr 15, 2018, 7:52:10 PM4/15/18
to Project Lombok
This is self-defeating.

axiom: Convenience when coding is important.

Proof of axiom: If you didn't care that much about it, clearly writing 'setX' is no hardship compared to writing 'x', and therefore you can just go with POJO style and be happy. If POJO style alone is not good enough for you, then clearly you care about stylistic choices.

Given the above rule, then... how in the blazes can you accept the situation where you have BOTH 'name(String newName)' AND 'setName(String newName)', being equivalents of each other, in the same class? That's not nice style at all. And we've already posited that you care about style and APIs and such.


I guess it works out if you care about certain aspects of API design but don't care about others, but the kind of scenario where you get there just doesn't add up to a consistent programming experience in my view. Evidently this is a world where you write in notepad and the auto-complete dialogs of your IDEs are irrelevant. Lombok is not designed for you, if that's how you program.

The harsh penalty of seeing double in your API docs and all other places 'list of methods' comes up (such as your IDE's outlook views and autocomplete dialogs) is vastly more costly than the gain of being able to write fluent API whilst playing ball with stuff that expects beanspec style setters.

One utterly crazy trick solving both problems in one go is that we generate synthetic beanspec methods, thus conviently making it illegal to call them from java source and having them not show up anywhere relevant (not in javadoc, not in auto-complete dialogs, at any rate), and yet, at the VM level these methods exist; you can reflect into them and compiled code can call them just fine. It's javac / ecj that act as if synthetic methods do not exist, the VM doesn't look at the 'synthetic' flag.

The problem is, we can't make em synthetic without a post-compile class rewrite op, which means the feature is a bit complex, hard to explain, and the produced end result cannot be rewritten as a delomboked source file which is quite a big cost. We're willing to pay it, but not for such an exotic feature.

Martin Grajcar

unread,
Apr 15, 2018, 8:21:07 PM4/15/18
to project...@googlegroups.com
IMHO having two setters is more ugly than anything else. I guess that rewriting BeanUtils.setProperty and related stuff could be done in a few minutes and then you could use reflection with fluent setters and anything you prefer.

Concerning ORM tools, I'm using Hibernate and I've solved the problem by annotating the fields instead of the methods. This may have some disadvantages, but so far I haven't noticed any. Other tools may be tougher.

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombok+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Luis

unread,
Jan 31, 2019, 7:01:17 AM1/31/19
to Project Lombok
I'd also like to upvote this request, I think this has become a necesity and a standard as mentioned above swagger uses it, if it were not so then this request and all it’s comments would not exist. I think Lombok should offer a way to achieve this and the developer is the one who chooses to use it or not.

Reinier Zwitserloot

unread,
Feb 9, 2019, 1:05:21 PM2/9/19
to Project Lombok
I've said before why this request makes no sense. No amount of '+1' style commentary is going to change our minds. If someone manages to shoot some holes in my reasoning about why this feature request makes no sense might move the needle, but that's the only way.

stijn

unread,
Sep 6, 2022, 8:44:23 AM9/6/22
to Project Lombok
Your earlier comment makes no sense in my opinion:

"the above rule, then... how in the blazes can you accept the situation where you have BOTH 'name(String newName)' AND 'setName(String newName)', being equivalents of each other, in the same class? That's not nice style at all. And we've already posited that you care about style and APIs and such."

by no means they are equivalent to each other. One returns this, the other returns void. They are two distinct kinds of functionality to add to your class. I've been trying to implement this in my current project and I am amazed this isn't possible using Lombok.
Op zaterdag 9 februari 2019 om 19:05:21 UTC+1 schreef Reinier Zwitserloot:

Reinier Zwitserloot

unread,
Sep 6, 2022, 10:15:17 AM9/6/22
to Project Lombok
> by no means they are equivalent to each other. One returns this, the other returns void.

That's, API design wise, meaningless. Agree to disagree, perhaps? We're not addressing this issue.

Marc Günther

unread,
Sep 26, 2022, 12:43:25 PM9/26/22
to Project Lombok
The issue is, that someone who for whatever (historical?) reasons is forced to have bean-style setters on their classes (aka: set prefix and void return) would like to use fluent setters for their own development. I think that request makes perfect sense.

Is there really added complexity here to support that use case. These two seem like completely separate annotations, I am actually surprised it does not already work like this out of the box.

Regarding your "axiom". If the presence of the bean-style setters is dictated by the use of some libraries that follows Java Bean convention, than the existence of these setters is NOT the choice of the developer, so your argument falls apart. I don't see why the usage of such library should disallow one from using fluent setters. 

Yes, it's ugly. So what. OP never said that this feature will make the generated code prettier. But it will make his own code prettier, and that is way more important I think.


Reply all
Reply to author
Forward
0 new messages