Hi, thanks for asking about this.
There's not much process, but there unfortunately is some that isn't quite
written down yet. :-) Essentially something must be deprecated for removal in
some release prior to it actually being removed in a subsequent release. In the
"old days" of multi-year releases, marking for removal in one release and
removing it in the next seemed reasonable. In the new model of six-month
releases, removing something in the very next release seems too soon. We're
currently thinking that typically one should remove a feature no sooner than the
second release after it's marked for removal, unless there's a compelling reason
to remove it more quickly.
In this case the bug report (JDK-8227024) says that the APIs in question were
marked for removal in JDK 9. But Xuelei's message says that they were deprecated
(ordinarily, i.e., not-for-removal) in JDK 9, and then deprecated for removal in
JDK 13. That looks right, since the JDK 12 docs don't mention deprecation for
removal.
I also note that the deprecation annotation says since="9" which is the release
in which deprecation first appeared, but not the release in which
forRemoval=true was added. It isn't very clear whether this is the date of first
deprecation or date at which forRemoval=true was added. I should think about
clarifying the spec in that regard.
In any case, it's probably premature to remove these APIs from JDK 14. If it's
reasonable to do so, I'd suggest postponing the removal until JDK 15.
s'marks
On 7/8/19 12:28 PM, Bradford Wetmore wrote:
I'm not completely up on the nuances of the overall removal process, but
codewise it looks good.
Brad
On 7/8/2019 8:02 AM, Xuelei Fan wrote:
Hi,
Please review the following update for JDK 14:
http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/
and the CSR:
https://bugs.openjdk.java.net/browse/JDK-8227395
The javax.security.cert APIs were deprecated in Java SE 9 and marked for
removal in Java SE 13. Applications should use the java.security.cert APIs
instead.
Thanks,
Xuelei
