On 02/06/2018 06:45, David Holmes wrote:
On 2/06/2018 11:07 AM, Stuart Marks wrote:
On 6/1/18 5:15 PM, David Holmes wrote:
I would expect the CSR that marked them as deprecated for removal,
also serves for the actual removal. Certainly for VM flags we don't
do a separate CSR for each phase (deprecation, obsoletion, expiration).
Hm. Well, this hasn't been tested for Java SE APIs yet, as most of
the deprecations-for-removal occurred in Java SE 9, before the CSR
was active. Instead, those deprecations went through the (Oracle
internal) CCC process.
Now that we're fully on the CSR system, I'd expect that deprecations
(whether or not for removal) and removals of Java SE APIs would have
separate CSR requests. The reason is that adding or changing a
deprecation annotation is a spec change, and removing the API is a
distinct spec change. They also occur in different releases.
Good points. Though given the annotation is on the method being
removed it's really only one spec change.
Adding @Deprecated(forRemoval=true) in one release and then removing the
element in a later release has to be tracked as two spec changes, and
thus two CSRs. There may be more steps of course. In the case of
Thread.stop(Throwable) under discussion here, and several
SecurityManager methods, the methods were "degraded" (to always throw an
exception or only check AllPermission in the case of the SM methods)
before removal. So that's another intermediate spec change that has to
be tracked via the CSR.
-Alan
