News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

Integration Watch: Java to C: No mean feat




September 15, 2008 — 

A few weeks ago, a client contacted me to see whether I would be interested in working on a project to convert a 150,000-line Java codebase to C. Before responding, I decided to see what tools were available. Given the nearly infinite variety of open-source projects and the fact that C and Java dominate OSS projects, I figured there would be the usual wealth of tool choices available to automate the conversion.

To my amazement, I discovered only a few resources—and those were mostly abandoned or dying projects; one-off commercial tools on rarely updated Web sites; and, in the case of GNU GCJ, a product that supports only Java 1.2. There’s no good, comprehensive solution. So, how to proceed?

One possible approach is to convert code semi-automatically: Put some pieces in place, use a set of filters (in AWK or Perl) to partially convert the Java, then finish the job by hand. The pieces you’d have to put in place are substantial but not overwhelming: A garbage collector (I’d use the Boehm-Demers-Weiser), implementation of basic Java classes (such as String, some collections and some File classes) to which new classes are added as needed and, finally, some kind of object model. The latter requirement is challenging; creating one from scratch requires lots of careful thinking.

One solution is to use the GObject model from Glib (part of the Gnome open-source project), which is written in C. This would solve the problem of an object model, but it’s an unforgiving path. First of all, it requires a long learning curve and a lot of boilerplate code. Second, it means you have to ship some of the Gnome libraries with your product. Gnome is a great project for Linux, but its support for other platforms, especially Windows, is weak.

The Vala project in Gnome seeks to produce a simple OO language that compiles to C and uses Glib. This would be an almost ideal solution, were it not for the fragility of the project, which is still early in its development cycle and, once again, is unfriendly to platforms other than Linux. Essentially, if you choose the source code translation path, you’ll need to write your own object model and develop your own quasi-OO syntax to match the Java you’re working with.

Another approach, I believe, is more likely to work: Start not from the Java source, but from the Java bytecodes.

Interestingly, there are ways to convert C code without having to emulate JVM operations. One is to translate the bytecodes back into a simple, declarative language from which C statements can be generated. A package that does this translation is Soot, from McGill University in Canada. Soot, which is open source, was originally designed as a framework for optimizing bytecodes. One of its byproducts was the ability to translate those bytecodes into a variety of easily parsed formats.

The conversion to compilable C that faithfully replicates the Java functionality is nontrivial. Part of the problem is that some data is lost when the Java compiler, javac, creates bytecodes (for example, enums are enforced by javac, but the type data is not passed to the bytecodes). Another issue is the lack of symmetry between Java’s assembly-level constructs and C. In a thesis on the topic, one student lists many of the issues, ranging from the prosaic, such as name length (C can require that names be disambiguated in the first 63 characters), to the seemingly intractable, such as C’s lack of reflection and its vastly different security model. To be fair, such problems are not unique to this approach; they would have to be solved in a source-level port as well.

The JC compiler claims to have solved most of these problems. But the project has been suspended since 2005, and even then it had specific requirements. Nevertheless, it did manage, per its docs, to automate C to Java conversion.

Working from binaries has one compelling advantage: It is inherently automatable, so that changes to the original Java codebase simply require a new build (whereas for a source port, each change to the Java side entails painstaking reconstruction in C). Had I accepted the project, I would have exhausted binary before going to source migration.

This lack of conversion tools is unlikely to improve. Java is very fast today, so performance is no longer a big driver to convert to C. And since the Java Native Interface works well, native-to-Java communication is no driver either.

The project I was looking at, however, was a Java library; and for that, you do need to convert. But you’ll have to go it alone.

Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.



Related Search Term(s): Javaopen sourcesoftware development


Share this link: http://www.sdtimes.com/link/32821
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading