Regarding the removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
christoph.langer at sap.com
Mon Jan 25 23:49:27 UTC 2016
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
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:
>>> 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
>>> 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).
> 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
> -- daniel
>> Best regards,
>>> As for the latter cleanup, what triggered this is that EnvironmentCheck
>>> is using sun.boot.class.path...
>>> best regards,
>>> -- daniel
More information about the core-libs-dev