RFR Java types for anonymous C enums are generated with invalid class names.

[Henry Jen]

Mostly I agree. I am thinking along the same line, for completely anonymous like the second example, we would generate those in the global name space, i.e., the interface for the header file itself.

However, for any enum with name or typedef name, I’ll still prefer to have them in the named interface. I believe that’s more close to developer’s mentality or intention, also would be more consistent to future C++ work.

Cheers,
Henry


> On Apr 1, 2018, at 7:49 PM, Samuel Audet <samuel.audet at gmail.com> wrote:
> 
> C enums don't define a scope, so in my opinion whether they are anonymous or not, it doesn't make sense to try to wrap them in an interface or a class. Developers pay no attention to the name of these enums when using them in C, so why should they when using them from Java? Further, when they are anonymous, it forces users to give them a decent name, but since these don't have any names to start with, it becomes that much harder to figure out a way to refer to them! In JavaCPP, I just declare them as "public static final int" in the "global" namespace. Taking the example from the bug tracker:
> 
> typedef enum temp {
>    ONE,
>    TWO
> } temp_t;
> 
> enum {
>    Java,
>    C,
>    CPP,
>    Python,
>    Ruby
> };
> 
> typedef enum {
>    RED = 0xff0000,
>    GREEN = 0x00ff00,
>    BLUE = 0x0000ff
> } color_t;
> 
> enum SIZE {
>    XS,
>    S,
>    M,
>    L,
>    XL,
>    XXL
> };
> 
> JavaCPP maps this to:
> 
> /** enum temp */
> public static final int
>    ONE = 0,
>    TWO = 1;
> 
> /** enum  */
> public static final int
>    Java = 0,
>    C = 1,
>    CPP = 2,
>    Python = 3,
>    Ruby = 4;
> 
> /** enum color_t */
> public static final int
>    RED = 0xff0000,
>    GREEN = 0x00ff00,
>    BLUE = 0x0000ff;
> 
> /** enum SIZE */
> public static final int
>    XS = 0,
>    S = 1,
>    M = 2,
>    L = 3,
>    XL = 4,
>    XXL = 5;
> 
> Samuel
> 
> On 03/30/2018 10:56 AM, Henry Jen wrote:
>> Author role is needed to have account on openjdk JIRA, which means at least have a signed  Oracle Contributor Agreement in place.
>> See http://openjdk.java.net/bylaws#author for details.
>> Without Author role, you can read the bugs but won’t be able to do any modification. Before gain the author role, participate in this mailing list and existing contributor can help to modify the bug. Hope that helps.
>> Cheers,
>> Henry
>>> On Mar 29, 2018, at 5:09 PM, Samuel Audet <samuel.audet at gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I would like to participate in that thread, but it does not look like I can log in there, and it does not appear possible to sign up either. What would I need to do to get an account?
>>> 
>>> Samuel
>>> 
>>> On 03/30/2018 04:11 AM, Henry Jen wrote:
>>>> Thanks, this fix part of the issue we encountered with anonymous enum.
>>>> I filed a bug JDK-8200452[1] for various cases, we need to have a better strategy for naming anonymous enum, particularly when without typedef.
>>>> Cheers,
>>>> Henry
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200452
>>>>> On Mar 27, 2018, at 10:00 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>>>> 
>>>>> Please review.
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~sundar/jextract_anonymous_enum/webrev.00/
>>>>> 
>>>>> Thanks,
>>>>> -Sundar
>>> 
>