Hi.
>> Seems to be an interesting task. :) I'll see what I can do. I think, a
>> generic mechanism must be possible here. Say, a resource name
>> MyClass.ann.xml exist next to the MyClass.class. When required, the
>> annotation reader looks for the corresponding file and reads annotations.
>
> Yes. If one could change the 'ann' portion, that can be used to have
> multiple bindings for the same set of classes.
Yeah. Further options are, for instance, selecting which exactly XML resources
will come into play (like, project-ex.jar should be used but not project.jar).
> The other thing to consider is a performance. I might have mentioned
> this somewhere else, but reading annotations from an external file could
> be a lot quicker than using reflection, because the # of annotations
> tend to be much smaller than the # of methods/fields. The RI has to
> check for all the fields/methods just to see if there are any JAXB
> annotations. If all annotations are available in the file, especially if
> they are all in one file, it could be a lot quicker.
>
> In that sense, it might be nicer to have one XML file includes
> annotations for more than one class --- like one XML file per package,
> maybe. There's obvious trade-offs, but it's worth considering.
Nice idea, I'll consider it.
>> The only thing I miss right now is instantiation of annotations.
>> Annotations are essentially either abstract classes or enums. Enums
>> are trivial. Abstract classes need to be implemented first (I simply
>> haven't done this before).
>
> You mean annotations are interfaces, right?
Well, yes, the difference between abstract classes and interfaces is not
relevant here.
> java.lang.reflect.Proxy
> should be able to implement it for you, if you just want to get it done.
>
> If you want to do it efficiently (don't know if the difference matters),
> then there might be other ways, like full byte-code synthesis via ASM
> or BCEL.
>
> But I recommend java.lang.reflect.Proxy as the first step.
Thanks, I don't think I'll have any problems implementing this. ;) This is just
something I haven't yet done before.
I think I'll avoid ASM/BCEL/Javassist at the moment to avoid additional
dependencies.
>> This can really be a generic mechanism which simply parallelizes
>> reflection-based annotation discovery. Maybe I miss something and the
>> thing like this already exists? AnnotationReader could the be
>> implemented on top of this mechanism.
>
> There's some effort to back port annotations to JDK 1.4, so those folks
> might have something (like http://backport175.codehaus.org/)
>
> But there are also a few key differences. Here, we'd actually prefer to
> be able to have a multiple set of annotations. Those projects tend to
> simply mirror the semantics of Java5 annotations, so they might not let
> you choose annotation sources.
Yes, this does not seem like what I'm trying to do.
I've started the new "annox" project few days ago:
https://annox.dev.java.net
This will be the middle layer for annotation readers, independent of JAXB or
anything else. I think this is a nice idea which is good for Java in general.
XAnnotationReader for JAXB will be based on annox then. I'll also use annox in
my "annotate" plugin.
>> BTW, I'm working on the "annotate" plugin which converts XML Schema
>> annotations into class/field annotations. For instance the XML:
> <snip />
>> This works already, so I think I'll try implementing this idea with
>> ann.xml as well.
>
> Cool. Where is this annotate plugin available?
This is the part of hyperjaxb3-tools. It's not released yet and I think I'll
first implement annox and base the annotate plugin on annox.
I've also reworked the "toString" plugin and implemented the "cloneable" plugin.
All these "general-purpose" plugins (hashCode, equals, toString, cloneable,
annotate, jaxbindex) are part of the hyperjaxb3-tools module. They will be
release in 1-2 weeks independently of Hyperjaxb3 (which is also being actively
developed), when I finish documentation and add sample projects/build scripts
for developers.
Bye.
/lexi