As discussed in the mail thread starting at <http://mail-archives.apache.org/
mod_mbox/openoffice-dev/201806.mbox/%3c651c8fee-b467-421c-eae1-a8710f41692c
@apache.org%3e> "Just a little side note on the scripting framework ...",
external code that uses the Java class
com.sun.star.script.framework.provider.ClassLoaderFactory stopped working
because LO changed that class in binary (and compile-time) incompatible ways
over time.
The class is not listed at
<https://api.libreoffice.org/docs/java/ref/index.html> (and neither at
<http://www.openoffice.org/api/docs/java/ref/overview-summary.html>), so it was
not considered part of the stable URE interface. But it is apparently used by
external code, and it indeed seems to make sense that it is used by external
code that implements scripting providers. (A follow-up commit should therefore
mark the class as part of the stable URE interface. I keep that separate so
that it is easier to backport this functional fix.)
With ScriptProviderForooRexx.oxt from
https://svn.code.sf.net/p/bsf4oorexx/code@r589 installed in LO, "Tools - Macros
- Organize Macros - ooRexx... - My Macros - Create... - Library1 - OK -
Create... - Macro1 - OK - Edit" failed due to
> warn:cui.dialogs:21768:21768:cui/source/dialogs/scriptdlg.cxx:740: Caught exception trying to invoke N3com3sun4star3uno9ExceptionE msg: [jni_uno bridge error] UNO calling Java method invoke: non-UNO exception occurred: java.lang.NoSuchMethodError: com.sun.star.script.framework.provider.ClassLoaderFactory.getURLClassLoader(Lcom/sun/star/script/framework/container/ScriptMetaData;)Ljava/lang/ClassLoader;
> java stack trace:
> java.lang.NoSuchMethodError: com.sun.star.script.framework.provider.ClassLoaderFactory.getURLClassLoader(Lcom/sun/star/script/framework/container/ScriptMetaData;)Ljava/lang/ClassLoader;
> at com.sun.star.script.framework.provider.oorexx.ScriptEditorForooRexx.edit(ScriptEditorForooRexx.java:305)
> at com.sun.star.script.framework.browse.ScriptBrowseNode.invoke(ScriptBrowseNode.java:200)
cae57d2e58 "ClassLoader->URLClassLoader" (which
this commit reverts) had changed the return type of the two getURLClassLoader
overloads from ClassLoader to derived URLClassLoader (and ultimately only for
cosmetic effect; it was leftover from a previous attempt at fixing a Coverity
issue by using URLClassLoader.close(), but which is only available in Java 1.7,
so the attempt had been reverted). That caused the above failure.
And 68cd011c90 "java: reduce scope, make some
methods private" (which this commit also reverts) had changed the second
getURLClassLoader overload (which is not called in the above scenario) from
public to private, which is also a binary-incompatible change.
Other commits removed throws clauses, which is only a compile-time issue but not
a binary-incompatible change. I left those changes in for now, but if need be
they could also be reverted.
Change-Id: I98f533d88c7c1580956c3c281e72a1c78fa3f56f
Reviewed-on: https://gerrit.libreoffice.org/55871
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Add a toolbar A little enhasment for the editor has been done.
Added a toolbar for set of buttons that was previously in a JPanel
and now it is in Jtoolbar in the editor
Change-Id: Ie04232e7824c051f272d69cc109eec0e70ccf921
Reviewed-on: https://gerrit.libreoffice.org/29806
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
and
coverity#1371366 Resource leak on an exceptional path
coverity#1371376 Resource leak on an exceptional path
Change-Id: Ic0fd05f02b1d78a47d4ee924dee8f10811586d0d
Cloneable, odd additional equals overloads, odd hasCode implementation---all
smells like clueless cargo cult. And I see no place where it would get used.
Change-Id: Icca89531ce9181fb47eacfb6fae704f4f45012a9
Bartosz Kosiorek