JDeveloper Overview and (book) Review

Dear visitors,
I will pretend I forgot that I'm about a year without posting anything and I will go straight to the subject that I owe to you: The review of the book "Processing XML documents with Oracle JDeveloper 11g". Before start I would like to make an introduction to JDeveloper.

About JDeveloper

Introduction

JDeveloper is the Oracle's Strategic IDE. Besides being used to develop Oracle's products it is a tool that has the goal to support all Oracle's technological stack, and also the majority of Java EE patterns and derivables. For example: you can draw a BPEL flow that orchestrates several services available in Oracle Service Bus, develop WSRP portlets that will be consumed by your Oracle Portal, implement EJBs that can be easily published like Web Services, or even build an portal that follows the E2.0 trend with Webcenter ADF components.

Main features

• Integrated enterprise development environment
• Visual and declarative editors
• Complete development lifecycle coverage
• Built-in development framework
• Advanced features for Java, Database, Web services, SOA, and Web development

Being a developer, I cannot forget to mention the powerful Oracle ADF (Application Development Framework). I will not cover details but worth it is saying that part of the framework is considered a model JSF implementation -- by the way, it was donated to the Apache Foundation -- and it has a powerful abstraction of the model layer (JSR-227) that, with the JDev's drag-and-drop-declarative interface, makes the development of lowly coupled and highly cohesive applications much simpler and more productive.

JDeveloper and Netbeans

Both IDEs are very important and their development will not stop. While support for Oracle's stack will be implemented mostly in JDev, NetBeans will continue to provide a powerful open source IDE.

License:

JDeveloper is a free tool, you don't have to purchase it. Besides, there is a runtime license required for any production application if you choose to use Oracle TopLink or the Oracle ADF. This license is already included in all editions of the WebLogic Server. Nevertheless you can use JDev for development/evaluation. There is no special license for academic/open source use, but in many cases the "Free OTN License Agreement" (check it out) for JDeveloper will cover this type of usage.

This is the information that I've found in Oracle's website (see the links at the end of the article). Remember: "license things" can and do change. Always check them first before using the product.

Curiosities

For those who are willing to know something about the JDev’s origins.

Processing XML documents with Oracle JDeveloper 11g – The Book

Introduction

In my opinion, JDeveloper 11g shows that it has reached a very good maturity with regard to dealing with XML. The idea of this book is to show us several easy-to-use out-of-the-box JDev’s features while, at the same time, it exposes fundamental concepts about XML processing.

Some concepts about XML presented by the book:

• DOM Parser
• SAX Parser
• Validation with XSD
• XML navigation using XPath
• XML transformation using XSLT

Some JDev's features that are also presented by the book:

• XML Edition(by code and also by its own structure)
• Creation of XSD using drag and drop
• Wizard to generate XMLs using XSDs
• Automatic XML validation (using XSD)

