LouisLou2 opened a new issue, #2097: URL: https://github.com/apache/fury/issues/2097
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/fury/issues) and found no similar issues. ### Version fury 0.10.0 ### Component(s) Java ### Minimal reproduce step 1. Create a class Lucy with final modifier, containing an Integer and an int. 2. Create another class Sam containing a List<Lucy>. 3. Serialize an instance of Sam using Apache Fury. 4. Attempt to deserialize the byte array back to an object. ```java import org.apache.fury.Fury; import org.apache.fury.Language; import java.util.ArrayList; import java.util.List; public class Main { final public static class Lucy { Integer i; int j; Lucy(Integer i, int j) { this.i = i; this.j = j; } } public static class Sam { List<Lucy> a = new ArrayList<>(); Sam() { this.a.add(new Lucy(1, 2)); this.a.add(new Lucy(3, 4)); } } public static void main(String[] args) { Sam sam = new Sam(); Fury fury = Fury.builder() .withLanguage(Language.XLANG) .withRefTracking(true) .ignoreBasicTypesRef(true) .ignoreTimeRef(true) .ignoreStringRef(false) .build(); fury.register(Lucy.class, "Lucy1"); fury.register(Sam.class, "Sam1"); byte[] bytes = fury.serialize(sam); Object it = fury.deserialize(bytes); System.out.println(it); } } ``` ### What did you expect to see? I expected the object to be deserialized successfully without any exceptions. ### What did you see instead? I encountered the following exception during deserialization: ```bash Exception in thread "main" org.apache.fury.exception.InsecureException: class org.apache.fury.Main$Lucy is not registered, please check whether it's the type you want to serialize or a **vulnerability**. If safe, you should invoke `Fury#register` to register class, which will have better performance by skipping classname serialization. If your env is 100% secure, you can also avoid this exception by disabling class registration check using `FuryBuilder#requireClassRegistration(false)` at org.apache.fury.resolver.ClassResolver.createSerializer(ClassResolver.java:1235) at org.apache.fury.resolver.ClassResolver.getOrUpdateClassInfo(ClassResolver.java:1197) at org.apache.fury.resolver.ClassResolver.getSerializer(ClassResolver.java:806) at org.apache.fury.type.GenericType.getSerializer(GenericType.java:187) at org.apache.fury.serializer.collection.AbstractCollectionSerializer.xwriteElements(AbstractCollectionSerializer.java:461) at org.apache.fury.serializer.collection.AbstractCollectionSerializer.xwrite(AbstractCollectionSerializer.java:450) at org.apache.fury.Fury.xwriteRef(Fury.java:561) at org.apache.fury.serializer.StructSerializer.xwrite(StructSerializer.java:158) at org.apache.fury.Fury.xwriteRef(Fury.java:551) at org.apache.fury.Fury.serialize(Fury.java:325) at org.apache.fury.Fury.serialize(Fury.java:276) at org.apache.fury.Main.main(Main.java:357) ``` However, when I removed the final modifier from the `Lucy` class, the error disappeared. Upon reviewing the code, I found that in the `AbstractCollectionSerializer::xwriteElements` method, the check for `elemGenericType.isMonomorphic()` leads to this issue. The fury considers final classes as Monomorphic, which causes it to execute Serializer `elemSerializer = elemGenericType.getSerializer(fury.getClassResolver());`. However, `fury.getClassResolver()` cannot find the information for the Lucy class because, in XLANG mode, registered classes are located in `XtypeResolver`, not `ClassResolver`. This results in Fury believing that `Lucy` has not been registered, leading to the exception. ### Anything Else? Additionally, I have some thoughts about the use of isMonomorphic() and the assumptions surrounding the final keyword. It seems that determining if a class is monomorphic based solely on it being final can be somewhat problematic, especially in communication between two systems. For instance, just because a class is marked as final on one end, it may not hold true on the other. Considering that final implies the class won't be subclassed, Fury might decide to skip writing out the MetaString that identifies the specific class. However, there might be cases where systems have classes with identical fields but differing in their finality or inheritance structures. Take, for example, a situation where class A is final on one end, and thus it chooses not to serialize the MetaString. On the receiving end, there's a class B with the same fields as A, but it isn't final. Here, Fury would typically expect to read a MetaString first before resolving the class. This discrepancy could potentially lead to inconsistencies if one system assumes a class is non-inheritable due to its final designation, while the other anticipates normal class inheritance and serialization strategies. Thus, relying on the final status of a class to manage serialization behaviors may create issues when there's no guaranteed consistency in how classes are structured or expected on both communicating ends. ### 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]
