https://kotlinlang.org logo
Join Slack
Powered by
If you want something that is not nullable but is ...
# announcements
a
If you want something that is not nullable but is assigned later, you can use 
lateinit var
. Though I do not know.how it interacts with the framework.
r
the framework is calling constructor, so it passes the values, and after that it does the checks, so this will not help
a
I don' really understand. Constructor is called twice?
r
no, framework receive a json request, and should map json to class, so first it construct the object, and after that do validation, even not null validation
a
OK, I seem to have not understood the problem. According to other answers, the problem is with annotations, not the nullability itself.
r
We just need to not generate Intrinsics.checkParameterIsNotNull(name), just in this cases, not everywhere than everything will work
e
@rrader you could disable intrinsics by startup parameter, but it’s not good decision, better to find another solution. Look at this answer: https://stackoverflow.com/a/42000389/5400641 (it’s possible to configure jackson to check that you want)
r
yeap, I know, but we do not want fails on the first missing property
a
I do not think it is a good solution, or solution at all. Null safety is one of the cornerstones of kotlin and one can't allow user just to turn it off.
r
if we will be able to mark classes in order to not generate checks than this will be ok
@altavir we need this only in json mapping cases, so not everywhere
validation is done by framework, so null safety will not be affected
a
If you allow it just once, then you can't ever be sure that null safe variable is really null safe.
r
well, in Kotlin already exists 
!!
, so yes, it will be our choise
a
use a different framework? 🧌
on a more serious note, I think your framework is doing it the java way (which is obviously wrong). if you allow a 
String
to be 
null
, then you lose all of the compile-time guarantees. IMO it sounds like "Hey, lets fix the symptoms"
r
yes I agree, but I can not change the framework, it is not so simple
a
instead of kotlin classes for your DTOs, maybe use Java classes
e
as a not very good solution, you may try to create 2 dto objects with common interface, contains all properties, and on first one make all properties 
nullable
, and on second choose as needed. With this you will only needed to add mapping from one dto object, to second. But it’s possible to do it with reflection (like ModelMapper library do)
r
Why? Kotlin already have 
-Xno-param-assertions
option, why not restrict this by annotation?
a
why waste precious time of the developers to fix the symptoms of java code?
i mean if its a very common problem, they tend to fix it (e.g. 
lateinit
), but you can still create a yt-issue and see what the devs say
e
-Xno-param-assertions
is a very bad solution, you will disable all runtime checks. So you will lose early failing on errors.
r
yes, So I only want an annotation to be able to not disable all runtime checks 🙂
a
and still a null can lurk deep into your code when one part has no runtime checks 😉
r
yeap, but this is checked by framework and tests 😉
4 Views
Open in Slack
PreviousNext
Powered by