Open aneveux opened 12 years ago
Study is as follow,
We have 4 Resource Selector,
1) org.parallelj.designer.typeselector.processor.annotation 2) org.parallelj.designer.typeselector.processor.model 3) org.parallelj.designer.typeselector.processor.hierarchy 4)ProgramElementsResourceProcessor (this inner class, and use for procedure selection in handler)
and only in hierarchy one we manage our own cache, and this also can be removed, 1) we need to modify JavaExecutableProcessor,
instead of
javaSearchScope = JavaExecutableScopesCache.getInstance().getScope(type);
we need to use
javaSearchScope = SearchEngine.createHierarchyScope(type);
and need to remove some code which is fixed issue due to this internal cache management (see #30).
But SearchEngine cache is bit slow, so currently keeping own management cache hierarchy project in since no issue due to that.
ParallelJ contains various processors linked to the Resource Selector, from now, we can find cache mechanism in approximately all of them, but it's perhaps not mandatory. As JDT for example comes with a native cache mechanism, we perhaps don't have to develop our own cache mechanism.
The only one which seems mandatory for the moment is the one linked to EMF models. But we need to validate that it's completely true, and if so, we can remove the cache mechanisms from the other processors.