8ef01413f6
As discussed in the mailing list thread starting at <https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html> "Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)", the bridge implementation at bridges/source/cpp_uno/gcc3_linux_s390 is apparently dead and should thus be removed. However, that was the only bridge implementation for 32-bit S390, which implies that support for the 32-bit S390 architecture as a whole is dead and should thus be removed. Change-Id: I18b3b4fa11df4ce693107bad6bbea2fab1c19f26 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146058 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> |
||
|---|---|---|
| .. | ||
| distributions/OpenOfficeorg | ||
| inc | ||
| plugins/sunmajor | ||
| qa/unit | ||
| source | ||
| CppunitTest_jvmfwk_sunversion.mk | ||
| CustomTarget_jreproperties.mk | ||
| CustomTarget_jvmfwk_jvmfwk3_ini.mk | ||
| Executable_javaldx.mk | ||
| IwyuFilter_jvmfwk.yaml | ||
| Library_jvmfwk.mk | ||
| Makefile | ||
| Module_jvmfwk.mk | ||
| Package_jreproperties.mk | ||
| Package_jvmfwk_jvmfwk3_ini.mk | ||
| Package_rcfiles.mk | ||
| 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."