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

[Holo The Sage Wolf]

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

This is a non-goal, the anonymous main class can only be in the unnamed
package of the unnamed module, meaning it is very restricted in use, you
can also not reference any method (static or not) of the class from the
outside, so it is pretty much impossible to use this feature for utility
classes from design.

>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.

Again, the class is not visible by design. I also don't understand why it
will help modularize, the modularization order should be: "all in main" ->
"methods" -> "classes (and friends)" -> "files"

If you swap classes and files you ran into a risk of people stop using
classes all-together, while stop using files is very unlikely (furthermore,
it is ordered by size)

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

But the static solution would require new semantics and an unnamed class,
which are arguably as big of a language feature

On Tue, Apr 11, 2023, 19:31 Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> 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.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230411/d264ba5f/attachment-0001.htm>