RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

[Roger Riggs]

Hi,

I don't see there is much point in deprecating an API that is not exported.
It doesn't show up in the javadoc and the compiler overrides with 
-addexports would already be needed.

The internal uses should be updated but that should not be a reason to 
put off warning other
consumers that a transition to another API is needed.  One of the 
purposes of @deprecated is to start
a very slow/long process moving.

$.02, Roger


On 9/14/2016 5:11 AM, Daniel Fuchs wrote:
> Hi Joe,
>
> As much as I would like to support removing obsolete
> classes, I wonder if the forRemoval=true is a bit
> premature.
>
> I see that for instance, com.sun.org.apache.xml.internal.resolver.Catalog
> seems to be still used at many places in our code base.
>
> It would be more convincing if we could first make our
> own codebase stop using these classes: then we could
> be confident that forRemoval=true is the better choice!
>
> best regards,
>
> -- daniel
>
> On 14/09/16 05:48, Joe Wang wrote:
>> Hi,
>>
>> Please review the deprecation of the internal Catalog API.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8165784
>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/
>>
>> Thanks,
>> Joe
>