On Sat, 24 Aug 2024 10:16:55 GMT, Eirik Bjørsnøs <eir...@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
