New candidate JEP: 463: Implicit Classes and Instance Main Methods (Second Preview)

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Nov 2 09:32:52 UTC 2023


Hi David

On 01/11/2023 21:23, David Alayachew wrote:
> 1. In the name of simplifying things for beginners, what is the reason 
> why the main method is specifically called "main"? Would not "run" or 
> something similar be better? The word "main" implies to me that it is 
> the "main" method (out of all of the others). But that right there 
> means I must be aware of the concept of there being multiple methods. 
> But again, that's forcing the beginner to think about concepts that 
> they don't yet need to. Most students' first programs will be solely 
> contained in a single method.

I believe calling it any name other than "main" would compromise one of 
the main goals of this JEP, which is stated nicely in the "Growing a 
program" section (I actually believe this section is, IMHO, the most 
important one in the JEP, and the ones that is driving many of the 
decisions contained in it!):

> Even so, all members are interpreted just as they are in an ordinary 
> class. To evolve an implicit class into an ordinary class, all we need 
> to do is wrap its declaration, excluding |import| statements, inside 
> an explicit |class| declaration.

Perhaps there's a more intuitive name out there - but regular classes 
would still need a "magic" name to pick what they want to run. And since 
"main" is the magic name that's been used for the last 25 years, our 
hands were a bit forced here...


>
> 2. Alternatively, could we have the name be irrelevant if it is the 
> only method in the class? If we do that, then the concept of the 
> "main" method would be really impactful, because, once you introduce 
> the concept of multiple methods, students are likely to ask themselves 
> "which method will get run first?" In that instance, the concept of a 
> method called main wll be extremely intuitive and understandable. I 
> really like this idea. I feel like we have an opportunity for a 
> memorable "light bulb" moment in student's minds. If they ask 
> themselves which method will be called now that there are multiple, 
> the "main" method will make perfect sense the first time. It will 
> complicate that launch protocol. For example, do we allow parameters? 
> I say, it should follow suit with "main" semantics.

Again, quoting from the above section:

> Eliminating the |main| method altogether may seem like the natural 
> next step, but it would work against the goal of gracefully evolving a 
> first Java program to a larger one and would impose some non-obvious 
> restrictions (see below <https://openjdk.org/jeps/463#Alternatives>). 
> Dropping the |void| modifier would similarly create a distinct Java 
> dialect.
So, it seems natural for an implicit class with one method to behave 
exactly like an implicit class with two methods. Adding special rules 
for an implicit class with one method seems ad-hoc and likely to 
backfire. E.g. you add a method and your program no longer compiles or, 
if you are unlucky and you call the second method "main" now you launch 
that one instead, perhaps unkowingly.

Cheers
Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231102/58d0b04b/attachment-0001.htm>


More information about the amber-dev mailing list