Thanks for reviewing and engaging.
On 7/16/20 5:31 AM, Rémy Maucherat wrote:
On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik <fha...@vmware.com
<mailto:fha...@vmware.com>> wrote:
for discussion, all feedback and questions welcome:
I've created a concept of having Apache Tomcat, embedded, run
without reflection in a native image.
This concept creates a jar, tomcat-embedded-programmatic.jar, that
can be fine tuned to only include what is needed in a default
configuration when an embedded tomcat instance is used and
configured programatically.
Steps to run Apache Tomcat using Java 8 without reflection
1. Make sure you have native-image (from the graal installation)
on your path
2. git clone -b
feature/embed-minimal-programmatic-jar-file-master
g...@github.com:fhanik/tomcat.git
3. cd tomcat/res/graal/
4. ./build-tomcat-native-image.sh && ./graal-measure.sh
Should yield an output similar to (Graal 20.1):
SUCCESS: the servlet is working
RSS memory: 20.7M
Image size: 20.5M
or using an older graal, 19.2
SUCCESS: the servlet is working
RSS memory: 18.0M
Image size: 16.7M
This also leaves a file named
${java.io.tmpdir}/XReflectionIntrospectionUtils.java so that you
can review the solution to IntrospectionUtils.java
Goals of this concept
1. Do not break anything
2. Create a new and optimized for size artifact,
tomcat-embedded-programmatic
3. Remove reflection by introspecting classes that are currently
passed into IntrospectionUtils.set/getProperty by generating
setters/getters at build time
How it's done
1. I've build out a small introspection tool in the package
org.apache.tomcat.util.xreflect
2. During build time, it analyses a set of known classes that are
used with IntrospectionUtils.java, and generates
XReflectionIntrospectionUtils.java
3. When it packages tomcat-embed-programmatic.jar it uses the
generated code when calling setProperty and getProperty
A PR would look like this:
https://github.com/apache/tomcat/compare/master...fhanik:feature/embed-minimal-programmatic-jar-file-master?expand=1
Well, this is a bit complex and hard to maintain (like, for example,
storeconfig), so that's a downside.
It is keeping track of one more artifact, tomcat-embed-programmatic.
Right now, it is manually maintaining the list of classes that it
generates setProperty/getProperty for. I derived this list by running
the test suite. There is of course an option to fully automate this.
So starting with Tomcat and its initial server.xml, the process would be:
server.xml -> equivalent Tomcat embedded code -> equivalent Tomcat
embedded code with custom IntrospectionUtils code
The concrete benefits may be limited though.
The goal of this artifact is to actually strip all non programmatic code
and bring down the code base to minimum bare essentials.
That means, it's not for applications that want to deploy a WAR file, or
do XML based configuration. My primary use case, is a Spring Boot
application where the framework servlets and filters are configured
programmatically, easy for the AOT compiler to work with, and everything
else is then handled by the framework.
There wouldn't be support by this artifact to handle EE style XML
configurations, including fragments. That is already done by
tomcat-embed-core, which is almost 50% larger generated native image
size in order to support all use cases and features.
I looked at more code generation for web.xml since the digester is
nice for that, but the benefit becomes even more questionable. It is
harder to manage, and the generated classes have to be loaded
dynamically [unless even more code is generated]. If there are tons of
fragments, there is a good intuitive reason why it becomes useless. so
I didn't want to do it. I prefer if things remain a bit EE-ish,
ultimately.
I believe that tomcat-embed-core.jar with its META-INF GraalVM metadata
files does support the EE feature set quite well, even though, those are
manually maintained as well.
My primary goal was to create a leaner alternative, targeting images
that specifically are looking to optimize image size and memory usage.
Thanks for chiming in,
Filip
