Android Support - Removing MethodHandle [API <26]

[Anuken]

I am considering GraalJS as a scripting solution for my cross-platform Java application, which targets desktop (OpenJDK), Android and iOS (w/ RoboVM). After adding GraalJS to my build.gradle and adding some basic test code, I get the following compilation error upon attempting to launch an Android application:

com.android.tools.r8.utils.AbortException: Error: MethodHandle.invoke and MethodHandle.invokeExact are only supported starting with Android O (--min-api 26) (truffle-api-19.3.0.jar)

This means that I would need to switch to API 26 if I wanted to use GraalJS as is. The issue is, devices at API level 26 or above make up only ~30% of the market, and thus my current minAPI is set to 14, and I would like it to stay that way.

My question is, would it be at all possible for me to either manually remove usage of MethodHandle from truffle-api, or emulate the functionality with another class internally? I am aware that this will lead to reduced performance, but it is preferable to no performance at all.

Code, if at all relevant

//in build.gradle, main module dependencies
 compile "org.graalvm.js:js:19.3.0"

//in any source file inside application
Context.create("js").eval("js", "console.log(\"Initialized JS context.\")");

[wirthi]

Hi @Anuken

thanks for your question and trying to run Graal.js on Android.

I see at least three core classes in Truffle-API use MethodHandles. We also use MethodHandles in some places in Graal.js, but none of them is relevant to the core engine. So yes, maybe you can rewrite that code to use something different, but I cannot guarantee that is the only problem you would have.

@vjovanov or @chumer do you have any thoughts on this?

Thanks, Christian

[vjovanov]

We are not using RoboVM in GraalVM. We use native-image to deploy to Android and I don't see how we could get com.android.tools.r8.utils.AbortException: Error: MethodHandle.invoke and MethodHandle.invokeExact are only supported starting with Android O (--min-api 26) (truffle-api-19.3.0.jar) as the error message. Did you use tools from

https://github.com/gluonhq/client-maven-plugin

to get this deployed?

Also, note that on iOS you will have to disable the JIT in native-image for this program to work.

CC @johanvos who is working on Android support in Gluon and maintains the client-maven-plugin. CC @lazar-mitrovic who is doing pretty much the same thing for a demo.

[johanvos]

If you use the regular android build tools, you'll still have a regular android application. Using Gluon Substrate (https://github.com/gluonhq/substrate) via the client-maven-plugin (https://github.com/gluonhq/client-maven-plugin) you will under the hood use GraalVM native-image to convert your whole Java application into a native library that is then loaded on Android by a default Activity. Doing so, you can use the latest Java instead of the Android "Java".

Work in progress, the build logic for Android will be integrated in Substrate very soon now (a few days).

[frank-dspeed]

Other related question what is about running node on android ????

can it get compiled to LLVM and then integrated?

i am working at present on open-pwa and we are build on node at present but would love to use graaljs-node

we have a extra fork of nodejs for ios and android and the nativ nodejs does run on most of the other platforms

so the question is will node-graaljs also need to have own forks for android or is that solved via graalvm already?

Did Some One try to Package node-graaljs?

node-graaljs === c code graaljs === gets compiled to LLVM

can node-graaljs get compiled to LLVM already?

[wirthi]

can node-graaljs get compiled to LLVM already?

We have done some experiments on that. Using Sulong (GraalVM/LLVM) to execute the C parts of Node.js and thus nicely integrating the JS and the C parts into GraalVM. We got that to work, and see nice peak performance as the language boundary between JS and C folds away, but warmup is worse than it is now as you need to warm up all the LLVM code in GraalVM. This is still a long-time goal for us.

[wirthi]

Closing this ticket, as direct support for Android is not on our (GraalVM/JavaScript's) agenda.

[frank-dspeed]

@wirthi graaljs javascript is already working on android via graalvm but the node part needs work but good to know.

[wirthi]

Happy to take improvements in that area! We won't work on that - my team (GraalVM/JavaScript) does not have Android on any agenda, not even longer-term.

The original question regarding MethodHandles is one we will not resolve either. Our compatibility goal currently is JDK11 and we expect runtimes to support that.

[frank-dspeed]

@wirthi your biggest market will be the browser market once some one got any useable browser working with graalvm your project will takeoff

[wirthi]

How is that? Graal.js is not targeting Browser at all. Our design goal is Servers.

[frank-dspeed]

@wirth there is some effort in getting GraalVM into CEF the Chromium Embedder Framework to produce apps and replace v8 there with graalvm to run any lang with a interface Electron alternativ and so on. As also there are plans to get alternativ languages running for the web

Also there is Equal Mozilla effort.

[frank-dspeed]

The CEF Implementation would be a Game Changer since we could then more easy Code Nativ Modules in more languages. as also interpret more languages some how like in the old days with the Java Runtime as Plugin :)

