<html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    <p><br>

    </p>

    <div class="moz-cite-prefix">On 29/03/2023 19:33, Archie Cobbs

      wrote:<br>

    </div>

    <blockquote type="cite" cite="mid:CANSoFxu-DvRLtmJM8ADgbS377=RJqJj3brF6mpZb0W6zHDUQzg@mail.gmail.com"><span style="font-family:monospace">        Set<Foo<?>>

        fooSet = EnumSet.noneOfGeneric(Foo.class);</span></blockquote>

    <p>Of course you can say Set<Foo<?>> - but you can't say

      EnumSet<Foo<?>>.</p>

    <p><br>

    </p>

    <p>

      <blockquote type="cite">Personally, I would still be happy to have

        generic enums even without any accomodation by EnumSet/EnumMap.</blockquote>

    </p>

    <p>I hear you - but I believe that EnumSet/Map with their methods

      are just a reminder of what would actually happen should we

      unleash generic enums in the large. There are many API

      enum-friendly points sedimented over the years which use the exact

      same patterns as EnumSet/Map - all these API points will not be

      usable when working with a generic enum. So, even if the JDK might

      come up with some solution for its own problematic classes (and

      that solution is not even 100% satisfying), there are classes

      outside our control that will just not work with the new enums.

      One rule we try to stick to when adding new features to the Java

      language, is that it should look like they have been there from

      the start. WIth generic enums that's sadly not the case, and

      worse, they create a split between API points that work with them

      and those which don't, which is ultimately bad for the ecosystem.</p>

    <p>(That's not to say that generic enums are not useful - I still

      find many useful applications for them...)</p>

    <p>Maurizio<br>

    </p>

    <p><br>

    </p>

  </body>

</html>