Speaking of unsexy programming, we’ve got a new Java release.
Featuring thousands of performance, stability, security, and productivity improvements, Java 27 (Oracle JDK 27) provides a strong foundation for continued Java innovation. To help organizations prepare for more secure communications in a post-quantum world, Java 27 advances its post-quantum cryptography (PQC) capabilities with hybrid key exchange for TLS 1.3.
↫ Oracle press release
The OpenJDK release page has more information.
I myself find Java very sexy! It scales linearly from small 2G Netbook (if anyone remembers this) to nowadays a 128GB Epyc server — without even thinking much about the details of parallelism. If you are just a Civil Engineer coming from the business side and want to get stuff done, Java is awesome. Also, the ecosystem around is amazing with Apache providing so much high quality libraries. I just love it!
Btw, going to Java on Monday for a POC, wish us luck! 😀
Agree. Java is often used for very boring things, but as a technology it’s very interesting and comes from a great pedigree, i.e. Sun.
Andreas Reichel,
I stopped using java after oracle broke a lot of preexisting java software around the java 8 era. Prior to Oracle Sun really delivered on portability and I thought Java ONE was awesome one click solution for java software distribution. I was using it for both corporate and desktop programming. But after oracle’s thrashing broke tons of software I left and never looked back.
I remember you saying you used 3rd party JVMs… it might be worth a look but honestly I’ve already switched to C# and I gotta say I like C# as a language. Admittedly, .net framework was largely copied from java, but that’s not a bad thing.
Good luck.
I spent all week pounding my head trying to fix bugs in a legacy win32/MFC project… It’s an unwieldy code base with countless people having worked on it so there’s all kinds of nonsense in there on top of visual C being a real clunker. I do what I can. I think I’ve fixed the last open bug at 10pm on a friday, cross my fingers.
You are the kind of man I want to have in my team, when the AI-pocalypse happens!
It’s not Java that’s unsexy, but tools like Gradle that you can’t avoid using. The mix of declarative and procedural idioms, along with syntax changes in every release. It’s a total hell.
:-O !!!
I love Gradle so much! What do you hold against it? Compared to Maven it is so easy to script really big deployments, especially when you have to do things outside the normal Java stuff, like SPHINX documentation, database setups, multi-arch FFM compilation etc.
Andreas Reichel,
I’ve never used Gradle and so cannot comment on it directly, although OP’s comment makes me think of cmake. On the one hand it’s a big improvement over autoconf! However in practice what happens over and over again is that developers using different versions of cmake result in compile time build errors. Unless you’re on a cutting edge distro or running it out of repo, then cmake from an LTS environment often fails over stupid non-issues caused purely by cmake changes. It results in build failures that are purely artificial in nature and do not stem from the source code itself. It’s frustrating to have to fork code with the only purpose being to overcome cmake’s own breakages…yuck! I never suffered the issue to the same degree with autoconf. That’s what makes it infuriating about different developers working together (or apart) with cmake. This is very unfortunate because cmake is otherwise much nicer than autoconf, but it keeps introducing new compatibility problems that weren’t there before.
I wish cmake would focus less on updates that break stuff and more on long term build stability. But given how long this has been an issue, I have my doubts about it ever getting fixed. Obviously they want everyone to sideload the latest version and pretend there’s no incompatibility, but I still find it regressive next to other build tools that are realistically compatible over decades because the tools are mature and don’t see the need to regularly break releases.
So while I don’t know about Gradle, a_very_dumb_nickname’s post just reminds me of cmake’s issues 🙂
I get where you both are coming from, because I also face a lot of breakages in between the Gradle releases, but:
1) nobody forces anyone to upgrade gradle, you can stay with the wrapper
2) every breakage was fixable easily, especially when using a good LLM (Claude/Opus 5 is a very capable CI and Deployment engineer)
3) in my experience, the pros heavily outweigh the cons, examples:
– JavaCC prints only warnings on Grammar ambiquities, no way to get a clean exit code, so with Gradle you just write a Java/Groovy task parsing the out and the warnings to check if the grammar is clean
– IF/Else dependencies based on JDK versions or Operating systems is so simple in Gradle
– JavaDoc –> XMLDoclet –> Sphinx –> HTML gives you super clean API in your website (example https://manticore-projects.com/JSQLParser/javadoc_stable.html), I would not know how to achieve something like this in Maven
– Or look at https://manticore-projects.com/FPNG-Java/index.html where I have to build 9 different C libraries first for each OS and Architecture before wrapping it via FFM into one big JAR — would be a nightmare in Maven.
You can express any logic on your own, without tainting the program code or relying on a plugin — in the language you are writing in anyway (Java/Groovy/Kotlin). For me, this is a blessing.
I’m looking to Gradle from the Android side, and I stopped writing code for Android several years ago, so my perspective may be a bit outdated. There are so many magical code fragments that you have to copy-paste to compile your code. These “hacks” are usually not even stable enough to be compatible for several major versions. And on top of that, they heavily affect compilation speed and IDE speed.
Alright, I take your word for it — I have zero clue or experience about Android.
Best and cheers!
Important to understand is that basically no enterprise is migrating to non-LTS versions of Java. Current LTS is Java 25. The next one is Java 29 which should be ready 1 year from now.
Sure, but its good to have a kind of “java 29” Pre-view, stable enough to develop against internally to ensure your application is compatible when the next LTS comes out.
For example, my Java Swing to Browser fork https://github.com/manticore-projects/suramadu will need so work since they changed AppContext. So we are going to implement it and run everything internally asap to be ready when the next LTS happens.
Yup, this is exactly why these mid-lts versions are released.
Still no operator overloading.