Tip: Eclipse, OSGi and Execution Environments

I was working with a client recently and the question of what are execution environments came up. Execution environments (EEs) are simply symbolic representations of JREs. For example, rather than talking about a specific JRE (with a specific name at a specific location on your disk), you can talk about the J2SE-1.4 execution environment. This way things can be shared without referencing specific paths. Furthermore, tools like PDE help setup your classpath compliance settings base on the EE you’re working with (on a per bundle basis).

Ok, the reason the question about EEs came up was because of this screenshot:

What’s this screenshot show? Well, the client was interested in using a Base64 encoder so why not use one from the VM? At first, the comedian in me thought why not use one of the 20 we have in the SDK already?

Ok, maybe that’s a little of an exaggeration :)

Back to the problem at hand… in the beginning, things were OK… it wasn’t until the move to Eclipse 3.4 and the client updated his bundle to take advantage of execution environments. By selecting an execution environment, the client had his classpath updated and access rules were set on what packages are visible to the plug-in. Great! But why get the access restiction on the ‘sun.misc’ package? OSGi bundles can clearly see packages from the VM, this isn’t a problem. The problem is that ‘sun.misc’ isn’t a package that is considered to be included VMs (by default). You could imagine this become a problem if you’re bundles are working great on a specific Sun VM, but than people try to run your bundles on another VM that doesn’t have the ‘sun.misc’ package available. If you’re curious about what packages are supplied by which execution environment, see the OSGi compendium specification (999) and take a peak into the Equinox profile files (i.e., J2SE-1.4).

How do you solve this type of problem? Well, you have a couple options. The first, you can make OSGi aware of a package like ‘sun.misc’ by setting a system property before launching:

-Dosgi.framework.extensions=sun.misc

The other option is to create a new bundle that simply exports what is available in the VM and have your bundles depend on that if they need the specific package. There are other ways to get around this issue but generally the first option is the preferred route. Both of these options should make the tooling happy. However, don’t be tempted to do this frequently as usually doing this is a sign that your bundles aren’t VM independent.

Oh, another tip… if you’re looking at debugging where packages are being wired from, PDE includes a nice Plug-in Dependencies view to help you with this:

Using this view, I can tell where my imported packages are coming from while I’m developing. For example, it’s easy to see if you’re getting a package from the VM for free or from some plug-in.

Hope this tip helps and happy hacking! acking!