As soon as I saw this I just needed to look up the bytecode as I couldn't imagine what this should be translated to. While I believe "it" is a bug, I will show you what I found out so far.
For CHECKED there is actually created its own subclass, i.e. public final class GWGStatus$CHECKED extends GWGStatus even though GWGStatus is an enum itself. Probably again something that is allowed in the JVM bytecode, but isn't allowed in the Java language specification.
Now comes the not-so-congruent part. While the following works in Java:
GWGStatus.CHECKED status = (GWGStatus.CHECKED) GWGStatus.CHECKED;
status.auditDate = new Date();
System.out.println(status.auditor());
and prints Peter as expected, the cast isn't possible in Kotlin (yet?):
GWGStatus.CHECKED as GWGStatus.CHECKED // fails: Use of enum entry names as types is not allowed, use enum type instead
Now using java reflection utilities in Kotlin (e.g. status::class.java.declaredFields or .java.declaredMethods) both auditor() and getAuditDate() (etc.) are visible and accessible (as was already proven by the Java code itself). Analysing further and just using Kotlin reflection instead:
GWGStatus.UNCHECKED::class // returns class GWGStatus
GWGStatus.CHECKED::class // return class GWGStatus$CHECKED ... that's good so far
GWGStatus.CHECKED::class.declaredMembers // empty list ... didn't expect this one
// empty too: GWGStatus.CHECKED::class.declaredMemberProperties
// and GWGStatus.CHECKED::class.declaredFunctions
GWGStatus.CHECKED::class.superTypes // shows GWGStatus as expected
GWGStatus.CHECKED::class.members // shows clone(), finalize(), name, equals, hashcode, tostring, getdeclaringclass, ordinal... nothing we are interested in and rather the ~general enum members
GWGStatus::class.nestedClasses // empty too
Ok... we can't see them using Kotlin reflection (or maybe I did not use the right approach? ;-)). So: something smells like a bug here, but I am not sure yet what the bug is:
- is it that there should not have been created a subclass in the first place?
- is it that the subclass should be accessible and visible in Kotlin itself?
- is it that the Kotlin compiler should have complained about this as this is not a finished feature yet?
- is in fact the error message wrong and it should just have allowed the cast?
- something else?