db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@gmail.com>
Subject Re: svn commit: r543183 - in /db/derby/code/trunk/java: engine/org/apache/derby/impl/sql/compile/UnaryOperatorNode.java testing/org/apache/derbyTesting/functionTests/tests/lang/CollationTest.java
Date Thu, 31 May 2007 21:24:35 GMT
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?  Sure, it's Sun's JVM, but 
still...do we do have any other specific logic in the Derby code?

> Hmm, there is also a com.sun.org.apache.xerces.internal.impl.xpath.XPath
> class that we could check for. Its existence would at least give us the
> same guarantee as org.apache.xpath.XPath, I think.

Same question as above.

> If we require Xalan specific classes/methods and cannot only rely on
> generic interfaces, then I agree, Xalan is what we should check for.

I think this is probably the way to go.

> I'll log a JIRA issue for this, since it seems like a great usability
> improvement not to require separate downloads when the JVM has what's
> needed.

I think it's important to make sure we're talking about the same Jira.  I think 
it makes sense to file an issue for checking specifically for Xalan classes. 
I'm not so sure I like the idea of adding code to check for a set of classes 
that are only present in Sun jdks.  That makes me a little uncomfortable...

Army


Mime
View raw message