jdereg / json-io

Convert Java to JSON. Convert JSON to Java. Pretty print JSON. Java JSON serializer. Deep copy Java object graphs.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Custom Writers not including id and ref in output?

williamclocksin opened this issue · comments

I have written custom writers for an object graph in which the same object appears more than once. However, the output JSON string contains all copies of the one object. Furthermore, the JSON string contains no @id or @ref that would be needed to identify objects and references to them when reading the string to a JSON Object. Looking at the directory of test files, I note in the method CustomWriterTest.testCustomPersonWriterReaderinCollectionTypes() there are comments to suggest this doesn't work for custom writers. Is this something that is awaiting a fix? Or do I need to do something in the custom writer to ensure that @id's and @ref's appear?

Looking into this.

Do you have a simple, repeatable test case that shows this? If so, please send it my way. Thank you.

Thank you for your reply. After realising that I would need to write a custom reader/writer for every class in my program, I decided that I needed a solution that fit my use case better: Where each subclass is responsible for reading/writing its own variables, and calling super to read/write the variables of superclasses. This is similar to the NextStep archiving model rather than a Java serialization model. So, I wrote from scratch an archiver that reads/writes JSON from a cyclic object graph. It works, and is not very much code. I use @id and @ref in the same way as json-io. It has a @Class specifier also, which is used to find the constructor. Like NextStep archiving, there is an 'awake' method (I call it 'activate'), which my JavaFX program uses to traverse the unarchived object graph to write the corresponding JavaFX nodes into the Scene graph. I would be happy to show you the code, but I don't want to put it on GitHub because it is not ready for an audience. The parser/generator does not use streaming I/o, so I would probably rewrite it to use streaming instead of keeping the token list and the generated string all in memory.