October 2nd, 2012

by Ivan St. Ivanov

It’s day one of JavaOne. And it was the most controversial day in my conference attending career. Initially I thought it was the BOF day as my schedule builder didn’t give me a single conference talk. And it seemed to me very strange for the biggest Java conference: day one without a conference session. But… it is what it is, I thought. Well, early in the afternoon I realized that it is not the BOF day, but rather the day of my disappointment with the schedule builder tool. Or maybe it was the day when I was too stupid…

The situation at JavaOne is that if you want to attend a talk, you have to pre-register in an online tool, called schedule builder. Otherwise you have to wait and see whether there are places left. This tool is also the easiest one to use, if you want to see what the parallel running sessions are across the various buildings where JavaOne is held. And for today my schedule builder gave me about two or three slots of 3-4 talks each and tons of BirdOfaFeather sessions (BOFs) afterwards. And I usually don’t go to BOFs as these I believe are for the experts in a certain topics.

But how surprised I was when I saw people tweeting about visiting sessions that I never found in my agenda! Unfortunately it was already too late – these talks were already over by the time I checked twitter.

Advice to self: always read the printed leaflet and don’t rely on technology… 🙁

Anyway, at the end I think it was not a lost day for me. But read on…

OSGi and Java EE

One of the two conference sessions that I attended today was on a topic that I always want to give a chance, but soon afterwards disappoints me: OSGi. It was given by Bert Ertman and Paul Bakker. They presented themselves as having a lot of experience with developing and maintaining applications in the cloud. I know Paul also as contributor to JBoss Forge. There we had lively discussion last week about basing the tool on OSGi or not.

Bert started with a short introduction to the challenges that modern applications have: maintainability, zero downtime and ability for easy customization. The answer to all these is modularity. If you make your application modular, then you don’t need to stop the whole of it in order to apply bug fixes or new features. You can bring in new features or customization in certain parts and still be sure that your app is still running correctly. However, if you just use standard Java, you have some issues to achieve that:

  • You may try to follow the loose coupling and high cohesion principles by providing interfaces that your clients should code to, but nobody is preventing them to use your implementation classes instead
  • If your application consists of tens or hundreds jars, you enter the classpath hell world: you need to make sure that all of them are in your classpath with the correct versions
  • Solutions like Jigsaw may try to solve the above problems, but they do not suggest anything in the area of dynamically updating the modules at runtime. And the enterprises will start using Jigsaw productively probably in more than five years

So the solution to all these issues according to the speakers is OSGi. OSGi is not modularity, they stated. Modularity should be our key principle when designing software and OSGi is the only viable solution at the moment which can help us achieve it.

Then it was time for the demo. I have watched Bert and Paul speaking at several other occasions and what I like about them is that they always start with a clean sheet and build their demo app from scratch. No hidden steps, no previously prepared code, everything is live!

As most people think OSGi is hard because of the many things that you have to configure, Paul introduced us bndtools – an Eclipse plugin that does the dirty job of creating jars and writing configuration files for us. What I found good about it was that inside one Eclipse project you could build several OSGi bundles, each in its own jar file. bndtools handles that with a special configuration file, where you state which classes (or rather packages) you want in every particular bundle. Without the mentioned plugin you had to create one project per bundle and imagine the picture for relatively large application: 50 projects with 10-15 classes each. bndtools requires that you have a repository with the jars that you plan to use as your external dependencies. This may be a directory on your local machine, remote location and both.

And here comes one of the biggest problems I see with OSGi: what if the jar I am using is not in that repository? Most probably I should download it from somewhere else. If I don’t have luck and the jar is lacking OSGi artifacts, I have to put the manifest with the exported packages inside and store it somewhere locally. And if this is part of a continuous integration build, I should think of an automated routine that does it for me. And I don’t want to think about the situation when there are transitive dependencies, which are not part of my repositories. To conclude this: the fact that you need these small OSGi artifacts in your libraries creates more trouble than the issues OSGi solves.

