Re: finding all Java classes in a project

Sreenivasa Viswanadha wrote:
> 
> I am not sure this is the right way to do it. Also, we might end up 
> creating too many file objects just
> to get the names of classes?
> 
And how do you think the set of classes produced by the compiler would 
be determined (if that's what Dave wants, assuming from his code) ? If 
the result should correspond to compiler's output then, at some point, 
the IDE must verify the output's presence.

Creating a FileObject (or set of them) should be much lower overhead 
than keeping the whole filesystem indexed in MDR.

> I believe there should be some helper function/util in the Java  module 
> that takes a  project and
> returns the list of class names. For example, one could implement this 
> using the MDR which
> IMO, is the most correct way.
> 
First off, design of MDR <-> java integration supposes that it will 
primarily cache information from sources, if they are available, so it 
may deliver class names, which weren't actually compiled yet.
If that is what Dave wants, then yes, MDR *is* the correct way because 
there's no other (clean and precise) way how to extract them. Sadly MDR 
is not available _right now_. After it becomes standard part of 
distribution, we will see.

Second, the constraint I was talking about is, that if the function that 
Dave seeks is to return the exact results, the relevant portions of MDR 
needs to be refreshed.
That means that the FileObjects will be constructed anyway *and* MDR 
overhead will be introduced. If Dave does not need exact result, but 
only most recent ones, then yes, MDR can be used.

In either case, it seems ridiculous to cache (and keep in sync) model of 
class names (based on compiler's output), since they can be converted 
easily from browsed files' names without unnecessary overhead of MDR.


-Svata