Re: XCode JNI project

Thanks for the detailed info Mike. Changing the C file to an M file did the trick. I'm not sure why it was causing build issues previously. I've found XCode to be somewhat volatile.

I'm using the JSheets project as my guide, which takes into account all the thread safety items you mentioned.

I've got to the point now where I can create a JFrame in Java, then pass that through JNI to an Object-C function where I can get the corresponding NSWindow. I can do things like [myWindow title], but for some reason [myWindow showResizeIndicator:YES] doesn't seem to work. I've got some more digging to do!

Thanks again Mike,

-Ken

On Sep 27, 2008, at 2:44 PM, Mike Swingler wrote:

You should probably turn the .c file into a .m file, because you won't be able to include any of the Cocoa headers in a C file. Java will be able to find the C function symbols fine, as long as they have the proper export statements in front of them.

Since you are calling into Cocoa from Java, there are a number of things you should be aware of:

1) To call most of AppKit safely, you should -performSelectorOnMainThread, because the thread from Java you are coming in from is almost certainly not Thread 0, which is reserved for AppKit's run loop. See http://developer.apple.com/technotes/tn2005/tn2147.html for more detail on these issues.

2) If you are using thread safe Foundation classes, and making Obj-C message sends from a thread that originated in Java, you will need an autorelease pool setup to clean up objects expecting to be deallocated by a run loop's autorelease pool.

3) To be completely pedantic, you should also wrap your calls into Cocoa with @try/@catch blocks to prevent an Objective-C exception throw from completely blowing though a bunch of HotSpot stack frames and bringing your app to unceremonious ending.

To help with these issues (at least internally) we have created the JavaNativeFoundation.framework inside of /System/Library/Frameworks/JavaVM.framework/Frameworks. Now, this is not officially API (yet), but you can use this as a reference on how to handle the JNI entry and exit points the same way we do inside of Java runtime. Check out the sections around JNF_COCOA_ENTER() and JNF_COCOA_EXIT() to get a feel for how to structure these checks.

Best of luck (your going to need it writing JNI),

Mike Swingler

Java Runtime Engineer

Apple Inc.

On Sep 27, 2008, at 10:13 AM, Ken Orr wrote:

Thanks for the suggestions guys - all have helped with my understanding of the situation. Here's what I have now:

1) A C file with an auto generated header file (auto-generated from the corresponding Java class's methods marked "native - not exactly sure how this happens)

2) An Objective-C M file, which will have my Cocoa calls

3) I've added the Cocoa.Framework under Targets->JNILib->Link Binary With Library by right clicking it and adding the framework under "Linked Libraries".

Everything builds fine until I include the Objective-C's header file my C file. When i include the header, I get all sorts of errors (see attached screen shot).

Any thoughts?

<errors.jpg>

On Sep 27, 2008, at 11:00 AM, Alexei Svitkine wrote:

Have two files. A .m file that does what you want, and exposes that as a C function. And the C file that just calls that function.

-Alexei

On Sat, Sep 27, 2008 at 10:05 AM, Michael Hall <email@hidden> wrote:

On Sep 27, 2008, at 8:41 AM, Ken Orr wrote:

C file via "import <Cocoa/Cocoa.h>

First you wouldn't include that in a C '.c' file, it would have to be an Objective-C '.m' file. A '.c' file will imply a straight 'C' compile and the compiler won't know how to handle the Objective-C specific syntax it runs into in the Cocoa.h file. This should get real errors, not warnings, and should not in any way succeed - so maybe this isn't what you mean?

<ATT00001.txt>