On Wed, 28 Aug 2024 15:12:13 GMT, Eirik Bjørsnøs <eir...@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? Thanks for prodding! I have provided an answer to this question in the CSR: https://bugs.openjdk.org/browse/JDK-8338663#comment-14709333 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2384950202
