RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9
Roger.Riggs at Oracle.com
Wed Sep 14 17:15:28 UTC 2016
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.
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
> 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:
>> 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/
More information about the core-libs-dev