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

[Knut Anders Hatlen <Kn...@Sun.COM>]

Daniel John Debrunner <dj...@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?

-- 
Knut Anders

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

[Knut Anders Hatlen <Kn...@Sun.COM>]

Daniel John Debrunner <dj...@apache.org> writes:

> Knut Anders Hatlen wrote:
>> Daniel John Debrunner <dj...@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?

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

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

[Daniel John Debrunner <dj...@apache.org>]

Knut Anders Hatlen wrote:
> Daniel John Debrunner <dj...@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.