Graal native Image does that (though the compile time is quite long, but you can just run it on the JVM for development with hot reload and whatnot, and only do a native compile at release)

▲

clumsysmurf 3 days ago | parent [-]

From what I have heard, Graal is still quite a headache if you are using libraries that are not compatible, but maybe this is out of date.

▲

cogman10 3 days ago | parent [-]

Still an issue. The main problem is for native compilation you have to declare your reflection targets upfront. That can be a headache if your framework doesn't support it.

You can get a large portion of what graal native offers by using AppCDS and compressed object headers.

Here's the latest JEP for all that.

https://openjdk.org/jeps/483

	▲	gf000 3 days ago \| parent [-]
		Only those reflection targets that are not "visible" from straight forward code. If you have code that accesses the "stringLiteral" field of a class, then it will be auto-registered for you. But if you access it based on user input, then you have to register it manually. Also, quite a few libraries have metadata now denoting these extra reflection targets. But nonetheless you are right in general, but depends on your use case.