The book has 11 chapters and each of those has a well defined scope and they can be read independently (you don't need to follow any particular order). Generally each chapter introduces a different technology with the following order: an overview, discussion about the main features and the demonstration of a practical example. The examples are very simple and made with dozens of print-screens and source codes. Although it has about 370 pages, the big part of them are used to explain these examples, what turns the book more practical than theoretical.

Public

In my vision, the book targets to two types of public:
1 - Advanced Developers: the book can introduce technologies and may be used as a quick reference guide.
2 - Novice Developers: the book introduces fundamental concepts/tools, showing them in a practical way.

What caught my attention

The book talks about several recent technologies that are in evidence. There are chapters about DOM 3.0 LS, XSL-FO, XML conversions, and also Oracle Berkley DB. For each approach concerning XML processing, the author always uses the Oracle’s Implementation (Oracle XDK). This is very interesting because it shows us features that you don’t have when using the default interfaces.

What I missed the most

There are no details about performance or even about how to choose the right technology for the right problem. And... there is no mention of StAX.
Another point to mention is that the book doesn’t talk about the tight-coupling disadvantages that exist when the Oracle XDK implementation is used instead of the default interfaces.

Chapters overview

Chapter 1: Creating and Parsing an XML Document

• Introduction to SAX and DOM

Chapter 2: Creating an XML Schema

• Introduction to Schema (XSD)
• How to create a schema using the IDE and its wizards
• How to create XML based on a schema

Chapter 3: XML Schema Validation

• How to programmatically validate a XML document using schema

Chapter 4: XPath

• How to use the IDE to "query" the XML using XPath
• How to programmatically "query" the XML using XPath

Chapter 5: Transforming XML with XSLT

• Introduction to XSLT
• How to programmatically use XSLT
• How to use Oracle's XSLT extension function to call Java classes (very interesting, and seems very powerful as well)

Chapter 6: JSTL XML Tag Library

• Introduction to the JSTL XML tag library
• How to configure a web project that uses this tag library in JDev
• Using JSTL to parse and transform a XML document

Chapter 7: Loading and Saving XML with DOM 3.0 LS

• What is and how to use it
• Exposes advantages of using it

Chapter 8: Validating an XML Document with DOM 3 Validation

• Shows the "dynamic validation", a very relevant functionality that is part of DOM 3.0 LS. This is a very important stretch that I took from inside this chapter:

Oracle XDK 11g is the only XML API that implements the DOM Level 3 Validation specification (http://www.w3.org/TR/2003/PR-DOM-Level-3-Val-20031215/); however, some of the DOM 3 Validation features are not implemented by the Oracle XDK 11g API. A test was run by W3C to determine which of the DOM 3 Validation methods are supported by the XDK 11g implementation. You can refer to the results of the DOM3 Validation test (http://www.w3.org/2003/11/26-DOM3-Val-Oracle-Result.html) when developing a DOM 3 Validation application.

Chapter 9: JAXB 2.0

• Introduction to JAXB 2.0
• How to use JDev to generate the JAXB classes using a schema
• Introduction to the marshalling/unmarshalling process and to the JAXB 2.0 annotations

Chapter 10: Comparing XML Documents

• Overview about tools that can do XML comparison/diff
• Introduces the Oracle XDK 11g. This tool provides an API to work with comparison/diff and to automate the XSL generation. The second feature is achieved based on the original XML and the XML which we want to transform the original one into. Example: XML1 has X differences comparing to XML2. Using these X differences the API knows how to create an XSL that transforms XML1 into XML2

Chapter 11: Converting XML to PDF

• Overview of several tools that generate PDF files
• Short explanation about XSL-FO
• Demonstration on how to transform a XML into XSL-FO document using XSL
• How to use the Apache FOP API to transform a XSL-FO document into a PDF file

Chapter 12: Converting XML to MS Excel

• Overview about several tools to read/write XLS files
• This chapter is not like the others that introduce some standard patterns and concepts. This one just shows how to use Apache POI-HSSF to work with XLS

Chapter 13: Storing XML in Oracle Berkeley DB XML
This is a very interesting chapter because BDB XML is not a subject that is commonly discussed. It's worth to know the basics because it is an efficient way (and also fast) to store and query XMLs. Main points:

• Overview about Oracle Berkeley DB XML ("an embeddable XML database for storing and retrieving XML documents").
• Using BDB XML from command line (basic operations)
• Using BDB XML with a Java API (basic operations)

Chapter 14: Oracle XML Publisher

• Overview about Oracle XML Publisher (now it is called Oracle BI Publisher) and its advantages over the Apache FOP/Apache POI (shown on chapters 11 and 12, respectively).
• How to use Oracle XML Publisher + XSL-FO to generate PDF (and how it is possible to generate different formats as well)
• How to create and merge XSL-FO docs
• How to merge PDF docs
• How to use the "Data Engine API" to create an XML document from database data

Sources:

Processing XML documents with Oracle JDeveloper 11g
JDeveloper
JDeveloper History
JDeveloper FAQ
Oracle Java Tools FAQ

The X (Path) File

by Eduardo Rodrigues

This week I came across one of those mysterious problems where I had some test cases that needed to verify the content of some DOM trees to guarantee that the test went fine. So, of course, best way to achieve this is using XPath queries. And because the DOM trees involved were all quite simple, I figured writing the XPath queries to verify them would be like a walk in the park. But it wasn’t.

I spent hours and hours trying to figure out what was I doing wrong, googling around but nothing seemed to make any sense at all. Then, just when I was almost giving up and throwing myself through the window, I finally realized that tiny little detail that explained everything and pointed me out to the right solution. The culprit was the default namespace specified in my root element!

Turns out, whenever a namespace URI is specified without any prefix (like xmlns=”http://foo.com/mynamespace”), this is considered to be the document’s default namespace and it usually don’t affect parsers. But, as I found out, it does affect XPath big time. XPath, by definition, will always consider namespaces, even the default one. The problem with that is, because a default namespace don’t have any specific prefix, we completely lose the ability of using the most simple and common path-like approach when writing queries to locate nodes in the DOM tree.

Here’s a very simple example that illustrates the issue very well. Consider the following well-formed XML:

<?xml version="1.0" encoding="iso-8859-1"?>
<HR Company="Foo Inc.">
    <Dept id="1" name=”Board”>
        <Emp id="1">
            <Name>James King</Name>
            <Salary>150000</Salary>
        </Emp>
        <Emp id="10">
            <Name>Jon Doe</Name>
            <Salary>100000</Salary>
            <ManagerId>1</ManagerId>
        </Emp>
        <Emp id="20">
            <Name>Jane Smith</Name>
            <Salary>100000</Salary>
            <ManagerId>1</ManagerId>
        </Emp>
    </Dept>
</HR> 

If I want to check if there’s really an employee named “Jane Smith” earning a 100K salary in the “Board” department, a very simple XPath query such as “//Dept[@name='Board']/Emp[string(Name)='Jane Smith' and number(Salary)=100000]” would easily do the job.

Now just add an innocent default namespace to the root element:

<HR xmlns=”http://foo.com/HR” Company="Foo Inc.">

and try that very same XPath query that worked so well before. In fact, even the most simple of all queries – “/” – won’t work as expected anymore. That’s just because XPath considers the default namespace context and therefore requires it to be referenced in the query. We just don’t have any way of referring to that namespace in the query since it doesn’t have any prefix associated to it. My particular opinion on this issue is that it represents a huge design flaw in XPath specs., but that’s a completely different (and now pointless) discussion.

Unfortunately, there’s no magic in this case. To keep using XPath queries in this kind of situations, we need to use a more generic (and less compact) syntax where we can be more specific about when we do care about fully qualified (or expanded) names and take namespaces into consideration, or if we just care about local names but do not about namespaces. Bellow is the very same query, using this more generic syntax and these 2 different naming flavors, both providing the exact same outcome:

1. If you need (or want) to consider the namespace:
   

   //*[namespace-uri()=’http://foo.com/HR’ and local-name()=’Dept’ and @name='Board']/*[namespace-uri()=’http://foo.com/HR’
   and local-name()=’Emp’ and string(Name)='Jane Smith' and number(Salary)=100000]

2. If you just care about the elements’ names, then just remove the “namespace-uri” conditions:
   

   //*[local-name()=’Dept’ and @name='Board']/*[local-name()=’Emp’ and string(Name)='Jane Smith' and number(Salary)=100000]

The reason why I prefer to use function local-name() instead of name() is simply because, together with namespace-uri(), this is the most generic way of selecting nodes since local-name() doesn’t include the prefix, even if there is one. In other words, even if you had a node such as <hr:Dept>, local-name() would return simply “Dept”, while name() would return “hr:Dept”. It’s much more likely that the prefix for a particular namespace will vary amongst different XML files than its actual URI. Therefore, using predicates that combine functions namespace-uri() and local-name() should work in any case, regardless of which prefixes are being used at the moment.

Enjoy!

References

• http://www.w3.org/TR/xpath/
• http://www.w3schools.com/xpath/default.asp

Our first official book review in on its way...

by Eduardo Rodrigues

Great news!

We have been contacted (surprisingly) by Packt Publishing a few days ago and asked if we would be interested in read one of their new books and then publish an independent review here in the blog. We were very honored and flattered with the offer, so we obviously accepted it.

The book is "Processing XML documents with Oracle JDeveloper 11g" by Deepak Vohra.

One good thing that immediately caught my attention as soon as the book arrived today was seeing the name "Frank Nimphius" in the list of reviewers. This is certainly a good sign :)

Anyway, Fabio and I already have the book and we'll both read it and then compile our comments in a 4-hand post to come. We hope it wont take too long (and also hope this will be just the first of many other book reviews to come).

Cheers and keep reading!

A comprehensive XML processing benchmark

by Eduardo Rodrigues

Introduction

I think I've already mentioned it here but, anyway, I'm currently leading a very interesting and challenging project for a big telecom company here in Brazil. This project is basically a complete reconstruction of the current data loading system used to process, validate and load all cellphone statements, which are stored as XML files, into an Oracle CMSDK 9.0.4.2.2 repository. For those who aren't familiar, Oracle CMSDK is an old content management product, which has succeeded the older Oracle iFS (Internet File System). Because it's not an open repository, we are obligated to use its Java API if we want to programmatically load or retrieve data into or from the repository. That, obviously, prevents us from taking advantage of some of the newest tools available like Oracle's XML DB or even the recent Oracle Data Integrator.

Motivation

One of our biggest concerns in this project is with the performance the new system must deliver. The SLA is really aggressive. So, we decided to make some research to find out the newest XML processing technologies available, try and compare them in order to make sure which ones would really help us in the most efficient way. The only constraints are: we must not consider any non-industry-standard solution nor any non-production (or non-stable) releases.

Test Sceneries

That said, based on research and also on previous experience, these were the technologies I've chosen to test and compare:

• JAXP SAX 2 compliant parsers:
  Oracle XDK parsers shipped with JDeveloper 10.1.3.3
  Apache Xerces 2.9.1


• StAX 1 compliant pull parsers (Streaming API for XML):
  StAX 1.0 (JSR-173) API
  Codehaus Woodstox 3.2.4


• XML binding:
  Sun's JAXB 2.1.6 Reference Implementation
  Apache Commons Digester 1.8

I've initially discarded DOM parsers based on the large average size of the XML files we'll be dealing with. We most certainly can't afford the excessive memory consumption involved. I've also discarded Oracle StAX Pull Parser, because it was still a preview release, and J2SE 5.0 built-in XML parsers, since I know they're a proprietary implementation of Apache Xerces based on a version certainly older than 2.9.1.

The test scenery designed was very simple and was intended only to measure and compare performance and memory consumption. The test job would be just to parse a real-world XML file containing 1 phone statement, retrieving and counting a predefined set of elements and attributes. In summary, rules were (for privacy's sake, real XML structure won't be revealed):

1. Parse all occurrences of "/root/child1/StatementPage" element
2. For each <StatementPage> do:
1. Store and print out value of attribute "/root/child1/StatementPage/PageInfo/@pageNumber"
2. Store and print out value of attribute "/root/child1/StatementPage/PageInfo/@customerCode"
3. Store any occurrence of element <ValueRecord>, along with all its attributes, within page's subtree
4. Print out the number of <ValueRecord> elements stored
3. Print out the total number of <StatementPage> elements parsed
4. Print out the total number of <ValueRecord> elements parsed

Also, every test should be performed for 2 different XML files: a small file (6.5MB), containing a total of 420 statement pages and 19,133 value records and a large one (143MB) with 7,104 pages and 464,357 value records.

Based on the rules above, I then tested and compared the following technology sets:

1. Apache Digester using Apache Xerces2 SAX2 parser
2. Apache Digester using Oracle SAX2 parser
3. Sun JAXB2 using Xerces2 SAX2 parser
4. Sun JAXB2 using Oracle SAX2 parser
5. Sun JAXB2 using Woodstox StAX1 parser
6. Pure Xerces2 SAX2 parser
7. Pure Oracle SAX2 parser
8. Pure Woodstox StAX1 parser

Based on this tutorial fragment from Sun: http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html and considering that performance is our primary goal, I've chosen StAX's cursor API (XMLStreamReader) over iterator. Still aiming for performance, all tested parsers have been configured as non-validating.

In time; all tests were executed on a Dell Latitude D620 notebook, with an Intel Centrino DUO T2400 CPU @ 1.83GHz running on Windows XP Professional SP2 and Sun's Java VM 1.5.0_15 in client mode.

Results

These were the performance results obtained after parsing the small XML file (for obvious reasons, I decided to measure heap usage only when the large file was parsed):


As you can see, Apache Digester's performance was extremely and surprisingly poor despite all my efforts to improve it. So, I had no other choice than to discard it for next tests with the large XML file, from which the results are presented bellow:


Notice that the tendency toward a better performance when <!DOCTYPE> tag is removed from the XML document has been clearly confirmed here.

As for memory allocation comparison, I've once again narrowed the tests only to the worst case from performance tests above: large XML file including <!DOCTYPE> tag. The results obtained from JDev's memory profiler were:


Another interesting information we can extract from these tests is how much XML binding represents in terms of overhead when compared to a straight parser:

Conclusion

After a careful and thorough revision and confirmation of all results obtained from the tests described here, I tend to recommend a mixed solution. Considering its near 12MB/s throughput verified here, I'd certainly choose pure Woodstox StAX parser every time I'll have to deal with medium to large XML sources but, for convenience, I'd also choose JAXB 2 whenever there's a XML schema available to compile its classes from and the size of the source XML is not a concern.

As for complexity, I really can't say that any one of the tested technologies was found considerably more complex to implement than the others. In fact, I don't think this would be an issue for anybody with an average experience with XML processing.

Important Note

Just for curiosity, I've also tested Codehaus StaxMate 1.1 along with Woodstox StAX parser. It's a helper library built on top of StAX in order to create an easier to use abstraction layer for StAX cursor API. I can confirm the implementor's affirmation that StaxMate shouldn't represent any significant overhead for performance. In fact, performance results were identical when compared to pure Woodstox StAX parsing the large XML file. I can also say that it really made my job pretty easier. The only reason I won't consider StaxMate is that it depends on a StAX 1.0 API non-standard extension which is being called "StAX2" by guys at Codehaus.

That's all for now.

Enjoy and... keep reading!

JAXB 1.0 vs. 2.0 in JDeveloper 10g

by Eduardo Rodrigues

• if you already know JDeveloper's built-in JAXB compiler you can jump here
• Click on pictures to enlarge them
• Download this complete test case here

Ok, I know JDeveloper 10g already comes with an embedded JAXB compiler which can be found in menu "Tools -> JAXB Compilation...". The only problem with this compiler is that it's a JAXB 1.0 implementation and, believe me, the differences are simply HUGE when compared to it's successor, JAXB 2.0. And all for the very best. To prove my point, let's go through a simple example comparing both JAXB versions.

First of all, let's create a new application in JDeveloper with one empty project called "JAXB 1.0" adding only "XML" to its technology scope:



We must have a valid DTD or XML Schema so the JAXB compiler can work. Let's consider this small and simple XML Schema borrowed from a W3C tutorial:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<!-- definition of simple elements -->
<xs:element name="orderperson" type="xs:string"/>
<xs:element name="name" type="xs:string"/>
<xs:element name="address" type="xs:string"/>
<xs:element name="city" type="xs:string"/>
<xs:element name="country" type="xs:string"/>
<xs:element name="title" type="xs:string"/>
<xs:element name="note" type="xs:string"/>
<xs:element name="quantity" type="xs:positiveInteger"/>
<xs:element name="price" type="xs:decimal"/>

<!-- definition of attributes -->
<xs:attribute name="orderid" type="xs:string"/>

<!-- definition of complex elements -->
<xs:element name="shipto">
 <xs:complexType>
  <xs:sequence>
   <xs:element ref="name"/>
   <xs:element ref="address"/>
   <xs:element ref="city"/>
   <xs:element ref="country"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>
<xs:element name="item">
 <xs:complexType>
  <xs:sequence>
   <xs:element ref="title"/>
   <xs:element ref="note" minOccurs="0"/>
   <xs:element ref="quantity"/>
   <xs:element ref="price"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>

<xs:element name="shiporder">
 <xs:complexType>
  <xs:sequence>
   <xs:element ref="orderperson"/>
   <xs:element ref="shipto"/>
   <xs:element ref="item" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute ref="orderid" use="required"/>
 </xs:complexType>
</xs:element>
</xs:schema>

Just copy the code above to a file named "shiporder.xsd" in the project's root directory so it will automatically show in project's "Resources" folder:



Now select file "shiporder.xsd" in the application navigator, click the menu item "Tools -> JAXB Compilation..." and fill up the pop-up shown as the screenshot bellow:



After pressing the "OK" button, you should see the following scenario:



As you can see, the JAXB compiler generates a bunch of classes and interfaces reflecting the structure defined by the compiled XML Schema. If you look closer, you'll notice that some of the classes extend "oracle.xml.jaxb.JaxbNode" (like class ShiporderTypeImpl, for instance). That's because the built-in JAXB compilation feature we just showed relies on a JAXB 1.0 proprietary implementation provided by Oracle in its XML Developer Kit which comes with JDeveloper. You may get more details on this at Oracle XDK Home site.

Continuing with our test case, let's create a sample "testorder.xml" based on our shiporder.xsd schema:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<shiporder orderid="0001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:noNamespaceSchemaLocation="shiporder.xsd">
  <orderperson>Eduardo Rodrigues</orderperson>
  <shipto>
    <name>John Doe</name>
    <address>#100, Oracle Parkway</address>
    <city>Redwood City</city>
    <country>USA</country>
  </shipto>
  <item>
    <title>DVD+RW</title>
    <quantity>50</quantity>
    <price>.50</price>
  </item>
  <item>
    <title>17&quot; LCD Monitor</title>
    <quantity>5</quantity>
    <price>150.00</price>
  </item>
  <item>
    <title>Bluetooth Mouse</title>
    <quantity>10</quantity>
    <price>40.00</price>
  </item>
</shiporder>

To read in and process this sample XML using the package generated by Oracle's JAXB compiler, we must use the JAXB feature called "Unmarshal". To do that, I'll modify class test.jaxb1.TestJAXB1 like this:

package test.jaxb1;

import java.io.File;
import java.util.List;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Marshaller;
import javax.xml.bind.Unmarshaller;
import test.jaxb1.shiporder.*;

public class TestJAXB1 {

   static JAXBContext context = null;

   public static void main(String[] args) {
      try {
         context = JAXBContext.newInstance("test.jaxb1.shiporder");
         Unmarshaller unmarshaller = context.createUnmarshaller();
         Shiporder order = (Shiporder)unmarshaller.unmarshal(new File("testorder.xml"));
         System.out.println("Items included in order #"+order.getOrderid()+" are:");
         
         for (ItemTypeImpl item : (List<ItemTypeImpl>)order.getItem()) {
            System.out.println("\t:. "+item.getTitle()+" - "+
               item.getQuantity()+" item(s) at $"+item.getPrice()+" each");
         }
      } catch (Exception e) {
         e.printStackTrace();
      }
   }
}

Making a long story short, the "magic" performed by the Unmarshaller is basically to parse the XML using the classes generated by the JAXB compiler to map its entire content into memory. It's just like using a DOM parser to load the XML's DOM tree into memory. The advantage here is that the names, attributes and methods in JAXB generated objects strictly reflect the XML's structure defined by its schema making it much easier and more intuitive to work with them instead of a pure DOM tree. Running the test above, the outcome should be:



Quite easy. You'd probably think: Well... I'm ok with that. It's easy enough already. The question is: is that so??? NOT!!!

Now I will repeat the same test case described above only upgrading from JAXB 1.0 to JAXB 2.0. First, we'll need to get a working implementation of JAXB 2.0. I recommend Sun's reference implementation which can be downloaded here (at the time I was writing this post, version 2.1.6 was the latest one). Just follow the instructions in that page to install it correctly and notice the bin subdirectory containing some scripts, including "xjc.bat" (for Windows; "xjc.sh" for Unix). This is the script supplied to execute JAXB 2.0 compilation. The trick here is to embed it in JDeveloper as an "External Tool". I'll show you how to do that step-by-step:

1. Click the menu item "Tools -> External Tools..."


2. Press the "New..." button to start the "Create External Tool" wizard


3. Select "External Program" as the "Tool Type" and press "Next"


4. Fill the 3 displayed fields as follows:


• Program Executable:
  full path to the script "xjc.bat" which sould be <Sun_JAXB_2.1.6_install_dir>/bin/xjc.bat (or "xjc.sh" on Unix)


• Arguments:
  -d "${project.first.sourcepath}" -p ${promptl:label=Target Package Name} "${file.path}".
  
  Press button "Insert..." to see all macros available (i.e.: ${file.path}).
  
  The arguments above will be passed to the script "xjc.bat". Execute it with no arguments in a command prompt to see a help on all possible arguments. The default is to compile a XML Schema but you can use -dtd to compile a DTD instead, although it's an experimental feature.


• Run Directory:
  <Sun_JAXB_2.1.6_install_dir>/bin




5. Press "Next" to advance to "Display" step and fill the 3 fields as you like. I suggest the following:


• Caption for Menu Items:
  Compile XML Schema with JAXB 2.0


• ToolTip Text:
  Compile a XML Schema with JAXB 2.0 Reference Implementation by Sun Microsystems


• ToolTip Text:
  ide.fileicon:<SUN_JAXB_2.1.6_install_dir>/bin/xjc.bat




6. Press "Next" to advance to "Integration" step where I recommend selecting "Tools Menu" and "Navigator Context Menu"


7. Press "Next" to advance to the final step "Availability". Here, I recommend choosing the option "When Specific File Types are Selected" and then move only the item "XML Schema Type" from list "Available Types" to list "Selected Types"


8. Press "Finish" and done!

Now we have the same built-in "JAXB Compilation" functionality described before but now using Sun's JAXB 2.1.6. So, let's repeat the same test case using our new tool.

First, create a new empty project called "JAXB 2.0" also adding only "XML" to its technology scope.

We'll need to create a JAXB 2.0 library and add it to the project:



The important here is to add the following archives, located in directory <Sun_JAXB_2.0_install_dir>/lib, to the library's class path: jaxb-api.jar, jaxb-impl.jar and jsr173_1.0_api.jar.

Now just copy files "shiporder.xsd" and "testorder.xml" from project "JAXB 1.0" to this new project's root directory. Also be sure that the sources directory configured for the project exists and, if it doesn't, create it manually. That's needed because Sun's JAXB 2.1.6 compiler won't create its output directory automatically and the process will fail if that directory doesn't exist. Finally, select file "shiporder.xsd" in the Applications Navigator and execute our newly created menu item "Tools -> Compile XML Schema with JAXB 2.0"



Define "test.jaxb2.shiporder" as the "Target Package Name" when prompted. After execution, you should see the following output:



Just click the "Refresh" button on the Applications Navigator and the new package "test.jaxb2.shiporder" will appear. At this point we can already make a simple comparison:



As you can see, instead of generating 16 interfaces, 15 classes and 1 property file, JAXB 2.0 generated only 4 classes! And like it was not enough, if you look inside those 4 classes you'll notice that they are all very simple POJOs!!!

Take class "Shiporder.java" for example:

//
// This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.1.5-b01-fcs 
// See <a href="http://java.sun.com/xml/jaxb">http://java.sun.com/xml/jaxb</a> 
// Any modifications to this file will be lost upon recompilation of the source schema. 
// Generated on: 2008.01.09 at 12:41:26 PM BRST 
//

package test.jaxb2.shiporder;

import java.util.ArrayList;
import java.util.List;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;


/**
 * <p>Java class for anonymous complex type.
 * 
 * <p>The following schema fragment specifies the expected content contained within this class.
 * 
 * <pre>
 * &lt;complexType>
 *   &lt;complexContent>
 *     &lt;restriction base="{http://www.w3.org/2001/XMLSchema}anyType">
 *       &lt;sequence>
 *         &lt;element ref="{}orderperson"/>
 *         &lt;element ref="{}shipto"/>
 *         &lt;element ref="{}item" maxOccurs="unbounded"/>
 *       &lt;/sequence>
 *       &lt;attribute ref="{}orderid use="required""/>
 *     &lt;/restriction>
 *   &lt;/complexContent>
 * &lt;/complexType>
 * </pre>
 * 
 * 
 */
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
    "orderperson",
    "shipto",
    "item"
})
@XmlRootElement(name = "shiporder")
public class Shiporder {

