users@jaxb.java.net

Re: Peformance of JAXB

From: hitoshi uchida <uchida.hitoshi_at_canon.co.jp>
Date: Thu, 14 Apr 2005 12:21:45 +0900

2005-04-13 Kohsuke Kawaguchi wrote
> UCHIDA Hitoshi wrote:
> > Java Classes generated by xjc.sh compiler contain schema information
> > codes for validation. Can I delete the codes by using compiler option?
>
> Assuming that you are talking about 1.0, yes. See
> http://java.sun.com/webservices/docs/1.5/jaxb/vendorCustomizations.html#lwruntime

That's a useful customization.
I think it more efficient that, in generating classes from schema, xjc
compiler can delete classes that isn't used in an application.
If classes used by application are a few, many unused classes are'n
useful and use more PC memories.
For example, in compiling ,use both schema and applicatin using XML
data ,and so on.
I think it possible to delete the unused classes by using DOM infomation
of the application using XML data.

>
> > And, the generated Classes contain a main process of Unmarshalling and
> > Marshalling.
> > I think that the Unmarshalling and Marshalling processes faster than
> > using refrection API for mapping XML data into member variables of
> > Java Classes.
> > But I think, if the refrection API is used for the processes,
> > the generate codes would be smaller.
> > Why the Unmarshalling and Marshalling process is contained in the
> > Classes?
> > For performance? I know the refrection process is heavy.
> > But the heavy process is only first data mapping.
> > Later, refrection would not be used.
>
> I don't exactly understand what you are trying to say, but you might
> find it worthwhile to take a look at JAXB 2.0. The generated code no
> longer contains any of those.

I want to know why JAXB don't use refrection API like Castor.
Relaxer don't use refrection too.
Is the reason that the refrection is heavy process and uses more memory?

If JAXB libraris have Unmarshalling and Marshaling processes using the
refrection, the generated codes would be smaller without using the
compile customization.

-- 
Hitoshi Uchida
<uchida.hitoshi_at_canon.co.jp>