<div dir="auto"><div>>2. It would also make writing utility classes easier, thus benefiting<br>more people</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">>3. It would allow (assuming the implied class would be visible to</div><div dir="auto">others) students to first "modularize" their application into separate</div><div dir="auto">logical units before going to classes.</div><div dir="auto"><br></div><div dir="auto">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"</div><div dir="auto"><br></div><div dir="auto">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)</div><div dir="auto"><br></div><div dir="auto">>4. It would not require touching the "main" finding logic. That could</div><div dir="auto">be considered separately in another JEP.</div><div dir="auto"><br></div><div dir="auto">But the static solution would require new semantics and an unnamed class, which are arguably as big of a language feature <br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Apr 11, 2023, 19:31 Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com">attila.kelemen85@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks. I don't want to make an estimate on how much boilerplate<br>
removal helps this to spread for shebang given that I didn't even know<br>
it's already supported (and as far as I can see it is supported for<br>
quite a long time now). So, I'll just assume that it will (there is<br>
really no good reason to assume otherwise anyway).<br>
<br>
What remains for me is that I don't see why not the "Interpret code<br>
units as static members" alternative was chosen. That section of the<br>
JEP provides two reasons:<br>
<br>
1. It would make "static" implicit which is not the case in normal<br>
classes. However, default modifiers depending on the context is<br>
already a thing: Enum constructors are private by default, interface<br>
members are public by default, while interface fields are implicitly<br>
static. I don't see why this particular case would be a heresy.<br>
<br>
2. Copy pasting the code when "upgrading" to classes would change the<br>
code. However, this is only a noticeable issue, if some methods are<br>
explicitly marked as "static", which is unlikely (might happen due to<br>
copy pasting from external sources), and even if that were to happen,<br>
the worst case scenario is a compilation error which is easy to fix,<br>
and might even have educational value to the student. Or, if fields<br>
were marked explicitly static, in which case it will matter if more<br>
than one instance of that class is created (which I think is still<br>
unlikely at this point).<br>
<br>
However, there are also benefits to the "static" approach (which seems<br>
to outweigh the cons for me) to basically make it a utility class:<br>
<br>
1. If we are talking about a non-beginner programmer, but someone new<br>
to Java, I would argue that it is less surprising to consider "top<br>
level" functions to be static. Of course, if the implied class is not<br>
visible to others, then it doesn't make much difference (same way as<br>
with the con 2).<br>
<br>
2. It would also make writing utility classes easier, thus benefiting<br>
more people.<br>
<br>
3. It would allow (assuming the implied class would be visible to<br>
others) students to first "modularize" their application into separate<br>
logical units before going to classes. At least in my mind, the<br>
logical progress of learning would be (in order): functions + basic<br>
types, loops and such, arrays, records, organizing code into logical<br>
units, classes: make that logical unit non-static, ...<br>
<br>
4. It would not require touching the "main" finding logic. That could<br>
be considered separately in another JEP.<br>
<br>
So, for me it seems that the "static" approach would have more<br>
utility. Pun totally intended. If you want, I can even provide a much<br>
more detailed description of how I imagine such a "static" solution<br>
would work.<br>
<br>
Attila<br>
<br>
Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank" rel="noreferrer">brian.goetz@oracle.com</a>> ezt írta (időpont: 2023. ápr.<br>
11., K, 1:24):<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
</blockquote></div></div></div>