CEF can then Expose a nice JavaScript API even for the Nativ Parts

[wirthi]

Can you point me to the CEF work? I am not aware of that.

[LifeIsStrange]

@frank-dspeed Please update, integrating graalVM into chromium would be the software revolution of the decade, enabling polyglot language support order of magnitude better than wasm and with much better performance!

[frank-dspeed]

@LifeIsStrange @wirthi there is no public repo of the branch at present because it is in a bad state i am the only one working on it at present it is NWJS (a C++ CEF Project) which exposes Chrome APP and Chrome Plugin Context API's + some tweaks needed to code desktop apps (transperent window features and so on) also exposing a JS API and Building NodeJS With the Same V8 as we use for CEF.

My Road is now to Get the same working but replacing v8 with GraalVM.

Current State

I got working builds of NWJS With V8 and Exposing graal-node not sharing the v8 context but messaging works and so on

What needs to get done?

CEF Needs some new apis that do implement CefV8Context this is how the v8 context is Handled inside CEF there we need to return a compatible graalvm implementation. https://magpcss.org/ceforum/apidocs3/projects/(default)/CefV8Context.html

Time estimated till that works?

Maybe years as sayed i am the only one doing it at present and i got money problems because i work to much on my research and not on getting money i am doing it because it needs to get done.

But Can you hackaround with it already sure

CEF is not so Complicated at all so running experiments with it in all directions is already simple you can call into the JVM from C and vice versa.

the part that takes time is shiming the API as CEF has got a own abstraction over v8 called CefV8

About Nativ Image

JNI Works great with graal-node compiled as nativ. So The most first easy integration is to build

• https://www.graalvm.org/22.0/reference-manual/native-image/JNI/
• https://www.graalvm.org/22.0/reference-manual/native-image/#build-a-shared-library
• https://code.google.com/archive/p/chromiumembedded/issues/708 v8 as shared lib in CEF
• Missing part v8 isolates compatible shim to build a native image as shared lib that we can call from CEF

[LifeIsStrange]

@frank-dspeed If you achieve this (being able to have Kotlin or python, java or even scala code in the browser) via GraalVM you would enable a software disruption and be officially my #1 favorite coder. Is there a place where you document progress? Indeed I hope Oracle will see the opportunity to contribute towards that endeavor as that would be groundbreaking and enable so many uses. In parallel to performance, each language ecosystems has unique libraries in specific domains that would very greatly complement the current web. It would bring on the web platform the human resources of hundreds of billions of dollars spent in libraries development.

Did you consider going the Electron vs CEF route? pros and cons? Also google made an interesting proof of concept showing a webview<-->v8 architecture that does message passing over RPC https://github.com/GoogleChromeLabs/carlo You might wanna take some inspiration from this work?

An alternative to JNI is javacpp, I've heard it enable very great interop between C++ and Java https://github.com/bytedeco/javacpp

also do you have a github repository for this? code?

[frank-dspeed]

@LifeIsStrange if that was not clear that is already possible lets open a issue for that maybe i get more people to join that. And ya i am the new maintainer of carlo even with my project called open pwa https://github.com/open-pwa/open-pwa

i am specialist for interop integration and as you maybe saw in my current github readme i am deep into devtools also carlo got deprecated because we got a whole new concept that is even more destruptiv.

Many people are not aware of the fact that we the chromium dev community already ship the electron killer via our puppeteer npm package it ships devprotoocol + chromium current can be systemwide installed and it can reuse the current chrome version that is installed on the system. Even the IE Chrome one.

so that eleminates the overhead of the electron concept.

i am also part of the most current fastest web framework i am doing at present the http3 optimisation for the just js project

and that is part of my other work a p2p internet that even works without IEEE compatible hardware.

So i am deep into interop and integration. Maybe you want to follow https://github.com/stealify/stealify the org is a gigantic mess because i had so many concepts and integration designs but you can see what it is about i have for example

Apache Ignote NodeJS bindings and such stuff many JVM JNI stuff

https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite

here the secund ranking framework https://github.com/just-js/just/issues/14

that is for example raw v8 just with some c++ if you ever wondered how to create something with less overhead. That is what builds up Cloudflare Workers by the way.

Issue about GraalVM Browser Integrations

• https://github.com/oracle/graaljs/issues/600 sorry got interrupted while writing

[lemanschik]

closed by:

• https://github.com/lemanschik/web-modules/issues/4

@wirthi above linked issue is the tracker of the cef work as i replaced the whole cef chromium internal we have now a v8 based component system inside chromium.

inside out reverse control

this enables directly interop with the chromium content component as also the v8 components via the chromium MOJO::IPC that connects everything