Now that I'm back being an engineer/architect, I'm again thinking of too many projects that I want to do with the time I have. I'm getting involved in the Target Communication Framework (TCF) which has an exciting opportunity to standardize target (in this case mainly embedded targets) communication and services for the purposes of debug and data collection amongst other things.
I am also trying to make it easier to use CDT for specific platforms. Windows and Android and soon Qt are the main ones there. But I've run into problems with the complexity of CDT's build system that I need work with the community to clean up.
And there is another shiny object has caught my attention and I'd love to get time on that too. Our long term holy grail on the CDT has been to support developing native libraries for Java. The debug scenarios are scary, but I've been thinking of another area that should be a lot more attainable.
That's automating the creation of the code that JNI development requires. There's two paths. One is generating skeletal C code for Java native methods. And the other is generating wrapper Java classes for C++ classes. There used to be commercial products that did that, but I'm not sure if they're still around. And given the power of the Java and C++ parsers we have in Eclipse, and the code generation frameworks available, it shouldn't be that hard, you would think.
I think this would be a huge benefit to JNI developers, or at least me :). The interesting thing to note is that Android had the foresight to use JNI for their native interface so there's a new community who could use it. If anyone is interested in doing something like this, give me or the cdt-dev list a ping.
What do you think about SWIG (www.swig.org)? As for me, I used it in commercial products and have been delighted.
ReplyDeleteDoug might want to revisit the work that was initially started as a GSOC project about 3 years ago.
ReplyDeletehttp://eclipse-soc-mariot.blogspot.com/
Don't know if the guy is still active but it would be nice to see this working. Especially with Android development on the rise.
SWIG is probably the obvious choice when creating Java-wrappers for C/C++, although my experience with SWIG is that even though SWIG goes to great length to generate usable wrappers, the generated Java classes have a distinct taste of C++.
ReplyDeleteCan't you draw from the SWT for this? We're mainly generating stub code around OS calls, but the PI generation on platforms other than OS X seems very close to what you're describing.
ReplyDeleteDid you consider JNA (java native access)?
ReplyDeleteHere I gave some information on what I did. There is 2 parts in the current code :
ReplyDelete- The first one is a debug configuration which attaches GDB to the current JVM process I think this part is quite easy to adapt to current CDT version and help to debug JNI code.
- The second part is the seamless debugging "simulation" with invisible breakpoints and threads management. This part needs some work to be usable with all JVM implementations and playing with threads is may be not the best solution to achieve seamless debugging.
I have never used JNI again after I discovered JNA (and Com4J). Makes writing Java programs that use external libraries a smooth experience.
ReplyDeleteI haven't tried JNA, but Android uses JNI and I'd love to see progress on the JNI front.
ReplyDeleteTry Jace.
ReplyDeleteThis cavalcade is adapted from what I apprehend on best blog. And it acquire so abounding admired things to learn. So i would like to accede for creating this arresting blog.
ReplyDeleteAndroid developer