Re: Ongoing bsh interface problem

Glenn Murray wrote:
> 
> 
> 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.*;"?

No, in this case only myjavalibs itself would be scanned,
because this is the name of the package.
Ok, if there are classes in myjavalibs that import classes of
other packages, those packages had to be scanned as well ....
But anyway, I think there is an easier solution:
JDEE initializes the class list lazily. This means the search takes 
place when the user requests the class list the first time.
Unfortunately, the list update method does not leverage this feature.
This could easily be fixed.
Together with the classpath check, the deferred update would at least 
mitigate the problem.
Your home directory would only be scanned if it appeared in the
classpath *and* you called a function that relies on the class list
(e.g. jde-import-*).
What do you think?

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

Well, there is actually no difference ;-)
What I tried to say is, that the class list does not only contain the 
classes of the project itself, but also all classes found along the 
classpath (e.g. org.apache.commons.logging.Log).

Cheers,

Martin

> 
> Thanks,
> Glenn
> 
>