Thread
#stdlib
    r

    rrader

    4 years ago
    diego-gomez-olvera

    diego-gomez-olvera

    4 years ago
    r

    rrader

    4 years ago
    Thanks, but we want to disable it only for some cases, not at all. Maybe an annotation
    gildor

    gildor

    4 years ago
    @rrader Just curious, what is your case?
    gildor

    gildor

    4 years ago
    @rrader I see. of course, I don't know exactly your case, but agree with other people on this thread, that solution with disabled null checks is really smell
    r

    rrader

    4 years ago
    @gildor
    !!
    and
    -Xno-param-assertions
    also are smell, but Kotlin support them in order to satisfy developers needs, the annotation will be same as
    -Xno-param-assertions
    but more restrictive which I think is better
    gildor

    gildor

    4 years ago
    -Xno-param-assertion is not officially supported and can be removed in future also not recommended to use Usually you avoid !! and use only when ut really necessary. Also !! way to check for null, not to avoid this check, just special syntax to throw NPE
    Maybe make more sense to improve such deserialization on Spring side? For example validate value before object creation (Kotlin nullability info from constructor can be used to validate this). Spring already supports some Kotlin features and guys from Spring did the great job to support nullability, maybe @sdeleuze could comment this case. Just because some annotation to disable null checks sound like a really bad idea, especially for such specific case
    r

    rrader

    4 years ago
    I will be happy with validation before object creation, but Spring provides support for declarative validation with JSR-303. So this is how JSR-303 works.
    gildor

    gildor

    4 years ago
    Okay, jsr303 can work after object creation, but nullability can be checked before object creation
    r

    rrader

    4 years ago
    if we fail on nullability, then we will not get others non nullability errors, main point is to get all validation errors about all properties at one time
    sdeleuze

    sdeleuze

    4 years ago
    What I can say about this is that we had to update Spring Framework 5 to support instance creation by constructor in addition to default constructor + setters in various places. The related JSR is 305 (not 303) and I don't think an annotation to disable such check is a good solution. Also be aware of that if you are using bean validation annotations: https://stackoverflow.com/a/35853200/1092077
    What framework are you using?
    If it is Spring, what version?