> 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
