You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jaxme-dev@ws.apache.org by Colin Bendell <cb...@point2.com> on 2004/01/09 20:20:37 UTC
RE: ObjectFactory optimizations
Better yet, why not add a static hashmap to javax.xml.bind.JAXBContext
that caches the constructed object in the method newInstance() using the
the classloader and the package name as the key?
-----Original Message-----
From: Colin Bendell [mailto:cbendell@point2.com]
Sent: Friday, January 09, 2004 10:34 AM
To: Jochen Wiedmann
Cc: jaxme-dev@ws.apache.org
Subject: RE: Why is .getJMPM() a factory method and not an
implementation method?
>The ObjectFactory is indeed specified by JAXB. However, JAXB does not
>require me, to instantiate it again and again. I am free to use a
single
>instance, which is definitely recommended for performance reasons.
Wouldn't making the jaxbContext variable in ObjectFactory a static
variable hide the performance penalty? eg:
private static JAXBContextImpl jaxbContext = null;
public ObjectFactory() throws JAXBException
{
if (jaxbContext == null)
{
jaxbContext = (JAXBContextImpl)
JAXBContext.newInstance("com.point2.griffin.service.test");
}
}
The only down side is that the jaxbContext will never be gc'ed until the
vm is shut down. Thoughts?
/colin
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: ObjectFactory optimizations
Posted by Jochen Wiedmann <jo...@ispsoft.de>.
Hi, Colin,
I had considered both of your ideas when writing the current implementation.
(My approach was worse, as I did not consider using the ClassLoader as a
part of the hash key.) I decided against.
While your idea will definitely work in 99% of all cases, there still
remains the rare cases, when the generated classes change dynamically. For
example, I can very well imagine that Axis might become such a case.
In other words: Having such a cache is fine in most cases, but one would
need to be able to turn it off. Rephrased again: The current implementation
would need to be in place anyways, together with a more complex variant.
Considering that in contrast the user is able to create a cache for himself
*quite* easily (as simple as creating a static variable), I decided that
it's not worth the trouble and better to keep it stupid, simple.
This is of course my feeling and nothing that cannot be changed by the
community. But you'd have to have at least another one voting +1 against my
-1. :-)
Jochen
Colin Bendell wrote:
> Better yet, why not add a static hashmap to javax.xml.bind.JAXBContext
> that caches the constructed object in the method newInstance() using the
> the classloader and the package name as the key?
>
> -----Original Message-----
> From: Colin Bendell [mailto:cbendell@point2.com]
> Sent: Friday, January 09, 2004 10:34 AM
> To: Jochen Wiedmann
> Cc: jaxme-dev@ws.apache.org
> Subject: RE: Why is .getJMPM() a factory method and not an
> implementation method?
>
>
>>The ObjectFactory is indeed specified by JAXB. However, JAXB does not
>>require me, to instantiate it again and again. I am free to use a
>
> single
>
>>instance, which is definitely recommended for performance reasons.
>
>
>
> Wouldn't making the jaxbContext variable in ObjectFactory a static
> variable hide the performance penalty? eg:
>
> private static JAXBContextImpl jaxbContext = null;
>
> public ObjectFactory() throws JAXBException
> {
> if (jaxbContext == null)
> {
> jaxbContext = (JAXBContextImpl)
> JAXBContext.newInstance("com.point2.griffin.service.test");
> }
> }
>
> The only down side is that the jaxbContext will never be gc'ed until the
> vm is shut down. Thoughts?
>
> /colin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: jaxme-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org