DO NOT REPLY [Bug 12481] - Method DTMManager.newInstance causes unnecessary memory consumption

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12481>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12481

Method DTMManager.newInstance  causes unnecessary memory consumption





------- Additional Comments From ilene@ca.ibm.com  2003-01-07 16:02 -------
I've been mucking around in the FactoryFinder classes in xml-apis.jar to fix 
some minor bugs and improve performance in the lookup procedure.  So, now I've 
come back to this bug report to see what can be done in DTMManager which uses a 
similar lookup procedure.

I've reread the initial description and I'm confused.  It looks like the name 
of the factory class is already getting cached (in foundFactory)if it is read 
in from the properties file (Would the DTMManager property really ever be set 
in jaxp.properties??) or the classpath.  So, getResourceAsStream, which is only 
called from the classpath search should never get called more than once?  What 
am I missing?  

(I'm actually a little worried about this, as it stands, because if different 
class loaders were used on different threads I'm wondering if this could cause 
problems.)

As Joe suggested, we could cache the Class instead of the string name to save 
the Class.forName call, but I'm not sure this addresses the original problem, 
or the classloader issue.

Actually, I'm not sure this class is threadsafe at all because of the static 
foundFactory field.