https://kotlinlang.org logo
Title
p

poohbar

08/30/2017, 7:24 PM
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
s

supaham

08/30/2017, 7:26 PM
explicitly define type?
p

poohbar

08/30/2017, 7:26 PM
but the compiler does not force me to do so, so whats the point?
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.
s

supaham

08/30/2017, 7:27 PM
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
a

agomez

08/30/2017, 7:28 PM
it'll work with jsr305 annotations
s

supaham

08/30/2017, 7:28 PM
any quite a few others, lombok and jetbrains's of course
p

poohbar

08/30/2017, 7:28 PM
Assume the 3rd party library has no such annotations. Even Java stdlib is missing them.
What then?
s

supaham

08/30/2017, 7:29 PM
I believe some exceptions, beyond the scope of this question are made in kotlin compiler
a

agomez

08/30/2017, 7:29 PM
read the javadocs and then trust it up to date and dereference as nullable or not nullable
s

supaham

08/30/2017, 7:29 PM
In the case of Java stdlib. As for third parties, well then you'll have to explicitly define types
var res: ReturnType = someJavaFuncThatActuallyReturnsNull()
Would error if it returns null there
r

Ruckus

08/30/2017, 7:30 PM
@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?
p

poohbar

08/30/2017, 7:30 PM
No, I don't have to do anything. The compiler does not enforce it. And that's the mistake I am pointing out.
s

supaham

08/30/2017, 7:31 PM
The guy who invented null reference even regrets it himself 😂 https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions
p

poohbar

08/30/2017, 7:31 PM
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.
s

supaham

08/30/2017, 7:31 PM
@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
I believe it is much better than requiring you to explicitly specify nullsafe types with
!!
every time you make a java call
p

poohbar

08/30/2017, 7:32 PM
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?
s

supaham

08/30/2017, 7:33 PM
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
a

artem_zin

08/30/2017, 7:33 PM
@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
p

poohbar

08/30/2017, 7:36 PM
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!
Honestly, I would be happy with an IDE warning or suggestion.
👏 1
a

agomez

08/30/2017, 7:37 PM
go ahead and write your own inspection
a

artem_zin

08/30/2017, 7:40 PM
@poohbar developers were enforced to specify nullability before, it was hard to write code that used Java interop https://blog.jetbrains.com/kotlin/2014/10/making-platform-interop-even-smoother/
p

poohbar

08/30/2017, 7:42 PM
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.
a

artem_zin

08/30/2017, 7:43 PM
As far as I remember you could specify nullability or it’ll be nullable, this is basically what you want
p

poohbar

08/30/2017, 7:44 PM
MyClass.java
public class MyClass {
    public Date getToday() {
        return null;
    }
}
test.kt
fun main(args: Array<String>) {
    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.
a

artem_zin

08/30/2017, 7:45 PM
🙂 I understand, that’s exactly how it was before and not that many users liked it, so we have what we have now
p

poohbar

08/30/2017, 7:46 PM
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.
j

janvladimirmostert

08/30/2017, 7:47 PM
@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
👍 3
p

poohbar

08/30/2017, 7:47 PM
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.
j

janvladimirmostert

08/30/2017, 7:48 PM
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.
a

agomez

08/30/2017, 7:48 PM
ask someone to write such inspection in youtrack or write and publish your plugin
p

poohbar

08/30/2017, 7:49 PM
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.
j

janvladimirmostert

08/30/2017, 7:50 PM
Pure Kotlin is null-safe, it's Java that is not
a

agomez

08/30/2017, 7:50 PM
exactly
j

janvladimirmostert

08/30/2017, 7:51 PM
if you interface with C/C++ libs via JNI, you will face similar issues, you can't guarantee anything when interfacing with external languages
p

poohbar

08/30/2017, 7:53 PM
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.
a

agomez

08/30/2017, 7:54 PM
kotlin is not just java, you can transpile it to javascript, and there's also kotlin native
j

janvladimirmostert

08/30/2017, 7:55 PM
with Java you have GWT which does the toJS, same for native I believe when using LLVM
Java 2.8 or 2.9 might be closer to the right version
p

poohbar

08/30/2017, 7:56 PM
@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.
works for functions
j

janvladimirmostert

08/30/2017, 7:59 PM
@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.
a

agomez

08/30/2017, 7:59 PM
vote that issue to make it work for local variables
j

janvladimirmostert

08/30/2017, 8:01 PM
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
i

ilya.gorbunov

08/30/2017, 8:20 PM
@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()
c

codeslubber

08/31/2017, 12:46 AM
@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..
p

poohbar

08/31/2017, 1:03 PM
@janvladimirmostert How do your wrappers solve the issue noted by Ilya above?
j

janvladimirmostert

08/31/2017, 1:33 PM
@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) ?: ""
p

poohbar

08/31/2017, 1:35 PM
But what if the java lib returns a complex type with nested objects.. those could be null even if you wrap the return type.
j

janvladimirmostert

08/31/2017, 1:40 PM
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.
a

arekolek

09/05/2017, 3:25 PM
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
    }
}
d

dragas

09/05/2017, 7:08 PM
@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.
In kotlin based code, on the other hand, the warning is there.
a

arekolek

09/06/2017, 7:05 AM
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.
There’s no distinction between non-nullable and nullable properties in java.
But Kotlin treats non-annotated Java types as “platform types” and:
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.