[JSR308] Basic Problems (in Design?)
Gaurav Vaish
gaurav.vaish at gmail.com
Thu Oct 16 22:41:00 EDT 2008
Hi Rémi,
Thanks for the piece of information. I did help.
Thanks Eugene, for your response. But what I was looking for is the exact
class-name / class-instance rather than isAssignableFrom
Thanks Artemus, for pointing me to annotationType() method. I think I missed
it out. I think that should serve my purpose.
All,
btw, any chances of looking into inheritance in Annotations. And, do you
think anytime in future along with @interface, we may also have @class to
support class-based Annotations rather than only interface-based? The reason
is I would related items to be encapsulated in one class, like in .Net (C#
or VB.Net or whatever).
Rather than first having an annotation and then a class that hunts for it
and then another class that picks-up the values and processes them, I would
rather have individual annotations initialize themselves in their own way...
getAnnotationByClass(MyAnnotation.class).initialize() and let them get
initialized in the way that they are interested in.... or else the
processing (business logic processing rather than annotation processing)
chain belong a little too long.
Again, if need be I can post a sample case-study to support the need for
this (open a bug?).
-Gaurav
On Fri, Oct 17, 2008 at 12:53 AM, Rémi Forax <forax at univ-mlv.fr> wrote:
> Artemus, Eugene, if you take a look to the code equals() is called on
> the annotation class
> (getClass().equals()) not on the annotation itself.
>
> Gaurav, annotations in Java are interfaces not classes to avoid
> a common mistake in C# that consist to embed the code that react to an
> annotation
> directly in the annotation.
> In Java, annotations are kind of spec and doesn't suppose a peculiar
> implementation.
> Moreover, if you want to get an annotation of a specific type, it's
> better to use :
>
> http://download.java.net/jdk7/docs/api/java/lang/reflect/AnnotatedElement.html#getAnnotation(java.lang.Class)<http://download.java.net/jdk7/docs/api/java/lang/reflect/AnnotatedElement.html#getAnnotation%28java.lang.Class%29>
>
> in you example:
> MyAnnotation annotation=ma.getClass().getAnnotation(MyAnnotation.class);
>
> cheers,
> Rémi
>
> Artemus Harper a écrit :
> > 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
> > <mailto: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>
> > > <mailto: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>
> > <mailto: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>
> > <mailto: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 <mailto:JSR308 at lists.csail.mit.edu>
> > > https://lists.csail.mit.edu/mailman/listinfo/jsr308
> > >
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20081017/22ed558e/attachment-0001.htm
More information about the JSR308
mailing list