On Mon, Jul 13, 2020 at 11:59 PM Filip Hanik <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.
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.
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.
Rémy
