Extra language specification rules that you need to be aware of for your whole career... in order to make the first 30 seconds easier when looking at hello-world for the first time.

The genius of this proposal is that besides the implicit unnamed class, the other changes are all purely done to the program launcher program, no changes are proposed for the language at all.

And one could argue that quickly writing up some program happens often regardless of skillset (I do make at least two psvm Main classes per month), so the code reduction there is also a welcome change.

> the other changes are all purely done to the program launcher program, no changes are proposed for the language at all

But the behaviour of the launcher is covered by the language spec isn't it? It's the language that specifies how main is selected.

https://docs.oracle.com/javase/specs/jls/se19/html/jls-12.ht...

Well, there is nothing in the spec that says would forbid the JVM loading a ProgramLauncher.class file with a public static void main method, which will look at the program arguments and if it has something ending in .java, it will compile that file, and load the resulting class (current mode of execution).

Also, even if it might become a spec change (a language level one, not a jvm level one), it will be an additive change, at worst some new program won’t run on older JVMs, but all old program will continue to run on new ones.

As I mention on the sibbling comment, C# 10 already went through this.

For me it seems like a reaction to JavaScripts and Pythons of this world, optimizing for Hello World just to win over them on those 30 seconds.

They are going to rewrite their applications anyway, when performance comes knocking on the door.

I think there is more value to a terse declaration of 'main()' than people think. In C#, you can declare a quite functional microservice under 90 lines of code with asp.net core's minimal api format. To this day I think the "enterprise style religious OOP+SOLID Java/C#" is something that has to go - so many applications that take 30 files and 4 projects could've been declared in 3-5 files with the most of core logic being in Program.cs that you can grasp within few seconds of looking at it.

It will never go away, before it was COBOL, xBase, C, C++, Smalltalk.

Tomorrow might be Go, Rust, Zig, or whatever they fancy using.

These are projects at scale of dozens of developers with various skill sets distributed around the world, optimizing for Hello World hardly matters.

It's also a reaction to languages like Kotlin that already have these and run on top of the JVM. With Kotlin these don't apply just to main. IIRC, other JVM languages have similar reductions in boiler-plate compared to Java.

C# just went through this for C# 10, which I find a waste of resources, optmizing for "Hello World" is not what matters in large scale engineering.

Large scale engineering is totally beside the point for this. This is about optimizing for teaching a first language (since many will stick with that).

Read the article, the "static trap" is a real thing for new students (on top of all other ceremony). To solve the issue of main being non-static some students will start to put static everywhere as a 'fix' to their initial issue, a day or two later they'll be asking why every student gets the same name (because they have one static variable to keep the student or name objects).

The verbosity of Java also introduces another more serious problem for learning, not only do the students have problems compiling, they also start putting their mind on focusing on syntax instead of logic once they're past the first few problems. The issue of de-programming students from this affliction is waaay too common to be ignored.

Back when I was a TA, first year students got along just as well with Pascal, Fortran and C++, many of which lacked a programming background.

I wasn't found of minimal APIs, global usings and implicit Program.cs for C# 10, and share a similar opinion in relation to Java.

No need to try to make it look like JavaScript and Python, each language has its place.

Anecdata - I'm self taught. Started my learning on Python.

I wanted to delve into Java. And sure enough, my very first thoughts were "wtf is public static void, why does this even matter, and why is print() so weird and long?"

Shit, I ended up finding it easier to get into F# than Java.

Then I got hired for a Java role, which is proof that the universe has a sense of humour.

And none of the listed languages enforce main to be part of a class, hence the described problem didn't exist for your students.

I've taught C to beginners after the Java class and whilst there are some related problems those students encounter, the extra confusion caused by having main in a class doesn't exist (and doesn't cause as much syntax vs logic confusion later on).

I can assure you they were using OOP in C++, creating their own standard library, leaving behind the ways of C, as any proper C++ course during the ARM C++ days.

The lecture notes that eventually became this book were their path into discovering C++.

https://www.bertrand.pt/livro/programacao-com-classes-em-c-p...

"Top-level statements" in C# is a double edge sword: In a long run it will help make C# a bit more approachable to an absolute beginner to programming by reducing "noise" and cognitive load but right now it tends to confuse the beginner due to countless tutorials, SO answers, books, courses being written using using, namespace, class, Main structure.

Which makes the feature kind of pointless. Especially since all teaching materials (and those who have used them for teaching) were saying to just ignore the rest for now and concentrate on

  Console.WriteLine("Hello World!");

which is, as it's written, confusing to a beginner anyway ("What is Console?") until he learns about classes, after which both namespace and using get clear(er).

It's not optimising for Hello World. It's optimising for a new student's learning experience, so that concepts can be introduced in a more reasonable order.

I beg to differ, as soon as they need a second file, import a dependency or use additional helper methods, they get to face all of it anyway.

And then there is the issue with leaky abstractions when the code that gets compiled interfers with the ideal worlds that the compiler injects, and possible confusing error messages get generated.

Like it happens with all guest languages that target the JVM pretending to be Java, and one gets a confusing stack trace only understandable by those with proper Java background.

> as soon as they need a second file, import a dependency or use additional helper methods, they get to face all of it anyway.

The problem isn't the set of things students will need to learn, but the order in which they encounter them. Students write a one-file program before they write a two-file one, but because Java is optimised for large programs, today they encounter things like accessibility rules -- which exist to serve large programs -- before they even get to write a very small one. That's the idea of the "on-ramp" in the title -- you end up int the same place, but with a smoother ride.

Both students and teachers who prefer Python to Java as a first language mentioned this "on-ramp" problem as one of the reasons. There are others, and they will be addressed by other enhancements.

BTW, importing other packages and using helper methods does not require knowing about accessibility rules.

> Like it happens with all guest languages that target the JVM pretending to be Java, and one gets a confusing stack trace only understandable by those with proper Java background.

But this is not a "guest language" and we'll need to ensure that stack traces -- which we also control -- will not be confusing.

If we're talking beginners / students here couldn't this all be hidden by a specialized IDE? Why the need to put it into "real Java"?

Lets see how much better it gets over C# 10 then.