Daniel John Debrunner <[EMAIL PROTECTED]> writes: > Knut Anders Hatlen wrote: >> Daniel John Debrunner <[EMAIL PROTECTED]> writes: >> >>> Army wrote: >>>> Knut Anders Hatlen wrote: >>>>> OK, so if we did some kind of reflection trick in SqlXmlUtil to use the >>>>> com.sun.org.apache.xalan package if org.apache.xalan wasn't there, that >>>>> would probably work. >>>> Hmm...would this me we were coding Derby for a specific JVM (or set >>>> of JVMs)? Is that a precedence we really want to set? >>> No. I think Sun states for their VM that applications should not use >>> classes in the com.sun domain. >> >> How would com.sun.org.apache be different from com.sun.crypto, >> com.ibm.crypto and com.sun.jndi.ldap, which all are used in the current >> code base? > > Doh, I was thinking of the sun.* packages: > http://java.sun.com/products/jdk/faq/faq-sun-packages.html > > Sorry. > > Ideally derby wouldn't have any dependency on a specific JVM vendor's > classes, especially if there are standard classes (java[x].*) to > perform the same functionality. One fact would be are those classes > documented as part of the JVM implementation?
The JAXP reference implementation (https://jaxp.dev.java.net/) documents the package names in its Compatibility Guide. It looks like most of SqlXmlUtil could be written against java[x].* interfaces, with the exception of the two methods (loadSerializer() and serializeToString()) that use the Xalan classes. Since Xalan's interface is currently not in the Java SE spec, an approach with an internal serializer interface with the possibility for different implementations sounds reasonable to me. -- Knut Anders
