For further consideration...

David Goodenough david.goodenough at
Tue Mar 31 01:35:39 PDT 2009

On Monday 30 March 2009, Mark Thornton wrote:
> David Goodenough wrote:
> > 5 years as near to indefinitely as matters).  I need compiler
> > checkability for field references now.
> Define an annotation
> @interface @fieldReference {
>     String name();
> }
> class MyClass {
>     @fieldReference("myField") static FieldRef FIELD_REF;
>     static {
>        // use reflection to set initialise static fields with
> @fieldReference annotations
>     }
> }
> You could use an annotation processor to verify that the @fieldReference
> named valid fields and was attached to a suitable reference field. There
> are probably other ways of doing this, but it does give you the compile
> time check you want without requiring a language change.
> Regards
> Mark Thornton

My first instinct when I read this was that this was another example of 
moving the problem to a better place (the place where the field originates
rather than the place where you use it) but that it was still uncheckable. 

But then you suggest using the annotation processor to do the verification
process, and that does seem to answer the question.  Its odd that none
of the potential users of this (Binding frameworks, Criteria like APIs, and
PropertyChangeSupport) have used this approach which makes me a 
little suspicious.

The only niggle that strikes me immediately is that existing beans will
not be suitably annotated, and this includes all the Swing screen widgets
(subclassing or a helper class can solve that as it is a well defined set)
and classes built by schema scrapers from places like existing SQL
databases, or from XML schemas.  These would have to have these added
manually, or the tools that do the extraction would have to be modified.
But that is not a show stopper, its just a little extra work to be done.

I will have to try this and see if it solves the problem.  If it does then I
will happly withdraw my proposal, and stop getting in everyone's hair.


More information about the coin-dev mailing list