3 ms·

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

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.

dtech 2y ago
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.
pjmlp 2y ago
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++.
- msgilligan 2y ago
  > Thus Kotlin will always be a guest language If you a writing libraries for the JVM, Java is preferred to Kotlin because it does not drag along a standard library dependency. To be fair there is Kotlin Multiplatform where this is not the case. https://kotlinlang.org/docs/multiplatform.html https://kotlinlang.org/docs/multiplatform.html
  - pjmlp 2y ago
    Yes, and it has the issue of having its own way of #ifdef, because not all platforms offer the same semantics. It is no different than writing C code across UNIX, Windows, mainframe, microcomputers and embedded, consoles, and somehow work across all of them.
- samus 2y ago
  Android Java is almost identical to mainline Java nowadays.
  - pjmlp 2y ago
    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.
fiddlerwoaroof 2y ago
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.
- dtech 2y ago
  IntelliJ is excellent for Kotlin, on par or better than for Java. It's unsurprising as Jetbrains basically uses Kotlin to sell IntelliJ.
  - fiddlerwoaroof 2y ago
    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.
- Clamchop 2y ago
  > avoid ugly things like Spring's autowiring of dependencies. This seems awfully close to "avoid Spring" to me, heh. Though, I've grown rather fond of Spring Boot over time, but I've gathered that's not exactly the popular consensus.
  - fiddlerwoaroof 2y ago
    > This seems awfully close to "avoid Spring" to me, heh. Exactly :)
  - samus 2y ago
    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.
    - 2y ago
vips7L 2y ago
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. Pick your poison.
- foolfoolz 2y ago
  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.
  - vips7L 2y ago
    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.
    - samus 2y ago
      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.
- kasperni 2y ago
  > It’s been proposed, but is stuck behind Valhalla. It is actually a central part of Valhalla now [1]. [1] https://openjdk.org/projects/valhalla/ https://openjdk.org/projects/valhalla/
  - vips7L 2y ago
    Yes that qualifies as "stuck behind valhalla" for me. Valhalla... truly is Valhalla. Will we ever see it?
gavinray 2y ago
I write server-side Kotlin at $DAYJOB, for several years. Kotlin used to be a marked improvement over Java. A series of large language changes, starting with JDK 16, have leveled the playing field somewhat. Nowadays Java has Record types (data classes), sealed interfaces, pattern matching, etc. Java's pattern matching actually got the ability to use guard clauses in match expressions BEFORE Kotlin implemented it: https://kotlinlang.org/docs/whatsnew21.html#guard-conditions-in-when-with-a-subject https://kotlinlang.org/docs/whatsnew21.html#guard-conditions... If Java had the ability to write free-floating functions outside of classes, and to declare function types succinctly like: (String, Number) -> Number It'd probably be on-par with Kotlin for me.
- invalidname 2y ago
  Check out Manifold project. It might not be for you since it's a bit of an aftermarket hack. But it's open source and has some crazy innovative ideas.
dionian 2y ago
I wouldn't really use either, unless Scala was not viable. Both feel like watered down versions of what I can do in Scala, which has little downside
- vips7L 2y ago
  Scala is not viable. They continue to make breaking changes and the tooling ecosystem can’t keep up with the language changes. It’s a giant mess.

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.

dtech 2y ago

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.

pjmlp 2y ago

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++.

msgilligan 2y ago
> Thus Kotlin will always be a guest language If you a writing libraries for the JVM, Java is preferred to Kotlin because it does not drag along a standard library dependency. To be fair there is Kotlin Multiplatform where this is not the case. https://kotlinlang.org/docs/multiplatform.html https://kotlinlang.org/docs/multiplatform.html
- pjmlp 2y ago
  Yes, and it has the issue of having its own way of #ifdef, because not all platforms offer the same semantics. It is no different than writing C code across UNIX, Windows, mainframe, microcomputers and embedded, consoles, and somehow work across all of them.
samus 2y ago
Android Java is almost identical to mainline Java nowadays.
- pjmlp 2y ago
  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.

fiddlerwoaroof 2y ago

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.

dtech 2y ago
IntelliJ is excellent for Kotlin, on par or better than for Java. It's unsurprising as Jetbrains basically uses Kotlin to sell IntelliJ.
- fiddlerwoaroof 2y ago
  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.
Clamchop 2y ago
> avoid ugly things like Spring's autowiring of dependencies. This seems awfully close to "avoid Spring" to me, heh. Though, I've grown rather fond of Spring Boot over time, but I've gathered that's not exactly the popular consensus.
- fiddlerwoaroof 2y ago
  > This seems awfully close to "avoid Spring" to me, heh. Exactly :)
- samus 2y ago
  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.
  - 2y ago

vips7L 2y ago

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. Pick your poison.

foolfoolz 2y ago
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.
- vips7L 2y ago
  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.
  - samus 2y ago
    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.
kasperni 2y ago
> It’s been proposed, but is stuck behind Valhalla. It is actually a central part of Valhalla now [1]. [1] https://openjdk.org/projects/valhalla/ https://openjdk.org/projects/valhalla/
- vips7L 2y ago
  Yes that qualifies as "stuck behind valhalla" for me. Valhalla... truly is Valhalla. Will we ever see it?

gavinray 2y ago

I write server-side Kotlin at $DAYJOB, for several years. Kotlin used to be a marked improvement over Java. A series of large language changes, starting with JDK 16, have leveled the playing field somewhat. Nowadays Java has Record types (data classes), sealed interfaces, pattern matching, etc. Java's pattern matching actually got the ability to use guard clauses in match expressions BEFORE Kotlin implemented it: https://kotlinlang.org/docs/whatsnew21.html#guard-conditions-in-when-with-a-subject https://kotlinlang.org/docs/whatsnew21.html#guard-conditions... If Java had the ability to write free-floating functions outside of classes, and to declare function types succinctly like: (String, Number) -> Number It'd probably be on-par with Kotlin for me.

invalidname 2y ago
Check out Manifold project. It might not be for you since it's a bit of an aftermarket hack. But it's open source and has some crazy innovative ideas.

dionian 2y ago

I wouldn't really use either, unless Scala was not viable. Both feel like watered down versions of what I can do in Scala, which has little downside

vips7L 2y ago
Scala is not viable. They continue to make breaking changes and the tooling ecosystem can’t keep up with the language changes. It’s a giant mess.