search

caoccao / Javet

Javet is Java + V8 (JAVa + V + EighT). It is an awesome way of embedding Node.js and V8 in Java.
https://www.caoccao.com/Javet/
Apache License 2.0
687 stars 65 forks source link

Questions around Android usage #145

Closed sky-ricardocarrapico closed 2 years ago

sky-ricardocarrapico commented 2 years ago

Hey!

We're currently using https://github.com/LiquidPlayer/LiquidCore (only the V8 part) on our Android app, but since it seems unmaintained and doesn't support debugging, we're looking for an alternative. At first the idea was to adopt J2V8, but then I found this project, and it seems much nicer than using J2V8 directly.

Our use case here is to have our native Android layer calling a JS layer, which uses libs from our company that in the end do network requests and then bring the results back to the native layer. Additionally, sometimes the JS layer will need to retrieve additional information given by the native layer through bridges.

While reading the documentation I gathered some questions/suggestions, mainly around Android usage, and I was hoping to share them before trying to integrate the library.

1. On the docs it says this:

Starting with Android Gradle Plugin 4.0, we can use coreLibraryDesugaring to desugar Java 8 APIs and access them freely on any Android API version. We're currently using this on our app and it works perfectly. This would allow to drop the dependency on ThreeTenBp and I think it would be pretty easy to integrate.

2. If you need ABI version 21/22, please use Javet v1.0.x or contact the maintainer for details.

Our app is still targeting API 21 as minSdk. Is there any reason for the library to drop support for these? Is it because of the APIs that I mentioned above and that coreLibraryDesugaring` solves?

At the same time, the minSdk on the main branch still shows API 21: https://github.com/caoccao/Javet/blob/main/android/javet-android/build.gradle.kts#L30

Did this go forward?

3. We'll need to implement XMLHttpRequest on the bridge, delegating to OkHttp. We're already doing this for LiquidCore and it works fine.

Our data flow will be something like:

  1. Native
  2. JS
  3. Native (to make the HTTP request)
  4. JS (with the HTTP response)
  5. Native (with the final result)

In the middle of 2. and 3., JS might need to call additional bridges to gather information.

Do you foresee any issue we might find implementing it?

Thank you!

caoccao commented 2 years ago

Thank you for raising these detailed questions. Javet Android distribution is a completely community driven project. Here are my thoughts for your reference.

Q1: I'll try coreLibraryDesugaring to see if it works for Javet.

Q2: V8 v9.7+ requires a more up-to-date clang which is not supported by the legacy Android NDK. I spent a whole weekend figuring out how to upgrade to V8 9.7+. The build always failed below ABI 23. I did a small range of survey among Javet Android users. They were fine with ABI 23. The door is not completely closed to ABI 21-22, but that requires tens of hours of investigation. It wasn't a good investment of my time. That minSdk in build.gradle.kts slipped through my fingers and was just corrected in the dev branch. Thank you for pointing that out.

Q3: That is not a problem. Almost all Javet use cases (most of which are proprietary projects) have the similar workflow as you posted. Project Javenode developed by me is a good example in the open source world.

In summary, I think the major hurdle in your case is the ABI 21-22 compatibility.

Approach Javet v1.0.x Javet Latest
PROS It meets all your need. It is in sync with the main branch.
CONS It requires extra effort in cherry picking the main branch up. The V8 stays at v9.6. The ABI 21-22 remains a question mark till a throughout investigation is completed.

Hope these make sense to you. If you are interested in adopting Javet, please visit discord to discuss with me in private.

sky-ricardocarrapico commented 2 years ago

Thanks for answering!

I started integrating the lib to explore a bit. If all goes well I'll probably look into contributing something (Android wise). My NDK knowledge is zero though, so I'm not sure I would be very helpful in that aspect. By keeping updating v1.0.x, would you rather see that cherry-picking and version releasing happening on this repo or should I eventually fork it?

caoccao commented 2 years ago

Well, wish you a wonderful journey.

I'm fine with creating a long-term branch for v1.0.x. I think it's better to keep it in the same place for the community. The docker build for Android should be good enough. And if you need me to release that branch to maven central, just let me know.

caoccao commented 2 years ago

I spent a few hours investigating these. Here is some info for your reference.

sky-ricardocarrapico commented 2 years ago
  • Unfortunately, coreLibraryDesugaring doesn't fit in because V8 has to support Android 3.0. Please refer to this commit and this [revert]

I'm a bit confused. Android 3.0 is API 11 while the min API that the lib is requiring is now API 23. And on the Java 8 support docs I don't see anything mentioning Android 3.0, only Android Gradle plugin 3.0.0 (while the lib is already using 7.0.3).

What do you mean by this?

(https://github.com/caoccao/Javet/commit/a44ae2e4e1f105623b3d170b4fece6b765057cfe) for detail.

  • I created a dev branch for v1.0.x. You are welcome cherry-picking new features up.

Thank you!

caoccao commented 2 years ago

I'll try again sometime later. V8 is compiled against Android SDK 3.0. Upgrading that SDK may be tricky.

caoccao commented 2 years ago

I managed to have coreLibraryDesugaring work. You are welcome trying the new release and please let me know if you have any questions.

sky-ricardocarrapico commented 2 years ago

Hey, thank you! That's great to hear.

I'm still working on the integration on our side. I'm building an abstraction on top of our current runtime so I can switch one for the other, that's why it's taking so long. But I already have most of the Javet implementation of this abstraction, and let me tell you, it's unbelievable how easy it is to do the same things we were doing with the other runtime. Everything just simply works. Amazing work 👌

caoccao commented 2 years ago

Thank you for the compliment. Best wishes to your integration.

GrahamBorland commented 2 years ago

Which version of Javet do I need to get coreLibraryDesugaring to work? I'm experimenting with javet-android:1.1.6 and I see a dependency on org.threeten:threetenbp:1.3.7 which is conflicting with some other dependencies in my app.

Thanks!

caoccao commented 2 years ago

Starting from v1.1.1, Javet Android has no longer depended on that library anymore. I wonder if there's a misconfig in your case.

GrahamBorland commented 2 years ago

The Gradle dependency report shows this dependency:

+--- com.caoccao.javet:javet-android:1.1.6
|    \--- org.threeten:threetenbp:1.5.1

And the dependency is declared in the pom.xml here: https://github.com/caoccao/Javet/blob/7058c0275043ce79f8d14113c3af1400c1491238/android/pom.xml#L53-L55

caoccao commented 2 years ago

Thank you for pointing it out. I missed that in the pom.xml. This commit was just pushed. It'll be corrected in the next release.

Is it possible to exclude that dependency in your project as a temp solution?

GrahamBorland commented 2 years ago

Fantastic, thanks for the response! I'll look at excluding it.