How is Java these days compared to Kotlin, comparing latest versions of both? I know Java continues to improve and take features from Kotlin but Kotlin is also improving itself.
It is the Java Virtual Machine, not Kotlin Virtual Machine.
Thus Kotlin will always be a guest language and not the target of all companies designing JVM implementations.
That is left for Google with their .NET flavour, ART + Kotlin, where Android Java plays the same role as J# did for .NET, after Microsoft had let go of J++.
Android Java is stuck in a subset of Java 17 LTS, released in 2021, hardly almost identical to mainline.
And this only happened, most likely because the Android team realised Kotlin was losing access to modern Java libraries, with ART being stuck in Java 8, so there was an update cycle for Java 11, followed by one for Java 17.
So far there are no public plans to update ART for something newer in Android 16, from the previews made available thus far, they actually also started rewriting OS components into Kotlin, it is no longer only Jetpack libraries.
It's a perpetual discussion. Java enthusiasts will generally say there is no or only a small difference, while at the same time being excited about Java getting features that Kotlin has had years before (e.g. smart casting).
In general Java is getting better but more weighed down by legacy and existing design decisions than Kotlin, so a lot of improvements from Kotlin are not possible to be made in Java.
Java is running ahead of Kotlin in a few things, mainly virtual threads which don't require black-red functions like coroutines.
I find Java 21 very pleasant, as long as you figure out how to avoid ugly things like Spring’s autowiring of dependencies.
I haven’t really given kotlin a fair try, but I find it ugly the couple times I’ve tried to work with it.
What I’m really curious about: do IntelliJ’s refactorings work as well for kotlin as Java? I find the refactoring tools make up for Java’s shortcomings as a language.
Spring is perfectly usable without `@Autowired`, at least outside of test classes. SonarQube has a rule that helps avoiding it. Just use constructor injection instead.
Constructor injection is still autowiring. Spring used to demand that you annotate constructor arguments with @Autowired but that changed some time ago.
No, it's the only sane technique to do dependency injection. And it still doesn't force you to do autowiring; you can also write a @Bean factory method for all components in the application if you really want.
Do things like inline method and inline base class work correctly? It’s not a given that IntelliJ is works correctly for Kotlin if the semantics of Kotlin are harder to analyze statically.
In my opinion the only critically missing feature in Java that Kotlin has are nullable types. It’s been proposed, but is stuck behind Valhalla.
Kotlin has a lot of other smaller features that help with conciseness. Like single line methods, but it’s still missing critical features like checked errors.
Yeah I'm hopeful for a post-valhalla future now that things are slowly rolling in. There's a lot of stuff that Brian has proposed but has been put on hold!
java is on a great trajectory now. it gets big updates. they know where they are missing on features. even without nullable types you have optional. it’s a great language for any project.
Optional is not good at all. It is not enforced by the compiler and optional itself can be null. In hot loops it can allocate like crazy. We need compiler support to enforce nullability and to get null into the type system.
In a codebase heavily reliant on Optional it can be worthwhile to install NullAway just for the benefit of banishing that particular source of null. That doesn't help with dependencies of course (unless you are certain they also use a nullability checker), and calls to those will have to be wrapped with your favorite `null -> Optional.empty()` helper function.
The pain with allocation is temporary. It is one of the candidates to become value types.
