> > 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?
Afaik, only jars with a faces-config.xml under META-INF are subject to scan in classpath. On Sun, Jan 18, 2009 at 4:01 PM, Jan-Kees van Andel < jankeesvanan...@gmail.com> wrote: > > 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 >
