diff options
author | Stephan Bergmann <sbergman@redhat.com> | 2019-04-09 14:51:54 +0200 |
---|---|---|
committer | Stephan Bergmann <sbergman@redhat.com> | 2019-04-09 22:31:17 +0200 |
commit | 3d27b2fa9c5a03f78e5145377402f8a88e3da1be (patch) | |
tree | be09d47208ad2f3f4564987a25d5d6d875744792 /icon-themes | |
parent | d38f9934f08939032cca64a32de58fa3901a88d5 (diff) |
tdf#124503: Support JRE installations with unknown java.vendor property
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>
Diffstat (limited to 'icon-themes')
0 files changed, 0 insertions, 0 deletions