141–150 of 424 posts
Earlier quoted context omitted.
It’s still missing null safety, right? Which means it’s still a hard no for me.
Nullability annotations + tooling makes this a non-issue in practice.
Earlier quoted context omitted.
It's on you bc it was (arguably but still) dead 17 years ago. edit: don't get me wrong, i am not here to hate java, but bc i am also ... hm necrophil :)
17 years is a rookie number. Take C# auto-properties, for example: 19 years ago! Now try asking, "When did Java get auto-properties?"
I missed generators like that virtual threading for example.
btw: i was referring a single point when oracle bought sun and "closed java".
Earlier quoted context omitted.
They lack in performance, stability (compatibility), observability (telemetry), productivity, or some combination thereof. They are chosen, of course (especially C#; Go and Rust are far behind), but not as much as Java.
I think you have a biased view. The number of stuff written in Rust in the last couple of years has absolutely exploded. For example, I see a lot of projects now that provide SDKs in Rust but don’t bother with Java. And I say this as someone who still writes most of my code ( or tell my LLM to write) in Java.
Project Valhalla will go into Java 28 (next year, and preview version). Fingers crossed I'll manage to use null type safety in my lifetime.
Serious question: when should one use Java for greenfield projects in 2026?
Earlier quoted context omitted.
Checked exceptions are controversial mostly because a lot of the core APIs use them in places where it's pointless to check, like IOException. Using them correctly can be great tho.
>in places where it's pointless to check, like IOException Can you explain why this is pointless? In my mind, this being a checked exception would hopefully be a hint that I should think about this failure-case and make an explicit decision whether to handle it or not. Network connection failed? Maybe I retry. Maybe I store that data somewhere else as a fall back. Isn't this similar to Go programmers needing to check…
As soon as you consider retrying a network failure, you immediately need to start thinking about distributed systems failures, idempotency, and all that good stuff.
As soon as you start thinking about the above, it becomes immediately obvious that low-level calls should not be able to decide to re-run themselves.
Earlier quoted context omitted.
When you are already familiar with it or work in a Java shop, there are better options if you are starting from scratch, but if you already have 50 guys that know Java it's a pretty big ask for all of them to switch.
Why not Kotlin?
Earlier quoted context omitted.
> First off, Oracle are doing versions at approximately twice the cadence Is that actually a good thing? But Oracle started playing a game, for better or worse, where they decided to couple the "language version" with a single specific runtime's release schedule. For example, in "Java 27" there are exactly 0 language changes and 1 minor feature addition to the TLS library. Everything else is OpenJDK runtime internals…
The Java language and runtime have been co-designed as a unified platform for many years now. Virtually every significant feature has language, library, and VM people working on it, and we often don't even know when we start how much of the feature would be in the language, library, or VM. Consequently, there is no "language version" or a "runtime version". There's only a platform version, which is defined in a singl…
And of the 4 non-preview JSRs in the Java 27 release, only 1 of them is actually part of the "platform version".
The other 3 are strictly changes to Hotspot internals with no platform involvement at all. They did not change any aspect of any Java platform in any way whatsoever. That is what I'm referring to. I'm not referring to the fact that the core library, language syntax, and runtime specs are all part of the same version. I'm referring to the fact that Hotspot specific behaviors and adjustments are also branded as being part of the platform release.
Like there's no Java 27 platform spec that says that G1 is the default garbage collector. That would of course be an absurd platform spec change. But that is still somehow a "feature" of the Java 27 release according to Oracle.
Earlier quoted context omitted.
Why not Go, Rust, or C#?
They lack in performance, stability (compatibility), observability (telemetry), productivity, or some combination thereof. They are chosen, of course (especially C#; Go and Rust are far behind), but not as much as Java.
As to Rust - we all, hopefully, agree that it’s great language, but not for some startup making websites or Mongo based, boring backends. It’s great for the stable, system level products.