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

Chen Liang liach at openjdk.org
Wed Sep 25 15:44:42 UTC 2024


On Wed, 28 Aug 2024 15:12:13 GMT, Eirik Bjørsnøs <eirbjo at openjdk.org> wrote:

>>> I think linking to the CSR would be fine, but there is no prerequisite for API specs to link to CSRs. Need @jddarcy to double check here. I was emulating `Thread.stop`:
>>> 
>>> https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/java.base/share/classes/java/lang/Thread.java#L1637
>> 
>> I am not suggesting link to the CSR, what I was indicating the CSR provides more details  because of the proposed removal.
>> 
>> Comparing to `Thread::stop` is not quite the same, and  the verbiage you are pointing to above was added when the method was [degraded to throw a UOE](https://bugs.openjdk.org/browse/JDK-8277861), not  when it was [deprecated for removal](https://bugs.openjdk.org/browse/JDK-8277861)
>> 
>> The overall usage of ZipError is extremely minimal in the wild at best, from what I can tell was in a catch statement and was not documented to be thrown by any public  API, though was thrown by ZipFile's internal ZipEntryIterator::next
>> 
>> If this was a more heavily used Exception, it would probably warrant further consideration for additional documentation, I am not convinced it is needed here
>
> Thanks @LanceAndersen and @liach for your patient reviews.
> 
> I have updated the Specification section of the CSR and moved it to the Proposed state for an initial round of reviews:
> 
> https://bugs.openjdk.org/browse/JDK-8338663

@eirbjo Can you answer CSR review question about whether to just deprecate the constructor of `ZipError` for removal at the CSR?

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

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


More information about the core-libs-dev mailing list