[Java] Registration order dependency for nested enum fields causes ClassUnregisteredException

[LouisLou2]

Search before asking

• I had searched in the issues and found no similar issues.

Version

0.10.0

Component(s)

Java

Minimal reproduce step

package org.apache.fury;

import org.apache.fury.config.Language;

public class Main1 {

  enum Kind {
    X,
    Y,
    Z
  }

  public static class SomeClass {
    private Kind kind;
  }

  public static void main(String[] args) {
    Fury fury = Fury.builder().withLanguage(Language.XLANG)
      .withRefTracking(true)
      .ignoreBasicTypesRef(true)
      .ignoreTimeRef(true)
      .ignoreStringRef(false)
      .build();

    fury.register(SomeClass.class,"MyTypeResolver");
    fury.register(Kind.class,"MyKind");

    SomeClass someClass = new SomeClass();
    byte[] bytes = fury.serialize(someClass);
    Object obj = fury.deserialize(bytes);
    System.out.println(obj);
  }
}

Running this code results in a ClassUnregisteredException. However, if we simply swap the registration order (register Kind.class before SomeClass.class), the code works fine.

What did you expect to see?

I expect to be able to register classes in any order before starting actual serialization/deserialization operations. The registration phase should not require a specific dependency order, especially for nested types like enums within classes. This would make the library more user-friendly, especially when working with complex class hierarchies with many interdependencies.

What did you see instead?

An exception is thrown complaining that the enum class is not registered, even though it is registered right after the class that uses it:

Exception in thread "main" org.apache.fury.exception.ClassUnregisteredException: Class org.apache.fury.Main1$Kind is not registered
  at org.apache.fury.resolver.XtypeResolver.buildClassInfo(XtypeResolver.java:301)
  at org.apache.fury.resolver.XtypeResolver.getClassInfo(XtypeResolver.java:262)
  at org.apache.fury.serializer.StructSerializer.getGenericType(StructSerializer.java:104)
  at org.apache.fury.serializer.StructSerializer.lambda$buildFieldGenerics$2(StructSerializer.java:94)
  [stack trace truncated]

Anything Else?

After step-by-step debugging, I have traced the exact cause of the issue:

1. When registering SomeClass, the code flow enters XtypeResolver.register(Class<?> type, Serializer<?> serializer, String namespace, String typeName, int xtypeId) around line 201.

2. In this method, since SomeClass is not an enum, it executes:

   classInfo.serializer = new StructSerializer(fury, type);

3. Inside StructSerializer constructor, it calls:

   fieldGenerics = buildFieldGenerics(fury, TypeRef.of(cls), fieldAccessors);

4. This method attempts to build generic type information for each field in the class, including the kind field which is of type Kind (enum).

5. For each field, it calls getGenericType(Fury fury, TypeRef<T> type, FieldAccessor fieldAccessor) which contains:

   if (resolver.isMonomorphic(cls)) {
     t.setSerializer(fury.getXtypeResolver().getClassInfo(cls).getSerializer());
     return t;
   }

6. When processing the kind field, cls becomes Kind enum, which is detected as monomorphic.

7. This leads to calling fury.getXtypeResolver().getClassInfo(cls) for the Kind class:

   public ClassInfo getClassInfo(Class<?> cls) {
     ClassInfo classInfo = classInfoMap.get(cls);
     if (classInfo == null) {
       classInfo = buildClassInfo(cls);
     }
     return classInfo;
   }

8. Since Kind is not yet registered (we register it after SomeClass), classInfo is null, and it calls buildClassInfo(cls).

9. Inside buildClassInfo(cls) around line 301, it checks if the enum is an inner enum of another enum, and since it's not, it throws:

   Class<Enum> enclosingClass = (Class<Enum>) cls.getEnclosingClass();
   if (enclosingClass != null && enclosingClass.isEnum()) {
     serializer = new EnumSerializer(fury, (Class<Enum>) cls);
     xtypeId = getClassInfo(enclosingClass).xtypeId;
   } else {
     throw new ClassUnregisteredException(cls);
   }

10. If we reverse the registration order (register Kind first, then SomeClass), the error disappears because getClassInfo(cls) can find the already registered Kind class in classInfoMap.

The issue is that the library eagerly analyzes fields during class registration, rather than deferring this analysis until serialization actually begins. This creates an implicit requirement to register types in dependency order, which becomes problematic with complex class hierarchies.

Are you willing to submit a PR?

• I'm willing to submit a PR!

[chaokunyang]

This is indeed an issue, we create serializer lazily in java serialization mode, but create serializer eager in xlang mode. We need to make the serializer creation lazily for xlang mode too