/source/bn-IN/framework/

git' href='git://go.suokunlong.cn/lo/core' title='lo/core Git repository'/>
summaryrefslogtreecommitdiff
path: root/jvmfwk/plugins/sunmajor/pluginlib/otherjre.cxx
AgeCommit message (Collapse)Author
2024-12-02tdf#147021 - Use std::size() instead of SAL_N_ELEMENTS() macroLeSci-0x1
Change-Id: If8222286f36cda3071d63a14896d8d89c5802437 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177650 Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Tested-by: Jenkins
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>
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-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>
2020-08-18Silence new Clang 12 trunk -Werror,-Wstring-concatenationStephan Bergmann
"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>
2019-04-26tdf#42949 Fix IWYU warnings in jvmfwk/ & jvmaccess/Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I6c1041f261ba5a6f81efd3dcbc12baf2746e1839 Reviewed-on: https://gerrit.libreoffice.org/71217 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-02-09loplugin:indentation in jvmfwk..lotuswordproNoel Grandin
Change-Id: I1af665f4c6d34d8514dd23bb7a3eba700ce3ddbc Reviewed-on: https://gerrit.libreoffice.org/67559 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>