Enums with constant-specific method implementation

Question

Just faced the following problem. I have a persistent class with one of the fields of it is enum with constant-specific method implementation:
@Persistent
public class Message
   static public enum Type
       DEFAULT
           @Override
           public String getDescription() { return "Some description"; }
       public abstract String getDescription();
   private Type type;
}When I try to store the record, I get the exception:
java.lang.IllegalArgumentException: Class could not be loaded or is not persistent: messages.Message$Type$1The problem seem to be in that compiler creates a separate class, namely Message$Type$1.class for the DEFAULT instance and this class is not known by BDB..
If I remove the constant-specific method from enum, everything's working fine (as the ..$1.class is not created by compiler).. Except the fact that I'd like to have constant-specific methods there..
Any ideas on this? Maybe it's a bad idea to create constant-specific methods if it means that each constant would get own class file (and they would bloat the storage routines)?

Answer 1

Hi Mikhail,
I recreated the problem here and you're right, constant-specific methods aren't working. This isn't something we thought about, to be honest, or tested.
Just based on an initial quick look I see that for the compiler generated class, the Class.isEnum method returns false, which is why we don't recognize this as an enum and eventually why we throw the exception you're seeing. But assuming that we can identify the class as an enum (that shouldn't be too difficult) I don't know what other problems we will run into in trying to support this.
For now I think the best thing is to avoid using the constant-specific methods. I have opened a ticket (#18357) so that we'll remember to look into this in more detail and see whether it can be supported in the future.
If we are able to support it, then I'm hoping that we won't to store extra metadata for constants that have methods. In other words, I'm hoping that we won't have to add any extra storage or processing overhead.
--mark