Eclipse question re dependencies

[Rhino]

Is there a way to determine the class dependencies in my code within
Eclipse?

For example, one of my projects makes use of various classes within a
"Common" project along the way. What is the simplest way to determine the
specific classes from "Common" (and any other projects outside my own) that
my project depends on?

At the moment, I'm actually opening each Java source file, looking at the
imports for each class where the first qualifier isn't java, and then
writing it down on a piece of paper. There's got to be a quicker way in an
IDE as slick as Eclipse but I'm not seeing it. (I tried searching on "class
dependencies" in the Eclipse help and got lots of hits but none of them
seem on point.)

I'm using Eclipse 3.5.2.

 

[Lew]

Is there a way to determine the class dependencies in my code within
Eclipse?

For example, one of my projects makes use of various classes within a
"Common" project along the way. What is the simplest way to determine the
specific classes from "Common" (and any other projects outside my own) that
my project depends on?

At the moment, I'm actually opening each Java source file, looking at the
imports for each class where the first qualifier isn't java, and then
writing it down on a piece of paper. There's got to be a quicker way in an
IDE as slick as Eclipse but I'm not seeing it. (I tried searching on "class
dependencies" in the Eclipse help and got lots of hits but none of them
seem on point.)

I'm using Eclipse 3.5.2.

While I can see how there might be occasional times when that information is
marginally useful, it's usually enough to know what JARs your code depends on,
since you don't get to pick and choose partial JAR pieces in your deployment.

A UML diagramming tool will give you what you want. If there isn't one built
in to Eclipse, there are plugins for that.

 

[Tom Anderson]

For example, one of my projects makes use of various classes within a
"Common" project along the way. What is the simplest way to determine
the specific classes from "Common" (and any other projects outside my
own) that my project depends on?

Edit your project's build path to take Common off it. Look at the Problems
view and see what classes now can't be found.

Don't know how you'd get that as a file, though.

tom

 

[Rhino]

While I can see how there might be occasional times when that
information is marginally useful, it's usually enough to know what
JARs your code depends on, since you don't get to pick and choose
partial JAR pieces in your deployment.

Fair enough. This is certainly information I don't need terribly often
but I find myself wishing I had a quick way to get it today....

I'm really just trying to ascertain precisely which classes from outside
of my project would be necessary if the project were to be re-created on
another computer. It seemed like something that Eclipse might provide
built-in support but apparently not....

A UML diagramming tool will give you what you want. If there isn't
one built in to Eclipse, there are plugins for that.

I've been meaning to get into some UML diagramming anyway so I'll start
looking in that direction....

Thanks for your reply.

 

[Rhino]

Edit your project's build path to take Common off it. Look at the
Problems view and see what classes now can't be found.

That's a pretty quick and effective way to get the actual information.

Don't know how you'd get that as a file, though.

Since Eclipse apparently doesn't give you a built-in way to figure this out
- and write it to a file - I may just knock together a quick class to do
this for me. Shouldn't be too hard to get a class to just open all the java
source files in a project in turn, grab the import statements and then sort
the accumulated imports and remove duplicates....

Thanks for your suggestion!

 

[Lew]

Since Eclipse apparently doesn't give you a built-in way to figure
this out
- and write it to a file - I may just knock together a quick class to do
this for me. Shouldn't be too hard to get a class to just open all the
java [sic]
source files in a project in turn, grab the import statements and then
sort
the accumulated imports and remove duplicates....

import statements don't define class dependencies.

---------------------8<-----------------------
// import nothing;
class Foo {
com.rhino.common.Bar bar = com.rhino.common.DISCO;
…
}
---------------------8<-----------------------

Lest you think RGB is splitting hairs, this comes up quite often in real code.

For example, code that interacts with JDBC will often use both
'java.util.Date' and 'java.sql.Date' in the same class. Only one of those can
be imported.

IDEs like Eclipse and NetBeans do dependency analysis - that's how they know
where to show you the errors. Perhaps you can review their source to see how
they do it.

I am not familiar with Java's Java compiler API, but I speculate that it might
have some useful features for your problem.

 

[Tom Anderson]

import statements don't define class dependencies.

---------------------8<-----------------------
// import nothing;
class Foo {
com.rhino.common.Bar bar = com.rhino.common.DISCO;
?
}
---------------------8<-----------------------

RGB is right - figuring out the true dependencies is harder than this.
There's this guy called Joshua Maurice you should talk to about it ...

tom

 

[Rhino]

Since Eclipse apparently doesn't give you a built-in way to figure
this out
- and write it to a file - I may just knock together a quick class
to do this for me. Shouldn't be too hard to get a class to just open
all the java [sic]
source files in a project in turn, grab the import statements and
then sort
the accumulated imports and remove duplicates....

import statements don't define class dependencies.

---------------------8<-----------------------
// import nothing;
class Foo {
com.rhino.common.Bar bar = com.rhino.common.DISCO;
…
}
---------------------8<-----------------------

Lest you think RGB is splitting hairs, this comes up quite often in
real code.

It's not a frequent occurrence in _my_ code

For example, code that interacts with JDBC will often use both
'java.util.Date' and 'java.sql.Date' in the same class. Only one of
those can be imported.

I see your point; if I omit the import because of the class between the
java.sql.Date and java.util.Date - which actually happens in my
DateTimeUtils class - and only look at import statements, I will miss the
fact that I've specified java.sql.Date directly in one of my methods.

I hadn't thought of that but it necessarily renders the approach of
looking at imports slightly less than infallible. But, given how rarely I
have that kind of clash in my code, I'm not going to sweat it a lot. And
it's not like I need something that's absolutely 100% guaranteed reliable
anyway. I was just looking for something a little faster than what I'm
doing now in the rare instances where I actually need that dependency
information.

IDEs like Eclipse and NetBeans do dependency analysis - that's how
they know where to show you the errors. Perhaps you can review their
source to see how they do it.

I am not familiar with Java's Java compiler API, but I speculate that
it might have some useful features for your problem.

I'd think about going that way if this were a more important need but
it's not. If it becomes more important, I'll probably look at the UML
modelling tool you suggested earlier in preference to writing something
that involves have to figure out how Eclipse does dependency analysis....

Thanks for the suggestions though!