Re: Ongoing bsh interface problem

On Sun, 12 Mar 2006, Martin Schwamberger wrote:
> Glenn Murray wrote:
>> If you are interested in an internal list of classes for the project, why 
>> shouldn't the class list update be restricted to the compilation 
>> destination directory, and in that case only when the user specifies it?
>
> My description might have been a bit misleading.
> The directory I have been taking about is the destination directory.
> JDEE's compile finish hook does already restrict the update to the
> this directory.
> It takes all subdirectories into account because of Java packages.
> All imported packages might contain newly compiled files.
> The update could be optimized by checking the imports of the source file. The 
> check would need to be performed recursively for all updated packages.
>
> I would not disable the update if the destination directory is not specified. 
> If a class file is accessible via classpath, it should be available for JDEE.

It seems to me that any attempt to recursively search 
directories not specified by the user is doomed.  For 
example, it seems that the default behavior for compiling 
~/Test.java is to search ~/*.*, so JDEE locks up Emacs for 
12 minutes while it's busy generating a 
"java.lang.OutOfMemoryError: Java heap space" message. 
Note that when I installed wine it created the following 
link:

lrwxrwxrwx  1 glenn glenn 1 2006-02-02 10:52 .wine/dosdevices/z: -> //

so, in fact, JDEE is trying to search the entire filesystem. 
If you tried to restrict the search to the source code 
imports you might still encounter the link problem---who 
knows what links someone might put in "myjavalibs/" before 
doing "import myjavalibs.*;"?

> BTW, the class list contains all classes found in the classpath of the 
> project, not only those belonging to the current project.

I don't understand the difference between "the project" and 
"the current project".  Do you mean all JDEE projects?

Thanks,
Glenn