Discussions

News: Discussion: JSR 175, metadata and compile-time dependency issues

  1. Cedric Beust just blogged about some potentially ugly JSR 175 coupling issues with Java code in terms of compile-time dependencies. Perhaps this is a problem that can be solved via the JSR itself using metadata to qualify metadata.

    My perspective on this is that there will always be different kinds of annotations.

    a) One kind of annotation will merely be information that is always dismissible. A UML design tool's annotations for generated code that help round-tripping back into and syncing with the UML model are dismissible. You should be able to go to release and production without ever missing any necessary behavior even if the annotation library is missing. Javac could really ignore these kinds of annotations.

    b) Another kind of annotation will be information that adds valuable semantic information to the class/method/property/field under advisement, but could potentially be ignored. Meaning that the compiled code could still continue to be used at the cost of losing those semantics. Transactional and persistence mapping information (scary as it may sound) might fit that bill. Javac should issue warnings stating that intended behavior will not be realized.

    c) There can be yet another kind of annotation that can break the class if the annotation code cannot be located at compile time. In this case, the annotation is as important as the rest of the code itself. In other words, the base code itself is worthless without the annotations. Consider an MVC framework that annotates controllers, commands and actions with information that is typically stored as XML. In this case, the framework cannot make sense of these classes without those annotations.

    Technically speaking, this "difference" in the way that javac interprets annotations is something that easily be built into the annotation itself. Why not have a "meta" tag for the original meta tag definition that defines how javac should interpret the annotation.

    Extending Cedric's example (Note that I haven't a clue as to what JSR 175-based code looks like, so I am winging this):

    For,

    @SessionTag(
      ejb-name = "statelessSession"
    )
    public class TraderEJB implements SessionBean
    ....


    the @Session tag could be defined as:

    @AnnotationType (
    compile-time-dependency-response = "<ignore | warn | error>"
    )
    public class Session implements Annotation
    ....

    Using appropriate tag values of "ignore", "warn" or "error", the *tag developer* could incorporate valuable information that the compiler could use to respond to compile-time dependency issues.

    In fact, considering the necessity for division of roles in Java-based development, who better to determine how javac should interpret the annotation than the developer of the
    annotation? Using a javac command line option would merely pass on the responsibility to the developer, who might be recompiling the annotation library as part of his build process and forget to use the right option.

    What do you think?

    Sandeep.

    Threaded Messages (32)

  2. .NET[ Go to top ]

    How does .NET handle these sorts of issues?

    Does .NET allow users to develop and incorporate their own metatags?

    Or are there only a finite set of metatags, whose semantics are known to the C# compiler?
  3. .NET[ Go to top ]

    How does .NET handle these sorts of issues?

    >
    > Does .NET allow users to develop and incorporate their own metatags?
    >
    > Or are there only a finite set of metatags, whose semantics are known to the C# compiler?

    You can define your own metatags (or attributes as they are called). There is an "AttributeUsage" meta-metatag that lets you define what the attribute can apply to (as in class, field etc) - sort of like a pointcut.

    This article did a pretty good job of summarizing .Net attributes.

    However, in .Net, compile-time dependencies for attribute code are always checked and verified.

    Note: To interpret a tag, the actual declaraton information describing how the tag can be used, is required. So if you need to use the tag, then you need to reference the library or the code where the tag is described/implemented.

    My post relates to situations when you really don't care about attributes that might have made its way into your code (say from another tool), or want to ignore them temporarily, but you do NOT want to remove them.

    In fact, I think this way, you can actually make metadata in classes truly non-intrusive.

    Sandeep.
  4. "Non-intrusive"[ Go to top ]

    In fact, I think this way, you can actually make metadata in classes truly non-intrusive.


    When I use the term "non-intrusive" I only mean to say that the metadata can be used if required, but will not break (at compile/run time) your code if you don't want it to.

    Sandeep
  5. .NET[ Go to top ]

    @AnnotationType (
    compile-time-dependency-response = "<ignore | warn | error>"
    )


    This feels very sloppy to me. If I am looking at the complete source code for an application, and that application has a compile-time-dependency-response of 'warn', I can not predict how the application will behave unless I am able to look into the compiler log (same applies to Cedric's ignore-attributes flag). If the flag is set to 'ignore,' even the compiler log won't help me.

    My post relates to situations when you really don't care about attributes that might have made its way into your code (say from another tool), or want to ignore them temporarily, but you do NOT want to remove them.

    I don't think metadata should be used in this situation. I think it would be better to take your attribute behavior, and code it as advice. Then use an external pointcut definition (or pointcut language) to decide whether or not you want to apply the advice.

    Now, if I want to determine whether advice is applied to the class, I simply need to look at the pointcut definition instead of trying to hunt down the correct compiler log. (Furthermore, an AOP-enabled IDE can make it readily apparent whether the advice is being applied) This feels like a more structured definition of how the code will behave.
  6. Yes, but is it standardized?[ Go to top ]

    Then use an external pointcut definition (or pointcut language) to decide whether or not you want to apply the advice.


    Yes this would be great. But how I don't recall any proposals to make external pointcut definitions part of the standard Java package. So, as far as a generic solution goes, we are essentially stuck with JSR 175.

    And consequentially, what do you if you are dealing with tags that it makes sense to leave in with the code, but you don't want interrupting your compile cycle with dependency checks. The use of UML-targeted tags that tie back into a class model, for the purposes of fast round tripping, is a real enough example of this situation.

    Sandeep
  7. It's runtime attribute dude[ Go to top ]

    In my opinion:
    - a *Runtime* attribute should always be available during compilation. The code breaks if it's not there, the attribute class is used in the code, it's part of the dependencies. Transaction settings or ORM stuff are indeed runtime attributes.
    - other attributes such as a uml annotation are not *Runtime* attributes at all. The attribute class is not used in the code itself at all. It just marks something and then those attributes are used for generating a uml diagram or whatever. You don't need them at all when you're running the application.

    So since JSR175 is about *Runtime* attributes naturally javac should reports a compilation error when a runtime attribute is not there. Another possibility is to make distinction between the two useage types in JSR175.

    Ara.
  8. It's *not* runtime attribute dude[ Go to top ]

    Ara:
    So since JSR175 is about *Runtime* attributes


    No, JSR 175 is not just about Runtime, it supports three types of retention: SOURCE, CLASS and RUNTIME.

    --
    Cedric
  9. It's *not* runtime attribute dude[ Go to top ]

    <Cedric>
    No, JSR 175 is not just about Runtime, it supports three types of retention: SOURCE, CLASS and RUNTIME.
    </Cedric>

    Ah ok. I haven't read the spec at all. So if SOURCE attributes are not needed in runtime then no need to put the jar file containing the class, but for RUNTIME/ClASS we should. And all these types have the same syntax? That's tricky, you can't figure out a tag is of which type. If you don't report an error when a RUNTIME attribute class is missing you may confuse the user because later a class deep in your code will report a weird ClassDefNotFoundException out of nowhere. If you do report errors then you have to put the jar file containing TogetherJ's UML attributes in your classpath, even though you don't need it at all! I think @Transaction syntax for runtime tags and @@UmlClass for SOURCE tags is probably a good idea. Otherwise I think javac should always report erro during compilation, although in runtime you don't really need the jar file and so you don't include uml SOURCE attributes when you release the application.

    Ara.
  10. .NET[ Go to top ]

    This feels very sloppy to me. If I am looking at the complete source code for an application, and that application has a compile-time-dependency-response of 'warn', I can not predict how the application will behave unless I am able to look into the compiler log (same applies to Cedric's ignore-attributes flag). If the flag is set to 'ignore,' even the compiler log won't help me.



    "Warn", Corby, is probably the most dicey option of the lot. I threw it in there for completeness.

    However, in general, it make sense that this sort of control be added to the metadata application process. Not having the control is OK when your metadata is targeted at qualifying compile time, runtime or deployment behavior.

    However, if not, (let's say its targeted at code generators, or tag-aware IDEs) then I see no reason why compile time dependency checks ought to be enforced.

    Sandeep
  11. I've never heard of JSR175 and I do not like the idea that code comments are causing my perfectly valid java code to not compile. All the peripheral technology extensions must be made in such a way that they do not impact basic code compiling, something with which everybody is familiar with.
  12. Difference between JSR 175 and JSR 40[ Go to top ]

    These two JSR look the same, can anyone give a quick difference between the two. Are we re-inventing the wheel?

    -----------------------------------------
    http://javaRSS.com
    Just one bookmark - for all java related news, articles and blogs.
    -----------------------------------------
  13. What is going on here?[ Go to top ]

    Lets copy&paste weblog statement:

    This file will not compile unless you have the EJBGen annotations (com.bea.wls.ejbgen.annotations.*) in your classpath. You have just tied yourself to a tool.

    What compile is being talked about here?

       -- Java (javac)
       -- EJB compile (ejbgen)

    I absolutely do not see how metadata may interfere with compilation. Specially
    this example will really raise many eyebrows -- I mean where is the separation
    of following concerns (application code vs platform code)

       -- Interface/inheritance/typing (compile time)

       -- Attribute/aspect (post compile time)

    Soumen Sarkar.
  14. What is going on here?[ Go to top ]

    \Soumen Sarkar\
    Specially this example will really raise many eyebrows -- I mean where is the separation
    of following concerns (application code vs platform code)

       -- Interface/inheritance/typing (compile time)

       -- Attribute/aspect (post compile time)
    \Soumen Sarker\

    Alot of indiviudals in this thread have referenced the JSR in terms of seperation of concerns and AOP.

    I have to ask - why?

    The information on the JSR I've read is pretty clear - it's a meta-data facility. You can declare extra-language "stuff" in your source files. That's it.

    I don't see any attempt in the JSR to be AOPish, or to seperate anything - in fact, the point of the JSR is IMHO to tie your source purposefully to an external tool or facility. Quite the opposite of AOP. Perhaps Jboss and other AOP posts thither and yon have confused the issue, but on its face JSR 175 is about as far as you can get from AOP or seperating out concerns. The JSR is about codifying meta-data, and as a (highly desirable side effect) banishing a number of trauma-inducing XML files.

    Personally, I don't see a problem here, or Cedric's point to be honest. By using meta-data you're purposefully tying yourself into some external facility.
    Having it checked at compile time is one of the bonuses over the Javadoc style.

    This ties back to comments I've made before - meta-data is not going to rock people's world. It's going to feel alot like EJB in practice, just with alot less files :-) If you want AOP, then use an AOP package. Don't look to meta-data to magically do it for you (or, if you really desperately want magic, pray to the JBoss Gods and hope they deliver!).

        -Mike
  15. What is going on here?[ Go to top ]

    Mike:
    the point of the JSR is IMHO to tie your source purposefully to an external tool or facility.


    Not necessarily purposefully. Imagine that you and I work on a common project and I send you an EJB for debug or for sharing. I use EJBGen, you don't. You won't be able to compile my file unless you download EJBGen, for which you have no use.

    Personally, I don't see a problem here, or Cedric's point to be honest.


    I hope it's clearer now.


    This ties back to comments I've made before - meta-data is not going to rock people's world.


    I think it's going to have a much deeper impact than that. I can see a world where most of the Java files you see every day contain a lot of metadata, most of which you have no use nor understanding for.

    --
    Cedric
  16. Metadata is going to have impact[ Go to top ]

    <Mike Spille>
    meta-data is not going to rock people's world
    </Mike Spille>

    I believe code metadata is indded going to rock. The reason being interface/
    inheritance/typing has its use in information classification
    (category calculas). However, this classification is in terms of computational
    ontology and attributes offer an way to escape from an ontological domain.
    How the ontological separation of concern is used is semantic/system
    building richness (no syntactic mechanism can yet replace that).

    Do not narrow your focus on AOP. That is just one application. I see
    documentation extraction as another application. I can see other application
    based on attributes and heuristics.

    I repeat, attributes are a nice syntactical mechanism to bring discipline
    in conveying whatever is extra-syntactical. How you use that is your business.

    Soumen Sarkar.
  17. Metadata is going to have impact[ Go to top ]

    Yes, but that still doesn't strike me as worth of any world-rocking. "a nice syntactical mechanism to bring discipline in conveying whatever is extra-syntactical" is just that, nice. But proponents of inline metadata treat it as if it were the second coming of who knows what. Here's what I see coming out of the new metadata mechanism, based on what I've seen in the .NET world:
    1) A poor-man's AOP.
    2) A lot of people using it to do things that sound cool at first, but end up costing a lot from a maintenance and reusability standpoint due to unexpected coupling issues.

    I think metadata sounds nicer at first than it really is in practice, and that's based upon my own experience with it in practice. Believe me, I was wowed by it when I first started working in .NET, and now I'm pretty much over it except where it absolutely gives me something of value that I couldn't get any other way.
  18. Metadata is going to have impact[ Go to top ]

    Sure I agree with you. The whole mantra of attribute is that there is
    divide between "application code" and "platform code" and the platform
    code is powerful(does quite a lot of useful things), standard (by
    market dominance) etc etc. For example IIS is a powerful, standard platform
    whose advantage could be taken by .NET code with metadata.

    To get back to this thread:

    Metadata causing compilation error -- I am sorry I can't agree with this.
    After all in Java, compilation and run is blurred. Are we just talking about
    one mode of producing bytecode with metadata?
  19. What is going on here?[ Go to top ]

    I see your point, but I suppose I'm looking at Meta-data a different way.

    In the current world, if I give you some source that imports x.y.z and uses something in it, butI fail to give you the jar that contains x.y.z, then you're dead in the water.

    Likewise with the JSR, if I give you some source code containing meta-data from x.y.z, but I fail to give you the jar that contains x.y.z, then you're toast too.

    My point here is that meta-data is _not_ a seperation of concerns. You can't use EJBGen metadata, or ACME Metadata, and expect to ship that source off to someone who doesn't have EJBGen or ACME. If you could do such a thing, then meta-data would in effect become free-form and in most ways no better than the javadoc method today.


    \Cedric Beust\
    I think it's going to have a much deeper impact than that. I can see a world where most of the Java files you see every day contain a lot of metadata, most of which you have no use nor understanding for.
    \Cedric Beust\

    It seems awfully neat and promising in the abstract, but in reality it's just another feature with limited uses. The reason you're _not_ going to see "most of the java files you see every day contain[ing] a lot of metadata" is that developers will learn quickly that lots of meta-data in lots of files is unmaintainable. Developers will learn that they're losing encapsulation, losing modularity, that when they attempt this their carefully seperated software layers start compressing into fewer layers. A world where most Java files have lots of meta-data is, conceptually, the same world where you have a class with 80 methods.

    What I believe you'll find is that overuse of meta-data will be another of those "smell" things that Martin Fowler admirers like to point out. :-)

        -Mike
  20. What is going on here?[ Go to top ]

    <mike>
    In the current world, if I give you some source that imports x.y.z and uses something in it, butI fail to give you the jar that contains x.y.z, then you're dead in the water.

    Likewise with the JSR, if I give you some source code containing meta-data from x.y.z, but I fail to give you the jar that contains x.y.z, then you're toast too.
    </mike>

    One of those moments when I agree with Mike. I frankly don't see Cedric's concern too. Metadata (as we use it in both Java and .NET) is integral part of system's source code, if you will. Having only part of it and not having the whole naturally leads to compilation errors :-)

    Regards,
    Nikita.
    Fitech Labs.
  21. What is going on here?[ Go to top ]


    > I think it's going to have a much deeper impact than that. I can see a world where most of the Java files you see every day contain a lot of metadata, most of which you have no use nor understanding for.
    >
    > --


    That is exactly has been my concerns lately.. code cluttered with annos.
    using simple text editors would be utterly useless.

    dm
  22. What is going on here?[ Go to top ]

    Soumen:

    What compile is being talked about here?
    >
    > -- Java (javac)
    > -- EJB compile (ejbgen)
    >
    > I absolutely do not see how metadata may interfere with compilation.


    Because the metadata is now imported as a regular Java package, so if you don't have it, javac will fail.

    --
    Cedric
  23. Because the metadata is now imported as a regular Java package, so if you don't have it, javac will fail.

    >
    > --
    > Cedric


    I think that some people, including myself, are quite confused about how JSR 175 is going to work. Could you please provide more information about it (or better still, get a spec out into the JCP) so we can have a more fact-based discussion? For example, I don't understand why metadata needs to be imported as a regular Java package (can't the compiler simply read the metadata and add it to the class file?). I don't know what basis the expert group has made this decision on. And I don't understand the process by which this metadata is going to be used by tools - do they tie in with javac somehow or are the files modified post-compile?

    If you could help elucidate any of these issues, I and others here would be grateful.

    Richard
  24. I think that some people, including myself, are quite confused about how JSR 175 is going to work.

    No joke. I don't understand how it is possible to hold a meaningful conversation about a language feature which has no publicly available documentation. Gafter (Sun's compiler writer) said he'd include the spec when he sends out the next beta compiler release, but that has yet to happen.

    As far as usability is concerned, right now I just need some simple tags for some aspecting I'm doing. I understand how pointcuts are more flexible, but frankly, there are just situations where it makes much more sense to tag classes then it does to individually list them all out in a pointcut. Both pointcuts and metadata are good - just differently.

    God bless,
    -Toby Reyelts
  25. Availability of the specification[ Go to top ]

    We are almost done with the public draft, so JSR 175 will enter public review very soon (and a special note for those of you who are part of the JCP: the draft is already available for community review).

    --
    Cedric
  26. compile-time dependence[ Go to top ]

    http://www.jcp.org/en/jsr/detail?id=220

    urmm, why would you need to import BEA specific meta-tags when EJB3.0 will defines a standard set for you.
  27. I've used the equivalent attributes in .NET, and have also created my own for use. The problem is, these things are really code dependencies of a different sort, the same as making a class implement an interface of some sort. Consider that in .NET, you can mark a class as serializable by either making it implement ISerializable or by marking it with the "[Serializable]" attribute. In either case, your class needs to "import" (using "using") the appropriate classes in its header, and your compiler needs to have a reference to the package in question (I think in this case it's "System.Runtime.Serialization", though I could be wrong).

    I think that while attributes and metadata are useful, they are inherently limiting. Think about one of the most common uses for this metadata in .NET: marking a class for XML serialization. This is extremely useful for creating configuration classes that are fed from an xml configuration file. You mark up your classes and method names with attributes that specify what their xml type is (element or attribute), as well as the name.

    The problem is, this limits your class to one kind of serialization. What if, for the configuration classes I mentioned, you wanted a configuration mechanism that could be fed from an xml file or a database? Your configuration classes are tightly coupled to XML. They are not reusable (or at least not easily) for database work. What if your database access required you to also define metadata attributes and mark your class up with them (this isn't the case, but another persistence mechanism could require this). Your code then gets marked up with another set of dependencies, in this case, both of which are optional. For a truly flexible system, you'd want the classes representing your config object to be totally decoupled from any persistence mechanism, and then you'd want to (behind the scenes) plug in whichever mechanism made the most sense. Hibernate's support for connection providers is a good example.

    I think the big issue with metadata markup, in Java or .NET, is that it tightly couples your classes. While the J2EE approach of external metadata has its faults (deployment descriptor hell), there is at the very least loose coupling. Metadata has the same requirements from a library dependency as the use of interfaces does, but doesn't offer the implementation decoupling that interfaces can. An interface implies a library dependency, but at least the implementation can be flexible. Metadata markup, compiled into the class, implies both a library and an implementation dependency that just doesn't make me comfortable.

    As a final comparison, consider Microsoft's proposed ORM libraries, which I believe make use of metadata (using .NET attributes) in the class, compared to Hibernate's external XML mapping files. Which do you think requires less coupling? Which do think ties you to a particular implementation? Which do you think is easy to drop out and transparently replace with another ORM mechanism?
  28. I've used the equivalent attributes in .NET, and have also created my own for use. The problem is, these things are really code dependencies of a different sort, the same as making a class implement an interface of some sort. Consider that in .NET, you can mark a class as serializable by either making it implement ISerializable or by marking it with the "[Serializable]" attribute.


    > The problem is, this limits your class to one kind of serialization.

    Exactly the problem. I'm working on an app with a Java back end and a .NET GUI. The data interchange is XML. On the Java side, I'm using ElectricXML which has an external XML mapping file from my schema to java classes. The .NET side has to use all these static arrangements with embedded meta data attributes. As we may modify the XML to make something an attribute rather than an element, or adjust the name for clarity, I can just update my mapping file for the Java side. The .NET requires reworking the source code.

    I see this as making certain methods of reuse impossible, because the reuser has no control over a Serialization process, for example.
  29. I do not know JSR 175 secrets, but I think compile-time dependency in not a problem if metadata is not owerused by tools.

    It must be possible to use standard "generic" attribute class for all of use cases:

    public class Attribute {

      Attribute(String params);

    }

    @Attribute("stateles")

    class MyClass {..



    And this is "evil" attribute usage:

    public class EJBStateles extends Attribute {

      EJBStateles();

    }

    import javax.ejb.*

    @EJBStateles

    class MyClass {..

    I am 99% sure ejb will use "evil" way :)
  30. Could we possibly teach the compiler to thinklessly stuff the attribute info into the .class file so that only at runtime it would (or wouldn't) get used?

    Perhaps teach the compiler to optionally warn about unchecked attribute dependencies at runtime?

    A bit like it is with C compilers that _may_ allow you to use a function w/o a declaration?

    Imagine we have:

    import a.b.c.soft.AttributeA;
    @AttributeA("qqq");

    or even
    import a.b.c.soft.AttributeA;
    import a.b.c.soft.AttributeB;
    @AttributeA("qqq", new AttributeB("zzz"));

    which would result in attaching the following
    info to a .class file:

    new a.b.c.soft.AttributeA("qqq");
    new a.b.c.soft.AttributeA("qqq",a.b.c.soft.AttributeB("zzz"));

    and if some soft queries for
    a.b.c.soft.AttributeA
    at runtime it will be used otherwise not.
  31. teach the compiler to optionally warn at _compile time_ about attributes that are being thinklessly stuffed in there

    Here the compiler could probably "use" a class it does not know about
    (I assume the attribuet is represented with a class) because the
    we probably need only use the _constructors_ of this class, and we
    could generate references to them not knowing in advance that the
    class even exists.

    (
      True, if class A extends class B
      the attribute C could probably have a C(A)
      constructor and the user might have written
      @C(new B("qqq"))

      To deal with this we could make up special rules
      for attributes, that is we could require the writer of
      meta-data to coerce all attributes to their strict types, like
      @C((A)new B("qqq"))
    )

    year, seems I'm using "attribute" instead of "annotation" --
    it the influence of http://jakarta.apache.org/commons/sandbox/attributes/

    btw, can I read JSR 175 plans somewhere? I could find nothing at
    http://www.jcp.org/en/jsr/detail?id=175 looks like they haven't issued
    and drafts yet, have then?
  32. I see JSRs like this follow a troubling trend of re-inventing the wheel! Why is it so important for the core Java language to provide features that are already supported by an open source initiative ("remember logging??")? XDoclet already provides some functionality that JSR 175 seeks to provision. The reason it does not go any further is simple... not many people requested it! So what do we gain by adding this baggage to the language itself!

    And have we already forgotten the nasty compiler directives (i.e. compile time attributes) and Macros (i.e. runtime attributes) from C / C++. Just have a look at any serious piece of MS C code if you need a reminder! Not only is the code less readable… the design does-not bind to the code intuitively… hence the need for even more AOP attributes on the code. I believe more that half the functionality provided by compile-time or runtime attributes can be provided by a powerful code-parser tool.

    Personally I think comments should be left as comments, anything thing else compile or runtime is "Code". If meta-data has to be embedded into the code, it should provide it’s own construct. Leave the comment block alone!

    My $ 0.03 (after adjustment from inflation)

    Cheers
    Adi
  33. I see JSRs like this follow a troubling trend of re-inventing the wheel! Why is it so important for the core Java language to provide features that are already supported by an open source initiative ("remember logging??")? XDoclet already provides some functionality that JSR 175 seeks to provision. The reason it does not go any further is simple... not many people requested it! So what do we gain by adding this baggage to the language itself!


    XDoclet is not a standard. Besides, XDoclet tag are not programmatically accessible in any standard way at runtime.

    >>> And have we already forgotten the nasty compiler directives (i.e. compile time attributes) and Macros (i.e. runtime attributes) from C / C++. Just have a look at any serious piece of MS C code if you need a reminder! Not only is the code less readable… the design does-not bind to the code intuitively… hence the need for even more AOP attributes on the code.

    Tags, in the context of JSR 175, do not alter compiler behavior, beyond the compiler trying to locate dependencies needed to interpret the tag. Tag usage in this regard ends up being exactly like referencing any other Java class in your code. Tags are not targeted at modifying compiler behavior.

    >>> I believe more that half the functionality provided by compile-time or runtime attributes can be provided by a powerful code-parser tool.
     
    In a portable, non-intrusive, elegant fashion? Then why has it not been done yet? Besides code parsing adds a step to the build process. Not that that's a big deal.

    The basic idea with JSR 175 is to emded metadata in the compiled class file itself. Embedding metadata via comments in the code is not the best strategy. Javadoc is and should remain Javadoc.

    >>> Personally I think comments should be left as comments, anything thing else compile or runtime is "Code". If meta-data has to be embedded into the code, it should provide it’s own construct. Leave the comment block alone!

    Couldn't agree more with you on this point ;-)

    Sandeep