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

[Samuel Audet]

I would say that deliberately making the behavior inconsistent with C/C++
is asking for trouble...

Besides, we have "enum class" for that in C++, so the mentality depends on
whether we're using C-style enums or "enum class".

Again, if this is just for system calls in C, that's not an issue, but C++
is a lot more. Trying to do everything differently from C++ will result in
people never figuring out how to use it!

Samuel

2018年4月3日(火) 3:36 Henry Jen <henry.jen at oracle.com>:

> 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
> >>>
> >
>
>