Bug ID: JDK-6405311 XtVaSetValues call does not work when running in 64-bit Java 1.5 on Linux

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
5.0u12 b01Fixed

The XtVaSetValues call works in our standalone app, it does not work when we invoke our libraries inside the java environment. The same code works on Solaris and does not work on Linux. For example,
	int i = 5;
	XtVaSetValues(_topForm, XmNuserData, (XtPointer)i, NULL);
	XtPointer data;
	XtVaGetValues(_topForm, XmNuserData, &data, NULL);
	int *j = (int *) data;
	fprintf(stderr, "j = %d\n",j);
The value printed for j on Solaris is 5, on linux it is 0.

A testcase is also provided in this report. 

Just some details on what it contains.

TestApp/SimpleApp - Java application - use the run* scripts to run the app.   Should be self-expanatory.  You must click on the "Win" button for the window generation process to start.  Build* scripts also exist for rebuilding if needed.

TestApp/TestJava - contains the JavaBean (MyBean, which extends Canvas).  Also has build* scripts, should you have to build again.

TestApp/Testsrc - native library which is the native side for the JNI. There are build and run scripts for all three SDKs (2 Solaris, 1 Linux), plus build scripts in the top level TestApp directory to do a full rebuild for each platform/SDK I was testing against. Code in MyBean_imp.cpp is where the code exhibiting the problem resides.

The java application (TestApp/SimpleApp) has my bean (TestJava/MyBean (which extends Canvas)) added to it for the test. MyBean is to serve as the location in the test application which I will use to position my widgets once I get the native widget associated with it. I also use the MyBean widget to walk up the widget tree for other purposes. In order to kick off the process of going native and getting the bean widget, use the "Win" button that is on the application. 

Motif code works fine on Linux in their standalone product.  

AWT_TOOLKIT environment variable must be set to Mtoolkit to run their code.

Here is the OS info...

Uname: Linux fruity 2.6.5-7.201-smp #1 SMP Thu Aug 25 06:20:45 UTC 2005
x86_64 x86_64 x86_64 GNU/Linux 

Release:
Welcome to SUSE LINUX Enterprise Server 9 (x86_64) - Kernel \r (\l).
Linux version 2.6.5-7.201-smp (geeko@buildhost) (gcc version 3.3.3 (SuSE
Linux)) #1 SMP Thu Aug 25 06:20:45 UTC 2005

java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_05-b05, mixed mode)
I tested it with 1.5.0_06-b05. The problem still exists.

EVALUATION well, we need build motif we use on linux and libawt.so so it does not export motif's calls. Thus user will be able to use another motif in his application which uses awt. But this doesn't mean that user can cast window it obtains using JAWT to motif widget and work with is as with regular motif widget. This is unsupported. Our public API (JAWT) provides XID and you need to work with it as with XID. So, I'm leaving it open until CTE will fix binaries problem in 5.0 (as far as I know we do not have such problems in mustang)

26-05-2006