JNI wrapper for NSSavePanel

[Steve Hannah]

> Are you building/running the app from Xcode? You could try setting a
> breakpoint to inspect the local state.
>
>
I'm building the JNI library in XCode, but the application I'm building in
Netbeans and packaging using Marco's port of AppBundler.

I've experimented with threading issues and don't think that is the problem
now in this case, but still don't know what is the problem.  I have
modified the example to make it simpler.

The following code does not work:

JNIEXPORT jstring JNICALL Java_ca_weblite_mactools_Sandbox_saveDialog

(JNIEnv *env, jobject jthis, jstring title, jstring extension){

    //JNF_COCOA_ENTER(<#env#>);

    return JNFNSToJavaString(env, @"/Users/shannah/Downloads/out2.pdf");

    //JNF_COCOA_EXIT(env);
 }

If I uncomment the JNF_COCOA_ENTER/EXIT lines, it works properly.

I have my Java logging working now so I can follow the progress with
println statements right up until it calls the native method.  I get a
crash at that point.  It doesn't even enter the native method (i.e. if I
put a print statement first line, nothing happens.

It almost seems like putting the JNF_COCOA_ENTER/EXIT calls inside the
method some somehow changes the method signature so that Java can no longer
find the correct method to call at runtime.... but that doesn't seem
possible.

Given my inexperience with XCode, I suspect that it could be a problem with
the way I'm building/linking the JNI library.  The fact that calls to
JNFNSToJavaString() work makes me thing that the JavaNativeFoundation is
correctly linked (?).

Note:  I'm going through this exercise to try and write the code with
JNF_COCOA_ENTER/EXIT because, despite the fact that the library worked
perfectly the way it was on Mountain Lion, it doesn't work on Lion, so I'm
trying to cover all of my bases to figure out why.  When I got stuck at
this step, I figured it's worth finding out what this problem is just in
case it's related to the Lion problem.

I'm building it with settings:
Base SDK: Latest OS X (OS X 10.8)
Deployment Target: OS X 10..7  (although I've tried 10.6 and 10.8 with same
results).


Any other suggestions or tips, much appreciated.


Best regards

Steve


>> JNF_COCOA_ENTER/EXIT do more than just setup an autorelease pool - they
>> also catch ObjC exceptions and re-throw them as Java runtime exceptions.
>>
>> Do you have the backtrace of where you are crashing when using
>> JNF_COCOA_ENTER/EXIT?
>>
> I do, but I'm having difficulty making heads or tails from it.  I'm also
> struggling with getting logging information out on the Java side as I'm
> working on a Mountain Lion machine and I can't find where System.out and
> System.err are logged by default... and the sandbox is making it difficult
> for me to set a log location manually... (anything that runs or fails
> before or during the setting of a custom log location is not logged).
>
>
> I think (but I'm not certain) that this is the way it is now on Lion and
> Mountain Lion - output logged to stdout/stderr directly (including the JVM
> System.out/err) just goes to /dev/null unless you run the primary
> executable from a shell or some other parent process that gives it a TTY.
> Otherwise, the only thing that gets logged to the system console comes
> through ASL, like NSLog(). Of course, I may be completely off on this, but
> perhaps this is explaining what you are seeing.
>
> Also, are you doing anything special to run this JNI method on the main
>> AppKit thread (or are you using SWT)?
>
> Ah.. I hadn't thought of that, but yes.  I'm overriding the
> java.awt.FileDialog class's setVisible() method to display this as a modal
> dialog.
>
>
>> If not, you may want to use +[JNFRunLoop
>> performOnMainThreadWaiting:withBlock:], which will block the current
>> thread, run your block on the main thread (safe for AppKit), and then
>> continue execution of your Java thread when the block returns.
>>
>
> I'll give this a shot.
>
> Thanks for the suggestions.
>
>
> No problem. Please do always think of the threading considerations when
> writing JNI. We try to let you not worry about exceptions and autorelease
> pools if you use JNF, but threading is still something you have to think
> through when you get JNI and Cocoa tangled together.
>
> Best of luck,
> Mike Swingler
> Apple Inc.
>
>


-- 
Steve Hannah
Web Lite Solutions Corp.