Java 27
mail.openjdk.org331 points by mkurz 19 hours ago
331 points by mkurz 19 hours ago
C# dev here: it’s amazing how different this is from a Microsoft release. First off, Oracle are doing versions at approximately twice the cadence. But also, and I’m guessing this is a function of the much larger Java audience: things rarely get two preview versions in a proper release. Updates in beta versions, yes, all the time. It also feels like Microsoft are bundling a lot more into the platform and leaving less to the community. Again, probably an artifact of the different sizes of the communities. Also, the page reads like an open source “We’re finished, we’re tired.” announcement rather than the razzmatazz of a Microsoft release.
One difference I think about is generics. Java and .NET bolted generics on to an existing system. Java used type erasure in such a way that a List<OfThat> is really just a List. Type erasure has a lot of limitations. If I am coding in Java for days I never get into trouble with it because I know how to color in the lines. But do some balls-to-the-walls metaprogramming and then it is annoying that you can't write
Expression<Integer> add(Expression<Integer> a, Expression<Integer> b);
Expression<Double> add(Expression<Double> a, Expression<Double> b);
Expression add(Expression a, Expression b)
.NET on the other hand did not keep backwards compatibility, so a List is not a List<X> so .NET had a schism where some API functions use generic collections and others use non-generics which was annoying in its own way.
Something like that is how all methods in Java are virtual whereas methods in C# may or not be virtual. All-virtual is probably not the best for performance, but it is simple for understanding. You never have to think "do I make this virtual or not?" or think "is that method virtual or not and does that have consequences for how I use it?"
This should address your example https://openjdk.org/jeps/218
That's about letting you do Expression<int>, not about removing type erasure or otherwise allowing overloads based on type parameters.
It's one end of the same problem.
int is not an Object, so just erasing is no longer a valid approach, you need to specialize the class/method itself to use int-specific byte code.
> 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 which don't impact the language or how you use it. So if you don't use OpenJDK (such as if you use Oracle's other runtime, GraalVM), then Java 27 basically doesn't even exist at all. Skimming the past couple of C# releases, it doesn't look like Microsoft is playing that game, so the release cadence will of course be different.
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 single spec approved by the JCP (https://openjdk.org/projects/jdk/27/spec/). This also makes things easier with regards to compatibility and evolution.
I wish there was a canonical write up on the governance of "java" and its history, it has changed a lot over the years (not just once I guess) and has a lot of fine prints. I find it hard to understand the hidden reasons and behind-the-scenes conflicts/compromises. There could probably be a whole book about this I guess.
One of the more prolific opensource projects, but apart from the JEP process not very open access (which is a fair choice the contributor('s employer) can make).
I'd read it.
> There's only a platform version,
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.
Right. There's a "Java SE" (platorm spec) version, and a JDK version that corresponds to it, but not everything in the JDK affects or is dictated by the spec.
BTW, Java is developed "code first", which means that we first work on the implementation in OpenJDK, and then extract the relevant spec changes from it.
> But that is still somehow a "feature" of the Java 27 release according to Oracle.
It's a feature of the OpenJDK JDK, which is, indeed, the Java implementation done by Oracle (with contributions from others). The language is very careful, as you can see in the announcement: "JDK 27, the reference implementation of Java 27". The Java SE 27 spec is here: https://www.jcp.org/en/jsr/detail?id=402
You’re only counting JEPs, which are only for more involved features. There are lots of changes to the JDK apis that are used by other runtimes. See, for instance: https://javaalmanac.io/jdk/27/apidiff/26/.
Admittedly, the terminology here is almost designed to be maximally confusing, and I’ve never read a good post that laid out how everything relates.
Fair, although even there I don't know if I'd call that "lots" at just 23 added or modified methods that aren't in preview
There are also bug-fixes and performance improvements that are not going to show on the page I linked.
I do think it’s plausible this is a smaller release. Not that this was the real point of the discussion, but I think it’s still just a good idea to have more than one release a year. It keeps things moving smoothly, and lowers the cost of missing a release, which has beneficial effects.
I started programming when Java 6 was relatively new. Back then it was about 3-4 years in between releases. Although I don’t write much Java any more, I’m happy to see changes shipping more frequently now.
There's not really a second C# runtime. Java has several, some based on the Openjdk, but a few that are completely new like OpenJ9 and Graal.
The closest C# has is mono.
This sort of thing is bound to happen with that situation. Heck, it happens with C++ whenever a new C++ version comes out. Some C++11 features took years to make their way into all the compilers.
Graal is based on OpenJDK. OpenJ9 while using a separate JVM and JIT leverage the openjdk class path as well as the build environment and various other things.
I don’t think there’s a single alternate implementation that doesn’t leverage a good chunk of openjdk somehow
For the simple reason that class files with JVM bytecode are the standardized intermediate representation. Therefore, duplicating the frontend is wasted effort.
Up to a point.
Embedded systems versions tend to have their own ways, which is why despite everything Android using Dex isn't a first in the Java ecosystem.
I didn't read the parent comment as being particularly positive in their description; it didn't sound like it was being stated as a good thing to me.
Polyglot dev here, that uses both ecosystems, Java since 1996, .NET before it was announced to the public in 2001, only available to selected Microsoft partners.
A big difference between both ecosystems is that the Java world is like C and C++, even though Java isn't defined by ISO or ECMA, since Sun days the main implementation is only a reference, there are official documents for everything, and there is a plethora of implementations, with various kinds of JIT, GC and AOT approaches.
You can pick the real time versions for embedded from PTC and Aicas, the cloud first from IBM and Azul with finance markets in mind, the Android cousin, the various implementations for M2M gateways, copiers and phone dashboards (Ricoh, Xerox, Cisco), IoT with microEJ, and many more.
Whereas Microsoft hardly cares about ECMA nowadays, most of Mono/Xamarin is gone replaced by Core CLR and modern .NET, .NET Compact is gone, community maintained and so on.
That alone, regardless of the languages on top of JVM, or CLR, makes a big difference on the audiences when one silos themselves to a single ecosystem.
Java releases used to be glacial multi-year affairs. Lots of discussion of features that then missed the release train and you knew they'd not be with you for another multi-year period.
They made a conscious decision to switch to a regular six-month cadence and it's been all the better for it. The preview-mechanism has been terrific there too, allowing half-baked features to be aired without absolutely committing to something that turns out to be flawed.
Edit: Ninja-ed by Romario77's sibling comment :)
> Microsoft are bundling a lot more into the platform and leaving less to the community.
This is a good thing. In Java everything has multiple community offerings, so before doing anything you have to evaluate the community offerings and decide which one to go with. If you go with the wrong one you may end up having to switch at some point, and that can be painful. This happens so often that most of the time spent when using Java is doing these evaluations and comparisons. With C# you just use the one built into .NET platform. Saves a ton of time.
Sometimes the thing built into the .NET platform is great, sometime it is just crap but developers will use it anyway and it sets back the ecosystem.
There is this division of labor between systems programmers and application programmers and often we think systems programmers are better because they know more about algorithms and data structures and compilers and assembly language and such. On the other hand, application developers understand how to reconcile the mental model of managers and employees and customers with computers, reality and common sense and, once they get experienced, see the commonalities between all the run-of-the-mill bizapps that we are coding all the time.
Application programmers do a lot better at applications framework than systems programmers and make things like Ruby on Rails and Spring. Systems programmers make terrible things like ASP.NET MVC (I worked out a way to do MVC with ordinary ASP.NET, why couldn't they, with access to the platform internals?)
Which is why there are so many complaints about doing FOSS in .NET, as many companies won't use anything that isn't blessed by Microsoft, and there is an history of Microsoft cloning FOSS projects.
If someone wants to create a project by assembling bits and pieces from different open source products they can, but many just go for Spring (Boot) and call it a day.
All of my projects are based on Spring and I don't really have to look outside of that ecosystem. It almost acts as an aggregator of different open source solutions and often works by abstracting the functionality so that differences are not that big. I recently switched messaging providers and didn't have to change much of my code.
Yep, with Spring Boot development is so easy, and even decade old projects are mostly easy to upgrade. I don't have experience from C# or .NET development, but at least compared to Python and especially JS ecosystems it's so much better.
Generally fairly painless in recent years, you need to divide the .NET timeline into original timeline ( .NET 1.0 -> Framework 4.8 ) and "core" lineage/timeline.
The Core (smaller, but also properly crossplatform) project begun in 2014, fairly major rewrites with breaking changes in the new releases up until 2019 (.NET Core 3.1) and 2020 (the 5.0 release that became the official major "unification" with most parts of Framework having newer alternatives and being "complete" even if 6.0 and 7.0 patched holes).
Projects started with core 3.0/3.1 in 2019 have a pretty easy and clear upgrade path without major breaking changes up until today.
It's not JS/Node volatility, and the cleanups in the language/runtime were well worth it in hindsight (still maintaining old 4.8 applications running under IIS), also 4.8 is still nominally supported so there's no immediate stress in upgrading (There are better semantics today, but with huge projects those semantic differences, mainly no lazy-loading by default are a risk).
> Python and especially JS ecosystems it's so much better.
That's a pretty low bar to beat.
10 years ago I was working at a place that was building Python systems that had dependency graphs too complicated for pip to handle. I was able to solve the problem for my system with a "wheelhouse" system that could compute a list of wheels that could be installed to build it but the confidence of my team in Python had flagged.
I had a sheaf of notes about the problem and figured out the math to build a proper dependency resolver for Python and tested out a lot of ideas such as being able to use http range requests to get the metadata out of wheels on PyPi without having to download the whole wheel.
The problem I had no solution for though was "how to stop developers from trashing the environment that the dependency manager runs in." The data scientists I worked with had an astonishing target for wrecking anything at all. Myself I would have my poetry's environment got bad for reasons I didn't understand every few months ago.
I also found the Python community just didn't care that pip didn't really work right. The most seductive form of blub is "I can accept using things that fail intermittently." I got a job coding Java and Javascript and never built the package manager.
Then uv came along and managed to sell itself as "crazy fast" which did connect with people more than "correct". Written in rust, uv would have beaten my system in the fast department, and since it is a binary, there is no way anyone can screw up a Python it depends on -- as I see it, both technical and marketing genius!
> If you go with the wrong one you may end up having to switch at some point, and that can be painful.
https://en.wikipedia.org/wiki/Log4Shell
https://learn.microsoft.com/en-us/dotnet/core/install/window...
> Also, the page reads like an open source “We’re finished, we’re tired.” announcement rather than the razzmatazz of a Microsoft release.
I think this is because the JRE/JDK upstream releases are a bit like Linux kernel releases: all the major first-party feature development goes on in subprojects that maintain their own "living forks" during feature development, with the teams on these features doing PRs against the fork's own "main"; that "fork's main" having its own subproject maintainers who ensure a mess isn't made of it; and then those maintainers eventually polishing up that fork-main into a single big one-shot PR to upstream once the feature-as-a-whole is ready.
(Compare/contrast: the Linux kernel's mm, rt, and kvm feature development efforts.)
Because of this, the top-level "project maintainers" (i.e. the people who decide what gets merged into upstream main) aren't really the same people as these subproject people who care deeply about these new features. They want to ship stuff people want, but they personally mostly deal all day with requests to merge 1. small bugfixes, and 2. features so small that no JEP is needed.
But then, every once in a while, they have to deal with a request to merge one of these huge subproject upstreaming PRs. And sure, it's already heavily reviewed by the subproject's maintainers, who they trust. But they do still have to audit it and learn it and create a stabilized release path for it. "Handover" stuff. And that's tiring!
So, given that the toplevel project maintainers write the release notes, I'm not surprised they come off as weary about releases.
(That being said, for purely PR reasons, the toplevel maintainers could ask the subproject staff to contribute their perspective to the release notes of a release that merges their work? But this could also just-as-well be a separate blog post—which would probably be better for sharing. I don't think I've ever seen a centralized Java blog [is there one?] but I think the subproject teams do tend to have them.)
the release cycle time was a deliberate choice.
Java tried to do fairly large updates and sometimes the release cycle would be very unpredictable as things would slip and take much longer than anticipated.
So to make it more predictable and to keep updates coming they switched to 6 months cadence with long term support (LTS) every two years.
This I think is a pretty good way of doing things, makes people who plan things figure out how to split feature development into these 6 months cycles, it made JEPs more granular and I think it made project Valhalla possible, if they tried doing it the old way it would never happen.
Splitting things in small chunks clarified what needs to be done and the path forward. It still takes very long time, but doesn't cause big incompatible changes and I think overall Java has good progress without being stalled.
I remember Dolphin being a particularly painful one, and as I recall it ended up with some weird compromises (wasn't erasure supposed to avoid needing to update the bytecode format, but then annotations required it anyway? Something along those lines)
yeah - they took forever, one reason being that Sun was in financial troubles and then acquisition took a long time.
Second was about licensing and Apache Harmony.
So, eventually they dropped most of the big things that were planned - Project Lambda with closures, Project Jigsaw with modularisation, Collection Literals. They eventually came back, but took a while to implement, so it was a prudent decision to make.
I never thought of Java being the 'move fast ~and break things~' alternative over .NET, but Java has a faster release schedule to get features out sooner.
I don't think modern Java is a 'move fast ~and break things~' environment. It's a comparatively stable platform with an enviable focus on backwards compatibility. The maintainers have talked about "last mover's advantage" when it comes to introducing new language features. Java has a checkered history when it comes to novel programming language features, so I think this is good.
Granted, the maintainers are more inclined to deprecate and remove parts of the API than has historically been the case but it is mostly obsolete things like applets. And you may need to keep a close eye on runtime flags and their effects.
Move fast and break things does not describe Java well at all.
Their process is still very deliberate, they go to some lengths to avoid getting it wrong when they add new features to the standard. New features have to get through their preview phase successfully before becoming final. [0]
They're also pretty committed to not breaking existing source code or bytecode.
[0] https://openjdk.org/jeps/12 JEP 12: Preview Features
It's pretty much the opposite.
A fixed release schedule makes development more relaxed so it can be properly done, no need to rush for some release date.
If it's not yet ready, there is 6 more months to get it merged.
Seriously, how many are using always the latest releases of Java instead the LTS ones? With LTS ones you have ~2/3 years between the versions.
We often use the latest version of Java at my work place. We haven't had any issues with upgrading, so there's no benefit of waiting for an LTS. There's no big process behind it either. The developers just quietly change the version as part of keeping the project up to date (BAU)
It may be that we are shielded from edge cases because we are based on Spring, which is probably the most tested piece of software before new versions of Java are released. But it's my impression that the risk of upgrading to a new version of Java is not the same today as it was in the past. The only advantage of an LTS is that it is supported longer, so that you can postpone the upgrade if you really want. It's not as if the intermediate releases are inferior or less safe.
At my last job, we only used LTS in production. Upgrading Java was always a long process, but that's more due a legacy monolithic app across thousands of servers.
You can almost think of the LTS releases as a major release and the non-LTS as a minor release, so really this could be 25.2. The current Java release schedule is to maintain a consistent and predictable release cadence instead of pushing big new features every 6 months.
> Java has a faster release schedule to get features out sooner
While still being behind on most features?
To misquote Bart Simpson:
> Let me get this straight: we're behind the [other languages] and we're going to catch up to them by going slower than they are?
Gotta go faster if you ever wanna catch up. However, Java is also purposefully slow. Everything is extremely considered. And while it means it takes a while before you get a feature it tends to be pretty good.
Which features exactly? Java got exhaustive pattern matching before C# (through sealed interfaces), it has switch expressions, multi-line strings, green threads and structured concurrency, is getting value types, and even type classes in the work.
Granted, I havent' used either for a couple of years, so my knowledge is a little rusty. Yes, some of them are "just syntax sugar", but man oh man does it make C# such a pleasant language to work with.
Used to work at a company which had services both in Java and C#, so some of Java's decisions or indecisions felt like pain points when switching between the two:
- Proper IEnumerable with proper iterators that in turn enables Linq (but in general permeates everything and is insanely easy to use and build upon). E.g. building an async service that behaves like an IEnumerable? Implement two methods.
Collection is halfway there, but I honestly cannot remember what was irking me about it in comparison to C#.
- Properties. Yeah, yeah, sealed classes, records and all that. Often you still need plain old classes.
- object initialisers. Which makes constructing anything a breeze. And on top of that you don't need manual .of methods for anything Colleciton-like if it'sa an IEnumerable.
- extension methods.
- named and optional arguments in functions
- null coalescing operator
- generics over primitive types (unless it was already implemented, I remember seeing a JEP about it)
- async/await. Yes, I know: different approaches to concurrency and all that. A lot of unnecessary verbiage could still probably be hidden behind a friendlier syntax.
- (sadly impossible in JVM to type erasure, only including this because I remember needing it many moons ago) generics metadata in runtime
- .... definitely a bunch more I don't remember at this point ...
At the same time, all this syntactic sugar makes the language's surface area gigantic. Like it's almost C++-level complex, and then you would have to properly understand all the interactions between this matrix of features.
That's absolutely a valid language design and many people prefer that, but I personally prefer a bit smaller language with a bit more IDE auto complete, but where you never have to think about what exactly does a line do.
(And then there is also Go that falls off the other edge of the cliff with useless if err checks spamming the code making actually functioning error handling hard)
> a bit smaller language with a bit more IDE auto complete, but where you never have to think about what exactly does a line do.
If you need IDE to autocomplete, then you definitely spend more time to understand what a line does ;)
> - object initialisers
Probably not a good idea since they break encapsulation by exposing internals of the class. There is work on withers, which should make defining builders far simpler.
> - extension methods.
They make code harder to understand. If they ever come they would have to be declared at the top of each source file.
> - null coalescing operator
Maybe we'll get it, maybe not, but they want to first introduce proper nullable types, lest there is a risk of painting themselves into a corner.
> - async/await
There is a fork in the road, and Java has gone into the direction that leads to virtual threads and Structured Concurrency, for the simple reason that there is no simpler syntax than plain old synchronous code.
> - ... generics metadata in runtime
There are plans to add a kind of reified generics, so maybe we'll get it.
> Proper IEnumerable with proper iterators that in turn enables Linq
Are you referring to generators?
> Properties
As far as I'm aware, it is a deliberate choice not to implement them, and I can see their point of view.
> object initialisers
I believe the same justification applies here, it's mainly syntactic sugar, and can result in certain undesired behavior by bypassing constructors where validation can happen.
> extension methods
Typeclasses are currently being explored, which are a superior approach.
> named and optional arguments in functions
Those would be nice (at least named arguments). I can see how optional arguments could complicate things.
> generics over primitive types
As you mentioned, it's in the works
> async/await... verbiage could still probably be hidden behind a friendlier syntax
The approach they took does not need any extra syntax.
> Are you referring to generators?
Both I guess.
Main thing is https://learn.microsoft.com/en-us/dotnet/api/system.collecti... which seems to be everywhere in the language and the library.
> I believe the same justification applies here, it's mainly syntactic sugar, and can result in certain undesired behavior by bypassing constructors where validation can happen.
This is mostly due language design. Java heavily relies on properties and provides no facilities for them. Hence the builder pattern instead of object initializers.
In C# object initializers synergize with properties: https://learn.microsoft.com/en-us/dotnet/csharp/programming-...
> The approach they took does not need any extra syntax.
You mean it needs 15 lines whete C# needs one? ;)
> the page reads like an open source “We’re finished, we’re tired.” rather than the razzmatazz of a Microsoft release.
The vibe selects the audience perhaps.
People who are tired and just want to finish their work like the first style. People who want to do more cool work more quickly, maybe without finishing, like the second. Depends on the work, I suppose.
Because there is nothing in it, that's why this release, along with majority of the recent ones drop like wet farts. How many previews of the vector API would you like?
I read nine JEPs. Sure, some are re-Previews, but they are important since they often contain improvements from community feedback. Specifically, it would be quite unwise to finalize the Vector API before Project Valhalla. Apart from that, I'm sure that there are lots of minor visible changes that didn't get a JEP.
Anyway, not every release can be filled to the brim with new features, and people were also kinda busy whipping Project Valhalla into shape. INHO it's still preferable to stick to a predictable schedule instead of creating uncertainty in the community.
> Also, the page reads like an open source “We’re finished, we’re tired.”
I mean it's short and concise and there are additional resources that provide more detail. IMHO it's not a bad thing.
I kind of wish C# would slowdown releases in some areas. I have not been a huge fan of some of the changes in the past year. I love the performance changes and bits of functionality here and there, but the syntax-sugar is getting annoying.
People complain, but most of the actually used changes are in things that continually used where I find painpoints.
Not 100% on board with the collection expression changes (I found fluent Linq chains usually more readable), but they're improving painpoints so I think it'll work out in the end hopefully.
Interesting take, how is optional functionality annoying? Isn't the fact that it's just sugar a huge benefit? Us old timers can simply stick to what we're familiar with.
Because unless you are the only person maintaining your codebase other people in your organization will start using the cool new syntax sugar and optional functionality. So you will be forced to deal with it as it starts showing up in your codebase.
I don't get this either. You can even lock the language level if you really don't want it, or you can just ignore it.
(GP here)
> Isn't the fact that it's just sugar a huge benefit?
My main gripe is that I cannot remember what is allowed and not allowed between multiple versions of the same language. On a daily basis I hop between apps versioned in .NET Framework 4.8 all the way to .NET 10. I have to constant remember, are nullable types allowed here? What about 'new(); vs. new Object();', new collection syntax, new switch syntax, new extensions syntax, etc..
Plus, I just find it obnoxious that the same thing can be written so many different ways. I can think of 7 ways to assign a new empty List<T>.
List<T> foo = new List<T>();
var foo = new List<T>();
List<T> foo = new();
List<T> foo = new List<T> { };
var foo = new List<T> { };
List<T> foo = [];
var foo = (List<T>)[];
There are probably more that I am forgetting. What irks me most is Java is older than C#, and from what I can remember, it is not nearly this ridiculous in terms of syntactical sugar. So, what is the true benefit behind all this sugar? It hardly saves any keystrokes in the age of autocomplete in IDEs.
I am inclined to believe most of the sugar is an attempt to make the language appeal to a newer generations of programmers. But I would argue features are more attractive than syntactical sugar. I believe Rust is truly impressive language. In my opinion, its syntax is uglier than sin, but that does not seem to deter many from using Rust.
Some of those ways come from just plain object initialisers. Which are amazing and sorely needed in Java.
That's why you get `new List<T> { };` Because it could be `new ComplexObject { <fileds and properties> }`.
Same for `new`.
Some come from type inference which Java also has.
That's why you can have `List<T> foo = new List<T>();` and `var foo = new List<T>();`
It's not really "7 ways to assign a new empty List<T>". It's "7 ways to create an object", and Java several of them, too.
> Some of those ways come from just plain object initialisers. Which are amazing and sorely needed in Java.
They really aren't, and they are IMHO an antipattern since they break encapsulation. One might argue that encapsulation doesn't matter with mere data classes, but Java will cater to that use case by introducing withers.
Most new syntax features make code more readable. For those that don't there are company style guides and `AGENTS.md`. The C++ philosophy comes down to "if it works ship it" and I don't think you're expected to use every single new feature.
You don't really have to use the latest C# version, though. Install the latest .NET and you get the performance improvements without usually having to change anything about your code.
It's a normal open source announcement without the corporate bullshit. No fatigue. No doom. Just facts! /s
razzmatazz? Do you mean marketing lies and self aggrandizement for merely doing shoddy work?
>> Oracle are doing versions at approximately twice the cadence.
This has nothing to do with Oracle. All good that you hear from Java in the last few years, is the great community and good old people from Sun working at Oracle.
Someone doesn't know their Java history. Oracle bought Java 16 years ago in 2010. At that time Sun had been working on Java 7 for over 4 years with no release date in sight. Oracle trimmed the fat and released Java 7 in less than a year. And since then has kept a regular release cadence. Sun would probably still be working on Java 7.
it wasn't about Oracle trimming the fat. Java 8 took 3 years to release and then Java 9 another 3 years.
They had to commit to half a year release cycles and LTRs every 2 years. Since then the releases became a lot more predictable. Whatever is not ready is not released (or is there as a preview feature).
This more agile approach is a lot better in my experience and we see that the changes made are more relevant and what people actually want.
“The good old people from Sun working at Oracle” is now Oracle as well.
This thread, which I read most of, reads like a 'how to be a language-war thread without explicitly being one'. :)
Just use the language the (keeps putting) puts bread on your table. All languages have their own 'baggage'.
Wrt to AI, I agree with pron's comments that for very large code bases, AI can't do 4$hit.
"The Java Story" documentary by CultRepo on YouTube is pretty great. A major topic is the release cadence which some other comments here are mentioning / joking about.
Serious question: when should one use Java for greenfield projects in 2026?
These days, Java is mostly used in greenfield software that has to be very reliable, very performant, and last for many years. So it's often the first choice for banking, telecom, finance, government, defence, manufacturing control, logistics and shipping, media streaming, retail, hospitality, healthcare etc.. It's usually not a first pick for more exciting software, such as Python type checkers, JS bundlers, or TUI file managers.
I think of Java/Kotlin and Spring as a secret weapon for startups. My workplace was a startup 5 years ago and it's amazing how things just worked as expected, leaving us more time to focus on the product. We have tried a few alternatives over the years, such as a few services in Rust, but the people who implemented those have usually seen the advantage of using a stable ecosystem after a few years. It's unfortunately something you need to experience yourself instead of being told by someone else.
This is quite the take - i doubt most startups building in these spaces are using Java.
First, they do. Second, most software is not only not produced by software startups, it's not even produced by software companies. Do you know how much software a bank, or a credit card company, or a telecom provider, or a car manufacturer (like BMW), or a shipping company (like FedEx), or a defence company (like Boeing), or a large retailer (like Walmart) write in house?
Wasn't the discussion about greenfield projects? Or by greenfield do you mean internal greenfield projects at existing companies that already use Java?
i can't speak to the others but banking and healthcare is virtually all java top to bottom. The big healthcare EMR/EHR systems are Java and every bank i've ever worked with (i use to do a lot of integrations with the big banks) was all Java. I have friends in those areas and whenever they start up a new project it's still always Java since that's where their skills are and what's on the "approved tech." list.
in my healthcare experience (claims processing, medtech) Java existed for sure but it was always as a "legacy" system they were moving away from.
Until quite recently, the reasonably feature complete open source libraries available for things like DICOM or HL7 were old C/C++ libraries, Java, and C#. That often created a choice between Java and C#. People not doing Windows based development tend not to be interested in C#.
Cross platform C# is certainly getting huge in healthcare and medtech recently though.
Is it? My experience from 2014 - 2018, was that C# was only used in the lifesciences software for Windows, and as wrappers around device drivers mostly written in COM.
Everything that was done on the backend side was done in Java, although there were some exceptions for .NET deployments.
So we ended up with mixed skills teams where depending on the ticket, you would be coding Java or C#.
What were they moving towards?
We embedded angular in our old Java client for hospitals. The user thinks he just opens a new window, but it's chrome in Java, which opens angular frontend, for our Java backend.
claims processing - TypeScript, lots of ETL tools with Go.
medtech - .NET and TypeScript.
From what I see, most software being created in these spaces isn’t made by startups.
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.
Saying that Go lacks in those is just showing how people are making software those days. It’s just terrifying.
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.
> Saying that Go lacks in those is just showing how people are making software those days. It’s just terrifying
I'm not following. Saying Go lacks in X shows how poor other software is? Can you connect the dots?
I don't know what compiler and GC quality has to do with how people are making software these days, and I don't think state-of-the-art optimising compilers and GCs are terrifying at all. Go opts for more traditional, simpler algorithms under the assumption that for many purposes they're good enough. That may be so, but sometimes workloads really are very demanding, and you need the best performance.
and the costs they are willing to pay. Go/Rust just kill everything else (except maybe C++) for performance and resource needs. JVM requires so many resources just to run small apps.
Quite the opposite, and the reason is that you can't extrapolate from small programs to large ones. Low-level languages (like C++) incur some significant overheads as they grow large (because of essential constraints of low-level languages that prevent them from doing certain optimisations that matter mostly in large programs), and these are exactly the overheads the JVM is designed to reduce. In small or short-lived programs, the situation is different, because Java does have some warmup costs and some fixed memory overheads that matter when you're small or short-lived. Go's compiler and GC are pretty basic, and are certainly good enough for smaller things, but don't scale as well to high workloads. Just the other day a colleague tested Caffeine, an old and well-established Java caching library, and Moka, a Rust caching library with the same workload. Caffeine had the same latency as Moka across all percentiles at twice the throughput.
I use Java every day but just to point out that your info about Go‘s GC seems out of date. They switched to Green Tea in 1.25 (I think?) - new GC that even has AVX-512 optimizations. Not sure what you mean by basic about the compiler but it‘s very fast and supports a large set of platforms. That‘s not basic to me.
We are using JDK25 and are considering rewriting parts of our product to Go because of lower memory pressure and faster startup time, i.e., cloud friendly. I actually love both languages.
> I use Java every day but just to point out that your info about Go‘s GC seems out of date.
I'm well aware that Go's GC has improved, but the moving algorithm was designed not just to be fast for a GC, but to be faster than no GC. So Go's new GC is good - for a mark and sweep collector. But it can't compete with a moving collector (the only thing that can is arenas, which are user-friendly only in Zig).
> We are using JDK25 and are considering rewriting parts of our product to Go because of lower memory pressure and faster startup time, i.e., cloud friendly.
Java probably will never have perfect warmup, but it's getting very good - https://openjdk.org/jeps/544 - probably in JDK 28.
As for memory, I think Java's memory strategy is generally misunderstood and I've given a talk about it: https://youtu.be/xr73mR7ii9M The footprint overhead exists to compensate for CPU utilisation when the CPU utilisation is more disruptive than memory usage. The problem is that many Java developers - and I'm not blaming them - don't understand this tradeoff and how to configure the JVM for optimal resource usage, but the great news is that a solution is coming soon, too - https://openjdk.org/jeps/8377305 - also possibly in JDK 28.
So it's very likely that both of these issues will be resolved six months from today, and you'd still get to enjoy better performance and telemetry than all alternatives.