[Enhancement] Native image via GraalVM

[lanthale]

Description

To improve the startup time allot the usage of graalvm with the AOT compiliation could be take muCommander on parallel with all the other filemanagers out there.
The only problem which could arise is that the JNI calls are not compatible with GraalVM native image. But I think it could be possible.

[ahadas]

@lanthale did you try v1.4.0? it starts significantly faster thanks to the contributions by @pskowronek and @Andreas0602. I really don't know if it makes sense to spend time on changing the JRE just to increase the startup time a bit more...

[lanthale]

The last improvements are very good I agree, so I see it as an optimization of the startup time.

I made some tests with javafx applications and quarkus applications. Both are starting with the native image GraalVM about 50% faster.

That means mucmd would be than instantly starting.
I tried to do a first shot but I could not compile mucmd. Than I tried the portable version to instrument with graalvm but I can only see the logo and many exceptions.
How can I start mucmd by cmd ? What do I have to specify as options ? (Cannot use the startup script)

[aadrian]

... just to increase the startup time a bit more...

@ahadas GraalVM has significantly faster startup time and less memory usage than the alternatives.
This is simply due to "physics" - allot of stuff is simply not performed or loaded by the native image as opposed to any JRE+"Main JAR"+"Lib JARs".

I really don't know if it makes sense to spend time on changing the JRE

There's no change of the JRE: everything remains the same, just using GraalVM (+configs) at build time, also extra native images of muCommander can be produced that are faster and require less memory.

(GitHub Actions can produce these, as they already do for many other open source projects)

[pskowronek]

... just to increase the startup time a bit more...

@ahadas GraalVM has significantly faster startup time and less memory usage than the alternatives. This is simply due to "physics" - allot of stuff is simply not performed or loaded by the native image as opposed to any JRE+"Main JAR"+"Lib JARs".

yup, I mean, we know what GraalVM is. Personally, not being against - but, is it worth to invest time on it?

I really don't know if it makes sense to spend time on changing the JRE

There's no change of the JRE: everything remains the same, just using GraalVM (+configs) at build time, also extra native images of muCommander can be produced that are faster and require less memory.

But still, there's that problem with native libs (JNI), right?
And not to mention OSGi - any experience with OSGi projects on GraalVM?

The load time as we observe right know consists of the following (at least on macOS):

• Java init Swing frames, that requires:
• loading fonts (I mean, Java Swing needs to gather info about installed system fonts, it is painfully slow on macOS at least) *)
• loading OSGi bundles (which I tried to make it in parallel - not so much with Felix sprit, but I did that anyway)
• starting base muC bundles and:
• starting all the file and protocol handlers for muC etc **)

*) The recent changes I've done were to init it in the background while OSGi bundles load/start
**) in OSGi way of doing things, those handlers ("plugins") should ideally init independently in the background while muC is already opened (akin to how IntelliJ Idea or Eclipse does).

So, for GraalVM we would need to check if:

• Swing UI init is much faster
• OSGi (Felix) works OK...
• loading fonts' metrics could be substantially faster