About removing Beanshell/Javascript (Rhino) ?

[Michael Stahl]

On 22.01.22 13:35, Ilmari Lauhakangas wrote:
> On 22.1.2022 13.27, Julien Nabet wrote:
>> Hello,
>>
>> Reading https://en.wikipedia.org/wiki/BeanShell, specifically:
>>
>> "Since Java 9, Java instead includes JShell 
>> <https://en.wikipedia.org/wiki/JShell>, a different read–eval–print 
>> loop 
>> <https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop> 
>> (REPL) shell based on Java syntax, indicating that BeanShell will not 
>> be continued"
>>
>> I wonder if we could remove Beanshell part from LO.
>>
>> Also, we use Rhino as Javascript engine (Rhino is written in Java). 
>> Some people proposed C/C++ engine like Spidermonkey or V8 (see 
>> https://bugs.documentfoundation.org/show_bug.cgi?id=97827) but it 
>> seems they may be problematic too because of instable API and specific 
>> GC, see Michael's comment here: 
>> https://bugs.documentfoundation.org/show_bug.cgi?id=97827#c7

another problem is that Rhino cannot simply be replaced by packging yet 
another JS implementation; if you look at the examples we ship, they have:

importClass(java.lang.Thread);
importClass(java.lang.System);

so any existing Rhino based macros will likely use the Java APIs and 
cannot work with a non-JVM based JS implementation.

importClass(Packages.com.sun.star.uno.UnoRuntime);
importClass(Packages.com.sun.star.lang.XMultiComponentFactory);
importClass(Packages.com.sun.star.awt.XDialogProvider);
importClass(Packages.com.sun.star.awt.XDialog);
importClass(Packages.com.sun.star.uno.Exception);
importClass(Packages.com.sun.star.script.provider.XScriptContext);

also, Rhino relies on the Java-UNO bridge and some Java glue code in the 
scripting model to provide access to UNO APIs; this would need to be 
reimplemented in the form of a bridge for any non-JVM based JS 
implementation.