    @XmlElement(required = true)
    protected String orderperson;
    @XmlElement(required = true)
    protected Shipto shipto;
    @XmlElement(required = true)
    protected List<Item> item;
    @XmlAttribute(required = true)
    protected String orderid;

    /**
     * Gets the value of the orderperson property.
     * 
     * @return
     *     possible object is
     *     {@link String }
     *     
     */
    public String getOrderperson() {
        return orderperson;
    }

    /**
     * Sets the value of the orderperson property.
     * 
     * @param value
     *     allowed object is
     *     {@link String }
     *     
     */
    public void setOrderperson(String value) {
        this.orderperson = value;
    }

    /**
     * Gets the value of the shipto property.
     * 
     * @return
     *     possible object is
     *     {@link Shipto }
     *     
     */
    public Shipto getShipto() {
        return shipto;
    }

    /**
     * Sets the value of the shipto property.
     * 
     * @param value
     *     allowed object is
     *     {@link Shipto }
     *     
     */
    public void setShipto(Shipto value) {
        this.shipto = value;
    }

    /**
     * Gets the value of the item property.
     * 
     * <p>
     * This accessor method returns a reference to the live list,
     * not a snapshot. Therefore any modification you make to the
     * returned list will be present inside the JAXB object.
     * This is why there is not a <CODE>set</CODE> method for the item property.
     * 
     * <p>
     * For example, to add a new item, do as follows:
     * <pre>
     *    getItem().add(newItem);
     * </pre>
     * 
     * 
     * <p>
     * Objects of the following type(s) are allowed in the list
     * {@link Item }
     * 
     * 
     */
    public List<Item> getItem() {
        if (item == null) {
            item = new ArrayList<Item>();
        }
        return this.item;
    }

