Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Re: Mac port: Status Update

On second thought, that didn't come out right. NSSelector, similar to a Smalltalk selector or a java.lang.reflect.Method object that can be called on any arbitrary class, is the way that events are handled in Cocoa.. That's probably going to involve a performance hit.

But the actual Java Bridge is a framework that can generate a proxy / JNI stub combo based on a mapping specification... And I believe most of Cocoa is mapped in this way. It's pretty sophisticated stuff, but it's marked as "legacy" in Apple's documentation, and I don't believe the new Project Builder allows you to create a "Java Wrapper project"...

http://developer.apple.com/techpubs/macosx/Cocoa/ProgrammingTopics/JavaBridge/JavaBridge.html

Stu


On Tuesday, December 11, 2001, at 01:29 PM, Mike_Wilson@xxxxxxx wrote:

Wow! It really uses reflect? That can't be good for performance.

McQ.




> Besides, going through all the voodoo to get the Obj-C code to talk to
> Java
> through JNI (and do it better than Apple can) would take a pretty large
> undertaking that would offset any gains we get by using the Cocoa API's.

The major difference is that the JavaBridge is primarily dynamic code,
i.e. it's generated through a mapping declaration (from what I
understand).  So it leverages reflection most of the time.  And it's
two-way.   A JNI mapping would be just a static wrapper around the ObjC
classes with some hooks for doing NSNotificationCenter and NSEvent
callbacks.




Back to the top