Tuesday, September 21, 2010

JavaOne 2010: OSGi Migration Headaches

Krasimir Semerdzhiev and Peter Peshev presented "OSGi Migration Headaches" at JavaOne 2010. The speakers took turns presenting and started with an introduction regarding OSGi, what it is, and why it is useful. This is one of those presentations that was useful to hear, but will be even more useful as a reference when working with OSGi. The slides contained several common problems encountered when introducing OSGi into a Java application.  For each problem, common issues or causes of that problematic symptom are listed.  It's a great format for a reference. Many of the issues and problem causes the speakers identified are
not specific to OSGi and so their discussion of those issues is generally useful to Java developers.

The speakers recommended Eclipse Plugin Development Environment (PDE) for creating bundle manifests.  This is easier and less error prone than hand-writing these bundle manifests.

Upon first bundle activation, one is likely to see java.lang.ClassNotFoundException. They listed possible causes of this (missing import-package, missing export-package, import version mismatch, forgotten/missing component, wrong boot class delegation property, file permissions problems). There is a potential problem of specifying versions incorrectly because of subtle differences in version specification syntax.

The java.lang.NoClassDefFoundError means class is not found but cannot get instance of. Possible causes include exception in static block, missing imported class, class version mismatch, HotSpot reflection JIT optimizations (BugID 6265952 related to 15 method calls).

The java.lang.ClassCastException can be caused by additional copies of the OSGi framework classes, undesirable additional JARs on the classpath, and conflict/clash between RT.jar and application libs.

The speakers discussed possible issues underyling the situation when it works in Eclipse but not in Equinox. See also the article OSGi with Eclipse Equinox - Tutorial.

The speakers talked about dependencies on startup order. They also discussed classloader resource assumptions and possible issues: JAR files, folders with class files/packages, URLs to JARs or classes, or new File call after loader resources iteration. Boot delegation specifics got its own slide: com.foo.* includes all sub-packages but not com.foo package itself.

Speakers recommended using Eclipse Memory Analyzer when trying to determine cause of conflicts, errors, and exceptions when using OSGi.

This presentation is one of those which would definitely be helpful to have on hand (hard copy of soft copy) as a reference when using OSGi. It would nice to be able to look up the common causes of these various identified issues by symptom.

No comments: