Paul Sandoz wrote:
> Hi,
>
> I am experimenting with performance improvements to FI integration into
> JAXB.
>
> In the latest FI code case there are the standard FI StAX
> parsers/serializers and the Enchanced FI parsers/serializers. The latter
> depend on an enhanced implementation of the former.
>
> In the JAXB 2.1 code base there are the standard FI XMLSerializer and
> StAXConnector implementations and the Enhanced ones. The JAXB runtime
> will decide on what to use based on whether the standard or enhanced
> StAX parsers/serializers are present.
>
> The reason for this approach is that i wanted to provide some backwards
> compatibility so that JAXB could be used with older implementations of FI.
>
> This approach seemed good when it was in my head but now see it in
> practice i really do not like it, so a general question: is it
> reasonable for JAXB 2.1 to depend on FI 1.2 and above for optimal FI
> integration?
> (BTW JAXB can always fall back to the non-optimal mode)
IIRC, FI serializer/parser always implement StAX interfaces, so I think
JAXB can always handle them as just another StAX implementations. Is
that the case?
If so, I think it's probably acceptable to say "JAXB 2.1 needs FI 1.2
for optimal performance", and "If used with FI 1.0, JAXB 2.1 will work,
but without any of the FI performance benefits".
What I'd like to avoid is to break existing applications, when those are
relying on the underlying container to provide them JAXB and/or FI (such
as any JavaEE apps running inside Glassfish.) They don't have control
over which JAXB version to use, or which FI version to use (and JAXB
might come from the container while FI might be bundled in the app.)
So if any of the combination breaks, that's bad. If some combinations
aren't as fast as it could be, that's much lesser evil to me.
> If so i can remove this enhanced stuff and cut a 1.2 branch. This would
> make things very easy, since nothing changes except version dependencies.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com