Age | Commit message (Collapse) | Author |
|
ah!, the original code had a type in it. That's
why it was refactored to remove the null check.
Now a proper fix for cids: 1326180<->1326190
Change-Id: Iba7fd47c03eb5c157f878e0e297e8688f20ae348
|
|
set this back to its original code pre..
commit e5bc8b60ecfca09a2014ab7090659f3428c8efa0
Date: Tue Aug 5 12:18:20 2014 +0200
to silence coverity about it
Change-Id: I9d8f1bda1a32fbf97c0bdc73edfeab9f74d6443a
cids: 1326180<->1326190
|
|
Change-Id: I0457b81668e9427a3c8d6a4af93438b7fb2bb7ba
|
|
Change-Id: I53431357f153d61d3f80e9a3e76358d8e9bb0e0b
|
|
(cid#1326323 Unguarded read)
Just switch this to an AtomicInteger, it's cheaper, and doesn't require synchronization,
so less chance of a deadlock.
This is an API change since this is a protected field in a public class, but anyone
messing with the internals of this class should have known better.
Change-Id: Idafc760c2e9d83442b8209ad23d180acb8dccb20
|
|
Change-Id: I41f89c4feefe4e012d72c663ebb9bbcb4aa7f163
|
|
we implemented this logic in the C++ URP code a while back, but the Java
code was not correctly updated.
Change-Id: I377d7150f1adb69d6f86d9b4f3406163aaf85aea
Reviewed-on: https://gerrit.libreoffice.org/17427
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I52cbaad71560d73f5e24f3de3cd62b00d678dd6c
Reviewed-on: https://gerrit.libreoffice.org/17187
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I8e429d1f03aac7c7cdb7ff4b43b3f46d40292510
Reviewed-on: https://gerrit.libreoffice.org/16709
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
Tested-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
|
|
This reverts commit cf92da3d6e1de14756efe3f1ee79f393a2f3787d.
iff can mean "if and only if" so not a typo
|
|
Change-Id: I3fc60856b5a56e71d70b55c89323be074bdec3b3
|
|
Change-Id: I60ed5eb658d50cbc7dc572facb5463b7527b4d9b
Reviewed-on: https://gerrit.libreoffice.org/16408
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
this is the canonical order, and it makes the code easier to read
Change-Id: I272e7f1e140296e582702b6dbf77a03eefb65470
Reviewed-on: https://gerrit.libreoffice.org/16242
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
|
|
Make the order be 'public static' or 'private static'
Just makes the code nicer to read.
Change-Id: I182424bda45a2d68642e5d04c6091d268ace1fe2
Reviewed-on: https://gerrit.libreoffice.org/16202
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Id2b645829ceb9affc76483a651fe6830a9f01cda
|
|
it can make a significant speed difference for applications
talking to the office binary via UNO
Change-Id: If6e901908fe6a6119ac1fd0bf8feebabe5602ff7
Reviewed-on: https://gerrit.libreoffice.org/13856
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I5d6071096307adbe7df0178000346cf915afa3e7
Reviewed-on: https://gerrit.libreoffice.org/13477
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Icd966a850b7c5e276e8b1d74566a4ea02e5b4a5c
|
|
AsynchronousFinalizer was originally added as
870a4401c05beec3d31c1f6055a64591edd0a9d9 "INTEGRATION: CWS mtg1: #i57753# Avoid
long-running finalize methods" referring to
<https://issues.apache.org/ooo/show_bug.cgi?id=57753> " Fix JNI-UNO bridge so
that the JVM doesn't run out of memory when a destructor locks the SolarMutex."
It is unclear to me how relevant "If JVMs are getting more mature and should no
longer have problems with long-running finalize methods, this class could be
removed again" really is in practice. After all, advice on hotspot-gc-devel is
to avoid finalize() if possible
(<http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-June/010215.html>
"Re: History of finalizer execution and gc progress?"). So stick with this
approach of home-grown draining for now (where a home-grown approach using
PhantomReferencens would need a dedicated draining thread, too, so would not
have much benefit over the existing code in practice).
Timely termination of AsynchronousFinalizer threads is achieved by using a
dedicated thread per bridge and joining it in the remote bridge's dispose()
resp. the JNI environment's new java_env_dispose.
Change-Id: Idcef2dbf361a1de22f60db73828f59e85711aea7
|
|
Change-Id: I49f3f59c76bd4dd078f7014b6a0450241214db7f
|
|
Change-Id: Ia01528460e2f4b610d123e29cad66520abc6a965
|
|
found by PMD
Change-Id: I87780366119c141cd2dafe6ca1bf2d9798b10aec
|
|
Change-Id: I1ab4e23b0539f8d39974787f226e57a21f96e959
Reviewed-on: https://gerrit.libreoffice.org/12164
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
by using early return in some methods
Change-Id: I3611c8c89b3a94ef7e1772d178acf065fd7fcdc7
Reviewed-on: https://gerrit.libreoffice.org/12374
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ia43976d84eede6f699381bc4f3daf89b95e4cb4f
Reviewed-on: https://gerrit.libreoffice.org/12150
Reviewed-by: Bryan Quigley <gquigs@gmail.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ic058759782f95e330d8c581911aeb163340a7c4b
|
|
Change-Id: I34ce000c48d2d79bfec854c8dd55d12f2bee29c7
|
|
Change-Id: I3c0c7f08d4d8ea594e72fc0d9b93d085d4ab4bf5
|
|
Change-Id: I76431b67f9f6fdde2906d6d8082457ef0847108e
Reviewed-on: https://gerrit.libreoffice.org/11964
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I1bb0999783f365e20b682c3707e73c65724265c9
Reviewed-on: https://gerrit.libreoffice.org/11955
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I58e7ebdd5c48094142f93f47271bcc0cc8b97981
Reviewed-on: https://gerrit.libreoffice.org/11892
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I597dac3cae7eafef75982789ab1b0d3d8d6999d2
Reviewed-on: https://gerrit.libreoffice.org/11863
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
Tested-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
|
|
the instanceof check returns false when passed a null value
Change-Id: I7742d0d9cf25ef23d9adee7328f701c7efeea8b5
|
|
the java.io.IOException(Throwable) constructor was only introduced
in 1.6
Change-Id: Icd40e91cce7a2e89e4a70ad55f31baaa86eebfe2
|
|
so that we get a nice complete stacktrace when it hits the final
handler
Change-Id: Iec4fcc15a2a25c55f591b5e069dce3d010197a90
|
|
Change-Id: I914985aa73653e0fb08200ddd06ad5b914087e3a
Reviewed-on: https://gerrit.libreoffice.org/11446
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
In other words, only executable files go in the MacOS folder. Dynamic
libraries and bundled frameworks (i.e., LibreOfficePython), and
nothing else, go in the Frameworks folder, and all other files go in
the Resources folder.
Especially, note that Java class files and rc (.ini) files also go in
Resources.
Such an app bundle structure is what Apple strongly suggests one
should use, and it has been hinted that future versions of code
signing and/or Gatekeeper will require such a structure.
There is still some ugliness thanks to traces of the historical
separation of URE from "the office". Like there are two separate
"unorc" files, one for URE, one for the LibreOffice application. IMHO,
this should be cleaned up, but is probably controversial.
(Eek! I now see there are actually *three* unorc files in the app
bundle. Not intentional. Need to fix that later.)
Change-Id: Idcf235038deb5b8e1d061734993e9f31869b7606
|
|
Change-Id: I611821d5f84b440ba542a8d62a374df7b505de15
|
|
Change-Id: Ie8eb163793dc575558149320dceffcd92bdcfdd4
Reviewed-on: https://gerrit.libreoffice.org/11245
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
|
|
Change-Id: I998f5796d7a5f10f790a1e861b741c54d0f62c19
Reviewed-on: https://gerrit.libreoffice.org/11191
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
in the absence of any other constructors, the compiler will automatically
generate a public no-arg constructor
Change-Id: I70eca507cd8e16e33580b3398d41d70690bc2909
|
|
found by PMD
Change-Id: I04cbf986ddbcffff987784f381b8a9f52f1b3f31
|
|
As of the JDK 1.4, Throwable.getCause() is the preferred method for getting thrown target exception.
Change-Id: I14f3f9ae52869d1149f92b32562e7fb3293109b5
Reviewed-on: https://gerrit.libreoffice.org/11027
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ia99765a6226317ee41ffb02a1b0dd7e6fd944a90
|
|
Change-Id: Icef19ef61ee0af2dd3bda527263934006271f219
|
|
Change-Id: If4fff3dd37326fbcdd01b743355a16591d71fa69
|
|
Change-Id: Ia8befb8d69914ce971174fc5f2ffc0e2f506a940
|
|
Change-Id: I7b18f62336c3a8ca4c538b30ce04c99f202a4756
|
|
Change-Id: I05c907a38b562231e968c17f14e09ef80e0a6ed1
|
|
Change-Id: I43d25ba49b758739ee8dc891b0db3e527004ec8b
|