[enums] Enhanced enums: state of the implementation

[Vicente Romero]

On 03/24/2017 01:17 PM, Vicente Romero wrote:
> Hi all,
>
> The initial support for enhanced enums have been recently pushed to 
> the amber repo, see [1, 2, 3, 4]. The current implementation has been 
> reviewed and compared with the current draft of the enhanced enums JEP 
> [5], looking for synchronization and omission issues. Below there is a 
> summary of the current state of the implementation,
>
> Thanks,
> Vicente
>
>  * Implementation overview
>
> In general terms the enhanced enum implementation is concise and 
> pretty small (~500 lines of code). Almost all of the changes are in 
> the front-end, and are mainly focused in providing for the additional 
> expressibility of enhanced enums compared to legacy ones. There is one 
> change that can't be considered a front-end one, it's related to the 
> binary name of enhanced enum constants and will be mentioned below.
>
> In the parsing area, the approach used for legacy enums is leveraged 
> for enhanced enums. The basic idea is still that an enum constant is 
> converted to a class creation expression that is assigned to a 
> variable which type is the one of the enum constant. The main 
> difference is that additional work is needed to parse the type 
> arguments, in the case of generic enums.
>
> The binary names of enhanced enum constants are different to that of 
> legacy ones. For example give the following code snip:
>
> |    enum Foo {|
>
> |||A {},|
> |||B {};|
> |||}|


sorry some format escape here, the example should have been:

enum Foo {
     A {},
     B {};
}

Thanks,
Vicente

>
> The binary names assigned by a javac compiler, with no knowledge of 
> enhanced enums, to enum constants Foo.A and Foo.B are Foo$1 and Foo$2, 
> whereas in the case of the current enhanced enums implementation they 
> are Foo$$A and Foo$$B.
>
>
>  * Sync issues with the current draft of the JEP 301
>
>
> The naming convention proposed in the section above, and already 
> implemented, is different to the one proposed in the JEP [5].
>
>
> [1] 
> http://mail.openjdk.java.net/pipermail/amber-dev/2017-March/000029.html
> [2] 
> http://mail.openjdk.java.net/pipermail/amber-dev/2017-March/000039.html
> [3] 
> http://mail.openjdk.java.net/pipermail/amber-dev/2017-March/000040.html
> [4] 
> http://mail.openjdk.java.net/pipermail/amber-dev/2017-March/000044.html
> [5] http://openjdk.java.net/jeps/301
>
>