Tuesday, October 23, 2007

What language to choose for Harmony GC development?

During Harmony GC development starting from GCv5, I made a design decision that we should try to keep the programming language "C" compatible. Although GCv5 uses certain C++ style, e.g., the source file names are using cpp suffix, we tried to avoid any C++ specific things.

The reasons I chose C for GCv5 development are:

1. We want GCv5 to control all its own memory, i.e., there is no hidden memory management brought in by the language. Writing GC in C++ doesn’t cause serious problem in this issue, but the problem is obvious when writing GC in Java, where there are lots of hidden objects allocated.

2. We try to keep GCv5’s capability for other runtimes written in C, which is common in open source community, such as Linux kernel, gcj, Ruby, etc. We expect one day GCv5 can be applied to some of them, although I don’t know when it will. We had successfully ported a version of GC to Ruby 1.9 last year.

3. We want to make GCv5 self-sufficient with all its own encapsulated utils, so that it can be easily ported to other languages if we want. For example, this design makes it very easy to write GC Runtime Helpers in Java. (I will talk about the runtime helpers later.)

4. In the early stage of GCv5 development, I used some C++ data structures such as linked list, vector, etc., then I removed them gradually, because we want to have delicate control on synchronous accesses to the data structures, such as sync-queue, sync-list, etc.

The arguments above are not strong enough though. I have to say it’s also kind of perfectionism. :)

Monday, October 15, 2007

Debugger for Java*/JNI Environments

Everybody who writes Java*/Native applications faces debugging problem. It is really difficult to write large applications since one have to use at least 2 debuggers to debug the program. One have to start application from Java* debugger and attach to the process with native one and switch between them during debugging process [1]. Until now!

The good news is Intel released integrated debugger for Java*/JNI environments. It allows to easily debug mixed mode application and pretty easy to install since is implemented as plug-in for Eclipse platform. Mixed mode debugger needs NCAI (Native Call Access Support) implementation in VM which is an expansion of JVMTI interface. Currently the only VM supporting this interface is Apache Harmony VM.

The debugger has pretty straight forward installation guide and intuitive interface. It’s a great step to make Java* easier to use with native libraries.














[1] There is number of links dedicated to the problem:
http://www.velocityreviews.com/forums/t152740-jni-debugger.html,
http://www.kineteksystems.com/white-papers/mixedjavaandc.html,
http://www-128.ibm.com/developerworks/java/library/j-jnidebug/index.html,
http://forum.java.sun.com/thread.jspa?threadID=670308&tstart=90.

Saturday, October 13, 2007

EIOffice with Harmony

It's a good news to Apache Harmony community that, a developer testing version (v0.02) of "EIOffice with Harmony" bundle was released on sourceforge at http://sourceforge.net/projects/eio-harmony/.

EIOffice is an office suite written in pure Java based on Java swing. It has complete functionalities for document processing, presentation creation, and spreadsheet generation. EIOffice is developed by Evermore Software Co., a company locating in Wuxi city, Jiangsu province of China. EIOffice is the abbreviation of "Evermore Integrated Office", so sometimes it's called EIO as well. It's "integrated" because it is a single application that support all the three types of office documents processing (document, presentation and spreadsheet). The data can be "linked" between them, such as from a spreadsheet into a report presentation. One an update is made to one site, all its linked sites will be updated accordingly and automatically.

The real appealing feature of EIOffice to a software developer is, it's written in pure Java, but there is no obvious performance issue in my using experience. And the memory footprint is acceptable (or surprisingly lower than expected).

To make EIOffice to work with Harmony is a serious exercise on Harmony graphics classlib support (swing/awt/Java2D). It's said EIOffice the world-largest single (desktop) application written in Java. Once Harmony can run all its functionalities smoothly, that probably means Harmony is ready for any Java desktop applications. The current bundle is version 0.02. It's still a long way to go, but considering the fast progress of Apache Harmony development, I believe a version 1.0 could be expected in a couple of quarters.