Ways to persist Guava Graph

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).

One way I found of storing the graph was through the DOT format, like so:

public class DOTWriter<INode, IEdge> {

    public static String write(final Graph graph) {
        StringBuilder sb = new StringBuilder();
        sb.append("strict digraph G {\n");

        for(INode n : graph.nodes()) {
            sb.append("  \"" + n.getId() + "\n");
        }

        for(IEdge e : graph.edges()) {
            sb.append("  \"" + e.getSource().getId() + "\" -> \"" + e.getTarget().getId() + "\" " + "\n");
        }

        sb.append("}");
        return sb.toString();
    }
}

This will produce something like

strict digraph G {
    node_A;
    node_B;
    node_A -> node_B;
}

It's very easy to read this and build the graph in memory again.

If your nodes are complex objects you should store them separately though.