I am pleased to announce the first public release of JXV.
JXV is a library which allows for Java objects to be given "XML Views", and for those views to be read back into objects. JXV supports both SAX and DOM output, and can read XML input from any SAX-compliant parser. Resulting DOM trees are dynamic, and reflect changes made to the object model even after they were created. JXV fully supports namespaces in it's XML views, and can correctly parse and read XML content with namespaces.
JXV uses a pluggable architecture which allows XML view factories to be configured and loaded at runtime. The JXV configuration mechanisms also leverage XML namespaces to allow the configurations for those different view factories to be inlined within the JXV configuration file. In this release, JXV comes pre-configured with view factories for JavaBeans, collections, array, and "flat objects" such as Strings, primitives, etc. These factories support a wide variety of configuration options, and are sufficient for most object models. Future versions of JXV will include pre-configured support for additional factories. JXV may also release special-purpose factories (such as ones providing views for RowSets, ResultSets and other JDBC structures) as extension packages.
JXV is open-source and freely available in both source and binary form. It is covered by an Apache-like license (see information at the project page). The JXV distribution contains a compiled binary version as well as a buildable "src" dir (Ant is required to use the build script).
For more information (and download locations) visit JXV's project page
so how do u compare it with other JAVA-XML Binding approaches? say, JAXB or Castor-XML? any exclusive feature? any known weakness?
I'm definately biased, but here is my opinion. Download the distribution and you can decide for yourself :)
First of all, the main design goal for JXV is different than that of JAXB for instance, which is why I prefer not to call it an XML binder. JXV is designed almost exclusively for cases where you want to start with completely standard Java objects and use XML as an added value. XML binders like JAXB (and at least some of Castor) are usually designed with the mindset that you want to "instanciate" an abstract XML definition like a DTD or schema as a set of Java classes. There is nothing wrong with this mindset, and it's very usefull for the main purpose of JAXB: reading and writing XML formats. However, there are types of information that I would not naturally model using an XML schema, like model components in a MVC application. These are components that are naturally described as OO structures, and modeling them with XML as a focal points seems un-natural to me. Despite this fact, using these objects in XML form can be very beneficial. You can query them using XPath or XQuery, generate markup (say HTML) from them using XSLT, etc. Existing web-application
frameworks (such as Maverick and Apache Cocoon) make use of this approach. From the very start I designed JXV with this idea in mind.
Moving to more practical lines, I think the main "advantages" of JXV over existing mappers (the ones I know, anyway) are:
- JXV is completely open and pluggable. Absolutely no XML-generating code is hardcoded into JXV - it is all loaded at runtime, and can be extended by users. I think this can become a very important point, but in order for that to happen we need to improve the documentation to make it easier for users to extends JXV, and get a more active community. A wide set of view factories for RowSets, ResultSets, EJB-related classes, servlet/JSP request/response and session classes, etc. could really boost JXV's useability.
- JXV's configuraion format is far more flexible and intuitive than other mappers, at least in my opinion. In castor, for instance, every property maps to exactly one element, text, or attribute. In JXV you can map a property to any XML structure you want, however complex it may be. I can't explain the whole idea of template-based configuration here, but the user's guide contains many examples.
- JXV's has a DOM implementation which is dynamic, and reflects the state of the objects even after they are changed. The biggest problem with DOM has allways been that it wastes a lot of memory, loading all of the document before you can process it. However, when dealing with objects that are in the memory anyway, a "reflective" DOM can solve, or atleast greatly reduce this problem. The DOM
doesn't store it's own information: it merely reflects the state of the objects (which are loaded in the memory anyway), so the amount of memory used is much smaller. Then the natural advantage of the DOM, random acces, can become critical. Consider querying a huge object model using an XPath expression to find the first child element. Using the reflective DOM, only the necessary information will be asked for by the processor and loaded. Using SAX, on the other hand, means that all of the document's events will be signaled, wasting a lot of time. I should note that the Domify project has a similar DOM tree implementation (designed with a similar mindset, particularly for the Maverick framework).
The points I think need improvement in JXV are:
- Robustness. JXV has not been tested by a large user base, so I don't consider it robust yet. That's why the current release is an alpha release. I hope that the open-source development mode would help us achieve better robustness.
- Not enogth view factories: I think it is important to have many view factories for many types of objects (I mentioned some above). Again, I hope the open-source mode will allow us to expand quickly in this respect.
- JDK1.4 dependency: the current release depends on JDK1.4. The dependency itself is quite easy to fix and I allready have a working CVS copy of it that I might release soon. However, JDK1.4 had very important performance improvements in certain data structures and many types of Reflection features. Therefore the performance in JDK1.3 is substantially weaker, and I'm not sure if it can be fixed.
- Documentation not mature: most of the documentation has not been reviewed by many people yet, so it may contain unclear points or even miss out on important information. The user's guide is an attempt to put some order in things, and I hope in a couple of releases it will reach a mature form.
If you have any other questions please post them.
Is the mapping fixed at compile time or can it be changed at runtime? By this I don't mean changing the map-implementing class at runtime but rather having a map-implementing class, which allows to change the mapping dynamically at runtime. As a continuation of the same - is the idea of the framework to use config files for the mapping or precompiled mapping classes?
Can I define multiple mappings for the same property of an object at the same, for instance:
These concepts don't exactly fit JXV's concepts, but I'll try to explain.
First of all, there is no "map implementing class" because JXV configuration is not based on a mapping. The JXV configuration of a JavaBean class is a "template" such as this one, for a Date:
The children of <bean:root> become the XML view of the Date object. If we had an order with a "myDate" property, we could configure it like this:
This would cause the elements of the Date view to be placed as children of the "my-date" element. Similarly, attributes defined on bean:root would become the attributes of the view and would be copied to the containing element. The bean:property element serves as a delegate, and is "replaced" by the view of the value of the property.
You can have many different configuration for the same class, and you can pass them as parameters in specific contexts. For instance, to create your second XML fragment, you can use:
<bean:property name="myDate" context-type="text">
Here a configuration item for the factory responsible of Date classes, the flat factory, is specified. The flat factory configuration item specifies which class to use in order to marshal the Date into text.
What JXV does have that resembles a mapping is the default processing framework. JXV can create default configurations for properties. This is controlled using the bean:apply-defaults element. You can change the way default configurations are generated by specifying your own XSLT template to generate them. The input format taken by this template is described in the user's guide.
You can also load different configuration instances altogether, and manipulate them at runtime.
There are many other different options, some of which are listed in the user's guide. Feel free to ask about any other issues you are interested in.
Is there an article available somewhere that explains and shows the exact functionality/intent of JXV?
Also, I guess the comparison you made between JXV and Castor or JAXB also holds for the long term bean persistence functionality of JSDK 1.4 (java.beans.XMLEncoder/Decoder)?
Unfortunately I have not written an introduction article yet, so I guess you can add that to the list of problems I gave in the previous message :) However, you can read the User's Guide that comes with the JXV distribution (in doc/user_guide.html). It explains most of the major features and also gives several examples of configuring and using JXV. I'll also put it up on JXV's homepage so you can access it online.
Long term bean persistence is something quite different, atleast in my view. The long term bean persistence classes aim at achieving something similar to serialization only with XML. The format is human readable, but what you get is not "normal" XML but rather a very specific format used to persist JavaBeans. A great deal of XML's power comes from the fact that it is a self-describing format, where at least some of the meaning of the data can be directly inferred from the data itself. When all your data is described in some sort of fixed format, where the metadata is given as a part of the specific format rather then the XML structure itself, I think you lose a lot of that power. Maybe what I mean will be clearer after you see the two examples below. As a result of this, it would be very hard for you to do anything meaningful to the XML you get from XMLEncoder other than read it back into a JavaBean. Applying something like XPath or XSLT to it would be cumbersome and require knowledge of the JavaBean's internal structure, not to mention XMLEncoder's format. It's definately not something that your users would be comfortable working with and changing.
Here is an example right out of the XMLEncoder API. The XML for a frame GUI object would look like this:
<java version="1.0" class="java.beans.XMLDecoder">
The same object, using JXV, would be written as something like:
<bounds X="0" Y="0" height="200" width="200"/>
JXV doesn't really fit writing GUI components, but I hope you get the picture. Also note that you can configure JXV in many different ways, while the bean-persistence format is relatively fixed.
In my current project, we have a need to access a back-end which exposes an XML interface. On our side we have a set of entity type java objects that are basically javabeans that represent the entities handled by the back-end, e.g. Person, Address etc.
We looked at various tools that do java to XML mapping but they usually made the assumption, as you say, that you start from some existing XML and generate the java classes, which was not the case for us. Another assumption of such tools that was blocking for us was that one java class was always mapped into XML in the same way, ie there is a one-to-one relationship between a java class and the XML schema of its XML representation. As we need to generate different XML depending on which request to the back end we are making (and e.g. an Address object may be transformed to an "Address" element in one case and "Addr" in another), this does not meet our needs.
The approach we have decided on is to still use a tool like Castor or Electric XML (or in the future JAXB) to get a default XML representation of the objects, and then write a set of XSLTs that will transform the XML into the specific format needed by the back-end.
From your description, I think JXV would have the flexibility to be a good alternative to the above architecture. As it is still in alpha I guess it's a bit too early to consider it now, but I think it responds to a need not covered by other Java-XML tools...
I'm happy to see that other people recognize the need I tried to fill with JXV. I've faced many situations where neither the XML is determined from the classes nor the classes are determined from the XML. Some binding frameworks address this need partially. Castor allows element, attribute, or no mapping for each property. But that still seems quite restrictive when dealing with a highly structured and hierarchial format like XML.
I don't advise you to use JXV in production now because I can't guarantee that it is mature enogth just yet. I do think that its worth taking a look at, even if only to get some ideas on how to design a system where XML views are decoupled from Java classes.
Just to make the difference clear for other people (I'm sure you have considered it), the approach of using Castor and then XSLT would be far less scalable since it requires the XSLT engine to build some sort of internal tree in the memory instead of just stream SAX events. JXV can write 5M/sec of XML code to the disk on my own personal computer, and you wouldn't have to do anything after it (and it eats little memory).
FYI, I released a new version, 0.2, which supports JDK1.3 as well as 1.4. JDK1.4 is still preferable because it has major improvements in reflection performance and also some important data structures.