[JSR308] Basic Problems (in Design?)

[Artemus Harper]

1. There is no need to do this because this is true:
ma.annotationType().equals(MyAnnotation.class);

2. Java has less boilerplate then c# does. In c# you have to keep track of
your own variables and property values, it allows more customization, but
allows programmers to do some rather dangerous things with annotations. What
you see documented in the javadoc for an annotated element is exactly what
you will get when you query it. Also note that java unlike .NET allows for
annotations within (different) annotations. You can create utility classes
to process the annotations as necessary, or possibly put some custom logic
into the enum values that are in the annotation.

On Thu, Oct 16, 2008 at 10:14 AM, Gaurav Vaish <gaurav.vaish at gmail.com>wrote:

> 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
>
>
>
>
>
> _______________________________________________
> JSR308 mailing list
> JSR308 at lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/jsr308
>
>


-- 
Artemus Harper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20081016/eed4683c/attachment.htm