Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: Ibb17d89a5ed618b4d5e6be9ac9ee89e2751c3ed7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159696
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I23ce970ad67047b0b22a9dda3dff047e5f59dff5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158203
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
...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>
|
|
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>
|
|
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>
|
|
Change-Id: I8636102554a76f2ba3f6297219b40761473a4489
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137285
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6e19d4d03957c35caa79a231927eae04ae630442
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136209
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
...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>
|
|
Change-Id: I05f3b171578b8fef5b15dcbbf10ae9b7cf2d1b02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133075
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
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>
|
|
Change-Id: I62a7534844006a7bf3c2ece5e5d2f8b739a15b9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132762
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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>
|
|
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>
|
|
Change-Id: I3f31f223b6e906c6b40415a8d5c66c27e3c7cff5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130338
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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
|
|
Change-Id: Idcfe7321077b60381c0273910b1faeb444ef1fd8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130242
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
Change-Id: I231195c36d620254cbcd2f4d7bbb9044f7887fe8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126413
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
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>
|
|
...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>
|
|
Change-Id: I049148d82eb306e8ba7fdc9f0cc650f45b05da0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125257
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
...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>
|
|
...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>
|
|
...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>
|
|
Change-Id: I78970269bfd3eb7ad6b069ac99eeee707619d3e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123416
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
Change-Id: I3c28651779f17e1a410505ffaa863b4773037ccf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123119
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I78339f1df1f0c55c7edaa552940b07d1ada3aeb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121386
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
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>
|
|
Change-Id: Iae559ca8bee9650c01167a4d1b918e18cbf03c28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118660
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...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>
|
|
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>
|
|
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>
|