    /**
     * Gets the value of the orderid property.
     * 
     * @return
     *     possible object is
     *     {@link String }
     *     
     */
    public String getOrderid() {
        return orderid;
    }

    /**
     * Sets the value of the orderid property.
     * 
     * @param value
     *     allowed object is
     *     {@link String }
     *     
     */
    public void setOrderid(String value) {
        this.orderid = value;
    }
}

"public class Shiporder {". No interfaces being implemented, no classes being extended at all. Only a simple JavaBean with its attributes and their respective accessors. The "magic" here is done thanks to the annotations. They perform the actual mapping between the XML's structure defined by the compiled XML Schema and the classes derived from that compilation process.

I think it's pretty obvious to see the huge advantages of JAXB 2.0 when compared to version 1.0. The compilation of a XML Schema produces much fewer classes and those classes are simply annotated POJOs. This certainly implies a much faster, lighter and easier to understand XML binding.

Besides, there are some other details that makes JAXB 2.0 even more beneficial. Javadocs are automatically generated, it relies on cutting-edge XML parsing technology called "Streaming API for XML" which basically gives much more precise control over XML document processing. For further info on this, read "Oracle StAX Pull Parser Preview" and "JSR#173 homepage". Finally, as opposed to the known limitations of JDeveloper's built-in JAXB 1.0 compiler, Sun's JAXB 2.1.6 supports:

