Java Universal Network/Graph Framework / Bugs / #196 NullPointerException with RadialTreeLayout

Joshua O'Madadhain - 2013-12-12

What version of JUNG are you using? This sounds a lot like this bug, which we fixed a while back: http://sourceforge.net/p/jung/bugs/129/

It would also help if you could construct a small self-contained example that demonstrates the problem.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Craig Garrett - 2013-12-13

I'm using 2.0.1. Please let me know if there is a later version I should use. If not, I'll try to make a sample program that reproduces the issue.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Tom Nelson - 2013-12-13

It appears that you have a graph vertex that the Layout has no location information for. Did you add a new vertex before this happened? What is the type you are using for your vertices? If it is a custom type, did you implement hashCode and equals?
Tom

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

I have the same issue, when inserting a node into RadialTreeLayout:

:::java
...
16:19:03,0110 [DEBUG] de.iisys.oom.view.graph.GraphPanel.insertNodeWithExternalLocation(GraphPanel.java:222) transformedP = Point2D.Float[233.0, 212.0]  
16:19:04,0532 [ERROR] de.iisys.oom.view.dialog.DialogManager.showErrorMessage(DialogManager.java:84) cannot execute: Insert node: {unknown:O}  
java.lang.NullPointerException
    at edu.uci.ics.jung.algorithms.layout.PolarPoint.polarToCartesian(PolarPoint.java:65)
    at edu.uci.ics.jung.algorithms.layout.RadialTreeLayout.transform(RadialTreeLayout.java:95)
    at edu.uci.ics.jung.algorithms.layout.RadialTreeLayout.transform(RadialTreeLayout.java:25)
    at org.apache.commons.collections15.functors.ChainedTransformer.transform(ChainedTransformer.java:127)
    at org.apache.commons.collections15.map.LazyMap.get(LazyMap.java:158)
    at edu.uci.ics.jung.algorithms.layout.AbstractLayout.getCoordinates(AbstractLayout.java:170)
    at edu.uci.ics.jung.algorithms.layout.AbstractLayout.setLocation(AbstractLayout.java:227)
    at edu.uci.ics.jung.algorithms.layout.LayoutDecorator.setLocation(LayoutDecorator.java:84)
    at edu.uci.ics.jung.visualization.layout.ObservableCachingLayout.setLocation(ObservableCachingLayout.java:92)
    at de.iisys.oom.view.graph.GraphPanel.insertNodeWithExternalLocation(GraphPanel.java:223)
    ...

Here is my method call:

:::java
public void insertNodeWithExternalLocation(Node newNode, Point2D insertPoint) {
    final Layout<Node, Relationship> graphLayout = graphViewer.getGraphLayout();
    Graph<Node, Relationship> graph = graphLayout.getGraph();
    if (graph.containsVertex(newNode)) {
        return;
    }
    if (insertPoint != null) {
        Point2D transformedP;
        transformedP =     graphViewer.getRenderContext().getMultiLayerTransformer().inverseTransform(insertPoint);
        org.slf4j.LoggerFactory.getLogger(GraphPanel.class).debug("transformedP = " + transformedP);
        // next call crashes:
        graphLayout.setLocation(newNode, transformedP);
    }
    graph.addVertex(newNode);
    finalizeInsertedNode(newNode);
}

In this case the RadialTreeLayout is wrapped inside a StaticLayout, since I have to derive it from a DirectedGraph.
I also use this for TreeLayout, where the insertion code works.

I guess that RadialTreeLayout#transform(V) is called before or instead of #setLocation(V,Point) and tries to get the location from newNode (which is not mapped inside the layout at that time)

Aaron Eng - 2016-07-20

I ran into very similar stack traces using RadialTreeLayout. In my case, it happened to be that the edges/vertices in my graph did not connect. E.g. I had vertex 1, 2, 3, 4, and edges 1->2 and 3->4. With this set of graph components, the radial treee layout doesn't traverse through one of the sets of vertices/edges and hence does not set positions for them, which means when attempting to convert the polar point to cartesion, you hit NPE. It's easy to miss from the stack traces that the polarToCartesian method is static, and hence it's not a problem in the polarToCartesian class but rather in the calling class providing null input values.

It would be nice to have an alternate way for this to fail, with a reasonable message instead of a messageless NPE, but it seems non-trivial to examine all edges/vertices and determine they do not form a continguous graph.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Aaron Eng - 2016-07-20
  
  Actually, I don't think I'm describing the right scenario. I was fixing a bunch of bugs in an app that uses jung and now think it was actually a different behavior I was working on when I observed these NPEs. Sorry, I should have taken better notes. Unfortunately, I also don't intend to start from the original app code and go through the changes one by one to see where this came up. So, sorry, not useful comment here.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Joshua O'Madadhain - 2016-07-20

Aaron, if this is still happening in JUNG 2.1, please file a bug on JUNG's new home on GitHub at http://github.com/jrtom/jung.

If it's still happening, I agree that it would be good to have a more informative error message.

FWIW, if you want to establish that a graph has only a single (weakly connected, i.e., ignoring edge direction if any) component, you can use WeakComponentClusterer for that. (It's not something that we would use as a preprocessing step for the layout algorithm, though.)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

NullPointerException with RadialTreeLayout

Java graph/network library

Group

Searches

Help

#196 NullPointerException with RadialTreeLayout

Discussion