Restore binary compatibility for ClassLoaderFactory

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)

cae57d2e588a4b5a104171e022b00abcc1605775 "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 68cd011c907d00493bf2bfde531c1e244819596b "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>

0 files changed, 0 insertions, 0 deletions