Support for Java enums in Native Types

[dteleguin]

Imagine a class with an enum property:

public class Foo {

    private Bar bar;

    public Bar getBar() {
        return bar;
    }

    public void setBar(Bar bar) {
        this.bar = bar;
    }

}

public enum Bar {
    FOO,
    BAR
}

Registering such a class with Native Types results in an exception:

Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: java.lang.IllegalArgumentException: Unsupported type for property 'typeParameters' in class java.lang.Class
	at dev.cel.extensions.CelNativeTypesExtensions$NativeTypeScanner.validateRegisteredClasses(CelNativeTypesExtensions.java:236)
	at dev.cel.extensions.CelNativeTypesExtensions$NativeTypeScanner.scan(CelNativeTypesExtensions.java:221)
	at dev.cel.extensions.CelNativeTypesExtensions$NativeTypeScanner.access$000(CelNativeTypesExtensions.java:154)
	at dev.cel.extensions.CelNativeTypesExtensions.nativeTypes(CelNativeTypesExtensions.java:131)
	at dev.cel.extensions.CelExtensions.nativeTypes(CelExtensions.java:362)
	at CELTest.<clinit>(CELTest.java:40)
Caused by: java.lang.IllegalArgumentException: Unsupported interface type: java.lang.reflect.TypeVariable
	at dev.cel.extensions.CelNativeTypesExtensions$NativeTypeScanner.mapJavaTypeToCelType(CelNativeTypesExtensions.java:302)
	at dev.cel.extensions.CelNativeTypesExtensions$NativeTypeScanner.mapJavaTypeToCelType(CelNativeTypesExtensions.java:296)
	at dev.cel.extensions.CelNativeTypesExtensions$NativeTypeScanner.getPropertyType(CelNativeTypesExtensions.java:276)
	at dev.cel.extensions.CelNativeTypesExtensions$NativeTypeScanner.validateRegisteredClasses(CelNativeTypesExtensions.java:233)
	... 5 more

This happens because CEL tries to introspect the implicit declaringClass property of the Java enum (which resolves to java.lang.Class, which has an interface-typed property typeParameters, which is not supported because of #1061). Perhaps we need to blacklist the standard java.lang.Enum methods the same way we do for java.lang.Object.

[l46kok]

We'll safely exclude enums from the bindings for now and update the documentation accordingly. Supporting them properly requires a larger architectural decision on the underlying type i.e: ints for Protobuf parity (via ordinals or a custom interface) against exposing them as strings, which is more commonly seen in other Java serialization ecosystems.

[dteleguin]

I can confirm that with both #1078 and #1069 I have been able to bind JsonWebToken and evaluate expressions on it. Great job!

However, we should not underestimate the importance of Enums; in the said JsonWebToken, the category property is modeled as an enum, and I could imagine it being used inside a policy (e.g. to implement different rules for different token types).

Another prominent example in Keycloak is EventType. This one is also interesting because it assumes the possibility of numeric comparison between the enum members - this is how you can select entire event type category. (In EventType, there is a special stableIndex property for that, but I could imagine a case where plain ordinals might be used).

Therefore, I would suggest to model enums as ordinals (or at least to keep the ordinals internally to enable comparison).