I write a lot of Kotlin code but still tend to use Java a lot. All of the features you mention are not really an advantage for Kotlin anymore.
Java has had tools to deal with nulls for a long time, we tend to assume everything is non-null unless annotated with `@Nullable` and let tools check correct usage at compile time... data classes are very similar to Java 16's records. Type-inference since Java introduced `var` is pretty much on-par with Kotlin.
Some people have already started talking seriously about Kotlin now just adding friction, as you need to keep updating its version and the Gradle plugin (which is not compatible with some versions of Gradle if you're stuck with some old Gradle plugins). Java 17 should probably stabilize sealed classes, which is one of the biggest advantages of Kotlin at the moment... to be honest, even though I've always been a proponent of Kotlin, I am not nearly as enthusiastic now as I used to be about it.
If I remember correctly, it's fairly easy to use @Nullable and still end up with nulls there, even without an IDE warning. I'll have to double check to see if I can still reproduce that.
Value classes cannot provide the performance/memory flatness that Valhalla will bring though. So I'm not really sure what benefit does "values classes" bring. Just to make sure, you are talking about the inline class which is just a wrapper around single property?
"value class" is the next step for inline classes. They are going to behave very much like Swift's struct and its "mutating methods". And they are going to be "Valhalla ready" so we'll get the performance improvements automatically when it lands.
In a sense, they are an upgraded data class with a much more precise and controlled form of mutation. Rather than a `var` field meaning the object will mutate in-place, it will basically automatically call a kind of (implicit) "copy()" method. Further, you may only mutate these `var` fields inside of class methods that are marked with a new keyword: `mutating`.
Read through the KEEP. It's pretty interesting stuff. At first it kind of rubbed me the wrong way, but the more I thought about it, the more excited I got about it- especially after thinking about how Swift does it and it works well there.
Well Checker framework to check nulls will limit you to Java 11 or earlier, at least until sometime after Java 17 lands. Also it is a constant pain having it guess wrongly about map value nullability based on key provenance which its not really smart enough to track, and it gets some Java api nullabilities wrong which need correcting here or there at annoying times. Better than nothing but nowhere near as good as proper language support IMO.
We don't use Checker, we tried it and it was too buggy/complex. We use IntelliJ itself to do the checks (so they don't run on every compilation, but they do run every time you change something) - you can configure it to treat null issues as errors instad of warnings. This is of course not 100% but it doesn't need to be, tests and code-review tend to catch the remaining places where we forgot to check for null.
NullPointerException is really rare in our codebase which is a few million lines of code (something like 80% Java, 20% Kotlin), so I wouldn't call it a major issue or even a minor issue.
At work, everyone has the choice to write code in either Java or Kotlin and most people, most of the time, stick with Java, so the percentage of Kotlin code is not increasing, it's mostly stable lately.
> Java has had tools to deal with nulls for a long time, we tend to assume everything is non-null unless annotated with `@Nullable` and let tools check correct usage at compile time...
Oh yeah, nothing like creating Frankenstein's monster instead of using a tool that was designed for the purpose. And no, it's not the same. You'll never beat Kotlin compiler , no matter how many annotation you use - you will always miss something.
> data classes are very similar to Java 16's records.
You mean Java 16's records are similar to data classes, since those were first.
> Type-inference since Java introduced `var` is pretty much on-par with Kotlin.
Not even close. Can't use it outside of functions, clunky final var instead of val.
> Some people have already started talking seriously about Kotlin now just adding friction, as you need to keep updating its version and the Gradle plugin (which is not compatible with some versions of Gradle if you're stuck with some old Gradle plugins).
My favorite kind of people. 'Some'.
> Java 17 should probably stabilize sealed classes, which is one of the biggest advantages of Kotlin at the moment...
Nice!
Let's wait until you'll upgrade to Java 17 while Kotlin has everything already and much more with compilation to JS and native in the future.
You can only assume non-null for your own code though. The java ecosystem of 3rd-party libraries will give you nulls, and most of the time won't include nullability annotations.
var is a nice step, but encourages mutability since it's not final by default.
Java has had tools to deal with nulls for a long time, we tend to assume everything is non-null unless annotated with `@Nullable` and let tools check correct usage at compile time... data classes are very similar to Java 16's records. Type-inference since Java introduced `var` is pretty much on-par with Kotlin.
Some people have already started talking seriously about Kotlin now just adding friction, as you need to keep updating its version and the Gradle plugin (which is not compatible with some versions of Gradle if you're stuck with some old Gradle plugins). Java 17 should probably stabilize sealed classes, which is one of the biggest advantages of Kotlin at the moment... to be honest, even though I've always been a proponent of Kotlin, I am not nearly as enthusiastic now as I used to be about it.