Ways to persist Guava Graph
graph, guava, java
Solution
To briefly recap the reason why Guava's `common.graph` classes aren't `Serializable`: Java serialization is fragile because it depends on the details of the implementation, and that can change at any time, so we don't support it for the graph types.
In the short term, your proposed workaround is probably your best bet, although you'll need to be careful to store the endpoints (source and target) of the edges alongside the edge objects so that you'll be able to rebuild the graph as you describe. And in fact this may work for you in the longer term, too, if you've got a database that you're happy with and you don't need to worry about interoperation with anyone else.
As I mentioned in that GitHub issue, another option is to persist your graph to some kind of file format. (Guava itself does not provide a mechanism for doing this, but JUNG will for `common.graph` graphs once I can get 3.0 out the door, which I'm still working on.) Note that most graph file formats (at least the ones I'm familiar with) have fairly limited support for storing node and edge metadata, so you might want your own file format (say, something based on protocol buffers).
Problem
I'm using the `common.graph` from Google Guava in Version 21.0. It suits very well to my usecase without one aspect: Persistence. The graph seems to be in-memory only. The graph-classes does not implement `Serializable`, it was explained in this issue posts. Google describes three models to store the topology. The third option is: a separate data repository (for example, a database) stores the topology But that's all. I didn't found any methods in the package to apply a separate data repository. Is there any way to do this? Or is the only way to use the `nodes()`and `edges()` method to get a `Set` of my nodes and a `Set` of my edges? I can persist them in a database if I implement `Serializable` in this classes and restore the graph by calling `addNode(Node)` and `addEdge(Source, Target, Edge)` (there are no addAll-methods). But this seems to be a workaround. Thanks for your support!