Hi Eric, Thank you for your reply.
Well, it didn't even "compile" to native image for some reason (and the error messages didn't look to me like they were about some missing dependencies, though who knows). Ok, another kind of approach: would that make sense to use an Ahead-of- Time compiler (jaotc) to create a version of BaseX precompiled into a form of an OS native shared library (.so) and load it as a AOT library at the the time when the JVM starts to skip the JIT compilation phase and save some time on that? (we definitely don't need to recompile the same byte code with the JIT-compiler every time we start the app) I tried that: that looked slightly better: at least the AOT compiler successfully created the shared library image. But the JVM then refused to start the org.basex.BaseX class unless I also provide the BaseX JAR file in the class path and the time to start the app and process the query was even worse in that case. Ok, may there be any other options to make it possible to use BaseX as a command line tool that has to be started often to extract some bits of information from XML and JSON files to used the scripts written in other languages (UNIX shell scripts and Makefiles in my case). I use bits of information extracted from XML and JSON files to assign variable in Makefiles. I have an idea regarding the way to avoid starting the JVM multiple times: I perhaps could move from make to Apache Ant which has a special 'Java' task the purpose of which is to start an external class in the same JVM that Ant is running on but that would be the last resort (I would avoid moving to Ant as long as there is a slightest hope to stay with make as well as I perhaps won't change the XQuery implementation as long as there is a slightest hope to stay with BaseX). Maybe it's possible to run a BaseX server on the same machine during the build and use some light-weight client to connect to it, pass the query for execution and receive the results? (that requires the server to have access to local files (XML and JSON): need to recheck whether that would work) Thank you Best regards On Thu, 2022-12-01 at 16:56 -0500, Eric Levy wrote: > GraalVM, and especially Native Image, is an impressive and important > project, but more limited than many imagine. > > Building native images is constrained by practical issues. For > example, > running a Java application requires certain external dependencies. If > a > dependency is not available, then the application may fail, but > generally only at the point of invoking a specific feature that > requires it. If some feature is not invoked, then a missing > dependency > may be harmless. > > Dependency resolution is different for Native Image. Rather, the tool > attempts to find the complete set of dependencies utilized at all > points in an application, convert them all into native machine code, > and finally, bundle them into a single executable file. > > Native Image is less useful for consumers of a Java application than > developers. It might require integration of NI into the overall build > process, to achieve the results you want. > > > On Thu, Dec 1 2022 at 11:08:32 AM +0100, dli...@gmail.com wrote: > > Hello Everyone, > > Didn't anybydy try and is that possible to convert the BaseX JAR to > > a > > "native-image" (using GraalVM's convertor or any other tool maybe)? > > The reason: I have to use BaseX in scripts and Makefiles as an > > XQuery > > engine and have to call it often. The problem is the JVM startup > > time > > affects the performance significantly when it has to start multiple > > times. > > I tried just naïvely running the GraalVM's native-image convertor > > against the BaseX103.jar file and got errors with long backtraces > > (that > > I didn't quite understand to be honest). > > Did anybody try that, maybe? > > Best regards > > > > > >
