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

[Andrew Evers]

> If the blocks in your proposal are not instance initializers,
> this unfortunately makes it worse:
>
> - Even ignoring any possible syntactic ambiguity with instance
> initializers, now there are two identical-looking constructs in
> the language that mean subtly different things based on context.

The code is a Block, allowed in a lot of places.

Context is exactly the point. In the existing proposal both the developer
and some parts of Java need to be aware (within a few tokens of starting a
compilation unit) of two distinct contexts: a normal class and an anonymous
main class.

> - The "main blocks" are even more of an on-ramp-to-nowhere, since
> they would be illegal (or worse, mean something else!) in a full
> class.  Even without the conflict, this is creating a dead-end dialect
for the sake of avoiding a
> few keystrokes.

There is a clear pathway from the dialect to a full class, provided in the
original email.

If there is a goal that this proposal be a valid ClassBodyDeclaration in
the existing syntax, that should be clarified.

> Ultimately I think this proposal is motivated more by minimizing
character count than by reducing
> the number of concepts that simple programs must use, and as a result,
ends up creating net new
> complexity.

I would say that it retains the signature of main() exactly as it has been
for 20+ years, and allows an additional stage of using imports prior to
moving to the full class syntax. It's at most 13 bytes shorter, hardly
noticeable.

The original motivation of this proposal was when I was using Java as a
scripting language. Developers experienced in another language were
struggling with the exact concepts discussed here. We gave them a tool that
provided them with the option of using the simpler syntax, and how to move
to full class syntax when they hit its obvious limitations.

We found (over many years, we did this for Java 1.4) that not only was it
easier to grasp, but experienced folks would regularly write scripts up to
100 or so lines in the "with imports" version of syntax as it was still
more succinct. These scripts would typically be the sort of glue you see
tying systems together for process or data integration.

The second lesson would apply regardless of the exact syntax, as long as
imports are allowed. Without them, the on ramp is very short, since as soon
as you need something outside of java.lang, you're typing full package
names, and that is tedious (although var at least reduces this).

I think it would behoove the group to find a way for import statements to
be allowed.

On Mon, Apr 17, 2023 at 10:50 AM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> If the blocks in your proposal are not instance initializers, this
unfortunately makes it worse:
>
>  - Even ignoring any possible syntactic ambiguity with instance
initializers, now there are two identical-looking constructs in the
language that mean subtly different things based on context.
>
>  - The "main blocks" are even more of an on-ramp-to-nowhere, since they
would be illegal (or worse, mean something else!) in a full class.  Even
without the conflict, this is creating a dead-end dialect for the sake of
avoiding a few keystrokes.
>
> Ultimately I think this proposal is motivated more by minimizing
character count than by reducing the number of concepts that simple
programs must use, and as a result, ends up creating net new complexity.
>
>
>
> On 4/17/2023 10:24 AM, Andrew Evers wrote:
>
> Hi,
>
> 1. Understood.
>
> 2. I'm not proposing instance initializers, but this has caught two
people now.
>
> I'm proposing that absent a class declaration, the first block _is_ the
main method. You could even argue for the removal of the braces, but that
makes adding methods difficult. This is similar to the shell, python, PHP,
and PL/SQL anonymous blocks.
>
> On Mon, Apr 17, 2023 at 10:14 AM Brian Goetz <brian.goetz at oracle.com>
wrote:
>>
>>
>> > 1. Would it be at all possible to consider a main that returns int?
>> > Operating systems that don't support it are free to disregard it, and
>> > it feels better than System.exit(). It also allows skipping the idea
>> > of void, which is somewhat of a holdover from C.
>>
>> This is something we've left room to consider in the future, but feels
>> like "scope creep" at the present time.
>>
>> > 2. I have an idea for a slightly different approach to the problem
>> > that may solve a few of the problems being proposed, and allows for
>> > imports, which would make it more useful for scripting use cases.
>>
>> AFAICS, the spirit of what you're suggesting is to say that we can treat
>> an instance initializer as a "main" method.
>>
>> I would put this in the category of "clever" ideas, where you're
>> repurposing an existing language construct (instance initializers) to
>> avoid typing the characters "void main()".   Unfortunately, this fails
>> the "on ramp leads gracefully into the highway" test; when the class
>> gets complicated enough to need to be a named class, the instance
>> initializer sticks out like a sore thumb, because the author didn't want
>> an instance initializer, they wanted a main method.
>>
>>


On Mon, Apr 17, 2023 at 10:50 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> If the blocks in your proposal are not instance initializers, this
> unfortunately makes it worse:
>
>  - Even ignoring any possible syntactic ambiguity with instance
> initializers, now there are two identical-looking constructs in the
> language that mean subtly different things based on context.
>
>  - The "main blocks" are even more of an on-ramp-to-nowhere, since they
> would be illegal (or worse, mean something else!) in a full class.  Even
> without the conflict, this is creating a dead-end dialect for the sake of
> avoiding a few keystrokes.
>
> Ultimately I think this proposal is motivated more by minimizing character
> count than by reducing the number of concepts that simple programs must
> use, and as a result, ends up creating net new complexity.
>
>
>
> On 4/17/2023 10:24 AM, Andrew Evers wrote:
>
> Hi,
>
> 1. Understood.
>
> 2. I'm not proposing instance initializers, but this has caught two people
> now.
>
> I'm proposing that absent a class declaration, the first block _is_ the
> main method. You could even argue for the removal of the braces, but that
> makes adding methods difficult. This is similar to the shell, python, PHP,
> and PL/SQL anonymous blocks.
>
> On Mon, Apr 17, 2023 at 10:14 AM Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>>
>> > 1. Would it be at all possible to consider a main that returns int?
>> > Operating systems that don't support it are free to disregard it, and
>> > it feels better than System.exit(). It also allows skipping the idea
>> > of void, which is somewhat of a holdover from C.
>>
>> This is something we've left room to consider in the future, but feels
>> like "scope creep" at the present time.
>>
>> > 2. I have an idea for a slightly different approach to the problem
>> > that may solve a few of the problems being proposed, and allows for
>> > imports, which would make it more useful for scripting use cases.
>>
>> AFAICS, the spirit of what you're suggesting is to say that we can treat
>> an instance initializer as a "main" method.
>>
>> I would put this in the category of "clever" ideas, where you're
>> repurposing an existing language construct (instance initializers) to
>> avoid typing the characters "void main()".   Unfortunately, this fails
>> the "on ramp leads gracefully into the highway" test; when the class
>> gets complicated enough to need to be a named class, the instance
>> initializer sticks out like a sore thumb, because the author didn't want
>> an instance initializer, they wanted a main method.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230417/2280dad6/attachment-0001.htm>