Preparation for liveconnect separation

[rPraml]

Hello,

I've once again tried to identify the classes required for LiveConnect and move them into their own package.

This PR is intended to convey the rough plan. I assume it won't be merged in this form.

However, I would like to update it from time to time to document the current progress.

What's this actually about:

In my vision, Rhino should be divided into a core part (e.g., rhino) and a part that enables interactions with other Java classes (e.g., rhino-liveconnect).

rhino-core should be as free from reflection as possible (which is already largely possible thanks to the good work done recently in the Lambda area) - all these classes are moved to the lc.java package now (Maybe the name will change)

The advantages I expect from this:

• No use of reflection in rhino-core
• This will result in better compatibility, e.g., with grallVM native-image.
• (Presumably) better performance
• Security gain - Reflection may provide a potential attack surface for escaping a sandbox (although it's no guarantee that Rhino is secure)
• Splitting it into rhino and rhino-liveconnect allows for a leaner version

Disadvantage

• Moving certain classes will break one or more APIs

As described above, I will try to split the PR into several smaller PRs. e.g

• remove VMBridge (it dates back to a time because of Java 1.5 - we are 11 now and there - and we have multi release jars now, if we really need this)
• Use lambda initialization for all core - classes

BTW: This looks promising now. Test262 will run without LiveConnect classes

[gbrail]

Thanks -- I'll look at the various bits as they get implemented.

I think this is an important evolution, as it makes the core of Rhino more compact and less vulnerable to exploits.

We spent some time naming modules when we created the module structure, and I think it's important that the main module continue to be named "rhino" and not "rhino-core". The new module could be named "rhino-liveconnect," or "rhino-reflection" or "rhino-java-integration", I'm curious to hear other suggestions!

[ZZZank]

missing quit?

[ZZZank]

Is it possible to make a bulk registeration? Like so:

var properties = Map.<String, SomeFunction>of(
    "print", Shell::print,
    "quit", Shell::quit,
    "version", Shell::version,
    "load", Shell::load,
    "help", Shell::help
);
for (var entry : properties.entrySet()) {
    // define property, but how to determine the "length"?
}

It should be easier to read and maintain

[rPraml]

please see https://github.com/mozilla/rhino/pull/1993/files
If static import is used, it would match in one line.
but maybe it makes sense to replace
defineProperty(this, "defineClass", 1, Global::defineClass, DONTENUM, DONTENUM | READONLY)
by
defineFunctionProperty(this, "defineClass", 1, Global::defineClass)

[ZZZank]

Same as Shell, bulk registration would be nice

[ZZZank]

how about adding a common SpecialEquality interface for JavaEquals and StatelessEquals:

interface SpecialEquality {
    boolean rhino$equals(Object o);

    interface JavaEquals extends SpecialEquality {
        default boolean rhino$equals(Object o) {
            return this.equals(o);
        }
    }
}

Then in the future, we can handle objects with new special equality without having to modify EqualObjectGraphs code (by adding interface implementation)

[ZZZank]

Can we move them to LcBridge.instance.init(...)

[rPraml]

yes, I'll put that on my to-do list