...they contained no class files anymore, due to missing gb_Jar_set_packageroot
calls. However, those calls only work for subdirectories, i.e., the example
.java files need to be put into a package (I chose
org.libreoffice.example.java_scripts) for all of them). This in turn required
adaption of the parcel-descriptor.xml files; not sure what the logicalname
entries there are good for if anything -- the macro names at "Tools - Macros -
Run Macro..." now unfortunately(?) contain the fully qualified paths for the
HelloWorld, HighlightText, and MemoryUpdate examples. There are additional
examples at scripting/examples/java/ that apparently do not get packaged (but I
adapted them anyway).
ScriptMetaData.createURL produces weird URLs (ending in "/ucb/", and potentially
still containing vnd.sun.star.expand: prefix) that are apparently good for
loading documents for editing via UCBStreamHandler, but cannot meaningfully be
passed to a URLClassLoader.
It is unclear to me how the Java script provider shall ever have found the
script jars in the past.
insert() inserts before the given iterator and returns iterator to newly
inserted element, hence need to increment that iterator
(regression from 6bb68cae7c)
In most cases \super has its own group, but it's valid to have mixed
super and non-super text in a single group, as long as \super and
\nosupersub keywords are used: handle this.
We create 6 berkleydb backed databases. If no DB_ENV is provided for a
database, then berkleydb creates one for each database. Each
environment has a memory footprint of about 200k. It appears to be
legal to share an environment, which shaves about 1M off our
permanant footprint.
GCC gives the following warning which breaks compilation when using --enable-werror:
lockbyte.cxx: In function 'storeError store::FileLockBytes_createInstance(rtl::Reference<store::ILockBytes>&, rtl_uString*, storeAccessMode)':
lockbyte.css:512:37: error: 'prephitmp.221' may be used uninitialized in this function [-Werror=uninitialized]
lockbyte.cxx:906:1: note: 'prephitmp.221' was declared here
It's not clear from GCC's message, but what it warns about is
FileMapping::m_hFile. This is because of the following sequence:
* xMapping.release() makes xMapping.m_value be a default constructed
FileMapping
* the xMapping local variable in store::FileLockBytes_createInstance
gets destructed
* ~ResourceHolder() calls ResourceHolder::reset
* ResourceHolder::reset() calls FileMapping::UnmapFile::operator()
passing m_value as rMapping
* FileMapping::UnmapFile::operator() uses rMapping.m_hFile but
rMapping is a default constructed FileMapping and therefore has
m_hFile uninitialized
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>:
To me, this looks more like a compiler error. Also note that
ResourceHolder::reset only calls FileMapping::UnmapFile::operator() if tmp !=
value, which is not the case here, as both tmp and value are default-
constructed. And FileMapping::operator!= is carefule not to use the potentially
uninitialized m_hFile. But always intiializing m_hFile is probably not a bad
idea, anyway. And if it helps a certain compiler, all the better.
