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

Andrew Evers andrew.evers at gmail.com
Thu Apr 13 17:12:47 UTC 2023


There isn't an ambiguity as the simplified syntax I'm proposing doesn't
allow for an instance initialization block. For the instance initialization
block to be available, you must be in a class declaration, at which point
you're in the full syntax.

Parsing would be as follows, if the first token is:
* package - parse and work as a normal java class
* import - parse import statements until you reach either '{' or a token
that starting with a letter
  - if a letter, then treat as a normal java class
  - if { use this syntax.

When I have implemented this in the past, I've written it as a frontend and
generated an underlying Java source file to pass to the standard compiler
(the template using class Main is an example), then done line number fixups
on the errors.

On Thu, Apr 13, 2023 at 12:55 PM Holo The Sage Wolf <holo3146 at gmail.com>
wrote:

> I can't comment on the first point, but the second point won't work.
> The syntax you suggested creates at best an order of declaration
> dependency between the entry point and the instance initialized block, and
> at worst an ambiguity to the compiler.
>
> Also, I believe that in the current solution it is possible to import in
> an unnamed main class.
>
> On Thu, Apr 13, 2023, 18:49 Andrew Evers <andrew.evers at gmail.com> wrote:
>
>> Hi,
>>
>> I really like the idea of reducing the amount of boilerplate required to
>> get to a simple Java program.
>>
>> Two comments:
>> 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.
>> 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.
>>
>> Here are three examples showing the syntax.
>>
>> Example 1:
>> {
>>   System.out.println("Hello, World");
>> }
>>
>> Example 2:
>> import java.nio.*;
>>
>> {
>>   Path filePath = Path.of("file.txt");
>>   String fileContent = new String(Files.readAllBytes(filePath));
>>   System.out.println("Content is " + fileContent);
>> }
>>
>> Example 3:
>> import java.nio.*;
>>
>> {
>>   Path filePath = Path.of("file.txt");
>>   String fileContent = new String(Files.readAllBytes(filePath));
>>   greet(fileContent);
>> }
>>
>> void greet(String s)
>> {
>>   System.out.println("Content is " + s);
>> }
>>
>> The rules are simple:
>> 1. If the first non-whitespace is a {, then treat it as the block
>> defining the method public static void main(String [] args).
>> 2. If the first non-whitespace is "import" then capture the imports.
>> 3. If there is non-whitespace after the closing } in the main block,
>> include it before the class closing brace.
>>
>> That is:
>>
>> // import statements if any
>> class Main
>> {
>>   public static void main(String [] args)
>>   { // Content including { from source
>>   } // end of content, including }
>>
>>   // Content after closing } in source, if any.
>> }
>>
>> There are some minor fixups required on line numbers after the import
>> statements, these can be overcome by either ensuring that the additional
>> code takes up zero lines, or by fixing up the output of the compiler.
>>
>> Regards,
>>
>> Andrew.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230413/3f2e0c4d/attachment.htm>


More information about the amber-dev mailing list