[Java] support copy non-serializable objects such as java.lang.Package #2941

Activity

1. thmd

   added

   bugSomething isn't workingSomething isn't working

   on Nov 27, 2025
2. chaokunyang commented on Nov 27, 2025

   

   chaokunyang

   on Nov 27, 2025

   Collaborator

   More actions

   @thmd could you provide a reproduction example?
3. chaokunyang commented on Nov 27, 2025

   

   chaokunyang

   on Nov 27, 2025

   Collaborator

   More actions

   It seems you are copy a java.lang.Package object, which is not serializable. I think we can just skip copy for such objects instead of raise errors
4. chaokunyang

   changed the title [-]Fory copy fails while deepCopy works[/-] [+]Fory copy fails for non-serializable java.lang.Package object[/+] on Nov 27, 2025
5. thmd commented on Nov 27, 2025

   

   thmd

   on Nov 27, 2025

   Author

   More actions

   I think this reproduces the issue.
   fory-hibernate-test.zip
6. thmd commented on Nov 27, 2025

   

   thmd

   on Nov 27, 2025 via email

   Last edited by thmd

   Author

   More actions

   The big thing is the difference between copy and serialize/deserialize pair. Should they behave identically? Also native java serialization doesn’t give error here. Following what java native does seems like a good idea.

   …

   On Thu, 27 Nov, 2025 at 8:39 PM, Shawn Yang ***@***.***> wrote: *chaokunyang* left a comment (apache/fory#2941) <#2941 (comment)> It seems you are copy a java.lang.Package object, which is not serializable. I think we can just skip copy for such objects instead of raise errors — Reply to this email directly, view it on GitHub <#2941 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVESIZ7N3XPIGA55XNUCCL364EINAVCNFSM6AAAAACNLRFE2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKOBWGIYTMNZSGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>
7. chaokunyang commented on Dec 8, 2025

   

   chaokunyang

   on Dec 8, 2025

   Last edited by chaokunyang

   Collaborator

   More actions

   I have no plans to introduce another type dispatch mechnisim for copy, it will use same Serializer dispatch system

   We could defer the exception to runtime. Instead of raise exception when get serializer, we could return a Serializer for any types. But for types which don't support serialization, we throw exception real serialization happens.
8. chaokunyang

   added

   good first issueGood for newcomersGood for newcomers

   on Dec 8, 2025
9. chaokunyang commented on Dec 8, 2025

   

   chaokunyang

   on Dec 8, 2025

   Collaborator

   More actions

   For any unserializable objects, the copy should just return original obejct
10. chaokunyang

    changed the title [-]Fory copy fails for non-serializable java.lang.Package object[/-] [+][Java] support copy non-serializable objects such as java.lang.Package[/+] on Dec 8, 2025
11. thmd commented on Dec 14, 2025

    

    thmd

    on Dec 14, 2025

    Author

    More actions

    I have no plans to introduce another type dispatch mechnisim for copy, it will use same Serializer dispatch system

    We could defer the exception to runtime. Instead of raise exception when get serializer, we could return a Serializer for any types. But for types which don't support serialization, we throw exception real serialization happens.

    I don't understand about Fory enough to tell what is meant by dispatch here. My big question if they are using similar/same code why is serialize succeed when copy fails? Does that have anything to do with transient fields? Does copy copies transient fields?

    I think I can more meaningfully comment based on my use cases if I understand the difference between copy and serializae and why one succeed and one don't.
12. jim-parsons commented on Dec 14, 2025

    

    jim-parsons

    on Dec 14, 2025

    Last edited by jim-parsons

    Contributor

    More actions

    I have no plans to introduce another type dispatch mechnisim for copy, it will use same Serializer dispatch system
    We could defer the exception to runtime. Instead of raise exception when get serializer, we could return a Serializer for any types. But for types which don't support serialization, we throw exception real serialization happens.

    I don't understand about Fory enough to tell what is meant by dispatch here. My big question if they are using similar/same code why is serialize succeed when copy fails? Does that have anything to do with transient fields? Does copy copies transient fields?

    I think I can more meaningfully comment based on my use cases if I understand the difference between copy and serializae and why one succeed and one don't.

    After some debug work, here is what i've found;

    The serialize/deserialize function will ignore the transient field, but copy won't , because the copy function need to calculate all the field value , which currently depended on fory#serialize function.

    So in this case, when copy filed protected transient FastSessionServices fastSessionServices; it failed, because it has unsupport serialize filed ClassLoader

    

    The serialize class wont handle transient field

    
13. chaokunyang commented on Dec 15, 2025

    

    chaokunyang

    on Dec 15, 2025

    Last edited by chaokunyang

    Collaborator

    More actions

    @jim-parsons @thmd How about checking whether transient fields are serializable in constructor of AbstractObjectSerializer, if not, we just copy transient fields by ref directly
14. thmd commented on Dec 15, 2025

    

    thmd

    on Dec 15, 2025

    Author

    More actions

    I feel that copy original ref when it's not mutable breaks the contract of DeepCopy which is what this is useful for. I almost want two flags for copy if possible.

    copyTransient - true/false
    copyOriginalRefIfNeeded - true/false
    
15. chaokunyang commented on Dec 15, 2025

    

    chaokunyang

    on Dec 15, 2025

    Collaborator

    More actions

    Transient fields always needs copy, some class use jdk writeObject/readObject to setup object invariant, Then set transient fields to correct values in those methods. If we don't copy transient fields, the copies object will be in wrong state.
16. chaokunyang commented on Dec 15, 2025

    

    chaokunyang

    on Dec 15, 2025

    Last edited by chaokunyang

    Collaborator

    More actions

    @thmd Or maybe we can just refine the error message, and let users to register a CopySerializer for unsupported classes directly. This is much easier. By default, CopySerializer just return original ref. And user can subclass it to customize the copy logic
17. thmd commented on Dec 15, 2025

    

    thmd

    on Dec 15, 2025

    Author

    More actions

    There are valid cases for both wanting to DeepCopy an Object with transient fields and without. A DeepCopy with transient field is obviously most complete state copy. But the truth is often (to my knowledge) transient is used to mark we don't care about like here Hibernate framework harness which is often not useful in a DeepCopy use case.

    DeepCopy objets are often used longterm e.g. in a cache which often makes transient references to ORM, Thread etc. invalid. Also most often DeepCopy is basically done using a serialize+deserialize pair which is what I was using before finding Fory.copy and such DeepCopy doesn't copy transient.

    Now there are other cases people do want transient fields where they need a library with Copy (which is rare) or do something manually. So I think it's worth having a Copy without transient option as it allow someone to safely migrate from a serialize+deserialize to Fory.copy for the added performance (both cpu + memory overhead) gains.

    I actually find returning original ref much more risky than skipping transient as DeepCopy is meant to give you an independent copy which original ref copy breaks and does so very silently.
18. chaokunyang commented on Dec 15, 2025

    

    chaokunyang

    on Dec 15, 2025

    Last edited by chaokunyang

    Collaborator

    More actions

    If we enforce users to register a Serializer for unsupported classes directly, users will be aware of t. So there is no risk.

    You can take HashMap as an example, it has size, modCount, table fields. They all are transient.

    If we skip transient fields, we are copying nothing and will get NPE instead.
19. thmd commented on Dec 15, 2025

    

    thmd

    on Dec 15, 2025

    Author

    More actions

    I actually wasn't aware that HashMap has such fields as transient. It seems like I can't use Fory.copy as a drop-in replacement for a DeepCopy need currently served by a serialize+deserialize and my use cases is better served by that. It would be less efficient than Fory.copy but still better than JDK serialization.

    HashMap could have made them regular (non-transient) field but still skip them in it's custom writeObject, which seems like a better design to me. Anyway it seems I know even lesser than what I thought about java serialization.
20. sjahedhussini commented on Jun 5, 2026

    

    sjahedhussini

    on Jun 5, 2026

    More actions

    Hi, I'm looking to make my first open source contribution, and this issue caught my attention. I'd like to take a stab at fixing it. From reading the stack trace and the discussion, it looks like the copy path is routing through the same serializer-lookup logic as serialize/deserialize, which hard-fails on non-serializable types like java.lang.Package. I'm thinking the fix lives somewhere in ClassResolver or AbstractObjectSerializer — would love any pointers from the maintainers on the preferred approach before I start. Happy to submit a PR.
21. sjahedhussini commented on Jun 20, 2026

    

    sjahedhussini

    on Jun 20, 2026

    Last edited by sjahedhussini

    More actions

    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.
22. itsCodeTide commented on Oct 14, 2026

    

    itsCodeTide

    on Oct 14, 2026

    More actions

    I’ve prepared an alternative fix in #4179 . It makes copy() return non-serializable JDK objects such as java.lang.Package by reference, while keeping serialization of those objects unsupported. This avoids trying to copy JVM-managed internals.
    The change adds direct and nested copy coverage, plus a check that serialization still fails. I also saw that PR #3797 is open for this issue; this PR takes a different approach.