How to define rules to avoid some methods during Java method discovering

[gusriobr]

I'm trying to embedded mozilla rhino in an android project to use js scripting with android view components through liveConnect.
It works really well but I'm having a problem during the Java method inspection.

When a class has methods with a signature that uses classes not present in the api level of the device, the method inspection crashes with a ClassNotFoundException, this is expected.
In Android, this problem is avoided with method annotation, and the class still works as long as the methods with the missing classes are not used.
For example, TextClassifier appears in android in level 26. TextInputEditText has a method setTextClassifier annotated with @ApiLevel 26, and you can use a TextInputEditText in devices with api level < 26 as long as you don't use a TextClassifier.

The key of the problem is method JavaMembers.discoverAccessibleMethods(), the change is fairly simple, look for annotations in methods, define a rule to exclude classes or to eat-up the ClassNotFoundException.
But instead of patching the code, I wonder if there's a cleaner way to do this without having to modify the library.

Thank you.

[gbrail]

There are so many embedding options in Rhino and I'm not sure if anyone has given you a good idea yet. But is there a specific method annotation that Rhino should be looking for, or an enhancement to the java embedding mechanism that you could possibly use?

[gusriobr]

in my case, the problem arise with methods annotated with tag @ApiLevel, so if the apilevel of the method is greater that the supported device level api, the method must be ignored.

[rPraml]

Maybe I should share my experiments, where I tried to add a securitymanager to rhino:
https://github.com/FOCONIS/rhino/commits/experimental-securitymanager

The most interesting commits are
FOCONIS@48999bb where I add a class shutter that checks a "visibleToScripts." runtime permission.

Unfortunately, the class shutter is not flexible enough at this point:

• Lets say you have a java class MyJavaClass with a method public void java.util.Map getMap()
• Assume that we are allowed to access classes from the java.util package.
• If the method returns a java.util.HashMap everything is fine
• If the method returns a com.sun.xyz.Map, the class shutter will only see the class name and will deny access to the com.sun... package
• I would expect at this point, that the class shutter goes up in the class hierarchy and allows me to access at least all methods that are defined by the Map interface.

That's why I changed the class shutter FOCONIS@9e4c32f and add some methods:

• visibleToScripts: Method left as it is. It will be invoked before the class is loaded
• checkAccessible: Method is called if class is visible to scripts. If class is not accessible, search is continued on super classes/interfaces
• isUseable: as search is always done up to "java.lang.Object", you have at a last chance to decide if you can really 'use' the class in scripts.
• boolean visibleToScripts(Class<?> clazz, Method method) A Method that matches on your use case.

If you check for the @ApiLevel annotation in this method, you may hide some methods from your application code.

I am planning to continue the work on this branch in a few weeks.

[gusriobr]

Thank you, it looks exactly what I need.

When is this branch expected to be included in a release?
https://github.com/FOCONIS/rhino/commits/experimental-securitymanager

[p-bakker]

As the https://github.com/FOCONIS/rhino/commits/experimental-securitymanager branch is based on the now deprecated and slated to be removed Java Security Manager, I don't see this branch (in its current state) ever being merged into Rhino