gluonhq
Download from link failed with status: 404, in version 1.0.24
Hi, I got this error on my Windows, when upgrade to version 1.0.24:
java.lang.RuntimeException: Error downloading zips: java.io.IOException: Error downloading link from https://github.com/gluonhq/vmone/releases/download/gvm-24-2/vmone-windows-x64.zip. Unexpected status code: 404
at com.gluonhq.substrate.util.FileDeps.setupDependencies(FileDeps.java:334)
at com.gluonhq.substrate.util.FileDeps.resolvePath(FileDeps.java:174)
at com.gluonhq.substrate.util.FileDeps.getJavaFXSDKLibsPath(FileDeps.java:106)
at com.gluonhq.substrate.target.AbstractTargetConfiguration.processClassPath(AbstractTargetConfiguration.java:788)
at com.gluonhq.substrate.target.AbstractTargetConfiguration.validateCompileRequirements(AbstractTargetConfiguration.java:392)
Unfortunatly! Windows is not supported yet by Gluon plugins e.g. 1.0.24 and above! https://github.com/gluonhq/substrate/issues/1284
I think, unfortunalty vmone repo is removed from official gluonhq org and moved to another place, maybe this is the porblem causing the above issue!
Expacted location it should be:
https://github.com/gluonhq/vmone (but it's no longer availabe now)
Now it's can be accessed at:
https://github.com/abhinayagarwal/vmone
@johanvos @jperedadnr @abhinayagarwal What is the reasons behind moving of vmone, I think, old users will base issue!
@ctoabidmaqbool Yeah, I also saw the shift. I pinged @jperedadnr in another issue of gluonfx-maven-plugin repo but he didn't seem to respond.
TLDR: you have to use 1.0.23 (@jperedadnr can you confirm?)
Background: Last week, I archived the vmone repo. I got more complaints than constructive contributions, so I consider it a failed experiment.
It was never intended to be something that was used in public, as it was mainly experimental work. The background: the stack that this plugin uses, requires a combination of a specific fork of a GraalVM version, a specific build of a fork of OpenJDK and some patched logic for dealing with mismatches. Most of this work is due to the fact that the VM code is spread over different places:
- OpenJDK has the root of the VM code (hotspot)
- GraalVM has some VM functionality in Java files
- GraalVM has some VM functionality in C files
- GraalVM does not support the VM compiled for iOS
- OpenJDK class libs need to link with the correct VM code, but that comes from different places (see above)
- OpenJFX native class libs depend on the JDK class libs and on the VM ones.
It's extremely difficult to get all those separate parts to work together. Imho, the better solution is to have a single repository where JavaFX on mobile is considered a first class citizen. This is what I hope to achieve in OpenJDK/Mobile. All other efforts are by definition running behind, and take huge efforts to be maintained.
(thanks for your understanding)
@johanvos The 1.0.23 version has another major failure in finding libjvm.a file. I found this error even after using the latest Gluon's GraalVM. @ctoabidmaqbool figured out that the plugin was finding the file at the wrong location (see his comment just below mine).
Here's the source issue and my comment:
- https://github.com/gluonhq/gluon-samples/issues/119#issuecomment-2676078689
Notice that GluonFX 1.0.23 requires GraalVM 17 from https://github.com/gluonhq/graal/releases/tag/gluon-22.1.0.1-Final, as long as JDK 17 and JavaFX 21-ea.
TLDR: you have to use 1.0.23 (@jperedadnr can you confirm?)
Background: Last week, I archived the vmone repo. I got more complaints than constructive contributions, so I consider it a failed experiment.
It was never intended to be something that was used in public, as it was mainly experimental work. The background: the stack that this plugin uses, requires a combination of a specific fork of a GraalVM version, a specific build of a fork of OpenJDK and some patched logic for dealing with mismatches. Most of this work is due to the fact that the VM code is spread over different places:
- OpenJDK has the root of the VM code (hotspot)
- GraalVM has some VM functionality in Java files
- GraalVM has some VM functionality in C files
- GraalVM does not support the VM compiled for iOS
- OpenJDK class libs need to link with the correct VM code, but that comes from different places (see above)
- OpenJFX native class libs depend on the JDK class libs and on the VM ones.
It's extremely difficult to get all those separate parts to work together. Imho, the better solution is to have a single repository where JavaFX on mobile is considered a first class citizen. This is what I hope to achieve in OpenJDK/Mobile. All other efforts are by definition running behind, and take huge efforts to be maintained.
(thanks for your understanding)
@johanvos Moreover I think, Gluonhq must support all major platforms like it was for 1.0.23 e.g. Windows, Linux, macOS, Android, IOS, recent plugins e.g. 1.0.24 and 1.0.25 was lacking support for Windows(x64) and Linux (AArch64).
https://github.com/gluonhq/gluonfx-maven-plugin/issues/518#issuecomment-2677804403
I think there should be easy way to make native-image for all major platform by liverging Graalvm native-image.
As now it exposed that 1.0.24 and 1.0.25 are for expiremetal pupose not for production ready, so how much it expacted to use Graalvm (java 23+) production ready> ,
Hi @ctoabidmaqbool I believe you misunderstand the idea of free and open source software. There should be no "Gluon must" in such a project. Substrate and this plugin are open source. Everyone is free to contribute. Gluon contributed the major part of the code, but everyone is invited to contribute. Some non-Gluon people contributed as well: they see bugs, or want to add functionality, so they create an issue, create a PR, discuss it, and merge it. That is very rewarding, and that is how an OS project should be. Projects like these can show how a community (the JavaFX on Mobile community) can work together to achieve great things. But it demands collaboration.
If you keep insisting that it is easy to use GraalVM native-image to build cross-platform JavaFX applications, then please go ahead and do so. Me and others would really be happy to see that working. (I made it clear that I have more faith in OpenJDK/Mobile as a basis, and that is the path I am following now.)
@johanvos
Thank you for your response and for sharing your perspective on open-source collaboration. I fully respect and appreciate the immense contributions that Gluon and other community members have made to JavaFX on Mobile. My intention was never to impose demands but rather to highlight the importance of cross-platform support, as many developers rely on these tools for production use.
I completely agree that open-source thrives on contributions, and I acknowledge the complexity involved in maintaining compatibility across multiple platforms. My main concern was the recent changes in GluonFX 1.0.24+ and VMOne, which have impacted users relying on Windows x64 and Linux AArch64. Understanding that these versions were more experimental helps clarify the situation, and I appreciate the transparency around that.
Regarding GraalVM native-image, I understand the technical challenges involved, and my comment was more about exploring possibilities rather than assuming an easy implementation. If there are specific areas where contributions would be most beneficial, I would love to understand how I or others in the community can help to improve support for these platforms.
Again, I appreciate the hard work that has gone into this project and look forward to contributing and collaborating in any way that helps move things forward.
Best regards, @ctoabidmaqbool
apache-maven-3.8.8-bin
graalvm-svm-java17-linux-gluon-22.1.0.1-Final
openjdk 17.0.3
GraalVM 22.1.0.1
v1.0.23
As GluonFX plugin 1.0.23 are dependent upon substrate 0.0.63. And latest substrate version just now is 0.0.66-SNAPSHOT.
Is there anywhy we can get features / development of substrate from 0.0.64-0.0.66, which are not effected by vmone e.g.
- https://github.com/gluonhq/substrate/commit/0004727dff45bcf10201593cf6690fccfe487706
@jperedadnr @johanvos
Is there any plan to continue from 1.0.23 again!
The reason I started vmone was to work around new incompatibilities/changes in GraalVM. As long as those are not solved (and my attempt to solve it failed), we can't do any builds at all. It is the reason we are moving away from GraalVM and are trying to become downstream of openjdk/mobile only.
@johanvos What do you think, how far away are we from being able to create a dylib for iOS (device and simulators) of some java code based on openjdk/mobile in interpreter only mode, if that is a design goal at all? How would the C interop to call into this library be handled?
@johanvos
By moving away from GraalVM and adopting openjdk/mobile only, it reminds me of the early days of JavaFX Mobile, including projects like javafxports and javafxmobile-plugin.
As a long-time Java and JavaFX user for nearly 8–9 years, I have worked with JavaFX 2.0, JDK 1.8 and earlier, and was an early adopter of JavaFX Mobile and JavaFXPorts. Given my background with these technologies, I wanted to ask:
- Is openjdk/mobile conceptually similar to what javafxmobile-plugin aimed to achieve, or is it an entirely different approach?
- What were the key limitations or reasons behind moving away from JavaFXPorts/javafxmobile-plugin, and how does openjdk/mobile address those challenges?
I understand that a lot has changed since JDK 1.8, especially with the modularization of Java (JPMS), the open-sourcing of JavaFX, and shifts in iOS/Android development (e.g., RoboVM, GraalVM changes, and evolving platform constraints). Would love to hear your thoughts on how these factors influenced this transition and what the long-term vision looks like for JavaFX on mobile.
Looking forward to your insights!
Also note that, I am main user of Windows and Android OS and sometimes Linux too.
apache-maven-3.8.8-bingraalvm-svm-java17-linux-gluon-22.1.0.1-Finalopenjdk 17.0.3GraalVM 22.1.0.1v1.0.23
@ctoabidmaqbool Can I use JDK 21 with the rest of the other configurations? I think it would fail due to GraalVM-Gluon-build as it was made to work with JDK 17 or lower, right?
apache-maven-3.8.8-bingraalvm-svm-java17-linux-gluon-22.1.0.1-Finalopenjdk 17.0.3GraalVM 22.1.0.1v1.0.23@ctoabidmaqbool Can I use JDK 21 with the rest of the other configurations? I think it would fail due to GraalVM-Gluon-build as it was made to work with JDK 17 or lower, right?
@SaptarshiSarkar12 — You can check all GraalVM releases provided by Gluon here: 👉 https://github.com/gluonhq/graal/releases?page=1
As you correctly assumed, GluonFX plugins (both Maven and Gradle) along with Substrate work best with the custom GraalVM builds provided by Gluon, since they include additional patches and changes specifically for JavaFX and native-image builds on mobile/desktop targets.
Looking at the release history, after GraalVM CE Gluon 22.1.0.1-Final (which supports OpenJDK 17), the next available release from Gluon is GraalVM CE Gluon 23+25.1-dev-2409082136, which supports OpenJDK 23.
This means there’s no official GraalVM release from Gluon that supports JDK 21 — the supported versions jump directly from JDK 17 to JDK 23.
To summarize:
- GluonFX v1.0.23 = Requires graalvm-svm-java17-gluon-22.1.0.1-Final (based on JDK 17).
- GluonFX v1.0.24+ = Requires graalvm-java23-linux-amd64-gluon-23+25.1-dev (based on JDK 23).
So, unfortunately, JDK 21 is not an option for now when using GluonFX.
@ctoabidmaqbool Thanks for the detailed comment 😀. Yeah, I also saw just now and I'm stuck as I can neither downgrade to JDK 17 (because my OSS project uses JDK 21 features) not can I upgrade to JDK 23 which leads to missing VMOne. Let's wait until the team and contributors come up with success.
@ctoabidmaqbool Thanks for the detailed comment 😀. Yeah, I also saw just now and I'm stuck as I can neither downgrade to JDK 17 (because my OSS project uses JDK 21 features) not can I upgrade to JDK 23 which leads to missing VMOne. Let's wait until the team and contributors come up with success.
Thanks for your kind words, @SaptarshiSarkar12 ! 😀
If you still want to work with GluonFX v1.0.24+, JDK 23, and VMOne — just like I am — it is possible to set up and build everything locally with some manual adjustments.
The key is to be a bit hands-on and comfortable tweaking things in your local environment, especially if you want to explore or experiment with advanced configurations.
For reference, I’ve created and maintain some personal forks of the related repositories to help with this process:
These forks allow me to patch, update, and experiment with configurations that are not officially supported. It’s a bit of work, but if you’re comfortable with building the full stack from source and keeping up with upstream changes, it can be done.
That said, it’s not the easiest route — but definitely possible for power users who want to keep pushing forward.
Let me know if you’d like any pointers or guidance on setting up your own environment like this! 🚀
@ctoabidmaqbool I don't see any comeback from the Gluon Team in the near future. So, if there are no security restrictions, I can set up those forks and use those. Would love to know your process. Thank you for your great help 🙏!
@ctoabidmaqbool Can you provide any guidance for setting up my own environment for following your process?
@ctoabidmaqbool Can you provide any guidance for setting up my own environment for following your process?
What is your development environment? e.g. Windows, Linux or MacOS?
I am basically using Windows 10 & WSL (Ubuntu)!
Clone (git clone) or fork, official git repo e.g.
- https://github.com/gluonhq/gluonfx-maven-plugin or https://github.com/gluonhq/gluonfx-gradle-plugin
- https://github.com/gluonhq/substrate
- https://github.com/gluonhq/vmone
I use TortiseSVN or TortiseGit to manage SVN and Git repos! For Development I use IntelliJ idea, VSCode, Notepad++ and Visual Studio
./gradlew publishToMavenLocal (substrate)
mvn install:install (gluonfx-maven-plugin)
./gradlew publishToMavenLocal (gluonfx-gradle-plugin)
make clean all (vmone)
You can use eclipse temurin jdk
You can learn a lot from AI Chatting Platfrom e.g. ChatGPT
But before digging into development steps, I want to know that vmone comes back e.g. https://github.com/gluonhq/vmone/releases/tag/gvm-24-2.1
So I think, you can use gluonfx plugins GluonFX v1.0.24 or v1.0.25 but as mentioned befor, these are not 100% ready at development side!
@ctoabidmaqbool Thank you for the detailed process. I will definitely try that if something goes wrong while testing VMOne.
So I think, you can use gluonfx plugins GluonFX v1.0.24 or v1.0.25 but as mentioned befor, these are not 100% ready at development side!
Yes, I have tried that just now. All builds except windows succeed. I tried testing the generated executable for Ubuntu and it works flawlessly! For windows, build with v1.0.23 works and I haven't tested if executables for macOS work as I don't have a mac. I would request if anyone can try out the macOS build of my project, Drifty and confirm if it works. Here's the link to the workflow and the artifacts:
- The workflow run: https://github.com/SaptarshiSarkar12/Drifty/actions/runs/13483552384
- For macOS AArch64 (
macos-14-GUI-Build-Files): https://github.com/SaptarshiSarkar12/Drifty/actions/runs/13483552384/artifacts/2686376837 - For macOS Intel (
macos-13-GUI-Build-Files): https://github.com/SaptarshiSarkar12/Drifty/actions/runs/13483552384/artifacts/2686374097
@johanvos
It is the reason we are moving away from GraalVM and are trying to become downstream of openjdk/mobile only.
This is the first time I'm hearing of openjdk/mobile, so I don't know exacty what it is. But this sounds like the exact opposite of what I wanted to explore with https://github.com/gluonhq/substrate/issues/1315. Does this mean the intention is to no longer support JavaFX on dekstop using GraalVM? My specific use-case is a Windows (and experimentally Linux) desktop JavaFX application compiled through GraalVM native-image, so it sounds to me that we'll be locked to the the current JavaFX/GraalVM versions we're using?
It is the reason we are moving away from GraalVM and are trying to become downstream of openjdk/mobile only.
This is the first time I'm hearing of openjdk/mobile, so I don't know exacty what it is. But this sounds like the exact opposite of what I wanted to explore with gluonhq/substrate#1315. Does this mean the intention is to no longer support JavaFX on dekstop using GraalVM? My specific use-case is a Windows (and experimentally Linux) desktop JavaFX application compiled through GraalVM native-image, so it sounds to me that we'll be locked to the the current JavaFX/GraalVM versions we're using?
Hi @kkriske , No, you shouldn't be locked at the current versions. Unless I'm missing something, everything is open source and available. Personally, I don't see the benefits of using GraalVM for JavaFX anymore, compared with the effort it takes -- especially if you want to support mobile using the same codebase. If others still do prefer that approach, that's all great of course, and I don't think there is any hurdle preventing others (e.g. you?) to follow that path. If there is anything missing, let me know.
@johanvos We don't support mobile, only Windows desktop (and Linux experimentally) with a legacy JavaFX UI. Most of the software is actually just a CLI tool intended for computationally heavy workloads. The main requirement for GraalVM native-image is the source code protection it provides by compiling to native. Everything else is nice to have but not the root requirement. I haven't done research on the topic in a while for as far as I know native-image is the only tool that provides that functionality in that capacity.
While you're right everything is open source, and I've made some contributions myself, if Gluon no longer provides the minimal support, e.g. the reflection/JNI config files, there would be a significantly higher maintenance cost for everyone. While we can still contribute that to e.g. the official GraalVM reachability metadata repository, it's way easier to keep config up to date as a core maintainer of javafx than as a random developer that needs to reverse engineer what's going on. JavaFX is also quite reflection/JNI heavy which makes it all the more painfull if we need to rely on oss contributions for that.
To me it sounds like the biggest problem with native-image is mobile, and for desktop it should be fine to support native-image.
The reason I created https://github.com/gluonhq/substrate/issues/1315, and thus what I'm missing for better GraalVM support, is to align JavaFX with how a library should behave in native-image. And by that I mean provide features and embedded configuration files in the actual JavaFX artifacts so a build does not require the custom gluonfx-maven-plugin at all.
Our build passes over 50 additional linkerArgs options to the gluonfx plugin that are normally configured out of the box by native-image, but since JavaFX does it's own linking step, we need to put additional effort in trying to keep that in sync with the GraalVM codebase.
In the current setup, if I understand everything correctly, the native-image configuration is not published in the official artifacts, and since the plugin does static linking of native libraries, there are custom artifacts downloaded as well, since the official ones only container dynamically linked libraries. So a lot of magic going on under the hood. For desktop applications it should be fine to just use dynamic linking so the whole custom linking step is unnecessarily complex in my humble opinion.
@kkriske (and others in this thread) Thanks, that makes things a bit more clear. I'm still trying to understand a few things though. We have to think about it (and with "we" I mean you, me, and others who are interested). The reason we did a JavaFX - GraalVM integration was the need of an AOT compiler, after RoboVM went out of business. Unfortunately, Apple still does not allow to execute dynamically generated code on their devices, and in the spirit of WORA, one of the greatest things about Java, I still believe we somehow have to make sure Java runs first-class on iOS devices -- which is why we created all this stuff and "integrated" an AOT compiler.
That is a very different usecase than what you describe, but that doesn't mean your usecase is less relevant -- it's just something we didn't consider when starting this. But I'd like to learn more about that usecase (from you and others). What exactly do you mean with "source code protection"? If it is what I believe it is, there might be a few options to support this. To choose which option is best, one of the most important things to me is maintainability. Everything we do in this area is free, and free resources are of course limited. The json-list for jni/reflection configuration is a maintenance nightmare, as are many other things with the current approach -- but especially for non-mobile, we can do much better and have a more maintainable approach.
This is probably getting way too off-topic for this issue, but please contact me off-line with thoughts and ideas about this, so that we can move forward.
Unfortunately, Apple still does not allow to execute dynamically generated code on their devices
I don't know anything about the Apple ecosystem, but I don't see how dynamic code generation comes into play here.
What exactly do you mean with "source code protection"?
native-image gives us a native binary, which is hard to reverse engineer. We do not provide jars to clients as that both requires a JVM runtime on the client machine (I know there are packaging options to redistribute the JVM, but still), and jars would be easy to decompile by bad actors, or competitors looking for a creative source of inspiration.
I agree maintainability is key here, which is the reason I created https://github.com/gluonhq/substrate/issues/1315 as the requirement for a custom plugin creates maintainability overhead.
Please let me know how you prefer I contact you, we have had contact previously on the GraalVM slack fyi. My thougths on how to move forward basically boil down to https://github.com/gluonhq/substrate/issues/1315, but I have no view on the requirements for mobile and the limitations imposed by native-image on mobile.
Currently, I want to use GluonFX primarily for Windows and Android platforms, as the majority of our customers are based on these systems. Although I plan to explore Linux, macOS, and iOS support later, my current target is Windows, Android, and Web.
For Windows, I’m using Zulu JDK 17 with JavaFX 17, along with Launch4j and Inno Setup for distribution. For Android, I still rely on the older JavaFX Mobile plugin with Oracle JDK 8, and for web, I use JPro with JDK 17.
I aim to move to GluonFX with GraalVM/Substrate to boost GUI performance and protect source code, since traditional .exe (Launch4j) and .jar setups are relatively easy to reverse engineer.
So far, GluonFX 1.0.25 with GraalVM 23+ works fairly well for Android (even if experimental), but I’ve faced issues with versions like 1.0.23 or 1.0.26+, making it hard to migrate my full project.
Hence, my current focus is on using GluonFX for Windows and Android only.
@johanvos apologies for the spam tag, but I feel that without direct tag this otherwise may get lost in a sea of GitHub mails.