Joshua O'Madadhain

The Dijkstra* classes keep track of distances using a Map objects rather than using primitive doubles, which adds overhead. The question of whether `CompactHashSet` is worth it has been the...

We haven't yet sorted that out, no (and that's on me, and it's blocked behind a few other common.graph-related things, I'm afraid). That said, even if we change the API,...

These are good questions. :) For `BasicMapEntry`, I think that the appropriate answer is to get rid of that class entirely. Options for doing so include (a) using Maps.immutableEntry(), (b)...

No. The JavaFX-related code was an experiment, which we decided not to follow up on. The current version of JUNG does not include any JavaFX-related code, and I don't anticipate...

@aalmiray We're not necessarily opposed in principle to introducing an abstraction layer, but that's another thing we've experimented with a while back (at that time, several years ago, it was...

`common.graph.Network` might also be appropriate if your `V` values are unique and capable of acting as a key to their "endpoints" (aka row and column specifiers).

It's not the only metric, but it's an important one. Utility is the other primary consideration, and obviously the difficulty of implementing a correct solution is an aspect of that.

Just to add another possibly-complicating factor, at least some of the Table uses inside Google may become Graphs/ValueGraphs/Networks now that common.graph is available and becoming more mainstream. (One of the...

FWIW, `ValueGraph` has two existing methods that (as far as I can tell) supports the requested need on the read side: ``` Optional edgeValue(N nodeU, N nodeV); // use with...

We could certainly key this to whether the original graph permits self-loops; that's easy. The question of correctness is a bit tricky, though. Transitive closure is determined in terms of...