On Tue, 1 Oct 2024 15:50:59 GMT, ExE Boss <d...@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
