JSR 175: Adding Meta Data to Java


News: JSR 175: Adding Meta Data to Java

  1. JSR 175: Adding Meta Data to Java (22 messages)

    The new JSR 175 is aimed at adding meta data to Java in a formal way. We currently "hack" this functionality by using javadoc comments (e.g. XDoclet). Having a formal mechanism to add meta data will be great. For one, we can gain access to these "attributes" at runtime via reflection.

    We should also think about which items should be in deployment descriptors, and which should be placed in meta data. For example, should EJB transaction attributes be in an XML file, or in the code? In some cases couldn't a deployer "break" the system by changing the transactional situation?

    We have the ability to add information to our bytecode, so now we just need to agree on the "standard" way to let the compiler know in the language (@meta vs. meta java keyword, etc).

    Looks like a step in the direction of aspects... which sounds good to me. What do you think?

    Check out the JSR at:

    Threaded Messages (22)

  2. This is a great idea, but it also looks like a reaction
    to the metadata facility present in the .NET platform.
    When I first saw that, I thought: "Well, MS have taken
    many ideas from Java, but that is a feature I would like
    to see for Java too". Looks like we're getting there.
    Isn't competition great ;-)
  3. Spot on. Most tech steals ideas from other technology.
    I hope that Sun does take "the best" from the .NET framework and do it in a Java way. The problem is pride, but it looks like that isn't getting in the way.
  4. Very nice! I'm sure there are already written a lot of papers on the dilemma "in code VS in depl. desc."
  5. A few ideas that might also be interesting: inheritance of metadata and allowing bytecode as metadata.

    These would provide a very nice way to extend the language in a dynamic fashion.. eg. implementing pre- and postconditions in an Eiffel fashion would be feasible, like this:

     * @meta precondition { assert x!=null; }
    public void setX(Object x);

    Of course it has certain problems to be solved, eg. what context would the code be compiled in (so that it sees param x)... (Or forget the bytecode, just put an OCL string as a metadata, and compile it during classloading, etc - inheritance of metadata however would be very important)

    The nice thing about this that it would be optional: you can choose to _compile_ the code without certain metadata, or you can just choose to ignore it in runtime.. New VMs would honor this metadata, but it wouldnt break compatibility with old ones, they simply ignore it.. etc. etc..

    Any thoughts?
  6. JSR 175: Adding Meta Data to Java[ Go to top ]

    The basic principle of being able to add attributes to java code through some mechanism (whether in the form of javadoc style tags, or as part of the java language) seems to make sense. However, the expert group should be careful to limit to scope to what makes sense.

    Looking at the description: "The EJB architecture defines significant extra information in its deployment descriptors that is used to provide information on things like the persistence relationships of fields, the transactional properties of methods, and so forth. Source code defining web services components has similar needs."

    it is clear that replacing deployment descriptors may be one of the goals. However, the separation of the EJB code and deployment descriptor totally make sense. It makes it fairly straightforward to change the implementation, without modifying or recompiling the code.

    If the WorkShop model is an example of things to come, the overuse of these tags will lead to very confusing, none-maintainable and none-reusable code. It is hard-coding many things that should really be more loosely coupled. Take the database controls for example. The actual connections and SQL statements to be used are placed in meta tags. This means that I cannot change my persistance model, without modifying the source, recompiling and redeploying. Having such things as part of a decoupled XML file makes much more sense, what is needed is a UI that can manage these separate files as an abstracted whole.

    The none-reusability is evident when looking at web services. I want some logic that can be reused as both a web service and as a handler for a form submission. Should I use meta tags within the code for all the possibilities, or should I just create new XML files for each access mechanism? If its all in one file, this means that two people cannot easily work on the difference aspects.

    In general it is good to separate the interface from the implementation. Moving into a service oriented world that will become more and more important. The over-use of meta tags, will move more and more of the implementation into the interface. In WL WorkShop the interface IS the (generated) implementation - no decoupling at all.

  7. JSR 175: Adding Meta Data to Java[ Go to top ]

    In response to Dave Tomkins:

    Yes, you are making good points about the separation of interface and implementation. It is a fine line: on one side, we want both descriptions to be separated (as it is currently the case in J2EE, with the downside of XML file proliferation), but it's also very convenient to have them centralized in one file where a developer can easily modify them.

    I still think that the single-file approach makes sense, especially if you get the assistance of tools to fold/hide whatever gets in the way of readability.

    Also, we are aware of the risk of explosions of tag definitions, and you can be sure that some namespace functionality will be included in the specification. We already got bitten by this detail between Workshop and EJBGen, so we are acutely aware of the problem :-)

  8. JSR 175: Adding Meta Data to Java[ Go to top ]

    ...on the other hand, the assistance of tools would also allow you to manage multiple XML files transparently by abstracting away the fact that they existed.

    This would then allow for the reuse part that I'm sure the meta tag format would make difficult. I'm not against the idea of attributes per se, just attributes that include implementation detail, like an entire SQL statement.

    It's very valid to provide additional information about an interface, @meta requiresTransaction=true for example, that cannot be included using standard java language, but extending this to generate, rather than validate, runtime would, IMHO, be a step in the wrong direction.
  9. Perhaps - but I'm less concerned with how every other part of the Java specs makes use of JSR 175. It seems likely that this can and will be figured out once 175 is put in place. I'd be more concerned about making sure JSR 175 is flexible enough to support the valid uses than I would be to block the invalid ones, although both should remain concerns.
  10. How does this differ from just having a preprocessor? Seems to me that with a preprocessor we can get a lot more bang for the buck. And it would have to be easier to implement. No grammar changes. No production rule changes.
  11. To Sartoris Snopes:

    after the preprocessor is finished, the information is no longer tied to the class/method... so you would have to distribute the source, to allow other parties to create their own set of data based on the metatinformation in your classes... as an alternative of course the preprocess can generate a standardized file (eg. XML) - but then what's the point in seperating it from the class file?

    having metadata in the classfile allows for easy runtime introspection, and other goodies, like inheritance of metadata..
  12. RAmbling Comments Follow. You have been warned

    Not sure about the proliferation of configuration files in general is the way to go.

    Not sure if Meta Data is the way to go.

    Why do we compile? Origianlly, it was to convert human readable code to machine readable code. With interpreted languages, coding in a compiled language becomes an perfomrance issue. Java is strongly typed. Without the concerns for perfomrnace, you could run Java Code through an interpreter (there are several out there) and use it as a scripeted language.

    In C based applications, compilation is expensive, so to make quick fixes, or to controll access to the program, people started using configuration files. There is a fine line between a configuration file and a scripting language. Sendmail is an example of something that crosses that line.

    EJBs, and regular Java Beans both have descriptors. In the first Rev of the EJB spec, the descriptor was actaully the serialized state of a class. This was ugly and on the next rev was replaced with an XML based descriptor.

    All these descriptors defeat the benefit of early binding.

    This makes it far more difficult to integrate.

    OO languages have the fundamental concept that code is data and data is code. If we choose to program in Java, with all of its OO benefits, why do we config in XML? Why do we need another language to define the initial state of the system?

    Serializable is a basic interface. In it we specify that a class can be converted to a binary form for a variaty of reasons. It specifies no methods on the implementing object. To taga field as non-perisistable you use the javadoc style tag @transient. Would it not make more sense to specify a method:

      Property[] getTransientProperties()


      Property[] getSerializbleProperties()

    But really these things should be at the Class level. So really it should be:

    static Property[] getTransientProperties()

    but here we run into the limitation that You cannot have a static method in an interface and you cannot extend java.lang.Class.

    I think I'd like to be able to extend Class. Make all the current methods final, but allow the developer to extend Class with the methods that pertain.


  13. JSR 175: Adding Meta Data to Java[ Go to top ]

    To Adam Young:

    You didn't mention an important thing about config files. In abstract it is "separate things that change from those that don't". You easily can run several copies of your application with different config files, try doing this with your code. Unless you generate your code, it's unbearable.
  14. JSR 175: Adding Meta Data to Java[ Go to top ]

    I agree to the separate things that change from those that don't. I even think that a small degree of interpreted data is necessary. What I don't like is the way that the interpreted grows from small to large.

    Take the example of JBoss. You want to run two instances on your local machine. You want to run one instance per developer, because you are coindg on a centralized server (I've worked this way on some projects). Right now, to configure you would have to Copy the orignial configuration, and modify it per developer. Just take the port issue. Developer # 1 get 8080-8089. Devloper #2 gets 9080-9089 etc. This is the kind of thing that You would want to script. So now to configure your application, you run a script, to write a config file, that gets read in, and interpreted to code. I'm sure we've all come across this situation.

    I'd personally rather have a JbossConfiguration class. Make it a non abstract base class. It contains all the defaults. You can extend it and only have to specify those propertyies that differ from the defaults. Better yet, Make an interface, a default implementation, and the ability to rewrite from scratch if you want absolute control.

    Does it really make a difference if it is written in Java VS XML? You have to solve the same set of problems. The Syntax is a little different. With Javas non-type safe collections you probably will want to do collections as arrays which makes programming a little uglier. The amount of information you would have to process in validation would be less.

    In this case, the "configuration" info would simply be the name of the configuration class:


    java $HOTSPOT $JAXP -classpath $JBOSS_CLASSPATH org.jboss.Main org.jboss.config.DefaultConfigFactory

    and to vary from the main:

    java $HOTSPOT $JAXP -classpath $JBOSS_CLASSPATH -Dgetcare.config.number=$USER_NUMBER com.getcare.configuration.DeveloperConfiguration

    Random Gripes:

    Yes, I hate the environmental variable stuff in Java. But working around it is failry standard. Can we non-deprecate that stuff, please?

  15. JSR 175: Adding Meta Data to Java[ Go to top ]

    "I agree to the separate things that change from those that don't. "

    The problem is that you and 100 other people want to "change" some particular thing and I don't ever want to change it.

    To you (and the other 100), it should probably be in a configuration "file" or some sort of command line parameter (or environment variable).

    To me, it might as well be in with the java source code.

    Whatever the solution. To be usable, it will have to allow for setting things in the source and overriding them at some later point.

    A good example of this is the way Ant works with properties being set in the Ant script or the properties file. A rule is made to let us predict how to leave the property alone or change it for "my" configuration. Now both situations are covered.
  16. JSR 175: Adding Meta Data to Java[ Go to top ]

    An idea:

    Wouldn't it be possible to have two ways of setting attributes:

    (1) Set default attributes in the code (like C#).

    (2) Override default attributes set in the code using external XML-files (like J2EE). The XML-files would have to follow a specified format for (a) relating an attribute to a certain part of the code - e.g. what field, method etc. (like AspectJ) and (b) a standardized way of definining the attribute.

    And of course attributes should be accessible using reflection-similar mechanisms no matter how they were set.

    That would give us the best of both worlds! ;-)

    /Rasmus Lund ( rasmus AT it.edu )
    J2EE and WebLogic instructor
  17. Need late binding[ Go to top ]

    The need for late binding, especially in the scope of multiple persistance schemes, or multiple bindings for web services are the reasons why meta-data is wrong and xml descriptors are right for implementation details.

    JSR 181 is especially flawed. This is stuff that should definitely going into XML descriptors, not into java source files, since I may want to repurpose my java classes in many ways. Use the same java classes to service multiple web service requests, handle versioning of services, etc.

    Vote No on 181, vote Yes on 175 providing its just meta data for interface specification, not implementation.
  18. JSR 118 is great.[ Go to top ]

    Have you ever tried out .NET's .asmx files? With some simple code annotations, someone who is not familiar with the intricacies of the SOAP or JAX-RPC API, or of an XML descriptor file can create and deploy a fully functional web-service, and metadata about the web services config is either right there inline in the code, where it's easy to work with, or automatically inferred. For me anyway, it's very convenient and a lot easier than setting up separate descriptors.

    True it does not have all the flexible, late-binding features that full J2EE provide, but the web service is done, running, and meeting the developers current business need.
    It would seem like a shame if the J2EE world didn't standardize this sort of convenient one-file approach to posting web services.

    Roger Weber
    Software Engineer
  19. JSR 175, JSR 181[ Go to top ]

    Dave, do you really think that metadata should never be used to help with implementation?

    To me, that is the main benefit of JSR 175: it lets you put a brief, simple annotation in your Java code to save yourself from the effort of writing boilerplate, routine, and potentially buggy plumbing code or external config files to express something that you'd rather just declare inline in Java. It helps you keep your focus on the real logic of your program instead of spending unnecessary effort on worrying about the infrastructure all the time.

    Here are a few examples from different arenas that I think parallel each other and in my view would be excellent applications of 175:

    1. @meta ejb:requiresTransaction="true" - right in front of a bean class would cause a container to join a transaction or start one if needed (actually you'd want all of the choices, TX_REQUIRED/TX_REQUIRES_NEW/etc)

    2. @meta webservice:exposeAsWebService="true" - right in front of a method on a web service class would cause a container to expose the method as a web service (actually you might want to configure doc/literal/rpc encoding styles, etc too)

    3. @meta serialize:transient="true" - right in front of a field would cause the serialization framework to skip the field. Actually, we don't want to do this via JSR 175 because Java 1.1 already added the "transient" keyword to the Java language itself. But arguably if we were adding this today we'd probably want to do it via 175's mechanism because we don't want everybody going and adding new keywords to Java.

    All the above could be done using API calls (e.g., beginTransaction() etc) or external XML config files. But you don't want to write all that code by hand or maintain all those extra files. As a developer, you just want to say "make it so" in your code and have it work.

    That #1 idea is the really the gist of ejbgen, ejbdoclet, etc, (which I haven't been involved in the design for but which have proven to be very popular tools and very beautiful solutions to the J2EE configuration problem).

    The #2 idea is really the gist behind JSR 181, WLW JWS, etc. The reason I have submitted JSR 181 is that I'm hopeful that we can provide as much ease-of-use for web services as ejbdoclet+ejbgen have done in their design for EJBs - and I also think as a community we need to do do better than Microsoft's .asmx.

    It's true that JSR 175 is going to have to deal with a number of problems, including namespace collisions, making the shape of legal metadata discoverable, and so on. But if it can solve these problems, it seems like the whole beauty of it is that it enables solutions like JSR 181.
  20. No Preprocessor![ Go to top ]

    How does this differ from just having a preprocessor? Seems to me that with a preprocessor we can get a lot more bang for the buck. And it would have to be easier to implement. No grammar changes. No production rule changes.

    I think you are mixing concerns here. Meta Data has a very real place in component
    oriented programming. In fact it is a very real need. As a container writer, I
    need to read the meta data--and if it is encoded into the bytecode, it makes my
    job easier. As a component writer I need to provide the meta data--and on many
    projects deployer and developer are one and the same. I have noticed a large
    improvement in productivity when important attributes are included with the source

    Preprocessors get messy real quickly. I am thinking of several C/C++ projects I
    have worked on in the past. Preprocessors have more potential for abuse than
    meta data.
  21. So, you're saying to simply add in the capability for meta data, then, whilst the details of how it will be used are being ironed out in a number of additional JSRs, allow vendors to do things how ever they want? How will this improve over, say, the existing specs for EJB deployment? At least there are standards for this...

  22. I agree with you Dave. We should be careful not to overuse @tags (or may I say attributes) and we should be very careful about static and dynamic attributes. I beleive jsr175 should also try to find a common interface and access method mechanism for both static (attributes buried inside bytecode, retrievable from Class) and dynamic/deployment-oriented (xml deployment files) meta-data. Another thing worth to be careful about is other jsr which deal with deployment descriptors. I've read somewhere that JSP1.3 is going to be the first J2EE spec to adpot an xml schema based deployment descriptor approach. Well, if it's true then that's obviously not in harmony with this jsr imho.

    XDoclet project manager
  23. . I've read somewhere that JSP1.3 is going to be the first J2EE spec to adpot an xml schema

    I went for Servlets2.4 and JSP1.3 session @JavaOne. One of the primary goals of Servelts2.4 spec is extensibility and this is achieved by using xml schema to define deployment description rather than DTD.

    The talk continued on how specs (and frameworks) based on servlet 2.4 spec can make use of this.