Say “OSGi” and Java is not very far behind, they have been married since the early days. When we started working on the specifications Java was our obvious partner, and OSGi’s parents were well acquainted which made the marriage quite convenient. We needed a portable and security sensitive environment and we were very smitten with Java. However, the world has moved on since then and many other interesting partners are popping up all the times. People tell me that the adoption of OSGi technology is often hindered by the overhead that is introduced by a Java Virtual Machine and its sometimes obese library (it was very slim when we started!). We should also not forget the enormous amount of legacy code available in a diverse range of languages that many companies are unable to port. So far we had to deny them the wonderful features that OSGi offers like modularization and (remote) management. Why not let our minds wander off a bit and see what options there are?

A very interesting trend at this moment is the efforts of many to port native environments to the Java VM. Last week at Oredev a Ruby expert told me that JRuby (the Java implementation of the interpreter) had a significant better thread model than Ruby itself. JRuby is getting awfully close to implement the full Ruby language, which could create a drive to make JRuby a preferred environment because it can painlessly integrate any efforts written in Java. A similar story can be told about Jython, a Java based implementation of Python.

Even PHP is possible; I am currently preparing a demonstration for the 7 December OSGi members only webinar. We will show standard PHP applications running on an OSGi framework. The PHP interpreter (Quercus, from the Resin web server) is completely written in Java and it was not hard to turn it into a bundle. I just needed an activator that tracks bundles with PHP pages and registers a servlet under the right namespace. It is really cool to see how you can now write a web site in PHP and deploy it to an OSGi framework as a bundle!

The Java VM misses a few instructions to implement dynamically typed languages efficiently, but there are discussions going on to add these instructions to the VM. VM based solutions remain almost all of the advantages of using Java because they use the same programming and security model. Using the Java VM as the common denominator is therefore a very nice model and I expect to see many examples of this model in the coming years.

The VM model still leaves out native applications, and there are some really cool native applications out there. The standard Java solution is JNI, which, well, ehh, sucks; JNI is extremely intrusive and pedantic. Porting a C application to run under a Java VM is a painful exercise. The alternative is to use some communication mechanism, like for example sockets, and communicate over this medium. Doable, but it is hard because it requires addressing mechanisms, marshalling (serializing) to communicate any parameters, and many more chores: see CORBA if you want to know how painful this can be.

One of the best features of the OSGi Framework is the service registry. The service registry really decouples bundles from each other. A bundle that needs to communicate with another bundle never directly addresses that other bundle but uses a shared service to communicate. A service is defined by the API it implements and a set of properties. Services are detected or found dynamically and then bound. The service registry arbitrates between providers and consumers and provides appropriate security and life cycle control.

The most elegant solution to the legacy and native problem is an implementation of the service registry in C. Most languages besides Java support a very easy integration with C libraries. On the PC and on Linux it is quite easy to directly call DLLs or shared libraries from most dynamic languages. Writing a service registry in C that has the same semantics as the OSGi service registry should not be rocket science. Using a fast communication medium like shared memory would minimize any overhead. Key problems are the garbage collection, leasing issues, and marshalling. You could optimize the registry for tightly coupled clusters, though the technology obviously enables more loosely coupled solutions.

There are of course many interesting questions remaining. Should the management of the bundles remain in Java, or should these aspects be moved to a C library as well, allowing full Java free implementations? Obviously Java will be the best supported environment for a long time to come, however, living apart together might not be a bad solution to satisfy the requirements that I am hearing more and more.

Peter Kriens

Last week I visited the OOPSLA in Portland to promote the OSGi. During that time I also visited many different sessions. Interestingly, only this week I started to see a trend in the conference, strangely enough not while I was there. Trends on OOPSLA are important; this is the conference where objects, patterns, aspects, and many other innovations were first discussed.

The trend is the focus on domain specific languages. We seem to be entering the time when Java is not the one size that fits all we something think it is. Interestingly, one of the key persons in the Java world (Guy Steele) had a presentation about Fortress, a language that is intended to replace Fortran. The syntax is highly optimized for mathematics. A key aspect is that the language should be readable by the domain experts. This means they have operator overloading because there are many mathematical operators that have formalized definitions. They allow the overloading of many Unicode characters, solving one of the problems with C++ where there were too few operators to work with.

However, there were many other presentations that address the language issue. A company called Intentional Software presented an editor that could display and edit the same abstract syntax tree in many different forms. This ranged from a mathematical expressions with all the nice looking formatting, to Java code, and all the way to the graphically display menu structure of a mobile phone. Again, the interesting aspect is that syntax does matter. But there was more. Another presentation told the story of a company that had 400 pages of requirements and domain knowledge. The estimate was that the system was roughly going to be 20.000 pages: a 50x increase in size. The presenter’s solution was to model the domain in a domain specific language and generate the system from the program written in that language. The expectation was that the system could be written in around 4000 pages of code. During the rest of the OOPSLA there were many more Domain Specific Language (DSL) presentations.

You see the shimmers of Domain Specific Languages in things like Ant and Maven. The XML files that parametrize Ant and Maven define a language. Unfortunately, they picked XML, which caused much of the clarity of a domain specific language to be lost in the sea of tags. Many developers have attempted to design domain specific languages using XML; the art of real language design seems lacking in today’s computer science classes. And it is so easy today with javacc, antlr, and other compiler compilers.

What does this mean for the OSGi service platform? The OSGi Service Platform is currently highly Java oriented, do we need other languages?

First there is already a domain specific language for Eclipse plugins called eScript, written as an example for the Eclipse FAQ book. Unfortunately it does not run as is on Eclipse 3.3, but it is an interesting approach. Instead of mucking around with MANIFEST.MF, plugin.xml, resources and Java code, it is all specified in one concise file. I think this approach is promising. An environment like Eclipse contains so much functionality, it would be very nice if one could tap into that functionality with a short script instead of all the work involved today.

I think the OSGi service platform is a great platform to provide the runtime for Domain Specific Languages. The OSGi provides a wonderful plumbing infrastructure for the generators that map the DSL programs. The nice thing about DSLs is that they only specify domain related issues and leave the plumbing and other chores to the environment. This implies that any overhead that the OSGi service platform requires can easily be created by the generators. This will make it very easy for people to write highly productive and specialized code while not being bothers with plumbing.

Look for DSL and you will find more than just modems. After a long time where very few languages were developed, I expect to see many domain languages to see the light in the coming years. I hope the Java community can embrace this opportunity by allowing these languages to run on the Java VMs and not oppose these innovations. Domain Specific Languages could be a great boon for our productivity, and could make the OSGi Service Platform more attractive to a larger audience.

     Peter Kriens