On Wed, 24 May 2023 13:56:05 GMT, Julian Waters <jwat...@openjdk.org> wrote:
> On Windows, the basic Java Integer types are defined as long and __int64 > respectively. In particular, the former is rather problematic since it breaks > compilation as the Visual C++ becomes stricter and more compliant with every > release, which means the way Windows code treats long as a typedef for int is > no longer correct, especially with -permissive- enabled. Instead of changing > every piece of broken code to match the jint = long typedef, which is far too > time consuming, we can instead change jint to an int (which is still the same > 32 bit number type as long), as there are far fewer problems caused by this > definition. It's better to get this over and done with sooner than later when > a future version of Visual C++ finally starts to break on existing code I think the JNI type definition change is okay. However many of the other changes appear to me to not involve Java variables and so don't need to be Java types i.e they should be `int` rather than `jint` - though as these are native Windows types there may not actually be any reason to change them from `long`. This is for the client-libs folk to decide. src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 325: > 323: } > 324: > 325: jint sx, sy, ex, ey; These are not Java variables. They get passed to the win32 GDI Arc function below which expects `int`. src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 605: > 603: return; > 604: } > 605: jint sx, sy, ex, ey; Again these don't seem to need to be Java types. ------------- PR Review: https://git.openjdk.org/jdk/pull/14125#pullrequestreview-1442950619 PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1204903525 PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1204904147
