This seems to be a weird micro-optimisation. While I agree with some of the goals (classless files, parameterless main exist in Kotlin and are nice to have), they should, in my opinion, not be implemented for the sole purpose of making `main` as minimal as possible.

I don't think you need to understand every single character of your very first program right from the beginning. A few of the concepts can be hand waved away to be explained in a later chapter without impeding the overall understanding of programs once you left the sub-twenty-lines beginner programs.

Doesn't Groovy (https://groovy-lang.org) achieve much of this? I remember being taught with it at university for some time before they introduced Java. With Groovy you don't need the class or main method, and can have a program which is just `println "Hello world!"`.

Another option that seems better in my mind at least is any classless java file is just a class with the same name as the file implementing Runnable. run() is a better name for a main() method anyway.

Not a Java dev here, at least in part because the amount of ceremony to do trivial things seems excessive.

My understanding is that the ceremony and redundancy is deliberate. You type the same meaning multiple times so the compiler can detect inconsistencies and tell you about them. I.e. it's a feature, not a bug. Slightly analogous to type annotations or unit tests, one wants to write the redundant information in exchange for compiler diagnostics.

Syntactic sugar to make the language less annoying to work in is opposed to that goal, hard to guess if that's better for the target market.

I wonder - why he has not take it a step further and propose to get rid of return type (void) also? It would look even more slick (add optional semicolons and we will get javascript out of this :)).

main() { println("Hello World"); }

I know that this notation is traditionally reserved for constructors but I'm not 100% sure why we cannot differentiate between methods and constructors just by looking at class name?

Kotlin's syntax is cleaner in some most places, more explicit in some places (no implicit nulls, and wrt generics) and much terser when using naked functions etc.

Did Java's papa get jealous?

Confused about the criticisms now. Otherwise everybody complains about Java boilerplate. Remove some of it and make it optional, to avoid bogging down newbies in irrelevant details in the first instance, and further lead to less boilerplate to make simpler applications in the second instance (or further down the line). I'm not seeing a massive amount of effort being expended here, and I don't see how it's being wasted.

I am amused by this:

> Worse, the early exposure to static methods will turn out to be a bad habit that must be later unlearned.

I have been using Java since 1.0 and it is my default language. I am writing Java code today.

I write functions using ‘static’ all the time. I prefer that a function be static. It shows that it does not depend on state of the enclosing object. Using ‘static’ on methods is not a bad habit. Having static fields and state is to be avoided.

I always love seeing Brian Goetz’s articles, they explain the problem succinctly and they do a great job of validating their approach, showing the shortcomings of alternatives.

I especially like the language team’s very conservative attitude, valuing backwards compatibility greatly. Here, they again solve most of the problem by simply changing the “program launcher” code, without any modifications/special casing done on the language level. For the rest, we will see. I think foregoing public requirements is a no-brainer, the rest may need a bit further thought based on further comments, here is the mailing list: https://mail.openjdk.org/pipermail/amber-spec-observers/2022...

The declaration of a class and the incantation of public static void main is pure mystery to a beginning programmer.

This article misses the point, however. The problem is not writing your first hello world. The ceremony is not so much in the language itself but in the infrastructure. The verbosity of the language is just the tip of the iceberg.

I think Java back in the 90's started out actually quite decently, although from the get-go it had the verbosity. But at least it didn't have everything else yet that you're expected to know for any non-trivial program.

The first time the word "enterprise" appeared together with Java was the moment it went all downhill.

I have long considered that having to have the class definition explicit in the file is redundant, especially as the 2 have to have the same name anyway. Obviously if you need to `extend` or `implement` then an explicit declaration is needed. But otherwise, just defaulting to the file base name is more than sufficient.

When i read the title, I thought they were finally going to fix gradle or improve maven. Those are the real on-ramps and they are a much bigger barrier to entry than main().

A cleaner/simpler alternative was Kobalt, but it’s now abandoned. A simple, official build tool would make the ecosystem easier to learn.

https://github.com/cbeust/kobalt

I like the idea of simplifying the main method, but it's honestly not a huge barrier as a high school teacher. Most IDEs will fill in the declaration of main for you, and I think it's perfectly fine to tell students "we'll worry about that later, write your code in the braces" without diving in to all the details. To me, what would be more helpful is an easier way to read input from stdin during a program. I usually give my intro students a static class that wraps Scanner, but it's a bit of a pain.

Applause! However, it's not always about "saving keystrokes"... it's about lowering accidental complexity and making code easier to reason about by requiring less cognitive load on the reader.

Another example: the lack of literals for collections in Java. Imagine this:

  Map x = {"a": "A", "b": "B"}; // not Java

vs:

  Map x = new java.util.HashMap();
  x.put("a", "A");
  x.put("b", "B");

The first case is more declarative, and thus easier to grasp. In the second case you have to read, parse and "execute" line by line in your head... (Does ordering matter? Does line 3 depend on line 2?, etc).

When things like these compound, you end up with code-bases many times bigger and harder to grasp than in other languages.

Granted: you can write shitty code in any language, nothing will save you from that... But I think Java makes it harder to write simple and concise code, even to experienced coders.

Then there's also the "cultural" thing many already mentioned ("enterprise Java")... which is very real, but no JEP/JSR will fix that ;-).

Brian shows brilliance, even at "trivial" issues. I trust his judgement :-).

C# has this on their new ASPNET 7.0 docs. To have a single Program.cs file with all the builder and app code . incredibly accessible to a new learner of the framework.