注释@NotNull 不适用于值对象

Question

In one of my spring boot's @RestController methods I'm getting a json object in @RequestBody .

I want the fields in this object to be not null, that is they should always have non-blank value.

Based on many answers like these , I tried to use @NotNull, @NotEmpty, @JsonProperty(required = true) on fields, but it is not working.

Even if the attribute in JSON is not present, the field is receiving a default value.

My code:

RestController:

import org.springframework.web.bind.annotation.*;


@RestController
@RequestMapping("/api")
public class MyController {

    @PostMapping("/save-data")
    public void saveData( @RequestHeader("my-request-header") String myHeader, @RequestBody MyValueObject myValueObject) {
        service.saveData(myValueObject);
    }

}

POJO:

import com.fasterxml.jackson.annotation.JsonProperty;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.Getter;
import javax.validation.constraints.NotNull;


@Builder
@Getter
@Setter
@Data
@AllArgsConstructor
public class MyValueObject {

    @JsonProperty(access = JsonProperty.Access.READ_ONLY)
    @NotNull
    private String id;

    @JsonProperty(value = "my_name")
    @NotNull
    private String name;

    @NotNull
    private int age;
}

So if in json request I'm passing only id & name, I'm still getting age as 0(zero).

Answer 1

Primitive types do have default value which is what is getting set for age since it is int. Can you change it to Integer class.

Answer 2

javax.validation.constraints.NotNull;

The notion of validation is generally what you apply to outside input . You have no control over that input directly; hence, the need to validate it before continuing.

Crucially, then, it should be possible for an object that models this input to represent invalid state . After all, invalid input can happen , and your code is supposed to perfectly represent such input. This input should then be deemed as invalid and rejected once you try to use it.

That means it should be possible to mark something as @NotNull (this particular NotNull annotation, which is specifically about validation, there are others that are not,), and still create an object where the value is null anyway. Such an object is not valid , and a validation framework will know it isn't, based on that annotation.

There are other takes on not null annotations. When you are using a class as a 'model' for defining an SQL database table, annotations exist that guide the creation of the CREATE TABLE statement, and one can 'guide': Please add an SQL NOT NULL constraint. That's a completely different concept entirely and yet those annotations are also called @NotNull .

A third concept is requesting code injection to inject a null check. This is what lombok's @NonNull annotation does. If you write:

void foo(@lombok.NonNull String hello) {
  System.out.println(hello);
}

then lombok turns that into:

void foo(@lombok.NonNull String hello) {
  if (hello == null) throw new NullPointerException("hello");
  System.out.println(hello);
}

And a fourth, yet again completely different take, is as a type system modifier. The notion 'the parameter to the foo method is a string reference that CANNOT be null. This take sounds identical to lombok's take, but it is in fact essentially the opposite. This code, is obviously silly and doesn't even compile, it's that silly:

void foo(String arg) {
  if (arg instanceof Integer) thow new IllegalArgumentException("Please give me a string and not an integer");
}

for the exact same reason, the lombok generated code is 'silly' if you deem that @NonNull to be a type modifier. It CANNOT be null as per the type analysis, so why are you checking for an impossibility?

Thus, this is a 4th 'take' and all 4 takes are completely different in what they mean and do . This last one doesn't "work" with vanilla java (which doesn't enforce non-nullity onto callers, the way java does enforce that you eg don't pass an Integer instance to a method like this, and you can't get around this enforcement in any way), but there are compiler plugins and the like that add it, and if you live in a world where all compilation uses these plugins, then the null check is, indeed, warning-to-error-level unneccessary.

To add fuel to this already considerable fire, java supports annotating parameters, fields, and methods. Java also supports annotating types. Some null annotations operate on p/f/ms, others operate on types, and yet again this causes significant differences in how to use them and what they actually end up causing to happen.

Given all that, hopefully you now understand why it is 'hard' to make a @NonNull or @NotNull annotation do what you want it to do. They are all different, and there are like 20 commonly used variants.

I noticed in your question you didn't actually properly describe what you want. Probably because you're not quite aware of all the various takes on what 'not null' can mean. You can use this answer as a guide so you know precisely what you do want and then read the documentation of the various null-annotation framework(s) you have available to you, and pick the correct one. Then apply that annotation, and it'll then do what you want it to do.

I want the fields in this object to be not null, that is they should always have non-blank value.

an int cannot be 'blank'. If you consider '0' to be 'blank', okay, you can of course add a constraint that they must not be 0, but @NonNull or @NotNull , any variant and any of the 20 takes out there on the concept, they'd all NOT do that. Because null and 0 are very different things. Various validation frameworks do have a 'not this specific int value' concept, you can use one of those.