strepsirrhini/office-gobmx
9
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
office-gobmx/jvmfwk
History
Stephan Bergmann c74133420f tdf#151545: Restrict JvmfwkUtil_isLoadableJVM to macOS x86-64 
That check had been added with 32bc8ddbf3
"tdf#94716 allow Oracle's JDK to be used on OS X 10.10 and 10.11", back at a
time when there was substantial trouble with installations of Apple's own Java
and Oracle JREs.  One consequence of that commit and its
JvmfwkUtil_isLoadableJVM check was that on macOS we only supported JDKs (with a
surrounding Contents directory containing an appropriate Info.plist files), not
plain JREs (cf. <https://wiki.documentfoundation.org/ReleaseNotes/5.1#macOS>
"Prior work arounds of having both an Apple JRE 6 and an Oracle JRE 8 are no
longer sufficient.  Use of the JDK is now hard coded, see tdf#74877, tdf#94716
and core commit 32bc8ddbf335dd26019edcf12758643b4cff9913.")

However, Apple's own Java is long since deprecated (cf.
<https://support.apple.com/en-us/HT204036> "You can also download legacy Java SE
6 from Apple if you’re using an app that specifically requires this unsupported,
out-of-date version."), and presumably of no practical concern at least on
contemporary Aarch64-based macOS.

And there is e.g. SDKMAN! (<https://sdkman.io/>), which installs JDKs in a way
that they are not surrounded by Contents directories containing appropriate
Info.plist files, so JvmfwkUtil_isLoadableJVM returned false for them and you
couldn't add them on the LibreOffice Advanced Options tab.

So at least for Aarch64-based macOS, drop that presumably-legacy
JvmfwkUtil_isLoadableJVM check (but keep it for x86-64--based macOS at least for
now, just to be safe).  (That implies that for Aarch64-based macOS, it should
now work again to also use plain JREs.)

Change-Id: I3bcbb3c14e3a9e9dde39fd6f4572b632e05df9e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141508
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-10-18 19:15:07 +02:00
..
distributions/OpenOfficeorg There was a typo in the AdoptOpenJDK java.vendor property value 2021-11-18 09:48:53 +01:00
inc Add loongarch64 support. 2022-08-11 10:53:00 +02:00
plugins/sunmajor tdf#151545: Restrict JvmfwkUtil_isLoadableJVM to macOS x86-64 2022-10-18 19:15:07 +02:00
qa/unit Turn OSL_DEBUG_LEVEL >= 2 SelfTest into CppunitTest 2021-07-08 08:05:26 +02:00
source try harder to remove "OSL_PIPE" pipe on SIGTERM 2022-09-19 18:28:33 +02:00
CppunitTest_jvmfwk_sunversion.mk Turn OSL_DEBUG_LEVEL >= 2 SelfTest into CppunitTest 2021-07-08 08:05:26 +02:00
CustomTarget_jreproperties.mk
CustomTarget_jvmfwk_jvmfwk3_ini.mk
Executable_javaldx.mk
IwyuFilter_jvmfwk.yaml
Library_jvmfwk.mk tdf#151545: Restrict JvmfwkUtil_isLoadableJVM to macOS x86-64 2022-10-18 19:15:07 +02:00
Makefile
Module_jvmfwk.mk Turn OSL_DEBUG_LEVEL >= 2 SelfTest into CppunitTest 2021-07-08 08:05:26 +02:00
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 Updated README.md files 2021-04-19 11:13:41 +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."