I am really not convinced by the NPE problems argument 1 I h

Question

I am really not convinced by the NPE problems argument 1 I have rarely if ever had a Java program blow up due to NPE 2 Kotlin s protection from NPE ends whenever you use platform types Those are not solved satisfactorily IMO ``` var res = someJavaFuncThatActuallyReturnsNull res is now SomeJavaType at this point I can start passing res around and later access anything on it and get an NPE Kotlin didnt help at all ```

supaham · Answer

explicitly define type

poohbar · Answer

but the compiler does not force me to do so so whats the point

poohbar · Answer

I can now have my project completely polluted with ticking time bombs ready to throw NPE any second Any perceived null safety is now moot

supaham · Answer

I think it s to be more convenient for the java libraries If those libraries use annotations like findbugs s then kotlin automatically interprets return types

agomez · Answer

it ll work with jsr305 annotations

supaham · Answer

any quite a few others lombok and jetbrains s of course

poohbar · Answer

Assume the 3rd party library has no such annotations Even Java stdlib is missing them

poohbar · Answer

What then

supaham · Answer

I believe some exceptions beyond the scope of this question are made in kotlin compiler

agomez · Answer

read the javadocs and then trust it up to date and dereference as nullable or not nullable

supaham · Answer

In the case of Java stdlib As for third parties well then you ll have to explicitly define types

supaham · Answer

`var res ReturnType = someJavaFuncThatActuallyReturnsNull ` Would error if it returns null there

Ruckus · Answer

< poohbar> You may be the outlier on this topic considering pretty much everyone else who uses Kotlin seems to fall in love with the null safety first and foremost Maybe you just wrote much cleaner Java than most

poohbar · Answer

No I don t have to do anything The compiler does not enforce it And that s the mistake I am pointing out

supaham · Answer

The guy who invented null reference even regrets it himself joy <https en wikipedia org wiki Tony Hoare Apologies and retractions>

poohbar · Answer

Ruckus I think the null safety is a swell idea but I think it s sad that it s not consistently enforced for platform types as well

supaham · Answer

< poohbar> because it doesnt know if the type is nullable or not because those libraries did not use tools to provide metadata to methods and other features of the language

supaham · Answer

I believe it is much better than requiring you to explicitly specify nullsafe types with ` ` every time you make a java call

poohbar · Answer

What All the compiler needs to know is this type is not coming from Kotlin and there are no annotations to help me I must ask the user to provide the type explicitly Are you saying this could not be done

supaham · Answer

Oh i see Well I m sure there s further reason to why it wasn t done Maybe they decided it would interfere with their dynamic property types or whatever they re called

artem_zin · Answer

< poohbar> it used to be enforced but it was too much of a hassle to work with especially when you re just starting to migrate Java project to Kotlin and have to have lots of Java interopish code

poohbar · Answer

Artem was it really the way I am talking about Enforcing explicit types on vals and vars for java calls would completely lock down the null safety across the whole project The cost seems very minimal to me I think what you are talking about was when they tried to infer null non null type from the annotations or by analysis I am saying make the dev specify it

poohbar · Answer

Honestly I would be happy with an IDE warning or suggestion

agomez · Answer

go ahead and write your own inspection

artem_zin · Answer

< poohbar> developers were enforced to specify nullability before it was hard to write code that used Java interop

poohbar · Answer

Artem maybe I am not making myself clear but this is not what I am talking about They say so Kotlin has treated Java types as nullable This is not what I want

artem_zin · Answer

As far as I remember you could specify nullability or it ll be nullable this is basically what you want

poohbar · Answer

MyClass java ``` public class MyClass public Date getToday return null ``` test kt ``` fun main args Array lt String gt val mc = MyClass val today = mc today today day print BOOM NPE ``` There are no warnings no IDE suggestions nothing I am saying that the `val today` should not be allowed without explicit type That s all

artem_zin · Answer

slightly smiling face I understand that s exactly how it was before and not that many users liked it so we have what we have now

poohbar · Answer

Ok I will file a feature request to at least add the IDE warning Because this makes the whole NPE safety absolutely moot and I am surprised more people don t see it I have yet to write Kotlin program that would not interact with Java

janvladimirmostert · Answer

< poohbar> if you don t mix Java and Kotlin the null safety is solid We write everything from scratch and the thing for which we do use external libraries we write Kotlin wrappers for which does the null checks to and from the Java code

agomez · Answer

