Java::Import::Design 0.03

Java::Import::Design is the design of the Java::Import Module.

MOTIVATIONS

The original motivation for writing this module came out of a project I was working on during my previous employment. We had built a system in which a major part was implimented using EJBs on a J2EE server. In addition, we had a large component of the system, that already existed, and was written in Perl. We did not want to scrap our Perl work but it was becoming more tedious to maintain two implimentations as more and more things were being added to the system.

So, we decided that the major pieces of business logic would reside on the J2EE server and the Perl would be modified to make calls to the server. After some time and experimentation we began to realize that the memory footprint as well as the amount of time needed to make calls to the server using existing Perl to Java integration sulutions were just not acceptable. We therefore set out to find some other way. We tried all sorts of things but in the end we couldnt find anything that met our requirements and therefore decided to keep the origional system of doing things.

While at that job we never did find a suitable way to integrate our two systems. However, the problem still haunted me. It wasnt until the end of my career at that company that I saw an announcement for Googles first Summer of Code. It just so happened that as Google was announcing their brand new program that I had begun to play with the GNU GCJ suite of Java tools and came up with the idea of taking advantage of their ability to natively compile Java code for use with Perl. This may not have been a new idea but I couldnt find anything that would help me so I decided to write and submit a proposal to Google. Well, I was accepted and you now have Java::Import.

When I began to work on this project I started by creating my own namespace instead of stepping on the toes of the other existing Java/Perl integration project, Inline::Java. I did this primarily because I wanted a clean slate on which I could fully explore the nuances of GCJ, in particular its CNI interface. As I worked my module started to evolve into its own beast and at that point it seemed locigal to keep my own namespace. It is not my intention to replace Inline::Java and I still think that in te future much of the work I have done can be used by Inline::Java as an option to use GCJ specific functionality.