The way to do dependency injection in the approach proposed by Paul was actually the service registry pattern. It is considered as anti pattern in some of the latest papers on test driven development, but the way Paul did it was really clean – all the registration of service implementations and their look up was isolated in special activator classes that you usually don’t test. These activators are pretty much like the standard OSGi activators, but are a little bit more high level. They are implemented in the Felix dependency manager library, which plays the role of the bean manager in CDI. It makes sure that you don’t have plumbing code in your business logic – it does all the dependency injection handling for you. And it also tries to avoid NullPointerException when your dependency is not available yet. I think, however, that the way you declare all these injections or exports is a bit tedious. I like more CDI: everything is declared inside the class that needs it with appropriate annotations and not in a separate location. Paul, however, mentioned that there is such thing for OSGi too, but he preferred this approach.

The second part of the demo was dedicated to Java EE and OSGi integration. There are three ways to achieve that:

  • OSGi is the core of the server, the different Java EE APIs are exposed as services, but the applications deployed do not know about the presence of OSGi . This is the way most present application servers (for example Glassfish) are implemented
  • Hybrid solution: the bundle context is injected as a resource to the applications and they locate the various Java EE APIs through it. This is the least recommended approach according to the speakers
  • OSGi a la carte: you import just the APIs that you need as bundles on top of an OSGi runtime

The last option was demoed. It can be applied in the cases, when you don’t really need the whole Java EE stack. Suppose your application uses MongoDB (and not relational database/JPA) as persistence, client side JavaScript (and not JSF) as presentation technology and just RESTful web services. In this case it is more proper to just take the libraries that you need packaged as OSGi bundles and import them into your runtime.

Project Nashorn

Project Nashorn’s main idea is to implement a JavaScript engine on the JVM. So that you can write and run JavaScript code inside the virtual machine taking advantages of all the optimizations that the HotSpot compiler does for you. Besides Oracle there are other companies and communities that contribute to the project: IBM, NetBeans, Twitter and Red Hat.

You can run JavaScript code both on the command line, inside Java code (using javax.script.ScriptEngineManager to evaluate it) or as a script file. The basic features of the project are:

  • JavaScript objects and arrays have internal representation in the JVM
  • Functions are implemented with method handles (which means that they use invokedynamic and Java 7)
  • String, Boolean and Number have native representations
  • Object properties are implemented as JavaBeans getter and setter methods
  • It’s possible to extend existing Java classes
  • You can handle Java exceptions inside JavaScript cde

At the end there was a quick demo on some of the features of the project, but to be honest, I didn’t get much of it as it implied more JavaScript and Java script engine knowledge from the audience.


So, now time for the cool part of the day [and the night]. After this presentation I finally met the Forge project lead Lincoln Baxter III. He then took me to a Red Hat gathering, where I met Arquillian’s Aslak Knutsen, Karel Piwko and Andrew Lee Rubinger, CDI’s Pete Muir, Snowdrop’s Marius Bogoevici, Errai’s Christian Sadilek, RichFaces’ Brian Lеathеm and some other cool folks. I shared with Lincoln my fears about basing Forge on OSGi, I asked him about the plans and outlooks for 2.0 and some other stuff. Then I discussed with Aslak my ideas about integration testing with Arquillian the tool that we develop in my team at SAP. We then talked with him and Andrew about their new book. The reason that I write about all this is that this is one of the main points of a conference: networking. You follow on twitter, read the blogs and activities of different projects throughout the whole year. However, once or twice you catch the important people, drink a beer or two with them and share your questions, proposals and anything you like.

The climax of the evening was the JavaPosse’s unofficial JavaOne party, held at Kate O’Brian’s Irish pub. To be honest I expected more podcast listeners to show up. But anyway it was real fun for me to catch Dick, Tor and Carl and to share with them how much they inspired me to keep exploring and learning more and more. Thank you guys and keep on the good job you do for our community.