RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays

Sean Mullan mullan at openjdk.org
Wed Dec 3 14:00:47 UTC 2025


On Wed, 3 Dec 2025 08:41:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There are a lot of APIs that return an array. Some of them use an array internally and so need to make a defensive copy/clone to return. Jai may be able to say more on the motivation for JDK-8370688. Maybe a concern with code uses identity to check equality, or maybe the concern was that the caller could modify the JarEntry's certs/signers by modifying the array?
> 
> I don't think the proposed change addresses either concern. We could potentially change the `@return` description to say that it returns a new array, which makes it a testable assertion. There are many other methods that return arrays, including other methods that return arrays of certs and code signers so we might want to change these at the same time.

I agree. The original commit was more aligned with what should be done. For security related information like arrays of certificates, I think the caller often needs to know one way or the other whether mutating the returned value affects the original object's contents. And I think in general, `JarEntry` should be returning a new array each time these methods are called. We can at least ensure that the JDK implementation follows the specification.

> @seanjmullan @wangweij Do you know if there has been any discussion about deprecating getCertificates? Developers have been re-directed to use getCodeSigners since JDK 5.

Not specifically, although I agree that it probably should be deprecated.

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

PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3606987622


More information about the core-libs-dev mailing list