<div dir="auto">I think it won't be a problem to allow imports in an anonymous class body as the "import xyz;" syntax isn't used by anything that could make this ambiguous.<div dir="auto"><br></div><div dir="auto">For the main method I think we have 2 valid paths to choose here. </div><div dir="auto"><br></div><div dir="auto">1. The whole file is main and we allow methods in methods meaning that the files content is practically a static main method in an anonymous class. (C# style)</div><div dir="auto"><br></div><div dir="auto">2. We keep the main method as a method static or non static with return type (void, int) "main" parameters (nothing or args) and the main block.  (currently proposed)</div><div dir="auto"><br></div><div dir="auto">Personally I prefer the later as it still provides a visual marker for the entry point and prevents confusion when for example a beginner switches from anonymous to a named class and wonders why he can't write statements in the class body. The difference between class scope and method scope is important to understand. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">A bit of topic but I would love to see methods in methods and statics in methods allowed regardless of the "main" topic as they are technically possible (using an inner class in the method) but have huge syntactic overhead due to the unnecessary inner class.</div><div dir="auto"><br></div><div dir="auto">Great regards </div><div dir="auto">RedIODev </div><div dir="auto"><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 18, 2023, 02:23 Andrew Evers <<a href="mailto:andrew.evers@gmail.com">andrew.evers@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="color:rgb(80,0,80)">> > I think it would behoove the group to find a way for import statements to be allowed.<br>> <br></span>> Imports are allowed. Can you say which part of the JEP led you to believe they aren’t? Maybe we need to clarify something.<br><div><br></div><div>The JEPs mention import four times. The first implies it might be possible, the second in the current launch protocol, and the other two prefaced by "excluding".</div><div><br></div><div>If there was an example that included an import statement, it would help a lot.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 17, 2023 at 7:42 PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank" rel="noreferrer">ron.pressler@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>
<br>
> On 17 Apr 2023, at 16:34, Andrew Evers <<a href="mailto:andrew.evers@gmail.com" target="_blank" rel="noreferrer">andrew.evers@gmail.com</a>> wrote:<br>
> <br>
> <br>
> 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.<br>
<br>
JEP 445 also support imports and also retains the signature of main. It just accepts a few more signatures, and also allows an instance main to process command-line arguments.<br>
<br>
> <br>
> I think it would behoove the group to find a way for import statements to be allowed.<br>
<br>
Imports are allowed. Can you say which part of the JEP led you to believe they aren’t? Maybe we need to clarify something.<br>
<br>
— Ron</blockquote></div>
</blockquote></div>