New candidate JEP: 445: Flexible Main Methods and Anonymous Main Classes (Preview)

[Attila Kelemen]

Thanks. I don't want to make an estimate on how much boilerplate
removal helps this to spread for shebang given that I didn't even know
it's already supported (and as far as I can see it is supported for
quite a long time now). So, I'll just assume that it will (there is
really no good reason to assume otherwise anyway).

What remains for me is that I don't see why not the "Interpret code
units as static members" alternative was chosen. That section of the
JEP provides two reasons:

1. It would make "static" implicit which is not the case in normal
classes. However, default modifiers depending on the context is
already a thing: Enum constructors are private by default, interface
members are public by default, while interface fields are implicitly
static. I don't see why this particular case would be a heresy.

2. Copy pasting the code when "upgrading" to classes would change the
code. However, this is only a noticeable issue, if some methods are
explicitly marked as "static", which is unlikely (might happen due to
copy pasting from external sources), and even if that were to happen,
the worst case scenario is a compilation error which is easy to fix,
and might even have educational value to the student. Or, if fields
were marked explicitly static, in which case it will matter if more
than one instance of that class is created (which I think is still
unlikely at this point).

However, there are also benefits to the "static" approach (which seems
to outweigh the cons for me) to basically make it a utility class:

1. If we are talking about a non-beginner programmer, but someone new
to Java, I would argue that it is less surprising to consider "top
level" functions to be static. Of course, if the implied class is not
visible to others, then it doesn't make much difference (same way as
with the con 2).

2. It would also make writing utility classes easier, thus benefiting
more people.

3. It would allow (assuming the implied class would be visible to
others) students to first "modularize" their application into separate
logical units before going to classes. At least in my mind, the
logical progress of learning would be (in order): functions + basic
types, loops and such, arrays, records, organizing code into logical
units, classes: make that logical unit non-static, ...

4. It would not require touching the "main" finding logic. That could
be considered separately in another JEP.

So, for me it seems that the "static" approach would have more
utility. Pun totally intended. If you want, I can even provide a much
more detailed description of how I imagine such a "static" solution
would work.

Attila

Brian Goetz <brian.goetz at oracle.com> ezt írta (időpont: 2023. ápr.
11., K, 1:24):
>
> As you allude to, there is already the “Single File Source Launcher”, which let’s you run a Java program directly from the command line without compilation (`java Foo.java`), which has been around for a while, and additionally does support “shebang” execution.  (There are plans to extend this further.). This was aimed at script-like programs, which, while not written by beginners, also do not require the ceremony of the class declaration.  So the design center here is not “beginning programmers”, but “simple programs”, but of course there is a lot of intersection between the two — beginning programmers write simple programs.
>
> There is also a chicken-and-egg problem here; one of the reasons people don’t write script-like programs in Java so often is because of the declaration and building overhead.  But that’s an accidental consequence, and we can remove these impediments.  So students may be the most obvious group of beneficiaries, but they are not the only ones.
>