RFR: 8336843: Deprecate java.util.zip.ZipError for removal

[Lance Andersen]

On Sat, 24 Aug 2024 10:16:55 GMT, Eirik Bjørsnøs <eirbjo at openjdk.org> wrote:

>> On a corpus search, found
>> org.eclipse.jdt.core/search/org/eclipse/jdt/internal/core/search/indexing/AddJarFileToIndex.java references ZipError (16 usages)
>> 
>> sbt/internal/inc/zip/ZipCentralDir.java referenced ZipError(was based off an old copy of ZipFS I believe), the file does not seem to be part of the GitHub repository and there are 5 usages
>> 
>> com/aoapps/lang/Throwables.class  and com/aoindustries/lang/Throwables.class (clone of each other I believe) 
>> 
>> com/android/tools/apk/analyzer/internal/ArchiveManagerImpl. ( 1 usage)
>> 
>> 
>> So would be good to also alert those projects if possible
>
>> So would be good to also alert those projects if possible
> 
> I guess the deprecation warning itself is the "official" channel for communicating this type of information. But I agree it doesn't hurt to alert at least some of the larger projects, on a best-effort bases. So I have reached out to the following projects by reporting issues:
> 
> * Eclipse JDT: https://github.com/eclipse-jdt/eclipse.jdt.core/issues/2856
> * SBT / Zinc: https://github.com/sbt/zinc/issues/1385    
> * Android Studio apkparser: https://issuetracker.google.com/issues/361862739

> @eirbjo I have updated the CSR to describe the solutions from both our and user sides.
> 
> I think you can update the class Javadoc to something like:
> 
> ```java
> /**
>  * A legacy error for invalid ZIP format from argument incorrectly regarded as an internal error.
>  * This extends {@code InternalError} to maintain compatibility with preexisting client code catching
>  * {@code InternalError}.
>  * 
>  * @deprecated
>  * This error is not suitable to indicate an exception for a general ZIP file; use {@link
>  * ZipException} instead.
>  * <p>
>  * {@code ZipError} fell out of use in the reference implementation in release 9 when the native ZIP
>  * API was brought over to Java. Its last uses was in ZipFile and the demo zipfs in release 8.
>  * <p>
>  * Code bases supporting release 8 should update to catch InternalError instead. Old binaries can
>  * use bytecode patching to upgrade CONSTANT_Class references to {@code java/util/zip/ZipError} in
>  * exception handler ranges to {@code java/lang/InternalError}.
>  */
> ```
> 
> I don't know if we should include such an excerpt:
> 
> ```java
> /**
>  * <p>
>  * In a future release, implementation of {@code ZipError} will be removed before this class itself
>  * is removed; at that point, {@code ZipError} can no longer be constructed or used, but can still
>  * be compiled against as an aid in migration.
>  */
> ```
> 
> I left the questions in CSR comment section; hope Joe Darcy can give us some advice here.

While I agree an `@deprecated` note should be added, I do not feel it needs to be that verbose.  I would simply borrow from what was done for `SecurityManager`.  The CSR can provide some more background


I also do not see a need to anything WRT the constructors as that is overkill IMHO.   

A release note will also go with this change which can  suggest that code that also must support JDK 8 leverage InternalError

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

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