Calling native V8 JavaScript functions from Java

J2V8 is a set of Java bindings for V8. J2V8 brings the V8 API to Java developers. We developed J2V8 to help with the performance of Tabris.js, our cross-platform, mobile development toolkit.

A common J2V8 question is, how can I call native JavaScript functions from Java? For example, how can you invoke JSON.stringify() on a V8Object from Java. It turns out to be relatively straightforward.

In the case of JSON, you can acquire this object like any other V8Object. Calling V8Object json = v8.getObject("JSON"); will return a handle to the native JSON object. From here, you can invoke any function on this object using the executeFunction method from Java. The executeFunction takes the name of the JSFunction you wish to invoke and the list of parameters as a V8Array. Putting this all together, you can serialize any V8Object as a JSON string:

  V8Object v8Object = new V8Object(v8).add("foo", "bar");
  V8Object json = v8.getObject("JSON");

  V8Array args = new V8Array(v8).push(v8Object);
  String result = (String) json.executeFunction("stringify", args);
  System.out.println(result);  

  args.release();
  v8Object.release();
  json.release();

For more J2V8 tips and tricks, follow me on twitter.

You may also like...

Share this Post

Twitter
Google+
LinkedIn
Facebook

Tags

2 Responses to “Calling native V8 JavaScript functions from Java”

  1. kishan devani says:

    add support for setter and gettr…
    and also …

    how to build J2V8.

  2. Abrar says:

    Hello,

    We’re using J2v8 in our application and came across an issue which caused a lot of crashes and I’d like to propose a solution for it.

    Issue (2 parts):
    1. The so files that are bundled with j2v8 are named differently for each architecture type. For example, libj2v8_android_x86.so and libj2v8_android_x86_64.so which by the way are the same exact files, just named differently.
    2. The application using j2v8 crashes in many cases because it can’t find the ‘.so’ file for the CPU architecture. The problem I believe is in the LibraryLoader.getArchSuffix() method which is used while constructing the file name for the so files. Based on the ‘os.arch’ this method returns the arch suffix and appends it to the file name. The issue is that it is really hard and probably not ideal to expand / maintain method for all os.arch types. For example, currently this method does not support or check for archv7a which is what most of the new Android devices have (Samsung s6 edge for instance).

    Proposed solution:
    1. I believe that the so file names should be generic and they should be placed in appropriate jniLibs directory. Then we should trust Android to look in the appropriate directory and load the correct so file. For instance, the structure would look like this:

    “`
    -> jniLibs
    –> armeabi
    —> libj2v8_android.so
    –> armeabi-v7a
    —> libj2v8_android.so
    –> x86
    —> libj2v8_android.so
    “`

    2. We can completely get rid of LibraryLoader.getArchSuffix() and do not append anything to the filename before loading the library.

    Then j2v8 can be distributed as an AAR with the above directory structure, which people will be able to use in their application an an Android library.

    I’ve tested the above approach and it seems to work fine with most arch’s I was having issues with since Android picks up the appropriate so files. Furthermore, this means we’ll have less so files and will reduce the size of the APK (for example instead of having x86 and x86_64, we’ll just have one file).

    Please let me know what your thoughts are on this. I’m happy to make the changes once we agree on an approach and can create a pull request. I just wanted to run this by you first to see if you agree with the above and if I have missed anything.

    Thank you!

    Kind regards

2 responses so far

Written by . Published in Categories: EclipseSource News, Editors choice

Looking for a job?

X
Karlsruhe / Remote
JavaScript
Mobile
Karlsruhe / Victoria / Remote
Windows
Mobile
Karlsruhe / Victoria / Remote
Java
Android
Mobile