Regarding the removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java

[Daniel Fuchs]

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/
>
>>>//
>
>>
>