Add @Validator.

[lombokissues]

Migrated from Google Code (issue 639)

[lombokissues]

:bust_in_silhouette: reinierz   :clock8: Feb 10, 2014 at 19:42 UTC

Any method with @ Validator is called right before returning from any generated constructor and any generated setter.

A warning is not emitted if lombok never generates a call to it; eclipse / your IDE will take care of it if it's private and you don't call it yourself, and it's rather ugly to try and hack support for that, as it'd be a cross-cutting concern.

@ Validator has no parameters. You can't suppress lombok's generation of a call to this method in all generated setters and all generated constructors (if you want to skip validation, it's no longer boilerplate).

Multiple methods can have @ Validator on it; they'll all be called in declaration order.

The @ Validator method may have a return type, but the returned value is ignored. The idea is to accept the object's state, or, to throw an exception. @ Validator methods must not have any arguments, and must not be static. otherwise, any combination of keywords is fine.

Any throws clauses on validator method(s) are copied to all generated code (whether they are checked or not). Lexically identical exceptions are not copied (though note that java.io.IOException and IOException are not lexically identical even though they refer to the same type. Fortunately, declaring the same exception a bunch of times on the same method is actually legal java code).

[lombokissues]

:bust_in_silhouette: smarencik   :clock8: Nov 22, 2014 at 19:32 UTC

For constructor it has sence but I don't understand how about setters. If I need validation for setter then I write setter manually.

[lombokissues]

:bust_in_silhouette: reinierz   :clock8: Nov 25, 2014 at 22:02 UTC

Simple; whenever you set 1 of the many fields of your object, they are ALL validated again. This is highly efficient: If you're messing with validation at all then clearly this is not your super-tight inner loop that actually cares about performance at the CPU cycle level, at any other level, validation is free, and this way you waste no code or time trying to specify which code validates what, and also gives you trivial access to cross-field validation (where the validity of one field depends on the contents of another, so setting either should retrigger that particular part of the validation. Easier to just trigger it all everytime).

[lombokissues]

:bust_in_silhouette: marco.servetto   :clock8: Nov 26, 2014 at 00:42 UTC

whenever you set 1 of the many fields of your object, they are ALL validated again. Yes, I like your philosophy. I think this is the way to go

[lombokissues]

End of migration

[keesvandieren]

Is this issue still open? This is the reason we cannot use Lombok for builder pattern code.

[wakeboarder3780]

As @keesvandieren mentioned, without the @Validator annotation the value of the builder annotation is quite minuscule and will only serve for the simplest of objects that require no validation.

I will further lobby that in december of 2014 lombok wrote this article which stated to use @Validator for the validation concerns and it will work seamlessly with the @Builder annotation: https://projectlombok.org/proposals/changes_to_builder-20141204.html

It's 4 years later. Where is this Validator annotation? Without it, the Builder annotation only solves for the simplest of use cases. Is @lombokissues abandoning the concept of the @Validator annotation? If so, why?

[keesvandieren]

We are now using Kotlin data classes for new projects, and using http://immutables.github.io/ for domain objects in Java.

[brucewinger]

That is the only feature Immutable provides missing in lombok, any plan on this ?

[bbottema]

It's 4 years later. Where is this Validator annotation? Without it, the Builder annotation only solves for the simplest of use cases. Is @lombokissues abandoning the concept of the @validator annotation? If so, why?

4 more year slater...

[janrieke]

I think this will be covered by #1207.