Converter for support for all Javet objects

[Cormanz]

Hello, I'd like to propose a suggestion! I know Javet has support for Interception, but coming from previously using GraalJS, being able to interop with any java object is just very, very convenient. Perhaps Javet could implement such a converter (I've attempted to but had some problems) which converts any Java object to a V8 object.

My idea of how this could work is like so:

You take some Java object, use Reflection to extract all of its methods, and you make the V8 object have those methods too. Then, in JS, when I call javaObject.meth(1), it's going to get the actual Java object and call that method.

I think this would be really useful since it would allow for even more easily interoping between JS and Java.

[caoccao]

Thank you for raising this feature.

I intended to leave that to Javet users for 2 major reasons:

1. That brings considerable performance overhead. Currently JavetObjectConverter doesn't register property/function interceptors so that performance is excellent without runtime reflection.
2. Java allows overloading functions whereas JavaScript doesn't. Moreover, JavaScript allows passing less arguments. So, guessing which Java method is the one requires considerable coding effort. If it's not designed well, stack-overflow may occur.

As you've met, I think it's almost impossible to achieve that without support at JNI level. I'll consider doing some experiments. Of course, that takes some time.

[caoccao]

The JavetProxyConverter and related document has been included in this commit.

Here are few issues in your approach for your reference.

1. It will face issues when dealing with overloaded methods. As JS doesn't have overload, Javet needs to guess which overloaded method is the most suitable one.
2. Its performance is not good as there are too many callback to be registered.
3. Its memory footprint is a little bit higher as every callback context has to be stored.

Please wait for the next release, and let me know if you have any questions.

[Cormanz]

That's true, the proxy converter is probably a better idea. Saw the new commit since I have this project subscribed/followed on github, thank you so much for adding this!

One more thing - perhaps for security purposes, the converter could be initialized in such a way that only specific packages and/or classes can be converted to/from Java?

[caoccao]

Yes, regarding the security, there are a few ways of achieving that. Subclassing, config, ... I'll find one or multiple suitable ways without performance overhead later.

[Cormanz]

Maybe one idea of what you could do is to allow for a lambda to be passed as an argument, which would take in the class instance, and return a boolean of if that lookup should be allowed or not.

[caoccao]

I decided to recommend subclassing for complete customization in response to the following challenges.

1. Class level filter customization
2. Generic template level filter customization
3. Method level filter customization
4. Value level filter customization

My current thought is it's quite hard to satisfy them in a simple way. So subclassing seems to be the only way, though it is not ideal.

Please refer to this commit for detail.

[caoccao]

Now, it's included in v0.9.6. Enjoy.

[Cormanz]

Appreciated! Thank you!