JNI wrapper for NSSavePanel

[Steve Hannah]

This is not a valid C function based on the return type - in the case where
> an error occurs, the return value of this function is undefined and will
> likely be whatever garbage is left on the stack (isn't Xcode
> warning/erroring about this like crazy???). You need a "return NULL;" at
> the very end so that the JNI return value will be defined in the case where
> you don't make it to the first return.
>
> Thanks for the tip, I'll add the null return and see if that helps.  (No
Xcode didn't complain... no warnings, no errors, "build succeeded").

>
> Are you sure the library is even getting built and loaded? Can you make a
> plain JNI function next to this one that contains nothing but a simple
> "fprintf(stderr, "test\n");" in it? Call that first, and see if the library
> is even loaded.
>
> Yes.  The library is getting built and loaded.  I have 2 other JNI methods
that are working properly  (but only if I don't wrap them in
JNF_COCOA_ENTER/EXIT).  In my java logging I output the string result of
another one of the methods just before calling this one and it outputs fine.


> 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 (?).
>
>
> It may be getting hauled in by Java 7 itself, and not explicitly linked.
> If you don't have the JavaNativeFounation.framework explicitly linked in
> the target that builds your library, that would also cause the compiler to
> infer that the JNF_COCOA_ENTER/EXIT macros are actually functions, and
> treat them as undeclared/unlinked entities.
>
> Run otool -L on your library, and make sure the full path to
> JavaNativeFoundation.framework is printed out. If it isn't, you are only
> picking up the symbols inside of it by accident.
>

Thanks... I'll try that.

Best regards

Steve


>
> Regards,
> Mike Swingler
> Apple Inc.
>
> 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.
>
>
>


-- 
Steve Hannah
Web Lite Solutions Corp.