Is Gluon VM deprecated because of GraalVM?

Gluon and GraalVM work on a bit different levels which in fact means that they can cooperate with each other more than compete. GraalVM is a JVM and a cross-compiler. Gluon provides abstractions for writing apps on different platforms.

Consider, for example, an Android app. GraalVM Native Image lets you compile your code written in a bunch of programming languages to an Android executable, i.e. an APK. With standard Android SDK you would be forced to use Kotlin or old Java (newer Adroid SDKs support a subset of features from Java 8, but meh). With GraalVM you can use new Java, Scala, Python, Ruby... pick and choose.

But GraalVM by itself won't give you any tools to communicate with an Android device. Do you want to display something on the screen? Use local storage? Pr listen for events coming from the backend? Good luck, GraalVM knows nothing about it.

Here enters Gluon. It provides plugins and libraries that work as the abstraction layer between your code and the underlying device, so that - in theory - you are able to write the same code for Android, iOS, and desktop. ("in theory" because in practice each of these platforms requires a bit different treatment anyway). So, for graphical user interface, you will use JavaFX which is maintained by Gluon. You will add it to your Maven or Gradle configuration, and tadaah now you're able to write an app with UI which will work on Android or iOS just as it works on desktop.

It's all still in early stages but it looks promising. I like that people working on very different stuff can come together and produce something like that.

@Elias, GluonVM is not a thing at all now. You are victim of some kind of old marketing here. Article/doc you linked is 3 years old and mentions still even ODLEST approach using javafxports and jfxmobile plugin (peek there again and see that some links are dead and github repo of jfxmobile is 3 years old). On my way to understand current state of Gluon Mobile, I found this very old article (2014) which nicely described OLDEST approach, where javafx was used on top of DalvikVM on android devices and using RoboVM on iOS. But then came Apple and prohibited use of JIT compilation and any kind of external VMs on his devices. So that way was gone. Then came Oracle with GraalVM which is JDK more in java itself and part of such GraalVM is minimal VM for natively compiled java code, they call it SubstrateVM (Oracle). Although GraalVM compiles code into pure native processor code, in some cases when apps use reflection, there must be way to reflect on metadata at least on some classes. This must be explicitly provided to GraalVM compilation phase. And there are tools for scanning such access in your code, although it may require also manual tweaks in case your app is too dynamic (some kind of dependency injection and such magic), not a problem in most simper mobile apps though. This all is hard to do manually. And then came Gluon with his name Gluon VM term (as of your linked doc from 2018), probably, starting using GraalVM to build native images. And gluon ALSO used term SUBSTRATE in his products. Its Gluon-Substrate on github. This is NEW, CURRENT approach. Understand Gluon Substrate as "advanced-build-engine" using GraalVM, rather than any kind of new "VM". As there is not in fact any VM in GluonMobile native apps (apart from the GraalVM SubstrateVM left here because of reflection) - are you still following? Yes, its unfortunate mess in terms mostly :-). But thats OK, it simply just works now. Gluon Substrate build-engine hides everything magic inside new gluon "client-maven-plugin" (primary) and "client-gradle-plugin" (community). This provides goal "mvn client:build" which uses Gluon Substrate to assemble everything together for mobile and even embedded on Raspberry Pi. Uses ARM-based openJDK, ARM-based openJFX and allows you to run even almost pure JavaFX app on android/ios DEVICES, but this result will have NO access to such OS PLATFORM. For this, there is Gluon-Attach which defines abstract APIs and implements them on specific platform to provide access to things which ARE NOT part of JavaFX and tries to do it uniform way. When you develop app, you make it as DESKTOP and can run it even without native image built. In fact, its recommended, because you have all tools. Only if final app works as expected, you can do "mvn client:build" and other steps to pass it to your device or emulator to test there. You have also Glisten UI enhancements which provide some unified "Material Design" based UI on both android and iOS. Its not platform native though. Its not for ALL kinds of applications, but from my point of view, its enough for me to do something which can be distributed to Apple and Google stores. Yes, there are still quirks, most depends on Attach implementations. Consider this as kind of HAL/PAL - hardware or platform abstraction layer, but do it carefully. Its not so well defined here and some hardware access has no desktop implementations in Attach yet. Some makes no sense on desktop, ya. But I can imagine for development at least SIMULATED desktop implementations, with some kind of companion development app helping to test EVERYTHING on desktop before final deployment on the devices. Attach is quite flat set of abstractions for platforms, just some things are still missing. Anybody with AndroidSDK+NDK and iOS expertice can try to extend there what is missing for HIS app.

OLD (2014) article, well written but for OLD approach (STRONG WARNINGS!): https://www.infoq.com/articles/Building-JavaFX-Android-Apps/

NEW video, describing even OLD approach (46:42) and NEW Substrate-build-engine (50:52) https://drive.google.com/file/d/1Td9rZLh-1sY-GylBcPIrpM9028GJ43T7/view

For the "substrate" term, compare this about GraalVM JDK and Gluon-Substrate github: https://en.wikipedia.org/wiki/GraalVM https://github.com/gluonhq/substrate

I also read too much while starting investigating Gluon ... there is old approach (javafxports, robovm, android glued) and new (grallvm substrate) sometimes mixed and unfortunately some internal naming in Gluon Substrate also notes "VM" etc... but OK. After cofusing phase, I returned to the drawing board with http://openjfx.io and START HERE with pure JavaFX first (mvn javafx:run, mvn:javafx:jlink), begin to end, literally. Learn maven (easier, required) and gradle (at least reading build scripts) basics. Note that using old Gluon approach there was possibility to integrate with android environment naturally, but now its all over Attach services only. Native Gluon app lives out of android environment in fact. Its not interpreted by DalvikJava its PURE native and you need Gluon.Attach layer which interfaces with android and ios runtimes and sometimes provides also desktop implementations (not mandatory, not tested, not enforced, not simulated, yet ... browse through attach services sources to understand whats there now). After you will be able to jlink javafx apps according to openjfx.io, then go to gluon-samples on github and try them too, now you can do mvn client:build (IF and only if you will have VS2019 Community well installed and run client:build from his x64 Native Tools CMD-line, if you are on windows - its all described in gluon docs - but forget to scan internet too much, stick with current info)