Eclipse question re dependencies

Discussion in 'Java' started by Rhino, May 20, 2010.

  1. Rhino

    Rhino Guest

    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.

    --
    Rhino
     
    Rhino, May 20, 2010
    #1
    1. Advertising

  2. Rhino

    Lew Guest

    On 05/20/2010 02:12 PM, Rhino wrote:
    > 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.

    --
    Lew
     
    Lew, May 20, 2010
    #2
    1. Advertising

  3. Rhino

    Tom Anderson Guest

    On Thu, 20 May 2010, Rhino wrote:

    > 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

    --
    The revolution is here. Get against the wall, sunshine. -- Mike Froggatt
     
    Tom Anderson, May 20, 2010
    #3
  4. Rhino

    Rhino Guest

    Lew <> wrote in news:ht3v3u$h2e$:

    > On 05/20/2010 02:12 PM, Rhino wrote:
    >> 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.
    >

    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
     
    Rhino, May 20, 2010
    #4
  5. Rhino

    Rhino Guest

    Tom Anderson <> wrote in
    news::

    > On Thu, 20 May 2010, Rhino wrote:
    >
    >> 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.
    >

    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!


    --
    Rhino
     
    Rhino, May 20, 2010
    #5
  6. Rhino

    Lew Guest

    Rhino wrote:
    >> 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....


    RedGrittyBrick wrote:
    > 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.

    --
    Lew
     
    Lew, May 21, 2010
    #6
  7. Rhino

    Tom Anderson Guest

    On Fri, 21 May 2010, RedGrittyBrick wrote:

    > On 20/05/2010 21:59, Rhino wrote:
    >>
    >>> On Thu, 20 May 2010, Rhino wrote:
    >>>
    >>>> 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?

    >>
    >> 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....

    >
    > 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

    --
    London has a suburb for every emotion. -- Cliff Laine
     
    Tom Anderson, May 21, 2010
    #7
  8. Rhino

    Rhino Guest

    Lew <> wrote in news:ht4gte$csv$:

    > Rhino wrote:
    >>> 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....

    >
    > RedGrittyBrick wrote:
    >> 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!


    --
    Rhino
     
    Rhino, May 22, 2010
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Thomas
    Replies:
    1
    Views:
    771
    Robert Olofsson
    Oct 18, 2003
  2. javaguy44
    Replies:
    1
    Views:
    1,057
  3. Bill Grant
    Replies:
    1
    Views:
    466
    Ferenc Hechler
    Oct 20, 2004
  4. Ilias Lazaridis
    Replies:
    0
    Views:
    499
    Ilias Lazaridis
    Jan 8, 2005
  5. Andrew Wagner

    Rake task dependencies question

    Andrew Wagner, Sep 10, 2010, in forum: Ruby
    Replies:
    3
    Views:
    100
    Ryan Davis
    Sep 10, 2010
Loading...

Share This Page