substrate
substrate copied to clipboard
gluonhq
Request for Gluon/Graal release
There was no gluon graalvm release for a year and a half. The last edition is very old. Have you abandoned this project already? If so, is there an alternative? I want to build for Android (a spring boot project), but it is only possible with newer graal.
I second this. GraalVM has moved on and there's loads of improvements, so it'd be great to:
- Get a new release! :)
- Get some clarity on the future
- Get information on why a custom VM is needed to begin with, and some information on where we don't need it (some people seem just fine without) -- if it's just needed for mobile, let's say that! And say why.
- Interact / discuss (not just with large paying corporations, but also with the next generation of developers who will become your next paycheck if they adopt your tech - think ahead!)
I really think the whole JavaFX ecosystem is suffering overall, because of a lack of a place to discuss these things (i.e., the OP's question shouldn't have to be an "issue" on GitHub), and a lack of clarity/communication. It's a lose/lose situation waiting to happen, and tonnes of new engineers are rejecting JavaFX because it has become a quagmire of seemingly-dead hard-to-navigate projects. I don't want to see that happen...
As I've said before, it's not really an "active open source project" just because source code is on GitHub. Ya gotta talk to people and release.
No answers yet, so that is not promising. I hope to see Java 21 support and some Native Image improvements (Parallel GC) in the next version for mobile.
I know it is a lot of work, so I understand if it is only done for LTS releases, but maybe this year in June again?
Unfortunatly, there is not active support/response from devs here!
I was also expacting there should be graalvm release form gluon too, as befor! Why there is no offical support / response from gluon, is they are bizy much!
For our project, we use gluonfx maven plugin as documented by gluon and simply replaced the env var to the GRAALVM distribution to point to the latest graalvm community edition version (https://github.com/graalvm/graalvm-ce-builds/releases) and it works like a charm. The gluonfx maven plugin takes correctly the graalvm ce edition, builds the application without problem and it works at runtime without differences compared to the gluonhq substrate one. For information, our application is only built on windows desktop and is based on Java 21 and the latest version of javafx. Perharps other could try the same test for their app and that gluon substrate's fork is not useful anymore ?
Yes, there's many problems that can occur by simply updating. If you don't experience that in your application, you're just lucky that you're not using something problematic / unsupported.
The mobile part does only work with the old Gluon build from June 2022 (so iOS and Android). For the Desktop there is no issue to move to a newer version such as 21.0.2., but for Desktop I don't need Gluon.
There are unfortunately issues on Desktop also, it depends what your application is doing as to whether or not you encounter issues.
OK, thanks for your feedback. Is there a way to know the possible issues on Desktop : a document or some tickets you would know of ?
@xberkhout
The mobile part does only work with the old Gluon build from June 2022 (so iOS and Android). For the Desktop there is no issue to move to a newer version such as 21.0.2., but for Desktop I don't need Gluon.
Hi. Please clarify what you mean that you don't need Gloun for Desktop. Thanks. Hugo
I can build a JavaFX Desktop application without Gluon, but I cannot build a mobile application without.
@jperedadnr @johanvos: are there any plans to release a new Gluon GraalVM and substrate? It would be good for planning purposes to know if this project is dead or not (I obviously hope it isn't…)
The project is absolutely not dead, and I would love to see more frequent and up-to-date releases as well. The difficulty we face is that changes in upstream GraalVM have a major impact on Substrate. There is lots of manual work involved between the release of a new GraalVM version and a release of Substrate. Most of this work is completely irrelevant to the mobile port, so it is a waste of time. Therefore, I am personally in favor of improving the foundations for Substrate. When something changes in either OpenJDK, OpenJFX or GraalVM, I want this to almost automatically get integrated in Substrate. That is lots of work, and it starts with OpenJDK Mobile, where we're currently spending lots of time on. The AOT compiler is the next step.
While this is non-trivial work (sponsoring welcome!!) it takes some time. It has been my hope that the current version of Gluon Substrate, which has a pretty hard dependency on specific versions for GraalVM, JavaFX and the JDK, would be good enough to bridge the gap towards the new system.
But if this is not the case, we should consider doing a new release (at the cost of delaying the new foundation). It's a though choice, and I highly appreciate all input.
I am very glad to hear this the project is still alive. Sponsoring is no problem, I already did something this morning ;-)
But I think after almost two years with no update (June 2022), it might be good to have an update soon at the cost of delaying a new foundation. But this of course depends on how much time is involved for a release and how much time the new foundation will cost to be ready. If you have to delay the foundation with one month, and that new foundation would anyway not be ready before the end of 2024, then it would be very welcome and release the pressure on the new foundation a bit.
But if the new foundation would be ready for the end of the year and a release would delay that with at least two months, it is possibly not worth a release now.
Thanks for the reply @johanvos (on a Saturday!). Glad to hear it's still on the radar.
Just to add some weight to this ask. I am (trying) to develop a relatively simple Windows / Linux / Macos desktop application, and along the way I have encountered quite a few GraalVM bugs that have mostly already been, or will be, fixed in later versions of GraalVM.
It's always quite a worry and extra workload to make some simple improvements, then to have to troubleshoot cryptic native image problems at the end.
Just yesterday, I encountered this issue (fixed in later GraalVM builds), and adopted workarounds/hacks, because of these bugs:
https://github.com/oracle/graal/pull/4279 https://github.com/spring-projects/spring-kafka/issues/2545
This one I just reported a few days ago:
https://github.com/oracle/graal/issues/9261
...is related to exporting/importing Java prefs (XML) using the Java Preferences API -- basic Java APIs adopted by a lot of Java apps including, I imagine, mobile apps -- and it does look like a real bug in GraalVM that has been there since preferences were supported -- so I guess it will be fixed very soon. In my example, the only viable solution here to make progress, is to completely disable/hide all of this functionality on MacOS (the problem resides on MacOs only), etc... in reality, there'll be a GraalVM fix very soon that I cannot use.
There's been a handful of other examples I've already forgotten about.
I think my point is that GraalVM was/is very volatile, still improving all the time, and once developers graduate above HelloWorld examples, the Gluon version quickly shows it age with blocking issues that are largely solved with later versions of GraalVM.
+1 to a new Gluon GraalVM build :) ...
As Gluonfx-Maven-Plugin, Gluonfx-Gradle-Plugin, Substrate is tottaly dependent upon GrallVM for it's final building/packinge process. So I think, user can use latest GrallVM version (e.g. which can have imporvements, bugs/issues fixed, new features etc).
It's only possible when Gluon practically focus on new GrallVM (Gluon) releases, so new features/bug fixes can be re-used without finding any hackes or tricks for such a problem!
So gluon and Graalvm must be runs on parrallel side!
It's been more than 2 years since the last release. Can we expect a release of GRAAL that is based on JDK 21 or even JDK 22? In that way, we can catch up with the upcoming JavaFX 23. Thank you for your hard work!
I am having some issues with latest GraalVM release e.g. https://github.com/gluonhq/graal/releases/tag/gluon-23+25.1-dev-240905-2007
https://github.com/gluonhq/substrate/issues/1276 https://github.com/gluonhq/hello-gluon-ci/issues/37
It's much appreciated New GrallVM is released, but still it have some issues!
https://github.com/gluonhq/substrate/issues/1277
Yeah, this ticket should be re-opened until substrate works for desktop builds. We should not pretend...
- Interact / discuss (not just with large paying corporations
Can you elaborate on those "large paying corporations"? (I have no idea who/what you refer to)
- Interact / discuss (not just with large paying corporations
Can you elaborate on those "large paying corporations"? (I have no idea who/what you refer to)
E.g., companies/customers who pay for and interact/discuss with Gluon on support, roadmaps, new features, fixes, or request additional capabilities (that may get delivered). There may not be as many as Gluon would like, but they do/did/will exist, hopefully, and they do get to talk to Gluon in ways we don't. I hope that's a fair assumption. E.g., there's no way the only conversations happening are those that are visible here on GH.
Please don't shoot the messenger here or take offense...there's a good few thumbs up on some of my/other people's comments like this because there's a good amount of agreement.
It's much appreciated New GrallVM is released, but still it have some issues!
#1277
I have closed this issue! As that was just a mistake not issue with latest Gluon Graal Release
However, Windows Support is not fully implemented yet, still in progress!