Discussions

News: Java Meta Data Interface Spec 1.0 Final Available

Bookmark and Share Get thread feed

  1. Java Meta Data Interface Spec 1.0 Final Available (12 messages)

    The Java Metadata Interface (JMI) 1.0 final has been posted. The JMI spec is a pure Java metadata framework API that supports the creation, storage, retrieval, and interchange of metadata. In the J2EE world, JMI will help integrate apps, tools, and services. JMI will also help speed the use of Model Driven Architecture (MDA) tools/techniques by providing a mapping of J2EE concepts to the OMG Meta Object Facility (MOF).


    Download Java Metadata Spec 1.0.

    Check out the Java Metadata Interface JSR.
    Reply to this

    Threaded Messages (12)

  2. Java Meta Data Interface Spec 1.0 Final Available[ Go to top ]

    This will certainly help. Having a standard Java API for reading and writing UML models via XMI is very much welcome.

    However, there is still more to do. I hope one of the next steps is to define a profile for each J2EE component type so that standard transformations between tools are possible. We have the EJB Profile for UML, but it hasn't even been finalized. Without these profiles, JMI's use will be limited in the J2EE world.

    Regards,
    Bill
    Reply to this Reply to original

  3. Java Meta Data Interface Spec 1.0 Final Available[ Go to top ]

    What I find most interesting with J2EE adopting JMI as the standard meta-data inter-operability is, how J2EE would employ the features of the underpinning model-driven architecture.

    For example, MDA may prove very valuable for streamlining the currently somewhat cumbersome deployment descriptor configuration, by extracting EJB meta-data to partially auto-configure. What I find pretty irritating in the current EJB deployment process is that, what was originally (pre-J2EE) a compilation-time effot (with proper type checking by the compiler) has become an effort of tediously hand-editing XML deployment descriptors in the most app server environments.

    Also in places like CMP and object-relational mapping of business objects, MDA might be helpful to establish a generic process to which different app servers and middleware /persistence and caching vendors could adhere to..?

    cheers.
    -hari.
    Reply to this Reply to original

  4. Java Meta Data Interface Spec 1.0 Final Available[ Go to top ]

    Finally a hardly missed Java feature is on its way. I can't wait to get the final release in my hands.
    I like tools like XDoclet which help to simplifiy the development process of complex applications with technologies like EJB and Struts. Currently XDoclet is using Javadoc like attributes to define the Meta Data which they use to generate all the EJB stuff. I hope they will use the new Specification (in the future) to be even better than today.

    <Mirko/>

    Reply to this Reply to original

  5. Java Meta Data Interface Spec 1.0 Final Available[ Go to top ]

    <quote>
    Finally a hardly missed Java feature is on its way. I can't wait to get the final release in my hands.
    </quote>

    I think you are mixing up this JSR with JSR 175, which will deliver the metadata used by tools such as WebLogic Workshop, EJBGen and XDoclet.

    --
    Cedric

    Reply to this Reply to original

  6. Java Meta Data Interface Spec 1.0 Final Available[ Go to top ]

    <quote>
    I think you are mixing up this JSR with JSR 175, which will deliver the metadata used by tools such as WebLogic Workshop, EJBGen and XDoclet.
    </quote>

    Yes, you're right. I saw it when I read your comment. Thanks.

    <Mirko/>
    Reply to this Reply to original

  7. Java Meta Data Interface Spec 1.0 Final Available[ Go to top ]

    Do you know if this API is compatible with java.lang.reflect.* or a bridge is required ? if so, is the bridge provided ?

     Obsiously the information provided by introspection is not very rich, but may be sufficent in many cases: for instance if you are doing a property sheet editor, it would be nice to give as a parameter as well a java class, an XSD or a MOF.

    loïc
    Reply to this Reply to original

  8. Java Meta Data Interface Spec 1.0 Final Available[ Go to top ]

    It uses its own brand of reflection, I don't know if they are based on the java.lang.reflect.* classes.....

    Cheers
    Ray
    Reply to this Reply to original

  9. Java Meta Data Interface Spec 1.0 Final Available[ Go to top ]

    Do you know if this API is compatible with

    > java.lang.reflect.* or a bridge is required?
    > if so, is the bridge provided?

    The JMI spec maps all attributes and references to pairs of get/set methods (e.g. attribute "name : String [1..1]" gets mapped to String getName()/void setName(String name)". So, using standard reflection-based introspection will more-or-less work with JMI instances out of the box. JMI also provides its own reflection capability using, e.g. "void refSetValue(String propertyName, Object value)" and "Object refGetValue(String propertyName)". Actually, JMI's reflection model is much richer than reflection-based introspection because you have access to the entire model and the entire meta-model.

    If the "2u" UML 2.0 intrastructure proposal is adopted, then with MOF/UML 2.0 we should have even richer introspection capabilities because tools will be able to automatically recognized "design patterns" used in the design of the metamodel, if the metamodel is based on the core templates defined in the intrastructure.
    Reply to this Reply to original

  10. Java Meta Data Interface Spec 1.0 Final Available[ Go to top ]

    Not to be confused with .NET-like class-level metadata, which is rumored to be coming in a future Java release, but has no spec or JSR (last I heard).
    Reply to this Reply to original

  11. Java Meta Data Interface Spec 1.0 Final Available[ Go to top ]

    <quote>
    Not to be confused with .NET-like class-level metadata, which is rumored to be coming in a future Java release, but has no spec or JSR (last I heard).
    </quote>

    It does, it's JSR 175.

    --
    Cedric

    Reply to this Reply to original

  12. Java Meta Data Interface Spec 1.0 Final Available[ Go to top ]

    Is any implementation of the JMI coming soon?
    Which j2ee-related product will support it soon ?
    Any news?
    Reply to this Reply to original

  13. Java Meta Data Interface Spec 1.0 Final Available[ Go to top ]

    1. There is NSMDF which can be found at nsuml.sourceforge.net. They have been tracking the standard through the JCP. NSMDF is the foundation of NSUML, which is the foundation of the open-source ArgoUML design tool, among other things. It generates source code for the the implementations of metamodels you give it. There is no built-in persistence in NSMDF. NSMDF has an Undo/Redo mechanism and a JavaBeans-style event system. I don't know about what kind of transaction support NSMDF has. It is licensed under the LGPL.

    2. There is MDR from netbeans.org (mdr.netbeans.org). MDR can be used inside NetBeans or standalone (outside of Netbeans). They are also building a graphical front-end to MDR that requires NetBeans. It is a usable but not complete implementation of the JMI 1.0 spec. But, Netbeans has been tracking the JMI spec and so it should be fully compliant soon. Definitely, it is very usable (I've been using it for a few weeks). MDR generates the interfaces for your metamodel, and generates bytecode in realtime to implement those interfaces; it does not generate source code like NSMDF does. MDR has an event system like NSMDF; an undo/redo mechanism is being designed by another team. MDR has a built-in plugabble persistence SPI; currently, a Btree-indexed file-based persistence implementation is provided. MDR has transactions that support many read-only transactions and a single read-write transaction _per repository_. It is licensed under the SPL.

    3. The reference implementation is from Unisys and you can download it from the JMI website. I have not used it. It comes with a user guide that is very informative. Unisys's reference implementation is a scaled-down version of a product that existed long before JMI (MOF's first mapping was to Corba). Look at the RI website for details about the licensing.

    4. If you want to create your own implementation you can get a copy of the TCK for free under the SCSL (see the JMI JSR site).

    The most obvious omission that is common to #1, #2, and #3 above is that none of them can check constraints that you have defined in your metamodel. #1 and #2 currently do not even check that your metamodel is well-formed (because they can't automatically check constraints, and the MOF metmaodel constraints haven't been hard-coded into them). The non-free version of the Unisys implementation does have support for checking constraints written in OCL.
    Reply to this Reply to original