Yeah, it is not going to compile everything. For most Java apps, which were built in a world where startup time was a known disadvantage of the JVM, they will probably be better off with a JITed VM anyway. This is more of a new capability, allowing JVM languages the ability to move into usecases where they have never shined before. Like CLI apps, for example. I would expect most usage of AOT compilation will be for new software, not existing software.

That being said, generics and factory patterns aren't a problem for graal at all. Reflection and dynamic class loading are the biggest offenders.

How about GUI? Does JavaFX rely on dynamic classloading? (I presume so, given its XML-driven approach.) If so, would it be possible to refactor it away? Or perhaps introduce a preprocessing phase of some sort?

Gluon put out substrate which is supposed to do this:

https://github.com/gluonhq/substrate

Great that this is in the works.

Do you know about its workings?

I do not, other than it's based on GraalVM native image. I just know of its existence. I believe this is how gluon is pushing crossplatform for iOS since apple doesn't like the JVM JIT.

Reflection, factory patterns, type parameters/generics are are all handled by Graal. You just need to make the appropriate config file for your app.

> type parameters/generics

Those are purely compile-time constructs.

At least you'd still have AspectJ, because it can instrument bytecode before the AOT compiler sees it. Replacing Spring with Dagger would let you codegen your DI, but in 2020 you need a really good reason to blow that much eng work to improve your startup time.

One of the things that those sticking to Java 8 are missing out are the JIT caches that are now part of all major implementations, as those features were integrated into the FOSS variants from the commercial products.

Which is why most commercial AOT compilers for Java have been mostly focused on embedded deployments first, and as code caches or fast startup path on enterprise scenarios.