The observant may notice that there have been a rather significant drop in my post frequency over the last month or so. This is because I’ve managed to get a very nice job in the industry working in C#, Java, and things like Jasper Reports and Postgres, therefore I’ve been very busy. Also, When I did have time, I just couldn’t come with anything to write about that I could finish; the only thing I could think of was that ubiquituous generic ListView Sort Handler class but that would take a while to write-up again.

Then I thought, why not find something interesting in my work that I can safely talk about without breeching my confidentiality agreements? Easy enough. So I’ve gone with Mixed-Language concepts.

I have a book published in 1994, titled, “Mixed Language Programming” (ISBN 1-5581-332-9). My recollection of it’s content was that it speaks mostly of interoperation between Visual Basic, C/C++, Object Pascal, and even Word/WordBASIC. Even then the idea was pretty unique- to have a single goal be accomplished by more than one Program was on the very edge of what was considered sane- but to use two or more completely different Programming Environments was considered more trouble than it was worth.

Nowadays, interoperation is usually easier. Many sets of languages share the same application platform. For example .NET Languages all compile to CLR and need to support the Common Type System (CTS); they can use the Base Class Library as well as libraries written in other .NET languages, as long as they conform to the CTS. This means that integrating Visual Basic .NET, C#, F#, IronPython/IronRuby and similar .NET language implementations is relatively easy and more “first-class”.

The Java platform is another one that has a wealth of Development languages that run on it. The Virtual Machine and Run-time have taken a few different routes on the design path than .NET (Type Erasure comes to mind) but is still a useful platform. Scala, Java, Clojure, Groovy and Jython can create and consume standard Java libraries.

Fundamentally what has assisted the more common occurrence of Mixed Language Programming (or at least made it so mentioning it at a social gathering was no longer a social faux pas that caused the room to go quiet) Is these differnet platforms that not only make it easy but practically encourage it by making different languages have their own unique capabilities.

This does bring me however to the idea of [i]cross-language-platform[/i] Programming. In many ways we’ve simply expanded the barriers; In, say, 1994- Programming Languages and their compilers/interpreters were more or less proprietary and they had their own set of concepts. Some Programming languages called something an Overlay; others called it a module; others still referred to them as libraries. So you got a mixing of technical jargon. While most Programming languages compiled to the same Object Code Format, there were still considerations such as Name mangling that could make accessing and using that Object code as imports from another language difficult or even impossible. This is part of why it was typically not worth the hassle; Even if Language B made a certain task take half as much time, you would lose that advantage and fall behind time wise simply because of trying to have to figure out the specifics of your compiler and languages and how they would interact at the binary level. Now it is a question of how to move across platforms; for example, how do you communicate between a C# application and a Java application?

There has been quite a measure of success in this area. First, it was determined that the .NET runtime was almost entirely a superset of the Java run-time, so IKVM was born. IKVM is actually a Java runtime that runs on top of the .NET CLR. This might seem weird or pointless but in doing so you both eliminate the need for the Java runtime but you also gain the ability to more closely couple your .NET and Java logic to work together. Your C# Application can directly access the classes and properties of your Java Application.

However, for my case, our “problem” was more or less that we were using C# for the bulk of our work but it was decided (before I was around at any rate) to go with Jasper Reports to update the Reports. (I use Update because fundamentally it’s a move from an ancient system and codebase to a new, modernized one). I Did some experiments myself with trying to get Jasper reports to run as a .NET assembly and I imagine I could have got that working but there is something fundamentally- “untrustworthy” about doing so. I mean you are changing a rather full-featured library designed to run on the Java Platform and making it run on another, completely separate, platform. Even int he best case there is still the threat of problems. So I decided to take the easier route and simply write a Java wrapper application that could expose the required functionality to a C# Application by simply being called with Command-Line parameters. Of course this is the simplest way of Cross-language communication but it works fine in this case because there is no need to communicate with the launched Java application beyond the passed parameters. One issue that did appear is that the C# application could not easily pass arbitrary parameter types to the resulting report- such as Images or other element types. This resulted in some of that logic being moved directly into the Java Application since it does have direct access to Jasper to add parameters in whichever format it wants to.

The entire thing was actually pretty interesting. I hadn’t made a Java Swing Application for a rather long time and I learned a lot about that, even though I just needed one JFrame with one Report Viewer control. the C# Application that invokes it passed in parameters and information for filtering results, but it also is generic and used for multiple Jasper reports. The data about what inputs to provide and how they get passed to the Java application and subsequently passed as parameters to the report where they get used to control queries, is retrieved through XML files. Here I learned to use XDocument (conclusion: XDocument rules). The Filter application itself is designed to be invoked through the Command Line. This is something that I originally felt was a bit silly but it does make sense on the level of simplicity; Arguably, these components- which are never invoked on their own- could be made separate class libraries, but that would complicate testing, it would complicate deployment, and it would essentially add complication. Overall it was decided that if we limited the actual interface between the different portions to the Command Line, it would be easier to track down where the problem is. I’m still not 100% convinced but at least now I know there were some good reasons and a decision making process behind it.

There is a lot of mixing, because the older system is, well, older. It also uses different data formats and therefore there is interoperation there as well. Connecting to remote mainframe systems, grabbing indexed records created in BASIC, writing them to a Database which then get’s accessed with standard queries to recreate the functionality of the original in a modern environment.