[JSR308] Custom annotations?
Richard Gomes
rgomes1997 at yahoo.co.uk
Tue Feb 12 10:37:24 EST 2008
I plan to make the compiler give errors/warnings when the annotation processor
is being used. The code should compile without the annotation compiler,
anyway.
If possible, I'd like to ear suggestion from you guys on a tentative idea of
implementation I had.
The basic idea is:
I have one annotation which tells other annotations are 'much like a
typecast' , as we have in C++. Recapping from previous thread:
@Retention(RetentionPolicy.SOURCE)
@Target(ElementType.ANNOTATION_TYPE)
public @interface Typecast {
// Marks other annotations as 'typecasts'
}
Then I could define some tagging annotations, used much like a typecast:
@Typecast
@Retention(RetentionPolicy.SOURCE)
@Target({ ElementType.FIELD,
ElementType.LOCAL_VARIABLE,
ElementType.PARAMETER })
public @interface Rate {
// No methods - Tagging annotation
}
@Typecast
@Retention(RetentionPolicy.SOURCE)
@Target({ ElementType.FIELD,
ElementType.LOCAL_VARIABLE,
ElementType.PARAMETER })
public @interface Volatility {
// No methods - Tagging annotation
}
Finally, I'd like to raise a compiler error when I try to assign not
semantically equivalent fields, like this:
@Rate double rate = 1.0;
@Volatility double vol = rate; // cannot compile!
I'd like to ear from you guys about some doubts... only some overall
directions, as I know I will have to browse the examples anyway.
1. How many phases the compiler performs and how the annotation processor
plugs into the compiler in order to process the code generation tree? I mean:
@Typecast must be declared/defined in order to give meaning to @Rate and
@Volatility, which must be declared/defined in order to give meaning to the
assignment statement which will end up failing. I add that @Typecast must be
declared in the source code and already known (semantic meaning defined) by
the annotation processor in order to verify if @Rate and @Volatility were
properly declared (without any methods, I mean). Once @Rate and @Volatility
have been accepted, they will be ready to give semantic meaning to fields in
assignments and so on.
2. Is it correct to say that's enough to have RetentionPolicy=SOURCE for @Rate
and @Volatility annotations? My aim is to avoid any performence penalty as
possible at runtime due to performance concerns.
Thank you all and be sure that any suggestion/opinion/critics is highly
appreciated.
-- Richard
On Monday 11 February 2008 16:47:42 Tom Ball wrote:
> Richard Gomes wrote:
> > On Sunday 10 February 2008 22:52:32 Tom Ball wrote:
> >> Richard Gomes wrote:
> >>> Hi Mike,
> >>>
> >>> Thank you for your directions.
> >>>
> >>> It should be very convenient to detect that ...
> >>>
> >>> @Rate double rate = 1.0;
> >>> @Volatility double vol = rate;
> >>>
> >>> .... cannot compile because the variables are semantically different,
> >>> nevertheless both are represented internally as floating point numbers.
> >>
> >> It had better compile, as annotations aren't supposed to change
> >> compilation behavior. Your error detector could certainly flag it as an
> >> error, however.
> >>
> >> Tom
> >
> > Hi Tom,
> >
> > JSR-308 is very interesting for our project because we are able to reach
> > very strong type checking whilst producing small, fast, clear, organized
> > and well documented code. More info at
> > http://www.jquantlib.org/index.php/DeveloperCorner
> >
> > In the future we will have to implement the annotation processor and
> > cause compilation errors wherever necessary.
>
> All of your work looks good, but you can't modify the behavior of
> Java-compatible compilers. JSR-308 gives error checkers additional
> support, but compliant Java compilers cannot change their behavior based
> on different annotation values. Now, there may be OpenJDK
> implementations which may do that in the future, but they can't be
> considered compatible with Java until the specification of Java changes
> to allow annotations to change compiler behavior.
>
> Tom
>
> Tom
--
Richard Gomes
http://www.jquantlib.org/
http://www.linkedin.com/in/rgomes
H:+44(870)068-8205
T:+44(77)9955-6805
More information about the JSR308
mailing list