>Even using OpenJDK is a sword of damocles waiting to fall. No, it really isn't. Honestly, people seem to go to great lengths of talking nonsense to discredit Java. There are many reasons to not like a language, and that is absolutely fine. But there is no point talking nonsense about it when you could just... not use it.
I was under the impression that openjdk changes licenses once a new version comes out. That's why the parent comment said "the only downside to openjdk is you have to upgrade every half year", right?
I don’t think someone can revoke your gpl licensed software you already have.
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.
I hope structured concurrency ends up feeling better than async/await with less sugar. The examples do not instill confidence, but we shall see.
It looks like a far smarter approach than async/await
I was under the impression that openjdk changes licenses once a new version comes out. That's why the parent comment said "the only downside to openjdk is you have to upgrade every half year", right?
I don’t think someone can revoke your gpl licensed software you already have.
Check out 17 U.S.C. §203 and §304. I think it's possible to revoke the license after 35 years (at least in the US).
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.
After working with it for over 20 years, I think it's time has come and gone and that it's not the most efficient way to build enterprise applications anymore. You're lucky that Clojure program still works on the newer JVM because many of the applications I worked on, which were very large, could not be migrated to newer versions of Java. In fact, that experience repeated several times for me. I barely ever worked on anything that used the latest versions of the JVM, every place I worked was always on things like "Java 8" and crap like that. It was infuriating, but the situations were not unique at all.
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.
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 think the rise of containers and being able to compile and run natively has eliminated the argument that would favor the JVM. It's so easy to fully control your dev and deployment environments now using Docker images and to me, that's a far better solution. tl;dr -- containers eliminate Java long term.
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 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 fo…
With over 20 years working with Java, I'd much prefer working on Python for lots of reasons, but a big one is that the kinds of projects that involve Java are always involve the same stupid politics and organizational struggles. I've noticed that projects involving Python are way more enjoyable with less friction, likely due to the organizations themselves being more open-minded and maybe younger. I don't know. At some point, every Java project at every Fortune 500 company I worked with was the same damn hellish mess and I had to get away from that.
>Even using OpenJDK is a sword of damocles waiting to fall. No, it really isn't. Honestly, people seem to go to great lengths of talking nonsense to discredit Java. There are many reasons to not like a language, and that is absolutely fine. But there is no point talking nonsense about it when you could just... not use it.
I was under the impression that openjdk changes licenses once a new version comes out. That's why the parent comment said "the only downside to openjdk is you have to upgrade every half year", right?
No they said that because builds of the OpenJdk codebase by the OpenJdk team are only supported for 6 months until the next version comes out.
Builds of the OpenJdk codebase by other vendors are supported for other lengths of time.
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 disagree. That has not been my experience whatsoever. Every company I helped, and it's been dozens, had struggles moving to a new versions of the JVM. Every single time there were major issues that required a lot of re-work and re-testing. I bailed around Java 17 or 18, but it didn't matter because NOBODY I was working with was actually even using that version! On one particularly bad project in 2022, a client had a security imperative to update the JVM from 1.5 on a major internal system and my role was to determine efficacy. I quickly found out that several key libraries had ceased support long ago around Java 1.7 and there was no path forward for those. They were simply deprecated products. My team tried getting the source code and re-compiling those 3rd party jars, with the idea of taking ownership of that code, but it was spiraling in terms of scope. They would not listen to me that even getting them to 1.7 was going to be problematic. Worse, some drive-by manager would not believe my appraisal and brought another guy to prove me wrong. It turned into this big pissing contest, which I resented. The other resource wasn't anywhere near as experienced as me, just kind of arrogant and overly confident. I decided to fire that client, which sucked because they were the tippy top of the Fortune 10. Last I heard, they had not made any progress with that upgrade and were still using it on 1.5.
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.
Java has the same problem most imperative languages do, which is the lack of clear separation between mutable and immutable state, rigorously enforced by tooling. Many large-scale Java programs try and work around this by using immutable collections, which certainly makes a difference but can only go so far. Java has the additional issue of being object-oriented, which leads to spaghetti parent-child relationships un…
Valhalla should be able to address this to some extent with immutable value classes.
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…
You haven't done it, then. Just the re-testing of everything in these large companies is terrifying and complex. Particularly the real-time stuff like Kafka. Most companies refuse to update unless absolutely necessary as they see the solution as an investment that has to produce. Security concerns have changed that attitude somewhat, but you would be surprised how much re-work is often necessary. The frustration of sorting it all out is not worth the money, imho--I'd rather just do something else, so I am.