[jdom-interest] To intern or not to intern

[Nick Reeves]

I left this issue until the flurry associated with beta 5 release had
passed, so now is the time to raise it again.

There are a number of places where JDOM uses interning, ie makes canonical
copies which can be compared with == rather than equals. One problem with
this that I have mentioned before is that this introduces static data which
requires special handling such as synchronization to allow multiple threads
to use the JDOM classes at once, even on completely disjoint documents. This
special handling is missing at the moment.

Before we discuss whether and how to add this special handling for thread
safety of static data there are two further issues associated with interning
and Java 1.1 that you need to be aware of.

a) Java 1.1 has no weak references so the intern table will never release
the interned objects leading to memory bloat in a long running server.

b) Java 1.1 Object serialization is lacking the readResolve() mechanism
which allows Objects read in to be replaced by the interned equivalents.
Thus JDOM Objects which require interning could not be made Serializable.
One position that some people might adopt is that they don't care about
Object Serialization because for them XML is the external form.

Thus a high level policy decision needs to be made about which of the
following strategies on interning will be adopted throughout JDOM code.

1) Leave the code as it is making it unsuitable for multithreaded and long
running servers.

2) Remove the use of interning.

3) Continue to use interning but only address the issues of thread safety,
and ignore the issues of memory bloat and Object Serialization.

4) Continue to use interning, and address all the the issues for Java 2, by
providing an alternative Java 2 specific implementation of the relevant
parts.