[Discussion / Suggestion] Would or could GraalVM + native-image be considered as a useful distribution option for glimmer-related applications? about glimmer HOT 4 CLOSED

I forgot one use case rationale. This can be explained by e. g. people writing in the glimmer DSL,
and everything works fine on, say, linux - but now they want to get this to work on windows and
OSX too, so having java available (or just the native-image produced file) would be a useful
additional option, if I understood things correctly so far. I don't know how difficult it is to get e. g.
glimmer-dsl-swt to work - I have not yet tested it, but it's now on my todo list. Then I can test the
custom shapes too. :D

(This, by the way, reminds me of gtk + cairo too. At the least we can draw that way. I found the
API of cairo a bit cumbersome, so perhaps the perfect-shape gem simplifies that.)

from glimmer.

"Perhaps this is too much work right now considering that GraalVM is changing a lot"

You hit the nail on the head with that statement. I don't trust GraalVM at this time. Also, the standard Java Virtual Machine already supports polyglot software engineering with many languages, like Kotlin and JRuby. In the future, perhaps JRuby itself will offer AOT (Ahead-Of Time) executable compilation since it has been mentioned several times in presentations given by its creators, but until that time, Glimmer DSL for SWT already supports building native installers for Windows (MSI & EXE), Mac (DMG, PKG, and APP), and Linux (RPM & DEB) via the JVM-included jpackage, automated by the glimmer package command. (You can learn more here: https://github.com/AndyObtiva/glimmer-dsl-swt/blob/master/docs/reference/GLIMMER_PACKAGING_AND_DISTRIBUTION.md)

Of course, JRuby startup time is a bit slow (even with the native executable packaging as EXE on Windows and APP on Mac), so Glimmer DSL for SWT's forte is actually building highly sophisticated business applications that get started by company clerks once at the beginning of the day, and are kept on all day long. App startup time does not matter much in that case, but application development productivity matters a lot to businesses, and thus Glimmer DSL for SWT's highly thorough and sophisticated features come in very handy in that case.

For applications that should start quickly, Glimmer DSL for LibUI is the most promising option at this point. Of course, as you mentioned, it has no automated methods for producing app executables on Mac and Linux yet though OCRA could be used on Windows as you already mentioned.

Regarding the perfect-shape gem, one thing to clarify is that it is a Math Geometric Algorithm library, not a GUI shape drawing toolkit. In other words, it is used in order to make calculations such as "is the mouse click point inside a shape or composite shape?", "does this shape intersect the screen viewport rectangle?", etc... So, Perfect Shape is an auxiliary library that helps with adding advanced features to GUI toolkits, such as effortless declarative Drag & Drop. I already do that in Glimmer DSL for SWT because Java already implements these algorithms. Ruby on the other hand does not have an equivalent or a complete geometry library that covers all GUI cases with a uniform API, so this is where Perfect Shape helps. That way, I could use it to augment Glimmer DSL for LibUI with the same advanced Drag & Drop features that Glimmer DSL for SWT has. I am not there yet as I still need to finish all planned features for version 1.0 of Perfect Shape before I get to that point. But, that is my plan behind it. It is to add advanced Drag & Drop to Glimmer DSL for LibUI.

Otherwise, both Glimmer DSL for SWT and Glimmer DSL for LibUI already have complete shape drawing facilities. Glimmer DSL for SWT does so via the Canvas Shape DSL, and Glimmer DSL for LibUI does so via the Area API.

Anyways, until I think that GraalVM is a reliable option, I am dismissing for the time being (closing this issue). I would much rather JRuby supported AOT compilation itself since it is already a very reliable language runtime used by thousands of businesses (not just an experiment).

from glimmer.

I changed my mind about GraalVM Native Image. I would like to give it a try in case it offers anything of use to Glimmer DSL for SWT (even if it already supports native executable packaging).

I am reopening this issue until I have expanded some effort into trying GraalVM Native Image out.

Thank you for reporting.

from glimmer.

According to the research I just did, TruffleRuby is not compatible with JRuby. Worse yet, its Graal Native Image does not really do AOT (ahead-of-time) compilation to the Ruby code itself, yet only to the Graal+Truffle implementation code:
https://github.com/oracle/truffleruby/blob/67ee8b015d729749591ceff8b77037eb606bf3df/doc/contributor/native-image.md

As such, my initial gut feeling was right for avoiding TruffleRuby, and I do not see value in supporting it for the time being, especially given that Glimmer DSL for SWT already supports native executable packaging on Mac, Windows, and Linux.

from glimmer.