Visit Azul.com Support

Native Applications

Table of Contents

Looking for Zing? The Azul Zing Virtual Machine is now Azul Zulu Prime Builds of OpenJDK and part of Azul Platform Prime. Learn more.

A native application is any application that is written in a language other than Java and calls JNI_CreateJavaVM to create the VM and makes calls to Java code. This is usually written in C/C++ and contains the “main” function to start execution.

For Information about known issues while running native launch apps with Azul Zulu Prime Builds of OpenJDK (Azul Zulu Prime JVM), see Known Issues Running Native Apps in the Troubleshooting Azul Platform Prime section of this guide. For information about garbage collection and tuning, see GC Log File Analyser.

Invoking Native Applications with Azul Zulu Prime JVM

If Native (C/C++) applications invoke Azul Zulu Prime JVM, consider these issues before you execute your code.

  • Native application — Identify how the native app creates the VM to find possible collisions with areas used by or allocated by the Azul Zulu Prime JVM.

  • Consider known limitations when running native apps on Azul Platform Prime. Identify the issues by the failure messages.

  • Invoking the Azul Zulu Prime JVM — check for differences between a stock build and a Azul Zulu Prime JVM build.

  • Native apps should also know how to run Azul Zulu Prime JVM specific features such as the Tick Profiler mechanism and C-Heap Leak detection.

Consult the cases listed below to determine your best course of action.

Invoking the Azul Zulu Prime JVM in Native Applications

There are two primary ways of invoking the Azul Zulu Prime JVM in native applications. Key sections of code are highlighted.

Case 1: Native application dlopens libjvm.so and uses dlsym to find 'JNI_CreateJavaVM’.

Note
libjvm.so is dependent on libraries inside the paths mentioned in LD_LIBRARY_PATH.

Sample source:

 
…… JavaVMInitArgs vm_args; JavaVMOption options[1]; options.optionString = "-Djava.class.path=./"; vm_args.version = JNI_VERSION_1_6; vm_args.options = options; vm_args.nOptions = 1; /* Create the Java VM */ void* libjvm_handle; jint (*createVM_handle) (JavaVM **pvm, void **penv, void *args); libjvm_handle = dlopen("libjvm.so", RTLD_LOCAL | RTLD_LAZY); if (!libjvm_handle) { fprintf(stderr, "Can't load libjvm.so with error %s\n",dlerror()); exit(1); } createVM_handle = dlsym(libjvm_handle, "JNI_CreateJavaVM"); res = createVM_handle(&jvm, (void**)&env, &vm_args); if (res < 0) { fprintf(stderr, "Can't create Java VM\n"); exit(1); } ……

Sample build/compile line:

 
gcc -fPIC -I${JAVA_HOME}/include -I${JAVA_HOME}/include/linux –o hello_world hello_world.c

Sample run:

 
LD_LIBRARY_PATH=${JAVA_HOME}/jre/lib/amd64/server:$LD_LIBRARY_PATH ./hello_world

Case 2: Native application directly calls JNI_CreateJavaVM by linking against libjvm.

Sample source:

 
…… JavaVMInitArgs args; JavaVMOption options; args.version = JNI_VERSION_1_6; args.nOptions = 1; options.optionString = "-Djava.class.path=./"; args.options = &options; int rv; rv = JNI_CreateJavaVM(jvm, (void**)&env, &args); if (rv < 0 || !env) printf("Unable to Launch JVM %d\n",rv); else printf("Launched JVM! \n"); ……

Sample build/compile line:

 
export LD_LIBRARY_PATH=${JAVA_HOME}/etc/zing/lib:${JAVA_ HOME}/etc/orca/lib:${JAVA_HOME}/etc/libc++:${LD_LIBRARY_PATH} gcc -fPIC - I${JAVA_HOME}/include -I${JAVA_HOME}/include/linux -L${JAVA_HOME}/jre/lib/amd64/server –ljvm –o hello_world hello_world.c

Sample run:

 
LD_LIBRARY_PATH=${JAVA_HOME}/jre/lib/amd64/server:$LD_LIBRARY_PATH ./hello_world

The libjvm.so library has a dependency on the libstdc` version 3.4.20 or higher. If the executable loads `libstdc from the system, where the version of libstdc++ is less than 3.4.20, the following error is thrown:

 
/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20` not found (required by /path/to/libjvm.so)

See Troubleshooting Azul Zulu Prime JVM Errors for the details and solution.