title: Mapping Collection of Enum types that implement interface
body: <p>I've got a tricky thing I'm trying to map with Enums for storing static data.</p>
  
  <p>It starts off with enum classes declared as such:</p>
  
  <pre><code>interface MyInterface {
      String getName();
  }
  
  public enum A implements MyInterface {
  FIRST_A("First A");
  private final String name;
  private A(String name) {
  this.name = name;
  }
  public String getName() {
  return name;
  }
  
  public String toString() {
  return name;
  }
  }
  
  public enum B implements MyInterface {
  FIRST_B("First B");
  private final String name;
  private B(String name) {
  this.name = name;
  }
  public String getName() {
  return name;
  }
  
  public String toString() {
  return name;
  }
  }</code></pre>
  
  <p>Now I want to use these as:</p>
  
  <pre><code>List&lt;MyInterface&gt; elements</code></pre>
  
  <p>The problem comes in mapping the collection.  I can persist these just fine normally if I use a CompositeUserType I've written for writing the class of the enum being persisted as well as the String value that would come from persisting an @Enumerated with the EnumType.STRING.  In those cases I can declare:</p>
  
  <pre><code>
  @Type(type="MyCustomEnumType.class")
  @Columns(columns = {
              @Column(name = "enumValue"), @Column(name = "enumClass")
  })
  private Enum enumValue;</code></pre>
  
  <p>In that case I can persist them just fine, but I'm uncertain if using @Type on the collection will make all items inside that collection persist using that custom type.  Should I use @ElementCollection as well on it since it's such that it's embeddable?  Or do I use the user type class I've written as the targetClass of the collection?  I'm a bit confused on how it works for something like that.   I want to keep it generic enough to persist A or B possibly in the collection (although it will end up being only one type per entity persisted, but could be either).</p>
  
  <p>I'd prefer not to have to set this up as an Entity class due to it being static data that won't change, but may have a new version in the future which would end up being another enum.</p>