<div dir="ltr">> If the blocks in your proposal are not instance initializers, <br>> this unfortunately makes it worse:<br>><br>> - Even ignoring any possible syntactic ambiguity with instance<br>> initializers, now there are two identical-looking constructs in<br>> the language that mean subtly different things based on context. <br><br>The code is a Block, allowed in a lot of places.<div><br></div><div>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.</div><div><br>> - The "main blocks" are even more of an on-ramp-to-nowhere, since<br>> they would be illegal (or worse, mean something else!) in a full <div>> class. Even without the conflict, this is creating a dead-end dialect for the sake of avoiding a </div><div>> few keystrokes.</div><div><br></div><div>There is a clear pathway from the dialect to a full class, provided in the original email. </div><div><br></div><div>If there is a goal that this proposal be a valid ClassBodyDeclaration in the existing syntax, that should be clarified.<br><br>> Ultimately I think this proposal is motivated more by minimizing character count than by reducing</div><div>> the number of concepts that simple programs must use, and as a result, ends up creating net new</div><div>> complexity.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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).</div><div><br></div><div>I think it would behoove the group to find a way for import statements to be allowed.<br><br>On Mon, Apr 17, 2023 at 10:50 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br>><br>> If the blocks in your proposal are not instance initializers, this unfortunately makes it worse:<br>><br>> - 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. <br>><br>> - 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. <br>><br>> 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.<br>><br>><br>><br>> On 4/17/2023 10:24 AM, Andrew Evers wrote:<br>><br>> Hi,<br>><br>> 1. Understood.<br>><br>> 2. I'm not proposing instance initializers, but this has caught two people now.<br>><br>> 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.<br>><br>> On Mon, Apr 17, 2023 at 10:14 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br>>><br>>><br>>> > 1. Would it be at all possible to consider a main that returns int?<br>>> > Operating systems that don't support it are free to disregard it, and<br>>> > it feels better than System.exit(). It also allows skipping the idea<br>>> > of void, which is somewhat of a holdover from C.<br>>><br>>> This is something we've left room to consider in the future, but feels<br>>> like "scope creep" at the present time.<br>>><br>>> > 2. I have an idea for a slightly different approach to the problem<br>>> > that may solve a few of the problems being proposed, and allows for<br>>> > imports, which would make it more useful for scripting use cases.<br>>><br>>> AFAICS, the spirit of what you're suggesting is to say that we can treat<br>>> an instance initializer as a "main" method.<br>>><br>>> I would put this in the category of "clever" ideas, where you're<br>>> repurposing an existing language construct (instance initializers) to<br>>> avoid typing the characters "void main()". Unfortunately, this fails<br>>> the "on ramp leads gracefully into the highway" test; when the class<br>>> gets complicated enough to need to be a named class, the instance<br>>> initializer sticks out like a sore thumb, because the author didn't want<br>>> an instance initializer, they wanted a main method.<br>>><br>>><br></div></div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 17, 2023 at 10:50 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<font size="4"><font face="monospace">If the blocks in your proposal
are not instance initializers, this unfortunately makes it
worse:<br>
<br>
- 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. <br>
<br>
- 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. <br>
<br>
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.<br>
<br>
<br>
</font></font><br>
<div>On 4/17/2023 10:24 AM, Andrew Evers
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>1. Understood.</div>
<div><br>
</div>
<div>2. I'm not proposing instance initializers, but this has
caught two people now.</div>
<div><br>
</div>
<div>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.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Apr 17, 2023 at
10:14 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> 1. Would it be at all possible to consider a main that
returns int? <br>
> Operating systems that don't support it are free to
disregard it, and <br>
> it feels better than System.exit(). It also allows
skipping the idea <br>
> of void, which is somewhat of a holdover from C.<br>
<br>
This is something we've left room to consider in the future,
but feels <br>
like "scope creep" at the present time.<br>
<br>
> 2. I have an idea for a slightly different approach to
the problem <br>
> that may solve a few of the problems being proposed, and
allows for <br>
> imports, which would make it more useful for scripting
use cases.<br>
<br>
AFAICS, the spirit of what you're suggesting is to say that we
can treat <br>
an instance initializer as a "main" method.<br>
<br>
I would put this in the category of "clever" ideas, where
you're <br>
repurposing an existing language construct (instance
initializers) to <br>
avoid typing the characters "void main()". Unfortunately,
this fails <br>
the "on ramp leads gracefully into the highway" test; when the
class <br>
gets complicated enough to need to be a named class, the
instance <br>
initializer sticks out like a sore thumb, because the author
didn't want <br>
an instance initializer, they wanted a main method.<br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div>