RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v3]

[Chen Liang]

On Tue, 1 Oct 2024 15:50:59 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Eirik Bjørsnøs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into ziperror-deprecation
>>  - Simplify the deprecation note by focusing on behavior in the current release
>>  - Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError
>>  - Update copyright year
>>  - Deprecate java.util.zip.ZipError for removal
>
> The issue with removing `ZipError` (or any other exception class, such as `SecurityException`), is that existing classes which reference it in the `exception_table` of a `Code` attribute will fail verification.
> 
> --------------------------------------------------------------------------------
> 
> This is different from referencing removed classes in method or field descriptors, those get treated as if they had the following declaration for the purposes of verification when determining whether `checkcast`s are necessary:
> 
> public abstract final class <name> extends Object {
> }

@ExE-Boss Indeed, the removal is intended to be binary incompatible. Just like the example in [the fucntional removal of SecurityManager(https://openjdk.org/jeps/486), users can instrument or statically preprocess their `java/util/zip/ZipError` class entries to `java/lang/InternalError` similar to the preprocessing of `System::exit` calls.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2386449193