On Sun, Mar 10, 2019 at 6:24 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> Hi guys, > > Anyone got a look to graalvm native-image tool? > Tomcat does not work OOTB due to its JMX wide usage - all is not > implemented in graalvm native scope. That said most of this code is not > really used by Tomcat and can be dropped while keeping Tomcat - at least > embedded - running. The other hit issue is the URL handler usage. > > So concretely - and without entering into the details at that early stage, > ensuring TomcatURLStreamHandlerFactory does not use URL custom factory > registration (constructor) and Registry/MBeanUtils don't rely on > MBeanServer loading directly would be a first step to be able native > images. To test it I @Substitute them with substrate API but it requires to > fork some part of Tomcat which is not desired at all on my side. > > This is just the first step since, if you want to keep all features, you > will need to create a json with the reflection metadata for some features > but at least these two "changes" would enable to run native-image > successfully. > > Overall this mail does not intend to speak of "fix" yet but only mainly > intend to ask two questions: > > 1. any existing status on graalvm native image support I would have missed? > 2. any will to work in that direction in the community? (graalvm is still > very young and lack several features to really embrace java ecosystem so > can be fair to say "later") > Well, the said features are quite useful/nice/etc, and I haven't been looking at native images. Any real concrete plan to improve things without removing useful items ? Rémy
