LouisLou2 opened a new issue, #2103: URL: https://github.com/apache/fury/issues/2103
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/fury/issues) and found no similar issues. ### Version 0.10.0 ### Component(s) Java ### Minimal reproduce step ```java 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: ```java classInfo.serializer = new StructSerializer(fury, type); ``` 3. Inside `StructSerializer` constructor, it calls: ```java 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: ```java 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: ```java 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: ```java 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? - [x] I'm willing to submit a PR! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
