office-gobmx/jvmfwk
Stephan Bergmann 81debfba86 Restrict macOS ARM64 to Java >= 17
The commit message of e529461bcb "Enable JVM also
on macOS ARM64" had identified
<https://cdn.azul.com/zulu/bin/zulu17.0.63-ea-jdk17.0.0-ea.27-macosx_aarch64.zip>
"to work reliably now" while other (older Zulu) JVMs "have always crashed with
SIGBUS that smelled like our uses of pthread_jit_write_protect_np in
bridges/source/cpp_uno/shared/vtablefactory.cxx colided with corresponding calls
in the in-process JVM".  Those observations would be in line with
<http://openjdk.java.net/jeps/391> "JEP 391: macOS/AArch64 Port" only
implemented for Java 17 now (see
<dbc9e4b50c>
"8253795: Implementation of JEP 391: macOS/AArch64 Port").

So for macOS ARM64 assume that all OpenJDK variants (i.e., providing an empty
jvmfwk/distributions/OpenOfficeorg/javavendors_macosx_aarch64.xml) of at least
Java 17 (i.e., building on recent 3460c16d7f
"Make getVersionInformation always return a VersionInfo" and "change the
hardcoded '1.8.0' to '17' for just that one platform") work.

Change-Id: I11e8ba232cee066a25a49edebd0cc50e24e84124
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123989
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-21 15:13:42 +02:00
..
distributions/OpenOfficeorg Restrict macOS ARM64 to Java >= 17 2021-10-21 15:13:42 +02:00
inc Make getVersionInformation always return a VersionInfo 2021-10-21 12:42:03 +02:00
plugins/sunmajor Make getVersionInformation always return a VersionInfo 2021-10-21 12:42:03 +02:00
qa/unit
source Restrict macOS ARM64 to Java >= 17 2021-10-21 15:13:42 +02:00
CppunitTest_jvmfwk_sunversion.mk
CustomTarget_jreproperties.mk
CustomTarget_jvmfwk_jvmfwk3_ini.mk
Executable_javaldx.mk
IwyuFilter_jvmfwk.yaml
Library_jvmfwk.mk Drop support for dead GNU Java 2021-10-20 21:33:53 +02:00
Makefile
Module_jvmfwk.mk
Package_jreproperties.mk
Package_jvmfwk_jvmfwk3_ini.mk
Package_rcfiles.mk Restrict macOS ARM64 to Java >= 17 2021-10-21 15:13:42 +02:00
README.md

JVM Framework Wrappers

Wrappers so you can use all the Java Runtime Environments with their slightly incompatible APIs with more ease.

Used to use an over-engineered "plugin" mechanism although there was only one "plugin", called "sunmajor", that handles all possible JREs.

IMPORTANT: The <updated> element in vmfwk/distributions/OpenOfficeorg/javavendors_*.xml files should only be updated for incompatible changes, not for compatible ones. As stated in the commit message of https://gerrit.libreoffice.org/#/c/69730/ in LibreOffice gerrit:

javavendors_*.xml <updated> should not have been updated...

Changing <updated> causes jfw_startVM and jfw_getSelectedJRE (both jvmfwk/source/framework.cxx) to fail with JFW_E_INVALID_SETTINGS, which in turn causes functionality that requires a JVM to issue a GUI error dialog stating that the user must select a new JRE in the Options dialog. While that behavior makes sense if a JRE was selected that would no longer be supported by the modified javavendors_*.xml, it is just annoying if an already selected JRE is still supported. And a compatible change to javavendors_*.xml implies that an already selected JRE will still be supported."