On Aug 19, 2006, at 5:14 PM, Andrew Thompson wrote:
On Aug 18, 2006, at 6:35 PM, Michael Hall wrote:
4). In particular considering what I had done more recently in
trying to automatically generate directly from the Framework/API
header files to the jnilib. Eliminating the JNIDirect runtime
dependancy on gcc. Those efforts initially mostly directed at
Cocoa and it's frameworks. This you might remember is how we are
told JDirect used to work more less, based off the universal
headers, I don't claim it as an original idea.
Of course wheels can always be re-invented. It might be
interesting to see what might be created from scratch. I have a
little too much effort tied up in this.
It's always struck me that Java and Objective C are both very
dynamic languages. Java has Reflection and Objective C is all based
on a few C functions for sending messages (not to mention things
like NSInvocation)
It occurred to me that all one might really need to do is generate
(or type in!) Java interfaces for any given Objective C class. Then
one could use reflection and Java's java.lang.reflect.Proxy
class... something like this.
//Java 5 syntax - of course, you'd wrap up all this plumbing in a
nice library
int pointer = Something.createObject(...);
NSWhatever objCinstance = Proxy.newInstance
(NSWhatever.class.getClassLoader(), NSWhatever.class, new
ObjCInvocationHandler(pointer));
objCinstance.init();
...
Proxy has been recommended before but I'm not quite sure why you need
it here.
class ObjectiveCInvocationHandler() implements InvocationHandler {
private final int instancePointer;
public ObjectiveCInvocationHandler(final int instancePointer) {
this.instancePointer = instancePointer;
}
public Object invoke(Object proxy,
Method method,
Object[] args)
throws Throwable {
... what goes here is non trivial, but also not rocket
science...?
you just need a JNI bridge to Objective C's NSInvocation or
to objc_msgSend itself?
}
What Patrick had originally laid out for Cocoa is pretty much still
the basis for what I have. Use the Cocoa runtime methods. So there is
a root class.
ObjectiveCObject which includes the invocations to objc_msgSend such
as...
protected static native int objc_msgSend(int self, int op);
protected static native int objc_msgSend(int self, int op, int
arg1);
Of course every Cocoa class that comes up with a unique oddball
series of parameters gets its own overloaded method in
ObjectiveCObject, so that starts getting to be quite a few when you
start supporting a large number of Cocoa classes.
But then everything subclasses off of that, so if another class adds
the same oddball signature in the future no changes to
ObectiveCObject would be needed.
So for example things go...
ObjectiveCObject
NSObject
NSAppleScript
NSObject in this design actually doesn't actually add much value that
I remember but is I think to be expected in the Cocoa class hierarchy.
In extending things out I ended up for some reason with a lot of
package private that I thought was sort of awkward in working with
from example classes.
The jnilib generator from header files part started getting into
things like Cocoa interfaces for one class popping up in the header
file for a different class. All of a sudden I had to think about
keeping everything in memory until I had parsed _everything_. Then
there started to be dependancies on non-Cocoa frameworks. So now I
not only had to figure out how to accurately and completely parse
Cocoa header files I also had to consider normal 'C' header files in
the mix. If I could of got through it of course that would I think
considerably increase the value of the tool. If you could basically
rip a JNI interface to any C or ObjectiveC code you might have
something useful.
Of course, there's a thousand other details to worry about -
marshalling parameters, reference counting, garbage collection.
But I always figured doing it this way avoids the tedious
generation of code for every single objective C class... well,
you'd want to generate a Java interface for the class, but you
wouldn't need a body.
Just a thought... may or may not work in practice.
Yes there are many things I hadn't even start thinking about
addressing. I think Apple was still struggling with issues like the
different memory management techniques. So it started seeming like a
whole lot of work. I hadn't had one person indicate an interest in
the project. Not to mention anyone offer to help or show a desire to
use part of it. Pretty much why I finally sort of shelved it myself.
My approach was to try and do as much as possible automatically, even
then the effort seemed like a whole lot of work. Anyone starting an
open source project for this might want to give some up front thought
to how much work whatever approach they take will actually be.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
