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

[Hunor Szegi]

Ok, I phrased it incorrectly. I see that technically it isn't static. My
concern is that the "main" method is usually static (until now it is always
that), but now you will be able to create a main method without the
"static" keyword. So for a beginner, without understanding fully the
difference between static and non-static (which isn't easy!) it seems that
the main became implicitly static. At least it behaves very similarly, and
it will work with or without the static keyword. So it can lead to
confusion. The class instantiation is hidden, so syntactically it seems the
main method became static automatically.

That's why I was thinking of a drastically new entry point declaration,
which can't be mixed up with the old static method. To avoid that order,
the main method is looked up. In theory it could be named differently.
Instead of "main" it could be called "start" for example. But I know we
should be careful using new words. So I thought that using simply "main()"
would be completely different to the current "public static void main()"
solution. "If we have the former, the latter should be disallowed." So in
practice it could be used as a simpler entry point. (With or without args.)

Hunor

On Tue, 11 Apr 2023 at 21:37, Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Hunor Szegi" <hunor.szegi at gmail.com>
> *To: *"amber-dev" <amber-dev at openjdk.org>
> *Sent: *Tuesday, April 11, 2023 10:29:33 PM
> *Subject: *Re: New candidate JEP: 445: Flexible Main Methods and
> Anonymous Main Classes (Preview)
>
> Hi All,
>
> Thank you for this new proposal, I like the idea of JEP 445 with the
> flexible main methods. My only concern is the implicit "static" keyword.
> Which means the initially learned main method format should be modified
> later, so this doesn't really support the gradual learning curve. It is
> even a little bit against the goal "Do not introduce a separate beginner's
> dialect of Java."
>
>
> There is no implicit static.
> It works the other way around, the launcher first checks for a static main
> and if none is found, it checks for a non static main and a default
> constructor.
>
> So I repeat, there is no implicit static.
>
> [...]
>
>
> Thanks,
> Hunor
>
>
> regards,
> Rémi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230411/4ba02f46/attachment-0001.htm>