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
