I've just noticed this example in Spring docs: ```...

# spring

[Czar]

I've just noticed this example in Spring docs:

class PersonForm(
    @get:NotNull @get:Size(max=64)
    private val name: String,
    @get:Min(0)
    private val age: Int
)

Does this mean that we can finally use non-nullable properties in validated pojos and still get a nice validation error instead of kotlin's null passed into non-nullable property?

[Quy D X Nguyen]

Those don't do anything for null verification iirc.

[Quy D X Nguyen]

Just tells Java to consider the better nonnullable

[Quy D X Nguyen]

For IDE support

[Czar]

@Quy D X Nguyen these are javax.validation constraints, not nullability markers

[Ben Madore]

i’m going to guess that you’ll get the kotlin nullable error. I’m not sure how spring would be able to delay that error from being thrown and then instead throw an error when a not-possible-to-be-null field is nullable

[leodeng]

it’s easy to find out by writing a small application to test it. you will still get MissingKotlinParameterException, wrapped in spring’s HttpMessageNotReadableException (since i tested with a web app).

[Quy D X Nguyen]

My bad. Ye, the validation annotations only work with an ORM or similar, so it doesn't do anything normally.

[Czar]

Ok, I think I was not specific enough in the original post, here's what I'm talking about:

data class UglyButCourteousPerson(@field:NotNull @param:JsonProperty("name") private val _name: String?) {
   val name @JsonIgnore get() = _name!!
}

data class NiceButBadBehavedPerson(@field:NotNull val name: String)

@RestController
class TestController {
   @PostMapping("nice")
   fun printPerson(@Valid @RequestBody person: UglyButCourteousPerson) {
      println(person.toString())
   }
   @PostMapping("not-nice")
   fun printPerson(@Valid @RequestBody person: NiceButBadBehavedPerson) {
      println(person.toString())
   }
}

testing:

POST localhost:8080/nice

{}
###
POST localhost:8080/not-nice

{}

/nice will return nice validation error json and log at warn level

Field error in object 'uglyButCourteousPerson' on field '_name': rejected value [null]

/not-nice will throw ugly (in this context) IllegalArgumentException, pollute log with stack trace and return 500 http status to client.
I'm still looking for a way to avoid both IllegalArgumentException and _field + getter!! ugliness
Is there a way to check the constraints before trying to create the pojo? At least for simple single-property constraints.
If there isn't are there any plans to improve this?

[Ben Madore]

i don’t see how that could work in general purpose. if you annotate a POJO with bean validation annotations, you’d then be requiring every and all code that instantiates or mutates that pojo to first check for the annotation, do the validation, and then populate. i don’t tihnk that’s feasible. I am fairly certain the validation works by looking at a fully populated object.

[Czar]

It doesn't have to work like that, annotations can be read and processed before instantiation, Jakcson does it for example, even spring does it (e.g. for @ConstructorBinding @ConfigurationProperties)

[Ben Madore]

but using actual JSR-349/380 bean validation depends on calling validator.validate(annotatedObject) afaik it doesn’t have anything like validator.validate(source, potentialTarget) to determine if the properties on source satisfy the annotations on target