Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Next Generation V8 Engine for Java #17

Open
caer opened this issue Jun 22, 2018 · 13 comments
Open

Next Generation V8 Engine for Java #17

caer opened this issue Jun 22, 2018 · 13 comments

Comments

@caer
Copy link
Member

caer commented Jun 22, 2018

We have been working on the V8 adapter for the past year now, adding new features and fixing bugs where they show up. Because this project never had a formal structure or goals, it has grown wildly and seen many new features, etc. Unfortunately, the base project - J2V8 - has also grown quite wildly and has not received any new commits in the past six months.

Knowing this, I would like to propose a new work effort to do the following with this project, in this order:

  1. Split up the unit test suite into separate test files for related functionality. Having one giant test is hard to maintain.

  2. Remove all static fields and instead wrap V8 objects in a new V8Runtime object which contains its own V8 instance and injection API. Class caches can be per-runtime or shared.

  3. Cull all annotations and options that do not directly relate to injecting Objects, Classes, and Methods as they are.

  4. Introduce a formalized API for decorating classes or groups classes with additional features like those found in Setter/Getter support #1 and Conversion of Java Maps and List to JS objects and arrays. #11 by third-party applications. We may provide built-in implementations for marshaling getters and setters, as a convenience. This API could also include a ByteBuffer-based messaging system so that the host (Java) may communicate with the guest (JavaScript) without a single JNI call, thus dramatically improving performance.

  5. Merge in the J2V8 project by taking only the V8-to-Java components (no Node.js support).

  6. Formalizing the build process so that all major platforms can be built for from the same system for the same V8 version at the same time.

This is a lot of steps to perform - and they will definitely cause breaking changes - so I would like to hear from other contributors, particularly @AlexTrotsenko. Thank you all so much for your time and interest!

@windrunner414
Copy link

Now I have successfully removed nodejs and upgraded V8 to 6.7
tim 20180623130130
tim 20180623130144

@windrunner414
Copy link

it seems not work on Android4.x (armeabi-v7a)

@AlexTrotsenko
Copy link
Contributor

@crahda nice plan !

I have some functionality ready, which is not directly related to the V8, but likely would be nice to have by other users, e.g. console.log(), which logs to Android output, etc. Similarly, our scripts uses node-like .setTimeout() api, etc. Would you like to ingrate such api in the new project under "utils" scope or prefer to keep them in separate project?
Second option looks preferable for me, but better to double-check upfront.

Second important thing is debug ability. As far as I see, currently there is only primitive debug api inside j2v8. As far as I see, there was debug ability from Eclipse in the past, but not anymore. How do you do it now?

Small hint for short-term changes: V8JavaObjectUtils.getRuntimeSarcastically() looks redundant if latest J2V8 is used.

Also, since it will be quite a new project I have to ask what do you think about using Kotlin for it?

@windrunner414
Copy link

i think these api should be kept in separate project
It's great to use kotlin
J2V8 use some outdated API(in v8 3.1)

@caer
Copy link
Member Author

caer commented Jul 3, 2018

@AlexTrotsenko : It would be preferable to implement all of that functionality as external modules of some kind. The goal will be to keep everything in this project as light as possible so that individual users can decorate the core JavaScript language as-needed. Debugging functionality could be added as a stretch goal (and would be very helpful), and several methods (like the sarcastic method) can definitely be removed as a part of these changes.

@windrunner414 : Awesome work on the new builds!

I am not familiar with Kotlin, and thus would not be able to support it in any capacity for this project. However, I am sure it would be possible to implement a Kotlin API of some kind if you thought it would be valuable - but again, that should be an add-on for this project and not a part of it.

@ewized
Copy link

ewized commented Jul 3, 2018

following

@re-thc
Copy link

re-thc commented Jul 3, 2018

Jooby also uses j2v8. Maybe worth contacting them to work together?

@caer
Copy link
Member Author

caer commented Jul 9, 2018

@hc-codersatlas That may be a good idea! This week I'll be looking into how fast we can complete the tasks mentioned in this issue and try to put together a roadmap.

@AlexTrotsenko
Copy link
Contributor

One more thing to mention in order not to forget it later: for now j2v8 is missing 64bit support: eclipsesource/J2V8#384

@AlexTrotsenko
Copy link
Contributor

@crahda since I was asking before:

I have created j2v8-debugger library.

It allows debugging J2V8 using Chrome DevTools.

Basic features like setting/removing breakpoints, step into, step out and step over, variables inspection, etc. are implemented.

It uses Stetho lib for communication with Chrome DevTools.

Also it's uses DebugHandler for accessing V8 debug information.

I hope, that it could be helpful already now and could be good add-on for upcoming fork project.

@caer
Copy link
Member Author

caer commented Oct 9, 2018

Hi @AlexTrotsenko ! Awesome work; seems like a cool library.

Since J2V8 appears to be alive again, we are diverting our efforts elsewhere. As far away as it sounds, you can expect another update from me sometime within the next six months --- we are planning a new fork of this project that will hopefully get rid of many of the pain-points we've been dealing with in regards to Java-JS bridging, but it will not be for general-purpose Java integrations (in order to narrow the focus of our development and provide a consistent development experience).

Thank you for the update!!

@caoccao
Copy link

caoccao commented Apr 7, 2021

I wonder if you get a chance to evaluate https://github.com/caoccao/Javet/ that is a brand new library with Java + Node.js + V8. I'm the maintainer of Javet.

@caoccao
Copy link

caoccao commented Jul 29, 2021

Neverminded, Javet started to support injecting arbitrary Java objects in V8 from v0.9.6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants