summaryrefslogtreecommitdiff
path: root/jvmfwk
AgeCommit message (Collapse)Author
2023-06-27loplugin:stringstatic look for more stringsNoel Grandin
that can be initialised at compile-time instead of runtime Change-Id: I08d516fdc13a3a79f93c079f89ac44cbc7a1ed71 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153620 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-21Allow bootstrap variables in Java user classpath settings, 2nd trySamuel Mehrbrodt
Add a second mode: When a classpath starts with '$', bootstrap variables are recognized. The classpath must then be provided as URL, not native path. Change-Id: Idcc229a2b4e9a512b0e712ea932a6e4293907db3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152899 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-06-08Revert "Allow bootstrap variables in Java user classpath settings"Samuel Mehrbrodt
This breaks existing paths which contain "\" or "$". This reverts commit cfc2376f804f13eb562f39182cb24fe7dc61d6ef. Change-Id: Ia58df0a4f061f45140575e89231bd18d044a9bc1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152604 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2023-05-25Allow bootstrap variables in Java user classpath settingsSamuel Mehrbrodt
This allows for relative paths to be configured as Java class path. Change-Id: Ie3e6bc3836fb316457e5c9f11dfb77d2fcd49ad4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152271 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2023-04-11accept aarch64 JDK for win/aarch64Christian Lohmaier
the check is only done for windows & mac since the property can have arbitrary values - in OpenJDK it is hardcoded for windows, but for other platforms it can come from autoconf. For a more detailed explanation see f05a42ef8c8192186f91a169047742e5c3ae9b9e Change-Id: I8555ef3b7153a9b744b45cf07deae3c3a1d48ae3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150119 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2023-03-30loplugin:stringadd in variousNoel Grandin
when applying my upcoming patch to also consider O[U]StringBuffer Change-Id: I8cf6a47ad357ddc73e2c430d966be72d5efd1485 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149767 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-03-14elide some temporary OStringsNoel Grandin
where we can pass a string_view into OStringToOUString Change-Id: If7803ba49aa15f6e9c7bd386d32fb84003155390 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148844 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-27Remove support for 32-bit S390Stephan Bergmann
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>
2023-01-27Remove support for AIXStephan Bergmann
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_aix_powerpc is apparently dead and should thus be removed. However, that was the only bridge implementation for AIX, which implies that support for the AIX platform as a whole is dead and should thus be removed. Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-24loplugin:unusedfields make some fields privateNoel Grandin
this is one of the secondary analyses this plugin performs Change-Id: I1c496e234513362338600180e51f7e71e605a7cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143180 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-11-10Add riscv64 supportSakura286
1. Configure gbuild 2. Add UNO Bridge for riscv64 Till now base function works well on riscv64. The bridgetest has passed. Test on Debian, Gentoo and openEuler. Credits: - Heiher <r@hev.cc> and Stephan Bergmann <sbergman@redhat.com> The riscv64 bridge implementation refers to mips64 and AArch64 bridges. - Bo Yu <tsu.yubo@gmail.com> configures gbuild for riscv64. - WANG Xuerui <xen0n@gentoo.org> provides lots of guiding tips. Change-Id: Ifad3b0de8b2c9e7328627ed03396bbd45a9c71e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137445 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2022-10-18tdf#151545: Restrict JvmfwkUtil_isLoadableJVM to macOS x86-64Stephan Bergmann
That check had been added with 32bc8ddbf335dd26019edcf12758643b4cff9913 "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-09-23Fix a misuse of two-argument std string_view rfindStephan Bergmann
...introduced in 655b6c2f46a73d9893ba8e6b572731a5890a4f72 "loplugin:stringviewparam". Unlike its O[U]String lastIndexOf(x, n) counterpart (which looks for the last x whose end position, exclusive, is <= n), string_view rfind(x, n) looks for the last x whose start position, inclusive, is <= n. (So here would have left slash unchanged.) (And the seemingly simpler jvm_dll.rfind('\\', slash - 1) would fail when slash is zero, as in that case it would call rfind with a second argument of npos, i.e., search for the last '\\' in the complete jvm_dll.) Change-Id: I148a5db860d4b9e9d58a4a8847880a7a7020c5a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140486 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-09-19try harder to remove "OSL_PIPE" pipe on SIGTERMCaolán McNamara
a) When oosplash got SIGTERM it used SIGKILL on soffice.bin, (concealed behind osl_terminateProcess) so soffice.bin has no chance to cleanup. Try SIGTERM, followed by SIGKILL if that doesn't work, to give soffice.bin a chance. b) java intercepts SIGTERM so if JNI_CreateJavaVM was called then our SIGTERM handler doesn't get called. Add -Xrs to jvm args to avoid this. Change-Id: I09f93d8093bc7c094482eda73b4eadc5a6cebb83 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140152 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-11Add loongarch64 support.wjh-la
Loongarch is a new RISC ISA , which includes a 32-bit version and a 64-bit version, Here are some documents about Loongarch： https://github.com/loongson/LoongArch-Documentation. The loongarch64 bridges implementation refers to mips64 bridges, and the code related to abi and asm has been modified Change-Id: I1d9cd3aadf63046c8cdecc9a64842567bfa1cecc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137486 Tested-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-07-21elide some makeStringAndClear() callsNoel Grandin
Change-Id: I8636102554a76f2ba3f6297219b40761473a4489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137285 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-06-21clang-tidy modernize-pass-by-value in io..jvmfwkNoel Grandin
Change-Id: I6e19d4d03957c35caa79a231927eae04ae630442 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136209 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-05use more o3tl::getTokenNoel Grandin
found by inspecting call sites of OUString::getToken Change-Id: I4269c7476c7aa46fac39528227e350568f0eb34a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132644 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-04Some JREs need the bin/server/jvm.dll path after allStephan Bergmann
...which had been removed in 18bdf78e156f3cd1e6ccbb3ae28e919583bac70c "Azul is just another OpenJDK variant", when fixing the previously mis-classified Azul JRE from "uses OtherInfo" to "uses SunInfo". But the IBM Semeru Runtime (<https://developer.ibm.com/languages/java/semeru-runtimes/downloads/>) is another arguably mis-classified case due to its java.vendor of "IBM Corporation" (and where the VENDOR_MAP_ENTRY<OtherInfo>("IBM Corporation"), line in jvmfwk/plugins/sunmajor/pluginlib/vendorlist.cxx might be relevant for some other JRE from IBM; at least, that entry is present ever since the introduction of vendorlist.cxx in 738e9b77b9d181b376188e405e1eb353cf93c597 "INTEGRATION: CWS jl8"). So just generally support the bin/server/jvm.dll path here for "uses OtherInfo", even though it should actually only be necessary for "uses SunInfo". (See the mail thread starting at <https://listarchives.libreoffice.org/global/users/2022/msg00246.html> "[libreoffice-users] LibreOffice 7.3.3.2 Windows 64 bit seems not detect AdoptOpenJdk JRE Windows 64 bit runtime".) Change-Id: I3a4d02309b7c833c3cd32dc2dda4f4cb7b216693 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133827 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-15use more string_view in jvmfwkNoel Grandin
Change-Id: I05f3b171578b8fef5b15dcbbf10ae9b7cf2d1b02 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133075 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-13loplugin:stringviewparam whitelist some more functionsNoel Grandin
for which we have o3tl:: equivalents Change-Id: I4670fd8b703ac47214be213f41e88d1c6ede7032 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132913 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-12loplugin:stringview more o3tl conversionNoel Grandin
look for call sequences that can use string_view and the new o3tl functions in o3tl/string_view.hxx Also add a few more wrappers to said #include file Change-Id: I05d8752cc67a7b55b0b57e8eed803bd06bfcd9ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132840 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-04-10loplugin:stringviewparamStephan Bergmann
Change-Id: I62a7534844006a7bf3c2ece5e5d2f8b739a15b9f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132762 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-15Allow for java.version consisting of four dotted segmentsStephan Bergmann
...like "11.0.14.1" reported now by java-11-openjdk-headless-11.0.14.1.1-5.fc35.x86_64, and which caused > warn:jfw:274674:274674:jvmfwk/plugins/sunmajor/pluginlib/sunjre.cxx:100: [Java framework] sunjavaplugin.so does not know the version: 11.0.14.1 as valid for a SUN/Oracle JRE. (For simplicity, cover it with the same code block that already covers a potential "_01" etc. part following the official(?) three dotted segments.) Change-Id: Id98235d3be59653ab412f9b6c1ffbf3b0470bd6f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131586 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-11new loplugin:trivialdestructorNoel Grandin
look for potentially trivial destructors that can then be elided Change-Id: I435c251bd4291b5864c20d68f88676faac7c43fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131318 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-02-22Replace some fprintf with SAL_WARNStephan Bergmann
Change-Id: I3f31f223b6e906c6b40415a8d5c66c27e3c7cff5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130338 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-22Remove a debug-style fprintfStephan Bergmann
...that had been added in 811de66d7fd8c93c43d8e4e2dc73720033ba939b "First attempt at getting access to the Java VM on Android", together with another fprintf(stderr, "Got lo_get_javavm = %p", lo_get_javavm); that had meanwhile been removed again in 5510127e89d6971a219ce3664e4631d6c6dda2b1 "Android code refactorig and hacking" Change-Id: I1a50563e2af1ea5a0ecbd2cc9d49d70c6e5bbbd3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130337 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Jenkins
2022-02-21Avoid unnecessary empty -Djava.class.path=Stephan Bergmann
Change-Id: Idcfe7321077b60381c0273910b1faeb444ef1fd8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130242 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-01-27Recheck modules [i-l]* with IWYUGabor Kelemen
See tdf#42949 for motivation Change-Id: I758bb27e93779e3df21c463714e49354748f446f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128715 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-12-07loplugin:unnecessaryvirtualNoel Grandin
Change-Id: I231195c36d620254cbcd2f4d7bbb9044f7887fe8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126413 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-11-18There was a typo in the AdoptOpenJDK java.vendor property valueStephan Bergmann
...ever since 61c4f96d6ae6a80370774e53287edb27cbce8067 "Support AdoptOpenJDK": At least the old AdoptOpenJDK 1.8.0_275 I had lying around on macOS reported it as "AdoptOpenJDK", not "AdoptOpenJdk". But instead of fixing all occurences of "AdoptOpenJdk", we can just as well get rid of that vendor listing completely now after 3d27b2fa9c5a03f78e5145377402f8a88e3da1be "tdf#124503: Support JRE installations with unknown java.vendor property" and 3460c16d7f749d8d2a59d8b927df5ec31f64a083 "Make getVersionInformation always return a VersionInfo ...even for JREs not listed in javavendors.xml, making it default to a VersionInfo with sMinVersion = "1.8.0". (For a rationale for not updating the <updated> elements of the modified jvmfwk/distributions/OpenOfficeorg/javavendors_*.xml see the commit message of 95c38f6d77f1cb6ff3dc229c5e7130b2e732891d "Drop support for dead GNU Java".) Change-Id: Iea34914201f604a0665a86dd07724628fa021c90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125402 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-17tdf#144695 VendorBase::isValidArch also for macOSStephan Bergmann
Lets extend it only to macOS (where there is some confusion now with Rosetta- translated vs. native processes on Apple M1 machines), not to all Unix-like OSs: The comment that it "is not defined what the exact [os.arch] values are" is still relevant. At least for OpenJDK, while Windows has a hardcoded list of possible values in GetJavaProperties at <https://github.com/openjdk/jdk/blob/9604ee82690f89320614b37bfef4178abc869777/src/java.base/windows/native/libjava/java_props_md.c#L568>, the corresponding non-Windows code in GetJavaProperties at <https://github.com/openjdk/jdk/blob/319a3b994703aac84df7bcde272adfcb3cdbbbf0/jdk/src/solaris/native/java/lang/java_props_md.c#L175> uses ARCHPROPNAME which, via > -DARCHPROPNAME='"$(OPENJDK_TARGET_CPU_OSARCH)"' at <https://github.com/openjdk/jdk/blob/c363db8ed00ff27eadf06294364d908d6a7d03a6/jdk/makefiles/CompileNativeLibraries.gmk#L185>, appears to somehow come out of Autoconf at <https://github.com/openjdk/jdk/blob/228c21635b011fbf956b83a0b07fc297e9a34c46/common/autoconf/spec.gmk.in#L93>, so probably can show some variance in actual values being used. Change-Id: I16725cd9365f6bd034372c653aa43ab84d487b98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125401 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-17Don't fail jfw_findAllJREs for just one JRE of WrongArchStephan Bergmann
...otherwise if one such JRE had found its way into a user's configuration, "Tools - Options... - LibreOffice - Advanced" would no longer show *any* JREs. Regression introduced with 9143dd4ebe37b608e43d04434cf831624bf55b65 "Related tdf#54443 List only matching JREs", which added WrongArch to the javaPluginError enum. Change-Id: I51fd47e585c6686be7a9282615c0978e4f6c460b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125396 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-16rtl::Static->thread-safe static in jvmfwkNoel Grandin
Change-Id: I049148d82eb306e8ba7fdc9f0cc650f45b05da0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125257 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-21Restrict macOS ARM64 to Java >= 17Stephan Bergmann
The commit message of e529461bcb126e0975ffa3f86e1fd5a630551de2 "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 <https://github.com/openjdk/jdk/commit/dbc9e4b50cdda35f5712deaf440c49f50b9edc96> "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 3460c16d7f749d8d2a59d8b927df5ec31f64a083 "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-21Make getVersionInformation always return a VersionInfoStephan Bergmann
...even for JREs not listed in javavendors.xml, making it default to a VersionInfo with sMinVersion = "1.8.0". 3d27b2fa9c5a03f78e5145377402f8a88e3da1be "tdf#124503: Support JRE installations with unknown java.vendor property", which had changed getVersionInformation to return an optional<VersionInfo>, said in the commit message: "For simplicity, assume that any versions of such JREs are supported. Our baseline is Java 6, and there are unlikely any older versions of JREs from unknown vendors out there." Our baseline is Java 8 by now, and there are still unlikely any older JREs out there, but for macOS ARM64 we may want to restrict to at least Java 17 implementing <http://openjdk.java.net/jeps/391> "JEP 391: macOS/AArch64 Port", and this commit is a prerequisite for such a change (where we would then e.g. change the hardcoded "1.8.0" to "17" for just that one platform). (OtherInfo::compareVersions in jvmfwk/plugins/sunmajor/pluginlib/otherjre.cxx unconditionally returns 0, meaning "versions compare equal", so introducing a default version of "1.8.0" should have no negative effect on any JREs that use OtherInfo.) Change-Id: I34dc5f2b755c2254a91d42c262786ceec70c746e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123958 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-20Drop support for dead GNU JavaStephan Bergmann
...which no longer worked anyway at least since aafc10c9edb61e13ac557c7e43c8d4a31dce4f37 "Bump Java baseline to Java 8": According to <https://en.wikipedia.org/wiki/GNU_Compiler_for_Java>, the last version of GCC providing Java was GCC 6.5. But trying to add a build of that ("Tools - Options... - LibreOffice - Advanced - Java Options - Add...") would already have failed before this commit due to a java.lang.ClassFormatError ("JREProperties (unrecognized class file version)") when executing the JREProperties code compiled with --release 8. (Whereas now it fails because it cannot even determine a JRE installation there according to the SunInfo rather than GnuInfo rules used for the now-unknown vendor.) The <updated> elements of the modified jvmfwk/distributions/OpenOfficeorg/javavendors_*.xml have not been updated in line with the rules documented at the end of jvmfwk/README.md: As mentioned above, a GNU Java JRE cannot have been selected prior to this commit anyway, so even though this is nominally an incompatible change of the xml files, actually updating <updated> would only have negative ("just annoying if an already selected JRE is still supported") but no positive consequences. Change-Id: Ica245677dae977360bdb3c6544897eb060c3f844 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123906 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-20Azul is just another OpenJDK variantStephan Bergmann
...so there was no good reason for 0f95f8ffd7a3685ca53876005a9c96f2e2e7bc99 "Support Azul Zulu JRE (at least on Windows)" to map it to OtherInfo rather than SunInfo. (That way, it benefits from SunInfo::compareVersions's proper implementation, unlike OtherInfo::compareVersions which always returns 0. Although trying to add e.g. the too-old Java 7 <https://cdn.azul.com/zulu/bin/zulu7.50.0.11-ca-jdk7.0.322-linux_x64.tar.gz> would already have failed before this commit due to a java.lang.UnsupportedClassVersionError when executing the JREProperties code.) This also reverts all the "needed by Azul" additions in OtherInfo::getRuntimePaths; it is unlikely that any of the other JREs using OtherInfo silently also benefited from them, and JREs of unknown vendor use SunInfo (which does have those two paths already, as they are not only needed by Azul there). Change-Id: I4af9b4b9e65cd2346011522c105cfc62ec59f552 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123874 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-11loplugin:moveparam in jvmfwkNoel Grandin
Change-Id: I78970269bfd3eb7ad6b069ac99eeee707619d3e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123416 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-11In O[U]StringBuffer, make string_view params replacements for OUString onesStephan Bergmann
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That way, loplugin:bufferadd and loplugin:stringviewparam found many further opportunities for simplification (all addressed here). Some notes: * There is no longer an implicit conversion from O[U]String to O[U]StringBuffer (as that goes via user-defined conversions through string_view now), which was most noticeable in copy initializations like OStringBuffer buf = someStr; that had to be changed to direct initialization, OStringBuffer buf(someStr); But then again, it wasn't too many places that were affected and I think we can live with that. * I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to get them in line with their counterparts taking O[U]String. * I added an OUStringBuffer::lastIndexOf string_view overload that was missing (relative to OUStringBuffer::indexOf). * loplugin:stringconstant needed some addition to keep the compilerplugins/clang/test/stringconstant.cxx checks related to OStringBuffer::append and OStringBuffer::insert working. * loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related code that had been introduced in 1250aecd71fabde4dba990bfceb61bbe8e06b8ea "loplugin:stringviewparam extend to new.." Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-05drop 'using namespace std' in h* i* j*Julien Nabet
Change-Id: I3c28651779f17e1a410505ffaa863b4773037ccf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123119 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-09-01clang-tidy:readability-redundant-member-initNoel Grandin
Change-Id: I78339f1df1f0c55c7edaa552940b07d1ada3aeb5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121386 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-04Fix alternate JREs missing bin/ directory on java.library.pathSamuel Mehrbrodt
Exception looks like this: java stack trace: java.lang.UnsatisfiedLinkError: zulu11\bin\fontmanager.dll: Can't find depende nt libraries at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method) at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442) at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498) at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2648) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:830) at java.base/java.lang.System.loadLibrary(System.java:1873) at java.desktop/sun.font.FontManagerNativeLibrary$1.run(FontManagerNativeLibrary.java:57) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.desktop/sun.font.FontManagerNativeLibrary.<clinit>(FontManagerNativeLibrary.java:32) at java.desktop/sun.font.SunFontManager$1.run(SunFontManager.java:279) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.desktop/sun.font.SunFontManager.<clinit>(SunFontManager.java:275) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:398) at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:82) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) at java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.ja va:189) at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnviron ment.java:223) at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnviron ment.java:251) Change-Id: I7a16bb5813d4c089ddb4de34a250280cf6fee137 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119880 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2021-08-02convert #defines to OUStringLiteralNoel Grandin
mostly by doing $ git grep -l '#define.*\"' -- *.cxx | xargs perl -pi -e 's/^#define\s+(\w+)\s+(\".*\")/constexpr OUStringLiteral \1 = u\2;/g' Change-Id: Idface893449b0ef2a3c5254865a300585d752fbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119669 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-09loplugin:indentation (clang-cl)Stephan Bergmann
Change-Id: Iae559ca8bee9650c01167a4d1b918e18cbf03c28 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118660 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-08Turn OSL_DEBUG_LEVEL >= 2 SelfTest into CppunitTestStephan Bergmann
...and move "10.0", "10.10", and "1.5.0_010" from badVersions[] to good versions[] to make the test succeed (assuming these shall indeed be classified as good by now, presumably due to changes to the SunVersion implementation in the meantime) Change-Id: Ia7cf9b0e607743a5e0534078c0221c1423f6cfb3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118570 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-07Revert "I suspect that we unlikely to use JRE older than 1.3.1_07"Michael Stahl
This reverts commit b3541dea4889b9d0039554f87bd16e55189cf8b1. Reason for revert: The code did not just deal with text encoding differences, but also with properties whose value contains line breaks. For example, OpenJ9 has line breaks in "java.vm.info" and "java.fullversion", which now trigger asserts; also there is "line.separator" but this one happened not to cause problems so far. Change-Id: I3ded8e824e96b6fcf21677dd9ba72cbf58c1d261 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118495 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-29Enable JVM also on macOS ARM64Stephan Bergmann
My previous attempts of `make check` and running a --with-java build against various Azul JDK 13--17 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, randomly(?) causing some attempts of running generated code to SIGBUS. (See the email thread starting at <https://lists.freedesktop.org/archives/libreoffice/2020-December/086490.html> "Using Java on macOS ARM64".) But at least with the recent <https://cdn.azul.com/zulu/bin/zulu17.0.63-ea-jdk17.0.0-ea.27-macosx_aarch64.zip> on macOS 11.4, this appears to work reliably now: Multiple `make check screenshot` as well as some manual use of LibreOffice did not run into any such issues. Change-Id: I2b1327e7e877ed71420c174c1d88e68a96b3532e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118114 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-14Improve loplugin:stringviewStephan Bergmann
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for operator call arguments. (The "rather than copy, pass subView()" diagnostic is already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly for operator call arguments.) (And many call sites don't even require an explicit [u16]string_view, esp. with the recent ad48b2b02f83eed41fb1eb8d16de7e804156fcf1 "Optimized OString operator += overloads". Just some test code in sal/qa/ that explicitly tests the O[U]String functionality had to be excluded.) Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-10I suspect that we unlikely to use JRE older than 1.3.1_07Mike Kaganski
... and so possibly can rely on -Dfile.encoding=UTF8 now. This reverts 79ac0685de0b19d856db70a208a8372cb589646c and 3428bace79d64a10cfcabb79e4caa608ee5db233. Change-Id: Ia9e09025691b200c0f79427e0f4efe500f9c81f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115272 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
generated by cgit (git 2.34.1) at 2024-12-28 08:07:34 +0000