[JSR308] Basic Problems (in Design?)
Artemus Harper
subanark at gmail.com
Thu Oct 16 15:04:05 EDT 2008
equals should work for annotations, I don't see why not. If it doesn't then
its a bug since the documentation for Annotation (
http://java.sun.com/javase/6/docs/api/java/lang/annotation/Annotation.html)
states exactly the way equals and hashCode should work. In fact equals
should even return true if you implement the annotation yourself and define
what those values return (provided you also implement equals to spec).
On Thu, Oct 16, 2008 at 11:52 AM, Eugene Kuleshov <eu at javatx.org> wrote:
> Gaurav,
>
> First of all, it doesn't seem like your particular issue is in scope
> of JSR-308.
> You are right that equals method in Proxy instance generated for
> annotation value does not work, but at this point changing it would
> create backward incompatibilities with previous Java releases. Though it
> seem a low risk incompatibility and you can try to open a bug report
> using regular Sun bug reporting system.
>
> Also note that instead of equals(), you can use "ann instanceof
> EdujiniAnnotation" or
> EdujiniAnnotation.class.isAssignableFrom(ann.getClass()) or even better
> use clz.getAnnotation(EdujiniAnnotation.class) to avoid creating of the
> unnecessary Proxy instances for annotations you are not be interested in.
>
> regards,
> Eugene
>
>
> Gaurav Vaish wrote:
> > 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://www.mastergaurav.com/>
> > http://dwt.sourceforge.net <http://dwt.sourceforge.net/>
> > http://www.edujini-labs.com <http://www.edujini-labs.com/>
> >
> >
> >
> >
> > On Thu, Oct 16, 2008 at 11:15 PM, Artemus Harper <subanark at gmail.com
> > <mailto: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 <mailto: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 <mailto:JSR308 at lists.csail.mit.edu>
> > https://lists.csail.mit.edu/mailman/listinfo/jsr308
> >
> >
> >
> >
> > --
> > Artemus Harper
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > JSR308 mailing list
> > JSR308 at lists.csail.mit.edu
> > https://lists.csail.mit.edu/mailman/listinfo/jsr308
> >
>
>
> _______________________________________________
> 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/c90348b7/attachment-0001.htm
More information about the JSR308
mailing list