Jackson optimize JSON readability

[glad wolf]

For some background info, I'm working of a Library of interfaces/classes and algorithms related to Graph Theory.

I'd like to know if anyone has ideas on how to make the JSON produced by jackson of my graph interface to be more readable. The current setup has a map of node labels to adjacency lists as well as a List of nodes, containing their Type and properties (currently just a label for the default impl).

I've provided a reference of how one such json looks, what the graph its representing is and the Wrapper I'm using to configure my ObjectMapper.

If you have any suggestions on how I can make the produced json more readable, I'd love to hear them.

[versed scaffold]

<@&987246399047479336> please have a look, thanks.

[stiff bough]

Why do you have class names in the json ???
And you could convert the graph into latex graph

[glad wolf]

Since Graphs can have different Types of nodes and edges inside, it's impossible to know the node type just off of the properties. Additionally, since the library interfaces and classes are designed to be extended, I need to support custom implementations so telling jackson what class to create for each element of the graph is neccessary (as far as I'm aware).

Although I don't know much about LaTeX from what I can gather it doesn't seem like it would very effectively store custom properties nodes and edges may have

[stiff bough]

You can't have infinite extendability and at the same time all the other things you want

[glad wolf]

I'm not sure what you mean by all the other things

I'm just wondering if there's a way to compress this, even a little

[stiff bough]

Also your json is bad because it contains implementations, even if you use class names, you should never use implementations

[stiff bough]

like readability

or black magic

[glad wolf]

how would I make the Type Serializer not include the implementations and still know how to construct the objects?

[stiff bough]

You can't

that's the problem

you need to code this yourself

so try to code your program in a smarter way

[glad wolf]

how would you do it?

[stiff bough]

Also note that allowing any class to be used means that you can't run it unless you have those classes, which could cause a lot of problems

[glad wolf]

why would you want to import a graph that uses classes you don't have

that's perfectly fine

[stiff bough]

There are two ways

• either simply don't allow to extend it
• or code an api to extend it on purpose

[stiff bough]

what if you export it, then give it to a person who doesn't have the exact same addons as you?

[glad wolf]

that defeats my vision, which is allow users to extend the interfaces to meet their specific needs

such as creating a user Node with information about users

or any other implementation they might need

[glad wolf]

sure, but if people are using their own implementations with information specific to their project, they won't be an issue

because the information won't be useful without the classes anyways

[stiff bough]

Although I don't know much about LaTeX from what I can gather it doesn't seem like it would very effectively store custom properties nodes and edges may have
Although Latex is more limited than doing whatever you want, it's a language than many people know and so people could get the exported file and read it without any tutorial and without imporing it

[glad wolf]

I agree it would be a good idea to have a function to convert to LaTeX, but my goal here is to have the default json writer be lossless

[stiff bough]

You have to search what possibly could someone add to my lib
And then give official support to all of that

And if someone wants some hyper specific stuff, then they might as well fork your lib

And remember that you can't code something that could be extended in any ways
There are always limits, and so you need to set them correctly and code with that in mind

You can't just say "I'll allow anything"

[glad wolf]

Or I could make my interfaces & algorithms work with multiple implementations, and if the user needs something else they can make it

[glad wolf]

the goal is to add the foundation to make it as easy to add their own stuff as possible. So forking the library is fine

[glad wolf]

there are limits

however that doesn't mean I should focus my efforts on creating every conceivable implementation imaginable

I should work to let users fit the library to their needs

[stiff bough]

Then you don't need to prepare for anything
Like, why would you display in the json, the graph class?

[glad wolf]

that's true, I can probably remove that

that information is given when you read it in

[stiff bough]

First please define what could possibly be in the graph

[glad wolf]

nodes and edges with their own properties

[stiff bough]

if you manage to find everything, then none of the classes need to be displayed

[glad wolf]

there are countless uses for graphs. I'm not going to spend my time implementing every single one

[stiff bough]

Use yes, but we are not talking about use, we are talking at which information could you put in a graph

[glad wolf]

Pretty much just properties and functions related to their implementation

[stiff bough]

Which are?

[glad wolf]

well I suppose nodes are just objects that can be stored in a graph

[stiff bough]

• Nodes
• Edges
  That's kinda all

[glad wolf]

for a map software, the nodes would have the address, information about the location, and information to assist in finding routes such as average wait times for intersections.

Edges are much the same just representing roads, information such as road names, average time to pass, speed limits, safety, etc. as well as information to assist in finding routes

[stiff bough]

Edges may have information about their nodes, one or several labels + positions (start, end middle) + angle, id, stroke color, stroke width, direction or none, and then data
Nodes may have one or several labels + positions (center, outside from an angle) + angle, id, radius, stroke color, stroke width background color, and then data

[stiff bough]

All of them are data not related to graphes, then could be put in a separated field

[glad wolf]

You're right, they could simply contain a reference to another object

[tawdry grove]

{ 
  "nodes": {
    "id1": {
       "type": "...",
       "prop": 123
    }
  },
  "edges": {
    "id1": [{"to": "id2", "attr": "..."}],
    "id2": [{"to": "id3"}, {"to": "id1"}]
  }
}

something like this

and you pick a deserializer from "type"

[stiff bough]

class Node<N> {
  ...
  private N data
}
class Edge<E> {
  ...
  private E data
}
class Graph<N, E> {
  private List<Node<E>> edges;
  private List<Edge<N>> nodes;
  ...
}

then create your own data class

Like RoadData

[tawdry grove]

or use a Guava graph tbh

[glad wolf]

yeah that would work

[tawdry grove]

<dependency>
    <groupId>dev.mccue</groupId>
    <artifactId>guava-graph</artifactId>
    <version>33.2.0</version>
</dependency>

[stiff bough]

so then you handle everything about graphes only

[glad wolf]

the purpose of this is to learn about the different parts of graph theory. I'm aware there are more practical libraries

[tawdry grove]

oh okay

[stiff bough]

and then, the data is user specific, and you can easily transform it into json as long as the user create a method to jsonify it tho you will need classes in the json but only for data

and what if you want no data?

Just use Void type

You could even make a class for this

[glad wolf]

yeah that makes perfect sense

[stiff bough]

Graph<Void, Void> graph = new Graph<>();
// Or for easier use
class SimpleGraph extends Graph<Void, Void>(){}
SimpleGraph graph = new SimpleGraph();

[glad wolf]

yeah, that makes a lot more sense than what I was doing. Thanks a lot

also how do I close this question?

[versed scaffold]

Closed the thread.

[glad wolf]

ah there

[stiff bough]

You reopened it 🙂

[glad wolf]

💀

now I have to wait 2 minutes