...to improve diagnosing misuses of boolean expressions in client code (cf.
compilerplugins/clang/implicitboolconversion.cxx). This change should be
transparent to client code.
Missing overloads of insert() for bool have been added to OStringBuffer and
OUStringBuffer (which required dropping one !VALID_CONVERSION check that would
now pick that overload, but would be flagged by
compilerplugins/clang/pointertobool.cxx).
Change-Id: I2d64cd923b8f47bfaa31e753def6515c29a3f8c9
A final pass through the code, converting code to use the new
OUString and OString methods that can detect string literals.
Change-Id: Ifa6382335e5650a1c67e52006b26354e0692c710
cf. comment in framework header. Should have no impact on real
run-time Java a11y, which would be enabled later as-needed; only
on JRE selection. For extreme corner-cases, where your auto-selected
JRE has no a11y support either select another JRE in the UI or:
$ export JFW_PLUGIN_FORCE_ACCESSIBILITY=1
to override.
Change-Id: I59a6428e5a11664b75c29580cad76eb9500db45a
Compiler plugin to replace with matching number(), boolean() or OUString ctor,
ran it, few manual tweaks, mark as really deprecated.
Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
Change all instances of hardcoded "program", "share" etc subfolder names to
use those from <config_folders.h> instead. In normal builds, the end result
will not change.
Change-Id: I91c95cd8e482818be67307e889ae6df887763f53
...which has become necessary since bd60d41176
"Handle oveflow in O(U)String::toInt() functions" reduces values in the range
(SAL_MAX_INT32 .. SAL_MAX_UINT32] to zero, but some calls of toInt32(16) relied
on getting a correct (unsigned) value for the whole input range ["0" ..
"FFFFFFFF"] (see libreoffice-4-1 commit 9bf6c83367cedb7be81bf67f30d2147d26c7a8c3
"Revert overflow checks in O[U]String::toInt{32,64} again").
Audited all uses of toInt32/64 with non-decimal radix. (There is still a TODO
comment in oox/source/helper/attributelist.cxx, and
stoc/source/typeconv/convert.cxx will still need some love and test code.)
Change-Id: Iadaca1c0e41dab553687d0ce41c20c10cd657a95
...dead at least since c58b07c958 "#i20020#," if
not even since the beginning, 49614181e5 "#i20052#
plugin lib for java framework."
Change-Id: Ic0b35341cb8038ccfe0a2f4f5b758341b9ab13b9
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
Just sprinkle #ifdef SOLAR_JAVA into the code instead.
In the source for jvmaccess and jvmfwk such ifdefs can be removed as
it isn't compiled unless SOLAR_JAVA.
Change-Id: Ia8614f8bd6d833582d3b79b5fb75f9153fa79606
Done with a perl regex:
s/OUString\s*\(\s*RTL_CONSTASCII_USTRINGPARAM\s*\((\s*"[^")]*?"\s*)\)\s*\)/OUString\($1\)/gms
Change-Id: Idf28320817cdcbea6d0f7ec06a9bf51bd2c3b3ec
Reviewed-on: https://gerrit.libreoffice.org/2832
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
Since b699519969 "Drop support for /etc/opt/ure
and ~/.ure from LibreOffice 4" there is no place any more where a plain URE will
store information about a selected JVM, so JavaVirtualMachine::getJavaVM will
go into an endless loop of jfw_startVM -> JFW_E_NO_SELECT ->
jfw_findAndSelectJRE -> jfw_startVM -> ... The solution is to pass the JavaInfo
determined by jfw_findAndSelectJRE into the second invocation of jfw_startVM
(for which the parameter list of the latter needed to be changed), instead of
relying on jfw_findAndSelectJRE and jfw_startVM implicitly communicating that
information via user configuration files.
Change-Id: I5799f04c457e8a849c67ed827dc5e134c6563362
For one, /etc/opt/ure was probably never used by anyone anyway, so meant just
needless file-stats during startup. For another, accidentally created
~/.ure/javasettings_*.xml that later became stale were noted to cause trouble,
so that source is now closed.
For this to work, jvmfwk needs to be silent now if it cannot read/write any
shared/user javasettings_*.xml.
Change-Id: I332b5ebb9549dc6ccf7c99c439d9a3b61aeb5829
There are basicically two classes of cases:
1) Where the code is for obscure historical reasons or what I see as
misguided "optimization" split into a more libraries than necessary,
and these then are loaded at run-time. Instead, just use direct
linking.
2) Where dynamic loading is part of the functionality offered to some
upper (scripting etc) layer, or where some system-specific non-LO
library is loaded dynamically, as it is not necessarily present on
end-user machines. Can't have such in the DISABLE_DYNLOADING case.
Change-Id: I9eceac5fb635245def2f4f3320821447bb7cd8c0
Now that 5c47e5f63a "fdo#51252 Disable copying
share/prereg/bundled to avoid startup crashes" removed the use of share/prereg,
there is no longer need to generate it in the first place (by calling "unopkg
sync" at build or installation time), and so no need for the "unopkg sync" sub-
command, either. This also allows to simplify some of the jvmfwk code that was
only there so that "unopkg sync" (which can require a JVM) can work in "hostile"
environments (during build and installation).
Change-Id: I52657384f4561bf27948ba4f0f88f4498e90987f
...after gbuild'ification (they used to be added via solenv/bin/addsym.awk).
And sunjavaplugin.map is actually unused.
Change-Id: If6804cff8d01e268b84512d6c4b1edebde018cc0
