Re: finding all Java classes in a project

Sreenivasa Viswanadha wrote:
> 
>> 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.
> 
> 
> Nobody is saying keep it in cache. If the operation is so simple, there 
> *should not* be a
> overhead in the MDR. Otherwise,  there is a fundamental flaw in the MDR 
> design. FYI, you
> can scan JDK sources and get all the toplevel class names in < 5 sec 
> without any caching.
>
Hmm... I wonder how you do that without creating a FileObject for aech 
file scanned _and_ without using some cache to retrieve the data from. 
If FileObjects can be constructed (which was one of your original 
objections), then there's no point to go through MDR, which will add - 
for this use case unnecessary - wrappers doing JMI reflection and 
events. A simple helper method would do better.

If the point is to _avoid_ FileObject construction, then you have to get 
the information by some other means (e.g. fetching it from a prebuilt 
MDR model), but then you have to sometimes update the stored information.

Doing almost any form of persistence (and sync) is IMO much greater 
overhead than create & forget a few hundred FileObjects which will be 
reclaimed from newborn GC area almost instantly.

Anyway, I do not think that adding a generic reflective/even firing 
wrapper comes for free in any design.

-Svata