I didn't mind Java when the comparisons were to C++, Ruby, and Python. I can not find a reason to go back after Scala (which seemed to fail due to being indiscriminate) and especially Kotlin
Kotlin has always had smart-casting in if and when (sort of switch) expressions, which are strictly more powerful than the current version of Java "pattern matching". Both don't do de-structuring which I would consider a basic requirement for pattern matching, but at least Kotlin didn't call it pattern matching.
Of all languages the only one it's trying to catch up to (and in places outran) is C#
With many others it doesn't compete because it would need a from-scratch rewrite of the runtime (Erlang/Elixir), or a from-scratch redesign of the type system (Rust, perhaps Swift).
A hoarder may have much more furniture than I do, but if I buy a sofa it doesn't mean I'm trying to catch up to the hoarder (who has five). Java isn't trying to catch up for the simple reason that we don't want it to have all the features Kotlin does; in fact, we're trying very hard to avoid that (not to mention that we have yet to adopt a single Kotlin feature; our features usually take a different form, even though Kotlin, Java, and many other languages often rely on the same inspiration, which is usually the ML language). That's because some languages aim to be feature-rich while others aim to be more minimal. Both are likely to accumulate features over time, but at very different rates (we'll hold off on features for years until we're satisfied that their value justifies the added complexity to the language, as keeping that relatively low is very important to us).
If you like a richer language, the Java platform offers you options, but many people prefer smaller languages (the number of Java Platform developers who use the Java language has remained pretty much at a constant ~90% for the past 15 or more years), but we're aware that a non-tiny minority of developers prefer richer languages, and so we accommodate them, too. Either way, 95% of the JDK is runtime (standard library and the JVM) and tooling, and you'll enjoy it regardless of which frontend language you prefer.
> Both are likely to accumulate features over time, but at very different rates (we'll hold off on features for years until we're satisfied that their value justifies the added complexity to the language, as keeping that relatively low is very important to us).
This strategy will still navigate Java into a random local optimum like it happened with other languages (that value backward compatibility), just more slowly. The greedy algorithm does that. Even if you do it slowly and you are extra careful that each step indeed betters the language.
Of course, invoking 'there are two kinds of languages: one that people complain about and one that nobody uses', there are two kinds of language designs: one that is perfectly consistent and one that has had contact with the real world.
The issue is that it's hard to predict how certain features will be misused and even harder to remove a harmful feature from a language. That's why Java goes slow. (Although I think there's too much pussyfooting around string interpolation. But I also think too much type inference makes the code harder to read.)
Everything comes to an end eventually, and there's no strategy to avoiding it. But not trying to adapt to real changes in the environment could certainly be a recipe to hasten that end. And yes, we do really try and make sure that any change we make is more than worth it.
But if in 2026 Java is the third or second most popular language in the world overall and the #1 choice large applications that are both performance-sensitive and need to be maintainable, but is it possible that in 20 years, despite our best efforts, Java will decline sharply, perhaps even to the point of being only as popular as, say, Go is today? Sure.
> not to mention that we have yet to adopt a single Kotlin feature; our features usually take a different form, even though Kotlin, Java, and many other languages often rely on the same inspiration, which is usually the ML language
This seems disingenuous at best, or it's a symptom that I've noticed as a user more often that your JDK team seems to have blinders on and dismisses/ignores most other languages even if feature have proven themselves 10 times over.
There's several features Java added or is trying to add, usually 5-10+ years later than Kotlin, and that's ignoring Scala:
* Local type inference
* Switch expressions
* Records, although I found them barely usable because there is no copy() method or with-ers
* String templates unsuccessfully
* A very stripped down version of smart-casting with switch pattern matching
I'm sure there's tech-debt and esoteric compatibility concerns which make evolving Java hard, but from a developer's perspective it's just glacial to evolve and the result is weaksauce.
Local type inference, records, and switch expressions (alongside lambdas and generics) are all ML features, as every language designer will tell you (and Java did them quite differently from Kotlin). All of them, by the way, were well known to Java's original designer in the nineties, it's just that they thought it will be a while until mainstream programmers are ready for them, so their adoption in Java is best postponed.
BTW, even if you're not aware of ML's extraordinary influence on most programming languages, surely you're aware there are competitors to Java with analogous features that are far bigger than Kotlin.
As for string templates, our intent is not to have a feature simiar to what Kotlin offers. We obviously look at all languages regardless of popularity, but in that case, as we did in the case of virtual threads or records, we'll probably say, no, that's not what we want, to Kotlin's approach (even the Preview that we pulled was nothing like Kotlin's approach).
> I'm sure there's tech-debt and esoteric compatibility concerns which make evolving Java hard
Backward compatibility is rarely a hindrance at all. People just talk about it a lot because most organisations consistently say that backward compatibility is much more important to them than any language feature, but it's not all that hard to maintain.
> but from a developer's perspective it's just glacial to evolve and the result is weaksauce.
I find that statement hard to reconcile with the fact that the only languages as popular as Java or more are JS/TS and Python, while all the languages that are not "weaksauce" from "a developer's perspective" are doing far, far worse than Java. There has never, ever, been any sort of consensus among developers on the right set of features, and there have always been developers who prefer more features and those who prefer less. It's perfectly fine to be on one side or the other or even to say, "yes, I'm in the minority, but I still think I'm right", but I find it strange to claim to represent "the developer's perspective" when your preferences are mostly associated with languages that are doing worse rather than better.
You're driving java feature set with great expertise. It is hard to complain about it.
I know it is not a technically marvelous thing, it's not a high priority either...but the only thing I'd want differently is lot more syntactic sugar that reduces common boilerplates/actions/patterns to simple one liners.
However, with AI writing most of the code now, I now doubt the importance.
What I like about Java is that it is a deliberate late-mover language. It doesn't go for the latest shiny thing but looks at what features have proven themselves in other languages.
I can't help but to be a little sobered by the promises of Kotlin and C#. They look great on the surface, but once you have more complicated code to work on they tend to show warts quite fast.
Java is remarkably consistent and really doesn't have any sharp edges. Even with generics and type erasure, I found myself fighting the language semantics in C# way more often than Java.
I personally enjoy Kotlin. There are potential warts with it, but those exist with other languages.
That said, Java taking it's time and observing the playing field is a huge benefit. And now that they've been slowly delivering new language features, it's really made it pretty nice flow of powerful well thought out extensions each release. There hasn't been one of the new features that I think missed the mark.
Java still inexplicably doesn't have first-class support for string interpolation/templates. They were slated to add it in Java 23, but they removed it from the preview and it hasn't been seen since.
Honestly, I still write a lot of perl, and while interpolation is nice and good to have for simple things, I find myself using sprintf more and more in production code, especially in the cases the examples always show off, such as needing to alter the variable, add two together, etc. I assume those are just shown to illustrate you you can do that, and not imply you should, because commonly using arbitrary code execution within interpolation is something I'd feel compelled to beat out of my coworkers if I encountered it regularly.
The point of (sane) string interpolation is that it runs at compile time, which helps prevent people from inventing crazy template systems at runtime. And you automatically get things like safe SQL queries with parameter binding instead of injection vulnerabilities.
Syntax sugar still matters if you need to review the code. It was always about reading, not writing. Actually macros are even more powerful with LLMs. Metaprogramming has always been difficult for many (most?) programmers, but LLMs have no issue with it, and it's mostly doing the kinds of manipulations where as long as it compiles, it's correct, so you don't really need to review it in the same way.
The LLM itself is the metaprogramming, eventually we will be getting executables directly, the dream of previous AI Summers might finally materialise, with all the implications for the victims of software factories automation.
Pretty sure it’s the other way around: Kotlin was implemented on the JVM and that’s its primary target, and got a native implementation later for folks that don’t want to run a JVM.
A subset of Kotlin has a native backend, not good enough to power JetBrains products, which still require Java Virtual Machine.
It is so good, that JetBrains themselves rather use Rust or C++ for native code libraries on their IDEs, and not officially supported on the Android NDK.
Sort of? The kotlin standard library yes, but it’s pretty rare to write an app with only the standard library. It feels like you’re dismissing the Java interop as a secondary benefit, but for most uses of Kotlin it’s probably more important to project success than the language itself. So I think it’s accurate that without the JVM Kotlin would be essentially dead.
> dismissing the Java interop as a secondary benefit
I mean, I don't really care about any of that. I was just responding to the (likely unserious) technical critique that there is no Kotlin VM. As for whether Kotlin as a language would be popular without the JVM, that's a different question.
Nope, the JVM is the main platform, and also used for Android development, which by the way, still mostly uses Android Java on the platform code.
Kotlin Native came later, its memory model was incompatible with Java, thus breaking portability for libraries between JVM and Kotlin Native, thus Jet Brains had to reboot Kotlin Native memory model.
Currently it is mostly used to port Android code into iOS apps, hardly something that even JetBrains could show off running their IDEs on top off, nah, they still need the JVM.
Kotlin feels like it's having an identity crisis. The gap between the two languages continues to decrease. Kotlin is trying to be server-side, Android, but also every other platform (KMP). Feels like everything is brand new and also deprecated at the same time, always moving on to something new.
Maybe Roman really was the soul and it lost its touch without him?
I guess in the age of AI it doesn't matter since a few years from now, if you change your mind, you can just ask Jeeves to one-shot rewrite it back to Java.
Until Java fixes its type system to add nullable types (and not in that ridiculous tri-state nullability method that one JEP proposes), Kotlin will be several steps ahead of Java.
I can speak from experience that Fable 5.1 still writes code that compiles and usually runs fine but throws null pointer exceptions in reasonable edge cases.
I would definitely trim like 20% off scala, but I think slow compile times were the main reason. To a much lesser degree but sbt being one of the first things you deal with when learning the language didn't help.
If you put a gun to my head and tell me you can't write in kotlin, you must choose either Java or Scala - for a small project I think I choose modern Java. If you tell me I need to choose for a large cross team and mission critical project - I think I take the bullet.
Still, I have a soft spot in my heart for scala, learned a lot from it.
This comment has major 2018 vibes. Most enterprises I know have have migrated back to mainline Java. We'll see if this changes again LLM era, now that prioritizing the talent pool is less important and the friction of migrating stacks is much reduced.
I love how far Java has come. I still prefer TypeScript since I do a lot of frontend work and prefer to use the same language across the stack.
With the said, you can do exhaustive pattern matching in TypeScript! https://github.com/gvergnaud/ts-pattern
Java also has recursive patterns and (maybe still in preview) literal patterns: `switch (x) { case A(B(true, var c)) -> f(c); }`
Scala punching the air rn
Sigh, I so very miss writing Scala.
I still write Scala. But not sure for how long. I swear, it's such a joy to write code in Scala.
It's like French poetry.. So much elegance. An no effect system BS. Just like Martin Odersky intended it to be!
Curious what you meant about the effect system BS?
I'm assuming they mean Scala doesn't have the tortured Haskell IO monad.
>it's such a joy to write code in Scala.
Yes, but also a bit of a torture to read code in it..
Java continues to try and catch up to Kotlin https://kotlinlang.org/docs/sealed-classes.html
I didn't mind Java when the comparisons were to C++, Ruby, and Python. I can not find a reason to go back after Scala (which seemed to fail due to being indiscriminate) and especially Kotlin
> Java continues to try and catch up to Kotlin
Does it, really? Java has had pattern matching since 21 (2023). Kotlin still, to this day, the year of our Lord 2026, doesn't...
Kotlin had it since 1.0, it's just called `when` instead of `match`.
https://kotlinlang.org/docs/control-flow.html#expressions
Kotlin does not have inline destructuring in pattern matching.
Kotlin has always had smart-casting in if and when (sort of switch) expressions, which are strictly more powerful than the current version of Java "pattern matching". Both don't do de-structuring which I would consider a basic requirement for pattern matching, but at least Kotlin didn't call it pattern matching.
Of all languages the only one it's trying to catch up to (and in places outran) is C#
With many others it doesn't compete because it would need a from-scratch rewrite of the runtime (Erlang/Elixir), or a from-scratch redesign of the type system (Rust, perhaps Swift).
A hoarder may have much more furniture than I do, but if I buy a sofa it doesn't mean I'm trying to catch up to the hoarder (who has five). Java isn't trying to catch up for the simple reason that we don't want it to have all the features Kotlin does; in fact, we're trying very hard to avoid that (not to mention that we have yet to adopt a single Kotlin feature; our features usually take a different form, even though Kotlin, Java, and many other languages often rely on the same inspiration, which is usually the ML language). That's because some languages aim to be feature-rich while others aim to be more minimal. Both are likely to accumulate features over time, but at very different rates (we'll hold off on features for years until we're satisfied that their value justifies the added complexity to the language, as keeping that relatively low is very important to us).
If you like a richer language, the Java platform offers you options, but many people prefer smaller languages (the number of Java Platform developers who use the Java language has remained pretty much at a constant ~90% for the past 15 or more years), but we're aware that a non-tiny minority of developers prefer richer languages, and so we accommodate them, too. Either way, 95% of the JDK is runtime (standard library and the JVM) and tooling, and you'll enjoy it regardless of which frontend language you prefer.
> Both are likely to accumulate features over time, but at very different rates (we'll hold off on features for years until we're satisfied that their value justifies the added complexity to the language, as keeping that relatively low is very important to us).
This strategy will still navigate Java into a random local optimum like it happened with other languages (that value backward compatibility), just more slowly. The greedy algorithm does that. Even if you do it slowly and you are extra careful that each step indeed betters the language.
Of course, invoking 'there are two kinds of languages: one that people complain about and one that nobody uses', there are two kinds of language designs: one that is perfectly consistent and one that has had contact with the real world.
The issue is that it's hard to predict how certain features will be misused and even harder to remove a harmful feature from a language. That's why Java goes slow. (Although I think there's too much pussyfooting around string interpolation. But I also think too much type inference makes the code harder to read.)
Everything comes to an end eventually, and there's no strategy to avoiding it. But not trying to adapt to real changes in the environment could certainly be a recipe to hasten that end. And yes, we do really try and make sure that any change we make is more than worth it.
But if in 2026 Java is the third or second most popular language in the world overall and the #1 choice large applications that are both performance-sensitive and need to be maintainable, but is it possible that in 20 years, despite our best efforts, Java will decline sharply, perhaps even to the point of being only as popular as, say, Go is today? Sure.
> not to mention that we have yet to adopt a single Kotlin feature; our features usually take a different form, even though Kotlin, Java, and many other languages often rely on the same inspiration, which is usually the ML language
This seems disingenuous at best, or it's a symptom that I've noticed as a user more often that your JDK team seems to have blinders on and dismisses/ignores most other languages even if feature have proven themselves 10 times over.
There's several features Java added or is trying to add, usually 5-10+ years later than Kotlin, and that's ignoring Scala:
* Local type inference
* Switch expressions
* Records, although I found them barely usable because there is no copy() method or with-ers
* String templates unsuccessfully
* A very stripped down version of smart-casting with switch pattern matching
I'm sure there's tech-debt and esoteric compatibility concerns which make evolving Java hard, but from a developer's perspective it's just glacial to evolve and the result is weaksauce.
Local type inference, records, and switch expressions (alongside lambdas and generics) are all ML features, as every language designer will tell you (and Java did them quite differently from Kotlin). All of them, by the way, were well known to Java's original designer in the nineties, it's just that they thought it will be a while until mainstream programmers are ready for them, so their adoption in Java is best postponed.
BTW, even if you're not aware of ML's extraordinary influence on most programming languages, surely you're aware there are competitors to Java with analogous features that are far bigger than Kotlin.
As for string templates, our intent is not to have a feature simiar to what Kotlin offers. We obviously look at all languages regardless of popularity, but in that case, as we did in the case of virtual threads or records, we'll probably say, no, that's not what we want, to Kotlin's approach (even the Preview that we pulled was nothing like Kotlin's approach).
> I'm sure there's tech-debt and esoteric compatibility concerns which make evolving Java hard
Backward compatibility is rarely a hindrance at all. People just talk about it a lot because most organisations consistently say that backward compatibility is much more important to them than any language feature, but it's not all that hard to maintain.
> but from a developer's perspective it's just glacial to evolve and the result is weaksauce.
I find that statement hard to reconcile with the fact that the only languages as popular as Java or more are JS/TS and Python, while all the languages that are not "weaksauce" from "a developer's perspective" are doing far, far worse than Java. There has never, ever, been any sort of consensus among developers on the right set of features, and there have always been developers who prefer more features and those who prefer less. It's perfectly fine to be on one side or the other or even to say, "yes, I'm in the minority, but I still think I'm right", but I find it strange to claim to represent "the developer's perspective" when your preferences are mostly associated with languages that are doing worse rather than better.
You're driving java feature set with great expertise. It is hard to complain about it.
I know it is not a technically marvelous thing, it's not a high priority either...but the only thing I'd want differently is lot more syntactic sugar that reduces common boilerplates/actions/patterns to simple one liners.
However, with AI writing most of the code now, I now doubt the importance.
What I like about Java is that it is a deliberate late-mover language. It doesn't go for the latest shiny thing but looks at what features have proven themselves in other languages.
I can't help but to be a little sobered by the promises of Kotlin and C#. They look great on the surface, but once you have more complicated code to work on they tend to show warts quite fast.
Java is remarkably consistent and really doesn't have any sharp edges. Even with generics and type erasure, I found myself fighting the language semantics in C# way more often than Java.
I personally enjoy Kotlin. There are potential warts with it, but those exist with other languages.
That said, Java taking it's time and observing the playing field is a huge benefit. And now that they've been slowly delivering new language features, it's really made it pretty nice flow of powerful well thought out extensions each release. There hasn't been one of the new features that I think missed the mark.
> I found myself fighting the language semantics in C# way more often than Java
What's an example? I find C# quite well designed despite the Chinese menu of features.
> Java is remarkably consistent and really doesn't have any sharp edges. Even with generics and type erasure [...]
These back to back with a straight face...What is a sharp edge in your mind?
A sharp edge is writing meta typesystem code infolving covariance, invariance etc
Saw that in a typescript repository
It's ok when it's part of a very specific library, it's not ok using it as part of usual project code
What is the significant difference to Java? In C# you would write something like Foo<out Bar> instead of Foo<? extends Bar> or some such thing.
Java still inexplicably doesn't have first-class support for string interpolation/templates. They were slated to add it in Java 23, but they removed it from the preview and it hasn't been seen since.
https://www.happycoders.eu/java/string-templates/
Because the feedback on how they worked apparently wasn't that positive.
Also who cares having to use String.format() in the agentic coding age?
Honestly, I still write a lot of perl, and while interpolation is nice and good to have for simple things, I find myself using sprintf more and more in production code, especially in the cases the examples always show off, such as needing to alter the variable, add two together, etc. I assume those are just shown to illustrate you you can do that, and not imply you should, because commonly using arbitrary code execution within interpolation is something I'd feel compelled to beat out of my coworkers if I encountered it regularly.
The point of (sane) string interpolation is that it runs at compile time, which helps prevent people from inventing crazy template systems at runtime. And you automatically get things like safe SQL queries with parameter binding instead of injection vulnerabilities.
Interesting point - syntax sugar was nice when writing code by hand. Now we'd be fine if no such sugar was added anymore ever again.
Syntax sugar still matters if you need to review the code. It was always about reading, not writing. Actually macros are even more powerful with LLMs. Metaprogramming has always been difficult for many (most?) programmers, but LLMs have no issue with it, and it's mostly doing the kinds of manipulations where as long as it compiles, it's correct, so you don't really need to review it in the same way.
The LLM itself is the metaprogramming, eventually we will be getting executables directly, the dream of previous AI Summers might finally materialise, with all the implications for the victims of software factories automation.
The LLM still benefits from a concise type-checked language to write software in, in the exact way a human does.
That would be formal rules, Lean style, and not related to 3 GL languages.
It is the Java Virtual Machine for a reason.
Without Google's godfather, Kotlin would be gone for now.
Kotlin is so great, where is the Kotlin Virtual Machine, showing how Kotlin can stand on its own?
Uhm, Kotlin does compile to native without the JVM doesn't it? It runs in the JVM for Java interop, no?
https://kotlinlang.org/docs/native-overview.html
Pretty sure it’s the other way around: Kotlin was implemented on the JVM and that’s its primary target, and got a native implementation later for folks that don’t want to run a JVM.
Is that relevant? Kotlin fully exists without the JVM, as requested.
A subset of Kotlin has a native backend, not good enough to power JetBrains products, which still require Java Virtual Machine.
It is so good, that JetBrains themselves rather use Rust or C++ for native code libraries on their IDEs, and not officially supported on the Android NDK.
So the goal post is JetBrains has to rewrite their stack in Kotlin native for Kotlin to not need the JVM?
Eating your own dogfood has always been a milestone of maturity.
The goal post is that Kotlin is able to stand on its own, without any dependency of JVM ecosystem, for its evolution as ecosystem.
A sign of maturity that Kotlin is grown enough to leave its parents foster home, and stand on its own without pay checks from its folks.
Sort of? The kotlin standard library yes, but it’s pretty rare to write an app with only the standard library. It feels like you’re dismissing the Java interop as a secondary benefit, but for most uses of Kotlin it’s probably more important to project success than the language itself. So I think it’s accurate that without the JVM Kotlin would be essentially dead.
> dismissing the Java interop as a secondary benefit
I mean, I don't really care about any of that. I was just responding to the (likely unserious) technical critique that there is no Kotlin VM. As for whether Kotlin as a language would be popular without the JVM, that's a different question.
I stand by it until Kotlin Native is taken seriously, other than porting Android apps into iOS.
Nope, the JVM is the main platform, and also used for Android development, which by the way, still mostly uses Android Java on the platform code.
Kotlin Native came later, its memory model was incompatible with Java, thus breaking portability for libraries between JVM and Kotlin Native, thus Jet Brains had to reboot Kotlin Native memory model.
https://blog.jetbrains.com/kotlin/2021/05/kotlin-native-memo...
Currently it is mostly used to port Android code into iOS apps, hardly something that even JetBrains could show off running their IDEs on top off, nah, they still need the JVM.
Kotlin feels like it's having an identity crisis. The gap between the two languages continues to decrease. Kotlin is trying to be server-side, Android, but also every other platform (KMP). Feels like everything is brand new and also deprecated at the same time, always moving on to something new.
Maybe Roman really was the soul and it lost its touch without him?
I guess in the age of AI it doesn't matter since a few years from now, if you change your mind, you can just ask Jeeves to one-shot rewrite it back to Java.
Until Java fixes its type system to add nullable types (and not in that ridiculous tri-state nullability method that one JEP proposes), Kotlin will be several steps ahead of Java.
I can speak from experience that Fable 5.1 still writes code that compiles and usually runs fine but throws null pointer exceptions in reasonable edge cases.
Waiting so long for type safety and hoping it won't be a weird implementation.
Kotlin's implementation is very good, hoping with all my heart java will copy it
Scala*
To be fair, sealed classes were introduced in Java 15 back in 2020. But granted pattern matching is what makes them really useful.
I would definitely trim like 20% off scala, but I think slow compile times were the main reason. To a much lesser degree but sbt being one of the first things you deal with when learning the language didn't help.
If you put a gun to my head and tell me you can't write in kotlin, you must choose either Java or Scala - for a small project I think I choose modern Java. If you tell me I need to choose for a large cross team and mission critical project - I think I take the bullet.
Still, I have a soft spot in my heart for scala, learned a lot from it.
This comment has major 2018 vibes. Most enterprises I know have have migrated back to mainline Java. We'll see if this changes again LLM era, now that prioritizing the talent pool is less important and the friction of migrating stacks is much reduced.