summaryrefslogtreecommitdiff
path: root/jvmfwk/inc
AgeCommit message (Collapse)Author
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-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-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-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-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-01-29loplugin:stringviewparam extend to new..Noel
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>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann
...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-18tdf#123936 Formatting files in module jvmfwk with clang-formatPhilipp Hofer
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 Kelemen
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-09-17jvmfwk: add vendorbase entry for Windows Arm64Jan-Marek Glogowski
Change-Id: Iea89befded02ecfd7513cc3d8f116dd6ac2913be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102859 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-08-19Fix typosAndrea Gelmini
Change-Id: Ideee477b0c8f0d472a607ed69ba51351d87f61bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101010 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-05-15Drop the JVM "feature" concept supportStephan Bergmann
...now that 6ba74150866d71469827de9f4f19268dfa7db137 "jfw::isAccessibilitySupportDesired is obsolete" demonstrated that there is no more need for JFW_FEATURE_ACCESSBRIDGE, the sole feature that had been provided. * The javasettings_*.xml format still supports the <feature> tag, but it is ignored when reading and always written as "0". * There is no trace that "the bootstrap parameter JFW_PLUGIN_NO_NOT_CHECK_ACCESSIBILITY" whose mention gets removed from jvmfwk/plugins/sunmajor/pluginlib/JREProperties.java had ever been supported. (The only mention was 6873b3be47d71f94c38262003101576081acd241 "INTEGRATION: CWS jre5issues (1.3.18); FILE MERGED: 2005/01/18 12:48:48 jl 1.3.18.1: #i40879# in build environment the JRE is not tested for accessibility, because of potential X server problems" introducing that comment.) * The "Features" column is removed from the JRE table on the "LibreOffice - Advance" options page. Change-Id: I332d34b60548e7f2f852241ea8edfbee0ffcf510 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94329 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-07jfw::isAccessibilitySupportDesired is obsoleteThorsten Behrens
There's no platform left that would require java accessibility. Change-Id: I2149f619e20aae70d7713d223985f8016ade8e77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93600 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-03-09improve loplugin:unusedfieldsNoel Grandin
noticed something that wasn't being picked up, wrote some tests, and found an unhandled case in Plugin::getParentFunctionDecl Change-Id: I52b4ea273be6614e197392dfc4d6053bbc1704de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90141 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-21Drop o3tl::optional wrapperStephan Bergmann
...now that macOS builds are guaranteed to have std::optional since 358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to Xcode 11.3 and macOS 10.14.4". The change is done mostly mechanically with > for i in $(git grep -Fl optional); do > sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \ > -e 's/\<o3tl::optional\>/std::optional/g' \ > -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i" > done > for i in $(git grep -Flw o3tl::nullopt); do > sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i" > done (though that causes some of the resulting #include <optional> to appear at different places relative to other includes than if they had been added manually), plus a few manual modifications: * adapt bin/find-unneeded-includes * adapt desktop/IwyuFilter_desktop.yaml * remove include/o3tl/optional.hxx * quote resulting "<"/">" as "&lt;"/"&gt;" in officecfg/registry/cppheader.xsl * and then solenv/clang-format/reformat-formatted-files Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-14loplugin:finalclasses in i18npool..linguisticNoel Grandin
Change-Id: Ib903fb2fdb4c4c25f73053065b828dade8b63785 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86687 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-19sal_Char->char in idlc..linguisticNoel Grandin
Change-Id: Ib30fe34123ad7e5d892e8db9c742e08c4ca8fcd2 Reviewed-on: https://gerrit.libreoffice.org/85477 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-01Introduce o3tl::optional as an alias for std::optionalStephan Bergmann
...with a boost::optional fallback for Xcode < 10 (as std::optional is only available starting with Xcode 10 according to <https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite all code to use o3tl::optional instead of boost::optional. One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per fed7c3deb3f4ec81f78967c2d7f3c4554398cb9d "Slience bogus -Werror=maybe-uninitialized" should no longer be necessary (and whose check happened to no longer trigger for GCC 10 trunk, even though that compiler would still emit bogus -Wmaybe-uninitialized for uses of boost::optional under --enable-optimized, which made me ponder whether this switch from boost::optional to std::optional would be a useful thing to do; I keep that configure.ac check for now, though, and will only remove it in a follow up commit). Another longer-term benefit is that the code is now already in good shape for an eventual switch to std::optional (a switch we would have done anyway once we no longer need to support Xcode < 10). Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses boost::property_tree::ptree::get_child_optional returning boost::optional, so let it keep using boost::optional for now. After a number of preceding commits have paved the way for this change, this commit is completely mechanical, done with > git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g' (before committing include/o3tl/optional.hxx, and relying on some GNU features). It excludes some files where mention of boost::optional et al should apparently not be changed (and the sub-repo directory stubs). It turned out that all uses of boost::none across the code base were in combination with boost::optional, so had all to be rewritten as o3tl::nullopt. Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b Reviewed-on: https://gerrit.libreoffice.org/84128 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-04Fix typoAndrea Gelmini
Change-Id: I2991d07cb777ee83c24931798035fcc17ae48662 Reviewed-on: https://gerrit.libreoffice.org/76908 Tested-by: Jenkins Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
2019-07-31Improved loplugin:stringconstant (now that GCC 7 supports it): jvmfwkStephan Bergmann
Change-Id: I2bf2c6b5a896cc58195a5b8f85274b9d17c56ac8 Reviewed-on: https://gerrit.libreoffice.org/76667 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-04-13loplugin:sequentialassign in embeddedobj..l10ntoolsNoel Grandin
Change-Id: I69377e2f96a376a7a5ccaec268c4f92c00a250f7 Reviewed-on: https://gerrit.libreoffice.org/70705 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-12loplugin:unusedmethodsNoel Grandin
Change-Id: Ie90e53583484ee4f378ec92634adf3be7cd9ecbb Reviewed-on: https://gerrit.libreoffice.org/70650 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-09tdf#124503: Support JRE installations with unknown java.vendor propertyStephan Bergmann
After recent additions of 61c4f96d6ae6a80370774e53287edb27cbce8067 "Support AdoptOpenJDK" and 41507db590b24e1b9b45d95cad55c71ba2e4091d "Support Amazon Corretto" to our hard-coded list, there is now reports that at least Debian and Ubuntu tried to distribute versions of OpenJDK with the java.vendor propety set to string like "Debian" or "Ubuntu". Instead of trying to catch up with an ever-growing hard-coded list, it is probably better to stop relying exclusively on such a hard-coded list, and for unknown vendor values, try out whether the SunInfo backend (which supports the "generic" OpenJDK) would be able to handle the given JRE. (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. If this turns out to be problematic, we could include information about problematic vendors after all, or add a general check that JREs from unknown vendors are at least Java 6.) Many functions in jvmfwk/inc/vendorplugin.hxx that used to take a set of sVendor/sMinVersion/sMaxVerison/arExcludeList paramters had to be revised to take a vendorSettings parameter instead, and VendorSettings::getVersionInformation has been changed to return a boost::optional, so that unknown vendors can be handled gracefully. Change-Id: Ibf915f2ddd59e09b77e2c03be688cac0547b9ac9 Reviewed-on: https://gerrit.libreoffice.org/70460 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
2018-11-02fix signatures of deleted copy/assign operatorsNoel Grandin
Change-Id: Id1a0749b78a7021be3564487fb974d7084705129 Reviewed-on: https://gerrit.libreoffice.org/62718 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-10-14Remove useless constructor and destructorArnaud Versini
Change-Id: I3130ffb7e3ec1c39965ddbc921e5b3ef8303fa31 Reviewed-on: https://gerrit.libreoffice.org/61755 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-07-30Add missing sal/log.hxx headersGabor Kelemen
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx> (and don't make use of it themselves), but many other files happen to depend on it. This is a continuation of commit 6ff2d84ade299cb3d14d4110e4cf1a4b8070c030 to be able to remove those unneeded includes. This commit adds missing headers to every file found by: grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG') to directories from filter to jvmfwk Change-Id: I2a73d63f2aaef5f26d7d08957daaa8a30b412ac5 Reviewed-on: https://gerrit.libreoffice.org/58204 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-07-26jvmfwk: avoid -Werror=deprecated-copy (GCC trunk towards GCC 9)Stephan Bergmann
...by removing explicitly user-provided functions that do the same as their implicitly-defined counterparts, but may prevent implicitly declared copy functions from being defined as non-deleted in the future. (Even if a dtor was declared non-inline in an include file, the apparently-used implicitly-defined copy functions are already inline, so why bother with a non-inline dtor.) Change-Id: I1330a9fd4fc7f8fe8525b3ea02f9edb9e88e6638 Reviewed-on: https://gerrit.libreoffice.org/58059 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-10-23loplugin:includeform: jvmfwkStephan Bergmann
Change-Id: I7292ced23647692fdc85a3c234fb1469a91ad0ea
2017-04-13Use std::unique_ptr<JavaInfo> in jfw_plugin_getAllJavaInfosStephan Bergmann
Change-Id: I2beb95c42c666a788a87a45f59bc15ccfcf25aa6
2017-04-13Use std::unique_ptr<JavaInfo> in jfw_plugin_getJavaInfoByPathStephan Bergmann
Change-Id: I3511eaa12bb689a374a775204a3480d7c667a915
2017-04-13Use std::unique_ptr<JavaInfo> in jfw_plugin_getJavaInfoFromJavaHomeStephan Bergmann
Change-Id: I8be48d1eec799f347a5edaa67837cf1bbf4d2cc3
2017-04-13Use std::unique_ptr<JavaInfo> in jfw_plugin_getJavaInfosFromPathStephan Bergmann
...thereby fixing a memory leak Change-Id: I1aa91eeb407987abcdaa5221f4abd447f881c5d2
2017-04-13More std::unique_ptr<JavaInfo> lifecycle managementStephan Bergmann
Change-Id: If53347633ec4b2f8c2b221ba2057e0c38fa97b67
2017-04-12Convert rtl_uString -> OUString in jfw_get/setVMParametersStephan Bergmann
Change-Id: I55f96873661f686cd9625d69523718ccb54659dc
2017-04-12Simplify jfw::VersionInfoStephan Bergmann
Change-Id: I2cc1071bbaf9c68fbd621d6c0c6953b7646b1a62
2017-04-12Convert some rtl_uString -> OUString in jvmfwkStephan Bergmann
Change-Id: I08de5cab29dabc6fd824d5df8bac12c8520a05ae
2017-04-11Assert obvious preconditions instead of returning javaPluginError:InvalidArgStephan Bergmann
Change-Id: I93bb3aaa0106bce98995f843ee036c9570f6aaf0
2017-04-11sal_Bool -> boolStephan Bergmann
Change-Id: I8df49f349308cc17d684d5c0e8215aa628dfaeda
2017-03-13Related tdf#54443 List only matching JREsSamuel Mehrbrodt
I.e. show only 64bit JRE for 64bit LO and 32bit JRE for 32bit LO Change-Id: Id5e890637c7e1014bcb4e6fdd9ed9a33765112d5 Reviewed-on: https://gerrit.libreoffice.org/35026 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2016-12-25tdf#95416 Fix include filetamsil1amani3
Moved elements.hxx and fwkutil.hxx to jvmfwk/inc and changed the #include line in vendorplugin.hxx Change-Id: Ida7395e952c482af92c0561a7756be7cd0578b9f Reviewed-on: https://gerrit.libreoffice.org/32415 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: jan iversen <jani@documentfoundation.org>
2016-09-13loplugin:override: No more need for the "MSVC dtor override" workaroundStephan Bergmann
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark overriding destructors as 'virtual'" appears to no longer be a problem with MSVC 2013. (The little change in the rewriting code of compilerplugins/clang/override.cxx was necessary to prevent an endless loop when adding "override" to OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager(); in chart2/source/inc/LifeTime.hxx, getting stuck in the leading OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.) Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
2016-08-05(initial) sparc64 portJames Clarke
Change-Id: I8ec9bb5415a9e6b9083ba89a7790872d67625de1
2016-07-22Related: tdf#101057 inherit MalformedVersionException from std::exceptionCaolán McNamara
so we don't get std::terminate on MacOSX if its thrown up to JavaVirtualMachine::getJavaVM Change-Id: I1c6b79bf16cbaa66b8f79d495239e301d3ca58de
2016-07-04Fix some spelling errors in comments and stringsOtto Kekäläinen
Change-Id: Iecd6b5e13d6be14651f77d8e37f01117ba15a11e Reviewed-on: https://gerrit.libreoffice.org/26883 Reviewed-by: jan iversen <jani@documentfoundation.org> Tested-by: jan iversen <jani@documentfoundation.org>
2016-05-22Convert javaPluginError to scoped enumNoel Grandin
Change-Id: Ib3a32227d50fa9e0f9cc4106ce40a4c3e840f8c7 Reviewed-on: https://gerrit.libreoffice.org/25206 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
2016-04-30Fix typosAndrea Gelmini
Change-Id: Id81b16ff26283611f0b84929d831c827f847ab73 Reviewed-on: https://gerrit.libreoffice.org/24317 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
generated by cgit (git 2.34.1) at 2024-07-02 08:15:32 +0000