Reduce the scope of the J2V8 project

[irbull]

The J2V8 project tried to support too many things. It tried to be:

• A highly performant Java-based JS runtime for Android
• A highly performant Java-based JS runtime for other platforms (Windows, Linux, Mac)
• A set of bindings between Java and NodeJS
• Support for cross compilation from Windows, Mac and Linux to Windows, Mac, Linux and Android

While these are related, I simply cannot keep all these different plates spinning at once. On Android alone, we need to support at least 4 different platforms (x86, x86_64, arm, arm64). Mix in Windows (x86, x86_64), Linux (x86, x86_64), and Mac support, plus optional Node support for all these platforms and the number of targets is too much for me to test/maintain.

I am going to reduce the scope of this project to only support Android, non-NodeJS. Futhermore, I'm only going to support building from Linux to the 4 flavours of Android (x86, x86_64, arm, arm64). This doesn't mean I don't think the other platforms are valuable, I just can't manage them. I'm happy to either support a downstream project which enables other platforms, or link to someone else who wants to build these platforms.

What does this mean for the project:

• I'm going to be removing the NodeJS support. As I mentioned, I'd be happy to find a way to work with a downstream project if someone wants to maintain it
• I'm going to leave the existing build scripts in place (for windows, mac, linux), but I won't be producing builds with these. I also won't be maintaining these scripts, but if someone can offer PRs for them I'd be happy to apply them (assuming the PRs don't break the Android builds).
• I'm going to be closing issues that are out of scope. Again, if someone wants to maintain a downstream project, we could move those issues there

I'm sorry for any inconvenience, but honestly I haven't been building those other platforms for a few years anyways, and I certainly haven't been maintaining them. This really just makes explicit what has been happening implicitly for a while now. I hope by setting honest expectations and reducing the scope of this project, I can give more attention to its original goal, a set of Java bindings for V8 running on Android.

Comments and feedback is welcome.

[GrahamBorland]

This makes perfect sense.

[mccoysc]

Maybe nodejs support is more important than support so many kind of platforms.if only a js engine,we have much more choices,like webview and so on.but to nodejs,we have no choice.

[JessHolle]

There seems to be no reasonable JS engine alternative on Android, so the focus is appreciated.

If Microsoft keeps going aggressively towards Chrome and away from Edge the need on Windows platforms may eventually become as great there - but for a bridge between V8 and C#, rather than Java.

[irbull]

@mccoysc I agree that nodejs support is very interesting. However, on Android, it has never worked (we were not able to get NodeJS to cross compile for Android). I also don't have any funding to work on that, and we'll I would love to promise that I would work on it on my own time, we all know that the road to hell is paved with good intentions. That's why I think it's better to be honest about what I can support.

If someone is able to produce NodeJS builds for Android, the J2V8 bindings may be a good starting point.

I agree with @JessHolle that there is no reasonable JS engine for Android, which is why we built J2V8 in the first place.

[pendzjo]

@irbull - I've recently becoming very interested in this project for the Windows/Linux/Mac binding to NodeJs. I guess I would be interested in supporting a downstream project to maintain those, unless anybody knows of another project that can do this?

[re-thc]

@pendzjo the only other alternative is Graaljs from Graal.

[jamesrgrinter]

@pendzjo I’ve been looking around, again, for Script Engines to embed/ call from existing Java code (running on Linux/ia64) I’d already dabbled, and crashed the JVM, with this project’s NodeJs bridge - but being able to execute Node based code within the JVM, and call back out to Java methods, is still of interest to me. I’ve just come back to this after spotting a comment left on the issue I’d created.

With Nashorn being deprecated (and actively being dropped), no recent work being done on Jython, there’s not much else in around that is even trying to keep up to date with scripting language implementations.

I just don’t yet have any resource to be able to commit to helping with the effort, certainly not without a better understanding of what might be required to get it into a working state and keep it there.

[pendzjo]

@jamesrgrinter Sadly, I haven't really gotten started on anything, standing up a build environment for Windows has turned out to be more difficult and time consuming then envisioned (side note when I did pull request for #440, the linux setup was a breeze). I was hoping to get a build out supporting Linux and Windows using Java 1.8 and some updated LTS version of V8/NodeJs, still want to do it and have a pet project that needs this (so haven't forgetting it), but other priorities took me away from finishing setting up a Windows Dev environment (hopefully this will force me to look back into it...think will start a repo on my page call it j2v8-OS (@irbull, is that ok?) and keep track of what I'm doing there once I get the windows dev stuff going).

[irbull]

@pendzjo sure. Make a fork and hack around. Let us know if you make any progress with the windows stuff.

[pendzjo]

@irbull/@jamesrgrinter, I've been picking away at this for the last couple months. Managed to get the building/code base to compile with Java 1.8 and Node v12. But the node engine crashes when it attempts to be created or execute (all depends on how I try to make it work within the JNI). @irbull thanks for the amount of testing you put into the build system, it made the work of getting this far just a simple exercise of fixing what is causing the test to fail.