copyableAnnotations

[Mat Jaggard]

Would it be possible to add additional configuration to copyableAnnotations to allow me to copy Jackson's @JsonIgnore to the places it is allowed but not those it is not - specifically in this case it is allowed on methods, fields and constructors but not on parameters so I'd like it copied to the setter but not the parameter to the setter for example.

Ideally it would be great if this was auto-detected but I know that will be hard, but I'd be fine with it being configurable.

Maybe a key like copyableXXXXAnnotations for each location that it could be copied?

[Reinier Zwitserloot]

It feels like turning lombok.config into a shitty DSL that lets you configure all this is something everybody involved would find an ugly hacky disaster.

So, no, I don't think that's a good idea.

However, I have no problem 'hardcoding' knowledge about commonly used types in lombok core itself. I get that it doesn't really scale, and I'm all ears that we, internally, in lombok's own source repo, have a list that does have the ability to explain precisely where it is and isn't legal and where it should and shouldn't be copied, so that maintainers of other libraries have as easy a job as we can make it to add their annotations to this list, but let's not have all lombok users first read 4 pages worth to figure out how to write a lombok.config file to get it right, and then read the manual of whereever this annotation is from to make sure it all adds up, and then pray future versions of said library don't expand on the annotations' targets.

In other words, to answer your question: No, not possible. But what IS possible is that we just let lombok know what `@JsonIgnore` means. We already have a bunch of support for a bunch of jackson annotations, heck, I'm half surprised this doesn't already work right. See https://github.com/projectlombok/lombok/blob/5120abe4741c78d19d7e65404f407cfe57074a47/src/core/lombok/core/handlers/HandlerUtil.java#L320 - we already hardcode info about this annotation and how it should be copied. If lombok is not applying the right copying behaviour for JsonIgnore, that'd be a bug, and we need to fix it (primarily by shuffling it around in this linked source file).

[Mat Jaggard]

That makes perfect sense and I was starting to feel nauseous as I was suggesting the properties approach. In my previous job we used immutable value classes with @SuperBuilder which works perfectly (thanks!) but in my new job I've got a whole different setup and it doesn't quite work correctly. I'll have a look on Monday to see how that code works and whether I can fix it.

Thanks again.

--
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-lombo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/8445487e-95a2-467b-a45d-b6cb767c82b1n%40googlegroups.com.

[David Blevins]

Hi All,

I realize this was asked and shutdown, but I wanted to chime in and say I have the same need that annotations are copied to the builder methods rather than parameters.

I respect and agree with the DSL concerns, but could there be some basic flag that says when it comes to copying annotations, please copy to the setters and builder methods themselves rather than their parameters?

The fact that I can put lombok.config files in any location of my source is quite flexible enough that in practice I would never need any form of DSL-like syntax.  When working with marshaling/mapping libraries or APIs like JAXB, JSON-B, JPA, etc. I'm typically creating large trees and put all that code in a dedicated java package.  It would be very easy to also add a lombok.config in that package and set a simple policy of copy any annotation found on a field to the getter, setter, or builder method.  In most cases I wouldn't need to list the annotations explicitly as most APIs are designed to allow field or method injection to work equally.  The only time I would need to explicitly list a class by fully qualified name is the rare case when I want to exclude an annotation, which I could also safely do via the "lombok.copyableAnnotations -=" syntax.

So basically, the ability to say via lombok.config my policy is to copy annotations to methods (setters, builders).  Optionally, since I do have control over where I put my lombok.config and can place that just in specific packages, it could be nice to say my policy is to copy all annotations except where I've excluded via `lombok.copyableAnnotations -=`.

Thoughts?

Side note, this is actually the first time I've needed a lombok.config and my first instinct was to put it in this dedicated package as the documentation was very clear this was possible and useful for narrowing the scope that settings are applied.

-David

[Reinier Zwitserloot]

I think you misunderstand how complex this gets. There are a ton of 'copy targets', if the target audience for this hypothetical feature isn't aware of that and we actively try to keep things simple (both for us to write and maintain, and for the target audience to use), given that its hiding complex stuff, its likely the target audience does it wrong and then is all confused. Bad idea for a feature.

An annotation on a type, do we copy it to:

* Setter param

* Setter method

* Getter return type

* Getter method (there is a difference!)

* Wither param

* Wither method

* builder 'setter' param

* builder 'setter' method

* generated builder field

* do we remove it from the field or keep it there?

* ... and what if the answers to these questions depend on your situation and/or the version of the source of these annotations?

and that's not even all the complexity involved.

[Thorsten Glaser]

On Tue, 6 Sep 2022, Reinier Zwitserloot wrote:

> An annotation on a type, do we copy it to:
>
> * Setter param
> * Setter method
> * Getter return type
> * Getter method (there is a difference!)
> * Wither param
> * Wither method
> * builder 'setter' param
> * builder 'setter' method
> * generated builder field
> * do we remove it from the field or keep it there?
> * ... and what if the answers to these questions depend on your situation
> and/or the version of the source of these annotations?

Is it possible to do something like:

@LombokAddAnnotation({ setterMethod=AnnotationA, getterReturn=AnnotationB("foo") })

That would leave the decision/effort to the user.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

[David Blevins]

Completely understand the complexity. Let's talk through the use case at least and see if we can come to agreement on if it is something we think is useful -- even if we can't immediately see any good solutions.

Here's the use case in summary.

There are several APIs in the Java EE / Jakarta EE specifications that have the following injection rules for their annotations:

- Field injection: data is injected via annotations on fields of the class
- Setter injection: data is injected via annotations on setter methods
- Constructor injection: data is injected via annotations on parameters of a constructor

This means a lot of APIs have annotations that have a target type of FIELD, METHOD and PARAMETER. APIs that use this include CDI, JAXB, JSONB and JPA. JPA doesn't currently support constructor injection, but this is being discussed in Jakarta Persistence.

In the above, use of the annotations on Parameters are restricted to constructors. In the above, use of annotations on methods must be done on setters (methods with one parameter).

The use case is using Lombok to generate builders that are compliant with the above rules: annotations on a field are copied to the builder's "wither method"s so it can be used in the above APIs.

The trick is lombok will currently put any annotation that has PARAMETER as a target onto the parameter of the builder's "Wither param". This is true even if the annotation also targets METHOD. This means the builder cannot be used in the above APIs.

Do we think the above is a good use case?


-David

> To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/07e79db1-0f17-4634-9915-0f50a1575610n%40googlegroups.com.