From: Arno P. <ar...@pu...> - 2009-10-19 05:49:27
|
OK. I'm finally back online again... 2009/10/14 Panayotis Katsaloulis <pan...@pa...> > ( Right now I am writing a tool to automatically create skeleton files > from java files to objective-c files, so that creating the native part > from the java library to be as easy as possible) > This interests me. Right now it takes a lot of effort to write both the Java and Objective-C wrapper. I have been musing for some time about a way to automate this process as much as possible. If I understand you correctly, you want to generate the ObjC file from the Java wrappers? I think the problem is more complicated and deserves more thinking. ObjC has great reflection mechanisms. It is possible to "traverse" the Cocoa (binary) libraries and extract all required signature information (I believe that is how the free gcc toolchain guys generate the .h files that an application needs to #import). Ideally, I would like to do the same to create both the XMLVM-specific ObjC wrappers as well as skeletons for Java. The libraries that come with the iPhone SDK would serve as input to our XMLVM-wrapper-skeleton generator. There are several issues that come immediately to mind: - the Java skeletons would be manually edited with implementation for our Java emulator (of course, only if one wanted to continue the XMLVM-specific iPhone emulator written in Java). Here we have the typical problem of code generation tools where the output needs to be manually edited: update cycles become tricky (if you re-generate the Java code you might overwrite the hand-written part from the previous iteration). - things get even trickier when you consider the ObjC wrapper. While for most parts these wrappers are fairly "symmetric", there are numerous exceptions: for memory management, value types (structs), C-functions, pointer-to-pointer to mimic call-by-reference, just to name a few that come immediately to mind. I don't think such a wrapper-generator can do its work completely autonomous. What might be required is some kind of "meta-mapping file" that gives hints to this wrapper-generator (i.e., how to map ObjC signatures to Java). I would love to move in that direction. It would remove the error prone process of hand-coding all wrappers and skeletons and we have a realistic chance not to loose the battle with new SDK versions. But I don't believe that a "drive-by-coding" solution will be sufficient. Anyone interested to discuss this problem? In particular those who know ObjC well? Arno |