CODEWITHSUNDEEP
jakarta-eeconstraintsbean-validation
Arashsoft
Arashsoft

Reputation: 2767

What is point of constraint validation @Null?

I was checking list of available constraints in javax.validation package and I noticed that there is an annotation @Null which force the field to be null.

I do not understand what is point of adding it to my field if I already know it should be null.

For example look at this class:

public class MyClass{

    @NotNull
    private String myString1;

    @Null
    private String myString2;

    // getter setters...
}

@NotNull completely makes sense. I do not expect myString1 to be null. but @Null makes myString2 useless. What is point of having a field which should always be null.

Upvotes: 30

Views: 24654

Answers (2)

ThreeDots
ThreeDots

Reputation: 767

You may want to use @Null in combination with "Validation Group" to validate the null constraint only in certain cases.

Good explanation and example on validation groups provided by Hibernate

You will define validation group as simple interface

public interface FirstSave {}

then use it in constraint

public class MyClass {

    @Null(groups = FirstSave.class)
    private LocalDate lastUpdate;
}

then if lastUpdate is not null, calling validator.validate(myClassInstance) will not produce constraint violation (Default group was used), but calling validator.validate(myClassInstance, FirstSave.class) will.

You also have the possibility to provide your own implementation on how to use the annotation, i.e. I've seen validation method being annotated with @Null where null returned by the method meant that everything is alright. In the background there was probably custom implementation on what to do if annotated method returned not null result, but I didn't go deep into the code...

Upvotes: 22

Shiv
Shiv

Reputation: 51

@Null is a very important annotation. It is not useless. Let me show a common usecase. Say, there is DAO (entity) object with Id auto-generated.

If you use separate classes for DTO and DAO, @GetMapping returns list of DTOs without issues. On the other hand, @PostMapping for adding a new element requires that input DTO must not contain Id field and even if present it must be null or undefined. Such an input when converted to and from DTO object, expects Id must be blank. For this, @Null is the only choice

@PutMapping expects id must not be blank so @NotNull is required for id field when we expect update happens to a single object.

@DeleteMapping requires just integer Id , only if we want to delete an object with known Id.

There are alternative complicated cases, which usually are not handled but makes sense

@GetMapping can be used for any provided field but if any of the field other than Id is provided then Id must be blank. If Id is provided then all others must be blank.

There is also a complicated @PutMapping requirement, where in partial information is provided for update and expected remaining fields to be older values. Here non-null fields are updated.

Another annotation @DeleteMapping is used to delete or remove. If it is computed to blank, it can be implented with @Null constraint.

Usual CRUD operations are too simple but not a suitable usecase for practical expectations.

All these mix of requirements can be listed into groups. And constraints can be provided with groups attribute with separate Marked interface @Validated can be applied as per requirement.

Upvotes: 5

Related Questions