Call Java methods from vi

[xive]

I have exising software written in Java that I would like to make use of inside of a vi.  I have written a shared library in C++ that creates a Java JVM using JNI_CreateJavaVM and then calls a few methods from a specific class.  When i use this DLL from c++ application things work fine.  However when I try calling this dll from LabView JNI_CreateJavaVM fails with a -4 return code.  When looking around for help I often see http://digital.ni.com/public.nsf/allkb/BEE812007BA2A9B486256BC80068A49A?OpenDocument referenced and this has been the approach I have taken.  I have never come upon any sample code that shows this behavior working however.  If someone could point me to some sample code or suggest a reason why JNI_CreateJavaVM isn't working I would be very grateful.  Thanks.

[Joel Khan]

xive,

The best place to look at calling a DLL is the following tutorial: http://decibel.ni.com/content/docs/DOC-9069

The call library function node is used to call C/C++ dlls so you should need to write a C wrapper for the Java methods.

There should be other community members who have written C wrappers before. They might post some code on how to do this. 

<Joel Khan | Applications Engineering | National Instruments | Rice University BSEE> 

[markus kossmann]

Did you get a solution for your problem ?

I'am getting now the same problem  ( JNI_CreateJavaVM() failing with -4 which means "out of memory ")when calling it from Labwindows/CVI. That code used to work for a few weeks and and fails now since last week.  I've found some hints that this might be caused by memory fragmentation because the SUN/Oracle JVM needs a chunk of contiguous memory to allocate its heap, but no real solution

[RyanWright]

I ran into the same problem.  I am trying to call some code written in Java.  I am not a Java developer but a colleague has written a C DLL which I call from LabVIEW to invoke the JNI to execute the Java classes.  We ran into the exact same issue.  My colleague changed the amount of memory the virtual machine was requesting.  Here is a sample of the code from my colleague:

JavaVMOption options[4];
  jint res;
  options[0].optionString = "-Djava.class.path=C:\\Shared\\C-JNI-Bridge-Prototype\\bin"; //Path to the java class files.
  options[2].optionString = "-Xmx16m";
  options[3].optionString = "-Xms16m";
  options[1].optionString = "-XX:+HeapDumpOnOutOfMemoryError=C:\\Shared\\C-JNI-Bridge-Prototype\\bin\\dumps";
  vm_args.version = JNI_VERSION_1_6; //JDK version. This indicates version 1.6
  vm_args.nOptions = 3;
  vm_args.options = options;

I personally don't really understand this, but I believe this is using virtual machine options that are not the defaults.  The default options were probably requesting more memory than LabVIEW could allocate for the virtual machine.  Keep in mind that these limits will likely be different for your application.

[RyanWright]

These posts were helpful:

http://stackoverflow.com/questions/3400292/jni-enomem-from-jni-createjavavm-when-calling-dll-that-us...

https://forums.oracle.com/forums/thread.jspa?threadID=1546540