More new programs should be written in Java/on the JVM.
Most of the reasons Java dropped out of popularity no longer apply, and at this point it is an incredibly stable and mature ecosystem.
I can come back to a Clojure program I wrote ten years ago and it runs great, meanwhile a TypeScript program I write 6 months ago requires a bunch of updating and cleanup.
I'm rooting against Kotlin since it appears to be only usable with the JetBrains ide. I'm totally blind and Jetbrains tools are not nearly as accessible or easy to use as VS Code with all the Java extensions in my experience. At all the jobs I've had no one cared if I didn't use Idea, but considering it looks like there's no good VS Code tooling for Kotlin if I have to use Kotlin professionally it's going to be painful.
Thanks, I've starred the project so I can keep up with it. I don't currently have any plans to do anything with Kotlin but will look at this if I do in the future.
Java is hugely popular and widely used on large backend systems. I guess a lot of people here don't work on such systems? I'm always surprised when I see comments like the parent, since in my career exposure to Java is near-ubiquitous.
Python code that follows traditional Python paradigms is called "Pythonic".
Java code that follows Java paradigms is called "awful".
To be fully transparent, I've never written Java professionally, only for a couple small hobby projects 10 years ago, plus some while in school, so my opinion isn't worth the pixels you're reading it on, but I look at most Java code with abject horror.
Endless levels of abstraction. The apparent inability to write a simple function and instead creating a "ThingDoer" class with a single function called "doThing". Run-time introspection and reflection EVERYWHERE. Stack traces that are just an endless stack of calls to functions like ".invoke" and ".run".
I've been under the impression that all of that is a by-product of Java's strict type system, but someone please correct me. Why do Java paradigms seem so awful?
I think a lot of it is the people using it and certain parts of the culture. There are a lot of Enterprise TM programmers that seem to believe as many layers of abstraction and as much verbosity as possible with little tiny methods that do practically nothing leads to better solutions. It is totally possible to write concise and pragmatic code with Java. One thing that will be a thorn in your side though is null handling. The traditional approaches increase line count and branching. The newer(ish) Optional-based null handling is quite verbose but in width.
As others are saying, it's a culture not the language. C++ and even some Python etc written in the late 90s, 00s era has the same pattern-itis. It comes from slavish adherence to the Gang Of Four patterns books and an obsession with OO generally. Also the languages themselves were weak on non-OO abstractions and ways of doing code re-use, so for example it took forever for Java to get lambda expressions ... so people used one-off helper classes with "invoke" methods, etc.
Those are not Java paradigms per se - they're just practices of mediocre enterprise developers, of which Java has many, owing to being such a mainstream platform.
As for the language itself, a lot of verbosity has been culled in later language versions, with diamond operators, lambda expressions, local variable type inference, etc.
In either case, code is read more than it is written, so if a bit of verbosity makes code easier to read, I'm okay with it.
As someone who has seen awful code in pretty much every language I've worked with, I'd blame this more on inertia and reluctance to change habits. The bad patterns that have entrenched deep into the ecosystem are very hard to shed even when the language and platform is making progress at impressive speed.
ThingDoer.doThing was often just functional programming squeezed into an object-oriented straightjacket. Java 8 added first-class functions and lambdas over a decade ago, eliminating a lot of the need to turn simple behavior into full-blown classes.
This is such a funny workaround, I like that. But it doesn't matter in any library or your own code, since factory methods are much better (simply because they have names).
Java has been such an amazingly solid technological foundation... and for a long, long time! It may not be the most sexy language but it's been a stable one. We have applications created with Java 1.4 running happily on Java 21 LTS and expect to upgrade to this latest LTS (Java 25) soon. Java for the win!
Kind of tangential, I still remember Gmail app created in Java which used to run on my touch Symbian phone in 2009. It was cute as hell and got the work done.
Neat, I wrote some swing apps back in the day that I've thought about resurrecting, but didn't want to have to do much modifying since they are mostly toys, though useful to me. I'm gonna give it a try!
Swing is swing, it's as good as it's always been (eye of the beholder). As I understand it, it hasn't completely rotted on the shelf, they've made updates to the rendering to better leverage modern hardware, but it's not a modern toolkit by any means. But it is maintained, it still works.
JavaFX is good (I really like FX), and maintained, and portable. They just came out with 25 I think. But it's a completely different model than Swing.
It's as great as it ever was. I like it as its very stable and has a good model of interaction but if you want a modern embeddable map or embeddable chart stick with web interfaces. If you do go with swing definitely check out flatlaf to make it look modern.
I'm not sure I like the module import system very much. I think `import *`-like constructions make code a bit easier to write, but much harder to read, especially for developers new to the language / codebase.
C# and Nim love that style, and it makes them almost unreadable without a good IDE.
Personally, I much prefer Python's "short aliases" style, e.g. `import torch.nn.functional as F`
so module imports looks to be different from normal imports and actually helps reduce the number of imports the developer needs to write. FWIW Scala (which runs on java) does have import renaming and also type aliases which can do what you mentioned.
I wouldn't expect migrating from 17 to 25 to be an awful lot of work. The hard bump was moving from Java 8 to 9+ (11, typically), due to the introduction of the module system, removal of APIs previously shipped with the JDK (e.g. JAXB), etc. Things get much easier once you've passed this hurdle. Adopting 17 posed another, usually smaller, challenge due to reflection not working OOTB like before, but I'm not aware of other, equally disruptive changes after 17.
recently pulled the trigger on a migration out of jdk8
we decided to bite the bullet and do 21 instead of 17; one of the reasons being 25 being just around the corner.
as far as i can tell, the biggest hurdle is 8 to 11 (with the new modules system); but it's smooth sailing from there. the proof-of-concept was done with jdk17, but it worked as-is with jdk21 (except guice which needed a major version bump).
(of course being with a jvm language instead of java itself also probably helped)
For us 8 to 17 was tough due to a lot of things you weren’t supposed to be using going away (sun packages). But TONS of libraries did it anyway. And the move from javax to jakarta for a lot of things in there was also tough.
If you could get through that, you’re golden. From what I’ve seen going to 21 or 25 look easy. They’re just adding features, the big upheavals of doing the long needed cleanup are over.
I expect keeping up to date to be far easier from now on.
> For us 8 to 17 was tough due to a lot of things you weren’t supposed to be using going away (sun packages). But TONS of libraries did it anyway.
AFAIK, these libraries did so because there was no alternative, and some of the changes in Java 9 and later were done to provide them with an alternative. The only thing left is Signal/SignalHandler, which AFAIK still has no alternative outside the sun.* packages.
Damn, still not structured concurrency full release. Really looking forward to that one.
Happy to see Scoped Values here though. That'll be big for writing what I'll call "rails-like" things in Java without it just being a big "static final" soup in a god-class, or having a god object passed around everywhere.
The structured part is somewhat like using for and while loops rather than goto statements - it uses block scope to make it easier to reason about how concurrent code is compartmentalized.
However, you still have concurrent code. The example given uses futures rather than async/await, and so the thread blocks waiting for these other threads to complete.
The Java alternative to async/await is the virtual threads. Since they are not GC roots and the stack is a chain of heap-allocated objects, the idea is that they can have significantly lower overhead in terms of memory usage for small tasks. Rather than the compiler generating heap objects to store intermediate state, it just uses a virtual thread's stack.
However, even without async/await syntax you still have equivalent concepts. Since the compiler doesn't have native structured concurrency, it is emulated by putting tasks in lambdas. You fork off subtasks, and do a blocking get() to resolve the futures for their results. Heavy use of fork(), run() and get() aren't necessarily better than async and await keywords.
One concern I have is that Java virtual threads are supposedly preemptive, not cooperative. This means you will have less guarantees around concurrent modification than you would with a typical async/await system running cooperatively on an executor. Several languages willing to make more core changes around adding async/await have gone as far as to also integrate actor functionality to help developers write concurrency-safe code. I don't see Java being able to provide developer help/diagnostics here like other languages can.
Agreed. This is how I feel using it: https://xkcd.com/297/. It's from 2012! I hadn't even written my first `public static void main(string[] args)` then.
My favorite parts of TPL Dataflow are using Channels + Encapsulate to create custom blocks, backpressure, and parallel execution while maintaining ordering. Great library. I sometimes wonder if it would be possible/useful to implement a TPL Dataflow 2.0 on top of Channels.
What is the current situation of using Java (from legal standpoint)? In open source and in commercial setting? Oracle has a lot of fantastic technology locked up in Java (things like Truffle), how reasonable it is for new projects?
Note that the previous Java LTS release license reverts to the OTN license one year after the new Java LTS version is published, making it no longer free, assuming you keep up with the security updates. See the license note on the Java 21 LTS version[1].
OpenJDK is pretty much open and straight from Oracle.
If you don't like Oracle (and I wouldn't blame you), there are alternatives from parties ranging from the Eclipse Foundation to Microsoft and Amazon that will do the same thing.
As for new projects, Java is here to stay. It's longevity is part of why companies are still using Java 8/11; once you write it, it'll run pretty much forever.
The language lags behind in terms of features compared to pretty much any competitor, but it's functional enough to get anything important done.
I'd personally go Kotlin if you were to rely on the JVM (almost entirely because Java still lacks nullable types which means nullpointerexceptions are _everywhere_) or C# if you don't like the Kotlin syntax, but Java is Good Enough.
I don't disagree (it is gpl licenced after all)- but it's worth keeping in mind that openjdk is still provided by oracle, too.
And all the other variants ultimately just repackage it. So if oracle doesn't care about destroying the Java IP, it definitely could cut everyone off from updates going forward.
I don't think they'll do so however, MySQL is still freely usable too, right? And that's oracle IP too.
Might change if they ever get into financial troubles, but that's the same issue with all languages and frameworks.
Honestly, Java is one of those technologies I would never worry about in this way.
It is used everywhere. Just among the faang companies, Apple, Amazon, Netflix and Google definitely use it at scale, and they're just the tip of the iceberg. Taking away JVM updates would almost be a company-ending event for them, and they definitely have the resources to keep it alive if Oracle ever dies.
Nice to see "Vector API (Tenth Incubator)" - it should open possibility of doing low level vector maths much needed by machine learning toolkit in Java.
More new programs should be written in Java/on the JVM.
Most of the reasons Java dropped out of popularity no longer apply, and at this point it is an incredibly stable and mature ecosystem.
I can come back to a Clojure program I wrote ten years ago and it runs great, meanwhile a TypeScript program I write 6 months ago requires a bunch of updating and cleanup.
I'm secretly hoping that Kotlin and Compose will bring back Desktop apps on the JVM :-).
I'm rooting against Kotlin since it appears to be only usable with the JetBrains ide. I'm totally blind and Jetbrains tools are not nearly as accessible or easy to use as VS Code with all the Java extensions in my experience. At all the jobs I've had no one cared if I didn't use Idea, but considering it looks like there's no good VS Code tooling for Kotlin if I have to use Kotlin professionally it's going to be painful.
As of somewhat recently, Kotlin has a language server: https://github.com/Kotlin/kotlin-lsp
Using it in vscode, while not perfect yet, is starting to be alright.
Thanks, I've starred the project so I can keep up with it. I don't currently have any plans to do anything with Kotlin but will look at this if I do in the future.
I write desktop app on JavaFX (one Kotlin one pure Java). I don't see any problems why we should wait, it's production ready
Java is hugely popular and widely used on large backend systems. I guess a lot of people here don't work on such systems? I'm always surprised when I see comments like the parent, since in my career exposure to Java is near-ubiquitous.
I suppose we are talking about user-facing desktop software.
Most of the largest cloud was built on Java....
It is probably more related to people replacing multithreaded services with single-threaded workers.
In the circles I see, Java isn't popular because it's verbose and boring to use.
These days I don't see those as significant issues, tbh.
I would prefer a Clojure program, but I'll take Java over Typescript at this point.
> it's verbose and boring to use.
Python code that follows traditional Python paradigms is called "Pythonic".
Java code that follows Java paradigms is called "awful".
To be fully transparent, I've never written Java professionally, only for a couple small hobby projects 10 years ago, plus some while in school, so my opinion isn't worth the pixels you're reading it on, but I look at most Java code with abject horror.
Endless levels of abstraction. The apparent inability to write a simple function and instead creating a "ThingDoer" class with a single function called "doThing". Run-time introspection and reflection EVERYWHERE. Stack traces that are just an endless stack of calls to functions like ".invoke" and ".run".
I've been under the impression that all of that is a by-product of Java's strict type system, but someone please correct me. Why do Java paradigms seem so awful?
It's a culture, not language thing. Here is a JSON parser implementation (part of PlantUML) that lacks endless levels of abstraction.
https://github.com/plantuml/plantuml/blob/master/src/main/ja...
I think a lot of it is the people using it and certain parts of the culture. There are a lot of Enterprise TM programmers that seem to believe as many layers of abstraction and as much verbosity as possible with little tiny methods that do practically nothing leads to better solutions. It is totally possible to write concise and pragmatic code with Java. One thing that will be a thorn in your side though is null handling. The traditional approaches increase line count and branching. The newer(ish) Optional-based null handling is quite verbose but in width.
As others are saying, it's a culture not the language. C++ and even some Python etc written in the late 90s, 00s era has the same pattern-itis. It comes from slavish adherence to the Gang Of Four patterns books and an obsession with OO generally. Also the languages themselves were weak on non-OO abstractions and ways of doing code re-use, so for example it took forever for Java to get lambda expressions ... so people used one-off helper classes with "invoke" methods, etc.
Those are not Java paradigms per se - they're just practices of mediocre enterprise developers, of which Java has many, owing to being such a mainstream platform.
As for the language itself, a lot of verbosity has been culled in later language versions, with diamond operators, lambda expressions, local variable type inference, etc.
In either case, code is read more than it is written, so if a bit of verbosity makes code easier to read, I'm okay with it.
As someone who has seen awful code in pretty much every language I've worked with, I'd blame this more on inertia and reluctance to change habits. The bad patterns that have entrenched deep into the ecosystem are very hard to shed even when the language and platform is making progress at impressive speed.
ThingDoer.doThing was often just functional programming squeezed into an object-oriented straightjacket. Java 8 added first-class functions and lambdas over a decade ago, eliminating a lot of the need to turn simple behavior into full-blown classes.
I think Java is the best language for most medium to large projects or anything that requires threading or complicated/optimized IO
Especially now that hardware architectures are getting fragmented again, I hope it becomes more relevant.
I think Springframework is dragging Java's reputation down. I know Spring boot is better but it's such a monstrosity.
I feel like sadly Python has won the war, though. Good enough for most things even though it is pretty rubbish.
I see people trying to use Rust now for prod AI systems.
Crazy that it took this long to allow parameter validation and transformation before calling super in the constructor.
That was something that always bothered me because it felt so counterintuitive.
I've been programming in Java since before JDK 1.0 and that was one misfeature that bothered me then but that I've long since learned to work around.
Especially because you were always able to bypass it by declaring a `static` function and calling that as part of the parameters to `super`:
public Foo(int x) { super(validate(x)); }
validate would run before super, even though super was technically the first statement in the constructor, and the compiler was happy.
This is such a funny workaround, I like that. But it doesn't matter in any library or your own code, since factory methods are much better (simply because they have names).
Java has been such an amazingly solid technological foundation... and for a long, long time! It may not be the most sexy language but it's been a stable one. We have applications created with Java 1.4 running happily on Java 21 LTS and expect to upgrade to this latest LTS (Java 25) soon. Java for the win!
I wonder where Java would be today without superb tooling and smart student programs from JetBrains.
Java has enjoyed powerful IDEs since late 1990's, some of them are even free beer!
Kind of tangential, I still remember Gmail app created in Java which used to run on my touch Symbian phone in 2009. It was cute as hell and got the work done.
Neat, I wrote some swing apps back in the day that I've thought about resurrecting, but didn't want to have to do much modifying since they are mostly toys, though useful to me. I'm gonna give it a try!
Is Swing good now? Usually when people say Java is good now I assume they're not talking about Swing.
Swing is swing, it's as good as it's always been (eye of the beholder). As I understand it, it hasn't completely rotted on the shelf, they've made updates to the rendering to better leverage modern hardware, but it's not a modern toolkit by any means. But it is maintained, it still works.
JavaFX is good (I really like FX), and maintained, and portable. They just came out with 25 I think. But it's a completely different model than Swing.
It's as great as it ever was. I like it as its very stable and has a good model of interaction but if you want a modern embeddable map or embeddable chart stick with web interfaces. If you do go with swing definitely check out flatlaf to make it look modern.
Your neighbor's dog barks at Swing.
No, swing is pretty out of fashion if not deprecated. I know it pretty well, but still wouldn't choose it if starting a new project today.
I'd use Qt, though if you're not comfortable with C++ I've been told JavaFX is pretty good
Swing is standard part of JDK, there is nothing deprecated, it even got a Metal backend.
ive tried javafx but its always easier to me to go back to swing, if it aint broke dont fix it.
The JVM and its ecosystem can be used from other languages too like Scala which has all the sexy stuff, also clojure et al
And Kotlin!
(not a Java developer, no dog in this fight)
I'm not sure I like the module import system very much. I think `import *`-like constructions make code a bit easier to write, but much harder to read, especially for developers new to the language / codebase.
C# and Nim love that style, and it makes them almost unreadable without a good IDE.
Personally, I much prefer Python's "short aliases" style, e.g. `import torch.nn.functional as F`
so module imports looks to be different from normal imports and actually helps reduce the number of imports the developer needs to write. FWIW Scala (which runs on java) does have import renaming and also type aliases which can do what you mentioned.
C# supports the "using alias" like this:
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...My feeling (which is worth what it is worth) is that Java as an old language has been improving over the last 10 years, whereas C++ has gotten worse.
New Features: https://openjdk.org/projects/jdk/25/
Java 25 is an LTS release.
Can't wait to have a job migrating an application from 17 to java 25 in 10 years!
I wouldn't expect migrating from 17 to 25 to be an awful lot of work. The hard bump was moving from Java 8 to 9+ (11, typically), due to the introduction of the module system, removal of APIs previously shipped with the JDK (e.g. JAXB), etc. Things get much easier once you've passed this hurdle. Adopting 17 posed another, usually smaller, challenge due to reflection not working OOTB like before, but I'm not aware of other, equally disruptive changes after 17.
Except he didn’t say “for ten years” but “in ten years” referring to the extreme length of time companies take to upgrade
Already doing the work to move my team to 25 and it's been out for a day.
recently pulled the trigger on a migration out of jdk8
we decided to bite the bullet and do 21 instead of 17; one of the reasons being 25 being just around the corner.
as far as i can tell, the biggest hurdle is 8 to 11 (with the new modules system); but it's smooth sailing from there. the proof-of-concept was done with jdk17, but it worked as-is with jdk21 (except guice which needed a major version bump).
(of course being with a jvm language instead of java itself also probably helped)
Yeah, Java 9 was the Python 3 moment of the ecosystem, however it has been sorted out for ages.
For us 8 to 17 was tough due to a lot of things you weren’t supposed to be using going away (sun packages). But TONS of libraries did it anyway. And the move from javax to jakarta for a lot of things in there was also tough.
If you could get through that, you’re golden. From what I’ve seen going to 21 or 25 look easy. They’re just adding features, the big upheavals of doing the long needed cleanup are over.
I expect keeping up to date to be far easier from now on.
> For us 8 to 17 was tough due to a lot of things you weren’t supposed to be using going away (sun packages). But TONS of libraries did it anyway.
AFAIK, these libraries did so because there was no alternative, and some of the changes in Java 9 and later were done to provide them with an alternative. The only thing left is Signal/SignalHandler, which AFAIK still has no alternative outside the sun.* packages.
Damn, still not structured concurrency full release. Really looking forward to that one.
Happy to see Scoped Values here though. That'll be big for writing what I'll call "rails-like" things in Java without it just being a big "static final" soup in a god-class, or having a god object passed around everywhere.
Much better this way with previews, than the mess C++ is having nowadays with standardising features without implementations.
I hope structured concurrency ends up feeling better than async/await with less sugar. The examples do not instill confidence, but we shall see.
The structured part is somewhat like using for and while loops rather than goto statements - it uses block scope to make it easier to reason about how concurrent code is compartmentalized.
However, you still have concurrent code. The example given uses futures rather than async/await, and so the thread blocks waiting for these other threads to complete.
The Java alternative to async/await is the virtual threads. Since they are not GC roots and the stack is a chain of heap-allocated objects, the idea is that they can have significantly lower overhead in terms of memory usage for small tasks. Rather than the compiler generating heap objects to store intermediate state, it just uses a virtual thread's stack.
However, even without async/await syntax you still have equivalent concepts. Since the compiler doesn't have native structured concurrency, it is emulated by putting tasks in lambdas. You fork off subtasks, and do a blocking get() to resolve the futures for their results. Heavy use of fork(), run() and get() aren't necessarily better than async and await keywords.
One concern I have is that Java virtual threads are supposedly preemptive, not cooperative. This means you will have less guarantees around concurrent modification than you would with a typical async/await system running cooperatively on an executor. Several languages willing to make more core changes around adding async/await have gone as far as to also integrate actor functionality to help developers write concurrency-safe code. I don't see Java being able to provide developer help/diagnostics here like other languages can.
Unfortunately on .NET side, TPL Dataflow doesn't get enough love.
They added an async Channel and its actually pretty nice to work with, at least.
Agreed. This is how I feel using it: https://xkcd.com/297/. It's from 2012! I hadn't even written my first `public static void main(string[] args)` then.
My favorite parts of TPL Dataflow are using Channels + Encapsulate to create custom blocks, backpressure, and parallel execution while maintaining ordering. Great library. I sometimes wonder if it would be possible/useful to implement a TPL Dataflow 2.0 on top of Channels.
I would be shocked if they came up with something that made me want to move away from ZIO.
Nice overview of new features in Java 25: https://www.baeldung.com/java-25-features
What is the current situation of using Java (from legal standpoint)? In open source and in commercial setting? Oracle has a lot of fantastic technology locked up in Java (things like Truffle), how reasonable it is for new projects?
The only real nut right now is, if you're using the Oracle distributions, only the latest LTS is, essentially, free to do anything with.
Older releases are under their OTN license, which is only for personal and development, but not production.
Again, this only matters if you want an Oracle sticker on your runtime, OpenJDK and the other projects are full boat "do whateva" JDKs.
Note that the previous Java LTS release license reverts to the OTN license one year after the new Java LTS version is published, making it no longer free, assuming you keep up with the security updates. See the license note on the Java 21 LTS version[1].
[1] https://www.oracle.com/uk/java/technologies/downloads/#java2...
OpenJDK is pretty much open and straight from Oracle.
If you don't like Oracle (and I wouldn't blame you), there are alternatives from parties ranging from the Eclipse Foundation to Microsoft and Amazon that will do the same thing.
As for new projects, Java is here to stay. It's longevity is part of why companies are still using Java 8/11; once you write it, it'll run pretty much forever.
The language lags behind in terms of features compared to pretty much any competitor, but it's functional enough to get anything important done.
I'd personally go Kotlin if you were to rely on the JVM (almost entirely because Java still lacks nullable types which means nullpointerexceptions are _everywhere_) or C# if you don't like the Kotlin syntax, but Java is Good Enough.
There is literally 0 worry. OpenJDK is fully open source.
It's only a consideration if you are going to write your own Java implementation and distribute it.
Use OpenJDK (or similar) and you are free from any Oracle shenanigans.
I don't disagree (it is gpl licenced after all)- but it's worth keeping in mind that openjdk is still provided by oracle, too.
And all the other variants ultimately just repackage it. So if oracle doesn't care about destroying the Java IP, it definitely could cut everyone off from updates going forward.
I don't think they'll do so however, MySQL is still freely usable too, right? And that's oracle IP too.
Might change if they ever get into financial troubles, but that's the same issue with all languages and frameworks.
And there is Amazon Correcto, Eclipse Temurin...
Sure, that could stop to maintain it, but would put the power immediately in the hands of other companies with a fork
That said, you always have oracle's greediness...
> Sure, that could stop to maintain it, but would put the power immediately in the hands of other companies with a fork
I have a feeling all those companies / orgs would band together to maintain it.
Honestly, Java is one of those technologies I would never worry about in this way.
It is used everywhere. Just among the faang companies, Apple, Amazon, Netflix and Google definitely use it at scale, and they're just the tip of the iceberg. Taking away JVM updates would almost be a company-ending event for them, and they definitely have the resources to keep it alive if Oracle ever dies.
Nice to see "Vector API (Tenth Incubator)" - it should open possibility of doing low level vector maths much needed by machine learning toolkit in Java.
i think its time for some of the enterprise customers to maybe consider upgrading to java9?
i think some of the enterprise users should maybe consider upgrading to java9?
It's a damn shame that project Valhalla still isn't finished. This would fix so much and open up java for better matrix math support