Hi Jason
I noticed several "@SuppressWarnings("deprecation")" in some sun.* or com.sun.*
classes and it makes me feel uncomfortable. The usage of this annotation, if I
understand correctly, means we know we should not use it but we have to use it
because we are lazy or there are no better alternatives. I highly doubt if any
is the case here.
So, we should investigate how those methods are used. If they are strictly
internal (not jdk.exported) and not used inside JDK, remove them since they
will be inaccessible anymore in jdk9. If they are still used somewhere,
consider rewriting them (maybe in another fix). If they are jdk.exported,
rewrite if the deprecated interfaces is not shown in the API itself (type or
argument or return), otherwise, @deprecate them also.
Thanks
Max
> On Mar 5, 2015, at 03:02, Jason Uh <jason...@oracle.com> wrote:
>
> webrev: http://cr.openjdk.java.net/~juh/8073430/00/
> jbs: https://bugs.openjdk.java.net/browse/JDK-8073430
>
> Please review this change, which deprecates the classes in java.security.acl
> and javax.security.cert. These packages have been superseded by replacements
> for a long time.
>
> For java.security.acl, there have been replacement APIs available since JDK
> 1.2 in java.security.Policy and related classes. For javax.security.cert,
> replacements have existed in java.security.cert since JDK 1.4. These
> replacements have been noted in the javadocs, so applications using these old
> APIs have had plenty of time to migrate.
>
> Two methods
>
> HandshakeCompletedEvent.getPeerCertificateChain
> SSLSession.getPeerCertificateChain
>
> that return the javax.security.cert.X509Certificate type will also be
> deprecated.
>
> The change also includes deprecation warning suppression in a few areas,
> including sun.net.www.protocol.https.
>
> Thanks,
> Jason
