RFC: Move LiveConnect / Java interop classes to own jar

[rPraml]

Hello, I want to discuss, if it is a good or bad idea, to move the LiveConnect classes (NativeJavaXXX etc.) to a own package, so that it may be separated to a own jar( rhino-liveconnect.jar)

I'm aware that this requires to modify some APIs and will introduce a breaking change.

So far I have started to do a proof of concept, but before I put more energy into it, I wanted to ask if this is even desired.

The advantage is clearly, that the whole liveconnect thing, which most of the reflection and everything sits in an own jar. If the jar is not on the classpath, you cannot interact with java classes from your script.

The idea is to route everything over the wrapFactory (no wrapFactory = no liveConnect)

This PR shows the proof of concept and is still a draft. You may also see, that a lot of methods from ScriptRuntime etc. has to be made public. So I do not know if this is intended, but maybe we can adapt some of the ideas (especially, the idea, when the wrapFactory is null, that every attempt will fail in an exception)

[p-bakker]

I assume you know you can run Rhino without Java Interop enabled, no?

[gbrail]

Roland is working on documenting the specifics about that -- this reduces the risk that someone can escape into arbitrary Java code.

…

On Thu, Sep 26, 2024 at 8:41 AM Paul Bakker ***@***.***> wrote: I assume you know you can run Rhino without Java Interop enabled, no? — Reply to this email directly, view it on GitHub <#1655 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I22SNQU7MT3XRT6H6ULZYQTL3AVCNFSM6AAAAABO5COYXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZXGMZDIOJSHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rPraml]

further input follows. Can someone change this PR to draft? I do not have the permission (or do not find the "convert to draft" button 😆 )