You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Andrew Wason <aw...@rootbin.com> on 2002/02/08 16:25:48 UTC
JDK 1.4 and Xalan
Sun is bundling a version of Xalan and Xerces into JDK 1.4s rt.jar.
http://developer.java.sun.com/developer/bugParade/bugs/4624775.html
But the org.apache.* packages are not part of the JDK API spec and are not
in the endorsed standards set.
"The java.*, javax.* and org.* packages documented in the Java 2 Platform
Standard edition API Specification make up the official, supported, public
interface." (the org.apache.* packages are not in the spec)
http://java.sun.com/products/jdk/faq/faq-sun-packages.html
"No other packages from the J2SE platform API specification may be
overridden." (the org.apache.* packages are not in the overridable list)
http://java.sun.com/j2se/1.4/docs/guide/standards/index.html
I think this means that I am not allowed to replace the Xalan
implementation that ships with JDK1.4 (e.g. by forcing my xalan.jar first
via -Xbootclasspath/p:). I don't think I would want to do this anyway since
it would replace internal JDK implementation classes with a version the JDK
was not tested with. Also doing this makes things more difficult for my
apps users since I can't just ship an executable jar file with a
"Class-Path: xalan.jar xerces.jar" entry in its manifest.
In addition, since the org.apache.* packages are not part of the JDK 1.4
API spec (they are just part of it's internal implementation like the sun.*
packages), this means I should not use internal JDK implementation Xalan
classes like org.apache.xpath.XPath.
So it seems that as of JDK 1.4 I can no longer "legally" use Xalan at all -
I can't use the built in implementation and I can't replace it with my own.
Sun has usurped the org.apache namespace for their internal JDK
implementation, shouldn't they be using sun.org.apache or something? Or
possibly they could load their internal implementation classes
(org.apache.* and sun.*) via a different ClassLoader so those classes are
not visible to my application, freeing me to use my own xalan.jar without
conflicting with or replacing Suns version.
Andrew
--
Andrew Wason
/root/bin
aw@rootbin.com
Re: JDK 1.4 and Xalan
Posted by Edwin Goei <ed...@sun.com>.
Elliotte Rusty Harold wrote:
>
> That said, we really should complain to Sun to make sure they ship
> with a current version of Xalan. The one they ship breaks the Apache
> xml-security package and probably other things too. And we should
> probably add the $JAVA_HOME/lib/endorsed directory to the
> documentation somewhere if it isn't there already.
The Sun JDK1.4 product is a large project with many components and as
time nears product ship, components are frozen so that they do not
affect other components. So the version of Xalan that did get shipped
was the latest version before the freeze, which was 2.2_d10.
The downside is that users that need bugfixes after the freeze will need
to download a newer version and install it.
-Edwin
Re: JDK 1.4 and Xalan
Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 10:25 AM -0500 2/8/02, Andrew Wason wrote:
>I think this means that I am not allowed to replace the Xalan
>implementation that ships with JDK1.4 (e.g. by forcing my xalan.jar
>first via -Xbootclasspath/p:). I don't think I would want to do this
>anyway since it would replace internal JDK implementation classes
>with a version the JDK was not tested with. Also doing this makes
>things more difficult for my apps users since I can't just ship an
>executable jar file with a "Class-Path: xalan.jar xerces.jar" entry
>in its manifest.
>
I can tell you that you can fly like Superman. That doesn't make it true.
Sun can tell you you can't upgrade to a newer version of Xalan.
That's not true either.
Put the xalan.jar you want to use in your $JAVA_HOME/lib/endorsed
directory and Java will pick it up ahead of the bundled Xalan. On my
system that's F:\jdk1.4\lib\endorsed but yours is probably somewhere
different. I suspect the only thing Sun is using Xalan for internally
is javax.xml.transforms.*. I don't think the newer version of Xalan
is likely to break that.
That said, we really should complain to Sun to make sure they ship
with a current version of Xalan. The one they ship breaks the Apache
xml-security package and probably other things too. And we should
probably add the $JAVA_HOME/lib/endorsed directory to the
documentation somewhere if it isn't there already.
It certainly is more difficult for end users though. Does anyone know
offhand which version of Xalan Sun is shipping? I'd prefer not to
write code that depends on a later version if possible.
--
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| The XML Bible, 2nd Edition (Hungry Minds, 2001) |
| http://www.ibiblio.org/xml/books/bible2/ |
| http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ |
+----------------------------------+---------------------------------+
Re: JDK 1.4 and Xalan
Posted by Edwin Goei <ed...@sun.com>.
Andrew Wason wrote:
>
> Sun is bundling a version of Xalan and Xerces into JDK 1.4s rt.jar.
> http://developer.java.sun.com/developer/bugParade/bugs/4624775.html
>
> But the org.apache.* packages are not part of the JDK API spec and are not
> in the endorsed standards set.
Correct. The following is my understanding (but I have been known to be
wrong in the past).
>
> "The java.*, javax.* and org.* packages documented in the Java 2 Platform
> Standard edition API Specification make up the official, supported, public
> interface." (the org.apache.* packages are not in the spec)
> http://java.sun.com/products/jdk/faq/faq-sun-packages.html
>
> "No other packages from the J2SE platform API specification may be
> overridden." (the org.apache.* packages are not in the overridable list)
> http://java.sun.com/j2se/1.4/docs/guide/standards/index.html
Notice that it says "J2SE platform API" specification here. Further
down the page it states:
"In addition to the packages listed above, which are part of the J2SE
specification, users of Sun's J2SE Reference Implementation may be
allowed to use the Endorsed Standards Override Mechanism to override
implementation-specific classes..."
That clause does allow you to override the implementation packages also.
If you think about it, allowing API packages to be overridden but not
implementation packages does not make sense. For example, it clearly
allows API interface classes in org.w3c.dom to be overridden with newer
versions. However, if the newer version adds a new method say
Document.someNewMethod(), then that implies the current code in the JDK
that implements Document must also supply the new method. That current
code happens to be under org.apache.*, but in general it can occur in
any package. Therefore, it necessarily means that implementation
packages can also be overridden. Because, the implementation classes
can be in an arbitrary package the Java Virtual Machine (JVM) does not
enforce which packages can be overridden. The license is used to
enforce the requirement instead.
By license, I believe that means something like, if you ship a J2SE
implementation and call it "J2SE 1.4" then it must conform to the J2SE
1.4 API spec. This allows apps that depend on the J2SE 1.4 API spec to
be portable across any product called "J2SE 1.4".
BTW, the lib/endorsed mechanism in Sun's JVM is implemented by the same
mechanism as -Xbootclasspath.
I agree that the page could be improved to explain this. Perhaps you
can send that in as feedback.
>
> I think this means that I am not allowed to replace the Xalan
> implementation that ships with JDK1.4 (e.g. by forcing my xalan.jar first
> via -Xbootclasspath/p:). I don't think I would want to do this anyway since
> it would replace internal JDK implementation classes with a version the JDK
> was not tested with. Also doing this makes things more difficult for my
> apps users since I can't just ship an executable jar file with a
> "Class-Path: xalan.jar xerces.jar" entry in its manifest.
Since it sounds like you are distributing an application and not a J2SE
implementation, you can safely tell users to either use the lib/endorsed
method or the non-standard -Xbootclasspath approach that may not be
supported on all JVMs. You can also write your own ClassLoader code to
do what you want.
>
> In addition, since the org.apache.* packages are not part of the JDK 1.4
> API spec (they are just part of it's internal implementation like the sun.*
> packages), this means I should not use internal JDK implementation Xalan
> classes like org.apache.xpath.XPath.
I consider this a separate problem which I need to look more into.
Certainly, if you are distributing a simple app, you can use any of the
previous methods to get it to work. However, if you are distributing a
webapp that will run in a container and the webapp requires a particular
version of the XPath package, then what happens will depend on the
container you are running in. Someone else on this thread pointed to a
BEA WebLogic note about a similar issue.
>
> So it seems that as of JDK 1.4 I can no longer "legally" use Xalan at all -
> I can't use the built in implementation and I can't replace it with my own.
> Sun has usurped the org.apache namespace for their internal JDK
> implementation, shouldn't they be using sun.org.apache or something? Or
> possibly they could load their internal implementation classes
> (org.apache.* and sun.*) via a different ClassLoader so those classes are
> not visible to my application, freeing me to use my own xalan.jar without
> conflicting with or replacing Suns version.
I think I've addressed this question as the first issue above.
-Edwin
RE: JDK 1.4 and Xalan
Posted by Gary L Peskin <ga...@firstech.com>.
Andrew --
Have a look at http://java.sun.com/xml/jaxp/faq.html#pluggability. The
page that you reference
(http://java.sun.com/j2se/1.4/docs/guide/standards/index.html) indicates
at the bottom that "... users of Sun's J2SE Reference Implementation may
be allowed to use the Endorsed Standards Override Mechanism to override
implementation-specific classes such as the org.w3c.dom sub-packages
delivered in Sun's Reference Implementation. See the corresponding
license for details."
The question here is what is the "corresponding license". If it is the
XalanJ license, then you are certainly free to use what ever version of
XalanJ that you'd like. I don't really see any other license that could
qualify as the "corresponding" license.
In any event, to my mind the last sentence of the question in the first
URL above indicates that Sun recognizes that you can use the Endorsed
Standards override mechanism to -legally- use your newer version of
XalanJ.
Gary
> -----Original Message-----
> From: Andrew Wason [mailto:aw@rootbin.com]
> Sent: Friday, February 08, 2002 7:26 AM
> To: xalan-dev@xml.apache.org
> Subject: JDK 1.4 and Xalan
>
>
> Sun is bundling a version of Xalan and Xerces into JDK 1.4s
> rt.jar.
> http://developer.java.sun.com/developer/bugParade/bugs/4624775.html
>
> But the org.apache.* packages are not part of the JDK API
> spec and are not
> in the endorsed standards set.
>
> "The java.*, javax.* and org.* packages documented in the
> Java 2 Platform
> Standard edition API Specification make up the official,
> supported, public
> interface." (the org.apache.* packages are not in the spec)
> http://java.sun.com/products/jdk/faq/faq-sun-> packages.html
>
>
> "No other packages from the J2SE platform API
> specification may be
> overridden." (the org.apache.* packages are not in the
> overridable list)
> http://java.sun.com/j2se/1.4/docs/guide/standards/index.html
>
>
> I think this means that I am not allowed to
> replace the Xalan
> implementation that ships with JDK1.4 (e.g. by forcing my
> xalan.jar first
> via -Xbootclasspath/p:). I don't think I would want to do
> this anyway since
> it would replace internal JDK implementation classes with a
> version the JDK
> was not tested with. Also doing this makes things more
> difficult for my
> apps users since I can't just ship an executable jar file with a
> "Class-Path: xalan.jar xerces.jar" entry in its manifest.
>
> In addition, since the org.apache.* packages are not part of
> the JDK 1.4
> API spec (they are just part of it's internal implementation
> like the sun.*
> packages), this means I should not use internal JDK
> implementation Xalan
> classes like org.apache.xpath.XPath.
>
> So it seems that as of JDK 1.4 I can no longer "legally" use
> Xalan at all -
> I can't use the built in implementation and I can't replace
> it with my own.
> Sun has usurped the org.apache namespace for their internal JDK
> implementation, shouldn't they be using sun.org.apache or
> something? Or
> possibly they could load their internal implementation classes
> (org.apache.* and sun.*) via a different ClassLoader so those
> classes are
> not visible to my application, freeing me to use my own
> xalan.jar without
> conflicting with or replacing Suns version.
>
> Andrew
> --
> Andrew Wason
> /root/bin
> aw@rootbin.com
>