Scout/HowTo/3.7/Using JRE 1.6 with its packaged javax and w3c.org classes

The Scout documentation has been moved to https://eclipsescout.github.io/.

Many times people ask me why they have to add bundles such as javax.xml or org.w3c.dom, ... to their products even though they are using a JRE 1.6. An example: Plug-In org.apache.batik.dom contains an import dependency to org.w3c.dom and org.w3c.dom.events. Both bundles can be found on the eclipse Orbit download page.

When running a product / application with these bundles (batik 1.7) in jre 1.5 you simply add the bundle javax.xml and org.w3c.dom.events and are done.

But when running the same thing with a jre 1.6 you will most probably run into a runtime error "Loader Constraint Violation" for the class org.w3c.dom.events.Event. This is due to the fact that the osgi class loading tree found the class in the jre 1.6 (which since then includes all that stuff) bootclass path and later-on in the bundle org.w3c.dom.events. These two classes might be identical but have different class loader sources, which is a conflict.

The solution with jre 1.6 is NOT to add bundles with classes of the extended jre but adding a fragment to system.bundle. In our example: Do not add the bundle javax.xml and org.w3c.dom.events. Add a fragment say "jre16.fragment" with the following structure:

jre16.fragment
  META-INF
    MANIFEST.MF

The MANIFEST.MF is as follows.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Packages included in JRE1.6+ (W3C, XML, Activator)
Bundle-SymbolicName: jre16.fragment
Bundle-Version: 1.0.0.qualifier
Fragment-Host: system.bundle
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Export-Package: javax.activation,
 javax.transaction,
 javax.transaction.xa,
 javax.xml;version="1.3.0",
 javax.xml.bind;version="1.3.0",
 javax.xml.bind.annotation;version="1.3.0",
 javax.xml.bind.annotation.adapters;version="1.3.0",
 javax.xml.bind.attachment;version="1.3.0",
 javax.xml.bind.helpers;version="1.3.0",
 javax.xml.bind.util;version="1.3.0",
 javax.xml.crypto;version="1.3.0",
 javax.xml.crypto.dom;version="1.3.0",
 javax.xml.crypto.dsig;version="1.3.0",
 javax.xml.crypto.dsig.dom;version="1.3.0",
 javax.xml.crypto.dsig.keyinfo;version="1.3.0",
 javax.xml.crypto.dsig.spec;version="1.3.0",
 javax.xml.datatype;version="1.3.0",
 javax.xml.namespace;version="1.3.0",
 javax.xml.parsers;version="1.3.0",
 javax.xml.soap;version="1.3.0",
 javax.xml.stream;version="1.3.0",
 javax.xml.stream.events;version="1.3.0",
 javax.xml.stream.util;version="1.3.0",
 javax.xml.transform;version="1.3.0",
 javax.xml.transform.dom;version="1.3.0",
 javax.xml.transform.sax;version="1.3.0",
 javax.xml.transform.stax;version="1.3.0",
 javax.xml.transform.stream;version="1.3.0",
 javax.xml.validation;version="1.3.0",
 javax.xml.ws;version="1.3.0",
 javax.xml.ws.handler;version="1.3.0",
 javax.xml.ws.handler.soap;version="1.3.0",
 javax.xml.ws.http;version="1.3.0",
 javax.xml.ws.soap;version="1.3.0",
 javax.xml.ws.spi;version="1.3.0",
 javax.xml.ws.wsaddressing;version="1.3.0",
 javax.xml.xpath;version="1.3.0",
 org.w3c.dom;version="3.0.0",
 org.w3c.dom.bootstrap;version="3.0.0",
 org.w3c.dom.css;version="3.0.0",
 org.w3c.dom.events;version="3.0.0",
 org.w3c.dom.html;version="3.0.0",
 org.w3c.dom.ls;version="3.0.0",
 org.w3c.dom.ranges;version="3.0.0",
 org.w3c.dom.stylesheets;version="3.0.0",
 org.w3c.dom.traversal;version="3.0.0",
 org.w3c.dom.views;version="3.0.0",
 org.w3c.dom.xpath;version="3.0.0",
 org.xml.sax;version="1.3.4",
 org.xml.sax.ext;version="1.3.4",
 org.xml.sax.helpers;version="1.3.4"

That way the osgi is satisfied since the import dependencies of the batik plugin is met. And on runtime the classes are found directly in the jre 1.6