On Fri, 15 Nov 2024 01:05:10 GMT, ExE Boss <d...@openjdk.org> wrote: >> Doesn't this break any apps that use these offsets? Aren't these fields >> part of the public API of Unsafe, so changing them requires a CSR? > > @dean-long >> Doesn't this break any apps that use these offsets? Aren't these fields part >> of the public API of Unsafe, so changing them requires a CSR? > > This is the encapsulated JDK‑internal `Unsafe` in `java.base`, not the legacy > `sun.misc.Unsafe`.
> > @ExE-Boss , are you saying the CSR doesn't apply to jdk.internal.*? The CSR > > FAQ says: "Changes to public and exported APIs in jdk.*packages." Whether > > or not it needs a CSR, I think there are apps outside the JDK that will > > break because of this change. > > jdk.internal.** is JDK internal, none of these packages are exported. It's > okay to make changes in any release, any builds. Nothing outside of the JDK > should be depending on internal APIs like this. Netty, for example, has code to access jdk.internal.misc.Unsafe through reflection. Should the CSR FAQ be updated to remove references to `jdk.*,` or are there some jdk.* packages that require a CSR? As far as I can tell, none are exported. If later on someone decides to change these fields again, maybe to something like short, char, or byte, that better represents the possible value range, then we get the overflow problem again. How do we guard against that? Do we have regression tests for the overflow problem? There are other idioms we could use if casting with (long) is considered ugly. For example: long ARRAY_BYTE_BASE_OFFSET = Unsafe.ARRAY_BYTE_BASE_OFFSET; long offset = ARRAY_BYTE_BASE_OFFSET + index; long offset = Unsafe.ARRAY_BYTE_BASE_OFFSET; offset += index; long offset = Long.sum(Unsafe.ARRAY_BYTE_BASE_OFFSET, index); ------------- PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2492848291
