[jdom-interest] Re: static data needs to be thread data for multithreaded applications

Peter V. Gadjokov pvg at c-c-s.com
Wed Sep 27 02:53:46 PDT 2000

>Yep.  Weak references would come to the rescue.  I added a note in the
>code to mark this as a future possibility.  (I'm postponing action
>because it's potentially a lot of code and testing in an area that's
>been changing, and because weak refs don't work in JDK 1.1.)

My use of JDOM is also in server-world and I'd prefer to see a slightly
different direction - JDOM is a utility API so I think it should, as far as
possible, avoid making resource-management decisions for the API user and
when it does, it should provide hooks for as much control as feasible. In
the case of namespaces - assuming JDOM can one day tell between a namespace
name and a namespace declaration - Namespace declarations (or rather, their
prefix mappings) will probably be bound to a particular document so the
static data issue goes away there. If there is a big howl for memory sharing
between instances of docs with identical prefix mappings, the management of
that stuff can be opened up with an interface and you could optionally set a
prefix mapping manager delegate on docs. As to namespace names, I can't see
a good reason to keep these as global data either. There is no reason to go
through hoops to steal some CPU and save me some memory so I can do an
identity (==) comparison between namespace names. The comparison can be
optimized so it rarely has to do a full string comparison (and the URI
strings themselves can be interned for ==). For the memory-conscious, a
NamespaceName.intern() can be added. 

Short'n'sweet - the static-data/sync problem is partially exacerbated by the
lack of separation between namespace name and namespace declaration and the
centralized storage of things that may not need centralized management under
a better model. Weak references alone are not a good option for serious
server-side use -I might (well, I do) want better control than that (say, a
configurable, explicitly bounded LRU cache that is based on weak


More information about the jdom-interest mailing list