Comment by hocuspocus
3 hours ago
Native images shouldn't be too messy anymore, Oracle put a lot of effort into DX improvements and all major web frameworks are now aware it's an important and growing use case.
Struggling to build native images should be a sign you're reliant on libraries that are dangerously outdated and abandoned.
They can definitely be pretty messy in some ways; even the standard library doesn't work out of the box perfectly. I have certainly struggled to get image manipulation with java.awt (e.g. thumbnail generation for a fairly standard web use case) to work in a native image.
So it is an antipattern nowadays to manipulate the classpath after building? Iirc native image require static classpath, but it is quite common to inject e.g. environment specific data via the classpath. Should one just read from the filesystem instead, or what’s the strat there?
With the AOT cache, you can actually modify the classpath (or module path as is now used for modern applications) after it has started up. The names and classes for the APIs are different, but you can still load jars at runtime even with the AOT cache enabled and functional.
The AOT cache compatibility issues come when your boot module path differs between training and actual run. As long as that is not the case, you can use it without problem and load additional modules at runtime after it has started up.
With GraalVM, that is not possible. It still has the closed-world assumption.