Compiling under JDK 1.5

>That being said, I think the problem is more
>> difficult that just replacing variables named enum. 1.5 seems to use
>> DOM3 which has a different Document interface. We have an
>> IPortalDocument interface that extends the Document interface, and so
>> its implementation needs to be updated to reflect the new methods. It
>> would be great if someone wanted to work on that.

Tomcat only allows one level of XML and DOM support. If you have another
context on the same server that requires DOM3, then you have to solve the
problem even when using the DOM3 version of Xerces 2.6.x. You need to pull
up PortalDocumentImpl in Eclipse and either 1) generate dummy
implementations of the extra methods since they really aren't needed and
that way the module will work in both DOM2 and DOM3, or 2) generate delegate
methods that pass the new methods on to the wrapped Document object, but
that creates a version of PortalDocumentImpl that only works in a DOM3
stack.

Either takes about 10 minutes.

This is not the real problem. If you try to run in 1.5 without overriding
the built in XML support with some version of Xalan and Xerces, then you
discover that there is a bunch of imports and dependencies on explcit
org.apache.xml and org.apache.xpath classes (Serializer for example) that
are not exposed under that name in a vanilla JAXP stack. It is, therefore,
unlikely that uPortal will run in a raw 1.5 environment. It requires some
version of Xerces. If you add Xerces 2.6.x "endorsed" to Tomcat it overrides
the XML built into 1.5 and you don't have to change anything. If you wait
for Xerces 2.7.0, which will support DOM 3, and put it in the endorsed
library then you will have to change PortalDocumentImpl to support the DOM3
methods but that is all you will have to change. A third more bizarre option
exists today. You can run 1.5, and then put into the endorsed directory the
version of 1.5 source distributed by Sun for earlier releases. This is
distributed as six jar files and includes a xercesimpl jar which claims to
provide the org.apache.xml classes. This is functionally equivalent to
waiting for 2.7.0 because it would be a DOM3 stack with JAXP 1.3 support,
but it would also have the old Xerces concrete classes we depend on.

In summary, 1.5 is not the problem. Time is the problem. Things are
changing. If you don't do anything for 1.5, the same problems will hit you
again later from some other change.

The real problem, however, is either in Java, the Java community, or the W3.
I can explain it, but have not done the research to identify the culprit.
You have an interface, such as org.w3c.dom.Document. It has a specified Java
language binding in the Appendix of the standard http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/java-binding.html

Only, the W3 figures that from the DOM2 to the DOM3 standard they can just
add methods to the same interface with the same package name. Guess what
happens. Existing implementations of the old interface are now broken. Of
course they are. This is plain stupid. IBM didn't do this sort of thing.
Microsoft didn't do this sort of thing. When Microsoft confronts the same
problem, they create

interface Document3 extends Document2 {}
Or
interface org.w3c.dom3.Document extends org.w3c.dom2.Document {}

Then either version of the new interface adds the extra methods. A class can
implement the DOM2 or the DOM3 interface. Any class that implements DOM3 can
be case to be DOM2 because it's an extension. Now Java is not really very
good at versioning, but it can be used better than the W3 standard uses it.
This is stupid. It didn't have to be this bad. It's not our fault. It is our
problem. Sooner or later we have to deal. We are not alone.