JNI wrapper for NSSavePanel

[Mike Swingler]

On Oct 6, 2012, at 5:05 PM, Steve Hannah <steve at weblite.ca> wrote:

> On Sat, Oct 6, 2012 at 4:06 PM, Mike Swingler <swingler at apple.com> wrote:
> On Oct 6, 2012, at 3:11 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> > On Oct 6, 2012, at 4:08 PM, Steve Hannah wrote:
> >
> >> I have posted source for both versions of the method at
> >> https://gist.github.com/3846116.
> >
> > How about throwing a retain on path and see if it makes a difference?
> 
> The "path" is not an Obj-C object, it's a JNI jstring pointer, you can't retain it.
> 
> I'd actually recommend using JNFNSToJavaString(), instead of manually fetching out the UTF8String and then using the raw JNI.
> Thanks.  I planned to make that change once I got JNF_COCOA_ENTER/EXIT working. 

Are you building/running the app from Xcode? You could try setting a breakpoint to inspect the local state.

> 
> 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.