< poohbar> <http www jetbrains org intellij sdk docs tutorials code inspections html search=inspection>

poohbar · Answer

I understand but you can t ask me to write a wrapper for every Java lib I use just because of null safety That is a lot of work that could be done by the compiler

janvladimirmostert · Answer

as I said the only Java lib we currenlty use is VertX and we have extension methods on top of VertX which does a lot of things including making sure that we don t get hit by NPE

agomez · Answer

ask someone to write such inspection in youtrack or write and publish your plugin

poohbar · Answer

Sure I guess your use is different For me Kotlin is interesting especially because of its super smooth interop with Java and all the Java libs I can use I think we should not advertise Kotlin as a null safe language until this gaping hole is fixed

janvladimirmostert · Answer

Pure Kotlin is null safe it s Java that is not

agomez · Answer

exactly

janvladimirmostert · Answer

if you interface with C C++ libs via JNI you will face similar issues you can t guarantee anything when interfacing with external languages

poohbar · Answer

Like it or not Kotlin is very much a Java 2 0 and is heavily Java oriented It even reuses the same collections I think the platform type situation should be improved

agomez · Answer

kotlin is not just java you can transpile it to javascript and there s also kotlin native

janvladimirmostert · Answer

with Java you have GWT which does the toJS same for native I believe when using LLVM

janvladimirmostert · Answer

Java 2 8 or 2 9 might be closer to the right version

poohbar · Answer

< abreslav> said in the comment regarding the M9 release that some warning will be included later yet in the simple example above I get zero warnings and I am free to pass the val around until it blows up with a million dollar loss later down the line

poohbar · Answer

agomez · Answer

agomez · Answer

works for functions

janvladimirmostert · Answer

< poohbar> if you re running mission critical code and using Java libs in Kotlin code it s worth writing wrappers You re probably only using a few dozen Java methods so you can have a single class that with 50 lines of code that calls java methods and sanity checks the results coming back

agomez · Answer

vote that issue to make it work for local variables

janvladimirmostert · Answer

have written 120k lines of Kotlin over the last 4 months in one project which does make use of several Java libs a couple of wrappers and have not had a single NPE

ilya.gorbunov · Answer

< poohbar> Note that requiring explicit types for variables when assiging values of platform types won t help you if you do not use intermediate variable ``` val mc = MyClass mc today day print ```

codeslubber · Answer

< poohbar> have you looked at how Scala deals with nullity does not have this problem but it is different I did not know about this as I have been doing pure K Interesting

poohbar · Answer

< janvladimirmostert> How do your wrappers solve the issue noted by Ilya above

janvladimirmostert · Answer

< poohbar> by assuming that the result coming back from Java can always be null and checking for it Simple example ``` fun String indent String = StringUtils indent this ``` or alternatively ``` fun indent input String String = StringUtils indent input ```

poohbar · Answer

But what if the java lib returns a complex type with nested objects those could be null even if you wrap the return type

janvladimirmostert · Answer

do you have control over that Java class If so use the NotNull annotations If not then your options are to wrap the methods and clone the data into Kotlin objects not very efficient or be forced to null check everything on that object the whole time We don t have any data classes in Java so this has not been an issue for us

arekolek · Answer

It would be nice if Kotlin warned you when when assigning platform types to non null properties Like for example ```class ExampleActivity Activity lateinit var array IntArray override fun onCreate savedInstanceState Bundle super onCreate savedInstanceState array = intent getIntArrayExtra array throws IllegalStateException getIntArrayExtra array must not be null ```

dragas · Answer

< arekolek> There s no distinction between non nullable and nullable properties in java As far as I remember docs for `Intent getExtra` states that result MAY be null if it s not there thus you should just know your API

dragas · Answer

In kotlin based code on the other hand the warning is there

arekolek · Answer

gt In kotlin based code on the other hand the warning is there What do you mean by that Do you mean assigning nullable type to non nullable That s an error not a warning

arekolek · Answer

gt There s no distinction between non nullable and nullable properties in java But Kotlin treats non annotated Java types as platform types and gt When a platform value is assigned to a Kotlin variable we can choose the type that we expect If we choose a non null type the compiler will emit an assertion upon assignment This prevents Kotlin s non null variables from holding nulls What I m saying would be nice is that if there was a warning not an error when assigning platform to non null Or at least some Lint check for that That way you could for example use the ` ` operator to mark that place as safe or treat it as nullable instead depending on the API you are using