Re: finding all Java classes in a project

Svata, thanks for the tip about CompilationUnit.getBuildTarget().  That
does exactly what I need.  See more comments inline.

Svata Dedic wrote:
> 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.

The list is created at debugger start-up time and should match the
compiled classes.  There would not (normally) be any uncompiled
classes, but I'm interested only in the compiled ones.  MDR is not
necessary.

It does seem to me that there should be a function in either JavaProject
or CompilationUnit that returns the class names instead of my having to do
the conversion from URL to class name in my code.  But I can live with it
as it is now, since I discovered that I don't have to walk the filesystem
to find the class files.

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

[from a previous message]
> Dave Weatherford wrote:
>> I saw that Svata recommended using JavaProject.getClassesDescriptor(), but I
>> have not been successful; it always returns null for me.
>>
> This is surely a bug, if applied on the CU's build target.

I was trying to apply JavaProject.getClassesDescriptor() to the
ProjectMember for a source file.  Obviously not what it was intended
for.  I'm still trying to grok the various pieces of a Java project.

-- 
Dave Weatherford                Sun ONE Developer Products
[email protected]       Sun Microsystems, Inc.