Questions around Android usage

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:

• [ZonedDateTime](https://developer.android.com/reference/java/time/ZonedDateTime) (since ABI 26) is polyfilled by org.threeten.bp.ZonedDateTime so that Javet can work well with low ABI version.
• Stream and Optional are not supported because they are not available with ABI version 23-24.

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!

[GrahamBorland]

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

[caoccao]

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.