You just need to go checking every now and then the gerrit AOSP checkins, they cherry pick stuff from OpenJDK, every version gets a little piece.
Then they use this half baked support to sell Kotlin versus Java, and cleverly never compare Kotlin to the actual Java versions.
Modern versions are not as bad (to me) you can use val for type inferring. If irc they are implementing stuff similar to scala.
It's used quite a lot in enterprise as well.
Note: by no means I'm a Java dev, I learnt to hate it a little less.
Maybe data classes? That's not a game changer to me.
Coroutines? Loom will be better.
Nullable references? This might be worth it, but in my experience Optional<T> is enough.
And you get all that even if you have to target old JVM versions for some reason.
Regardless in kotlin you can simply do:
val s: String? = null
return s as String
val s: String? = null
!!s.trim()
What you're arguing is a false equivalence. In practice null safety isn't a problem when developing in Kotlin while it is a big problem in Java.
Valhalla has now been coming since 2014, so I would not expect it to help any software project in the next two years or so.
Experimental builds are available.
Surely using nullable annotations is more typing than ! or ?, but that is about it, no need to change languages.
> Surely using nullable annotations is more typing than ! or ?
That's Java's answer to many things but it seriously hurts readability (among other things).
I don't want to scroll over pages of getters and setters with annotations. Simple and common things should be expressible succinctly.
> but that is about it, no need to change languages.
Null safety is such basic need that it needs to be part of a modern high level language.
Not everything needs getters and setters, it is just cargo cult generating them blindly.
Also Java has records now, but you aren't going to get them on Android anytime soon.
Static analysis like PMD is also a basic need, not using something like Sonar as part of a CI/CD is just being careless.
> Not everything needs getters and setters, it is just cargo cult generating them blindly.
JavaBean spec (with getters and setters) is actual standard. It's purely theoretical argument that you don't have to use them while in reality they are used always and everywhere and any PR without them would be shot down immediately.
Setters/getters are just one example of Java's boilerplateness.
> Static analysis like PMD is also a basic need, not using something like Sonar as part of a CI/CD is just being careless.
Yes, but I want that feedback during coding and not in CI/CD. Yeah, I can set it up in IDE, but that's more configuration, more things to break up, more team wide standards. Why not just use Kotlin?
I'm no Java hater, I code Java for most of the day professionally. But why pretend that it's perfect? It's 25 years old with unfixable mistakes built in and ripe for replacement.
Sounds like a strict "your company" problem. No one needs to use the JavaBeans spec. It's fully optional.
> Yes, but I want that feedback during coding and not in CI/CD. Yeah, I can set it up in IDE, but that's more configuration, more things to break up, more team wide standards. Why not just use Kotlin?
You make a very weak case here for Kotlin since you need a static analyzer anyway (e.g. Detekt).
> I'm no Java hater, I code Java for most of the day professionally. But why pretend that it's perfect? It's 25 years old with unfixable mistakes built in and ripe for replacement.
No one pretends Java is perfect. For many projects I like using Kotlin. But there's also substantial investment in Java and "I have to type a bit less" is usually not enough to justify using Kotlin.
Your company - maybe I've been working in the wrong companies in the past 15 years, because Java's setters and getters have been used everywhere. Also look into some open source projects - how often do you see direct access to (non-final, non-package private) instance variables? Can't really recall a single case. For a good reason - exposing field access on a public interface violates encapsulation.
> You make a very weak case here for Kotlin since you need a static analyzer anyway (e.g. Detekt).
Of course static analyzer is necessary. That does not invalidate the claim that null safety guaranteed by a compiler is much faster/more effective.
> "I have to type a bit less" is usually not enough to justify using Kotlin.
Type less is a small price in typical large scale project. The big win is better readability since you don't have to scroll over tons of boilerplate or artificial abstractions caused by Java's rigidness.
Besides that NPEs are still happening in production all over the world so something is obviously "not ideal".
And when they become available, Java will have them on day one, while Kotlin who knows, specially when it needs to stay compatible with ART.
Kotlin designers will have eventually to face the reality that they are either an Android only language, or that Kotlin multi-platform will need to differentiate between what is supported on JVM and ART.
Check out inline functions and reified generics, too.
There's some compelling stuff there.
What I really wanted with regards to that feature was a textbuffer that can accept arbitrary fragments and translate those to Kotlin without committing anything to disk. But it has been a few years, I should check back on that
I'm probably ignorant here. I haven't coded in Java for 5+ years.
People like to talk and bash Oracle, but no one else, including Google bothered with Sun assets, and the community on their own would never made the improvements that Oracle has made in the last 15 years, if the way of Python and Ruby are any indication of how runtime improvements get made.
There was no way of knowing the farmer who'd buy the cow would claim goat milk infringes cow-milk protein IP (apologies for stretching the metaphor beyond breaking)
Of course in hindsight buying Sun would have been better for Google.
What about go-lang and dart?
Dart is not popular.
From my point of view, Google chose not to buy Sun because they hoped that Sun would just burn to the ground and as such, they would get away with the way they approached the whole situation.
On the other hand if Google had bought Sun, we would still most likely be stuck with Java 6 and just runtime improvements, if at all. If Go and Dart are any examples to go for.
It isn't even as if they don't have their own languages.
C++, Dart, Go, just pick one and provide a migration path.
Don't sell Java compatibility and promise that even with #KotlinFirst, Java and C++ are still relevant for Android. As they did at Google IO 2019.