[JSR308] Basic Problems (in Design?)

[Gaurav Vaish]

Hi,

I have been working with both Java since 1999 and .Net since 2000. Though I
don't want to compare them, but both have evolved learning from each other.

And though Annotations is a great welcome, I still do not appreciate the way
they have been taken up in Java.

Few problems:

1. Since the instances of Annotations are available through reflection
(getAnnotations method), I would love if the following held true:

    public @interface MyAnnotation { ... }

    @MyAnnotation public class ABC { ... }

    MyAnnotation ma = getMyAnnotationAtClassABC(...);

    *ma.getClass().equals(MyAnnotation.class);  *// I want this to be true

    *Reason: *The best advantage that we get is... suppose I need to keep a
track of the annotations added, I can keep a Map<Class, Instance> and then
directly say map.put(ma.getClass(), ma). This will ensure that my code is
forward compatible.

   I am (infact, my company is) - not sure about others - in great need to
his feature and my Web 2.0 (Ajax based) application heavily relies on
annotations for JSON Serialization/Deserialization. Annotations have helped
me make my serializer quite generic... but still has to rely on several "*
instanceof*" ensuring that my code if forward compatible.

2. And I still wonder - it will be great if somebody can explain or point me
to the rationale - why the "interface" and "proxy" route has been chosen.

   I would again love to have *"classes" working as attributes*, like how it
is available in .Net.

   *Reason*: Related functionality can be encapsulated in the
attribute-class itself.

   *Example*: I want to have an attribute-driven validation framework. I
create a base, may be abstract class, Validator that has a method
doValidate. And then to use as annotation, I create an annotation
ValidatorAnnotation that has a method createValidator. May be this
annotation is abstract. Implementations can inherit from it and implent
createValidator method. Any initialization that is required for the actual
validator is now encapsulated in the sub-class rather than requiring me to
create another class to instantiate the validator.

  Add to it the problem mentioned in (1) and the pain problem of the
developers should be well visible.

  If need be I can post here some real case-studies (code) as to what we
(the developers) do now and what fantastic thing we can have with just these
two features available.

  And as I write this, I see some interesting thought provoking postings at:
    https://lists.csail.mit.edu/pipermail/jsr308/2008-October/000482.html
    https://lists.csail.mit.edu/pipermail/jsr308/2008-October/000483.html


--
Happy Hacking,
Gaurav Vaish
http://www.mastergaurav.com
http://dwt.sourceforge.net
http://www.edujini-labs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20081016/19371b00/attachment.htm