Top 18 Jaxb Interview Questions You Must Prepare 19.Mar.2024

It’s not necessary

  • everything that must be done with XML can be done with SAX and DOM

It’s easier

  • don’t have to write as much code
  • don’t have to learn SAX and/or DOM

It’ s less error-prone

  • all the features of the schema are utilized
  • don’ t have to remember to manually implement them

It can allow customization of the XML structure

  • unlike XMLEncoder and XMLDecoder in the java.be package

<?xml version="1.0" encoding="UTF-8"?>

<cars xmlns="http://www.withoutbook.com/cars"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.withoutbook.com/cars cars.xsd">

<car year="2001">

<make>BMW</make>

<model>Z3</model>

<color>yellow</color>

</car>

<car year="2001">

<make>Honda</make>

<model>Odyssey</model>

<color>green</color>

</car>

<car year="1997">

<make>Saturn</make>

<model>SC2</model>

<color>purple</color>

</car>

</cars>

Standardize generated Java:

  • classes generated by different JAXB implementations may not be compatible with each other

Preserve XML equivalence:

  • unmarshalling XML to objects and marshalling back to XML may not result in equivalent XML

Bind existing JavaBe to schemas:

  •  can only marshal and unmarshal classes generated by JAXB
  • may be added later

Schema evolution support:

  • can’ t modify previously generated code to support schema changes
  • must generated new code

Allow generated Java to access:

XML elements/attributes not described in initial schema

Partial binding:

  • unmarshalling only a subset of an XML document breaks round tripping

Implement every feature of the schema language:

  • it’ s tough to implement all of XML Schema!

Support DTDs:

  •  focusing on XML Schema
  • DTDs were supported in an earlier version, but won’ t be anymore
  • tools for converting DTDs to XML Schemas exist

Customizations can be made at four levels

global:

  • defined at “top level” in a element
  • applies to all schema elements in the source schema and in all included/imported schemas (recursively)

schema:

  • defined at “top level” in a element
  • applies to all schema elements in the target namespace of the source schema

definition:

  • defined in a type or global declaration
  • applies to all schema elements that reference the type or global declaration

component:

  • defined in a particular schema element or attribute declaration
  • applies only to it

The relationships between the components involved in XML binding (data binding) are shown below schema -> classes XML -> schema Schema generates classes.

  1. Objects are instanceof classes.
  2. Marshal from objects to XML
  3. Unmarshall from XML to objects
  4. XML validates and conforms to Schema

Customizations can be specified in

  • the XML Schema (our focus)
  • a binding declarations XML document (not well supported by RI yet)

The XML Schema must declare

the JAXB namespace and version

xmlns:jxb="http://java.sun.com/xml/ns/jaxb"

jxb:version="1.0">

Customization elements are placed in annotation elements

 <xsd:annotation>

<xsd:appinfo>

 binding declarations

</xsd:appinfo>

</xsd:annotation>

The graph of Java objects can contain invalid data:

  • could occur when objects created by unmarshalling are modified
  • could occur when objects are created from scratch

Use a Validator to validate the objects

Example:

Validator v = factory.createValidator();

try {

v.validateRoot(cars);

v.validate(car);

} catch (ValidationException e) {

// Handle the validation error described by e.getMessage().

}

Other Validator methods:

boolean setEventHandler(ValidationEventHandler handler)

• handleEvent method of ValidationEventHandler is called

if validation errors are encountered

  • default handler terminates marshalling after first error
  • return true to continue validating
  • return false to terminate with ValidationException

Pass an instance of javax.xml.bind.util.ValidationEventCollector (in jaxb-api.jar) to setEventHandler to collect validation errors and query them later instead of handling them during validation.

ValidationEventCollector vec =

new ValidationEventCollector();

v.setEventHandler(vec);

v.validate(cars);

ValidationEvent[] events = vec.getEvents();

Cars cars = factory.createCars();

Car car = factory.createCar();

car.setColor("blue");

car.setMake("Mazda");

car.setModel("Miata");

car.setYear(BigInteger.valueOf(2012));

cars.getCar().add(car);

