db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
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 22:37:40 GMT
Knut Anders Hatlen wrote:
> Daniel John Debrunner <djd@apache.org> 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? I guess we could probably get rid of 
the com.ibm.crypto and com.sun.crypto references in Derby since the JVMs 
now load the crypo stuff automatically.

Dan.


Mime
View raw message