Develop Reference

Get rid of a jni resolve warning about java.lang.PanwHooks on java.exe startup

Every time I use java.exe, there is this warning:
PowerShell > java -version
[0.052s][warning][jni,resolve] Re-registering of platform native method: java.lang.PanwHooks.NativeMethodEntry(Ljava/lang/Object;ILjava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)V from code in a different classloader
java version "18.0.2" 2022-07-19
Java(TM) SE Runtime Environment (build 18.0.2+9-61)
Java HotSpot(TM) 64-Bit Server VM (build 18.0.2+9-61, mixed mode, sharing)
No matter the JDK version. It's the same behavior whether it's jdk1.8.0_211, jdk-11.0.14, jdk-17.0.2 or jdk-18.0.2. Same for OpenJDK 1.8, 11, 17 and 18.
I can not find where is the setting that is used that makes this happen. Any advice will be much appreciated.
The environment is windows 10.

It looks like it's loading a native library on VM startup as well:
[0.009s][info][os ] attempting shared library load of C:\Program Files\Palo Alto Networks\Traps\cyjagent.dll
which looks like a Java agent.
The 'Panw' in PanwHooks seems to stand for Palo Alto Networks, which seems to be an antivirus software. i.e. this antivirus software seems to be injecting a dll which is a java agent, into the JVM process, which then produces this warning.
You should be able to suppress the warning with -Xlog:jni+resolve=off (but I realize that's not ideal).

Solr not starting on MacOS M1 using Azul JVM

I switched to the Azul JVM in order to use a native ARM JVM and Solr was no longer able to start up. I started seeing a new error in the log:
The stack size specified is too small, Specify at least 384k
If I switch back to the Oracle jvm I do not get this error.

Requirements for stack size appears to be different between ARM and x86 JVMs.
The relevant lines setting the default in bin/solr is:
# Pick default for Java thread stack size, and then add to SOLR_OPTS
if [ -z ${SOLR_JAVA_STACK_SIZE+x} ]; then
SOLR_JAVA_STACK_SIZE='-Xss256k'
fi
SOLR_OPTS+=($SOLR_JAVA_STACK_SIZE)
The default is too small for the ARM JVM to start up. To increase the stack size add the following line to bin/solr.in.cmd
SOLR_JAVA_STACK_SIZE='-Xss512k'

I faced the same error when trying to start Solr for my Rails app.
After a lot of digging, I fixed it by adding the following line to my .zshrc file.
export _JAVA_OPTIONS='-Xss512k'
My use case:
macOS Monterey (M1 2020)
openjdk version "1.8.0_332"
OpenJDK Runtime Environment (Zulu 8.62.0.19-CA-macos-aarch64) (build 1.8.0_332-b09)
OpenJDK 64-Bit Server VM (Zulu 8.62.0.19-CA-macos-aarch64) (build 25.332-b09, mixed mode)

jQAssistant heap problems - set java version explicitly

I installed jQAssistant, set the JQASSISTANT_OPTS variable to -Xmx1024M -XX:MaxPermSize=512m as recommended and then get (when starting jqassistant.cmd):
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
I guess that jQAssistant is running on the wrong version of Java. Does anyone no how to determine or change the Java version? Or is there any other reason behind this?

Just run
> set PATH
on the command line prompt. You'll see output like the following containing the path to the Java installation that is used when running jqassistant.cmd:
`Path=C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Git\cmd;C:\Program Files (x86)\GNU\GnuPG\pub;C:\Program Files (x86)\PuTTY;C:\Development\apache-maven-3.3.9\bin;C:\Program Files\Java\jdk1.8.0_77\bin;C:\Program Files (x86)\Skype\Phone\;C:\Program Files\TortoiseGit\bin;C:\Development\jruby-9.0.4.0\bin`
(the relevant part in this case is "C:\Program Files\Java\jdk1.8.0_77\bin").
You can verify this by running:
> java -version
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
Usually the given parameters should work on all Oracle JVMs even if 1.8 releases will issue a warning about the no longer supported MaxPermSize parameter.
Can you provide an information what is running on your machine?

java flight recorder how to dump on exception, FlightRecordingDumpOnUnhandledException

java version 1.7.0_79
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
args i use
-XX:+UnlockCommercialFeatures
-XX:+FlightRecorder
-XX:+FlightRecordingDumpOnUnhandledException -XX:StartFlightRecording=duration=6m,filename=member.jfr"
-XX:FlightRecorderOptions=loglevel=debug,delay=2m,maxsize=2g"
error
Unrecognized VM option 'FlightRecordingDumpOnUnhandledException'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
what is the correct option to use ? to dump the recording on exception

-XX:+FlightRecordingDumpOnUnhandledException only works for JRockit. No similar option exists for Hotspot (JDK7/8)

Use the template manager that is available in Mission Control.
Go to Windows -> Template Manager and import the template and check
Heap Statistics and Allocation Profiling, export it. Done!
(I copy-pasted this text from similar question, #Kire wrote it as well)
Basically, you can just add exception-level=all to settings. I have no idea why Oracle don't have documentation for this parameters.

java on "server" linux: Is there any way to run in client mode?

I'm running a java web server as an internal component of another project, and unfortunately java insists on running in server mode (i.e. fast, and huge memory footprint), even when I pass the -client switch.
This is a problem because java takes up so much memory that my whole project is killed by the server.
I'm running java with the command:
java -client -classpath /home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/commons-fileupload-1.2.2.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/fop-20120125.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/xmlgraphics-commons-1.5svn.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/batik-all.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/docx4j-nightly-20120105.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/spark-0.9.9.3-SNAPSHOT.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/slf4j-log4j12-1.6.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/slf4j-api-1.6.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/jetty-webapp-7.3.0.v20110203.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/servlet-api-3.0.pre4.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/antlr-2.7.7.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/commons-codec-1.6.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/docx4j-2.7.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/poi-scratchpad-3.8-beta4.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/xalan-2.7.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/antlr-runtime-3.3.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/commons-io-2.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/serializer-2.7.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/xml-apis-1.3.04.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/avalon-framework-api-4.3.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/commons-lang-2.4.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/log4j-1.2.15.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/stringtemplate-3.2.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/avalon-framework-impl-4.3.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/commons-logging-1.1.1.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/poi-3.8-beta4.jar:/home/marcintustin/webapps/django/oneclickcosvirt/oneclickcos/java/wmf2svg-0.9.0.jar: Transcoder
java -version reports:
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
As I'm on a shared host, I can't install 32-bit compatibility libraries, so I can't use the 32-bit JRE. This turns out to be a problem because as confirmed by #birryree in the comments (thanks!), 64-bit JRE always runs in server mode.
Is there a way to force java to run in normal client mode?

Based on comments received (and testing), it seems that the 64bit JVM ALWAYS runs in server mode, which means that it is VERY profligate with memory.
The work-arounds are:
Get the 32bit JVM (and appropriate compatibility libraries if on Linux); or
Use the -X options to limit memory to a certain maximum.