On Wed, 3 Dec 2025 08:41:55 GMT, Alan Bateman <[email protected]> wrote:
> 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? What prompted me to file JDK-8370688 is that there's an internal class in the JDK (URLJarFileEntry) which extends `JarEntry` and overrides `getCodeSigners()` and `getCertificates()` to merely clone the returned array. With the way these 2 methods are implemented in `JarEntry`, the returned array is already cloned. So `URLJarFileEntry.getCodeSigners()/getCertificates()` ends up cloning that array twice. The intention of the JBS issue was to have JarEntry specify this current implementation, so that these sub classes of JarEntry can then rely on that specification and don't have to do the clone() themselves. The current proposed text in this PR, I think, needs to be more precise. The way it's worded currently doesn't allow for applications (or JDK internal classes) to rely on the returned array being a copy of the underlying one. As far as I remember, we have similar text in some API specification for methods that return a copy of the array, reusing that text might be useful (I'll try and find such an instance). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3605890862
