the people that work on Java & the JVM are very smart.
it has become a best of breed language - hell its better than Go for industry purposes.
the drawback with Java will always be the CULTURE - (maybe someone can insert a quote of how in physics progress is only made, when old physicist die - I don't wanna be morbid ) but with Java same that's when the culture will change.
All those people using typescript (could be using Java - but the culture doesn't want them and consider them heretics for not embracing religion of OOP and FactoryFactory)
> for not embracing religion of OOP and FactoryFactory
Not the case today. Of course, crappy code (or questionable patterns) can be found in all languages, and java community had made some innovations in the area early on, but today we have a different picture.
FactoryFactory has gone mostly extinct, the most likely place to see it is “dailywtf.com”.
We now know that we prefer composition over inheritance, we have stream api - language and community evolved, old patterns are not neccessary anymore to solve same/similar problems.
> We now know that we prefer composition over inheritance
When people say "composition over inheritance" in Java discussions, they usually mean the trivial modeling rule: prefer has-a over is-a.
But that’s not what composition is really about.
The deeper idea is interface composition -- building types by composing multiple behavioral contracts behind a single cohesive surface.
Java provides inheritance and interfaces, but it doesn’t provide first-class delegation or traits. So most developers never really practice interface composition. They either subclass, or they wire objects together and expose the wiring.
The slogan survived. The concept mostly didn’t.
The manifold project, for example, experiments with language-level delegation to make interface composition practical with Java.
it really depends on your project, and what framework(s) and libraries you choose to use.
Java still has a tonne of legacy projects using old(er) frameworks that rely on such patterns - spring has some old versions which is like that, and i am certain plenty of java projects are retaining those old versions due to lack of desire to upgrade.
If you're starting a greenfield development in java, you surely would not befall into that factoryfactory pattern (unless you're just copy/pasting old projects around...). But i imagine there's way fewer greenfield projects compared to older projects requiring maintenance.
It's still going to be hard to overcome the stigma of ex-Java developers coming into other languages and bringing their overly complex ideas with them. But I am happy to hear Java itself is evolving and I hope that limits the downstream effects of it being one of the most popular language a lot of devs start on.
It's getting better, it doesn't all have to be Spring Boot and JBoss.
There is quarkus, helidon and micronaut for slimmer more modern backend frameworks. jbang for scripting (think uvx, bunx), Tambo UI (https://tamboui.dev/) for terminal UIs, and more.
Along with all the new Java features that help you write much simpler code - eg. virtual threads, structured concurrency, stream gatherers, and performance / resource improvements.
It's not all there yet, but I think the next few years things will come together nicely (however a better build system is sorely needed - one of the things that Go / Rust did right).
If someone reads this and wonders what JBoss is, the contemporary variety is called WildFly and it is actually rather easy to install and play around with.
I've found it quite satisfying compared to the other "new" ones.
As for the original topic, I just want to echo what others have said, and say that I am happiest in Java when writing it as if it were Golang code. That an the first-class runtime and performance and deep ecosystem make it a great choice in 2026.
It’s still very much an annotation festival in the code, making the framework quite lengthy to learn for newcomers (gotta learn Java and the whole quarkus annotation DSL with it).
Go is verbose, but it is much more explicit and only uses standard language things instead of a whole annotation DSL.
Having used micronaut for a few years now, I hate it.
Maybe it's innate to trying to use a a fully fledged server-style framework in a serverless context, but I don't think it's suitable. In fact I think the whole idea ("Hey, let's bludgeon spring-like metaphors into an entirely new setting") was a poor one.
Java itself I've enjoyed more and more over time as the language has evolved into something much more expressive, and without all the enterprise crap. My hope is that one day frameworks like Micronaut will end up discarded too.
> a better build system is sorely needed - one of the things that Go / Rust did right
Honestly there are only two reasons I wouldn't pick up Java for personal projects, difficult to build single executable (Graal is still very un-ergonomic), ridiculous build systems.
I can kind of live with former, but Gradle is so very extraordinarily terrible that I don't know where to begin. Problem is, it solves some real problems (in extremely bad way) that people keep using it.
I long of a cargo-style revolution in Java world. (No, the newly popped up alternatives haven't really cut it so far)
After ~13 years of working with C#, I moved to Kotlin. It's such a beautiful language. When I have to read docs for a Java lib I realize why I like Kotlin.
I want to say culture around Java doesn't have to change, new culture is growing around succinctness (if not simplicity) of Kotlin, and it gets most of the benefits of Java ecosystem.
I must say I prefer C# over Java. They're pretty similar in a lot of ways, but LINQ is much nicer to use than the Java streaming equivalents. And there are some odd warts like Java lacking unsigned types.
As a Go developer, this is right on the mark. I’ve been hearing good things about Java lately, so I decided to check out the language for the first time since 2012 or something. And I was impressed!
The language maintainers have added so many great features while maintaining backwards compatibility. And slowly but surely improved the JVM and garbage collection. So after toying around for a bit, I decided to write some personal projects in Java.
After a week, I gave up and returned to Go. The build tooling is still an over engineered mess. Third party library APIs are still horrible. I will never invest even 5 minutes in learning that horrible Spring framework when stuff like Django, Rails, or the Go ecosystem exist.
The community, and thus the online forums and open source libraries, still approach engineering and aesthetics in a way that is completely foreign and off putting to me.
> Spring framework when stuff like Django, Rails, or the Go ecosystem exist.
Django and Rails have a very similar model to Spring, so frankly this is just "I was lazy to learn a new tool and it must suck" kinda take. Is there a learning curve? Sure. Does it worth it? I would say for typical CRUD stuff, yeah. No matter how trivial it is you will likely end up needing something that is a single annotation away. But you may want to try quarkus over spring.
I wonder if at we are standing looking at the smoking field of programming languages created over the last 50 years and gazing at the final survivors, of which Java is definitely one.
Why would anyone create a new language now? The existing ones are "good enough", and without a body of examples for LLMs to train on, a new language has little chance getting traction.
I learned IBM /360 assembler when I started in computers a long time ago. I haven't seen a line of assembler in many decades, but I'm sure it's a viable language still if you need it.
Java has won (alongside many other winners of course), now the AI drawbridge is being raised to stop new entrants and my pick is that Java will still be here in 50 years time, it's just no humans will be creating it.
I'm writing my own programming language right now... which is for an intensely narrow use case, I'm building a testbed for comparing floating-point implementations without messy language semantics getting in the way.
There's lots of reasons to write your own programming language, especially since if you don't care about it actually displacing existing languages.
Most of my 20 years of experience is Java. Now 3 years into a new job mostly using Python to build microservices. I feel much more productive using Python (plus uv, ruff and mypy for fast repeatable package management, linting and type checking). I see Python having a trajectory to keep improving and gaining more adoption - eg Python keeps growing in popularity https://survey.stackoverflow.co/2025/technology/. It will have real threads soon and better type checking with ty (thanks to astral who also make uv and ruff). Python gives an incredibly tight integration loop since you don’t wait on compiling. Our kotlin projects are always at least 2x slower for ci/cd builds. I like typescript, but working with it in IntelliJ is incredibly slow.
> Why would anyone create a new language now? The existing ones are "good enough", and without a body of examples for LLMs to train on, a new language has little chance getting traction.
Compiler writing can be an art form and not all art is for mass consumption.
> Java has won (alongside many other winners of course), now the AI drawbridge is being raised to stop new entrants and my pick is that Java will still be here in 50 years time, it's just no humans will be creating it.
This makes no sense to me. If AI possesses intelligence then it should have no problem learning how to use a new language. If it doesn't possess intelligence, we shouldn't be outsourcing all of our programming to it.
What advantage do old languages have that can’t be overcome or at least reduced to insignificance?
The 50-year head start in training data, runtime, and ecosystem? That may not be much, because LLMs are rapidly accelerating software development. LLMs can also generalize: take what they learned for one language and apply it to a “similar” language (and I think most modern languages are similar enough for broad effective translation: all have records/unions, objects, functions, types, control-flow, exceptions, and more). Some fairly recent languages (e.g. Rust, Swift) already have comparable runtimes and ecosystems to older ones, from human-driven development acceleration and concept generalization.
In a recent study, LLMs solved the most exercises in Elixir (https://autocodebench.github.io Table 4). Anecdotally, I’ve heard others say that LLMs code best in Rust, and (for UI) Swift. More importantly, I don’t see an older language advantage that is widening from LLM use; an older language probably is better for most use cases today, but any written code can be translated or regenerated into a newer one.
Programmers would create a new language when there is a fundamental change in hardware architecture such that the assumptions underlying the old programming languages no longer apply. Java is probably a poor choice for writing software in which most computation happens on GPUs. But I agree that someone (or something) will still be using Java to write new line-of-business applications in 50 years.
Same reason you'd ever create a new language — to start anew, breaking free from the shackles of backwards compatibility of the old language, having learned the lessons of the past.
The AI angle makes even less sense — surely we will want to create languages that
are tailored for them.
What do you mean by "better than Go for industry purposes"?
I don't understand what "industry purposes" means and in what aspects Java is better than Go in your opinion (I can think of some myself, but I'm interested in your perspective).
Not the GP, but for really large code bases, Go is missing a few features that I've noticed:
1) No immutable types. My work team is a huge user of immutable data stuctures in Java to make sure data passed around to other teams isn't changed. Go doesn't really have a good way to do this.
2) Refactoring can be really annoying (or at least really noisy) because of public/private being defined by capitalization of method/field names.
3) Error handling isn't great. I love Go's errors being just normal values, but the `error` interface is awkward when trying to figure out what kind of errors can be thrown without having in-depth knowledge of the kinds of errors that can be returned. We regularly need to make different decisions depending on the kind of error returned. Knowing which errors can be returned in Go is not defined by the method being called (only in comments).
Ya, that seems to be a misunderstanding. "Industry purposes" covers a huge range of stuff. Go is pretty good for systems programming where Java isn't really an option due to the fundamental limits imposed by garbage collection and lack of pointers. Java is pretty good for higher-level application development where occasional GC pauses are tolerable (the GC pauses are rare and fast now, but they still rule out using Java for certain purposes).
And Java has some advantages that are hard to beat. It performs better than Go and builds just as fast (at least when not using some popular build tools) while offering unmatched deep, low-overhead observability.
People might think they may enjoy another language more, but the portion of people who eventually come to regret choosing Java is probably lower than that of any other language.
Do you have some sources or experiences to share on this topic? I'm very curious. My experience is the complete opposite.
At my previous job there was a Java web application and running in Kubernetes (1 vCPU and 1Gi of memory) was able to deal with at most 80 requests per second, using up almost the full 1 vCPU and ~600-700MiB of memory. That was a bit disappointing, since we were supposed to support at most ~1000rps on this API, 13+ pods is a lot, and we felt "software could do better".
A reactive guru from another team told us we should use a reactive stack, so he came in and rebuilt the app using the reactive stack. Now it was doing about 120rps on one pod (about the same memory usage), which was a good improvement, but still disappointing.
One guy on the team was motivated to rewrite the API in Go as a proof of concept, and we were blown away. With the same 1 vCPU it was now able to handle 400 requests per second, while using ~100-200MiB of memory, and having approximately 20% better response times.
> builds just as fast (at least when not using some popular build tools)
I find this a little bit of a cop-out, because almost everyone is using the popular build tools. And it's quite a chore to build a full application without those popular build tools. With Go, all batteries for building are included.
> It performs better than Go
> and its optimising compiler and GCs blow Go out of the water without breaking a sweat.
Well, dandy! Since the performance gap is that big, it should be trivial to get hard data backing that up. Mind linking some representative benchmarks?
Dang, I just can't wait, same resource usage for Go and Java (RAM in particular, if you would), and Java performance that "blows Go out of the water".
> and builds just as fast
Oh? But you're comparing apples to oranges.
Go builds its source into a machine code executable, all optimizations are applied at this step. This then gets directly executed by the CPU.
Java "builds" its source into bytecode. It's a trivial transformation that then needs to actually be compiled and optimized by a virtual machine at runtime before the CPU can run it.
So then, what build time does Java have when doing AOT compilation? Again, hard numbers please, thanks.
> while offering unmatched deep, low-overhead observability.
> People might think they may enjoy another language more, but the portion of people who eventually come to regret choosing Java is probably lower than that of any other language.
Very believable statements, given that you literally work on Java for Oracle :) No need to bother to make a disclaimer about that I guess. Shameless.
Front page, 82 comments, comment 2 hours ago…why is this the top comment? “People who write Typescript could just be writing Java except they’re scared of being outcasts for not using design patterns” is bait, not a serious technical opinion.
I write TypeScript daily and honestly it is not about being scared of Java. The ecosystem just makes more sense if you are already building for the web. You write your frontend in JS/TS, your backend in the same language, your build tools understand it natively, and you share types between client and server. That is a hard thing to replicate in Java even if the language itself is technically better in some areas. The barrier is not cultural fear, it is practical convenience.
With SSR/HTMX/HATEOAS the amount of code executed on client side is relatively minor and does not justify the unstable JS/TS tooling and frameworks, and the security nightmare which is NPM-based supply chain.
Different tools for different purposes...which is good/right.
TypeScript is a superior programming environment for the browser, for sure.
Using it on the server? Why not, if you're not trying to scale (in capacity, or functionality).
Language-agnostic serialization exists for a good reason. It's not always right, but it's almost always the right thing to do.
The biggest problem with Typescript in the modern era is that LLMs are pretty bad at it, at least as compared to some other languages that are more well suited to LLM generation. What you say may have been a boon in the olden days, but it is hard to justify now. It is difficult to avoid Typescript/Javascript in the browser, sure, but now it's just as fast to duplicate everything in another language for the backend and at least gain the advantages on that end.
What if you have a mobile app? Rest APIs? The argument doesn't work. Every backend language has ways to generate specs/types/clients from the APIs code.
> You write your frontend in JS/TS, your backend in the same language, your build tools understand it natively, and you share types between client and server.
that's an excuse imho. It's a post-facto justifying using js on the serverside because of familiarity.
I know because the exact same reason was given for GWT (google web toolkit), and that failed pretty horribly (despite it being quite good imho).
> hell its better than Go for industry purposes. [...] the drawback with Java will always be the CULTURE
The industry purpose for Go is that all codebases look more or less the same, so workers can jump into any project they've never seen before and instantly feel like they wrote it themselves. Google talked about that a lot around the time Go was released. It is why they created it instead of just adopting Haskell or something.
Some of that simply comes down to the language not allowing much creativity, but without the culture developers would still find a way to mess with outcomes. You can still write crazy Go code if you want to. The culture is the piece that matters. If Java doesn't have the culture, how does it fit in industry?
Maybe this is just a question of taste but I never could get along with Javas (or Kotlin's) tooling.
Primarily working in Vim/Helix works for most languages from Nix to Typescript or Rust and C, but Java just never worked quite right. It also generally felt like it had a worse story around tooling from a DX perspective, something like Golang or even npm feels a lot lighter than the molasses of JDK management and gradle et al.
Besides doing yourself a disservice of not using a proper IDE, what exactly makes Java not writeable in vim or the like? Like it's a pretty simple language with not much magic going on.
On the contrary, as someone that earns their bread using both ecosystems, .NET is still pretty much tied to Windows, regardless of .NET team efforts, most shops going with macOS or Linux are former Microsoft shops saving on server licenses or giving Macs to their devs.
There are many platforms where .NET doesn't have an implementation, a phone to call their own (even if ART isn't proper Java, WP is no longer around), embedded systems, including factory and military weapons deployments (PTC, Aicas, microEJ), copiers (Xerox, Ricoh), phones (Cisco),....
C# is definitly better than Java dealing with value types and low level programing, or being embraced by the game development community, however not sure if the featurities of last years is the right path, I am starting to feel I should just reach directly to C++ instead.
Bright future for it just means it is not planning to become 40th or 400th.
(My prediction - in next ten years java will always be among top 6; new language might come to the very top and some leapfrogging game between c# and java)
I dont think the Spring ecosystem is bad. In fact, its one of the more stable frameworks. Even spring AI which is built for AI agents a new use-case is very intuitive if you take time to learn its abstractions. Usually doesnt take more than a day of reading docs and writing some try-out code. The thing I really like about Java is the stability of its packaging ecosystem. Maven is XML (yuck) but is okay with the IDE integrations. Gradle has advanced features often missing in Python / Go such as build caching. The OOP stuff is also good because it scales with very large code bases. In, fact frontend esp React adopted a functional style which leads to complexities associated with hooks. A mixed approach is usually better. Overall, the only bad thing are the multiple unnecessary abstraction layers which are a pain in any language. Rest of Java is quite good.
Enterprise space architecture is not picky, all programming languages get a place when they manage to hit big at corporate life.
It can be Yourdon with C and Pascal, Booch with Smalltalk and C++, Patterns with Smalltalk and C++, UML with Ada, C++, Smalltalk and Java, Rational RUP , Java and .NET application servers, Kubernetes with WebAssembly microservices,....
Ever looked into Typescript with effects, pretending to be Haskell?
> All those people using typescript (could be using Java - but the culture doesn't want them and consider them heretics for not embracing religion of OOP and FactoryFactory)
I assume you're specifically talking about the backend and not suggesting that people write Applets or use GWT or something.
Says a single guy who may have coined the term, but that's not how words work. The industry's millions of devs use it differently, so the de facto meaning is that java is an OOP language, and the original is closer to the actor model.
The problem is that many jobs with Java (that I've found) lean so heavily towards OOP that it's part of the job description. I just don't enjoy OOP and find that there's almost always a simpler approach, and to have it prescribed as part of the engineering culture will always steer me away.
Most of backend development on Java is procedural with OO syntax and ability to replace something in the chain of calls with stub in tests. Spring beans are usually stateless singletons containing a few references.
Yet if you ask people in the bay area, especially the those who are under 35, they would tell you that "Use Java? Over my deadbody". It's just amazing that people always chase shiny new things.
With LLMs as they currently stand, and with the reasonably confident hope they will get better why even have anymore languages. Shouldn’t we just have everything coded in the most performant language which would be Assembly or C?
With all due respect, I'm fairly sure that anyone using "VM" the same way as you do here really think of it as a container or what.
It's a runtime, and go also has a similar, fairly fat runtime. It's just burnt into the binary instead of being shipped separately. (Hell, even Rust has a runtime, it's just very very lean compared to languages featuring a full GC like go and java)
I wouldn't count myself as a JavaScript person at all, and usually avoid it where I can, going to some length, to make pages static, if possible. So I am not exactly in the group of people you are attacking.
However, I am afraid of the Java coder who is decorated as senior, has sway due to their position, and who will tell me, that something, that is a simple function, shall not be a simple public static "method", but must be wrapped in yet another object, which I need to instantiate, because OOP, and because obviously I don't know what I am doing, or because it doesn't fit existing "coding practices/style" or "Java style". I am afraid of the Java coder, who for years has not touched anything but Java, because their jobs didn't require anything else, because so many companies want Java. I am afraid of the one who throws around jargon like "dependency injection" all day, without ever using simple terms, or realizing what those things are looking like in another paradigm.
Lord, please save me from ever having to work with such obnoxious and uninformed, learning resistant people. This actually may be a straw man, but even one such character matching one or more of those traits, seated above at the seniority ladder will make a mess, that everyone else has to live with.
I mean, sometimes managers are uninformed and say stupid things?
You can use any of the other jdk builds from the plethora of other vendors and have zero interaction with Oracle.
I absolutely hate Oracle as a company, but they've really done a good job with Java stewardship. They actually open sourced the entire language / jdk and a lot of the tooling that used to be proprietary.
They still love to play the old Oracle tricks, so I'd rather not use any of their distributions. But the actual work that they do on the ecosystem has been a positive in my opinion.
I didn't use Java since 7, but from people that do - nowadays you basically don't code Java, you code Spring Boot. And that has all the bad things you think when people say "Java".
There are more Java devs than people in my home country. Like how could you even give a single description for all of them? They all work on vastly different stuff, from low-latency trading to robotics, to regular old CRUD. Not even the CRUD part is as monotonic though as you make it out to be.
Spring Boot isn‘t bad. It‘s opinionated about configurations and dependencies. Its main advantage is that you can start shipping production-quality code very quickly, focusing on business problems rather than anything else. Vibe coding on it is more or less stable, entire apps can be built solo in a few months. And it‘s easy to do fullstack with SSR based on Thymeleaf and Htmx. It is absolutely superior to anything that exists for node stack.
And then there‘s also Micronaut, if you prefer compile-time setup to Spring.
There's a lot of programming that has nothing to do with SpringBoot - and I say this as someone who works in a backend team that uses SpringBoot for all our apps.
A completely different culture of Java usage can and does exist a lot of places. It is absolutely true that success creates a certain ossification of practice. But SpringBoot is not necessary, any more than Guice or any other framework-y thing.
That's weird. Back when Java 7 was a new thing, people used Spring (Boot wasn't there yet) even more to compensate for the lack of language features. Also back then most projects still used XML configuration, so you actually write more Java code in modern Spring. Because Spring Boot uses Java configuration classes by default (although you can still use XMLs if you need for some reason).
> Nowadays you basically don't code Java, you code Spring Boot. And that has all the bad things you think when people say "Java".
Subjective experience, but largely agreed.
Vague rant that summarizes my own experience: major version updates kind of suck, even if Spring Boot is still better than regular Spring (I've gone through the XML hell, was not fun, even less so with a separate Tomcat instance that we had to deploy to, instead of an embedded one). In practice their huge effective pom.xml also leads to conflicts when your package needs something else and it feels a bit arcane to override things. There are things that have underlying technical reasons for being the way they are but seem stupid from afar - like how @Transactional doesn't work when called from within the same bean. Personally I also prefer code over convention for configuration and initialization so the whole annotation driven setup feels quite annoying and difficult to debug when things go wrong - but even the code configuration isn't always great and sometimes it feels like they have abstractions for the sake of abstractions. Spring Boot also often brings friends like MapStruct or Lombok or Mockito which add even more dynamic behavior and issues when you update JDK, alongside slow testing with JUnit and unpleasant debugging of jumping through numerous abstraction layers. You don't strictly have to, but people will.
I probably should have written down every complaint with exact details (so those could be picked apart as user error) over the years that I've been unfortunately maintaining and building shitty software with Java, but I will say this - modern Spring Boot isn't wholly horrible, it has a pretty rich ecosystem and you can do a lot of things with it, but the overall vibe I get from it ofen can be summarized with "Eww." I'd end up using it because I have to, or because it's a means to an end ("Hey, we need to build an event-driven system to integrate with a bunch of others, you have two weeks"), not because I want to.
For the sake of comparison, I believe that for plenty of the folks even Dropwizard would be worth a look: https://www.dropwizard.io/en/stable/ it is more or less like some glue around a bunch of idiomatic packages in the Java ecosystem and it's not horribly hard to integrate something that you want yourself (e.g. Dagger 2 for DI, at this point I'll take anything that does as much as possible at compile time https://dagger.dev/dev-guide/).
Or, for a more modern spin, Quarkus isn't too bad either https://quarkus.io/ or maybe Micronaut https://micronaut.io/ or perhaps Helidon https://helidon.io/ with neither of those being strong recommendations - figure out what you like for yourselves. For people that have been luckier than me, that might as well be the very same Spring Boot, just on better projects. JVM is a pretty cool piece of tech though, and so are the JetBrains IDEs with their refactoring features and nice Maven integration.
I program in Java for more than 15 years now. I can resonate with people hating the language from it's early days due to the experience with all the enterprisy features and over abstractions. Or confunding Java with the Spring ecosystem. But Java came a long way over the years. It's now what many would call a "modern" language. It's less verbose, has many of the features people find appealing in Scala and Kotlin and it can even compile to native binaries using GraalVM. This made building CLIs in Java feasible. Or lambdas.
I recently worked on a Go project and my task was to make it more configurable at build time and start time (add plugins / addons, make it possible to reuse from other libraries and tools). Turned I had to create *Factory and *Providers, even though I did not want to.
It's easy to avoid "AbstractFactoryProviderBuilder" if everything is hardcoded. Try to make it reusable and extensible, and I bet you write one yourself.
> It's easy to avoid "AbstractFactoryProviderBuilder" if everything is hardcoded. Try to make it reusable and extensible, and I bet you write one yourself.
The first domino is opting for OOP. AbstractFactoryProviderBuilders are just the inevitable downstream consequence of that initial choice. No need for factories if you don't traffic in objects in the first place.
Lack of virtual threads was its biggest remaining problem because this made the common ways of doing cooperative multitasking very ugly. Go's big thing was having that from the start. Maybe now that Java has it too, it's set?
Though JS will still have the least boilerplate because of the way it handles types.
IMO, Kotlin coroutines are better of Go's goroutines, although they are a little different beasts to compare honestly (apples and oranges). Go inits goroutines on stack, but min size is 4KiB, so it's not trivial to grow them. Also you need to watch over and destruct goroutines manually to prevent memory leaks (using
var wg = sync.WaitGroup
defer wg.wait()
wg.Add(1)
go func() {
defer wg.Done()
}
)
And create a separate channel to return errors from a goroutine. Definitely more work.
I think there is something to say for compiling to native code, having binaries in the ~25 MiB range, being able to run in distroless containers, being able to run a web application with less than 100MiB of memory and startup times measured in milliseconds rather than seconds (sometimes dozens of seconds).
Don't get me wrong, I like Java and don't very much like the Go language. But Java has a lot to improve upon still.
I think astronomers could measure the age of the universe in nano-Valhallas. Every year, it feels 50% closer to completion...
In all seriousness I'm happy with what Mr. Goetz and the team have done. Sealed interfaces (java 17) + exhaustive switch statements (java 21) means we now have union types in java! And instead of jumping on the async/await bandwagon we now have a more general solution that doesn't lead to API duplication (virtual threads). But Valhalla has been a veeery long time coming.
'Tis true. At the same time, Project Valhalla will be the most significant change to the JVM in a very long time, and probably its best chance to stay relevant in the future.
Glad to see this being removed. Java plugins especially on Linux were awful and required by tons of corporate stuff. Anyone remeber IcedTea Web? A functional and opensource Java plugin and Java Webstart implementation?
Note that the the Java plugin and webstart was removed a long time ago.
I personally regret that the API was removed as it's a few classes and they are still used. Just search JApplet on Github. It's also possible to run applets in the modern browsers with WASM or in Java IDE's as plugin.
I made several Webstart corporate apps back in the day! The infrastructure was pretty neat, when it worked. And it was a whole lot better than JS back then, still in the IE6 times.
If we ignore the fact that value types likely won’t ship before we have flying cars, Java has evolved greatly. I really like how they’ve solved concurrency, but I dislike how they’ve handled modules but this a minor issue.
The main problem with Java has always been its build tools. They’ve consistently been bad and continue to be. Even today, creating a bundled application with a stripped down JDK with jlink and jpackage is incredibly painful. You’ll need extensive knowledge of the Java CLI, modules, build tool plugins, or tools like Mill which simplify using jlink and jpackage, but even then it remains complex and frequently fails. In reality it should be as simple as something like "java package". Even these days, I frequently see Java developers presenting their desktop apps on Reddit and if you look at how they deploy them, it's often a fat JAR because they struggle to use jlink and jpackage effectively. Ironically, even generateing a fat JAR can be challenging.
As someone who has spent over two decades developing desktop applications including witnessing the shift to horrendous Electron firsthand I can tell you that this was a primary reason Java basically vanished from being so prevalent on desktops. Inexperienced developers often struggled to deploy even simple Java applications, grappling with either runtime incompatibilities (Ironically, developers are somewhat reintroducing the same problem with WebView-based applications) or having to tell their users how to launch a Java app. While some claim desktop apps are dead – which is nonsense – the same applies to CLI applications. CLI apps remain prevalent, primarily written in native languages or Golang, sometimes even Node or one of its derivatives. Rarely Java for the reasons I just mentioned and don't get me started with Graal Native. If someone decides to write a simple trivial CLI app in Golang, they'll simply build it with a single command and be done with it. With Graal Native, you'll have to go through using the tracing agent, and if you're lucky you'll have a fat native executable after minutes of compile time. Forget Graal for a minute though. Java would already go a long way if bundling your application with a stripped down JDK (jlink) was as easy as typing in a single command without having to deal with complicated Maven or Gradle plugins.
TIL Mill, I've been in build hell trying to package a javafx GUI gradle project that depends on a non-module-ified lib (usb4java, long story, no I can't use anything else). Beryx/badass failed entirely, was able to get something working with Gradle doing jlink and manual CLI jpackage ...
But tbh the whole experience makes me distrust the Java ecosystem if you're supporting anything that is slightly out of the community's view or priorities. Even JavaFX shows very patchy support for certain very standard UI concepts, and the situation with packaging is bad as you say.
Anyway, is mill worth switching away from Gradle? (Does mill integrate at all with idea?)
Mill does work with idea (via the build server protocol), and the ideas behind it are very sound (a build tool is basically a function calling other functions - on which they depend. You just want to parallelize their running and cache their results.
But it does have a learning curve and you may sometimes end up having strange error messages. (As an implementation, it's basically Scala macros turning normal looking scala functions into a static task graph). It is getting better and better support for mainstream java build setups, and it's possibly the best tool for something very custom. In between the two extremes, you may or may not have a better time with Gradle/Maven.
> Anyway, is mill worth switching away from Gradle?
Hard to say because I don't know how someone without Scala experience would fare with Mill. Then again, I think anything is better than Gradle. Really, anything. I even think I would do everything by hand rather than using Gradle. Also the creator of Mill is a great guy. Rest assured, if something's confusing or not working he's gonna help you out or fix it if necessary.
I feel like Gradle is only relevant for Android. All other projects are fine with Maven (and I like a lot that Maven doesn't allow to code in the build config, any complex logic should be extracted to a custom build plugin, using real code. I just have PTSD after some build.gradle monstrosities).
I was pretty surprised when I learned recently that the Java alternative for green threads doesn't use colored functions. It put Java in a higher place in my perception.
It doesn't completely solve function coloring though. Causing carrier threads to get pinned is still not good, similarly as calling blocking function from async function is not good in colored systems.
Any time you have a barrier between one function being able to call another. The original article on this called them red functions and green functions. A green function can call a red function but a red function can't call a green function.
In terms of async, it's when you have to have a function with "async" attached to it and making it so that only other async functions can call async functions.
It ends up creating a weird circumstance where you can end up with a lot of duplicated APIs, particularly in libraries, because you are providing both async and non-async versions of functions.
The term comes from an old blog post [0] about different kinds of effect systems. Every function has a color, and every colored function can only call functions that are compatible with it, usually of the same color. The net result is that you end up either duplicating a lot of your common code so you have compatible interfaces for all the different colors (let's call that "separate but equal" if we're feeling spicy), or you end up shoving round pegs into the square holes of your dominant function color.
The terminology is used to talk about languages that have async and sync functions where you declare (or color) the function as either async or sync.
In these languages it's pretty common for the language to enforce a constraint that async functions can only call other async functions. Javascript / Typescript, Python are popular examples of languages with colored functions.
"green threads" is generally how I see these systems identify as "non-colored but with async-like performance" fwiw. or "fibers". otherwise it's "async" or "coroutines".
There are different types of coroutines. The C++ type are sometimes called "stackless coroutines". With stackless coroutines you can't yield from a nested function call. Stackless coroutines are basically generators where you can pass arguments through resume, and async/await is effectively a form of stackless coroutines with yield/resume semantics that aren't fully generalized as coroutines, but oriented toward some bespoke notion of concurrency rather than as an abstract control flow operator.
"Stackful coroutines" allow yielding from any arbitrary point. They're basically fibers, except with the explicit control transfer and value passing yield and resume operators; there's no hidden or implicit control transfer like with green threads. Though, some people would argue allowing any function to yield without announcing this in their type signature is tantamount to hidden control transfer. Personally, I don't see how that's different than allowing any function to call other functions, or to loop, but in any event languages are free to layer on additional typing constraints--constraints that can be tailored to the desired typing semantics, rather than dictated by implementation details.
Stackless coroutines are typically implemented as a special kind of function whose state is allocated and instantiated by the caller. In contrast, stackful coroutines are typically implemented by reifying the stack, similar to threads. The "stack" may or not be the same as the system's ABI stack.
In stackful coroutines, unless there are additional typing constraints imposed by the language for hygiene reasons, any function can typically be called as a coroutine or use yield and resume. There's no need to compile functions into special alternative forms as call frame management works the same whether invoked from a coroutine context or not.
I have been using Java since version 1.4. Both the language and its ecosystem have come a long way since then. I endured the height of the EJB phase. I adopted Spring when version 1.2 was released. I spent hours fighting with IDEs to run OSGi bundles. I hated building UIs with Swing/AWT, many of which are still in use today and are gradually being replaced by lovely JavaFX. When I look at code I wrote around 12 years ago, I'm amazed at how much I've matured too.
> I hated building UIs with Swing/AWT, many of which are still in use today and are gradually being replaced by lovely JavaFX.
Dude JFX yielded what was called RIAs to JavaScript like almost 15 years ago. Of the three major GUI toolkits Swing, JavaFX, and SWT it was Swing that gained HighDPI support first (10 years ago), and continues to be the base for kick-as IntelliJ IDEA and other Jetbrains IDEs.
Swing was simpler in some ways than JavaFX. I still remember JavaFX treeview taking 3 Generics and I was unable to figure out what one of them is for from the docs. Had to go on Stackoverflow, where someone said it basically didn't matter. But JavaFX looked great at the time.
As someone who has been out of the Java world for many years, but recently forced back into it due to Android dev requirements, Post lawsuit, what is the relationship between Android (Google) and Java now? When can we expect 26 on Android? On that note, why is Android always so far behind? Is it because Kotlin is primary or is it deeper? Did the lawsuit play a role?
Android has their own runtime (creatively named as Android runtime), which does not run java byte code, but their own binary format. JVM class files can be compiled to that format, but the support for that always lags behind OpenJDK java versions.
Part of the reason kotlin became the de facto language on the platform was that they supported only terribly old Java at the time, that didn't even have lambdas even though it was already out.
The problem is that most of the Java libraries want to follow the desktop/server, aka the OpenJDK scene, but that would make them incompatible with Android so there was/is some incentives to bump up the version they support.
The new (ish?) Android UI toolkit is only useable from Kotlin and is implemented fully as a compiler plugin. Google has been clear that Kotlin is the Android language now and that's where new features are going.
I do really need to give flutter a try. My only reason I haven't yet is that I have no desire to learn Dart. How do you (or anyone) like Dart compared to Java or Kotlin?
I haven't read a Java manual since the time of Java 8. Do you have any books or other resources you could recommend to catch up with all that has changed in these years?
All the changes look great. But I don't know how I feel about the syntax. A lot of things that very well could be first-class just aren't. Instead of a `lazy` keyword, we get `LazyConstant<T>`.
I'm sure there's reasons as to why. I just don't know them.
It‘s easier to evolve library code. If Java would ever infer type of constants from initializer (makes more sense than a new keyword), it could look nice and powerful:
Once introduced, keywords and Java syntax is nearly impossible to change or to remove. If it's possible to get the job done using a class, perhaps with some JVM magic, it's not wise to whip out new syntax.
Still a lot, but in absolute terms the majority of Java applications are 8+ for 4-5 years now, according to Oracle's statistics - so they are a minority. It's just that there are so many java projects that it is still a huge number.
Seeing as we're having a $LANG war, after 15 years in JVM land, I moved to a Python / Go shop, and fuck I miss Java.
Not so much the language (although modern Java is pretty slick), but the stuff surrounding it.
* No typosquatting issues because every package has a group id verified by real humans and DNS TXT records.
* JMX as a standardized mechanism of exposing ways to interact with running code / expose metrics. (Even if you have to deal with the stupid ass protocol where you have to connect using a DNS identity the JMX server recognizes)
* Logging libraries that give people running the code control over what gets logged and how, not the developers (looking at you Golang, wtf is with your logging approach where devs have to explicitly consider the fact that you might want to run logging at DEBUG and code it into your start up args?)
* The ability (via JMX) to set, at runtime, one particular logger in one class or file to a desired logging level without restarting the application.
* The performance of the JVM.
* The vast FOSS ecosystem.
* Not having to fight C build chains for that one dependency that's using CGo or a Python wrapper around a C lib that no wheel supports for your given tuple of Python version, OS, and architecture.
Honestly, as someone who is a self-taught developer who taught himself in Python, I thought I was coming home to my first love.
Turns out, I really hate the horrible things you can do in Python - looking at you Django, don't be so dynamic your brains fall out - and really dislike the experience of trying to run a Go service compared to a JVM service.
Java and its ecosystem is just good at getting shit done in a predictable manner at both the dev level and ops level.
> * No typosquatting issues because every package has a group id verified by real humans and DNS TXT records.
While I think this is a huge boon, have you ever published a package on the Maven Central repository? I must confess I haven't in a few years now, but when I did until ~3 years ago it was a major pain in the ass. And every release again.
I think there's something to say about Go's model where the package is just in some Git hosting and a release is just creating a tag. As a package maintainer, this is just pure bliss compared to the Maven thing.
> and really dislike the experience of trying to run a Go service compared to a JVM service.
What are you running into specifically? I have the complete opposite experience. With Go, 1 small binary comes out that I can run anywhere (and put into a distroless container), whereas with Java I have to find a way to somehow run a full JVM (most often with (large parts of) an OS too).
Perhaps you're alluding to the things you can do with JMX, but I have never really seen much benefit in that. I found it trivial to add similar functionalities with internal HTTP endpoints easily. But since I don't have much experience in this particular area, probably I'm missing something.
> While I think this is a huge boon, have you ever published a package on the Maven Central repository? I must confess I haven't in a few years now, but when I did until ~3 years ago it was a major pain in the ass. And every release again.
I’m really surprised to read this. It is well-documented process. I regularly publish something there, never had problems. Why was it different for you?
Yeah, publishing a package is a PITA for the precise reasons of maintaining trust in, and the quality of the packages.
That's why you need documentation to publish to Maven central, that's why your package needs to specify its license, GPG checksum etc.
Yep, it's a lot harder than publishing to Pypi or Cargo, but I'm now firmly of the opinion that it's good that it is. The gates between you and publishing a package are there for deliberate reasons.
> Perhaps you're alluding to the things you can do with JMX
Yep, specifically things like "set the logger org.foo.package.Bla to DEBUG while the app is running", without restarting and without having to add an internal HTTP endpoint to be able to accomplish that. It's just there for free, every JVM logging library and metrics library exposes itself via JMX for that same reason - ease of observability, without restarts, without custom code.
E.g., I can access Kafka client metrics via JMX anytime I like. JConsole will even give me pretty graphs.
If I want them in Prometheus, I run the app with a Java agent that takes those MBean metrics and exports them in Prometheus format on an HTTPS endpoint.
I understand you can accomplish much the same with some internal HTTP endpoints, but that presumes they exist.
If you need them, but that microservice hasn't deliberately exposed them, you need to change the code, and then make a new release, which slows down your ability to diagnose what's going on right now.
In Java, every observability library exposes itself via JMX, all you had to do as a sysop was ensure that the JMX port was open.
Also, the ability to easily observe the metrics of the VM itself via JMX so I can see what's going on with GC in a running app without having to explicitly expose that.
If you suspect a memory leak, or something that should be GC-able isn't, or that there's far too many object allocations occurring that's smashing the first gen portion of the heap and causing excessive GC pauses, the instrumentation to investigate it as your app runs is right there, it's baked into the JVM.
That's why I miss it - the JVM was built to be instrumented and observed by the people running it.
I really wish Golang and everyone else would emulate the Java approach to observable metrics as well as the Java approach to logging and packaging.
There's no shame in stealing the good ideas Java had, but no-one seems to, to my frustration.
Some of the standard library stuff could be usable from Clojure and other languages. The jvm level optimizations (garbage collection) should benefit all jvm languages. The language changes are mostly not that relevant unless you program directly in Java.
I use Kotlin myself (after doing Java since 1995). Most of the overview here reads like they are adding a lot of stuff that Kotlin has had for many years. Structured concurrency, lazy stuff, etc. You can argue about which language does it better/nicer/etc. but that debate is a bit boring to me. But good for Java developers that they are getting some obviously useful things that so far they never had. Progress is nice. Better late than never.
Java improvements usually have a runtime component, so no, kotlin simply couldn't have had Lazy no matter what. It was just syntactic sugar for a getter.
Sometimes, yes. E.g. if the value types stuff ever gets implemented, that will be very useful for other JVM languages. OTOH some changes are purely syntax sugar in Java itself (e.g. allowing multiline string literals) and those of course don't affect any other JVM language.
I'm pretty sure all of Clojure runs on Java 8, so if you use some new feature I'm guessing you need to provide a fallback - but you're also going to be running on Javascript and other platforms, so that's par for the course
Modern Java is pretty succinct and expressive and I enjoy working with it. Like any long-lived project, Java has its quirks and baggage but you can let go of that baggage if you want. The ecosystem is evolving nicely with new features and it is quite pleasant to work with these days. I’m looking forward to migrate apps at work to 26.
When it was about the 7th incubator iteration, I got curious so I read the actual JEP history, and it had this informative tidbit, also included in the latest release:
"The Vector API will incubate until necessary features of Project Valhalla become available as preview features. At that time, we will adapt the Vector API and its implementation to use them and then promote the Vector API from incubation to preview."
Project Valhalla has been "in progress" for at least a decade now (Wikipedia say 2014). So who knows when we'll actually see a Vector API in preview.
They made the problem complexity of Valhalla ~10,000x harder by very strict backward compatibility needs. Project Valhalla can take many human generations and multi-billion man years to finish as a consequence.
I think Java became popular because of Sun. My experience with Java-based apps is bad. Laggy, resource-heavy, IDE bound, and it causes premature hardware performance degradation.
Google basically played a J++ with Android Java, with Kotlin as their .NET/C#.
At least they are forced to partially update Android Java, now Java 17 subset, so that Kotlin can keep up with was is mostly deployed at Maven Central.
Pretty sure they did a J# ;). But I agree that Kotlin is their C#.
The JDK and JVM has advanced so fast while android has been lagging. It's pretty frustrating, especially because google has been so slow to pull in changes from later java versions.
A part of me wishes that android would just dump their hokey dalvik, ART, and other BS and just use the OpenJDK or a fork of the OpenJDK with whatever special sauce they need. A lot of the project Leyden stuff lends itself nicely to maybe someday being able to run real java on android.
Edit: Apparently android is forking OpenJDK, since Android 7.
No, they didn't. Google happily used regular Java until Oracle played Oracle. Then Google stopped updating the supported Java language version and started diversifying away from Java.
the people that work on Java & the JVM are very smart.
it has become a best of breed language - hell its better than Go for industry purposes.
the drawback with Java will always be the CULTURE - (maybe someone can insert a quote of how in physics progress is only made, when old physicist die - I don't wanna be morbid ) but with Java same that's when the culture will change.
All those people using typescript (could be using Java - but the culture doesn't want them and consider them heretics for not embracing religion of OOP and FactoryFactory)
> for not embracing religion of OOP and FactoryFactory
Not the case today. Of course, crappy code (or questionable patterns) can be found in all languages, and java community had made some innovations in the area early on, but today we have a different picture.
FactoryFactory has gone mostly extinct, the most likely place to see it is “dailywtf.com”.
We now know that we prefer composition over inheritance, we have stream api - language and community evolved, old patterns are not neccessary anymore to solve same/similar problems.
Sample of one - junit (testing lib) source code, from quick glance it seems more procedural than dogmatic OOP: https://github.com/junit-team/junit-framework/blob/main/juni...
> We now know that we prefer composition over inheritance
When people say "composition over inheritance" in Java discussions, they usually mean the trivial modeling rule: prefer has-a over is-a.
But that’s not what composition is really about.
The deeper idea is interface composition -- building types by composing multiple behavioral contracts behind a single cohesive surface.
Java provides inheritance and interfaces, but it doesn’t provide first-class delegation or traits. So most developers never really practice interface composition. They either subclass, or they wire objects together and expose the wiring.
The slogan survived. The concept mostly didn’t.
The manifold project, for example, experiments with language-level delegation to make interface composition practical with Java.
https://github.com/manifold-systems/manifold/blob/master/man...
6 replies →
> FactoryFactory has gone mostly extinct
it really depends on your project, and what framework(s) and libraries you choose to use.
Java still has a tonne of legacy projects using old(er) frameworks that rely on such patterns - spring has some old versions which is like that, and i am certain plenty of java projects are retaining those old versions due to lack of desire to upgrade.
If you're starting a greenfield development in java, you surely would not befall into that factoryfactory pattern (unless you're just copy/pasting old projects around...). But i imagine there's way fewer greenfield projects compared to older projects requiring maintenance.
It's still going to be hard to overcome the stigma of ex-Java developers coming into other languages and bringing their overly complex ideas with them. But I am happy to hear Java itself is evolving and I hope that limits the downstream effects of it being one of the most popular language a lot of devs start on.
It's getting better, it doesn't all have to be Spring Boot and JBoss.
There is quarkus, helidon and micronaut for slimmer more modern backend frameworks. jbang for scripting (think uvx, bunx), Tambo UI (https://tamboui.dev/) for terminal UIs, and more.
Along with all the new Java features that help you write much simpler code - eg. virtual threads, structured concurrency, stream gatherers, and performance / resource improvements.
It's not all there yet, but I think the next few years things will come together nicely (however a better build system is sorely needed - one of the things that Go / Rust did right).
If someone reads this and wonders what JBoss is, the contemporary variety is called WildFly and it is actually rather easy to install and play around with.
https://www.wildfly.org/
I think this is an often overlooked solution to some of the problems we nowadays tend to approach the clown for.
As for build systems, Maven is old and cranky but if something else replaces it, it will probably be quite similar anyway.
10 replies →
I'd like to mention the web framework I'm using these days, Jooby:
https://jooby.io/
I've found it quite satisfying compared to the other "new" ones.
As for the original topic, I just want to echo what others have said, and say that I am happiest in Java when writing it as if it were Golang code. That an the first-class runtime and performance and deep ecosystem make it a great choice in 2026.
1 reply →
Quarkus is better, but isn’t that amazing IMO.
It’s still very much an annotation festival in the code, making the framework quite lengthy to learn for newcomers (gotta learn Java and the whole quarkus annotation DSL with it).
Go is verbose, but it is much more explicit and only uses standard language things instead of a whole annotation DSL.
3 replies →
There's also Javalin for oneshot java projects where you write your webserver like you'd write express.js
Not sure if I agree about the Go build system. Causes me endless issues at work - and my workmates, going by the number of complaints
A friend and former colleague was agog about Quarkus and it does look pretty compelling.
Having used micronaut for a few years now, I hate it.
Maybe it's innate to trying to use a a fully fledged server-style framework in a serverless context, but I don't think it's suitable. In fact I think the whole idea ("Hey, let's bludgeon spring-like metaphors into an entirely new setting") was a poor one.
Java itself I've enjoyed more and more over time as the language has evolved into something much more expressive, and without all the enterprise crap. My hope is that one day frameworks like Micronaut will end up discarded too.
3 replies →
I never want to read another Bean or log4j config ever again.
4 replies →
> a better build system is sorely needed - one of the things that Go / Rust did right
Honestly there are only two reasons I wouldn't pick up Java for personal projects, difficult to build single executable (Graal is still very un-ergonomic), ridiculous build systems.
I can kind of live with former, but Gradle is so very extraordinarily terrible that I don't know where to begin. Problem is, it solves some real problems (in extremely bad way) that people keep using it.
I long of a cargo-style revolution in Java world. (No, the newly popped up alternatives haven't really cut it so far)
After ~13 years of working with C#, I moved to Kotlin. It's such a beautiful language. When I have to read docs for a Java lib I realize why I like Kotlin.
I want to say culture around Java doesn't have to change, new culture is growing around succinctness (if not simplicity) of Kotlin, and it gets most of the benefits of Java ecosystem.
I also like Kotlin. The readability is awesome. ;)
1 reply →
I must say I prefer C# over Java. They're pretty similar in a lot of ways, but LINQ is much nicer to use than the Java streaming equivalents. And there are some odd warts like Java lacking unsigned types.
As a Go developer, this is right on the mark. I’ve been hearing good things about Java lately, so I decided to check out the language for the first time since 2012 or something. And I was impressed!
The language maintainers have added so many great features while maintaining backwards compatibility. And slowly but surely improved the JVM and garbage collection. So after toying around for a bit, I decided to write some personal projects in Java.
After a week, I gave up and returned to Go. The build tooling is still an over engineered mess. Third party library APIs are still horrible. I will never invest even 5 minutes in learning that horrible Spring framework when stuff like Django, Rails, or the Go ecosystem exist.
The community, and thus the online forums and open source libraries, still approach engineering and aesthetics in a way that is completely foreign and off putting to me.
> I will never invest even 5 minutes in learning that horrible Spring framework
well there's your problem - why are you using spring for a personal project, when there's so many other simpler, lighter weight frameworks around?
> Spring framework when stuff like Django, Rails, or the Go ecosystem exist.
Django and Rails have a very similar model to Spring, so frankly this is just "I was lazy to learn a new tool and it must suck" kinda take. Is there a learning curve? Sure. Does it worth it? I would say for typical CRUD stuff, yeah. No matter how trivial it is you will likely end up needing something that is a single annotation away. But you may want to try quarkus over spring.
Yeah, don't use Spring. If I'm doing DI, I want compile time DI, so Micronaut or Quarkus.
I wonder if at we are standing looking at the smoking field of programming languages created over the last 50 years and gazing at the final survivors, of which Java is definitely one.
Why would anyone create a new language now? The existing ones are "good enough", and without a body of examples for LLMs to train on, a new language has little chance getting traction.
I learned IBM /360 assembler when I started in computers a long time ago. I haven't seen a line of assembler in many decades, but I'm sure it's a viable language still if you need it.
Java has won (alongside many other winners of course), now the AI drawbridge is being raised to stop new entrants and my pick is that Java will still be here in 50 years time, it's just no humans will be creating it.
> Why would anyone create a new language now?
I'm writing my own programming language right now... which is for an intensely narrow use case, I'm building a testbed for comparing floating-point implementations without messy language semantics getting in the way.
There's lots of reasons to write your own programming language, especially since if you don't care about it actually displacing existing languages.
Most of my 20 years of experience is Java. Now 3 years into a new job mostly using Python to build microservices. I feel much more productive using Python (plus uv, ruff and mypy for fast repeatable package management, linting and type checking). I see Python having a trajectory to keep improving and gaining more adoption - eg Python keeps growing in popularity https://survey.stackoverflow.co/2025/technology/. It will have real threads soon and better type checking with ty (thanks to astral who also make uv and ruff). Python gives an incredibly tight integration loop since you don’t wait on compiling. Our kotlin projects are always at least 2x slower for ci/cd builds. I like typescript, but working with it in IntelliJ is incredibly slow.
2 replies →
> Why would anyone create a new language now? The existing ones are "good enough", and without a body of examples for LLMs to train on, a new language has little chance getting traction.
Compiler writing can be an art form and not all art is for mass consumption.
> Java has won (alongside many other winners of course), now the AI drawbridge is being raised to stop new entrants and my pick is that Java will still be here in 50 years time, it's just no humans will be creating it.
This makes no sense to me. If AI possesses intelligence then it should have no problem learning how to use a new language. If it doesn't possess intelligence, we shouldn't be outsourcing all of our programming to it.
5 replies →
What advantage do old languages have that can’t be overcome or at least reduced to insignificance?
The 50-year head start in training data, runtime, and ecosystem? That may not be much, because LLMs are rapidly accelerating software development. LLMs can also generalize: take what they learned for one language and apply it to a “similar” language (and I think most modern languages are similar enough for broad effective translation: all have records/unions, objects, functions, types, control-flow, exceptions, and more). Some fairly recent languages (e.g. Rust, Swift) already have comparable runtimes and ecosystems to older ones, from human-driven development acceleration and concept generalization.
In a recent study, LLMs solved the most exercises in Elixir (https://autocodebench.github.io Table 4). Anecdotally, I’ve heard others say that LLMs code best in Rust, and (for UI) Swift. More importantly, I don’t see an older language advantage that is widening from LLM use; an older language probably is better for most use cases today, but any written code can be translated or regenerated into a newer one.
1 reply →
Programmers would create a new language when there is a fundamental change in hardware architecture such that the assumptions underlying the old programming languages no longer apply. Java is probably a poor choice for writing software in which most computation happens on GPUs. But I agree that someone (or something) will still be using Java to write new line-of-business applications in 50 years.
1 reply →
> Why would anyone create a new language now?
Same reason you'd ever create a new language — to start anew, breaking free from the shackles of backwards compatibility of the old language, having learned the lessons of the past.
The AI angle makes even less sense — surely we will want to create languages that are tailored for them.
Why would anyone play chess in 2010? The drawbridge is rapidly being raised on human competitiveness.
The vast majority of programming languages ever created never aspired to win and I don't think that's going to change now.
What do you mean by "better than Go for industry purposes"?
I don't understand what "industry purposes" means and in what aspects Java is better than Go in your opinion (I can think of some myself, but I'm interested in your perspective).
Not the GP, but for really large code bases, Go is missing a few features that I've noticed:
1) No immutable types. My work team is a huge user of immutable data stuctures in Java to make sure data passed around to other teams isn't changed. Go doesn't really have a good way to do this.
2) Refactoring can be really annoying (or at least really noisy) because of public/private being defined by capitalization of method/field names.
3) Error handling isn't great. I love Go's errors being just normal values, but the `error` interface is awkward when trying to figure out what kind of errors can be thrown without having in-depth knowledge of the kinds of errors that can be returned. We regularly need to make different decisions depending on the kind of error returned. Knowing which errors can be returned in Go is not defined by the method being called (only in comments).
11 replies →
Go can't compete with Java bc it's not in the same category as Java.
- Java is a high-level, multi-paradigm programming language
- Go is designed as a systems language to supersede C projects at Google
Now Go identifies as a general purpose language that competes with Java? It's a free country, I guess.
16 replies →
"industry purposes" likely equates to "enterprise software development." And that assertion is 100% correct.
Exceptions
Ya, that seems to be a misunderstanding. "Industry purposes" covers a huge range of stuff. Go is pretty good for systems programming where Java isn't really an option due to the fundamental limits imposed by garbage collection and lack of pointers. Java is pretty good for higher-level application development where occasional GC pauses are tolerable (the GC pauses are rare and fast now, but they still rule out using Java for certain purposes).
22 replies →
And Java has some advantages that are hard to beat. It performs better than Go and builds just as fast (at least when not using some popular build tools) while offering unmatched deep, low-overhead observability.
People might think they may enjoy another language more, but the portion of people who eventually come to regret choosing Java is probably lower than that of any other language.
> It performs better than Go
Do you have some sources or experiences to share on this topic? I'm very curious. My experience is the complete opposite.
At my previous job there was a Java web application and running in Kubernetes (1 vCPU and 1Gi of memory) was able to deal with at most 80 requests per second, using up almost the full 1 vCPU and ~600-700MiB of memory. That was a bit disappointing, since we were supposed to support at most ~1000rps on this API, 13+ pods is a lot, and we felt "software could do better".
A reactive guru from another team told us we should use a reactive stack, so he came in and rebuilt the app using the reactive stack. Now it was doing about 120rps on one pod (about the same memory usage), which was a good improvement, but still disappointing.
One guy on the team was motivated to rewrite the API in Go as a proof of concept, and we were blown away. With the same 1 vCPU it was now able to handle 400 requests per second, while using ~100-200MiB of memory, and having approximately 20% better response times.
> builds just as fast (at least when not using some popular build tools)
I find this a little bit of a cop-out, because almost everyone is using the popular build tools. And it's quite a chore to build a full application without those popular build tools. With Go, all batteries for building are included.
8 replies →
> It performs better than Go > and its optimising compiler and GCs blow Go out of the water without breaking a sweat.
Well, dandy! Since the performance gap is that big, it should be trivial to get hard data backing that up. Mind linking some representative benchmarks?
Dang, I just can't wait, same resource usage for Go and Java (RAM in particular, if you would), and Java performance that "blows Go out of the water".
> and builds just as fast
Oh? But you're comparing apples to oranges.
Go builds its source into a machine code executable, all optimizations are applied at this step. This then gets directly executed by the CPU.
Java "builds" its source into bytecode. It's a trivial transformation that then needs to actually be compiled and optimized by a virtual machine at runtime before the CPU can run it.
So then, what build time does Java have when doing AOT compilation? Again, hard numbers please, thanks.
> while offering unmatched deep, low-overhead observability.
> People might think they may enjoy another language more, but the portion of people who eventually come to regret choosing Java is probably lower than that of any other language.
Very believable statements, given that you literally work on Java for Oracle :) No need to bother to make a disclaimer about that I guess. Shameless.
1 reply →
> and builds just as fast
Source? I'm not saying you're lying but I have never seen any Java project build as fast as Go
6 replies →
Front page, 82 comments, comment 2 hours ago…why is this the top comment? “People who write Typescript could just be writing Java except they’re scared of being outcasts for not using design patterns” is bait, not a serious technical opinion.
Oh. That’s why it’s the top comment.
I write TypeScript daily and honestly it is not about being scared of Java. The ecosystem just makes more sense if you are already building for the web. You write your frontend in JS/TS, your backend in the same language, your build tools understand it natively, and you share types between client and server. That is a hard thing to replicate in Java even if the language itself is technically better in some areas. The barrier is not cultural fear, it is practical convenience.
With SSR/HTMX/HATEOAS the amount of code executed on client side is relatively minor and does not justify the unstable JS/TS tooling and frameworks, and the security nightmare which is NPM-based supply chain.
Different tools for different purposes...which is good/right.
TypeScript is a superior programming environment for the browser, for sure. Using it on the server? Why not, if you're not trying to scale (in capacity, or functionality).
Language-agnostic serialization exists for a good reason. It's not always right, but it's almost always the right thing to do.
The biggest problem with Typescript in the modern era is that LLMs are pretty bad at it, at least as compared to some other languages that are more well suited to LLM generation. What you say may have been a boon in the olden days, but it is hard to justify now. It is difficult to avoid Typescript/Javascript in the browser, sure, but now it's just as fast to duplicate everything in another language for the backend and at least gain the advantages on that end.
What if you have a mobile app? Rest APIs? The argument doesn't work. Every backend language has ways to generate specs/types/clients from the APIs code.
> You write your frontend in JS/TS, your backend in the same language, your build tools understand it natively, and you share types between client and server.
that's an excuse imho. It's a post-facto justifying using js on the serverside because of familiarity.
I know because the exact same reason was given for GWT (google web toolkit), and that failed pretty horribly (despite it being quite good imho).
3 replies →
My experience has been that developers say that they’ll share types between the frontend and backend, and then in practice they just duplicate it.
> hell its better than Go for industry purposes. [...] the drawback with Java will always be the CULTURE
The industry purpose for Go is that all codebases look more or less the same, so workers can jump into any project they've never seen before and instantly feel like they wrote it themselves. Google talked about that a lot around the time Go was released. It is why they created it instead of just adopting Haskell or something.
Some of that simply comes down to the language not allowing much creativity, but without the culture developers would still find a way to mess with outcomes. You can still write crazy Go code if you want to. The culture is the piece that matters. If Java doesn't have the culture, how does it fit in industry?
Maybe this is just a question of taste but I never could get along with Javas (or Kotlin's) tooling.
Primarily working in Vim/Helix works for most languages from Nix to Typescript or Rust and C, but Java just never worked quite right. It also generally felt like it had a worse story around tooling from a DX perspective, something like Golang or even npm feels a lot lighter than the molasses of JDK management and gradle et al.
> Maybe this is just a question of taste but I never could get along with Javas (or Kotlin's) tooling
Are you joking? IntelliJ is without a doubt the best dev tooling environment available.
3 replies →
Besides doing yourself a disservice of not using a proper IDE, what exactly makes Java not writeable in vim or the like? Like it's a pretty simple language with not much magic going on.
"a solid foundation for the future" is faint praise for a language that has been around for over thirty years.
> It has become a best of breed language
To me it lags significantly behind .net (runtime) and C#/F# (language). I don't see Java catching-up.
They trade blows, and have different philosophies (complex runtime, simpler language vs the reverse).
E.g. on the GC side Java is ahead of any other platform, especially with the low-latency ZGC garbage collector.
6 replies →
On the contrary, as someone that earns their bread using both ecosystems, .NET is still pretty much tied to Windows, regardless of .NET team efforts, most shops going with macOS or Linux are former Microsoft shops saving on server licenses or giving Macs to their devs.
There are many platforms where .NET doesn't have an implementation, a phone to call their own (even if ART isn't proper Java, WP is no longer around), embedded systems, including factory and military weapons deployments (PTC, Aicas, microEJ), copiers (Xerox, Ricoh), phones (Cisco),....
C# is definitly better than Java dealing with value types and low level programing, or being embraced by the game development community, however not sure if the featurities of last years is the right path, I am starting to feel I should just reach directly to C++ instead.
Java is 4th on tiobe.
Bright future for it just means it is not planning to become 40th or 400th.
(My prediction - in next ten years java will always be among top 6; new language might come to the very top and some leapfrogging game between c# and java)
2 replies →
I dont think the Spring ecosystem is bad. In fact, its one of the more stable frameworks. Even spring AI which is built for AI agents a new use-case is very intuitive if you take time to learn its abstractions. Usually doesnt take more than a day of reading docs and writing some try-out code. The thing I really like about Java is the stability of its packaging ecosystem. Maven is XML (yuck) but is okay with the IDE integrations. Gradle has advanced features often missing in Python / Go such as build caching. The OOP stuff is also good because it scales with very large code bases. In, fact frontend esp React adopted a functional style which leads to complexities associated with hooks. A mixed approach is usually better. Overall, the only bad thing are the multiple unnecessary abstraction layers which are a pain in any language. Rest of Java is quite good.
Enterprise space architecture is not picky, all programming languages get a place when they manage to hit big at corporate life.
It can be Yourdon with C and Pascal, Booch with Smalltalk and C++, Patterns with Smalltalk and C++, UML with Ada, C++, Smalltalk and Java, Rational RUP , Java and .NET application servers, Kubernetes with WebAssembly microservices,....
Ever looked into Typescript with effects, pretending to be Haskell?
The fact that you mention Go explicitly hints a real issues with Java.
> All those people using typescript (could be using Java - but the culture doesn't want them and consider them heretics for not embracing religion of OOP and FactoryFactory)
I assume you're specifically talking about the backend and not suggesting that people write Applets or use GWT or something.
Hey even Go has got effective `FactoryFactory` stuff in a lot of open source projects. They just name it differently.
Java isn't even true OO. The only truly OO programming languages that I know of are SmallTalk, Obj-C, and Ruby
Says a single guy who may have coined the term, but that's not how words work. The industry's millions of devs use it differently, so the de facto meaning is that java is an OOP language, and the original is closer to the actor model.
The problem is that many jobs with Java (that I've found) lean so heavily towards OOP that it's part of the job description. I just don't enjoy OOP and find that there's almost always a simpler approach, and to have it prescribed as part of the engineering culture will always steer me away.
Most of backend development on Java is procedural with OO syntax and ability to replace something in the chain of calls with stub in tests. Spring beans are usually stateless singletons containing a few references.
1 reply →
> hell its better than Go for industry purposes
Yet if you ask people in the bay area, especially the those who are under 35, they would tell you that "Use Java? Over my deadbody". It's just amazing that people always chase shiny new things.
Right because golang is like 2 years old and new o.O
There's so much Java development in the Bay
chasing the new shiny? or running away from the zombie?
With LLMs as they currently stand, and with the reasonably confident hope they will get better why even have anymore languages. Shouldn’t we just have everything coded in the most performant language which would be Assembly or C?
The drawback is also the JVM. Its a heavy, bulky VM. The alternative being Go that is much lighter.
With all due respect, I'm fairly sure that anyone using "VM" the same way as you do here really think of it as a container or what.
It's a runtime, and go also has a similar, fairly fat runtime. It's just burnt into the binary instead of being shipped separately. (Hell, even Rust has a runtime, it's just very very lean compared to languages featuring a full GC like go and java)
There are no FactoryFactorys in Java. Never have been
I am captivated by your thought process.
[dead]
That and also the JVM is a marvel of engineering with millions of hours that were poured in by smart people over the last 30 years.
It can be as fast a C, supports a multitude of languages, introspection, surveillance etc.
JFR is one of my favorite things about the JVM. Such good tooling to figure out whatever it is you are having problems with in production.
I've also used Eclipse MAT to find tricky dangling references to objects that caused memory leaks. Definitely not as polished, but extremely useful.
1 reply →
Once i heard a manager explain "we must get rid of anything Oracle, including Java, because of license reasons". I see this attitude everywhere since.
JavaScript people are too afraid to use Java, that is why something like TypeScript exists.
And for personal projects, C# has become a better and more fun "just works" platform.
I wouldn't count myself as a JavaScript person at all, and usually avoid it where I can, going to some length, to make pages static, if possible. So I am not exactly in the group of people you are attacking.
However, I am afraid of the Java coder who is decorated as senior, has sway due to their position, and who will tell me, that something, that is a simple function, shall not be a simple public static "method", but must be wrapped in yet another object, which I need to instantiate, because OOP, and because obviously I don't know what I am doing, or because it doesn't fit existing "coding practices/style" or "Java style". I am afraid of the Java coder, who for years has not touched anything but Java, because their jobs didn't require anything else, because so many companies want Java. I am afraid of the one who throws around jargon like "dependency injection" all day, without ever using simple terms, or realizing what those things are looking like in another paradigm.
Lord, please save me from ever having to work with such obnoxious and uninformed, learning resistant people. This actually may be a straw man, but even one such character matching one or more of those traits, seated above at the seniority ladder will make a mess, that everyone else has to live with.
1 reply →
I mean, sometimes managers are uninformed and say stupid things?
You can use any of the other jdk builds from the plethora of other vendors and have zero interaction with Oracle.
I absolutely hate Oracle as a company, but they've really done a good job with Java stewardship. They actually open sourced the entire language / jdk and a lot of the tooling that used to be proprietary.
They still love to play the old Oracle tricks, so I'd rather not use any of their distributions. But the actual work that they do on the ecosystem has been a positive in my opinion.
1 reply →
I didn't use Java since 7, but from people that do - nowadays you basically don't code Java, you code Spring Boot. And that has all the bad things you think when people say "Java".
I don't know if it's true though.
There are more Java devs than people in my home country. Like how could you even give a single description for all of them? They all work on vastly different stuff, from low-latency trading to robotics, to regular old CRUD. Not even the CRUD part is as monotonic though as you make it out to be.
Spring Boot isn‘t bad. It‘s opinionated about configurations and dependencies. Its main advantage is that you can start shipping production-quality code very quickly, focusing on business problems rather than anything else. Vibe coding on it is more or less stable, entire apps can be built solo in a few months. And it‘s easy to do fullstack with SSR based on Thymeleaf and Htmx. It is absolutely superior to anything that exists for node stack.
And then there‘s also Micronaut, if you prefer compile-time setup to Spring.
There's a lot of programming that has nothing to do with SpringBoot - and I say this as someone who works in a backend team that uses SpringBoot for all our apps.
1 reply →
You're talking to specific people.
A completely different culture of Java usage can and does exist a lot of places. It is absolutely true that success creates a certain ossification of practice. But SpringBoot is not necessary, any more than Guice or any other framework-y thing.
That's weird. Back when Java 7 was a new thing, people used Spring (Boot wasn't there yet) even more to compensate for the lack of language features. Also back then most projects still used XML configuration, so you actually write more Java code in modern Spring. Because Spring Boot uses Java configuration classes by default (although you can still use XMLs if you need for some reason).
I’ve been working in Java for 12 years, my entire career. I have never worked on a Spring project.
> Nowadays you basically don't code Java, you code Spring Boot. And that has all the bad things you think when people say "Java".
Subjective experience, but largely agreed.
Vague rant that summarizes my own experience: major version updates kind of suck, even if Spring Boot is still better than regular Spring (I've gone through the XML hell, was not fun, even less so with a separate Tomcat instance that we had to deploy to, instead of an embedded one). In practice their huge effective pom.xml also leads to conflicts when your package needs something else and it feels a bit arcane to override things. There are things that have underlying technical reasons for being the way they are but seem stupid from afar - like how @Transactional doesn't work when called from within the same bean. Personally I also prefer code over convention for configuration and initialization so the whole annotation driven setup feels quite annoying and difficult to debug when things go wrong - but even the code configuration isn't always great and sometimes it feels like they have abstractions for the sake of abstractions. Spring Boot also often brings friends like MapStruct or Lombok or Mockito which add even more dynamic behavior and issues when you update JDK, alongside slow testing with JUnit and unpleasant debugging of jumping through numerous abstraction layers. You don't strictly have to, but people will.
I probably should have written down every complaint with exact details (so those could be picked apart as user error) over the years that I've been unfortunately maintaining and building shitty software with Java, but I will say this - modern Spring Boot isn't wholly horrible, it has a pretty rich ecosystem and you can do a lot of things with it, but the overall vibe I get from it ofen can be summarized with "Eww." I'd end up using it because I have to, or because it's a means to an end ("Hey, we need to build an event-driven system to integrate with a bunch of others, you have two weeks"), not because I want to.
For the sake of comparison, I believe that for plenty of the folks even Dropwizard would be worth a look: https://www.dropwizard.io/en/stable/ it is more or less like some glue around a bunch of idiomatic packages in the Java ecosystem and it's not horribly hard to integrate something that you want yourself (e.g. Dagger 2 for DI, at this point I'll take anything that does as much as possible at compile time https://dagger.dev/dev-guide/).
Or, for a more modern spin, Quarkus isn't too bad either https://quarkus.io/ or maybe Micronaut https://micronaut.io/ or perhaps Helidon https://helidon.io/ with neither of those being strong recommendations - figure out what you like for yourselves. For people that have been luckier than me, that might as well be the very same Spring Boot, just on better projects. JVM is a pretty cool piece of tech though, and so are the JetBrains IDEs with their refactoring features and nice Maven integration.
I program in Java for more than 15 years now. I can resonate with people hating the language from it's early days due to the experience with all the enterprisy features and over abstractions. Or confunding Java with the Spring ecosystem. But Java came a long way over the years. It's now what many would call a "modern" language. It's less verbose, has many of the features people find appealing in Scala and Kotlin and it can even compile to native binaries using GraalVM. This made building CLIs in Java feasible. Or lambdas.
I recently worked on a Go project and my task was to make it more configurable at build time and start time (add plugins / addons, make it possible to reuse from other libraries and tools). Turned I had to create *Factory and *Providers, even though I did not want to.
It's easy to avoid "AbstractFactoryProviderBuilder" if everything is hardcoded. Try to make it reusable and extensible, and I bet you write one yourself.
> It's easy to avoid "AbstractFactoryProviderBuilder" if everything is hardcoded. Try to make it reusable and extensible, and I bet you write one yourself.
The first domino is opting for OOP. AbstractFactoryProviderBuilders are just the inevitable downstream consequence of that initial choice. No need for factories if you don't traffic in objects in the first place.
Objects. Just say no.
7 replies →
Lack of virtual threads was its biggest remaining problem because this made the common ways of doing cooperative multitasking very ugly. Go's big thing was having that from the start. Maybe now that Java has it too, it's set?
Though JS will still have the least boilerplate because of the way it handles types.
IMO, Kotlin coroutines are better of Go's goroutines, although they are a little different beasts to compare honestly (apples and oranges). Go inits goroutines on stack, but min size is 4KiB, so it's not trivial to grow them. Also you need to watch over and destruct goroutines manually to prevent memory leaks (using
)
And create a separate channel to return errors from a goroutine. Definitely more work.
4 replies →
I think there is something to say for compiling to native code, having binaries in the ~25 MiB range, being able to run in distroless containers, being able to run a web application with less than 100MiB of memory and startup times measured in milliseconds rather than seconds (sometimes dozens of seconds).
Don't get me wrong, I like Java and don't very much like the Go language. But Java has a lot to improve upon still.
5 replies →
I think astronomers could measure the age of the universe in nano-Valhallas. Every year, it feels 50% closer to completion...
In all seriousness I'm happy with what Mr. Goetz and the team have done. Sealed interfaces (java 17) + exhaustive switch statements (java 21) means we now have union types in java! And instead of jumping on the async/await bandwagon we now have a more general solution that doesn't lead to API duplication (virtual threads). But Valhalla has been a veeery long time coming.
'Tis true. At the same time, Project Valhalla will be the most significant change to the JVM in a very long time, and probably its best chance to stay relevant in the future.
JEP 504: Remove the Applet API
Glad to see this being removed. Java plugins especially on Linux were awful and required by tons of corporate stuff. Anyone remeber IcedTea Web? A functional and opensource Java plugin and Java Webstart implementation?
Note that the the Java plugin and webstart was removed a long time ago.
I personally regret that the API was removed as it's a few classes and they are still used. Just search JApplet on Github. It's also possible to run applets in the modern browsers with WASM or in Java IDE's as plugin.
Remember IcedTea Web? Oh boy, I still have environments that use it.
I made several Webstart corporate apps back in the day! The infrastructure was pretty neat, when it worked. And it was a whole lot better than JS back then, still in the IE6 times.
Yeah XMLHttpRequest and activex thing IE6 had. That was Javascript style that days.
If we ignore the fact that value types likely won’t ship before we have flying cars, Java has evolved greatly. I really like how they’ve solved concurrency, but I dislike how they’ve handled modules but this a minor issue.
The main problem with Java has always been its build tools. They’ve consistently been bad and continue to be. Even today, creating a bundled application with a stripped down JDK with jlink and jpackage is incredibly painful. You’ll need extensive knowledge of the Java CLI, modules, build tool plugins, or tools like Mill which simplify using jlink and jpackage, but even then it remains complex and frequently fails. In reality it should be as simple as something like "java package". Even these days, I frequently see Java developers presenting their desktop apps on Reddit and if you look at how they deploy them, it's often a fat JAR because they struggle to use jlink and jpackage effectively. Ironically, even generateing a fat JAR can be challenging.
As someone who has spent over two decades developing desktop applications including witnessing the shift to horrendous Electron firsthand I can tell you that this was a primary reason Java basically vanished from being so prevalent on desktops. Inexperienced developers often struggled to deploy even simple Java applications, grappling with either runtime incompatibilities (Ironically, developers are somewhat reintroducing the same problem with WebView-based applications) or having to tell their users how to launch a Java app. While some claim desktop apps are dead – which is nonsense – the same applies to CLI applications. CLI apps remain prevalent, primarily written in native languages or Golang, sometimes even Node or one of its derivatives. Rarely Java for the reasons I just mentioned and don't get me started with Graal Native. If someone decides to write a simple trivial CLI app in Golang, they'll simply build it with a single command and be done with it. With Graal Native, you'll have to go through using the tracing agent, and if you're lucky you'll have a fat native executable after minutes of compile time. Forget Graal for a minute though. Java would already go a long way if bundling your application with a stripped down JDK (jlink) was as easy as typing in a single command without having to deal with complicated Maven or Gradle plugins.
TIL Mill, I've been in build hell trying to package a javafx GUI gradle project that depends on a non-module-ified lib (usb4java, long story, no I can't use anything else). Beryx/badass failed entirely, was able to get something working with Gradle doing jlink and manual CLI jpackage ...
But tbh the whole experience makes me distrust the Java ecosystem if you're supporting anything that is slightly out of the community's view or priorities. Even JavaFX shows very patchy support for certain very standard UI concepts, and the situation with packaging is bad as you say.
Anyway, is mill worth switching away from Gradle? (Does mill integrate at all with idea?)
Mill does work with idea (via the build server protocol), and the ideas behind it are very sound (a build tool is basically a function calling other functions - on which they depend. You just want to parallelize their running and cache their results.
But it does have a learning curve and you may sometimes end up having strange error messages. (As an implementation, it's basically Scala macros turning normal looking scala functions into a static task graph). It is getting better and better support for mainstream java build setups, and it's possibly the best tool for something very custom. In between the two extremes, you may or may not have a better time with Gradle/Maven.
> Anyway, is mill worth switching away from Gradle?
Hard to say because I don't know how someone without Scala experience would fare with Mill. Then again, I think anything is better than Gradle. Really, anything. I even think I would do everything by hand rather than using Gradle. Also the creator of Mill is a great guy. Rest assured, if something's confusing or not working he's gonna help you out or fix it if necessary.
I feel like Gradle is only relevant for Android. All other projects are fine with Maven (and I like a lot that Maven doesn't allow to code in the build config, any complex logic should be extracted to a custom build plugin, using real code. I just have PTSD after some build.gradle monstrosities).
3 replies →
I was pretty surprised when I learned recently that the Java alternative for green threads doesn't use colored functions. It put Java in a higher place in my perception.
It doesn't completely solve function coloring though. Causing carrier threads to get pinned is still not good, similarly as calling blocking function from async function is not good in colored systems.
There are not a lot of cases left that still cause pinning. FFI is the main one.
What are colored functions?
Any time you have a barrier between one function being able to call another. The original article on this called them red functions and green functions. A green function can call a red function but a red function can't call a green function.
In terms of async, it's when you have to have a function with "async" attached to it and making it so that only other async functions can call async functions.
It ends up creating a weird circumstance where you can end up with a lot of duplicated APIs, particularly in libraries, because you are providing both async and non-async versions of functions.
2 replies →
The term comes from an old blog post [0] about different kinds of effect systems. Every function has a color, and every colored function can only call functions that are compatible with it, usually of the same color. The net result is that you end up either duplicating a lot of your common code so you have compatible interfaces for all the different colors (let's call that "separate but equal" if we're feeling spicy), or you end up shoving round pegs into the square holes of your dominant function color.
[0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
The terminology is used to talk about languages that have async and sync functions where you declare (or color) the function as either async or sync.
In these languages it's pretty common for the language to enforce a constraint that async functions can only call other async functions. Javascript / Typescript, Python are popular examples of languages with colored functions.
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
In this context: functions anotated with async
[flagged]
1 reply →
[flagged]
2 replies →
Are you perhaps confusing green threads with stackless async models, like async/await? Green threads don't imply colored functions.
They said "Java alternative for green threads" so they're talking about not green threads.
1 reply →
No need of colored functions because that Java green thread returns a Future<Value> not Value like colored functions
That sounds just like promises in JS which most definitely are a function color.
"green threads" is generally how I see these systems identify as "non-colored but with async-like performance" fwiw. or "fibers". otherwise it's "async" or "coroutines".
There are different types of coroutines. The C++ type are sometimes called "stackless coroutines". With stackless coroutines you can't yield from a nested function call. Stackless coroutines are basically generators where you can pass arguments through resume, and async/await is effectively a form of stackless coroutines with yield/resume semantics that aren't fully generalized as coroutines, but oriented toward some bespoke notion of concurrency rather than as an abstract control flow operator.
"Stackful coroutines" allow yielding from any arbitrary point. They're basically fibers, except with the explicit control transfer and value passing yield and resume operators; there's no hidden or implicit control transfer like with green threads. Though, some people would argue allowing any function to yield without announcing this in their type signature is tantamount to hidden control transfer. Personally, I don't see how that's different than allowing any function to call other functions, or to loop, but in any event languages are free to layer on additional typing constraints--constraints that can be tailored to the desired typing semantics, rather than dictated by implementation details.
Stackless coroutines are typically implemented as a special kind of function whose state is allocated and instantiated by the caller. In contrast, stackful coroutines are typically implemented by reifying the stack, similar to threads. The "stack" may or not be the same as the system's ABI stack.
In stackful coroutines, unless there are additional typing constraints imposed by the language for hygiene reasons, any function can typically be called as a coroutine or use yield and resume. There's no need to compile functions into special alternative forms as call frame management works the same whether invoked from a coroutine context or not.
I have been using Java since version 1.4. Both the language and its ecosystem have come a long way since then. I endured the height of the EJB phase. I adopted Spring when version 1.2 was released. I spent hours fighting with IDEs to run OSGi bundles. I hated building UIs with Swing/AWT, many of which are still in use today and are gradually being replaced by lovely JavaFX. When I look at code I wrote around 12 years ago, I'm amazed at how much I've matured too.
One of the best tools I built was years ago with Swing and Miglayout. Still remember it fondly.
> I hated building UIs with Swing/AWT, many of which are still in use today and are gradually being replaced by lovely JavaFX.
Dude JFX yielded what was called RIAs to JavaScript like almost 15 years ago. Of the three major GUI toolkits Swing, JavaFX, and SWT it was Swing that gained HighDPI support first (10 years ago), and continues to be the base for kick-as IntelliJ IDEA and other Jetbrains IDEs.
Swing was simpler in some ways than JavaFX. I still remember JavaFX treeview taking 3 Generics and I was unable to figure out what one of them is for from the docs. Had to go on Stackoverflow, where someone said it basically didn't matter. But JavaFX looked great at the time.
As someone who has been out of the Java world for many years, but recently forced back into it due to Android dev requirements, Post lawsuit, what is the relationship between Android (Google) and Java now? When can we expect 26 on Android? On that note, why is Android always so far behind? Is it because Kotlin is primary or is it deeper? Did the lawsuit play a role?
Java's primary development happens on OpenJDK.
Android has their own runtime (creatively named as Android runtime), which does not run java byte code, but their own binary format. JVM class files can be compiled to that format, but the support for that always lags behind OpenJDK java versions.
Part of the reason kotlin became the de facto language on the platform was that they supported only terribly old Java at the time, that didn't even have lambdas even though it was already out.
The problem is that most of the Java libraries want to follow the desktop/server, aka the OpenJDK scene, but that would make them incompatible with Android so there was/is some incentives to bump up the version they support.
The new (ish?) Android UI toolkit is only useable from Kotlin and is implemented fully as a compiler plugin. Google has been clear that Kotlin is the Android language now and that's where new features are going.
I've used Java decades ago (anyone remember servlet?) and I'm glad that I can use flutter for Android development.
I do really need to give flutter a try. My only reason I haven't yet is that I have no desire to learn Dart. How do you (or anyone) like Dart compared to Java or Kotlin?
3 replies →
Man I still have scars learning Java in college. Took the entire fun out of coding until I ended up learning C.
I haven't read a Java manual since the time of Java 8. Do you have any books or other resources you could recommend to catch up with all that has changed in these years?
You might find those useful:
https://www.marcobehler.com/guides/a-guide-to-java-versions-...
https://advancedweb.hu/a-categorized-list-of-all-java-and-jv...
And this more like a reference:
https://javaalmanac.io/
https://javaevolved.github.io/
A couple of books were helpful to me, both by Venkat Subramaniam and published by Pragmatic Programmers:
- Functional Programming in Java
- Cruising Along With Java (this covers everything else that is "new" other than functional programming)
Really glad to see we're getting a native PEM API.
Pleasantly surprised.
But it is a preview though.
All the changes look great. But I don't know how I feel about the syntax. A lot of things that very well could be first-class just aren't. Instead of a `lazy` keyword, we get `LazyConstant<T>`.
I'm sure there's reasons as to why. I just don't know them.
It‘s easier to evolve library code. If Java would ever infer type of constants from initializer (makes more sense than a new keyword), it could look nice and powerful:
Because library code is easier to maintain and for people to understand.
And plus if you add a new keyword someone else will complain about complexity of keywords.
Once introduced, keywords and Java syntax is nearly impossible to change or to remove. If it's possible to get the job done using a class, perhaps with some JVM magic, it's not wise to whip out new syntax.
I wonder what percentage of java code in the world is still java 8, and always will be?
Still a lot, but in absolute terms the majority of Java applications are 8+ for 4-5 years now, according to Oracle's statistics - so they are a minority. It's just that there are so many java projects that it is still a huge number.
Seeing as we're having a $LANG war, after 15 years in JVM land, I moved to a Python / Go shop, and fuck I miss Java.
Not so much the language (although modern Java is pretty slick), but the stuff surrounding it.
* No typosquatting issues because every package has a group id verified by real humans and DNS TXT records.
* JMX as a standardized mechanism of exposing ways to interact with running code / expose metrics. (Even if you have to deal with the stupid ass protocol where you have to connect using a DNS identity the JMX server recognizes)
* Logging libraries that give people running the code control over what gets logged and how, not the developers (looking at you Golang, wtf is with your logging approach where devs have to explicitly consider the fact that you might want to run logging at DEBUG and code it into your start up args?)
* The ability (via JMX) to set, at runtime, one particular logger in one class or file to a desired logging level without restarting the application.
* The performance of the JVM.
* The vast FOSS ecosystem.
* Not having to fight C build chains for that one dependency that's using CGo or a Python wrapper around a C lib that no wheel supports for your given tuple of Python version, OS, and architecture.
Honestly, as someone who is a self-taught developer who taught himself in Python, I thought I was coming home to my first love.
Turns out, I really hate the horrible things you can do in Python - looking at you Django, don't be so dynamic your brains fall out - and really dislike the experience of trying to run a Go service compared to a JVM service.
Java and its ecosystem is just good at getting shit done in a predictable manner at both the dev level and ops level.
> * No typosquatting issues because every package has a group id verified by real humans and DNS TXT records.
While I think this is a huge boon, have you ever published a package on the Maven Central repository? I must confess I haven't in a few years now, but when I did until ~3 years ago it was a major pain in the ass. And every release again.
I think there's something to say about Go's model where the package is just in some Git hosting and a release is just creating a tag. As a package maintainer, this is just pure bliss compared to the Maven thing.
> and really dislike the experience of trying to run a Go service compared to a JVM service.
What are you running into specifically? I have the complete opposite experience. With Go, 1 small binary comes out that I can run anywhere (and put into a distroless container), whereas with Java I have to find a way to somehow run a full JVM (most often with (large parts of) an OS too).
Perhaps you're alluding to the things you can do with JMX, but I have never really seen much benefit in that. I found it trivial to add similar functionalities with internal HTTP endpoints easily. But since I don't have much experience in this particular area, probably I'm missing something.
> While I think this is a huge boon, have you ever published a package on the Maven Central repository? I must confess I haven't in a few years now, but when I did until ~3 years ago it was a major pain in the ass. And every release again.
I’m really surprised to read this. It is well-documented process. I regularly publish something there, never had problems. Why was it different for you?
Yeah, publishing a package is a PITA for the precise reasons of maintaining trust in, and the quality of the packages.
That's why you need documentation to publish to Maven central, that's why your package needs to specify its license, GPG checksum etc.
Yep, it's a lot harder than publishing to Pypi or Cargo, but I'm now firmly of the opinion that it's good that it is. The gates between you and publishing a package are there for deliberate reasons.
> Perhaps you're alluding to the things you can do with JMX
Yep, specifically things like "set the logger org.foo.package.Bla to DEBUG while the app is running", without restarting and without having to add an internal HTTP endpoint to be able to accomplish that. It's just there for free, every JVM logging library and metrics library exposes itself via JMX for that same reason - ease of observability, without restarts, without custom code.
E.g., I can access Kafka client metrics via JMX anytime I like. JConsole will even give me pretty graphs.
If I want them in Prometheus, I run the app with a Java agent that takes those MBean metrics and exports them in Prometheus format on an HTTPS endpoint.
I understand you can accomplish much the same with some internal HTTP endpoints, but that presumes they exist.
If you need them, but that microservice hasn't deliberately exposed them, you need to change the code, and then make a new release, which slows down your ability to diagnose what's going on right now.
In Java, every observability library exposes itself via JMX, all you had to do as a sysop was ensure that the JMX port was open.
Also, the ability to easily observe the metrics of the VM itself via JMX so I can see what's going on with GC in a running app without having to explicitly expose that.
If you suspect a memory leak, or something that should be GC-able isn't, or that there's far too many object allocations occurring that's smashing the first gen portion of the heap and causing excessive GC pauses, the instrumentation to investigate it as your app runs is right there, it's baked into the JVM.
That's why I miss it - the JVM was built to be instrumented and observed by the people running it.
I really wish Golang and everyone else would emulate the Java approach to observable metrics as well as the Java approach to logging and packaging.
There's no shame in stealing the good ideas Java had, but no-one seems to, to my frustration.
Lazy Constants looked interesting. The impl uses unsafe: https://github.com/openjdk/jdk/blob/master/src/java.base/sha...
> My hope is that the first JEPs out of Project Valhalla will be announced later this year
I have heard about Valhalla at least around release of Java 8. That said that site is a solid description of other current and upcoming JEPs.
Do changes to Java itself impact e.g. Clojure? I think it uses many java primitives instead of emitting jvm byte code but I can be wrong.
Some of the standard library stuff could be usable from Clojure and other languages. The jvm level optimizations (garbage collection) should benefit all jvm languages. The language changes are mostly not that relevant unless you program directly in Java.
I use Kotlin myself (after doing Java since 1995). Most of the overview here reads like they are adding a lot of stuff that Kotlin has had for many years. Structured concurrency, lazy stuff, etc. You can argue about which language does it better/nicer/etc. but that debate is a bit boring to me. But good for Java developers that they are getting some obviously useful things that so far they never had. Progress is nice. Better late than never.
Java improvements usually have a runtime component, so no, kotlin simply couldn't have had Lazy no matter what. It was just syntactic sugar for a getter.
2 replies →
Sometimes, yes. E.g. if the value types stuff ever gets implemented, that will be very useful for other JVM languages. OTOH some changes are purely syntax sugar in Java itself (e.g. allowing multiline string literals) and those of course don't affect any other JVM language.
Yes, kind of... for instance you can use Virtual Threads now from Clojure:
https://clojure.org/news/2026/03/11/async_virtual_threads
I'm pretty sure all of Clojure runs on Java 8, so if you use some new feature I'm guessing you need to provide a fallback - but you're also going to be running on Javascript and other platforms, so that's par for the course
In general, some java language changes do involve JVM changes.
So yes, it impacts other jvm languages like Closure.
Here most obvious would be GC improvements.
Modern Java is pretty succinct and expressive and I enjoy working with it. Like any long-lived project, Java has its quirks and baggage but you can let go of that baggage if you want. The ecosystem is evolving nicely with new features and it is quite pleasant to work with these days. I’m looking forward to migrate apps at work to 26.
Vector API (Eleventh Incubator) - maybe 11th time’s the charm.
When it was about the 7th incubator iteration, I got curious so I read the actual JEP history, and it had this informative tidbit, also included in the latest release:
"The Vector API will incubate until necessary features of Project Valhalla become available as preview features. At that time, we will adapt the Vector API and its implementation to use them and then promote the Vector API from incubation to preview."
Project Valhalla has been "in progress" for at least a decade now (Wikipedia say 2014). So who knows when we'll actually see a Vector API in preview.
They made the problem complexity of Valhalla ~10,000x harder by very strict backward compatibility needs. Project Valhalla can take many human generations and multi-billion man years to finish as a consequence.
On the other hand, there is a bunch of movement on Valhalla side nowadays. You can download a build and try out value types yourself!
[dead]
[flagged]
[flagged]
Dont you have parents to tell them that? Open a pr in the codebase
[flagged]
Cool. I feel as though I'll never be able to escape 8, or ignore Ellison's legacy, unfortunately.
> or ignore Ellison's legacy, unfortunately.
Can you elaborate?
Too little, too late. Followers.
Ah , Java, a language I pray I never have to ever touch again.
I think Java became popular because of Sun. My experience with Java-based apps is bad. Laggy, resource-heavy, IDE bound, and it causes premature hardware performance degradation.
Heh, you have no idea how many websites you interact with daily are powered by Java backends in that case.
Android as always in shambles. Shame that neither Google, nor ecosystem cares about Java because they’ve bought JetBrains kopium.
Google basically played a J++ with Android Java, with Kotlin as their .NET/C#.
At least they are forced to partially update Android Java, now Java 17 subset, so that Kotlin can keep up with was is mostly deployed at Maven Central.
Pretty sure they did a J# ;). But I agree that Kotlin is their C#.
The JDK and JVM has advanced so fast while android has been lagging. It's pretty frustrating, especially because google has been so slow to pull in changes from later java versions.
A part of me wishes that android would just dump their hokey dalvik, ART, and other BS and just use the OpenJDK or a fork of the OpenJDK with whatever special sauce they need. A lot of the project Leyden stuff lends itself nicely to maybe someday being able to run real java on android.
Edit: Apparently android is forking OpenJDK, since Android 7.
https://en.wikipedia.org/wiki/Android_Nougat
11 replies →
> Google basically played a J++ with Android Java
No, they didn't. Google happily used regular Java until Oracle played Oracle. Then Google stopped updating the supported Java language version and started diversifying away from Java.
6 replies →
That's a proper late 90s reference, props!
I wouldn’t blame Google for Oracle being a lawnmower.