On Wed, 3 Dec 2025 08:41:55 GMT, Alan Bateman <[email protected]> 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