• Javadoc generation


• The key and keyref features of XML Schema


• The List and Union features of XML Schema


• SimpleType mapping to TypeSafe Enum class and IsSet property modifier


• XML Schema component "any" and substitution groups


• Customization of XML Schema to override the default binding of XML Schema components


• On-demand validation of content based on a given Schema

To run the same unmarshalling test, just create class "test.jaxb2.TestJAXB2" as follows:

package test.jaxb2;

import java.io.File;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.Unmarshaller;
import test.jaxb2.shiporder.Item;
import test.jaxb2.shiporder.Shiporder;

public class TestJAXB2 {

   public static void main(String[] args) {
      try {
         JAXBContext context = JAXBContext.newInstance("test.jaxb2.shiporder");
         Unmarshaller unmarshaller = context.createUnmarshaller();
         Shiporder order = (Shiporder)unmarshaller.unmarshal(new File("testorder.xml"));
         System.out.println("Items included in order #"+order.getOrderid()+" are:");
         
         for (Item item : order.getItem()) {
            System.out.println("\t:. "+item.getTitle()+" - "+
               item.getQuantity()+" item(s) at $"+item.getPrice()+" each");
         }
      } catch (Exception e) {
         e.printStackTrace();
      }
   }
}

This is slightly different from class "test.jaxb1.TestJAXB1" but, after running it, you should see exactly the same outcome:



Well, that's it. I think I've made my point. So good luck in your JAXB 2.0 adventures!