> On Feb 5, 2015, at 3:32 PM, Konstantin Kolinko <kkoli...@apache.org> wrote: > > 2015-02-05 21:12 GMT+03:00 <kkoli...@apache.org>: >> Author: kkolinko >> Date: Thu Feb 5 18:12:31 2015 >> New Revision: 1657653 >> >> URL: http://svn.apache.org/r1657653 >> Log: >> Fix compilation failure in a test class when using JDK 1.5. >> The XPathFactory.newInstance(String, String, ClassLoader) method is @since >> Java 1.6. > …
> For a record, > if I enable the xpathPerformance test (by removing @Ignore annotation) > and run "mvn install" with JDK 1.6, > > using 1-argument version of XPathFactory.newInstance() results in printing > [[[ > Running org.apache.taglibs.standard.tag.common.xml.ForEachTagTest > factory.getClass() = class org.apache.xpath.jaxp.XPathFactoryImpl > ]]] > > using 3-arguments version of XPathFactory.newInstance() results in printing > [[[ > Running org.apache.taglibs.standard.tag.common.xml.ForEachTagTest > factory.getClass() = class > com.sun.org.apache.xpath.internal.jaxp.XPathFactoryIm > pl > ]]] > > So there is a difference. > At the same time, in both cases the test does not complete after > running for 1 hour. I had to abort the tests and kill java process > forked by maven/junit. So here is no difference. > > A comment for @Ignore is "Takes > 20s to run", so I was prepared to > wait, but an hour is more than I expected from that comment. > > Maybe reducing the size of a sample document > ("newBenchmarkDocument(200000)") will help. > > This is not my priority for now. I just run it as I wanted to verify > whether my code change mattered. This test was added when I was evaluating different options for addressing the XPath performance problems from bug #27717. I was trying to find a solution that used the standard JDK XPath APIs rather than having to rely on Xalan’s internal DTM interface. This test was used to distinguish between the JAXP-conformant xpath implementation built into the JDK and the one supplied as part of Xalan. As it turned out, both suffered from the same issue - they are O(N^2) compared to the xalanPerformance test which is O(N). The test is @Ignored as it is just for performance measurement rather than functional testing. I left it in in case anyone wanted to re-run the tests if an improved JDK XPath implementation came out. The 3-arg form here is used to ensure the JRE’s implementation is used rather than Xalan’s. This change breaks that as illustrated above where you can it is using the o.a.xpath version not the com.sun version from the JDK. An alternative might be to instantiate the class using refection as we should not reference a com.sun class directly. Alternatively, we could just revert the change as this just blocks building with JDK5 which is EOL’d (although we still generate Java5 bytecode for the production classes.) — Jeremy
signature.asc
Description: Message signed with OpenPGP using GPGMail