Classes "Dependency Walker"?

[Elena]

Is there a *simple* tool which, given a name of a class, lists
all .class and .jar files upon which such class depends, recursively?
Kind of what Dependency Walker does with Win32 binaries:

http://www.dependencywalker.com/snapshot.png

A command line version would be better.

I've found a few tools (CDA, Dependency Finder, etc.), but they seem
overkill and difficult to use.

Thanks

 

[Joshua Cranmer]

Is there a *simple* tool which, given a name of a class, lists
all .class and .jar files upon which such class depends, recursively?

Strictly speaking, this cannot be done correctly, if you take into
account that some programs may have class loaders which do not even have
a concept of class/jar files.

For a tool to find all jars a jar file depends on, just look at the
class path, as determined by the manifest. This will naturally be a
superset, however.

 

[Roedy Green]

Is there a *simple* tool which, given a name of a class, lists
all .class and .jar files upon which such class depends, recursively?
Kind of what Dependency Walker does with Win32 binaries:

There is GenJar which collect all the classes you need for a Jar.
See http://mindprod.com/jgloss/genjar.html

There was packajar, but I don't know if it is still around.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"It’s a job that’s never started that takes the longest to finish."
~ J. R. R. Tolkien

 

[Albert]

Joshua Cranmer a écrit :

Strictly speaking, this cannot be done correctly, if you take into
account that some programs may have class loaders which do not even have
a concept of class/jar files.

For a tool to find all jars a jar file depends on, just look at the
class path, as determined by the manifest. This will naturally be a
superset, however.

What a stupid answer !! Searching for deps might be to avoid a
"superset" and fit to what is needed.

 

[cbossens73]

Joshua Cranmer a écrit :




What a stupid answer !! Searching for deps might be to avoid a
"superset" and fit to what is needed.

After so many years lurking in this group I've seen
that Joshua Cranmer was very helpful and often answering
newcomer's questions.

He did give you a good answers.

Calling his answer "stupid" is the best way not to
get any help in the future in my opinion.

As a matter of fact I think nobody should answer
your question seen how you call names on people
helping you,

Charles.

 

[Andrew Thompson]

After so many years lurking in this group I've seen
that Joshua Cranmer was very helpful and often answering
newcomer's questions.

He did give you a good answers.

Note that the person asking the question is not
the same person who made the 'stupid' comment.

(As an aside. I too, have come to respect the
contributions of Joshua Cranmer.)

 

[Lew]

Note that the person asking the question is not
the same person who made the 'stupid' comment.

(As an aside. I too, have come to respect the
contributions of Joshua Cranmer.)

It was to address the possibility that a superset might not be what's wanted
that Joshua very responsibly pointed out that his idea might return a
superset, and that "trictly speaking, this cannot be done correctly"
exactly as the OP asked.

Chill out, "Albert". Oh, and "Albert", you only need one exclamation point
without intervening spaces to punctuate the end of an exclamatory sentence.

 

[Andreas Leitgeb]

Strictly speaking, this cannot be done correctly,...

It surely is impossible to do it "strictly speaking" absolutely
correctly, since it won't be able to catch all the dynamic
dependencies (by classloaders and reflection).

When restricting it to static dependencies, such an analysis is not at
all that infeasible. My first approach would be running
javap -verbose path.to.EachClass
and grep the constant table for lines like "^const #\d* = class "
and extract the mentioned class name from the eol-comment. This needs
to be done recursively for each other class thusly obtained, preferrably
making use of something like a HashSet to recognize classes that were
already handled or are being handled right now, since this dependency-
"tree" surely won't be loop-free.

So much for a "proof of concept"

No, I don't know of any simple tools, either. If I were
in the situation, I'd probably write it myself.

 

[Joshua Cranmer]

When restricting it to static dependencies, such an analysis is not at
all that infeasible. My first approach would be running
javap -verbose path.to.EachClass
and grep the constant table for lines like "^const #\d* = class "
and extract the mentioned class name from the eol-comment. This needs
to be done recursively for each other class thusly obtained, preferrably
making use of something like a HashSet to recognize classes that were
already handled or are being handled right now, since this dependency-
"tree" surely won't be loop-free.

It would probably be faster and easier to just open each class file and
read the constant pool to find class references, especially on very
large classes. An experienced programmer could probably throw together a
tool to do this in an afternoon--the hardest part is figuring out how to
format the output.

 

[Elena]

Thank you very much for your answers. I don't think a proper one has
been posted. Maybe I've stated my need in a wrong way.

What I need is a simple way to trace class dependencies on a deployed
solution. I'm a Java newbie yet I'm an experienced C++ programmer.
What I've observed is that my colleagues working on Java always seem
to struggle with classpath troubles, the same way I could do with
native DLLs, but I employ tools to automatically detect such problems.
I was wondering if there was an easy way to track down wrong
configurations and classpath conflicts. For instance, if a customer
calls, I can easily make the application trace: operating system,
paths and versions of loaded DLLs and so forth. What about a Java
application? Maybe the -verbose flag could help? Thanks.

 

[Joshua Cranmer]

Thank you very much for your answers. I don't think a proper one has
been posted. Maybe I've stated my need in a wrong way.

Let me a bit more explicit in my answer:
In the Windows development world, the basic unit of dependence is DLL files.

In Java, the basic unit of dependence is class files, which just happens
to be packaged into jars. It is possible--excluding class loader
shenanigans--to tell you what classes your Java program will use, but
there's no easy way to map these into jar files since they need not be
in the same jar file. I could theoretically repackage the JRE 7 runtime
into java7rt.jar and have stuff work but trying to repackage Vista's
kernel32 into vistakernel32.dll would break stuff.

I was wondering if there was an easy way to track down wrong
configurations and classpath conflicts. For instance, if a customer
calls, I can easily make the application trace: operating system,
paths and versions of loaded DLLs and so forth. What about a Java
application? Maybe the -verbose flag could help? Thanks.

For Sun's JVMs, it is possible to get Java to tell you its current
classpath via the java.class.path system property; java.ext.dirs also
tells you the extension directory. The documentation for
System.getProperties() implies that all JVMs must have these properties,
so it should work on non-Sun JVMs as well.

 

[Elena]

Let me a bit more explicit in my answer:
In the Windows development world, the basic unit of dependence is DLL files.

In Java, the basic unit of dependence is class files, which just happens
to be packaged into jars. It is possible--excluding class loader
shenanigans--to tell you what classes your Java program will use, but
there's no easy way to map these into jar files since they need not be
in the same jar file. I could theoretically repackage the JRE 7 runtime
into java7rt.jar and have stuff work but trying to repackage Vista's
kernel32 into vistakernel32.dll would break stuff.

Therefore a tool which extracts static class dependencies and then
starts scanning classpath directories and paths looking for required
classes and then dumping where it found them has not been developed?
Of course I'm talking about static dependencies and standard
classloader, otherwise I understand things get messy.

Thanks

 

[Mark Space]

Therefore a tool which extracts static class dependencies and then
starts scanning classpath directories and paths looking for required
classes and then dumping where it found them has not been developed?

Well, they have, and you mention two in you OP. Why are those tools not
suitable? Do they not perform some function you need?

 

[Thomas Kellerer]

Elena wrote on 02.04.2009 17:00:

I've found a few tools (CDA, Dependency Finder, etc.), but they seem
overkill and difficult to use.

Here is another list:

http://java-source.net/open-source/code-analyzers/dependency-finder