Custom transformer - create_instance invoked incorrectly? #54

Activity

1. tcalmant commented on Apr 7, 2024

   

   tcalmant

   on Apr 7, 2024

   Owner

   More actions

   Hi
   Sorry for the long delay, I seem to have missed the notifications for this project.

   Regarding your issue: the transformers given to javaobj.v2.load are supposed be instances, not classes.
   As a result, you should call obj = javaobj.load(inp, odrnavsTransformer()) instead of obj = javaobj.load(inp, odrnavsTransformer).
2. UnitedMarsupials commented on Oct 15, 2024

   

   UnitedMarsupials

   on Oct 15, 2024

   Last edited by UnitedMarsupials

   Author

   More actions

   Thank you, that seems to work now, but I'm still not getting much useful from the file I'm trying to decode. It seems to contain java.util.ArrayList with several dozens entries of the same vendor-specific items in it: vendor.apps.datalayer.client.navs.shared.api.Function.

   Do I need to know the fields of that vendor's class -- and put that knowledge into my Python script as the example in README.md is doing -- or would javaobj do that for me automatically? At least, for the fields of known Java-types?

   My goal is to be able to turn the binary Java-serialization data into a human-readable text -- ideally, in JSON-format -- and back.
3. tcalmant commented on Aug 12, 2026

   

   tcalmant

   on Aug 12, 2026

   Owner

   More actions

   On the original report: transformers are expected as instances, and passing
   the class gave a confusing error from inside the parser. #71 makes v2 and v3
   say what is wrong instead:

   TypeError: Transformers must be given as instances, not as classes:
   got the class MyTransformer, did you mean MyTransformer() ?
   

   On your follow-up question, whether javaobj can turn a vendor class into
   readable JSON without writing a transformer: partly, and it is worth knowing
   where the limit is.

   Everything a class writes through the default mechanism is recovered without
   any transformer: the declared fields, of every class of the hierarchy, and
   the collections, which are already converted to list / dict. You only
   need a transformer when a class defines its own writeObject(), because what
   it wrote is then opaque bytes whose layout only that Java class knows. No
   library can guess that from the stream alone.

   So a generic dump gets you quite far. With v3:

   import json
   import javaobj.v3 as javaobj
   from javaobj.v3.beans import JavaInstance, JavaArray, JavaEnum
   
   def to_python(obj):
       # Collections first: the transformed ones are dict/list *and* JavaInstance
       if isinstance(obj, dict):
           return {str(to_python(k)): to_python(v) for k, v in obj.items()}
       if isinstance(obj, (list, JavaArray)):
           return [to_python(o) for o in obj]
       if isinstance(obj, JavaEnum):
           return obj.constant
       if isinstance(obj, JavaInstance):
           out = {"__class__": obj.classdesc.name}
           for fields in obj.field_data.values():
               for field, value in fields.items():
                   out[field.name] = to_python(value)
           return out
       if isinstance(obj, bytes):
           return list(obj)
       return obj
   
   with open("dump.ser", "rb") as fd:
       print(json.dumps(to_python(javaobj.load(fd)), indent=2, default=str))

   On an ArrayList of vendor objects this gives you the list, and for each
   element its class name and its fields, the inherited ones included. If some
   field comes back empty, that class writes it in a custom writeObject() and
   that one needs a transformer.

   Going back to Java from that JSON is another matter: v3 can write streams,
   but rebuilding a class which has a custom writeObject() means reproducing
   its format by hand.
4. tcalmant

   closed this as completedin #71on Aug 12, 2026