[JSR308] Basic Problems (in Design?)
Gaurav Vaish
gaurav.vaish at gmail.com
Thu Oct 16 14:36:36 EDT 2008
Hi Artemus,
Thanks for the quick response.
*I am sorry but your first response seems wrong*.
Here's my quick test:
@Retention(RetentionPolicy.RUNTIME)
public @interface EdujiniAnnotation
{
String name();
int index() default -1;
}
@EdujiniAnnotation(name = "Alpha")
public class AnnotationTest
{
public static void main(String[] args)
{
System.out.println("Java Version: " +
System.getProperty("java.version"));
System.out.println("Java Version: " +
System.getProperty("java.vendor"));
Class clz = AnnotationTest.class;
Annotation[] allAnnots = clz.getDeclaredAnnotations();
for(Annotation ann: allAnnots)
{
System.out.println("Annotatiton: " + ann.getClass().getName());
System.out.println("Equality: " +
ann.getClass().equals(EdujiniAnnotation.class));
}
}
}
Output:
Java Version: 1.6.0
Java Version: Sun Microsystems Inc.
Annotatiton: $Proxy1
Equality: false
I know this is not going to work... since it is THE reason as to why I have
a bunch of "instanceof" checks.... a bit pain in the....
Regarding the second item... I would be anxious to know about the "rather
dangerous things" allowed.
And yeah... .Net also allows Annotations with different Annotations. Infact,
the annotation AttributeUsageAttribute is THE way to specify restrictions on
the usage (similar to the annotation Target).
Infact, I see the .Net Attributes several magnitudes more powerful than Java
Annotations which - at least to me - seem like a kid still learning to
crawl. Apologies if it hurts, but that's my view.
--
Happy Hacking,
Gaurav Vaish
http://www.mastergaurav.com
http://dwt.sourceforge.net
http://www.edujini-labs.com
On Thu, Oct 16, 2008 at 11:15 PM, Artemus Harper <subanark at gmail.com> wrote:
> 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/20081017/53e3540b/attachment-0001.htm
More information about the JSR308
mailing list