Submitted On 23-JAN-2002
jskeet
Is this what the Endorsed Standards mechanism is for?
(http://java.sun.com/j2se/1.4/docs/guide/standards/index.htm
l)
It's unclear whether it's there to allow people to upgrade
the interfaces themselves (as listed) or the
implementations of those interfaces.
Submitted On 06-FEB-2002
aw
Even if xalan/xerces were put in the extensions directory,
that doesn't help. I would need to tweak my customers JRE
installation, and doing that might break other Java
applications they run.
I think Sun should use different package names for the
org.apache stuff to isolate it from the version of the APIs
that an application is using - all Sun implementation
detail classes should be in com.sun.* or sun.* packages.
The org.apache packages aren't a documented public API or
endorsed standard in JDK1.4, so if I want to use something
like org.apache.xpath.XPath in my app, I have to ship my
own xalan.jar - I can't rely on the implementation in the
JDK since it is an internal implementation detail.
If I ship my own xalan.jar, and force the JDK to use it
(via -Xbootclasspath/p: or whatever), then I am replacing
JDKs internal implementation with one it has not been
tested with.
Here is a simple testcase that works under JDK1.3 with
xalan/xerces, but fails to run under JDK1.4 with this
exception:
Exception in thread "main" java.lang.NoSuchMethodError:
org.apache.xpath.objects.XObject.mutableNodeset()
Lorg/apache/xpath/NodeSet;
at XTest.main(XTest.java:24)
I assume this is because rt.jar contains older xalan/xerces
implementations.
import java.io.FileInputStream;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import org.apache.xml.utils.PrefixResolverDefault;
import org.apache.xpath.NodeSet;
import org.apache.xpath.XPath;
import org.apache.xpath.XPathContext;
import org.apache.xpath.objects.XObject;
import org.w3c.dom.Document;
public class XTest {
public static void main(String args[]) throws
Exception {
if (args.length != 2) {
System.err.println("Usage: XTest
<xml-file> <xpath-expr>");
System.exit(1);
}
DocumentBuilder db =
DocumentBuilderFactory.newInstance().newDocumentBuilder();
Document document = db.parse(new
FileInputStream(args[0]));
PrefixResolverDefault resolver = new
PrefixResolverDefault(document);
XPath xp = new XPath(args[1], null,
resolver, XPath.SELECT, null);
XObject xo = xp.execute(new XPathContext(),
document, resolver);
NodeSet ns = xo.mutableNodeset();
System.out.println(ns.getLength());
}
}
Submitted On 15-FEB-2002
poelsgeert
The Xbootclasspath option worked for me but it remains
weird why they didn't use the extensions for this.
Including external libraries still in full development and
undergoing major rewrites is very odd to say the least.
IMHO, I wouldn't mind even Sun libs to be remain separated
and upgradable through this mechanism.
Submitted On 02-JUL-2002
plexusnexus
This is clearly a bug and a flub under the aspect of
configuration management.
Submitted On 14-JUL-2003
Eddy-CA
This is stupid and the endorsed thing is just a stupid way to
get around this mispackaging.
This should be considered as a bug and the fix should come in
the next release.
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
