As a new user of JAXB, I've encountered a number of things that range
from confusing features to irritations. Rather than raise issues
directly, I thought I'd see if my gripes are reasonable or not before
progressing. Some of these are sure to have come up in the past.
There are a couple of features mentioned in the JSR or documentation
relating to the bindings file that are not reflected in the schema (at
<
http://java.sun.com/xml/ns/jaxb/bindingschema_2_0.xsd>). I can
understand that the "bindings@scd" attribute is an extension, but
couldn't this at least be defined in an extension namespace? This would
be consistent with standard practice for extending schema. This would
require an anyAttribute definition on the base schema, but that's a
reasonable thing to add anyway.
The same applies to the "schemaBindings@map" attribute, except that this
attribute is mentioned in the JSR explicitly.
As an aside, I'd also recommend that this feature carry a
warning - if you compile a schema A with xjc, then use this feature when
compiling schema B (that references schema A), if schema B contains
restrictions of types from A, the classes compiled from schema A are not
sufficiently aware of the restrictions and your (un)marshalling might
fail in baffling ways.
I don't like the fact that we identify schema by file name rather than
namespace URI. All other APIs use the namespace URI, and this allows us
to decouple the concept of the schema infoset and it's representation.
I could be demonstrating ignorance on this point, but from my reading of
the JSR, I can't see why this choice was made. For most schema, the
targetNamespace should be sufficient. Keeping the filename as an
alternative method of identification might be necessary for those rare
(?) schema that do not have a target namespace.
The implementation of xs:any is cumbersome where it is subsequently
restricted to include specific element definitions. It would not be
especially onerous to add get/set implementations on the restriction
type that transparently pass JAXBElement<?> instances to the underlying
list.
xjc is too finicky with argument order. If I define schema that include
imports without a schemaLocation attribute, all the imported schema must
be included on the command line before the schema that includes them, or
else xjc has a fit.
(Side note: using schemaLocation is, in general, a bad idea in many
scenarios, e.g. standards documents. Since the actual location or file
name isn't necessarily known a priori, any value specified for this
attribute. There are always better ways to specify where to find
schema, like the LSResourceResolver and the JAXP
"
http://java.sun.com/xml/jaxp/properties/schemaSource" property.)
This argument order problem is especially bad when using the Ant task,
because the Ant fileset isn't specifically ordered. This doesn't work:
<schema dir="${schema}" include="xml.xsd my.xsd" />
Instead, this is what you need to do:
<schema file="${schema}/xml.xsd" />
<schema file="${schema}/my.xsd" />
(Side note: the Ant task consequently reports that it is compiling
xml.xsd and others, which isn't very helpful, because all compilations I
run now say exactly the same thing. In fact, the last one on the list
is probably the most interesting one.)
To address this problem, xjc would have to inspect the targetNamespace
of each of the input schema and create an LSResourceResolver.
The codegen creates code that generates a lot of warnings from stricter
compilers. This isn't a big deal; after all, it IS valid, but it
generates a great deal of warnings. My recommendations (which are
subject to my personal preferences, of course, add your own slant):
- Add @SuppressWarnings("nls") to the generated ObjectFactory class, or
just the QName constants it declares.
- Setters all take an argument named "value", which shadows the
instance variable (particularly if you have elements in the form <x
a="b">xx</x>). It would be less chancy to prefix an underscore to the
field name: e.g. setX(String _x) {this.x = _x; }
- A few empty blocks are created. Extending classes that represent
restrictions are prime culprits.
- A few places don't use the "this." qualifier on instance fields where
they could.
- Note: Run a few generated files through Eclipse with all the warnings
turned on and witness the joy ;)
Regards,
Martin
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]