v8-adapter project visibility & discovery

[AlexTrotsenko]

This project looks really great and provides nice way for sharing Java classes in JS runtime.
The only problem for me was - it is very hard to discover it.

Few ideas, which, as for me, might help other people to find, benefit and contribute to this project:

1. Add link to this project in the the "read me" of J2V8 itself.
2. Rename project/repo to something like J2V8-adapter. It will help people to discover it during the search in GitHub. E.g. Simple search for "j2v8" shows similar, but not finished J2V8-classes, but not v8-adapter.

P.S. I have found this project when I was checking issues of J2V8 and thus found your comments about v8-adapter in the different issues. So, this is really helpful as well.

[caer]

That's a really good point! I've been concerned about visibility for a while now, but was sort of letting it slide until there was a more complete feature set in the v8-adapter project. Answering your ideas in order:

1. I think a link in the J2V8 readme would be a good move. However, I am not sure how they would feel about that (it should be fine since we're built on top of J2V8, but I always feel bad using one repository to advertise another). We could submit a PR and see what they say?

2. I had this debate when I was setting up the Maven coordinates for the V8 adapter. I think I wanted to ensure a separation from J2V8 and this project (in case the underlying V8 engine changed), but I realize now that this one relies so heavily on J2V8 that it would be nonsensical to try to separate them. There's absolutely no reason why it can't be renamed to the J2V8-Adapter.

[AlexTrotsenko]

Sounds good, I will prepare pull-request for J2V8 readme: I guess it will also looks good when it's not from lib's creator. Let's see what they answer. But theoretically it should be fine because:

• "v8-adapter" is one more good reason to use J2V8 itself.
• If you change name to J2V8-Adapter - then it's one more way to "promote" J2V8
• You already have good mention of J2V8 in this project wiki.

Concerning "feeling bad using one repository to advertise another" - that's true indeed, but I guess that this project could be really helpful for common users of J2V8 - thus it looks fair enough (at least from my point of view it's so, while there is nothing good like it around).

Please, let me know if you want to rename the project to J2V8-Adapter before I do the pull request to J2V8 wiki.

[caer]

Hey @AlexTrotsenko ! I'm bringing this thread back to life...

The official J2V8 repository has been silent, so I'm wondering if it may be better to branch off as a new project anyway. Thoughts?

[AlexTrotsenko]

Indeed, j2v8 is almost not active since August 2017 - with only few minor commits in December.
Thus, forking is indeed sounds like a good idea.
What's also make me sad is big amount of open pull requests in j2v8. The only question for me is what kind of issues should be addressed in such fork? I have not yet worked much with V8, only starting working with it this year - switching from Rhino.

Something, which I found annoying already:

• V8PropertyMap is "class is not considered API" according to the JavaDoc, but .toString() does not print content, but class name. It's resulting class of V8ObjectUtils.toMap(V8Object) utility class.
• Also despite changes like this, new releases are not available on wide amount of OS. E.g. latest 4.8.2 is missing for Mac OS X (last available is 4.6.0, which is one year old).

What is your thoughts on this topic?

[caer]

If we fork J2V8, I would probably fork it as a new project with a new name, and roll the features of this project into that one. My reasoning is that (I believe) the scope of J2V8 has grown wildly large, and it's trying to do more than provide a robust embeddable JS runtime...especially considering all the open issues and PRs.

Specifically, if we were to fork that project, I would not want to support Node.js. I am sure many people like it, but the use cases that our organization needs do not include Node.js. From there, we could streamline the build process, and probably perform a number of performance enhancements to make the features of this project work better and with less hacks.

[AlexTrotsenko]

@crahda what you are saying indeed make sense.

I think, that Ideally "j2v8" should be core project with ability to extend it easily by projects like this one without any hacks.
E.g. No Node should be inside "core" project, but possibly outside as separate "extension" project (similar to this one).

Concerning fork with another name: as for me, the main issue with maintaining such fork is merging useful changes from original repo to the fork. But taking into account, that unfortunately j2v8 was not developed for at least 4 months now - no major improvements is expected and thus forking it indeed makes sense.

So, as for me, the question now is about time resources. E.g. At first glance, only re-structuring, clean-up, etc. will take significant amount of time.

Thus in order to estimate efforts&time it makes sense for me to list upfront the goals, which are planned to be achieved with such re-structuring before stating the process.

For example:

1. Only V8, no NodeJS
2. Easier builds for most platforms: e.g. Android, linux, mac, etc.
3. up-to-date V8 runtime
4. Same V8 version in the same j2v8 version across all the platforms.
5. "Transparent" integration with "extension" projects. E.g. for v8-adapter: j2v8 project api should "transparently" deal with injected classes. Simplest example: V8ObjectUtils.toMap() or V8ObjectUtils.toList() should work similarly to V8JavaObjectUtils.translateJavascriptArgumentsToJava(): inner java-based JS objects should be converted back to java objects.
6. etc.

Some comments on last 2 items:
4. - I have found, that:

• 'com.eclipsesource.j2v8:j2v8:4.6.0@aar' has V8 4.10.253
• 'com.eclipsesource.j2v8:j2v8_macosx_x86_64:4.6.0' has V8 4.6.85.31
  As for me, it's not acceptable, that platform-specific variant of the same lib has another V8 version inside!

5. Concerning j2v8 project api dealing with v8-adapter classes:
   I have found, that there is a way, to specify "custom adapter" at JS/JAVA conversion. This ability was added quite recently. I am thinking of creating such adapter to deal with object injected by v8-adatper. Does it make sense for you?

[caer]

This is really good feedback, and I continue to believe that forking is probably the best option moving forward. The last update was in December of last year.

A good roadmap will be important; our (Alicorn Systems') goal would be to create an embeddable Java Script run-time that can be cleanly extended to support modifications both at a high-level (e.g., in Java) and a low-level (e.g., in C++) without disrupting the core project. This kind of expandability is critical for a new project that we are working on that requires zero-copy data passing between Java and JS.

To this end, and building off what you said, we would want to do the following (in order):

1. Fork the J2V8 project and rename it.
2. Remove all support for Node.js
3. Update all build scripts and ensure same V8 version is built and tested simultaneously for all artifacts and platforms.
4. Update to latest V8 runtime.
5. Merge with this project and develop a simpler but more expandable Java API for extension projects. This would include removing non-essential public APIs for the original J2V8 project and this project.

In all cases, if we assume responsibility for a fork of the J2V8, I would like to ensure that we begin writing our code to avoid as much garbage creation, blocking, and run-time reflection as possible. It will be difficult, but it could drastically improve the performance of the runtime in many cases (especially when dynamically injecting objects and classes).

[windrunner414]

Do you have plans to do these?
I'm now trying to remove nodejs and use the latest v8

[caer]

@windrunner414 Thanks for the note. I was planning to defer integration of the V8 project until it was definitively dead. We are about to hit the six-month mark, though, so I think it may be appropriate for us to fork. Let me work on some other issues and I will re-evaluate.

[windrunner414]

If you're ready to start, we can work together

[caer]

Let's move this discussion to #17 .