Jni issue- urgentllly

We have developed a *.dll that routes advapi32.dll functions to java code.My class uses j2sdk1.4.1_01 classes and also the same jre.When I try to execute this *.class using jre1.4.1_01 works fine,but when I try to execute the same class using jre 1.2.2 I've raised the error(not exception) "Fatal error in native code: try to access a static member from a non-static method".This is absurd because al my metods are statically methods even those in native code.If someone could help me I'll be very grateful.

The error sounds like something's wrong with the native methods. Make sure your code is correct.

Similar Messages

Solaris - Windows JNI Issues

*** Setting the scene ***
I am trying to write a library called GuidGetPid which will have only 1 method to return the current pid.
The header file generated by javah only has the following declaration in it:
* Class:     GuidGenerator
* Method:    getPid
* Signature: ()I
JNIEXPORT jint JNICALL Java_GuidGenerator_getPid
(JNIEnv *, jclass);I am new to working with JNI, but I was succussful in implementing and running my program in Solaris.
The implementation in C is:
#include <unistd.h>
#include <jni.h>
#include "GuidGenerator.h"
JNIEXPORT jint JNICALL
Java_GuidGenerator_getPid(JNIEnv *env, jobject obj)
     return getpid();
}*** My problem ***
I am trying to implement this is WinXP now. In MS VC 6.0, I wrote the following cpp file.
#include <process.h>
#include <jni.h>
#include "GuidGenerator.h"
JNIEXPORT jint JNICALL
Java_GuidGenerator_getPid(JNIEnv *env, jobject obj)
     return getpid();
}Everything will compile, and java can find the library, but for some reason it cannot locate the method getPid. Specifically I get the error message
Exception in thread "main" java.lang.UnsatisfiedLinkError: getPid
        at com.ml.mlim.mlde.pls.GuidGenerator.getPid(Native Method)
        at com.ml.mlim.mlde.pls.GuidGenerator.nextID(GuidGenerator.java:49)
        at com.ml.mlim.mlde.pls.tester.main(tester.java:23)Does anyone have any suggestions as to how I can fix this?

Hmm... strangely (maybe not), it works for me. Here, I've posted everything I used, including the generated header file and the command line arguments I used.
****** Java source file ******
public class test
     public static native int getPid ();
     static
          System.loadLibrary ("test");
     public static void main (String [] args)
          System.out.println (getPid ());
}*******Generated header file********
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class test */
#ifndef _Included_test
#define _Included_test
#ifdef __cplusplus
extern "C" {
#endif
* Class:     test
* Method:    getPid
* Signature: ()I
JNIEXPORT jint JNICALL Java_test_getPid
(JNIEnv *, jclass);
#ifdef __cplusplus
#endif
#endif******** C source file ********
#include <jni.h>
#include <process.h>
#include "test.h"
JNIEXPORT jint JNICALL Java_test_getPid (JNIEnv *env, jclass cls)
     return (jint) getpid ();
}******* Command line arguments *******
cl -Ic:\j2sdk1.4.2\include -Ic:\j2sdk1.4.2\include\win32 test.c -LD -Fetest.dll
Hope any of that information helped.
If you still have problems, check if the dll is anywhere on your system (or rename it completely so that there will be no conflicts whatsoever).
Cheers.

Jni issues linux

I am trying to run a simple jni program fron this site "http://public.cabit.wpcarey.asu.edu/janjua/java/jni/ " on Red Hat Enterprise Linux AS release 4 and jdk 1.5.09 , AMD opteron. But when i run the command "gcc -I /usr/java/jdk1.5.0_09/include/ -I /usr/java/jdk1.5.0_09/include/linux/ -shared -o libhelloNative.so helloNative.c" i get the following error
/usr/bin/ld: /tmp/ccOjRonK.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/tmp/ccOjRonK.o: could not read symbols: Bad value
can anyone tell me a fix for this , I had no problem running the same program on Redhat Linux workstaion 3 with intel xeon processor
Thanks

