sjahedhussini commented on issue #2941:
URL: https://github.com/apache/fory/issues/2941#issuecomment-4756515059
Hello @chaokunyang! After reproducing the error, I traced the error to the
method `ClassResolver.getSerializerClass(Class<?>, boolean)` and
```
if (config.checkJdkClassSerializable()) {
if (cls.getName().startsWith("java") &&
!(Serializable.class.isAssignableFrom(cls))) {
throw new UnsupportedOperationException(
String.format("Class %s doesn't support serialization.", cls));
}
}
```. The following code/test produces it:
```
Fory fory = Fory.builder()
.withLanguage(Language.JAVA)
.requireClassRegistration(false)
.build();
fory.copy(String.class.getPackage()); // throws
```
In order to solve this, my thinking is to let copy bypass this guard without
weakening serialize. As in, route these classes to a serializer whose
write/read still throw but whose copy works, similar to how
`ForyCopyableSerializer` already gives copy distinct behavior. Before I
implement, I wanted to check the design direction, since I saw the earlier
discussion about transient fields vs. returning the original reference:
For opaque JVM-managed classes like `java.lang.Package`, would you prefer
`copy()` attempt a field-based copy, or return the original reference? And does
this bypass guard for copy approach sound right to you, or would you rather the
fix be implemented somewhere else? Thank you, I just want to head in the right
direction before opening 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]