car = factory.createCar();

car.setColor("red");

car.setMake("Ford");

car.setModel("Mustang II");

car.setYear(BigInteger.valueOf(2011));

cars.getCar().add(car);

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema elementFormDefault="qualified"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns="http://www.withoutbook.com/cars"

targetNamespace="http://www.withoutbook.com/cars">

<xs:complexType name="car">

<xs:sequence>

<xs:element name="make" type="xs:string"/>

<xs:element name="model" type="xs:string"/>

<xs:element name="color" type="xs:string"/>

</xs:sequence>

<xs:attribute name="year" type="xs:positiveInteger" use="required"/>

</xs:complexType>

<xs:element name="cars">

<xs:complexType>

<xs:sequence>

<xs:element name="car" type="car" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Easy to use:

  • require minimal XML knowledge
  • don’ t require SAX/DOM knowledge

Customizable:

  • can customize mapping of XML to Java

Portable:

  • can change JAXB implementation without changing source code

Deliver soon:

  • deliver core functionality ASAP

Natural:

  •  follow standard design and naming conventions in generated Java

Match schema:

  • easy to identify generated Java components that correspond to schema features

Hide plumbing:

  • encapsulate implementation of unmarshalling, marshalling and validation

Validation on demand:

  • validate objects without requiring marshalling

Preserve object equivalence:

(round tripping)

  • marshalling objects to XML and unmarshalling back to objects results in equivalent objects

Example:

Marshaller m = factory.createMarshaller();

m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);

Writer fw = new FileWriter(“newCars.xml”);

m.marshal(cars, fw);

marshal method accepts:

  • java.io.OutputStream
  • java.io.Writer
  • javax.xml.trform.Result

related to XSLT

org.w3c.dom.Node

related to DOM

 org.xml.sax.ContentHandler

related to SAX

• Other Marshaller methods

boolean setEventHandler(ValidationEventHandler handler)

same as use with Unmarshaller, but validation events

are delivered during marshalling

void setProperty(String name, Object value)

supported properties are

  • jaxb.encoding – value is a String
  • the encoding to use when marshalling; defaults to “UTF-8”
  • jaxb.formatted.output – value is a Boolean
  • true to output line breaks and indentation; false to omit (the default)
  • jaxb.schemaLocation – value is a String
  • to specify xsi:schemaLocation attribute in generated XML
  • jaxb.noNamespaceSchemaLocation – value is a String
  • to specify xsi:noNamespaceSchemaLocation attribute in generated XML

Example:

ObjectFactory factory = new ObjectFactory();

Unmarshaller u = factory.createUnmarshaller();

Cars cars = (Cars) u.unmarshal(new FileInputStream(“cars.xml”));

unmarshal method accepts:

  • java.io.File
  • java.io.InputStream
  • java.net.URL
  • javax.xml.trform.Source

related to XSLT:

org.w3c.dom.Node

related to DOM:

org.xml.sax.InputSource

related to SAX:

• Other Unmarshaller methods
 void setValidating(boolean validating)
• true to enable validation during unmarshalling; false to disable (the default)
  boolean setEventHandler(ValidationEventHandler handler)
• handleEvent method of ValidationEventHandler is called
  if validation errors are encountered during unmarshalling
• default handler terminates marshalling after first error
• return true to continue unmarshalling
• return false to terminate with UnmarshalExceptio
• see discussion of ValidationEventCollector later

Create/Read/Modify XML using Java

  • but without using SAX or DOM

Validate user input:

  • using rules described in XML Schemas

Use XML-based configuration files

  • access their values
  • write tools that creates and modifies these files

Maps XML to in-memory objects according to a schema

Generates classes to represent XML elements:

  • so developers don’t have to write them
  • the “binding compiler” does this
  • the classes follow JavaBe property access conventions

Supports three primary operations:

  • marshalling a tree of objects into an XML document
  • unmarshalling an XML document into a tree of objects

includes validation of the XML against the schema:

used to generate the classes of the objects validation of object trees against the schema used to generate their classes

  • some constraints are enforced while working with the objects
  • others are only enforced when validation is requested

