One last bit (since you asked about runtime). Once the above
compile-time checks pass, you can then easily access the value of the
annotation at runtime using:
@ControlImplementation
public class MitchControlImpl {
@ControlBeanContext context;
// Extensible.invoke()
public Object invoke(Method method, Object [] args) {
String paramName =
context.getMethodPropertySet(MitchAnnot.class).intParamName();
int paramValue = (int)context.getParameterValue(meth,
paramName, args);
}
}
On 8/19/05, Kyle Marvin <[EMAIL PROTECTED]> wrote:
> On 8/19/05, Mitch Upton <[EMAIL PROTECTED]> wrote:
> >
> > I can see how this would work with String attributes, as you can just
> > parse them, find the markers, and then get the method parameter named in
> > the marker (via ControlBeanContext). However, has anyone thought of a
> > way to do this with non-String types? In this case, you can't come up
> > with some proprietary 'marker' syntax, and it has to be valid Java
> > syntax.
> >
>
> Hi Mitch,
>
> If your question is whether you could define an annotation like this:
>
> public @interface MitchAnnot {
> int intParam();
> }
>
> and then use it like this:
>
> @MitchAnnot(intParam={param1})
> public mitchAnnotatedMethod(int param1) { ... }
>
> then I think the short answer is that this is not possible.
>
> The problem here is that the Java compiler wants to do compile-time
> validation of @MitchAnnot usage against the declaration, including all
> of the annotation members. Because this is a syntactic check, it will
> happen before any APT processor handling of MitchAnnot (which exists
> for semantic checks and/or codegen) and the above will fail to
> compile.
>
> What you can do is something like this:
>
> public @interface MitchAnnot {
> String intParamName();
> }
>
> and then:
>
> @MitchAnnot(intParamName="param1")
> public mitchAnnotatedMethod(int param1) { ... }
>
> This satisfies the Java syntax for MitchAnnot and then an APT
> processor associated with MitchAnnot could do additional checking.
> For example, it could verify that the type of parameter referenced by
> the intParamName member ("param1") is actually an integer and generate
> appropriate errors if the types don't line up with the semantic
> contract.
>
> Hope this helps!
>
> -- Kyle
>
