On Tue, 27 Aug 2024 19:49:01 GMT, Eirik Bjørsnøs <[email protected]> wrote:
> > The javadoc should be focused on the current JDK release, not the prior
> > history of this Class
>
> Makes sense, let's focus on the current release.
>
> > ```
> > * @deprecated ZipError is deprecated and subject to removal in a
> > * future release. This class is obsolete. Use {@link ZipException}
> > instead.
> > ```
>
> The leading sentence here seems redundant, since it mostly just repeats the
> heading generated by javadoc:
>
> **Deprecated, for removal: This API element is subject to removal in a future
> version** _ZipError is deprecated and subject to removal in a future release.
> This Error is obsolete and no longer thrown. Use ZipException instead._
True, I kept it as it aligns with what was done for SecurityManager and is
sightly more specific. as to the element being subject to removal.
That being said, I am OK with dropping it if we get approval in the CSR.
>
> What do you think of dropping that first sentence, such that the rendered
> result would be:
>
> **Deprecated, for removal: This API element is subject to removal in a future
> version** _ZipError is obsolete and is no longer thrown. Use ZipException
> instead._
>
> (One might argue that _is no longer thrown_ hints at different behavior in
> past releases, but I still think it helps to clarify that code running on the
> current release need not worry about catching this error)
As I mentioned above, I am OK, with dropping it
Other options could be:
_ZipError is obsolete and is no longer used. ZipException should be used
instead_
or
_ZipError is no longer used and is obsolete. ZipException should be used
instead_
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20642#discussion_r1733485970
