summaryrefslogtreecommitdiff
path: root/jvmfwk
AgeCommit message (Collapse)AuthorFilesLines
2022-05-24tdf#149202 Allow for java.version consisting of four dotted segmentsStephan Bergmann1-4/+4
...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.) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131586 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 8e6462571bb4cb872f607b4ac9dfde7f43b79ac3) Change-Id: Id98235d3be59653ab412f9b6c1ffbf3b0470bd6f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134820 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-05-04Some JREs need the bin/server/jvm.dll path after allStephan Bergmann1-1/+5
...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> (cherry picked from commit c7b923a9ebaa40809c11659f8816a1d2bfd44c89) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133733 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-02-21Avoid unnecessary empty -Djava.class.path=Stephan Bergmann3-5/+22
Change-Id: Idcfe7321077b60381c0273910b1faeb444ef1fd8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130242 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 5e8f64e50f97d39e83a3358697be14db03566878) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130266 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-11-18There was a typo in the AdoptOpenJDK java.vendor property valueStephan Bergmann6-16/+0
...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 Bergmann1-1/+3
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 Bergmann1-0/+2
...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 Grandin6-47/+59
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 Bergmann3-1/+23
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 Bergmann3-30/+23
...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 Bergmann6-336/+0
...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 Bergmann2-5/+3
...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 Grandin4-4/+4
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 Bergmann1-8/+5
...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 Nabet6-35/+27
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 Grandin1-5/+1
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 Mehrbrodt1-0/+18
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 Grandin1-2/+2
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 Bergmann1-1/+1
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 Bergmann5-112/+172
...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 Stahl2-5/+48
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 Bergmann1-1/+1
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 Bergmann1-2/+3
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 Kaganski2-48/+5
... 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>
2021-04-21loplugin:stringadd replace OUStringLiteral temporaries with OUString::ConcatNoel Grandin1-1/+1
Change-Id: I656f06a74d9f0180ae460264563d6a935c7d2c60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114377 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-19Updated README.md filesHossein1-1/+1
* Updated README.md contents to fix various issues * Fixed source links by using [git:], processed by mkdocs scripts * Added README.md for ios, setup_native, unotest * Fixed issues with "underline" and "less than" sign Change-Id: I3e52a1d3372586c390ee6c42a2ef48bbabc81398 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114248 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein1-6/+11
Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-03-24Using .md extension/Markdown syntax for modules READMEHossein1-0/+0
Renaming all README files for all top level modules to README.md, applying no content change at this stage to be able to track history of the files. These files should be edited to use correct Markdown syntax later. Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-01-29loplugin:stringviewparam extend to new..Noel2-4/+4
O[U]StringBuffer methods Change-Id: I0ffbc33d54ae7c98b5652434f3370ee4f819f6f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110090 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-02Fix some warnings for Raspberry pi 4 (part2)Julien Nabet1-0/+8
Fix these kinds: /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:103:10: error: externally available entity 'is_complex_struct' is not previously declared in an included file (if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external] bool is_complex_struct(const typelib_TypeDescription * type) ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:129:10: error: externally available entity 'is_float_only_struct' is not previously declared in an included file (if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external] bool is_float_only_struct(const typelib_TypeDescription * type) ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:168:6: error: externally available entity 'MapReturn' is not previously declared in an included file (if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external] void MapReturn(sal_uInt32 r0, sal_uInt32 r1, typelib_TypeDescriptionReference * pReturnType, sal_uInt32* pRegisterReturn) /home/pi/lo/libreoffice/bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx:446:32: error: static_cast from 'void **' to 'sal_Int32 *' (aka 'long *') is not allowed sal_Int32 * pTempIndices = static_cast<sal_Int32 *>(pCppArgs + nParams); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ or some of these: In file included from /home/pi/lo/libreoffice/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c:26: /usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1945:1: error: unknown attribute 'externally_visible' ignored [-Werror,-Wunknown-attributes] _JNI_IMPORT_OR_EXPORT_ jint JNICALL ^ /usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1943:32: note: expanded from macro '_JNI_IMPORT_OR_EXPORT_' define _JNI_IMPORT_OR_EXPORT_ JNIIMPORT ^ /usr/lib/jvm/java-11-openjdk-armhf/include/linux/jni_md.h:35:42: note: expanded from macro 'JNIIMPORT' define JNIIMPORT __attribute__((externally_visible,visibility("default"))) Change-Id: I7cae1c52ee10306da666c9c234b9af7248efd04e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108567 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-01-02Use Unicode paths on Windows for jvmfwkMike Kaganski1-6/+11
Change-Id: I6f2e29d2e7908a40175dc2852e955f0a1bc501e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108481 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann1-4/+4
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann7-8/+17
...for LIBO_INTERNAL_ONLY. These had been missed by 1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take std::u16string_view parameters" because they did not match the multi-overload pattern that was addressed there, but they nevertheless benefit from being changed just as well (witness e.g. the various resulting changes from copy() to subView()). This showed a conversion from OStringChar to std::string_view to be missing (while the corresponding conversion form OUStringChar to std::u16string_view was already present). The improvement to loplugin:stringadd became necessary to fix > [CPT] compilerplugins/clang/test/stringadd.cxx > error: 'error' diagnostics expected but not seen: > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd] > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd] > 2 errors generated. Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-30loplugin:stringviewparam include comparisons with string literalsNoel1-2/+2
Change-Id: I8ba1214500dddaf413c506a4b82f43d63cda804b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106559 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-25loplugin:stringview (clang-cl)Stephan Bergmann1-2/+2
Change-Id: I47b44c80b2a5e3c9d84f5d7257efe17f138a1067 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106563 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-18tdf#123936 Formatting files in module jvmfwk with clang-formatPhilipp Hofer9-116/+98
Change-Id: Ie643402fbf10ac837c975d29068b7973e9dd6210 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105685 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-11-10tdf#42949 Fix new IWYU warnings in directories [h-r]*Gabor Kelemen2-0/+4
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I886b6f446293d3b1cfbf4ae05e8dbd7fabab9f20 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105510 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-10-22Only read Java settings files in application modeMichael Weghorn1-30/+35
The 'javasettings_${_OS}_${_ARCH}.xml' files are only meant to be used when the application mode of the Java framework is used, not in direct mode. From ure/source/README: > You can also use the > UNO_JAVA_JFW_JREHOME deployment variable to specify the location of a JDK/JRE > installation. For more information on this variable, see > http://udk.openoffice.org/common/man/spec/javavendorextension.sxw. From that http://udk.openoffice.org/common/man/spec/javavendorextension.sxw : > The direct mode of the framework is used within the build environment. > Java is needed there in order to register Java UNO components with the > regcomp tool. Direct mode means that no settings are written or read. > That is the parameters UNO_JAVA_JFW_USER_DATA and > UNO_JAVA_JFW_SHARED_DATA are not used. > [...] > Another example for using the direct mode is the SDK. The SDK uses the > libraries from the office installation. When an SDK is configured then > one specifies what Java is to be used. This Java shall then be used for > all task which require Java including registration of UNO components. In > order to override the java settings of the office the script which > prepares the SDK environment sets these environment variables: > UNO_JAVA_JFW_JREHOME=<file_URL_to_selected_Java> > UNO_JAVA_JFW_ENV_CLASSPATH=true > UNO_JAVA_JFW_VENDOR_SETTINGS=<file_URL_to_javavendors.xml_from_OOo> > By setting UNO_JAVA_JFW_JREHOME the framework is switched into direct mode > and the office settings are disregarded. Therefore, don't try to read the settings when using direct mode. This makes the relevant code path for accessing the settings conditional on 'jfw::JFW_MODE_APPLICATION' being used. Otherwise, using direct mode e.g. by starting LibreOffice using UNO_JAVA_JFW_JREHOME=file:///usr/lib/jvm/java-11-openjdk-amd64/ ./instdir/program/soffice --writer then going to the "Advanced" options in "Tools" -> "Options", where the Java settings reside would result in this SAL_WARN being triggered warn:jfw:10207:10207:jvmfwk/source/framework.cxx:119: [Java framework] Trying to access settings files in direct mode. and no JVM at all being shown in the list of available Java installations. Change-Id: I2b98d822aed2b160f970c50ca695a9f3beeacd34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104001 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-09-22Manually select JDK outside /Library/Java/JavaVirtualMachines on macOSStephan Bergmann1-31/+7
32bc8ddbf335dd26019edcf12758643b4cff9913 "tdf#94716 allow Oracle's JDK to be used on OS X 10.10 and 10.11" had restricted both addJavaInfosDirScan (jvmfwk/plugins/sunmajor/pluginlib/util.cxx, relevant when LO scans for available Java runtimes) and JvmfwkUtil_isLoadableJVM (which is more central and also relevant when manually adding a Java installation on the Advanced options page) to JDK installations under /Library/Java/JavaVirtualMachines. Recent versions of OpenJDK for macOS are provided as *.tar.gz files (e.g., <https://download.java.net/java/GA/jdk15/779bf45e88a44cbd9ea6621d33e33db1/36/GPL /openjdk-15_osx-x64_bin.tar.gz> avaiable at <http://jdk.java.net/15/>) that can potentially be installed anywhere, so it looks useful to remove the /Library/Java/JavaVirtualMachines restriction from JvmfwkUtil_isLoadableJVM. I'm not sure whether that would have any nagative impact, esp. for any scenario that would still be relevant today. When I unpacked the above openjdk-15_osx-x64_bin.tar.gz to ~/OpenJDK/ on my macOS 10.15.6, and manually added /Users/stephan/OpenJDK/jdk-15.jdk/Contents/Home on the Advanced options page, everything appeared to work fine. Change-Id: I15545cc786a4a423f3bfe22ba477a45d6ef7fdf1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103212 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-17jvmfwk: add vendorbase entry for Windows Arm64Jan-Marek Glogowski1-0/+2
Change-Id: Iea89befded02ecfd7513cc3d8f116dd6ac2913be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102859 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann1-3/+4
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-31Simplify some code involving SAL_PATHSEPARATOR and OString/OUStringBufferStephan Bergmann1-4/+2
Change-Id: If01e7c0d7d87a544f6601174ce43b37c63cfbcb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101746 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann1-5/+5
This is a prerequisite for making conversion from OUStringLiteral to OUString more efficient at least for C++20 (by replacing its internals with a constexpr- generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount, conditionally for C++20 for now). For a configure-wise bare-bones build on Linux, size reported by `du -bs instdir` grew by 118792 bytes from 1155636636 to 1155755428. In most places just a u"..." string literal prefix had to be added. In some places char const a[] = "..."; variables have been changed to char16_t, and a few places required even further changes to code (which prompted the addition of include/o3tl/string_view.hxx helper function o3tl::equalsIgnoreAsciiCase and the additional OUString::createFromAscii overload). For all uses of macros expanding to string literals, the relevant uses have been rewritten as u"" MACRO instead of changing the macro definitions. It should be possible to change at least some of those macro definitions (and drop the u"" from their call sites) in follow-up commits. Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-19Fix typosAndrea Gelmini1-1/+1
Change-Id: Ideee477b0c8f0d472a607ed69ba51351d87f61bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101010 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-08-18Add missing punctuation/spaces to error messagesStephan Bergmann1-3/+3
Change-Id: I4be46342b24a5993df74dbd047d88842a8df0412 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100901 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-18Silence new Clang 12 trunk -Werror,-Wstring-concatenationStephan Bergmann2-2/+2
"suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma?" Change-Id: I83828d8cc6f8ab9b0c1ca8a1c3fb528592c46504 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100897 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-10replace usage of blacklist with excludelist for IWYUThorsten Behrens1-1/+1
Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 Change-Id: I2f22d455d2a936a85750eaab1fda215ebb6d9d48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98182 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-02tdf#129264: Make javaldx always print a line upon successful executionStephan Bergmann1-0/+1
...where "do not use a JRE" (implying that the printed line consists of just a terminating newline) is a sufficient condition for a successful execution, too. (Also, it appears that extend_library_path in desktop/unx/source/start.c would have introduced unwanted empty segments into the path environment variable when the line printed by javaldx consisted of just a terminating newline.) Change-Id: Ic2f86de8a829b3dea51c0e4da1ac236298e16366 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97756 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-01Upcoming improved loplugin:staticanonymous -> redundantstatic: jvmfwkStephan Bergmann1-2/+2
Change-Id: I979e9142324df589229aafbb4a17f7495a79f0dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97594 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-22tdf#134167: jfw_plugin_getAllJavaInfos can successfully return empty listStephan Bergmann1-2/+1
Regression introduced with 6ba74150866d71469827de9f4f19268dfa7db137 "jfw::isAccessibilitySupportDesired is obsolete" Change-Id: I696f3240fa8760ae156ac3b8b1fd1fe42f81c539 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96821 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-05-27tdf#131572 Add java 9 module info for libreoffice.jarSamuel Mehrbrodt1-1/+1
Add a java module named "org.libreoffice.uno" for this jar. This needs to be compiled with Java 9. But since we want to keep b/c with Java 8, the rest of the jar has to be compiled with Java 8. This bumps the *build* requirement to Java 9 while keeping the *runtime* requirement at Java 8. The gbuild JavaClassSet class is changed to invoke javac twice, where the 2nd invocation compiles with --release 9 and a --patch-modules argument so that it finds the results of the first invocation and also the javamaker generated files in CustomTargets. Change-Id: I888f5dbe097cc37136e68db5919939877c981862 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91105 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-15 07:12:00 +0000