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!

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

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"

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

Yep, same for me, it's been a long time since I did java and while the publicstaticvoidmain mantra felt familiar I was a bit confused by the Scanner thing and couldn't say why.

Or if you're an Android developer then main doesn't exist at all and never has

But yeah I don't understand why the author is so excited about this. How "ugly" a trivial "Hello, World!" does not really matter much and isn't a good indication of anything about the language's ability to handle more than "Hello, World!"

Many of us took programming 101 in Java and so typed this dozens of times without having a clue what it meant.

Probably not in the least for developers, but it does affect beginners a lot.

I used to teach Java, and the total sum of magic incantations you needed before starting to actually "Hello, world" were an instant turn off for many students.

I think it’s been at least 5 years since I saw a main in the codebase.

Now that I think of it I rarely even write a truly new class from scratch, usually you just implement/extend some framework-specific thing.

It's insignificant for day-to-day programming for experienced developers, but has importance for learners.

Java sometimes has a culture of "the proper way to do this is to take all these little pieces and put them together in a specific way" which probably makes sense for an object oriented purist but is a bit of a drag day to day.

The scanner class is one such thing, but you also have things like wrapping a Reader in a BufferedReader to add buffering, and building a Pattern object to build a Matcher object which has a few different methods you can call to actually do anything useful

It is very OO, but it's also a bit annoying, and more modern java libs tend to give you a more comfortable API. Sadly modern java also tends to come with springboot and people who can't do anything, unless they use springboot

Frieren working on projects that last decades. Ya don't say... ;)

It's a shame that they only introduced this as a feature only for single-file programs.

It would make Java a much better language in my eyes if it allowed package-level methods, or even multiple records/classes per file. But apparently "impact on how Java code is written in general" is not wanted.

:-) So not even remotely dead.

This heavyweight syntax has nothing do with OOP. No common definition of OOP (before Java came into existence) said that functions cannot exist outside of a class.

Java choose to adopt object oriented purity in a very weird way. Sun has initially rejected the idea of standalone functions (static import was introduced in Java 5, closures in Java 8 and compact source files/instance main is only coming now). Even with static imports and compact source files, there is still a class holding these methods behind the scenes (for practical and compatibility reasons, more than to achieve any ideological or theoretical goals at this point). That seems like Sun was trying to keep the purity of "everything is an object", but at the same time they've introduced primitive values, which are clearly not objects. This was a pretty bad decision in my opinion. There is no practical benefit from requiring every function to be defined inside a class[1]. On the other hand, being able to have methods defined on an integer is a pretty nice feature.

If we look at a Smalltalk, which is generally considered be an example of a "pure" OOP language, we see a striking difference. This is Hello World in Smalltalk:

  'Hello, world!' printNl

[1] https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

I agree, this is the whole point of "Hello world", which is to show the boilerplate required to start a program capable of outputting text, as well as the actual code that outputs that text. It's also the chance to get the build tools setup, people forget that some of the 'boilerplate' is the actions required to build, which often are much more involved for newer tools and frameworks.

You can just say initially e.g. when I learned C++ that "#include <iostream>" can be "mostly ignored for now, but just know iostream stands for Input / Output stream, and this line is necessary to e.g. output with std::cout"; and there are no scars left from this.

I'm someone who wrote a lot of 'raw' Java and C++ without frameworks, which meant there was a lot less boilerplate and indirection etc. And for me, the big usability boon came about 10 years ago, around the same time for both Java and C++, when they started supporting lambda functions. I started passing code into algorithms and, although it sounds quite complicated, it simplified my programs substantially. Before that syntactic sugar gave the affordance I hadn't been organising my programs that way.

For the longest time Java had been very keen to be explicit, to the point of needing a log of cruft where it just felt like the compiler was checking you spelt every letter of the incantation correctly because both the compiler and you knew unambiguously what simple thing you were trying to achieve. But this tone changed in Java around the time the new entrants like Kotlin started taking over as what you develop in in a way that scala and clojure never managed. And suddenly all the get-out-of-your-way of lambdas saving you typing out classes and anonymous classes arrived and Java became a much nicer experience imo.

Java was never a horrible programming language. The hate is wildly overblown.

Meanwhile some languages like Python still suck 30 years later.

Most likely you have not seen horrible languages or your bar for being not horrible is quite high.

Even so. It has amazing backwards compatibility and package management.

C# has had top level statements since version 9.0 (Nov 2020), and it's still just a compiler trick that produces a static method behind the scenes. Top level functions work too, but in a similar way.

Decompiled example: https://lab.razor.fyi/#41rAyMUVUJSfXpSYq5dcLDSRsbQ4My9dIbiyu...

> lipstick on a pig's turd

There are several valuable compiler transformations that happen under the hood in languages like this. Closures as types, iterator/generator functions, async state machines. This is just another example.

I feel the same way about C/C++ having default return of 0 in main() only.

> If you can't have other top-level functions in Java, then it's a special case, which is ugly.

I assumed this meant that you could have free functions, but you're saying you can ONLY have `main` as a free function? Ok, then I agree this is also garbage.

Because usually you have an ide that manages imports for you automatically. So unless you are using a library that has multiple imports, usually you know the import to include, and in almost all cases it is automatically included.

