[hibernate-dev] Annotation Processor for HV

[Emmanuel Bernard]

On 6 déc. 09, at 22:51, Gunnar Morling wrote:

>
>
> 2009/12/4 Emmanuel Bernard <emmanuel at hibernate.org>
>
> On 3 déc. 09, at 23:09, Gunnar Morling wrote:
>
>> 2009/12/3 Emmanuel Bernard <emmanuel at hibernate.org>
>> For sole determination of allowed types for constraint annotations  
>> you wouldn't need any validator implementations (or HV core) on the  
>> AP classpath when working with the mirror API, just BV API and the  
>> AP itself.
>>
>> You do. Otherwise how do you make custom constraint work?
>>
>> Actually not. From an element annotated with a constraint  
>> annotation you can
>> - get the annotation mirrors
>> - filter on those annotated themselves with @Constraint
>> - retrieve the element value with name "validatedBy"
>> - retrieve the type mirrors contained
>> - retrieve the value of the 2nd type argument and check the type of  
>> the annotated element against it
>
> The classes referenced by the validatedBy *are* the validator  
> classes at least if by validator you mean ConstraintVaildator  
> implementation of the custom constraint, so they have to be in the  
> classpath to be mirrored by the AP machinery :)
> For built-in types it's a bit different as the @Constraint is not  
> filled up and has to be simulated.
>
> Hi,
>
> what I mean is that there is a distinction between the class path of  
> a project and the class path from which an AP attached to this  
> project can see classes (javac option "processorpath", in Eclipse  
> called "factory path", I referred to it as "AP class path" earlier).  
> An AP can see classes (in form of Java class objects) only if they  
> are part of the latter. Types defined in the project processed by an  
> AP (or part of the project's class path) the processor can only see  
> by means of the JSR 269 API.
>
> If we wanted to use HV core for determination of allowed  
> constraints, all constraint annotation types, validators and  
> annotated types needed not only to be part of the project class path  
> but also of the processor path. While this would work for  
> constraints built previously (by adding their classes/JARs to the  
> processor path), this wouldn't work for constraints/annoted types  
> defined within the processed project itself, as no class files exist  
> for them during compilation.
>
> So right now for determination the allowed constraint annotations at  
> a given element I only see the way described above: use the mirror  
> API to navigate from the annotated element to the type parameters of  
> the validator types referenced by any constraint annotations and  
> check wether the type of the annotated element is compatible (which  
> all can be done - though rather verbosely - by using the JSR 269 API).
>
> That way only the AP itself is required on the processorpath (and  
> possibly the BV API to make implementing the processor easier). This  
> generally works already in the patch Hardy applied. So if there  
> aren't any other ideas, I'd continue with that approach.

OK I understand better now, sorry about that. It's just that I find it  
weird that an AP cannot access the project CP as is. That would not be  
the first weird thing in the Java platform :)
It might make sense to push some of the mirror-based resolution code  
to jType (just like we do today for the Class based resolution), or at  
least isolate it as a first step to keep this option open.