Hi Eirik, I also be we should be OK to remove. That being said, as part of the change, we should update open/test/jdk/sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java Best Lance
On Feb 29, 2024, at 7:38 AM, Jaikiran Pai <jai.forums2...@gmail.com> wrote: Hello Eirik, I think that method (and its references in some test code comments) can be removed. Like you note it's a package private method within the java.util.jar package and I don't see its usage (other than test code comments) anywhere within the JDK repo. That @Deprecated annotation on that method seems to have been introduced as part of https://bugs.openjdk.org/browse/JDK-8066619 (review thread https://mail.openjdk.org/pipermail/core-libs-dev/2018-December/057030.html). I'm guessing it likely was an oversight to have added that annotation to an internal method instead of just removing its usage. -Jaikiran On 29/02/24 3:09 am, Eirik Bjørsnøs wrote: Hi, The non-public method java.util.jar.Manifest.make72Safe is marked @Deprecated(since="13"). However, the Javadoc comment has a '@deprecation' tag which presumably should have been `@deprecated`. I first thought of proposing a PR to fix the invalid tag, but then I noticed that the method is non-public and has no callers in OpenJDK. Not sure I understand why this internal method was marked deprecated in the first place and not simply removed? Are we worried about people calling this reflectively? What would be the best way to go about this? (a) Do nothing (b) Just fix the tag @deprecation -> @deprecated (c) Fix the tag, add forRemoval=true (d) Just delete the method altogether (it's internal after all). Cheers, Eirik. [oracle_sig_logo.gif] Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
