Wait a second, in very recent years the major Java projects I touched were still messing around with incomprehensible XML config files. Has that actually changed in some part of the industry?

> Has that actually changed in some part of the industry?

I suspect the only thing that's changed is that Oracle now charge you for the pleasure. ;)

More seriously though, its been a long time since I've touched Java, but I suspect the only thing that's changed is that its all hidden in magical kubernetes containers these days.

Not sure if you know what you are talking about? Most users of Java don't pay anything to Oracle. Many things have changed in the Java world. Kubernetes doesn't have any special relation to Java.

> Not sure if you know what you are talking about? Most users of Java don't pay anything to Oracle.

Congratulations Java Fan on missing BOTH the smily-face at the end of the first phrase AND the "More seriously though" at the start of the second.

I'm glad someone still loves Java though. ;)

Congratulations for posting your humorous hot takes on something you haven't touched in 10-15 years.

You can use annotations to get rid of a lot of XML in server side Java. See Spring Boot for example.

Yes, when I started getting into Spring(Boot?) in 2013-14 I was complaining about the annotation magic that you needed to sprinkle around the code, so that you could have a Java project take a long time to start up and fall over. The response at the time was that it was so much better than the old XML way that you "had" to do. So that kind of XML hasn't been needed for 10+ years.

Unless you count the XML dependency management with Maven, which isn't too bad.

I remember when that exact line of argument was made about '3/4 was silly, but they're putting a real effort into 5'

Also "3 was silly, they got 4 done right".

Although that was more connected to the performance improvements through Zend Engine than language sanity or robustness, at the time.

> ColdFusion, CGI, ASPX ... it was not exactly a beautiful world back then.

Pffft. VRML is the whole game, baby! Once everyone runs out and gets an SGI oxygen, Nobody is going to use freaking web browsers ever again. I mean, HTML, what a joke.

Also, ASPX (so ASP.Net) was a vastly superior technology to PHP. It was my first love, and I ditched it for Ruby on Rails, but ASP.Net was really good. Especially when you ran it on Linux using Mono.

The previous post probably should have said classic ASP, not ASPX.

Classic ASP was the more direct competitor to PHP, while ASP.net came along later, as part of a next generation of web server languages/frameworks/platforms.

I remember VRML being a possible PhD topic for me in 1997, I think that was about the last I heard of it!

The other option I was actually offered was in machine learning and categorisation, but I avoid it as it was obviously a dead end lol.

CVE-2026-109618 is evidence that it is absolutely not "good now". To make a pro-PHP argument the week that PHP's shortcomings just cost half the internet millions of dollars of lost time panic-patching an RCE is... an interesting choice.

No fan of php either but that bug was in C code.

Yes, PHP‘s C code.

>CVE-2026-109618 is evidence that it is absolutely not "good now"

That's a C language error, not a PHP language error. I don't see that CVE as particularly different from when they showed python's dictionaries could be attacked using dictionary hash-collision (something that also affected PHP). It's worse in being remotely executable, rather than merely a denial of service. But it's ultimately a facet of the C implementation rather than something wrong with the language itself. CVEs, even remote ones, will happen. Even java had its logging execution error.

I've made fun of plenty of things in PHP over time, but the language hit the mark it was aiming for initially. It was easy. A 12 year old could sit down and write an ugly little forum and it would work. Because it was easy for amateurs, a lot of amateurs wrote in it, and there's a ton of clumsy code out there. Because it was easy to setup and run with minimal setup, popular packages were very popular. Wordpress vulnerabilities matter because it was very easy for programming chop shops to hack out tons of websites for all the millions of little businesses out there that didn't often follow up on patching etc once that was done. PHP was bad largely for the same reason BASIC was bad. It was easy.

PHP being easy gives it a huge blast radius for anything that goes wrong with its implementation or popular frameworks and libraries.

Perhaps C isn’t the right language with which to implement PHP. C is bristling with foot-guns. That implementation choice is still the responsibility of PHP.

(I say this as someone who enjoys C programming)

> ColdFusion, CGI, ASPX ... it was not exactly a beautiful world back then.

You’re missing the point. Those are all dead. The implication is that PHP should have had the fate.

PHP had a super power - it was pretty stateless before that was cool. Thus, it is easy to understand and it's easy to scale. And a lot of it is basically transforming SQL columns into JSON or XML text. I used to laugh at it but now I just shrug. There's much worse things in Node-land.

> the Java fans will be along soon to tell us all how awesome Java is for the web

well, there's no Java2Shell at least.

> well, there's no Java2Shell at least.

Ahem, cough....

Log4Shell (CVE-2021-44228)

That’s not java2shell that’s “log4j2shell” which you even had to type..

Don't clutch those straws too tightly, you might drop them. ;)

Seriously. You're moving goalposts. I think we both know how popular Log4j is and how many millions of Java deployments that Log4j vulnerability affected.