Prev: Need help designing some JUnit tests
Next: Design Questions about static factory classes
From: RedGrittyBrick on 20 May 2010 19:00
On 20/05/2010 21:59, Rhino wrote:
> Tom Anderson<twic(a)urchin.earth.li> wrote in
> news:alpine.DEB.1.10.1005202003440.3936(a)urchin.earth.li:
>
>> 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....
>

import statements don't define class dependencies.

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

--
RGB
From: Lew on 20 May 2010 19:34
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
From: Tom Anderson on 21 May 2010 06:58
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
From: Rhino on 22 May 2010 16:57
Lew <noone(a)lewscanon.com> wrote in news:ht4gte$csv$1(a)news.albasani.net:

> 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
First  |  Prev  | 
Pages: 1 2
Prev: Need help designing some JUnit tests
Next: Design Questions about static factory classes