called from ClusterSingleSignOn.register() method with authType parameter

passed as the ClusterSingleSignOn.registerLocal() method argument

obtained from the msg.getAuthType() expression in ClusterSingleSignOnListener.messageReceived() method

… and so on.

The more you expand the tree, the deeper you dig in the chain of assignments and method calls that all lead to our field in question.

Notice the nodes with gray background — they denote duplicates, that is, the usages that are already present in the tree in another location. This can occur, for example, when a value comes from a single source (e.g. returned by a function), but is assigned to a field in several different ways, e.g. initialization in a constructor and a setter method call.

Duplicate nodes are highlighted to help differentiate paths we already inspected from those we did not.

And here is where we get another question:

What are all possible values our field can have?

To help you with that, IntelliJ IDEA can analyze all the paths in data flow hierarchy and group them by value — just click Group by leaf value button:

This is what we have found in our example:

Now it’s obvious that values of the field authType come from String final fields declared in the Constants class. Plus, the field can have a null value with which it is initialized.

Of course, IntelliJ IDEA cannot always determine the actual values a field can have. When we try to find all originating values for the password field in the same class SingleSingnonMessage, we’ll get the following:

As you see, the possible values are:

null — initial value

session.getNote(Constants.SESS_PASSWORD_NOTE) — looks like password retrieved from the session and IntelliJ IDEA has no knowledge what it actually is.

And the final question we might be interested in: What are the places this expression can flow into?
For example, we might want to know whether this variable, holding huge amount of data will ever be stored as a field anywhere?

Or, if I passed null here, will I eventually get a NullPointException anywhere in my code?

This is where the Dataflow from this action from Analyze menu is helping us. Let’s try it on a method call:

We get a hierarchical view similar to what we seen before, but the values flow in the opposite direction, from the method parameter.

As we can see, null argument can potentially wind up in the place of context parameter in the ELResolver.message() method, where it will immediately be dereferenced, meaning that we just found a path that leads to a potential NullPointException. Though, I am pretty sure it will never occur in real world

15 Responses to Analyzing Dataflow with IntelliJ IDEA

This is one of the best features I’ve seen so far. This alone would justify IDEA’s price tag for any serious developer. Tracing dataflow is a tedious task that you need to perform often, particularly when working with third party code — and when you’re working with a large team, all code is potentially third party (as in, not yours).

Great work, guys. I hope to see this feature trickle down to other languages (*cough* Ruby *cough*) as well.

Great upgrade, folks. Here’s a wish: although I’m already a heavy user of the old-style ‘dataflow to this’, you lost me on ‘dataflow from this’. I understand what it does, but the naming is making it harder than it is. Knowing how hard it can be at times, still, mind producing a nicer and ‘simpler’ name for the ‘from this’ dataflow?

Andrew, what do you suggest?
I’ve come across the ‘backward slicing’ and ‘forward slicing’ names for the dataflow to/from actions respectively, see http://people.brunel.ac.uk/~csstmmh2/exe1.html
But I am not sure whether they are any more understandable.

Looks like Maia is going to be the version even I’d find something useful for my daily work for long long time. I’ve purchase all versions from v6 to v9 already, but only with Maia I’m having hard times to wait the release to be released 😉

How about adding a verb to the feature name? Something like ‘Trace dataflow from’ and ‘Trace dataflow to’. This would actually be consistent with the menu where it appears, for everything else there starts with a verb.

Re: the naming of the commands, I immediately understood what “Dataflow to this” and “Dataflow from this” meant. By explicitly mentioning the direction tot he point of reference (this), it was very clear.

In contrast, I’m always confused between “Analyze Dependencies” and “Analyze Backward Dependencies”, and I think the issue there is it doesn’t explicitly indicate the direction to/from the object in question, e.g. “Dependencies on this” or “Dependencies of this”.

Guys, IDEA is rapidly rising to the first positions in my personal list of most respected programs; so is JetBrains. This is simply terrific, please keep up the recent spree of inspiration that seems to go into MAIA.