CODEWITHSUNDEEP
javaimportcode-analysis
user1628103
user1628103

Reputation: 197

Tool to determine transitive Java imports?

Is there some sort of tool that you can point at a set of Java classes, and it produces output showing the transitive imports of each class?

I understand that imports are not "transitive" from the point of view of the language itself - i.e. if com.acme.X imports com.acme.Y, and com.acme.Y imports com.acme.Z, that does not mean that you can refer to com.acme.Z within com.acme.X. But that's not what I mean:

Rather, I mean that com.acme.X nonetheless depends upon com.acme.Z (at least under the current implementations of X and Y), and I want to know that fact. In fact I want to know it for a large number of classes, and so I'm hoping that there's a tool do determine it automatically.

Either a standalone tool or an Eclipse plugin or feature would be great.

Thanks in advance.

EDIT to hopefully show what I want this for:

I have a huge monolithic jar that contains many features that are (essentially) completely unrelated. I'd like to break it apart into several smaller, more manageable, and more self-coherent jars.

Unfortunately, I can't do it simply by breaking it up based on packages, because many of the packages themselves are not self-coherent either. That is, for example, there's a "com.acme.utils" package. Two things in that package are probably have nothing in common except for the fact that they're both, in some sense, "utilities". One may be a utility for some particular business function, another may be TCP/IP utilities, another may be a set of string utilities, another may be some completely unrelated business function.

And there are a bunch of packages like this. So when you look at the transitivity of imports from the point of view of packages, they snowball without limit, and so more or less everything in the monolithic jar depends on everything else in the monolithic jar.

So I'd like to start by considering transitivity of imports from the class point of view, rather than the package point of view. That way I should be able to more easily determine what classes need to be reorganized from what existing packages into new, more coherent packages, and then after that I can break the monolithic jar apart by packages / sets of packages.

Upvotes: 4

Views: 736

Answers (1)

Erhan Bagdemir
Erhan Bagdemir

Reputation: 5327

we're using sonar for software metrics. http://www.sonarsource.org/

Upvotes: 2

Related Questions