Field constraints

[Andreas Wenger]

Hi,

Let me first say that Lombok is great. I especially love the withers that we recently discussed on, they are working like a charm.

My question for today: What is the best way in Lombok to check the validity of the fields within a class? I am aware of the @NonNull annotation, which is applied to the generated constructors and setters, but is there a more general approach?

Here is an example of a class using Lombok:


public class Canvas {
   
    @NonNull private String title;
    private int width;
    private int height;
    @NonNull private Color background;
   
    public Canvas(String title, int width, int height, Color background) {
        if (title == null || background == null)
            throw new IllegalArgumentException();
        checkWidth(width);
        checkHeight(height);
        this.title = title;
        this.width = width;
        this.height = height;
        this.background = background;
    }
   
    private static void checkWidth(int width) {
        if (width < 800)
            throw new IllegalArgumentException("width must be >= 800");
    }
   
    private static void checkHeight(int height) {
        if (height < 600)
            throw new IllegalArgumentException("height must be <= 600");
    }

    public void setWidth(int width) {
        checkWidth(width);
        this.width = width;
    }

    public void setHeight(int height) {
        checkHeight(height);
        this.height = height;
    }
   
}


I want to ensure that the width is always >= 800 and the height is always >= 600. As you can see, there are two problems: I have to reimplement the constructor and both setters, which is again lots of boilerplate code that could be avoided.
What I'd like to see is something like this:


public class Canvas {
   
    @NonNull private String title;
    @Checked private int width;
    @Checked private int height;
    @NonNull private Color background;
   
    private static void checkWidth(int width) {
        if (width < 800)
            throw new IllegalArgumentException("width must be >= 800");
    }
   
    private static void checkHeight(int height) {
        if (height < 600)
            throw new IllegalArgumentException("height must be <= 600");
    }
   
}


The (imaginary) @Checked annotation tells Lombok to execute the checkXxx(...) method when the field xxx is modified (constructor + setters). If not there, Lombok could generate a warning. There could also be a @Checked annotation on the class, which calls a check(...) method including all fields.

Is something like this planned for the next releases? Are there better solutions? Thanks for sharing your opinion.

Bye,


Andi

[Andreas Wenger]

Sorry, I missed the @Data annotation on both classes.

[Fabrizio Giudici]

It's something that I would like to see. Perhaps we should first look at
some existing annotations for field validation and check whether their
semantics are compatible - e.g. Bean Validation JSR 303.

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[Christian Sterzl]

Is that really something, lombok should do? Bean Validation has a lot of constraint annotations and I dont want to see them all reimplemented in lombok.
The devs will be confused which annotations a project uses and so on.

[Philip Healy]

I think that this idea has merit, provided that it reuses the JSR 303 annotations.

An issue with JSR 303 constraints currently is that they are only checked when validation is invoked, for example during DB persistence.

Using Guava preconditions to check parameters is another approach, but of course requires setters to be implemented that do the checking. If there are already validation annotations on the field then the Guava checks are essentially boilerplate.

It would be nice if Lombok could (optionally) enforce JSR 303 annotations automatically in generated setters.

On 12 May 2013 16:14, Christian Sterzl <christia...@gmail.com> wrote:

Is that really something, lombok should do? Bean Validation has a lot of constraint annotations and I dont want to see them all reimplemented in lombok.
The devs will be confused which annotations a project uses and so on.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Andreas Wenger]

Maybe we could generalize the idea. I used the checkXxx methods for constraint validation and throwing an Exception if the values are invalid, but the methods could do anything. The @Checked annotation could also be called @Guarded and the methods guardXxx. One could include logging in these methods, notify listeners on this field, and so on. Constraint checking is really just a single use case.