One thing I'll miss about this was the way this arcane writing increasingly made sense over time as you became a better programmer.

I learned Java only after Python and I remember being not quite familiar with types so even the 'void' and 'String[]' where a bit mysterious. After learning basic types that part made sense. Then you start learning about Classes and objects, and you understood that main is a static method of this class Main that must be required somehow. As you dive deeper you start learning when this class is called. In a weird way what started as complete, unknowable boiler plate slowly evolved into something sensible as you began to understand the language better. I have no doubt that seasoned Java devs see a lot more in that invocation that I do.

Good riddance though!

Good riddance indeed. The last 30 years of software teaching basically trained developers to produce complexity for its own sake, while calling it engineering. I'm not sufficiently full of myself to link to my own writing (yet) but I'm full of myself enough to self-paraphrase:

1. Programmer A creates a class because they need to do create an entry point, a callback, an interface... basically anything since everything requires a class. Result: we have an class.

2. Programmer B sees a class and carelessly adds instance variables, turning the whole thing mutable. Result: we have an imperative ball of mud.

3. Another programmer adds implementation inheritance for code reuse (because instance variables made factoring out common code into a function impossible without refactoring to turn instance variables from step 2 into arguments). Result: we have an imperative ball of mud and a nightmare of arbitrary dynamic dispatch.

At some point reference cycles arise and grandchild objects hold references to their grandparents in order to produce... some flat dictionary later sent over the wire.

4. As more work is done over that bit of code, the situation only worsens. Refactoring is costly and tedious, so it doesn’t happen. Misery continues until code is removed, typically because it tends to accumulate inefficiencies around itself, forcing a rewrite.

I remember our "intro to programming course at university" started with this program and the tutor said "I'm mostly gonna try and explain all the code I show you, as I show it, but this is the exception, you just have to accept this nonsense bit for now".

And yeah, it was pretty cool looking back on it later and realising I knew what it all meant!

And yeah, good riddance nonetheless!

Except a static class method is just a hand-wavy way of denying reality: that a program has a single entry point that has nothing to do with classes

As much as C++ has a lot of problems, them and other languages (python/ruby/etc) never denied that the procedural world existed, while Java wants to blindfold you and push you through a corridor until you get out of it and into the "perfect (not) OOP world"

Yeah, I agree with this sentiment. The boilerplate was oddly helpful when I was starting out.

Yup... if you're familiar with the old class-based approach, the new style raises more questions than it answers. Did they really turn "everything-is-an-object"-Java into a procedural language? What do you do if you do need command line arguments? Etc.

(I somehow mostly avoided learning Java, and my last passing contact with it was 20+ years ago, so these are honest questions).

In general, Java made OO design trivial to implement, but due to a clear specification standard requirement a lot more planning/time is needed.

Thus, many sub-optimal project coordination approaches ended up fighting the design patterns. Java is a good student language, but there are so many better options now... with fewer footguns, and without Oracles farts. =3