From command-line:

Windows: %JAXB_HOME%binxjc cars.xsd

UNIX: %JAXB_HOME%/bin/xjc.sh cars.xsd

these write generated files to current directory

From Ant:

 <java jar="${env.JAXB_HOME}/lib/jaxb-xjc.jar" fork="yes">

<arg line="-d ${gen.src.dir} cars.xsd"/>

</java>

Generated Files:

• com/withoutbook/cars directory

Car.java:

  • interface representing the “car” complex type
  • only describes get and set methods for car properties

Cars.java:

  • interface representing “cars” global element
  • extends CarsType and javax.xml.bind.Element (just a marker interface)
  • describes no additional methods

CarsType.java:

  • interface representing anonymous complex type defined inside the “cars” global element
  • provides method to get collection of Car objects (as a java.util.List)

ObjectFactory.java:

  • class used to create objects of the above interface types
  • extends DefaultJAXBContextImpl which extends JAXBContext

bgm.ser:

  • a serialized object of type com.sun.msv.grammar.trex.TREXGrammar
  • can’t find any documentation on this - don’t know its purpose

jaxb.properties:

  • sets a property that defines the class used to create JAXBContext objects
  • com/withoutbook/cars/impl directory

CarImpl.java:

  • class that implements Car
  • corresponds to the “car” XML Schema complexType

CarsTypeImpl.java:

  • class that implements CarType
  • corresponds to the XML Schema anonymous type inside the “cars” element

CarsImpl.java:

  • class that extends CarsTypeImpl and implements Cars
  • corresponds to the “cars” XML Schema element 

Default bindings can be overridden:

  • at global scope
  • on case-by-case basis

Customizations include

  • names of generated package, classes and methods
  • method return types
  • class property (field) types
  • which elements are bound to classes, as opposed to being ignored
  • class property to which each attribute and element declaration is bound

The syntax for the schemaBindings element is

<jxb:schemaBindings>

<jxb:package [name="package-name"]>

<jxb:javadoc> ... javadoc ... </jxb:javadoc>

</package>

<jxb:nameXmlTrform>

<jxb:typeName prefix="prefix" suffix="suffix"/>

<jxb:elementName prefix="prefix" suffix="suffix"/>

<jxb:modelGroupName prefix="prefix" suffix="suffix"/>

<jxb:anonymousTypeName prefix="prefix" suffix="suffix"/>

</jxb:nameXmlTrform>

</jxb:schemaBindings>

– every element and attribute within schemaBindings is optional

collectionType:

  • “indexed” (uses array and provides methods to get/set elements) or fully-qualified-java-class-name(must implement java.util.List)
  • default is “java.util.ArrayList”

enableFailFastCheck:

  • "true” or “false” (default)
  • if true, invalid property values are reported as soon as they are set, instead of waiting until validation is requested
  • not implemented yet in RI

generateIsSetMethod:

  • “true” or “false” (default)
  • if true, generates isSet and unSet methods for the property

underscoreBinding

  • “asCharInWord” or “asWordSeparator” (default)
  • if “asWordSeparator” , underscores in XML names are removed and words are camel-cased to form Java name
  • for example, “gear_shift_knob” goes to “gearShiftKnob”

bindingStyle (was modelGroupAsClass):

  • “modelGroupBinding” or “elementBinding” (default)

choiceContentProperty:

  • “true” or “false” (default)
  • allows objects to hold one of a number of property choices which may each have a different data type

enableJavaNamingConventions:

  • “true” (default) or “false”

fixedAttributeAsConstantProperty:

  • “true” or “false” (default)
  • if true, “fixed” attributes will be represented as constants

typesafeEnumBase:

  • “xsd:string” , “xsd:decimal” , “xsd:float” , “xsd:double” or “xsd:NCName” (default)
  • defines field type used to represent enumerated values in generated typesafe enum class

typesafeEnumMemberName:

  • “generateName” or “generateError” (default)
  • specifies what to do if an enumerated value cannot be mapped to a valid Java identifier
  • “generateName” generates names in the form VALUE_#
  • “generateError” reports an error