myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtiss Howard <>
Subject [Core] Annotation processing discussion (attn: Jan Kees)
Date Fri, 27 Feb 2009 21:31:28 GMT
Hi all,

I'd like to take this opportunity to address some concerns I have with
the way annotation processing is done.  I take interest in this
subject due to the extensive amount of work I have done in this area,
and I feel that I can shed some light on possible performance issues.
This message is mainly addressed to Jan-Kees van Andel as he is doing
the work on the MyFaces annotation processing engine, but of course
community input is always welcome.  I will address some points that JK
raised in a previous thread on the user mailing list:

"- Currently, I'm using the xbean-finder library from Geronimo for the
processing stuff. This library uses ASM under the hood which worries
me, since ASM is a widely used library and it has lead to many
classloading issues because of other frameworks packaging different
versions of ASM. "

I would strongly recommend that MyFaces does NOT move away from doing
class scanning with ASM (or some other bytecode scanning library) as
the only other alternative is pure reflection and the performance in
that case does not scale well at all.

"- I have also created an annotation scanner of my own, which is
actually quite fast and doesn't have a dependency on any library,
except Java. "

Since this scanner has no external dependencies, I'm tempted to
believe this is a reflective scanner.  If not, did you write a
bytecode scanning library?

"I don't think that making the annotation scanning code pluggable is
very useful since the xbean-finder library is already very easy to
use. "

The one major concern with the xbean-finder library is that it
assembles a list of all the JARs on the classpath and scans all of
them.  This is bad for a number of reasons:

1. The number of JARs to scan is _enormous_ in a typical customer
application running on a typical (i.e., bloated) appserver.
2. By indiscriminately scanning JARs that are on the classpath but not
necessarily part of the application you open yourself up to
potentially pulling in random annotations that could have negative
effects on the application.

Now, xbean-finder has a way for you to specify that you only want to
include JARs up to a certain point in the Classloader hierarchy, but
FaceConfigurator is not currently doing this :) and there is at least
one appserver I know of where even that approach wouldn't work since
applications are allowed to reference "shared libraries" that sit
apart from the normal classloader hierarchy.  At a minimum, I think
FacesConfigurator would need to allow pluggability for integrators to
decide how to populate xbean-finder with its set of Classloaders.

In terms of pluggability, what I'd like to see is a simple interface
that abstracts away annotation scanning.  This would be good for two
reasons: first, appservers that integrate MyFaces would be able to
take advantage of performance benefits that may arise from tight
coupling with their runtime (not to mention that they may need to
customize the classpath that xbean-finder or the like searches).  And
second, this is a good practice in general as MyFaces shouldn't
necessarily be tied to xbean-finder.  There may very well be better
solutions, and being able to plug them in would help in the long run.

My proposal for such an interface is this:

public interface AnnotationScanner {
	public Collection<Class> getAnnotatedClasses (Class annotationClass);
	public Collection<Method> getAnnotatedMethods (Class annotationClass);
	public Collection<Field> getAnnotatedFields (Class annotationClass);
	public Collection<Package> getAnnotatedPackages (Class annotationClass);

This interface is very similar to xbean-finder, and with good reason:
as you stated, it's a simple API to work with.  FacesConfigurator
would need minimal changes to adapt to this interface.  The advantage
here is, again, more freedom in how annotation scanning is performed.

Also, I would propose a factory that creates these instances with the
FacesContext (that should be enough context for implementers to work

Please let me know what you think.  Thanks,

Curtiss Howard

View raw message