Spring Framework Web Reactive can serve static resources with support for zero-copy file transfers.
This feature can lead to interesting performance gains and is already leveraged by many runtimes.
Because zero-copy only supports Files on the file system (i.e. not reading those from a zip file), we cannot right now leverage that support for static resources contained in webjars or if the app is packaged as an executable JAR.
We could overcome this by: * in production, prepend the list of resource locations with a temporary location * lazily extract resources as they're requested so that next time they'll be served from that file system location
We could probably make Spring Framework support part of the feature, with specific ResourceResolvers/ResourceTransformers and just let Boot auto-configure them.
Comment From: bclozel
Extracting resources at startup would definitely make the startup experience slow, so we won't choose this solution.
Possible solution, update the Framework ResourceResolver/ResourceTransformer chain to:
* prepend the list of locations with a temporary folder, created at runtime
* listen to requested resources and lazily decompress those resources in that location
* clear the CachingResourceResolver accordingly once the resource is extracted
This would need to heavily use the unpacking code written in Boot to guarantee a unique location for each application instance/run.
Other possible solution, change the packaging format to only store (and not compress) resources in the JAR. Then it may be possible to provide the jar file descriptor and a specific offset.
Comment From: bclozel
This has been supserded by the "efficient deployments" section in the reference documentation. Exploding the JAR before running it is the best approach to this performance problem.