Btw: in the compact example! The IO class is implicitly imported, so that example truly works without any import at all!

Among other things, I think a lot of Java IDEs automatically manage imports anyway.

i forgot. sorry.

Oh, I do remember the narrative: OOP is amazing but Cpp is not pure OOP let's make the OOPiest language possible.

I also remember casts all over the place in Java because polymorphism wasn't OOP enough.

And then lambdas and functions were not OOP enough to be first class values and that's why we needed numerous "verb-classes" everywhere.

And of course printf() is not OOP enough...

See Brian's article "Paving the on-ramp": https://openjdk.org/projects/amber/design-notes/on-ramp

Why should the entry point be a random special case? You're already admitting at this point that OOP is flawed so you might as well just have the balls to design a proper alternative (rather than a kludge)

It is, and it will be back soon just like Python's "if __name__ == '__main__'"...

It's not gone per se -- you can still write out the long form version if you want (this is required for backward compatibility).

What's now permitted is:

1. a simpler way of declaring a main method on a class -- you don't need the public or static, and the args is optional, so you can declare a `void main() { ... }` method on a constructable class;

2. declaring a main function (and other variables/functions) outside of a class -- here, the startup code will handle calling the main function, although I don't think the ability to call anonymous functions currently extends outside of the main function/file.

It ADDS complexity that doesn't actually exist. There's no "class" in the C entrypoint of a program. That's just nonsense.

C++ calls them free functions, and I always found them rather elegant. A common pattern, at least a few years ago, was to use free functions for anything that'd be a method in Java, but doesn't actually require access to anything non-public.

Back in 2005 or so, Java felt like "C++, but we know better" to me. I had no choice but to use it, but boy did they omit some stuff that was actually useful. The boilerplate back then (driven by both the limitations of the language and a surge in architecture astronauts) was absolutely insane. Don't even get me started on anything labelled "Java Enterprise" in the 2000s, bloat, slowness and bugs everywhere. IBM, Oracle and friends were running quite the circus. Creating working, performant software in that environment was a brutal challenge. I think Java, the language, is only partly to blame, but it was limited enough to spawn pretty complex code generators and frameworks.

Took the industy a decade or two to arrive at typed languages that were an actually good subset of C++ features. Java, in my opinion, wasn't one.

They are associated with a class, but the class is basically the file. There are limitations by doing it this way but it is out of preview and officially supported as of Java 25.

https://openjdk.org/jeps/512

If so, are we observing a move towards Universal Suffrage in the Kingdom of the Nouns? [1]

[1]: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

No, these are just default imports. Module import declarations are in for JDK 25 to make this kind of thing even easier: https://openjdk.org/jeps/511

I think all functions are associated with some class. But these classes sometimes are hidden from you and you don't need to know about them. Does that help you? What for would you use true free functions?

Nope. It's just sugar. [1]

It's somewhat implicit in the JVM spec, but functions are always bound to classes as methods. [2] The only kinds of heap objects you can have a reference to are class instances and arrays. [3]

The lack of free functions is really only a minor inconvenience for language implementers. Clojure, for instance, just compiles new classes to hold functions as methods.

From a programmer's perspective, you can write lambdas, but again, it's just syntactic sugar over an inner class.

[1] https://www.happycoders.eu/java/main-method/ [2] https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.h... [3] https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.h...

Presumably these exist in a Main.java file and the java class is implied. Similarly the string params are also implied, and the non param main() function is just an alias or a wrapper for main(String).

It's just syntactic sugar.

> this is something you learn like day 1 on learning java, and it's something you write once in a blue moon, like 0.001% of the code you are going to write.

I think this is the exact audience for this change: for newbies in day 1 of 10 years in their programming journey. Less boilerplate to just swallow, less time spent debugging an otherwise-fine lab exercise if not for the wrong instantiation of Scanner, more time actually focusing on the basics they should be focusing on.

Granted, I still think Java is a horrible first language to learn from or teach with but this is a step in the right direction. Might revisit this opinion in a few years, who knows.

Oh also, we use Java in production so we also have a bunch of ad-hoc "scripts" written in Java for mostly one-off interactions. Nonetheless, these scripts can get unwieldy fast. You'd think I'm exaggerating the benefit here but I, for one, welcome one less level of indentation in these scripts.

Mr Krabs!?

The goal is go make java easier to learn for people new to programming.

When they start with the old style there is an overload of concepts where the teacher just have to say "ignore all this", which is not ideal. With new style they grasp fewer concepts at first.

I'm not truly convinced this is such a big deal, but I lived through my university switching from Pascal to Java in the first programming class, and I can confirm people did get much more confused during the first few classes (to be fair they got way less confused later not having to deal with pointers tho).

Some people have so much time or so few things to do during the day that they can write a blog post about meaningless programming languade aestheticisms that only other frivolous people will understand and enjoy.

Excessive boilerplate code.

That's what I wanted to know too, but all we get is this one line:

> 1: When I was a Freshman in High School I asked a Junior what it meant. He had no clue.

OK... so it's confusing for juniors. A lot of stuff is. I probably didn't know what it all meant when I started either, but so what? You copy and paste it and move on. Eventually it makes sense. Not a big deal.