Re: [xmlvm-users] java.awt.Color and family

[Arno P. <ar...@pu...>]

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