Together with an old friend I started a new technical blog, called teamzone. I will shutdown this blog and will post from now on at teamzone.ch. Don’t worry, all existing Blog entries are moved to the new place and will not be lost.

Please update your RSS Feed to http://teamzone.ch/feed/.

My private blog still exists at  http://stefanjaeger.ch/.

Today, I encountered a very helpful feature in Eclipse. When I am debugging code, I sometimes want to know, what’s the result of a method is. If the result it’s not assigned to a variable, it gets complicated. Take a look to this example: what is the result of add(17,19)?

public class DemoApplication {
 
    public static void main(String[] args) throws Exception {
        DemoApplication calc = new DemoApplication();
        System.out.println(calc.divide(calc.add(17, 19), 2));
    }
 
    public int add(int i, int j) {
        return i + j;
    }
 
    public int divide(int i, int j) {
        return i / j;
    }
}

In earlier times, I stepped one step further to get into the method divide. Then I got the result of add(17,19) in my parameter.

But Eclipse is offering a better solution. In the Debugging Perspective, there is a view called Expressions. Just add a new expression add(17,19) and the Debugger is printing out the result.

The result is directly printed out:

A simple, but helpful feature in Eclipse!

There was a time, OSGi was for me just an “not understandable” abbreviation. Wiki told me, that OSGi is a framework for a dynamic component model. Huh? Is it just a specification or is it an implementation? Didn’t understand it all.

I started about two months with working a little bit with OSGi. I want to write here these parts, which were unclear for me at the beginning. It should be an introduction for everyone, who has never heard about OSGi.

Okay, let’s start.

The setup of OSGi is something like EJB.

1. EJB has a specification from Sun.
2. OSGi has specification from the OSGi Alliance.
3. EJB need’s an application server as a platform (Weblogic, Glassfish, Websphere, JBoss, and so on) to run an “EJB” application.
4. OSGi need’s also a platform to run “OSGi” application. Like an application server, which is implementing the EJB contract, an OSGi platform implements the OSGi framework specification. Currently, there some OSGi implementation out there. The most known are Equinox, Apache Felix or Knopflerfish.

Okay, now, we know, how OSGi is built. But what does it? In one sentence, it is something like a JVM with some extra features. OSGi extends the JVM and a Java program is running on that OSGi Platform instead of running directly on the JVM. OSGi offers some advantages, which I will mention shortly.

 
(Source: http://de.wikipedia.org/wiki/OSGi)

 
The difference between a usual Java program (a JAR file) and an OSGi program (let us call that a bundle) are some information in the META-INF\MANIFEST.MF file. These information looks like:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Example OSGi bundle
Bundle-SymbolicName: ch.stefanjaeger.osgi.example
Bundle-Version: 1.0.0

That’s it. An OSGi program (called a bundle) is nothing more than a JAR file with the MANIFEST.MF. Now, you can run this bundle in an OSGi environment like Equinox or Apache Felix.

Okay, know, we come to the advantages of OSGi. The biggest advantage is the ability to run a bundle in different versions at the same time. For example, bundle A has a dependency to bundle B in version 1.0.0 and bundle C has a dependency to bundle B in version 1.1.0.

With the usual JVM, you get a problem when running A and C in the same VM. The JVM will take the first “B” in the classpath it found. This means, it is possible, that for C gets the files from B in version 1.0.0 (instead of 1.1.0), which could result in “MethodNotFoundException” and such stuff.

With OSGi, this problem doesn’t exists anymore. In the MANIFST.MF you can define all dependencies explicitly with the version. Following example means, that our bundle has a dependency to the Apache Commons Lang Package in version between 2.0.0 and 2.1.0.

Require-Bundle: org.apache.commons.lang;bundle-version="[2.0.0,2.1.0]"

The OSGi platform checks at the beginning, that all required bundles are available and solves the classpath problem for us.

Okay, we’re almost finished. There is one important point I want to mention. Packages are not “open” as usual in JAR files. If we want to make some classes accessible for other bundles, we do have to export these packages:

Export-Package: ch.stefanjaeger.communiction.interfaces

Of course, OSGi can do more than that. But for this introduction, I think, it’s enough