jdbi
if i use this annotation @Accessors of lombok ,have a bug
if i use this annotation @Accessors of lombok, this method "Introspector.getBeanInfo" can't get this writeMethod of clazz, so if i use @Accessors(chain = true), will throw "No appropriate method to write property 'propertyName'"
https://projectlombok.org/features/experimental/Accessors
The generated method names don't look compliant to me. Bean mapping only works with getX/setX. fluent = true will break this. chain = true will make the setters return an instance, which I think also invalidates them as bean property setters.
Return type of setters shouldn't be important, however the name surely is.
Can you post a sample case that fails? We could possibly improve the behavior. I think allowing chain=true is doable, while fixing fluent=true might be a bit larger of a change. But the community is encouraging more fluent-style builders, and fewer bean-style names, so we should consider it.
@TheRealMarnes is correct on both counts--if fluent ~and~ or chain is used, then Introspector doesn't recognize the method as a Java Bean setter.
@stevenschlansker what do you think about a FluentMapper to support on the mapping side what we already support through bindMethods?
Either a new mapper, or maybe preferably extend the existing reflection mappers to also find fluent style properties. At the end of the day it feels like there is one "set fields via setter methods" mapper with just a number of strategies for deciding which methods to call.
The resolution strategy could be a pluggable List so people could define a following order of desired strategies. Those strategies could also hold the logic themselves behind an interface so people could plug in their own implementations.
Looking at the Introspector source code, I can confirm that it only considers a method to be a setter if it returns void. Line 520 (Java 8) for simple setters, line 528 for indexed setters.
Sorry I'm a bit late to the party, but wouldn't using bindMethods (or the BindMethods annotation) work?
I rarely use Lombok myself (and I've never used it with JDBI), but they were added in #910 to fix #902 which was also about using Lombok's Accessor annotations.
@FredDeschenes This ticket is about having an analog to bindMethods on the mapping side.
Oops, I missed the part about this being for mappers -_-
In that case, Lombok supposedly generates the @ConstructorProperties annotation on the constructor if you have the @AllArgsConstructor annotation on the class (this is according to both the Jdbi and Lombok documentations), but for some reason this isn't working for me at the moment (you can also write your own constructor with the annotation, although annoying it works). If you can get it to generate this you could use the ConstructorMapper with your current class(es) without issues.
By the way I thought about creating a jdbi-lombok plugin a while ago, but Lombok likes to keep stuff 'experimental' for way too long for my liking (ie: the Accessors feature has been experimental since 2012!), so things would (possibly) break each time Lombok decides to change stuff.
jdbi-lombok
I'm just wondering what this module would even do? I don't see how there's a problem combining lombok with jdbi, aside from obvious naming style conflicts that you can tweak. Custom pluggable strategies for things like name resolution and constructor/factory method searching is about all I can imagine such a module doing.
@TheRealMarnes : Yeah that's what I had in mind, kind of like the Kotlin plugin : a couple custom mappers for fluent accessors and other oddities like this (ex: maybe support @Builder), but as someone mentioned earlier in the thread this could probably be included in jdbi-core with a FluentMapper of some kind.
The other Lombok annotations (like @Data) generate valid beans anyway so nothing to do for those.
There's really no runtime dependency on Lombok itself--just the classes that get generated. So it's weird to name a module after a library that isn't an actual dependency.
Moreover, since Lombok is just generating code that follows a particular design idiom (which other libraries also follow, e.g. immutables.github.io), I think it makes more sense to name the new binders / mappers after the idiom rather than the library--if that makes sense.
@TheRealMarnes The biggest problem IMO is that none of the Lombok annotations are retained at runtime, so we can't even use reflection to inspect a class for annotations to decide what to do.
Was this ever figured out? I see it closed but I have not seen any documentation that says it can be done.
We shipped lombok support a while back, there are a number of tests here: https://github.com/jdbi/jdbi/tree/master/lombok/src/test/java/org/jdbi/v3/lombok
