I got it to work with a java class. When I converted that to kotlin it broke so I guess I'll just write the data objects in Java for now.

I'm trying to read some JSON using Gson, and have a line

gson.fromJson<Map<String, Any>>(jsonString)

this worked all day yesterday. Now today I am seeing

java.lang.IllegalArgumentException: Either none or all type parameters can be wildcard in java.util.Map<java.lang.String, ?>

. I am pretty sure nothing changed, so I have no idea why it's suddenly broken. Is a

Map<String, Any>

unacceptable?

And now it's working again. 😐

@untwisted: I'm using the new Android studio which only rebuilds the parts of the app that it thinks have changed but I get the impression that this doesn't work that well (It doesn't notice when I change annotations). Try rebuilding the whole app and see if that helps.

I've tried a full rebuild. I'm seeing this behavior on two different machines as well. 😕

Why do you need a Map<String,Any> ?

rednifre: The json object is a mapping of strings to values of different types

Is it possible to mark the whole Kotlin script (aka *.kts) as Serializable?

@untwisted: What, you mean like { "bla": 5, "foo":"bar" } ? In that case, you can parse that as an object, i.e. data class Thing(var bla: Int, var foo: String)

rednifre: I ended up reading it as a Kotson

JsonObject

. I guess I'm just confused why the

Map<String, Any>

doesn't work sometimes.

Since using kotlin I try to avoid nulls more than before. Now I wonder whats better for a DAO if an object is not found. Returning null or throwing an exception? What do you think

I've been using nulls and returning default values if a null is encountered.

@danijoo: i'd do it that way: if you always expect to get an object, throw an exception. if it is possible that you won't get an object, return null

@bsideup: you might want to resurrect #C0BT46EL8

Say I have this variable:

val foo: String?

Is the only way to run some code if foo is not null this:

if (foo != null) {
  bar(foo)
}

where:

fun bar(x: String)

I was hoping for some sort of

map

operation on

foo

like an optional.

You mean like

foo?.let { bar(it) }

?

@Ruckus: That’s it…thanks! I don’t know how I missed that in the docs. 😞

Useful for some common use cases

@Ruckus: Thanks!

np

Btw, feel free to send PRs for documentation! You guys sometimes know better what’s missing 🙂

@orangy: It’s there…I just totally missed it. 🙂

Thanks for all of the work on Kotlin. I’m telling everyone I know about it!

Aren’t calls to Java APIs automatically nullable? Have I just discovered a bug?

// automatically non-null
val handler = Thread.getDefaultUncaughtExceptionHandler()
// no warning, everything compiles, crashes at runtime
handler.uncaughtException(thread, throwable)

// alt + enter -> "specify type explicitly" suggests nullable type
val handler: Thread.UncaughtExceptionHandler? = Thread.getDefaultUncaughtExceptionHandler()
// Error: Only safe (?.) or non-null asserted (!!.) calls are allowed on a nullable receiver of type Thread.UncaughtExceptionHandler?
handler.uncaughtException(thread, throwable)

Why does

specify type explicitly

change the type?

is the smart cast to “Thread.UncaughtExceptionHandler” in the first line wrong?

@passsy: you might want to read this: https://kotlinlang.org/docs/reference/java-interop.html

Ok, got it. Is there a shorter way to force a nullable type?

val handler: Thread.UncaughtExceptionHandler? = Thread.getDefaultUncaughtExceptionHandler()
// shorter
val handler = Thread.getDefaultUncaughtExceptionHandler() ?: null