com.sun.xml.io.package.html Maven / Gradle / Ivy
This package provides experimental utilities,
made available only for use within Sun, that are useful
when reading and writing XML data, converting a stream
of Java data to a stream of XML elements (and vice versa).
JavaBeans ObjectInput and ObjectOutput done with XML
The XmlInStream and XmlOutStream classes work
together to provide an alternative to serialization; we're
currently calling this "publishing" for lack of a better word.
Don't think of this as document publishing; it's also distinct
from "publish/subscribe" systems. It may be used with both of
those kinds of system, but is distinct.
All primitive Java data types may be sent, but not all objects
can be sent on these streams. Only JavaBeans can be sent, if they
can be initialized using only reflection on public properties.
This means that an object's internal state is never exposed,
regardless of whether it's marked as transient or not.
(That significantly improves the long term versioning story.)
Properties which are themselves objects can be sent, permitting
graphs (potentially cyclic, but finite) to be sent.
Since the data is in XML format, it is
straightforward to interoperate with non-Java programs. The DTD used
for this data is the stream.dtd resource in this package. It
is fetched locally, rather than accessed over the network.
There's more work to be done in this area. For example, using this
to publish Swing objects should leverage a feature that's specific to
Swing: a convention for representing "defaulted" values (or at least,
ones that are represented as objects) which don't
need to be published. And in general, objects may need to participate
in their publication, in ways that may call for new APIs.
Base64 support
Not purely related to XML are the two classes for encoding and
decoding binary data as Base 64 text. This is a common Internet
convention, which maps three bytes of data into four ASCII characters for
safe transmission through text-only channels. The classes are used by
XmlInStream and XmlOutStream, and are made available for
general purpose usage.
Why is this Experimental?
This work is in a usable interim state, but is not final.
Some reasons that this is called experimental include:
- Objects can't currently control how they are published.
- Given acknowledged problems with serialization, we should
have a more thorough solution for any technology which could
largely replace it in common usage. For example, the basic
interfaces used with serialization (
ObjectInput
and ObjectOutput) seem odd when you look at
them closely, and it may be preferable to replace them with
more appropriate interfaces.
- There is related work ongoing at W3C and elsewhere. For
example,
DCD defines ways to represent some data types, which will be
used by the XML working group in some of their upcoming work.
We may well want to tie into that work, or perhaps the OMG's
version of that work.
- Streams of primitive data types will be used in conjunction
with other kinds of constructs, such as are being examined in the
context of some of that other work.
- Testing and performance work are needed. Some other workers
in this area have claimed that this approach can be significantly
faster than serialization, at least when a tool is used to generate
custom marshaling code (avoiding runtime introspection costs).