This would translate to something like:
- public Set<Class<?>> getClasses(VirtualFile classpathItem, Set<Class<? extends Annotation>> annotationsToLookFor) (from the Hibernate plugin, assuming it looks for annotation on fields, methods and type), or return a Map<Class<? extends Annotation>>, Class<?>>
Hibernate plugin only checks for class annotations.
I would not re-use it, better writting new behavior in separate plugin.
- public Set<Class<?>> getClasses(List<VirtualFile> classpath, Set<Class<? extends Annotation>> annotationsToLookFor, Set<Class<?>> supertypesToLookFor) (note: in case there are multiple SCIs with HandlesType, this could be less efficient than using a map to pass the annotations/types to look for, and getting a map back; of course, it is simpler too)
Can you explain this one a bit more.
Or, why mix the parameters; annotation and supertypes?
We already have the annotations method, simply adding the supertypes, and the use Set intersection to get both?
The first one is for the standard EE annotations, nothing special.
The second one mixes annotations with types because that's what that SCI feature does. It allows specifying a set of annotations, or a set of types, and you get in a listener a Set of the classes in the webapp that respectively use the annotations (type, method, field), or are a subclass or imlplement the specified types. No need for sorting, it's a single Set with everything. I was sugesting a single method since it could avoid loops going through all the classes, right ?
I was sugesting a single method since it could avoid loops going through all the classes, right ?
No, that's the whole point of having this scanning "framework" -- we do it all (all sorts of indexing, ...) in a single pass.
What we need is just to properly prepare the info, so when the query is invoked, it's basically O(1) lookup.
So, split methods make sense to me, as then all we do is Set::intersect.
Or am I missing something?
(a) one annotations per VirtualFile, (b) one annotations per set of VirtualFile
I guess this is can be just (a), and you'll do your own iteration?
and one superclass thing per set of VirtualFile
Will we have pre-existing set of supertypes, or can this be any class?
The first one is quite easy to handle, where for the 2nd one we need to keep the whole classes hierarchy is some registry/"database".
I am ok with your (a).
/** * Get annotated classes. * * @param cpEntry the classpath entry * @param annotationsToLookFor the annotations to look for * @return set of annotated classes */ Set<Class<?>> getAnnotatedClasses(VirtualFile cpEntry, Set<Class<? extends Annotation>> annotationsToLookFor);
I still need more info in order to impl this.
* should I care where the annotation comes from; e.g. from class, method, field, parameter, meta-annotation, ...
* does the class have all annotations from annToLookFor or just one is enough
Same goes for inherited superTypesToLookFor.
* does the class have to inherit all or just one
getAnnotatedClasses is for the usual EE annotations, some can be on field, method, type.
So, you don't care where it is? e.g. @RunAs on whole class vs. just on a method
In this case this signature will do:
* Get annotated classes.
* @param cpEntry the classpath entry
* @param annotationToLookFor the annotation to look for
* @return set of annotated classes
Set<Class<?>> getAnnotatedClasses(VirtualFile cpEntry, Class<? extends Annotation> annotationToLookFor);
Since you can do the merging/intersection/... yourself. ;-)