> On Dec 9, 2025, at 8:45 AM, Michael Sokolov <[email protected]> wrote: > > It's surprising that you would see so many messages from your search > application since the provider only logs these warnings when it is > created as a singleton, so I think that must mean you are running many > jvms? To answer your Q: I don't know how to disable the naggy warnings > either
Same for us - we see the message at startup and then not again for the lifetime for the app. Certainly not for every request. Maybe you're inadvertently re-initializing for each request? At least one of these messages is actually coming from Lucene: https://github.com/apache/lucene/blob/main/lucene/core/src/java25/org/apache/lucene/internal/vectorization/PanamaVectorizationProvider.java#L59-L69 Since it uses `java.util.logging`, I expect you could suppress this message by configuring jul with a level that suppresses this message. But really, you should only be seeing it once per init. Unclear if you can suppress the warning from the JVM itself about incubator modules, but this will go away eventually when the support becomes final, and also should be only once per JVM. > > On Tue, Dec 9, 2025 at 9:49 AM Trevor Nicholls > <[email protected]> wrote: >> >> Our application doesn't use any vector data types and so far as I know it >> doesn't do any vector type comparisons either. Nevertheless I added this to >> the commandline and I got a different message on execution: I think these message are about processing data with vector instructions, which doesn't necessarily mean you used vector types. For example it seems there's an implementation of postings that uses vector operations to decode them faster. >> I'm building and testing this on a machine with the full JDK but it will be >> deployed to machines that currently only have the JRE. Do I need the JDK >> installed everywhere? No, certainly not. This should all work fine with a JRE. ... >> >> >> >> [date & time] >> org.apache.lucene.internal.vectorization.PanamaVectorizationProvider <init> >> >> INFO: Java vector incubator API enabled: uses preferredBitSize=512; FMA >> enabled >> >> >> >> This goes to stderr, and I'd prefer to suppress it somehow. >> >> >> >> The Lucene doco suggested that I could disable the FMA vector extension by >> using the commandline option "-Dlucene.useVectorFMA=false" but this just >> generated a different series of messages to the error log. >> >> >> >> So far this is a trivial complaint that I wouldn't raise because the indexes >> are not built at a high frequency and these unnecessary message lines don't >> do any damage. >> >> >> >> However the application which performs the searches is also generating error >> output. If I include the --add-modules jdk.incubator.vector parameters, >> every search request adds the lines >> >> >> >> WARNING: Using incubator modules: jdk.incubator.vector >> >> [date & time] >> org.apache.lucene.internal.vectorization.PanamaVectorizationProvider <init> >> >> INFO: Java vector incubator API enabled; uses preferredBitSize=256; FMA >> enabled >> >> >> >> to the error channel. Now this is a problem because the error file grows >> like Topsy and any real errors in it are apt to get missed. >> >> >> >> I don't really need to be told every time that I'm using vectorization >> (although I'm not!) because I explicitly put it on the commandline. I only >> expect to see a warning if something is wrong. >> >> >> >> So that's the first question; is there some magical incantation that will >> allow Lucene to think it's using vectorization and still keep the error log >> clean? >> >> >> >> The second question is one that probably reveals profound ignorance. The >> option I was prompted to add to the application commandline refers to a jdk >> module. >> >> >> >> >> >> cheers >> >> T >> >> >> >> >> >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
