I have a question about how Kotlin manages NULL safety on comparison.
I have this code:
imageFile.addListener { _ , oldValue : File?, newValue : File? ->
run{
if(oldValue?.absolutePath != newValue?.absolutePath) loadFile()
}
}
It works fine, however if I change it to
imageFile.addListener { _ , oldValue : File?, newValue : File? ->
run{
if(oldValue!!.absolutePath != newValue?.absolutePath) loadFile()
}
}
It throws a NullPointerException and that's obvious, because when the application starts oldValue is NULL.
How Kotlin manages this comparison the first time?
Thanks for your help.
You are using safe call which avoid NullPointerException:
option is the safe call operator, written ?.
returns null if any of the properties in it is null.
Second option not-null assertion operator throws exception
The !! Operator
the not-null assertion operator (!!) converts any value to a non-null type and throws an exception if the value is null
Related
This code below throw nullpointer exception in third line. Because objectHashMap is null. But how is that possible. Its a nullable type and it can be null.
val objectsGTypeInd = object : GenericTypeIndicator<HashMap<String, Post>>() {}
val objectHashMap: HashMap<String, Post>? = dataSnapshot?.getValue(objectsGTypeInd)
val postList = ArrayList<Post>(objectHashMap?.values)
"collection == null" message writing at logcat
When you call ArrayList<Post>(null), you'll get this problem. If your objectHashMap is null, or it contains no values, you'll have a null there. The compiler isn't really complaining about you having a null, it's complaining about the fact that you're passing it to the ArrayList() constructor.
If you look at the JavaDoc for ArrayList, it states that the collection can't be null, or you'll get a NullPointerException:
/**
* Constructs a list containing the elements of the specified
* collection, in the order they are returned by the collection's
* iterator.
*
* #param c the collection whose elements are to be placed into this list
* #throws NullPointerException if the specified collection is null
*/
The problem is that objectHashMap?.values evaluates to null when:
objectHashMap itself is null or
values property is null
You’re using the safe operator ?. and this can obviously lead to null results which you shouldn’t pass to an ArrayList. You could provide a default value using the Elvis operator:
ArrayList<Post>(objectHashMap?.values ?: defaultValues)
Alternatively, an empty list can be created like this:
if(objectHashMap==null) ArrayList<Post>() else ArrayList<Post>(objectHashMap.values)
Note that in the second part, the compiler lets you use objectHashMap as a non-nullable type since you checked it in the if.
Kotlin docs state:
b?.length
This returns b.length if b is not null, and null otherwise.
Thus, you might be calling ArrayList<Post>(null) since objectHashMap: HashMap<String, Post>? is of type nullable due to the question mark at the end ?.
From the Kotlin docs about ArrayList, which link us to Java Class ArrayList<E> and the constructor you're using:
public ArrayList(Collection<? extends E> c) states:
Throws:
NullPointerException - if the specified collection is null
In lombok extension method obj.method() is a syntax sugar for SomeUtil.method(obj). It allows for obj be null.
Kotlin extensions methods are resolved statically so I assume it's the same syntactic sugar. But when I wrote
fun Any.stringOrNull() = this?.toString()
I got a warning about unnecessary safe call on non-null receiver. Does that mean I can't call extension functions on null objects like with Lombok?
You can call it on a nullable object if you define it to be an extension on a nullable type:
fun Any?.stringOrNull() = ...
Otherwise, like with any other method, you'd have to use the safe call operator.
You can create extensions on nullable receiver types. In your example, it has to be Any? instead of Any which would not allow null, see the docs:
Nullable Receiver
Note that extensions can be defined with a nullable receiver type. Such extensions can be called on an object variable even if its value is null, and can check for this == null inside the body. This is what allows you to call toString() in Kotlin without checking for null: the check happens inside the extension function.
fun Any?.toString(): String {
if (this == null) return "null"
// after the null check, 'this' is autocast to a non-null type, so the toString() below
// resolves to the member function of the Any class
return toString()
}
Be careful, for:
fun Any?.toString(): String
following behavior:
var obj: Any? = null
obj?.toString() // is actually null
obj.toString() // returns "null" string
just spent 15 very frustrating minutes before realized this...
val string: String? = "Hello World!"
print(string.length)
// Compile error: Can't directly access property of nullable type.
print(string?.length)
// Will print the string's length, or "null" if the string is null.
?. Safe Call operator for nullable receiver##
The safe call operator returns null if the value to the left is null, otherwise continues to evaluate the expression to the right, so in order to call any function on nullable receiver you need to use safe call operator after Any.(Use Any?)
Then you can check for null value of this(here this object points to receiver) inside function body.This is what allows you to call toString() in Kotlin without checking for null: the check happens inside the extension function.
fun Any?.toString(): String {
if (this == null) return "null"
// after the null check, 'this' is autocast to a non-null type, so the toString() below
// resolves to the member function of the Any class
return toString()
}
I have the following code fragment:
val foo: String? = null
foo.run { println("foo") }
I have here a nullable variable foo that is actually set to null followed by a nonsafe .run() call.
When I run the code snippet, I get foo printed out despite the fact that the run method is called on a null. Why is that? Why no NullPointerException? Why does compiler allow a nonsafe call on an optional value?
If I pass println(foo), I get a nice juicy null in the console so I think it's safe to assume that foo is actually null.
I believe, there are two things that both might be of some surprise: the language semantics that allow such a call, and what happens at runtime when this code executes.
From the language side, Kotlin allows nullable receiver, but only for extensions. To write an extension function that accepts a nullable receiver, one should either write the nullable type explicitly, or use a nullable upper bound for a type parameter (actually, when you specify no upper bound, the default one is nullable Any?):
fun List<*>?.isEmptyOrNull() = this == null || size == 0 // explicit nullable type
fun <T : CharSequence?> T.nullWhenEmpty() = if ("$this" == "") null else this // nullable T
fun <T> T.identity() = this // default upper bound Any? is nullable
This feature is used in kotlin-stdlib in several places: see CharSequence?.isNullOrEmpty(), CharSequence?.isNullOrBlank(), ?.orEmpty() for containers and String?.orEmpty(), and even Any?.toString(). Some functions like T.let, T.run that you asked about and some others just don't provide an upper bound for the type parameter, and that defaults to nullable Any?. And T.use provides a nullable upper bound Closeable?.
Under the hood, that is, from the runtime perspective, the extension calls are not compiled into the JVM member call instructions INVOKEVIRTUAL, INVOKEINTERFACE or INVOKESPECIAL (the JVM checks the first argument of such calls, the implicit this, for being null and throws an NPE if it is, and this is how Java & Kotlin member functions are called). Instead, the Kotlin extension functions are compiled down to static methods, and the receiver is just passed as the first argument. Such a method is called with the INVOKESTATIC instruction that does not check the arguments for being null.
Note that when a receiver of an extension can be nullable, Kotlin does not allow you to use it where a not-null value is required without checking it for null first:
fun Int?.foo() = this + 1 // error, + is not defined for nullable Int?
To add to what #holi-java said, there is nothing unsafe about your code at all. println("foo") is perfectly valid whether foo is null or not. If you tried something like
foo.run { subString(1) }
it would be unsafe, and you will find it won't even compile without some sort of null check:
foo.run { this?.subString(1) }
// or
foo?.run { subString(1) }
This is because the top-level function run accept anything Any & Any?. so an extension function with Null Receiver doesn't checked by Kotlin in runtime.
// v--- accept anything
public inline fun <T, R> T.run(block: T.() -> R): R = block()
Indeed, the inline function run is generated by Kotlin without any assertions if the receiver can be nullable, so it is more like a noinline function generated to Java code as below:
public static Object run(Object receiver, Function1<Object, Object> block){
//v--- the parameters checking is taken away if the reciever can be nullable
//Intrinsics.checkParameterIsNotNull(receiver, "receiver");
Intrinsics.checkParameterIsNotNull(block, "block");
// ^--- checking the `block` parameter since it can't be null
}
IF you want to call it in a safety way, you can use safe-call operator ?. instead, for example:
val foo: String? = null
// v--- short-circuited if the foo is null
foo?.run { println("foo") }
If I have a code fragment like
val myNullableString : String?
val resultingString = if (myNullableString.isNullOrBlank())
myNullDefaultString else String.format(myNullableString!!, someOtherString)
I have to use myNullableString!! in String.format() since the compiler would not be able to figure out that isNullOrBlank() includes a null-check. Is this correct or is there any way to tell the compiler that a function will infer that the instance is not null?
Kotlin 1.3 introduced a concept called contracts. From now on you can tell the compiler that a null check has been done. It has already been implemented for all necessary functions in the standard library (for isNullOrBlank() too).
So, your example would compile now without !!
val myNullableString: String? = null
val result = if (myNullableString.isNullOrBlank()) {
"default"
} else {
String.format(myNullableString, "hello") // myNullableString is smart-casted to String
}
Didn’t see any mentions that there is a way to tell such info to the compiler, but here is a workaround: having function returning null if string is empty and use let?.{} after that
inline fun String?.nullIfBlank(): String? = if (this?.isBlank() ?: true) null else this
val resultingString: String = myNullableString.nullIfBlank()?.let {
String.format(it)
} ?: myNullDefaultString
Compiler can perform smart cast from nullable type to non-nullable only after explicit check expression, like myNullableString != null
I am porting my template code to XTend. At some point I have this type of condition handling in a test case:
#Test
def xtendIfTest() {
val obj = new FD
if (true && obj?.property?.isNotNull) {
return
}
fail("Not passed")
}
def boolean isNotNull(Object o) {
return o != null
}
class FD {
#Accessors
String property
}
This works as expected as the property is null and the test will fail with "Not passed" message. But a simple change in the return type of isNotNull method to Boolean (wrapper):
def Boolean isNotNull(Object o) {
return o != null
}
fails with a NullPointerException. Examining the generated java code for this I can see that XTend is using an intermediate Boolean object expression and that is the cause of NPE. Am I missing the point of the XTend null safe operator (?.) or I can't use a method like this after the operator?
Thanks.
The operator behaves properly. The exception is thrown because of the usage of a Boolean in an if-expression, which requires auto-unboxing.
If you try the following:
#Test
def xtendIfTest() {
val Boolean obj = null
if (obj) {
return
}
fail("Not passed")
}
You will also run into a NullPointerException.
This is consistent with the Java Language Specification (https://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.8) - when auto-unboxing is required this can yield a NullPointerException:
#Test
public void test() {
Boolean value = null;
if (value) { // warning: Null pointer access: This expression of type Boolean is null but requires auto-unboxing
// dead code
}
}
Hope that helps.
Short answer: Change the second null-safe call to a regular call.
I.e. change
obj?.property?.isNotNull
to this:
obj?.property.isNotNull
Long answer:
The docs describe the null-safe operator thusly:
In many situations it is ok for an expression to return null if a
receiver was null
That means the second call in your example, property?. won't even call isNotNull if the left side of the call was null. Instead, it will return null. So the conditional "effectively" evaluates to:
if (true && null) { // causes NPE when java tries to unbox the Boolean
(By the way - the true is superfluous in this context, but I'm keeping it just in case you had another condition to check - I'm assuming you're just simplifying it to true for this example.)
If you make the change I'm suggesting, obj?.property will be evaluated, then the result will be passed to isNotNull, evaluating to this:
if (true && isNotNull(null)) {
which returns the proper Boolean object that will be auto-unboxed as expected.
A Word of Caution
In your first form of isNotNull, i.e. the one returning primitive boolean, you should actually get a warning like "Null-safe call of primitive-valued feature isNotNull, default value false will be used".
This is because you're stretching the intent of the null-safe call, which is to return null without invoking the right side method if the left side of the operator was null. But if your isNotNull returns a primitive boolean, the whole expression obviously can't evaluate to null, so Xtend uses a default instead, which is false for booleans.
To emphasize the problem in a different way - it evaluates to false without calling isNotNull - that means even if you used a method isNull after the operator, it would still return false!
The docs also mention this behavior (albeit in general terms):
For primitive types the default value is returned (e.g. 0 for int).
This may not be what you want in some cases, so a warning will be
raised by default
So I recommend always using a non-primitive return value on the right-hand side of a null-safe call. But if you're going to convert the isNotNull to a regular call as I suggested, this rule doesn't apply, and either return type is fine.