Thursday, July 25, 2002 09:46 PM
CORRECTION: I incorrectly said in my initial post that: "We are having the C code call the javax JFileChooser, and it lets us browse the hard drive to select any local file."
Instead, we're using javax.jnlp.FileOpenService.
We have only one DLL and we know it is being loaded because the function returns parameters correctly.
However, if the function is allowed to proceed to the first file operation (C file operation "fopen"), it exits without diagnostic (with Web Start 1.0.1) or simply does a no-op (with OpenJNLP). The fact that it fails to work with both WebStart and OpenJNLP seems to mean that it's a security problem or a bug in the JVM (JRE 1.4.0) ... or an undocumented security feature of the JNLP API.
Furthermore, the application works correctly outside JNLP, and all jar files have correct signatures (keygen). After invoking JNLP from command line with javaws, Java can successfully open and read from files.
We are not using the Java FileChooser as i said in my first post. What the code is actually doing is this:
fos = (FileOpenService)ServiceManager.lookup("javax.jnlp.FileOpenService");
fc = fos.openFileDialog(null, null);
String FileName = new String("");
FileName = fc.getName();
'FileName' is what gets passed into the C code. Java can successfully use 'fc' for file I/O in JNLP. Java can NOT use 'FileName' with java.io.FileInputStream for file I/O. Passing the string 'FileName' into the C code fails only after the first file operation (fopen), not anytime before.
Why won't Java 1.4 (under JNLP with " ") let our native DLL read and write to local files on the hard drive that the FileOpenService lets us select?