myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan-Kees van Andel <jankeesvanan...@gmail.com>
Subject Re: Scanning for annotated classes in MyFaces 2
Date Sun, 18 Jan 2009 16:01:35 GMT
> That sounds great.
>
> What is your general approach? Just read in the class as byte[], then
> use the class-file-format rules to get to the annotations sections on
> the class and the methods? From my quick scan of the classfile spec it
> seemed reasonably easy to do that...
>

This line is the important one:
DataInputStream dis = new DataInputStream(new BufferedInputStream(new
FileInputStream(classFile)));

The DataInputStream is responsible for delivering the bytecode to me
as easy-to-read ints, shorts and bytes.
The first chapter of this document specifies the relation between the
terms used in the spec and the DataInputStream API.
http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf

>From there it's just reading each field, which is quite cumbersome and
hard to get right the first time, because you need to read the spec
very carefully. For example, when reading a double or long, you need
to skip the next byte. Forget this and you get annoying errors, like
EOF or variables that contain nonsense.
But when you get the hang of it, it's not that hard.

> I'd be interested to know the actual requirements that MyFaces has for
> such a scanner. For example, does it ever need to look for annotations
> on methods when the class itself is not annotated?
>

I also have some questions for the JSF 2.0 EG, like what classpaths
need to be scanned by default. Or the policy of dealing with runtime
invisible annotations (I can read them, but Reflection cannot). I'm
also interested in general rules regarding class/method signatures.
For example, do you need to implement a specific interface when
annotating a class with @FacesComponent?

> Your comment about "expose parsed classes" seems to imply that you are
> providing some kind of DOM-style API. I would have thought that a
> SAX-style API would be better, ie various bits of code interested in
> annotations registers callbacks for annotations it cares about with the
> "scanner". Then the scanner scans all jars in the classpath and when
> something is found that matches a "registered" annotation, then it
> invokes the appropriate callback. That approach would minimise memory
> usage, and I can't see where we would need anything dom-like...

Well, for performance reasons you would like a SAX style API, but
afaics, the class file format is not very developer friendly. Maybe it
just takes some getting used to, but on first sight, it looks less
intuitive than SAX parsing an XML document. For example, class
attributes are placed below the fields and methods, so you don't know
the class annotations when reading through the fields and methods.
That's not very intuitive for a developer.

My plan was not to fully initialize the classes, but just fill them
with the bytes read. This way, I get a little bit more structure so I
don't have to think in bits and bytes too much. The heavy work will be
done lazily. For example, I don't initialize the classes' fields
unless the user asks for it, probably resulting in less memory usage
and better performance than a fully fledged DOM model.

But there's only one way to find out and that's implementing and testing it.

I'm gonna look at a SAX style API. Maybe it's not as bad as I first thought...

Regards,

/Jan-Kees

Mime
View raw message