"alesj" wrote : "emuckenhuber" wrote :
| | * jboss-metadata - for example jboss-metadata is just asking the AE to get a list
of classes which have a given top-level annotation (e.g. @Stateful). Then loading the
class and do a separate annotation processing with java reflect. This is also because AE
does not have enough information about inheritance, which is needed for all the EE
annotation processing.
| |
| But then you should not use java reflect, but JBoss Reflect. ;-)
| Why?
| Because this info is already present if we use McAnn, as McAnn already uses JBoss
Reflect, and Reflect caches this info.
|
| And this also shows that things go hand in hand, and that this inheritance check
should not be part of annotation scanning.
|
| Not to mention another very good example why re-using existing libs is good. ;-)
|
I come to the opposite conclusion. The ideal indexer will, in my opinion, scan a set of
classes associated with an archive once (at run time), and maintain a completely
string-based index of annotations -> members (by name), and classes -> superclasses
(by name). With this information, and one index per archive, you can find any annotation
(including inherited) on any member of any class without loading the class or using
reflection in any way. If you were to use an optimized string map like a trie for
example, it's possible this data could be collected very quickly and stored in much
less space than the equivalent reflective solution.
In addition, it's possible that this preindexing can be used to accelerate
classloading, at least to the extent that missing classes can be identified without
querying the filesystem.
Finally, using this system one can reuse the same index even when the same class or JAR is
part of many classloaders, since the index is based only on the file structure and not on
what's been loaded (think of shared JARs in the classpath of more than one isolated
EAR, for example).
One of the driving forces behind the discussion was the need (in EJB3, IIRC) to be able to
perform this kind of scanning without loading classes at all, even in the presence of
inheritance across modules. And this is a case where the existing solutions completely
fail to meet the requirements.
This is in addition to the use case of pre-indexing; but once such a fast/efficient index
exists for online scanning, why not reuse it for offline scanning too?
And this, as one might say, is why reusing existing libs is bad. :-) At least, using
existing libs even when they don't quite meet the requirements.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262973#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...