I am trying to run a simple jni program fron this
site
"http://public.cabit.wpcarey.asu.edu/janjua/java/jni/
" on Red Hat Enterprise Linux AS release 4 and jdk
1.5.09 , AMD opteron. But when i run the command
"gcc -I /usr/java/jdk1.5.0_09/include/ -I
/usr/java/jdk1.5.0_09/include/linux/ -shared -o
libhelloNative.so helloNative.c" i get the
following error
/usr/bin/ld: /tmp/ccOjRonK.o: relocation R_X86_64_32
against `a local symbol' can not be used when making
a shared object; recompile with -fPIC
/tmp/ccOjRonK.o: could not read symbols: Bad value
can anyone tell me a fix for this , I had no problem
running the same program on Redhat Linux workstaion
3 with intel xeon processorWas the xeon processor 64 bit?
This isn't a JNI problem, its a 64 bit vs 32 bit problem.
Thanks

JNI Issue on JDK vs JRE

Dear all,
I've a JNI dll that run fine when the execution is done with java.exe of JDK, but if I execute the code using java.exe of JRE I got an error of "access an invalid memory location". Both JDK and JRE are "1.6.0_21" on 32 bits.
Does anybody already have a problem like this?
Best regards

You have a bug in your JNI code. Pointer error or a misuse of an API.
The fact that it works in one place does not change that. It only means that the failure didn't cause that one to fail.

Mouse hook from JNI doesn't work

Hello
i am trying to register windows mouse hook(WH_MOUSE) from java using jni. (windows vista x64)
all is fine when i register hook from c++ application. strange things start to happen when the hook is registered inside jni.
i implemented a hook proc in 32bit dll, when it is injected into 32bit processes it looks ok, but 64bit applications stop responding. 64bit dll injected into all windows makes 32bit apps inactive for any mouse inputs, similar as in first scenario.
there are no problems with WH_KEYBOARD or WH_SHELL hooks
here is the code:
//dll loaded in jni function
extern "C" __declspec(dllexport) LRESULT HookMouseProc(int nCode,WPARAM wParam,LPARAM lParam)
     if(nCode<0)
          return CallNextHookEx(NULL, nCode, wParam, lParam);
     if(wParam==WM_RBUTTONDOWN && nCode==HC_ACTION)
          AfxMessageBox("inside mouse proc");
     return CallNextHookEx(NULL, nCode, wParam, lParam);
//jni dll
extern "C" JNIEXPORT jboolean JNICALL Java_winHook_WinHookUtil_setMouseHook(JNIEnv *env, jobject jObject)
     HMODULE hModule=LoadLibrary("WinHook32.dll");
     void* fnt=GetProcAddress(hModule, "HookMouseProc");
     g_hookMouse=SetWindowsHookEx(WH_MOUSE, (HOOKPROC)fnt, hModule, NULL);
     return JNI_TRUE;
i have no idea what is wrong. please help.
Edited by: user3530356 on 2010-10-03 16:19

all is fine when i register hook from c++ application.What about when you register the hook from a DLL? A 32-bit DLL? a 64-bit DLL?
This is clearly a 32/64 issue. Not a JNI issue.

Mapping struct dataype in C to Java JNI

Do anyone have idea how to map struct datatype in C to Java JNI?
I've got idea and examples of mapping primitive datatype and array in C to Java JNI but none for struct datatype in C?
Hope I can got an example of it! Thanks!!!

The first way - by the book
Read Sheng Liang's book (downloadable from ftp://ftp.javasoft.com/docs/specs/jni.pdf )
In brief - and explaining only the main steps - no detailed instructions - please read the book
You want to return an array of the following objects (they have only primitive data, for easing the explanation)
//-- C++
struct MyData {
    int firstField;
    char *secondField;
//-- Java
public class MyData {
    public int firstField;
    public String secondField;
}in the native Java method "doSomething" of the class MyProgram
public class MyProgram {
    static {
        System.loadLibrary ("myjni");
    public static native MyData[] doSomething() ;
}You will have to call JNI functions for creating the MyData[] array, for creating individual MyData objects, and for setting the individual fields of each MyData object. Very boring indeed.
The second way - the hard one
Instead of returning a Java array of Java objects, study the serialization format of Java, and return a Java array of bytes. Then use ByteArrayInputStream and ObjectInputStream, or DataInputStream, for deserializing the objects you do need to get in your program. It will be slower than creating directly the Java objects in your C++ program, but you can save a few lines of code in your C++ program. (You will maintain the program yourself, don't you?)
The third way - the lazy one
Instead of returning a Java array of Java objects, return a Java String (it could be a XML-formatted string, or a string using delimiters - what you think that is easier to encode in C++ and decode in Java.)
The third way - the better way
Use the SWIG framework ( http://www.swig.org ). Your code will be very maintenable, you will not have to deal with JNI issues (there are lots and lots of JNI details you will have to bother with, solve all that problems with SWIG). Take care with spelling - SWIG is not SWING.

-XcheckJNI

Peers
Appreicate your help here.
I came across 2 parameters that can be used to trouble-shoot / debug
JVM/JNI issues.
-Xcheck:jni and
-X???
Appreicate
1. let me know the full syntax of each parameters
2. do they work for JVM 1.4.2_11
Thanks

Cl.exe and mt.exe but got "...MSVCR80.dll was not found. Re-installing..."

The compile and manifest were completed with no complaints but when I ran the code, I got "This application has failed to start because MSVCR80.dll was not found. Re-installing the application may fix this problem.".
Here is what I did:
Step 1: Compile and manifest
"%MSVCDir%\bin\cl.exe" /I"%JAVA_HOME%\include" /I"%JAVA_HOME%\include\win32" /MD /LD /FeBinless.dll ../info/binless/jni_binless.c ../jni_shared/jni_gen_c.c ../jni_entropy/jni_entropy_c.c ../jni_input/jni_input_c.c ../info/binless/binless_c.c ../../info/binless/BinlessOpenComp.c ../../info/binless/BinlessWarpComp.c ../../info/binless/BinlessEmbedComp.c ../../info/binless/BinlessInfoComp.c ../../shared/MatrixToHist2DComp.c ../../shared/Info2DComp.c ../../shared/sort_c.c ../../shared/gen_c.c ../../shared/hist_c.c ../../input/input_c.c ../../entropy/entropy_c.c ../../entropy/entropy_bub_c.c ../../entropy/entropy_chaoshen_c.c ../../entropy/entropy_ma_c.c ../../entropy/entropy_tpmc_c.c ../../entropy/entropy_jack_c.c ../../entropy/entropy_plugin_c.c ../../entropy/entropy_ww_c.c ../../entropy/variance_jack_c.c ../../entropy/variance_boot_c.c ../../entropy/entropy_nsb_c.cpp /link libxml2.lib libgsl.a libgslcblas.a >> binless-out.txt
mt.exe -manifest Binless.dll.manifest -outputresource:Binless.dll;2
The operating system is Windows XP and has the following environment variables:
PATH=%JAVA_HOME%\bin;%LIBXMLDir%\bin;%ICONVDir%\bin;%GNUWINDir%\bin;%WINSDKDir%\bin;%MSVCDir%\bin;%MSVCDir%\..\Common7\IDE;%ZLIBDir%\bin;%systemroot%\system32;%systemroot%;%systemroot%\system32\wbem
INCLUDE=%WINSDKDir%\include;%GNUWINDir%\include;%MSVCDir%\include;%MSVCDir%\PlatformSDK\include;%JAVA_HOME%\include;%JAVA_HOME%\include\win32;%LIBXMLDir%\include;%ICONVDir%\include;%ZLIBDir%\include
LIB=%WINSDKDir%\lib;%GNUWINDir%\lib;%MSVCDir%\lib;%MSVCDir%\PlatformSDK\lib;%LIBXMLDir%\lib;%ICONVDir%\lib;%ZLIBDir%\lib
where:
GNUWINDir=c:\project\lib\GnuWin32
ZLIBDir=c:\project\lib\zlib
ICONVDir=c:\project\lib\iconv
LIBXMLDir=c:\project\lib\libxml2
WINSDKDir=C:\Program Files\Microsoft SDKs\Windows\v6.0A
MSVCDir=C:\Program Files\Microsoft Visual Studio 9.0\VC
Step 2: Compile the Java jni code
javac -d ..\classes ..\server\Binless.java
Step 3: Run the code
java -classpath ..\classes jni.test.test_binless
Got: This application has failed to start because MSVCR80.dll was not found. Re-installing the application may fix this problem.
Any help is greatly appreciated. Thanks.

This is a Windows side-by-side issue not a JNI issue. As such it doesn't really
belong in this forum except as an object lesson to people who create JNI's.
I had these issues when I moved to Visual Studio 2005 - which, oddly enough,
was the version of the IDE where SxS support was not only introduced, but
enforced.
The fact that you tried to put a SxS folder in the PATH tells me you know
nothing about how SxS and manifests works. You need to learn about these
things and then your problems will become blushingly obvious.
The Binless.dll manifest must be embedded, and it must contain dependency
entries that specify the SxS requirements, including the version(s) of the
dependent libraries. Secondly, the specific version of the libraries must be
installed on the target system.
My guess is your manifest specifies a CRT version that's not installed on your
system and that is why the system is complaining. Look for the
Binless.dll.intermediate.manifest file. It will tell you what your dll expects.
Here's an example of a dll (debug version) manifest:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
</trustInfo>
<dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.30729.4148' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
</dependency>
<dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC90.DebugMFC' version='9.0.30729.4148' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
</dependency>
<dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC90.ATL' version='9.0.30729.4148' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
</dependency>
</assembly>Get [Dependency Walker|http://www.dependencywalker.com/] it's free. You will need it at some point.
Cheers,
Mike

Is there any known issue about mutex lock used in JNI on Solaris 10?

Dear Oracle,
I'm facing a strange behavior when running a JNI application that use the mutex lock. The application hanged after running for a while on one of our Solaris 10 machines. After investigating the stack trace of the application, it shows that one of all the application's threads that access the JNI hold the mutex lock forever, and that cause the other threads cannot access the JNI. The same application works fine on other Solaris 10 machines.
The mutex function I used as show below:
mutex_lock(&mutex)
The application hanged at this line:
0xff2cc940 ___lwp_mutex_timedlock + 0x8
The Kernel version is SunOS 5.10 Generic_142900-14
Since this issue occurrs on only one Solaris 10 machine in our environment, we are wondering if there is any known issue regarding the mutex lock used in JNI on Solaris 10. We tried to search the Internet and the Java Bug database but found nothing related to this issue.
Best regards,
Krit K.

876587 wrote:
... and that cause the other threads cannot access the JNI. The same application works fine on other Solaris 10 machines.
Different environments mean just that. So something could be causing it outside java.
Additionally if anything at all is different in the execution data, such as even a name having a different size, then it would change the execution path.
Which would cause a problem in the JNI code to manifest itself on only one box. Probably isn't a pointer bug but all sorts of odd behavior can result from that.

Very interesting and quizzical issue in JNI COding.

HI All,
i've been facing a really frustrating, interesting and mindwrenching issue in my native code. Here is a background.
1. I was given a thirdparty ACtiveX OCX file that needed to be called through JAva.
2. I wrote a C++ JNI wrapper to call the methods of the activex object.
3. I first initialize the object, set the relevant parameters (sent from java) and then call the method I need.
4. For every record, I need to perform step 3. NOw, I am ryuning batch loads. THE code works fine for 9500 records. BUt, once the record count reaches 9885, I get a pop-up error from the activeX OCX control. I've not coded that pop-up. It comes out of the blue.
I initially thought that it could be a memory issue, but even after doubling my VM Memory allocation, I get the error. Its not a data issue, because the reocrd that causes the issue, if I run the code just for that single record, it works fine.
Below is the implemetnation of the C++ code. LEt me know if I'm doign somethign wrong or if someone has seen something like this happen before. WHAt is baffling is that it works smoothly for less records. When the pop up appears, no exception is caught on the native side also.!!!
Does java set aside some memory specfic for native libs and that is exhausted after 9885?
I'm running on windows, so is it possible to trace the internal malloc and release within the dLL?
ANy thoughts and ideas will help. I've been struggling for about three days now. ALso, do you know of a good C++ forum that i could post this question?
#include "stdafx.h"
#include "jni.h"
#import "thirdparty.ocx" raw_native_types
JNIEXPORT jstring JNICALL Java_org_nik_integration_test_Exporter_saveAsImage
(JNIEnv * env, jobject obj, jint height, jint width , jstring fileName, jstring encryptionKey, jshort encryptionAlgorithm, jstring encryptedImage, jshort imageType)
     const char* fName = NULL;
     const char* encryptionKeyc = NULL;
     const char* encImgc = NULL;
     ThirdPartyLib::_DTPPtr tpptr = 0;
     HRESULT hres = 0;
     try
          hres = ::CoCreateInstance(__uuidof(ThirdPartyLib::TP),NULL,CLSCTX_ALL, __uuidof(ThirdPartyLib::_DTP), (void**)&tpptr);
          //Retrieve values sent from Java
          fName = env->GetStringUTFChars(fileName,0);
          encryptionKeyc = env->GetStringUTFChars(encryptionKey,0);
          encImgc = env->GetStringUTFChars(encryptedImage,0);
                     tpptr->Key = _com_util::ConvertStringToBSTR(encryptionKeyc);
          tpptr->Algorithm = encryptionAlgorithm;
          tpptr->Img = _com_util::ConvertStringToBSTR(encImgc);
          tpptr->SaveUnencrypted(width, height,_com_util::ConvertStringToBSTR(fName) , 1);
     catch(_com_error &e)
          _bstr_t bstrSource(e.Source());
         _bstr_t bstrDescription(e.Description());
         printf( "Exception thrown for classes generated by #import" );
         printf( "\tCode = %08lx\n",      e.Error());
         printf( "\tCode meaning = %s\n", e.ErrorMessage());
         printf( "\tSource = %s\n",       (LPCTSTR) bstrSource);
         printf( "\tDescription = %s\n", (LPCTSTR) bstrDescription);
         // Errors Collection may not always be populated.
         if( FAILED( hres ) )
            printf( "*** HRESULT ***" );
          return NULL;
     __finally
          tpptr->Release();
          tpptr = NULL;
          //Release memory - java specific
          env->ReleaseStringUTFChars(encryptionKey, encryptionKeyc);
          env->ReleaseStringUTFChars(ink, inkc);
          env->ReleaseStringUTFChars(fileName, fName);
     }

Well you have now demonstrated conclusively that it has nothing to do with JNI.
It is either a bug with that component and/or you are using it incorrectly. Solutions to either of those would come from the source of that component, which would be somewhere besides here.
If it was a bug then you might find a way around it by doing one of the following
1. Try variations of use (options, parameters, whatever.)
2. Determine if you can solve your problem by only processing 5000 entries at a time (where 5000 chosen just to be significantly lower than the limit you have already found.) If that works then you can solve the problem by using a restartable executable that wraps the component.

Issue in JNI

WE are using WLS6.1
i am having issues in calliing JNI programs
from the servlet .The issues is that it gets called only sometime.WE have checked the LD library path , it seems to be ok .
Is there any service pack that needs to be put for JNI .

Well you have now demonstrated conclusively that it has nothing to do with JNI.
It is either a bug with that component and/or you are using it incorrectly. Solutions to either of those would come from the source of that component, which would be somewhere besides here.
If it was a bug then you might find a way around it by doing one of the following
1. Try variations of use (options, parameters, whatever.)
2. Determine if you can solve your problem by only processing 5000 entries at a time (where 5000 chosen just to be significantly lower than the limit you have already found.) If that works then you can solve the problem by using a restartable executable that wraps the component.

Issue while loading the library files(".so" or ".sl") using JNI

Hi,
We are loading the c library files using system.load during the init phase of servlet.
While loading the application for the first time everything goes smooth and application behaves as expected.
We are facing the below issue when we try restarting the application through admin console in case of WAS (web sphere) for any patch deployment in the application.
java.lang.UnsatisfiedLinkError: Native Library /users/test1/siva/jnilib.so already loaded in another classloader.
If we restart the complete WAS every thing works fine.
There is no specific System.unload function available in java to remove the loaded library in JVM.
Is there any alternate way to unload the library which is loaded in class loader to resolve this issue which can be called in the destroy phase of servlet?
Any help here is highly apreciated.
TIA,
Siva.

sivabalan wrote:
Hi,
We are loading the c library files using system.load during the init phase of servlet.
You mean a shared library, not C files (which would be source.)
However I am not sure that loading it in a servlet is a good idea. But that is a different issue.
Is there any alternate way to unload the library which is loaded in class loader to resolve this issue which can be called in the destroy phase of servlet?This is how it works on the Sun VM back to about 1.2. And as far as I know there is no other way for it to work on any other VM.
You have a class with native methods that relies on the shared library. The class and the shared library are loaded into a class loader. If the class loader is unloaded by the GC then the native library will be unloaded as well.
A class loader can be collected by the GC if if the classes loaded by it are no longer actively references. So ALL class instances can be collected.
If the above is true then by running System.gc() twice it will collect the classloader and thus the native library.
So in your situation it might work if your app server allows you do GC (full GC is better if that is an option). You could try unloading the app, then doing the GC option several times, then do a load. Try the GC option about 6 times and the reduce it down to see if 2 work.
If that doesn't work then there could be some programmatic solutions using the same idiom.

JNI memory/thread issue

Guys,
Here's the problem I'ce seen with JNI and using the JVM in C++.
I create AWT frames through a call to the constructor and access the window thro' call to the object.
before a call to DeleteGlobalRef, I call a Java method from C++ that calls dispose on the Frame.
I noticed that with time a lot of threads are not terminated and after a couple of creations and disposing of frames, the VM crashes.
Any thoughts....
Thanks.

You have a problem in your code.
If when you say "few" it means like 3-100, then the most likely explaination is you have buffer problem (over/under writing a buffer.) A problem like that does not cause problems until latter, sometimes much later, in the code.

JNI Multithreading/Callback Function Design Issues

Ok, I have been working on this for quite some time now and I simply can not figure it out. So any ideas are more than welcome. :)
I have Java code that uses a DLL that I created in C++. My C++ code links with a library made by a 3rd party (don't have access to the source or anything). The 3rd party's code creates a new thread and calls a callback function that I define in my C++ code. This callback is called continuously until I perform some other code to stop it. Now for the tricky part. In my callback function I need to pass some data back in Java. Here is where my design falls apart. Since the callback function is technically part of the 3rd party's thread, I have to call AttachCurrentThread() in the callback to get the JNIEnv pointer in order to ultimately call my desired Java method. The problem is that my Java method (or even the C++ callback function) are only invoked if I do a sleep() in my C++ code after I start the 3rd party code which creates the thread. If I do a Thread.sleep() in Java after I call the native function code, it just sleeps and the callbacks never get called. It appears as though the thread dies as soon as I return from my C++ code.
So now I am stuck. I have tried creating a thread in Java which simply calls the C++ code and the C++ code just loops waiting for an updated flag, however, this causes the 3rd party's thread creation code to fail (not quite sure why). However, even if their code worked, I'm not convinced this is even proper design. I apologize if this is simply a threading design principle as my multithreading programming techniques are a bit rusty and I've never done a multithreaded application this complex (this is a simplified version, but the idea is the same).
I welcome any suggestions or even documentation that may lead me in the right direction. Thanks in advance.

I have a similar issue.
from java I call a dll I wrote, which calls a third party scanner dll (cyber.dll). Everything works ok, except, when an event in the scanner occurs, it calls the call backin my dll, which calls the callback in java, which kills the vm with an access violation. If I execute the call back to java from a c method which I just called from java, it works, but if it gets called outside of the java execution of the native code, it fails.
I havent done anything with treads or syncronisation. Do I need to do this AttachCurrentThread stuff? If so, where do I get the _jvm handle as Im not starting the vm from c?

Interval Timing Issue On Solaris 10/Intel When The JNI Is Involved

We've observed an odd behavior bridging to interval timers over the JNI on Solaris 10/Intel, and I was wondering if anybody here has ever seen anything like this.
We have an interval timing facility that's implemented over a small set of platform-dependent native timing facilities. The *NIX "itimer" facility is used wherever it exists. On RedHat/Fedora we also implement a timer over the RTC device. On Windows we use a WaitableTimer.
On all platforms there's a Java class that bridges to an appropriate timing facility via the JNI, and to date this has worked great on all platforms except for Solaris 10 on Intel. By "worked great" I mean that the clock tics end up being almost exactly what we expect for a given configured Hz update rate. So... e.g. if we set up a timer for 50 Hz, then we actually get 50 Hz +/- some minor variation much less than 1 second.
On Solaris 10/Intel we set up a 50 Hz itimer in a plain-vanilla C app and we get ~50 Hz, but if we call the same C code from Java via the JNI we almost always end up with ~38Hz.
The amount of Java and native code involved is almost trivial, and the hardware is a smoking fast contemporary PC. We ran over the itimer facility on an old Sparc 5 box and it worked fine.
I've tried tweeking sundry esoteric -X and -XX JVM invocation options with no effect.
J2SDK 1.4.2-07 in all cases.
Thoughts?

I'd think you should be posting in the forum for the Solaris 10 os, not a Java forum. Maybe someone in the Java Native Methods forum would have the necessary Solaris 10 expertise, also.
If you do post elsewhere, either close this out with a final post or put a reference(s) to any other posts and say where you want replies posted, so replies aren't needlessly duplicated.

Jni issue- urgentllly

Similar Messages

Maybe you are looking for