Discussions

News: JSR 175 Annotation War Stories

  1. JSR 175 Annotation War Stories (28 messages)

    Cedric has stepped up to the plate, and has written up some nice information on using annotations. He has been working a lot with annotations recently, and he discusses shortcut notation, defaults, and multiple annotations.

    Conclusion
    After describing all these little annoying sides of JSR 175, I don't want to leave readers with the impression that the specification is flawed or unusable. Quite the contrary.

    I believe JSR 175 is going to change radically the way we program and I am betting that in a couple of years from now, all the Java source code we read and write on a daily basis will contain annotations.

    The syntax will undoubtedly look foreign to you at first sight, but I am confident that it will grow on you as you use it. It sure had this effect on me. Also, wait until we get some decent support for annotations in IDE's (code folding, coloring, etc...) and you won't even notice it's there any more.
    Read Cedric in JSR 175 war stories

    Threaded Messages (28)

  2. JSR 175 Annotation War Stories[ Go to top ]

    Although JSR 175 is prety goog in my opinion there are some small flaws:

    - @Overrides annotation is somewhat missused. It is better to have a reserved language keyword overrides (for example: public overrides String toString() { ... ) as in C#.
    Using annotation for that and requiring that compiler checks if method is realy overriden is unnatural and takes one line of code more.
    And @Overrides annotation is not required and methods can be overriden accidentaly.
    And yes, I know that the authors did not want to include new reserved language keyword, but I think they made mistake here.

    Mileta
  3. AOP as consumer[ Go to top ]

    Sorry for the repost, but just in case you missed it, we're doing some thigns around annotations and AOP: See my BLOG for more.
  4. Ugly syntax[ Go to top ]

    I found that the annotation syntax is very ugly... Anotations requires modifications in compilers. So it would be a lot better to add new keywords.

    If they keep the "@" stuff, then they should put it in the Javadoc comments. IDEs already support that. And it would requires no change in compilers as one could use the existing javadoc framework to implement them (implementation in compilers would be better).

    The proposed syntax requires changes in the compiler and in the Javadoc processor so they are documented in the generated documentation.

    I really hope that there will be a new proposed syntax.
  5. Ugly syntax[ Go to top ]

    Did you read the JSR FAQ on that subject
  6. Ugly syntax[ Go to top ]

    Yup, I did.

    From the FAQ :
    # Why didn't you use a new attribute keyword to declare annotation types?

    Given the huge number of Java programs already in existence, there is a great advantage to providing source compatibility. Many programs use attribute as an identifier, and those programs would no longer be legal. If fact, it would not have been possible to do this, as it conflicts with javax.print.attribute.
    I can undestand the argument. Introducing new keyword have a greater chance of causing incompatibilities. However, they are still not keeping source compatibility by putting annotations outside Javadoc comments.

    It would take a simple search a replace to fix source code that use the new reserved words (and you can have a compile switch to disable the new annotation keywords if you don't need them).

    Adding feature to a language by adding some new symbols will just make the language evolve into something that is unreadable. Imagine, if some other JSR want to add a feature and not use new keywords, it may propose the use of the "#" symbol, and then another will propose de "$" symbol and so on...
  7. Ugly syntax[ Go to top ]

    I can undestand the argument. Introducing new keyword have a greater chance of causing incompatibilities. However, they are still not keeping source compatibility by putting annotations outside Javadoc comments.
    Not sure what you mean, but source compatibility has been preserved 100% in JDK 1.5 (and it's been so since version 1.0 if I'm not mistaken), but maybe you have a different definition.
    It would take a simple search a replace to fix source code that use the new reserved words
    There is no such thing as a "simple search replace" when you have millions of lines of code out there.

    <blockoquote>
    Adding feature to a language by adding some new symbols will just make the language evolve into something that is unreadable. Imagine, if some other JSR want to add a feature and not use new keywords, it may propose the use of the "#" symbol, and then another will propose de "$" symbol and so on...There is nothing wrong with that as long as the feature that is being added is acknowledged as improving the language.

    --
    Cedric
    http://beust.com/weblog
  8. Ugly syntax[ Go to top ]

    Not sure what you mean, but source compatibility has been preserved 100% in JDK 1.5 (and it's been so since version 1.0 if I'm not mistaken), but maybe you have a different definition.
    As you said in your previous reply, source code compatibility has been broken once with the introduction of the assert keyword. I do not agree that the introduction of the assert keyword caused a lot of time and money in the industry. It did have an impact, but not a big as what you are implying. And there was also the case of the Swing API which moved from the "com.sun..." to "javax.swing...". That caused a bigger problem than the assert keyword. But then IDE had migration tools that did the job very well.

    And yes there is such thing as simple search and replace. And IDE can also make that easy with a migration tool. It may not solve all references to the new keyword (like if someone use introspection to access some attribute) but it will solve more than 99% of the cases. Also if you used the -1.4 compiler switch when compiling a module you would have no need to do the work unless you want annotation in that module (which is probably not a minor change in the module anyway).

    So the argument of preserving source-code compatibility sounds pretty weak to me.
  9. Follow ms C#[ Go to top ]

    I think we are mocing java in a wrong direction.
    I agree we could use @ java doc style for annotations.
    This new meta data tags just makes the code too hard to read, ans also requires compile changes.
    I would go ahead and use @ java doc tags if we want to implement this,
  10. Ugly syntax[ Go to top ]

    As you said in your previous reply, source code compatibility has been broken once with the introduction of the assert keyword.
    No, because you need a compiler switch to enable it.
    I do not agree that the introduction of the assert keyword caused a lot of time and money in the industry. It did have an impact, but not a big as what you are implying. And there was also the case of the Swing API which moved from the "com.sun..." to "javax.swing...". That caused a bigger problem than the assert keyword. But then IDE had migration tools that did the job very well.
    I don't know the size of the projects you are working on, but let me explain why I said that "there is no such a thing as 'simple search and replace'".

    Search and replace is pretty easy when you have one source line to support and that backward compatibility or backported fixes do not matter to you.

    As soon as you start branching the source code lines, this kind of sweeping change to the code base is *devastating*. Even the smartest IDE's won't help you when you need to backport fixes to a source that has undergone dramatic changes in structure and syntax.

    Fixing imports is a walk in the park compared to that.

    Anyway, the jsr175-comments email alias is still open, feel free to voice your concerns there and I am confident you will receive an answer. Even if you don't want to hear it :-)

    --
    Cedric
  11. Ugly syntax[ Go to top ]

    Cedric,

    Please, try to be consistent. You first say that the introduction of the assert keyword cost the industry a lot of time and money, then you say that it is not an incompatible change because of some compiler switch to enable it. If the change was compatible, it should not have cost the industry anything!

    Anyway, this thread has the potential of being endless so I'll just stop now :-)
  12. Wrong Direction[ Go to top ]

    Adding "@" is not just ugly, it's disgusting!

    If you have millions lines of code and you're so lazy migrating them - don't migrate then - you have to option! And have you ever heard of refactoring - every Java IDE has it today?!

    We should not let this syntactically beautiful language be a victim of laziness of certain developers! This is a high-level programming language, not an assembly one! You should not use such symbols such "@", "#", etc.

    Don't make Java pay, just because the majority of Java developers' focus is somewhere else at the moment! Don't let the big fans of assembly & unix syntax prevail! Keep the natural English-like syntax! No more "!@#$%^&"!
  13. Ungly Sintax[ Go to top ]

    Cedric, actualy since 1.1. Let´s not forget the so much missed scope operator:
    private protected :-) (the real equivalent to C protected)
  14. Ugly syntax[ Go to top ]

     So it would be a lot better to add new keywords.
    I believe you are in a very tiny minority if that's what you think.

    Adding new keywords comes to a very heavy price that neither Sun nor Java users are willing to pay without a *very* good reason.

    Just take a look at the chaos that ensued after the introduction of the "assert" keyword. Everybody agreed that it was worth it, but it cost a lot of time and money to the entire Java industry to adjust.
    I really hope that there will be a new proposed syntax.
    Mmmh... don't count on it. JSR 175 has been open for comments for several months now and we have received tons of feedback. Very little of it requested a new syntax, and the few that did were easily convinced about the good properties of the current syntax.

    --
    Cedric
  15. I fully agree with parent poster. The reason java succeeded in the first place was because it was "simple" and hence cut costs on development, training and maintenance. If you look around the industry, it’s very obvious that KISS principle (keep it simple and stupid) always succeeds (Windows??). Making java this difficult is only creating market opportunity for C# or other competitors.

    The parent poster also correctly questions how future changes should be incorporated in the language. Using a new symbol every time will definitely make it hard to read and maintain like C++. This is a very high impact decision and should not be made in haste. It would be good to agree on a common set of guidelines. For example, maybe Sun should decide that all future keyword additions would begin with @ symbol and add a keyword for annotations "@annotation". This will
    1. Keep the source compatibility
    2. Can be incorporated in coding guidelines
    3. Does not confuse the language as everybody understands that "@" symbol does not mean anything other than a keyword addition.

    Following this logic, if instead of "assert", we added "@assert" keyword, it would have been equally readable and would also have maintained the source compatibility.

    I am sure there are other ways to handle it. I suggest there is an "urgent" JSR to decide on this issue first before we go ahead and make these non intuitive changes to the language.

    Vinay
  16. Ugly syntax[ Go to top ]

    I believe you are in a very tiny minority if that's what you think.Adding new keywords comes to a very heavy price that neither Sun nor Java users are willing to pay without a *very* good reason.
    Well here's another voice from the "tiny" majority, it would have been MUCH better to add a new keyword (meta?) to language and disable it with a compiler switch than this horrendous, ugly, irritating thing you created.
  17. Ugly syntax[ Go to top ]

    I believe you are in a very tiny minority if that's what you think.Adding new keywords comes to a very heavy price that neither Sun nor Java users are willing to pay without a *very* good reason.
    Well here's another voice from the "tiny" majority, it would have been MUCH better to add a new keyword (meta?) to language and disable it with a compiler switch than this horrendous, ugly, irritating thing you created.
    Guys, where were you during the months when the JSR was in "public review" stage?!?

    --
    Cedric
    http://beust.com/weblog
  18. Ugly syntax[ Go to top ]

    I believe you are in a very tiny minority if that's what you think.Adding new keywords comes to a very heavy price that neither Sun nor Java users are willing to pay without a *very* good reason.
    Well here's another voice from the "tiny" majority, it would have been MUCH better to add a new keyword (meta?) to language and disable it with a compiler switch than this horrendous, ugly, irritating thing you created.
    Guys, where were you during the months when the JSR was in "public review" stage?!?-- Cedrichttp://beust.com/weblog
    Their comments are silly as far as syntax goes. Those of us who have been using XDoclet for years the syntax for JSR-175 is quite intuitive.

    One problem though with making JSR-175 part of the Java language rather than exposing them as doclet tags is that the adoption of JSR-175 will be quite slow. I still don't use assert in my programs because my code has to work on JDK 1.3 and JDK 1.4. So, it will be years before anybody can really use these doclet tags in many applications.

    I think a workaround for this would be to allow javac -source to be 1.5 be allow for -target 1.4. So, you could take a Java source file with annotations and compile it to JDK 1.4. This is doable because the bytecode format is compatible for annotations.

    $ javac -source 1.5 -target 1.4 Foo.java

    Then, change the AnnotationElement API to be static methods that take Method, Field, Class, and Constructor objects as parameters instead of using templates and such as they have now.

    public class AnnotationElement {
      public static Annotation getAnnotation(Method method, Annotation annotation);
    ...
    }

    Sure would save me the work of writing an annotation compiler that works with JDK 1.4. ;#)

    Bill
  19. The heart of the matter[ Go to top ]

    Now, isn't this the very core of what distinguishes the Java and the Microsoft camp...? In the Java World, "anyone" can contribute to the language and platform itself, thereby appealing to really ambitious and competent developers and architects who like, and are able, to work with the (oh so appealing) infrastructural, hardcore stuff.

    As for MS, I'm not saying that there aren't any competent developers working with .NET etc., BUT the language and platform is governed by one company, with a comparatively small amount of very competent people, that makes fast decisions on changes to the language and platform, always with sales and market position overruling the developers' need for becoming a part of development history and improving the wheel.

    Thus, leaving the preference debate aside, I think there is one important note to make. Since we all in the Java camp, and on TSS in particular, consider ourselves competent, and probably all can back up our claims with real-life experience and impressive CVs, and want to contribute to the language and platform we apparently appreciate so much, I think that there is a need to be more aware of that we are all working for one common goal (besides making ourselves and our companies successful) even though we might have different ideas of how to get there.

    Realizing that, and the main reason why probably most of us are attracted to Java in the first place, it's also important to understand that there will never be one perfect solution without flaws or compromises AND that we need to respect each others' work and be restrictive in dealing out hard judgements and emotionally negative statements. If we cannot prevent ourselves from doing that, we might as well give up the idea of one unified platform and, each one of us, set off to invent the wheel in extremus and create our own version of the Java language. While Mr Gates & Co are collecting their ever incresing pay cheques at the bank...

    Peace

    /Par
  20. Ugly syntax[ Go to top ]

    I've been clamoring about this for awhile. I don't propose any additional keywords but I think all the metadata, javadoc, etc. should be expressed using XML (sort of going beyond C#) allowing of course for some backword compatibility. Why? Well, for one can you say introspection?
  21. Ugly syntax[ Go to top ]

    I've been clamoring about this for awhile. I don't propose any additional keywords but I think all the metadata, javadoc, etc. should be expressed using XML
    It's exactly what we've been doing for five years and now we know how wrong it is. It's not just that XML is not a human-readable format, it's just that it introduces way too many redundancies when used to decorate Java elements.

    Any metadata added to Java elements should be specified in a Java source.
     Well, for one can you say introspection?
    It's a complex word, but yes, I can say it. But its connection to XML? No idea... Can you expand?

    --
    Cedric
    http://beust.com/weblog
  22. Ugly syntax[ Go to top ]

    I think you misunderstood what I was saying - I don't mean specifying metadata and comments in separate XML files, I meant within the Java source like this:

    http://msdn.microsoft.com/msdnmag/issues/02/06/XMLC/default.aspx
  23. Ugly syntax[ Go to top ]

    I think you misunderstood what I was saying - I don't mean specifying metadata and comments in separate XML files, I meant within the Java source like this:http://msdn.microsoft.com/msdnmag/issues/02/06/XMLC/default.aspx
    Ugh.

    Untyped, hard to read, can't be validated by javac...

    What are the advantages of this approach over JSR 175?

    --
    Cedric
  24. Ugly syntax[ Go to top ]

    Well, here's some code your Weblogic Integration tool generated, I think "@" is extraneous and can be replaced. We are going to have XML somewhere or another regardless.


    /**
     * This is the default controller for a blank web application.
     *
     * @jpf:controller
     * @jpf:view-properties view-properties::
     * <!-- This data is auto-generated. Hand-editing this section is not recommended. -->
     * <view-properties>
     * <pageflow-object id="pageflow:/fbWeb/concessionCarts/ConcessionController.jpf"/>
     * <pageflow-object id="action:begin.do">
     * <property name="x" value="100"/>
     * <property name="y" value="40"/>
     * </pageflow-object>
     * <pageflow-object id="action:concessionWrite.do#fbWeb.concessionCarts.ConcessionController.ConcessionWriteForm">
     * <property value="340" name="x"/>
     * <property value="200" name="y"/>
     * </pageflow-object>
     * <pageflow-object id="action-call:@page:concessionInput.jsp@#@action:concessionWrite.do#fbWeb.concessionCarts.ConcessionController.ConcessionWriteForm@">
     * <property value="136,220,220,304" name="elbowsX"/>
     * <property value="192,192,192,192" name="elbowsY"/>
     * <property value="East_1" name="fromPort"/>
     * <property value="West_1" name="toPort"/>
     * </pageflow-object>
     * <pageflow-object id="page:concessionInput.jsp">
     * <property value="100" name="x"/>
     * <property value="200" name="y"/>
     * </pageflow-object>
     * <pageflow-object id="page:inputComplete.jsp">
     * <property value="560" name="x"/>
     * <property value="200" name="y"/>
     * </pageflow-object>
     * <pageflow-object id="forward:path#index#concessionInput.jsp#@action:begin.do@">
     * <property value="100,100,100,100" name="elbowsX"/>
     * <property value="84,120,120,156" name="elbowsY"/>
     * <property value="South_1" name="fromPort"/>
     * <property value="North_1" name="toPort"/>
     * <property value="index" name="label"/>
     * </pageflow-object>
     * <pageflow-object id="forward:path#success#inputComplete.jsp#@action:concessionWrite.do#fbWeb.concessionCarts.ConcessionController.ConcessionWriteForm@">
     * <property value="376,450,450,524" name="elbowsX"/>
     * <property value="192,192,192,192" name="elbowsY"/>
     * <property value="East_1" name="fromPort"/>
     * <property value="West_1" name="toPort"/>
     * <property value="success" name="label"/>
     * </pageflow-object>
     * <pageflow-object id="forward:path#failed#begin.do#@action:concessionWrite.do#fbWeb.concessionCarts.ConcessionController.ConcessionWriteForm@">
     * <property value="304,220,220,136" name="elbowsX"/>
     * <property value="192,192,32,32" name="elbowsY"/>
     * <property value="West_1" name="fromPort"/>
     * <property value="East_1" name="toPort"/>
     * <property value="failed" name="label"/>
     * </pageflow-object>
     * <pageflow-object id="control:fbControls.support.db.Inventory#inventoryCtrl">
     * <property value="40" name="x"/>
     * <property value="40" name="y"/>
     * </pageflow-object>
     * <pageflow-object id="control:fbControls.controls.ConcessionCVS#cart">
     * <property value="20" name="x"/>
     * <property value="40" name="y"/>
     * </pageflow-object>
     * <pageflow-object id="formbeanprop:fbWeb.concessionCarts.ConcessionController.ConcessionWriteForm#concessionCartID#java.lang.String"/>
     * <pageflow-object id="formbeanprop:fbWeb.concessionCarts.ConcessionController.ConcessionWriteForm#qtySold#java.lang.String[]"/>
     * <pageflow-object id="formbean:fbWeb.concessionCarts.ConcessionController.ConcessionWriteForm"/>
     * </view-properties>
     * ::
     */
  25. Ugly syntax[ Go to top ]

    Well, here's some code your Weblogic Integration tool generated, I think "@" is extraneous and can be replaced. We are going to have XML somewhere or another regardless.
    Oh sure, no argument there. XML should never be in the face of programmers, that's all.

    XML is like Postscript. It should only be read and written by software, never by humans.

    --
    Cedric
  26. Ugly syntax[ Go to top ]

    XML is like Postscript. It should only be read and written by software, never by humans.-- Cedric
    Huh?! So you prefer Websphere's gibberish XMI files and dislike Hibernate's readable xml files?

    Ara.
  27. Ugly syntax[ Go to top ]

    XML is like Postscript. It should only be read and written by software, never by humans.-- Cedric
    Huh?! So you prefer Websphere's gibberish XMI files and dislike Hibernate's readable xml files?Ara.
    "Readable XML" is an oxymoron :-)

    I stand by my analogy of XML and Postscript. Any metadata that is tied to a Java element (class, method, field, etc...) belongs in the source.

    It should be overridable at deployment time, but for development, it needs to be in the source.

    --
    Cedric
    http://beust.com/weblog
  28. I put this here to connect this discussion with the thread in http://www.theserverside.com/news/thread.tss?thread_id=25448#119529

    Bellow you can see some fragments from the thread...

    [Glauco wrote]
    We can extend the language to include invariant expressions for classes and modules, and pre- and post-condition expressions for functions and methods. With this Java will support 'Design by Contract', beyond "a simple assertion facility" look at: http://developer.java.sun.com/developer/bugParade/bugs/4449383.html

    [Brian Miller wrote]

    Luscious! Now you're talkin' high quality software, the kind of software I can trust. The possibility of DBC encoded as metadata proves to me that Java annotations is a great concept. Annotations provide the most extensibility to Java, in a way very similar to XML. And an XML document can be the content of a Java annotation.

    I checked the BugParade 4449383, and Sun's evaluation of it says that DBC depends on JSR-199, which aims to publicize the javac package's entry point. Sun's evaluation doesn't consider metadata! Elsewhere on the bug ticket, an astute surfer added a remarking about this missed opportunity. Sun should jump on metadata for DBC instead of creating Java keywords. If you have a spare bug vote, visit it's ticket.

    ** Anyone knows how to start a campaign to put DBC in Java using metadata (jsr 175)?
    Annotated DBC deserves its own JSR. Until then maybe someone wants to start a SourceForge project?
  29. Ugly syntax[ Go to top ]

    My opinion was based on the assumption that people will be developing via tools such as Eclipse or Weblogic Workshop. These tools can encapsulate the metadata syntax from the user. Were metadata/comments expressed in XML then this would reduce the number of languages/syntaxes required, it would allow tools to introspect code in a more simplistic manner (a tool could extract all the future metadata and treat it as fragments in one large document or perform XSL translations, etc.). However, I realize the need to support the text editors and unlike Microsoft we can't just assume that everyone has to use DevStudio.