Hi Christoph,
Instead of trying to access
com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java in your
test - would it be possible for
your test to embed that functionality instead?
I am not sure how much sense that makes - the workings of that
class seemed a bit convoluted - and not quite adapted to the
JAXP implementation embedded in the JDK itself, but I was
wondering whether you could apply the same technique than what
we did when removing the internal xalan/xslt Process class which
was not used either:
http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.01/
If you really need EnvironmentCheck.java, then embedding it in
your test is probably the better option, as it will allow you
to 'fix it' to work with jdk9/jigsaw as well (e.g. using the
jrt: File System instead of sun.boot.class.path etc...)
best regard,
-- daniel
On 1/26/16 12:49 AM, Langer, Christoph wrote:
Hi,
as I was using the xslt EnvironmentCheck class in my private testcase
and recognizing it didn’t exist anymore in JDK 9, I stumbled over this
thread from last July below.
I understand that you want to clean up and remove unnecessary code but I
found the class quite useful as it would some up several (to me
seemingly) interesting jaxp version information. The other Version.java
class was removed, too. Was the information collected by these classes
really that crappy that it could just be removed? Where would I get my
XML version information from now?
Thanks and best regards
Christoph
On 7/28/2015 10:32 AM, Daniel Fuchs wrote:
/On 28/07/15 19:20, huizhe wang wrote:/
/Hi Daniel,/
//
//
/On 7/28/2015 8:22 AM, Daniel Fuchs wrote:/
/Hi,/
//
/Please find below a fix for yet another cleanup for jaxp:/
//
/Thanks for yet another cleanup! And, there is a lot more to come :-)/
//
/8130059: jaxp: Investigate removal of/
/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java/
///https://bugs.openjdk.java.net/browse/JDK-8130059///
//
///http://cr.openjdk.java.net/~dfuchs/webrev_8130059/webrev.00/
<http://cr.openjdk.java.net/%7Edfuchs/webrev_8130059/webrev.00/>///
//
/EnvironmentCheck doesn't seem to serve any purpose in JDK 9./
//
/Agree. It'd be a confusion more than anything else if used since it/
/produces many irrelevant information./
//
/It is not called anywhere. The proposal is to remove it./
/By doing a full grep on the JDK I also identified another/
/unused class (Hashtree2Node.java) which referred to EnvironmentCheck/
/inside a comment./
/I took the liberty to remove that class as well./
//
/Ok. The webrev looks good to me. If you'd want to remove the two/
/Version classes as shown in the test, that would be fine with me too./
/Then you could remove the whole test./
//
/Thanks Joe!/
//
/One of the two version classes (xalan) is used by ...xslt.Process.java/
/I already logged another bug to investigate removing that as/
/well (JDK-8130058)./
Great!
//
/Maybe we should remove the two versions classes as part of that/
/other bug? Or I could update my webrev to just remove the xerces/
/Version.java now, which as far as I can see is not called anywhere./
//
/As you prefer :-)/
I agree as you planned, considering removing the two version classes in
JDK-8130058.
Cheers :-)
Joe
//
/cheers,/
//
/-- daniel/
//
//
/Best regards,/
/Joe/
//
//
/As for the latter cleanup, what triggered this is that EnvironmentCheck/
/is using sun.boot.class.path.../
//
/best regards,/
//
/-- daniel/
//
