https://kotlinlang.org logo
#stdlib
Title
# stdlib
r

rrader

03/19/2018, 10:44 AM
d

diego-gomez-olvera

03/19/2018, 10:54 AM
r

rrader

03/19/2018, 11:03 AM
Thanks, but we want to disable it only for some cases, not at all. Maybe an annotation
👍 1
g

gildor

03/20/2018, 1:00 AM
@rrader Just curious, what is your case?
g

gildor

03/20/2018, 2:18 PM
@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

03/20/2018, 2:20 PM
@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
g

gildor

03/20/2018, 4:30 PM
-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

03/21/2018, 7:13 AM
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.
g

gildor

03/21/2018, 7:24 AM
Okay, jsr303 can work after object creation, but nullability can be checked before object creation
r

rrader

03/21/2018, 7:44 AM
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
s

sdeleuze

03/22/2018, 9:42 AM
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?
2 Views