Java 25 Officially Released
Posted4 months agoActive3 months ago
mail.openjdk.orgTechstoryHigh profile
supportivepositive
Debate
40/100
JavaProgramming LanguagesSoftware Development
Key topics
Java
Programming Languages
Software Development
Java 25 is released as an LTS version, bringing new features and improvements, with the community discussing its impact and potential applications.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
N/A
Peak period
136
Day 1
Avg / period
26.7
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Sep 16, 2025 at 9:25 AM EDT
4 months ago
Step 01 - 02First comment
Sep 16, 2025 at 9:25 AM EDT
0s after posting
Step 02 - 03Peak activity
136 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 30, 2025 at 6:24 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45261946Type: storyLast synced: 11/20/2025, 8:28:07 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Java 25 is an LTS release.
edit: I wrote "require" when I meant "ship with". We ship a Temurin JRE together with our product, so it's being updated with each new installation.
Happy to see Scoped Values here though. That'll be big for writing what I'll call "rails-like" things in Java without it just being a big "static final" soup in a god-class, or having a god object passed around everywhere.
My favorite parts of TPL Dataflow are using Channels + Encapsulate to create custom blocks, backpressure, and parallel execution while maintaining ordering. Great library. I sometimes wonder if it would be possible/useful to implement a TPL Dataflow 2.0 on top of Channels.
However, you still have concurrent code. The example given uses futures rather than async/await, and so the thread blocks waiting for these other threads to complete.
The Java alternative to async/await is the virtual threads. Since they are not GC roots and the stack is a chain of heap-allocated objects, the idea is that they can have significantly lower overhead in terms of memory usage for small tasks. Rather than the compiler generating heap objects to store intermediate state, it just uses a virtual thread's stack.
However, even without async/await syntax you still have equivalent concepts. Since the compiler doesn't have native structured concurrency, it is emulated by putting tasks in lambdas. You fork off subtasks, and do a blocking get() to resolve the futures for their results. Heavy use of fork(), run() and get() aren't necessarily better than async and await keywords.
One concern I have is that Java virtual threads are supposedly preemptive, not cooperative. This means you will have less guarantees around concurrent modification than you would with a typical async/await system running cooperatively on an executor. Several languages willing to make more core changes around adding async/await have gone as far as to also integrate actor functionality to help developers write concurrency-safe code. I don't see Java being able to provide developer help/diagnostics here like other languages can.
I'd use Qt, though if you're not comfortable with C++ I've been told JavaFX is pretty good
JavaFX is good (I really like FX), and maintained, and portable. They just came out with 25 I think. But it's a completely different model than Swing.
JetBrains is 25 years old, almost as old as Java.
I am an IDE guy since Borland products for MS-DOS, yet I was never sold on InteliJ anyway, and Android Studio made me dislike it even further.
NetBeans was bought by Sun in 1999 and opensourced on Jun 2000.
And all the other variants ultimately just repackage it. So if oracle doesn't care about destroying the Java IP, it definitely could cut everyone off from updates going forward.
I don't think they'll do so however, MySQL is still freely usable too, right? And that's oracle IP too.
Might change if they ever get into financial troubles, but that's the same issue with all languages and frameworks.
Sure, that could stop to maintain it, but would put the power immediately in the hands of other companies with a fork
That said, you always have oracle's greediness...
I have a feeling all those companies / orgs would band together to maintain it.
BTW, I don't dispute that Oracle is greedy, but I find the suggestion that Amazon, IBM, Google, MS etc. are any less so laughable.
It is used everywhere. Just among the faang companies, Apple, Amazon, Netflix and Google definitely use it at scale, and they're just the tip of the iceberg. Taking away JVM updates would almost be a company-ending event for them, and they definitely have the resources to keep it alive if Oracle ever dies.
Older releases are under their OTN license, which is only for personal and development, but not production.
Again, this only matters if you want an Oracle sticker on your runtime, OpenJDK and the other projects are full boat "do whateva" JDKs.
[1] https://www.oracle.com/uk/java/technologies/downloads/#java2...
The UPL is an OSI-approved open source license. It shouldn't be a problem to use in any setting, but you should check with your legal team to see what licenses are approved.
If you don't like Oracle (and I wouldn't blame you), there are alternatives from parties ranging from the Eclipse Foundation to Microsoft and Amazon that will do the same thing.
As for new projects, Java is here to stay. It's longevity is part of why companies are still using Java 8/11; once you write it, it'll run pretty much forever.
The language lags behind in terms of features compared to pretty much any competitor, but it's functional enough to get anything important done.
I'd personally go Kotlin if you were to rely on the JVM (almost entirely because Java still lacks nullable types which means nullpointerexceptions are _everywhere_) or C# if you don't like the Kotlin syntax, but Java is Good Enough.
That was something that always bothered me because it felt so counterintuitive.
public Foo(int x) { super(validate(x)); }
validate would run before super, even though super was technically the first statement in the constructor, and the compiler was happy.
From what I've seen, most people only care about the LTS versions of Java. Which means that after Java 21 LTS comes Java 25 LTS. The same happens with Ubuntu (after 22.04 LTS comes 24.04 LTS).
we decided to bite the bullet and do 21 instead of 17; one of the reasons being 25 being just around the corner.
as far as i can tell, the biggest hurdle is 8 to 11 (with the new modules system); but it's smooth sailing from there. the proof-of-concept was done with jdk17, but it worked as-is with jdk21 (except guice which needed a major version bump).
(of course being with a jvm language instead of java itself also probably helped)
If you could get through that, you’re golden. From what I’ve seen going to 21 or 25 look easy. They’re just adding features, the big upheavals of doing the long needed cleanup are over.
I expect keeping up to date to be far easier from now on.
We didn’t do that one giant jump. We moved from 8 to 17 in one step, then in a separate step upgraded Tomcat requiring the jakarta changes later.
I guess I tend to think of them as one “modernizing“ combo even though they’re not.
It sort of was; it was caused by Java no longer coming with the J2EE libraries. Before that, J2EE could be considered part of Java; now that it's a separate project, they were forced to rename the packages.
AFAIK, these libraries did so because there was no alternative, and some of the changes in Java 9 and later were done to provide them with an alternative. The only thing left is Signal/SignalHandler, which AFAIK still has no alternative outside the sun.* packages.
A programming language isn't only grammar and semantics.
These can be very useful in certain circumstances, but it should have always been clear that there is a risk they could one day be changed in an incompatible way or removed.
When code breaks, the user doesn't care about the details of the root cause, it stays broken.
Crucially, if the OpenJDK project had removed or changed these internal APIs the result would have been all the same. But it's simply unreasonable to expect Oracle to also maintain backwards compatibility there.
I'm not sure I like the module import system very much. I think `import *`-like constructions make code a bit easier to write, but much harder to read, especially for developers new to the language / codebase.
C# and Nim love that style, and it makes them almost unreadable without a good IDE.
Personally, I much prefer Python's "short aliases" style, e.g. `import torch.nn.functional as F`
I think a lot of what turns people off to the C# developer experience is not using full-blown Visual Studio. VSCode is great but I would never open csproj or sln files using it unless I needed to manually edit their actual XML contents.
It's not broadly advertised that you can buy a perpetual & fully licensed copy for $500 [0]. No subscription or other cloudy scam stuff is required, although Microsoft's product pages will initially lead you to believe it is.
[0] https://www.microsoft.com/en-us/d/visual-studio-professional...
No, I don't.
For some reason there exists a group of programmers that refuse to acknowledge use cases like "let me write a small program in nano over SSH" or "let me change one hardcoded variable and recompile the project and never touch its source code again". If your code is unreadable without IDE, it means that either IDE should be shipped with the compiler because it's an essential part of the language, or the language is garbage because its designers literally admit "we're too stupid to figure out how to solve this issue, hope that IDE does something smart because we can't".
1. This is an infinitesimally small use case
2. Often those same programmers somehow are completely fine using C++ or Rust
3. Even more often those same programmers deny the usefulness of IDEs just because they need those use cases once every 10 years or so, and keep using subpar tools
It’s ATO’d and everything, and it works for all the other contractors. They have no trouble shipping on time, give or take a decade or so; what’s your problem?
However, I don’t think your arguments are sufficient to outweigh the benefits that can be obtained by making a language platform with features that assume the presence of IDE support.
Either way, I’m just one person, so you do you.
(And since we're on the subject of Java, let's not forget how they used to split up JRE and JDK downloads in a very similar way.)
Having the IDE ready to go takes care of the use case of changing one variable, but you didn't need the IDE in the first place. That one's fine either way.
For the use case of making a whole new program in nano, I acknowledge and reject it. You'll be fine. Use cases that exist only out of stubbornness don't need to be catered to. You have the IDE one click away.
In small codebases anything would work.
PS: why do you even look at imports? Any decent editor just hides it, you never need it, you navigate just by clicking/hotkeys on names directly from code.
Most of the reasons Java dropped out of popularity no longer apply, and at this point it is an incredibly stable and mature ecosystem.
I can come back to a Clojure program I wrote ten years ago and it runs great, meanwhile a TypeScript program I write 6 months ago requires a bunch of updating and cleanup.
These days I don't see those as significant issues, tbh.
I would prefer a Clojure program, but I'll take Java over Typescript at this point.
Python code that follows traditional Python paradigms is called "Pythonic".
Java code that follows Java paradigms is called "awful".
To be fully transparent, I've never written Java professionally, only for a couple small hobby projects 10 years ago, plus some while in school, so my opinion isn't worth the pixels you're reading it on, but I look at most Java code with abject horror.
Endless levels of abstraction. The apparent inability to write a simple function and instead creating a "ThingDoer" class with a single function called "doThing". Run-time introspection and reflection EVERYWHERE. Stack traces that are just an endless stack of calls to functions like ".invoke" and ".run".
I've been under the impression that all of that is a by-product of Java's strict type system, but someone please correct me. Why do Java paradigms seem so awful?
https://github.com/plantuml/plantuml/blob/master/src/main/ja...
Is there a full library ecosystem of stuff written like the json parser you shared, which is as complete as the enterprisey library ecosystem? Similarly, SO answers? LLM output? Tutorials? YouTube videos?
I think the answer is no.
It's the same problem with C#. Just adding alternate paradigms means nothing. The only thing that matters is how a majority of code in the ecosystem is structured. In java, that's enterprisey code. Most code is glue code, so you're forced into the majority pattern, lest you want to write endless wrappers...
On the other hand, while typescript supports a lot of the enterprisey nonsense similar to C#, the majority of the ecosystem is written with simple functions, callbacks and options objects. Not in an enterprisey way. I don't need to use decorators to use zod.
People that eschew enterprisey code and prefer simple code can't switch to java or c# until the whole culture changes, regardless of the kitchen sink of features either language adds.
Going back to culture, who makes up the Typescript community? While C# devs are attracted to it there are many multiples more devs coming from a JavaScript background. This has a big impact on how the culture developed.
Taking a step back. C# devs often need to do frontend work. They could go with what the industry has settled on, React, or go another way. The bulk go with react and some perhaps lament still have to switch their brain to another mode for that work. Frontend is obviously more fragmented, but the scale prevents C# devs from influencing patterns to the extent that they do on the backend.
I'd argue similar for Java devs when it comes to frontend. In the case of Blazor, I think C# patterns are a much smaller factor in decision-making. In fact, lots of C# adherents would default to React given it's the industry standard.
C# is still much better because it has a lot of useful DX improvements: from object initializers to IEnumerable everywhere. It keeps the tower of abstractions lower, and makes working with the tower a better experience.
Though I've only worked on microservices written in C# in .net core
One reason Java codebases feel more abstract is that they're attempting to solve problems that the scripting worlds tend to just punt on, or handle in ways that don't scale well. And because Java's type system is nominal, solutions to those problems require names.
For example, a lot of the abstraction in Java codebases is to make things deeply testable. That's what drives dependency injection, which is where a lot of BeanFactory stuff comes from. What's the Python solution to that problem? Often they just hardly have tests by the standard of Java developers! This is why Python is big in ML research where codebases are often small disposable experiments, and why after a brief era where Django was popular it sort of died off in the wider server / big data space.
Another source of complexity and abstraction is a focus on pluggable ecosystems. Databases are abstracted by JDBC, and then again by an ORM, which then might be abstracted again by Micronaut or Spring, and at each layer there are multiple competing implementations available which implement standard APIs. This kind of thing happens much less in the scripting world. The downside is that scripting codebases are far more locked-in to their choice of libraries. Porting a Java codebase from one database or ORM to another is hugely easier, because the core APIs are all standardized.
On the other hand, how universal is the problem of migrating from one ORM to another? Not all problems Java I has been leveraged to solve are relevant today. This is the extra baggage we have to carry forward.
Eh, I don't think Java type system is strict, nor is it the root cause of this cargo cult mess. It's probably due to many enterprise programmers who think design patterns are the building blocks of everything rather than an invisible, emergent structure.
1. Lack of first class functions till Java 8 is one reason old APIs are horrible with inheritance and reflection everywhere. You had to extend class and override methods even for simplest of tasks.
After Java 11 the code is much more succinct and functional style. But old libraries remain.
There are places where the overextensibility these libraries provide is useful. But those are few.
2. the annotation processors were late to the game - so many libraries which need to inspect object structure (such as serialization) were written with heavy use of reflection.
I will give you an example of how frameworks designed for "modern" Java look like.
Micronaut has something called Micronaut data JDBC - in which you just declare methods with few annotations eg `List<Book> queryTop10BooksByYear(int year)` and it will auto generate the JDBC + SQL code and handle injecting it into your service. The returned object can be a POJO without all the Proxy object circus ORMs come with. I haven't seen something as easy in Python yet. And all this happens in compile time with an annotation processor.
As for the language itself, a lot of verbosity has been culled in later language versions, with diamond operators, lambda expressions, local variable type inference, etc.
In either case, code is read more than it is written, so if a bit of verbosity makes code easier to read, I'm okay with it.
Using it in vscode, while not perfect yet, is starting to be alright.
But, I am fully talking out of school because I don't know what the actual, no kidding, accessibility hurdles one faces when trying to do work in such a setup, nor what concessions VS Code has made to fix those problems
But I do know that YouTrack has a dedicated categorization for accessibility reports and I am sure they would welcome hearing about how they could win back those audiences https://youtrack.jetbrains.com/issues?q=%23%7BUI.%20Accessib...
That's actually quite correct and I'm saying this as someone that does Java on daily basis. Go is in fact superior in terms of deployment. I would rather deploy a Go-written service than a Spring Boot one. That being said, I love using Java for monoliths - large code bases crammed with business logic. I personally don't see Go doing very well in that direction.
And sure, it's not everyone's cup of tea, and/or plenty of people will chime in with "yes, but"s to defend golang or every other platform that isn't the JVM. I'm not yucking your yum! I'm just saying for me, the JVM is the bees knees
Also features like transaction management, dependency injection, validation frameworks, AOP-style cross-cutting concerns are better addressed in Java.
Java has collection streams with great customizability (filter/map/reduce/etc). Far better writing your 10,000th for-loop in Go. You can also get automatic parallel streams without writing any extra code.
Go's profiling tools (esp memory) are very primitive, sorry. JVM profiling tools beat Go's by orders of magnitude. So does the other tooling - GC tuning, monitoring, etc. Java flight recorder and VisualVM are gorgeous.
That said, Go is still better at memory efficient, tight network software like lean k8s controllers. Though frankly, Rust is encroaching into this space.
Btw, you can AOT compile Java if you wish... it'll probably be a larger binary than a Go binary, but that's whatever...
[Meta] ... God, I'm turning in pjlmp here, lol
The problem with this type of trend is it's often hype and you never know what actually happens or how does it evolve over time.
I've seen organizations make certain announcements, switch maybe 5%, give up and go in different directions, but only the initial announcement ever hit the news.
> and seduced by the promises of a language simple to learn, build, and deploy
It's always simple if you rip it all up. Nice and shiny toys are always great.
Why can't they co-exist?
> has eliminated the argument that would favor the JVM
This complaint is taking technology definitions too literally. I doubt new adopters of Java or the JVM are really going on about that now. It's more been about the ecosystem, the maturity, etc.
Especially now that hardware architectures are getting fragmented again, I hope it becomes more relevant.
I think Springframework is dragging Java's reputation down. I know Spring boot is better but it's such a monstrosity.
I feel like sadly Python has won the war, though. Good enough for most things even though it is pretty rubbish.
I see people trying to use Rust now for prod AI systems.
With this in context...
> I think Springframework is dragging Java's reputation down. I know Spring boot is better but it's such a monstrosity.
Is that really so? Spring's not the best, but it's definitely better in medium / large environments than a lot of other 1s. There are way more train wrecks to maintain that especially don't have any documentation or the libraries have gone dead.
It's an uphill battle, but it might just climb the hill because it's still such a behemoth.
And now let’s talk about .collect(toList())…
And records which look like ugly beans…
Java is the land of the verbose. But it can probably be solved with 9 extra characters on every line.
That was in 2008, we’d be happy by now; and Java had no qualms asking everyone to change the package names from javax’ to jakartax’ in Java 21, so they should have issued a java.collections package and deprecated the lists i java.utils.
95 more comments available on Hacker News