{"id":289,"date":"2019-01-21T13:48:49","date_gmt":"2019-01-21T11:48:49","guid":{"rendered":"http:\/\/www.descher.at\/descher-vu\/?p=289"},"modified":"2019-01-21T13:48:51","modified_gmt":"2019-01-21T11:48:51","slug":"java-11-jaxb-and-osgi","status":"publish","type":"post","link":"http:\/\/www.descher.at\/descher-vu\/2019\/01\/java-11-jaxb-and-osgi\/","title":{"rendered":"Java 11, JAXB and osgi"},"content":{"rendered":"\n<p>Starting with Java 11, several packages have been &#8222;<a href=\"https:\/\/openjdk.java.net\/jeps\/320\">hard-removed<\/a>&#8220; from the JRE itself (For Java 9 and 10 they were simply re-activateable by using a parameter) &#8211; one of those being the <em>javax.xml.bind<\/em> package, which used to provide (together with others) the JAXB implementation.<\/p>\n\n\n\n<p>Updating our <a href=\"http:\/\/www.elexis.info\">product<\/a> to become Java 11 compatible, proved to be a major task, but finally it seems I managed to do it. So here are the effective steps resp. pitfalls that one will run into:<\/p>\n\n\n\n<ul><li>The JAXB packages are not available anymore &#8211; how to find them?<\/li><li>My bundles have to run on both Java 8 and Java &gt;8 &#8211; how to achieve this?<\/li><li>Tycho is reluctant to build this, i miss packages<\/li><li>The concrete JAXB implementation seems not to be found, because OSGi &#8211; how to fix this?<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">The missing JAXB packages<\/h2>\n\n\n\n<p>In order to find replacements for the now missing bundles, we have to find the right set applicable for OSGi. I managed to identify the following maven bundles:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">com.sun.activation:javax.activation:1.2.0<br>javax.xml.bind:jaxb-api:2.4.0-b180830.0359<br>com.sun.xml.bind:jaxb-osgi:2.4.0-b180830.04<\/pre>\n\n\n\n<p>You can use a maven tool like <em>p2-maven-plugin<\/em> to create a p2 repository with these requirements for later inclusion. Have a look at our own dependency repo for an <a href=\"https:\/\/github.com\/elexis\/elexis-server-dependencies\/blob\/master\/pom.xml\">example<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Run &#8218;em on both Java 8 and Java &gt;8<\/h2>\n\n\n\n<p>OSGi R7 <a href=\"https:\/\/blog.osgi.org\/2018\/02\/osgi-r7-highlights-java-9-support.html\">introduced<\/a> the support for multi-release jars. These are bundles, where, dependent on the java version you use, different manifest information is to be applied.<br><br>The following picture shows an example where for Java &gt;=9 the <em>Import-Package<\/em> of the original manifest is replaced to import <em>com.sun.xml.bind.v2<\/em>. The resp. Import-Package will not be used for Java &lt;=8. In order to activate this, the main manifest has to be extended with <em>Multi-Release: true<\/em><\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"772\" height=\"444\" src=\"http:\/\/www.descher.at\/descher-vu\/wp-content\/uploads\/2019\/01\/2019-01-21_1045.png\" alt=\"\" class=\"wp-image-302\" srcset=\"http:\/\/www.descher.at\/descher-vu\/wp-content\/uploads\/2019\/01\/2019-01-21_1045.png 772w, http:\/\/www.descher.at\/descher-vu\/wp-content\/uploads\/2019\/01\/2019-01-21_1045-300x173.png 300w, http:\/\/www.descher.at\/descher-vu\/wp-content\/uploads\/2019\/01\/2019-01-21_1045-768x442.png 768w\" sizes=\"(max-width: 772px) 100vw, 772px\" \/><figcaption>The MANIFEST.MF in versions\/9\/OSGI-INF extends the original manifest for Java &gt; 8<\/figcaption><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Tycho: com.sun.source where are you?<\/h2>\n\n\n\n<p><strong>Caveat<\/strong> Building with Java 11 does not yet <a href=\"https:\/\/bugs.eclipse.org\/bugs\/show_bug.cgi?id=542905\">work<\/a> &#8211; all builds are done using Java 8<\/p>\n\n\n\n<p>While <em>com.sun.xml.bind.jaxb-osgi 2.4.0.b180830_0438<\/em> works fine within the IDE, when building your product trouble is on the horizon. <br><br><em>com.sun.xml.bind.jaxb-osgi 2.4.0.b180830_0438<\/em> formally requires the packages <em>com.sun.source.tree<\/em> and <em>com.sun.source.util<\/em> which are not provided to OSGi as they are expected to be made available by the JRE. At runtime, <em>org.eclipse.osgi_3.13.100.v20180827-1536<\/em> cares for this but at build and package time it is not satisfied.<br><br>This can be fixed by providing a special fragment with <em>Fragment-Host: system.bundle; extension:=framework<\/em> which may then be included to your feature.<br><br>See <a href=\"https:\/\/github.com\/eclipse-ee4j\/jaxb-api\/issues\/92\">https:\/\/github.com\/eclipse-ee4j\/jaxb-api\/issues\/92<\/a> for the detailed problem description and <a href=\"http:\/\/blog.meschberger.ch\/2008\/10\/osgi-bundles-require-classes-from.html\">http:\/\/blog.meschberger.ch\/2008\/10\/osgi-bundles-require-classes-from.html<\/a> for infos on its solution.<br><br>My own solution to this problem is shown in the following image:<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"939\" height=\"334\" src=\"http:\/\/www.descher.at\/descher-vu\/wp-content\/uploads\/2019\/01\/2019-01-21_1127.png\" alt=\"\" class=\"wp-image-308\" srcset=\"http:\/\/www.descher.at\/descher-vu\/wp-content\/uploads\/2019\/01\/2019-01-21_1127.png 939w, http:\/\/www.descher.at\/descher-vu\/wp-content\/uploads\/2019\/01\/2019-01-21_1127-300x107.png 300w, http:\/\/www.descher.at\/descher-vu\/wp-content\/uploads\/2019\/01\/2019-01-21_1127-768x273.png 768w\" sizes=\"(max-width: 939px) 100vw, 939px\" \/><figcaption>Providing com.sun.source.tree and com.sun.source.util to the OSGi environment<\/figcaption><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Implementation of JAXB-API has not been found<\/h2>\n\n\n\n<p>At runtime <em>javax.xml.bind.ContextFinder.newInstance<\/em> is used to create a JAXB object that is actually performing the work.  ContextFinder is part of the java-api bundle, and the actual JAXB implementation it tries to find is provided by <em>com.sun.xml.bind.jaxb-osgi<\/em>. <br><br>Now in OSGi we face the problem of the classloaders per bundle being separate. In <a href=\"https:\/\/github.com\/eclipse-ee4j\/jaxb-api\/issues\/78\">https:\/\/github.com\/eclipse-ee4j\/jaxb-api\/issues\/78<\/a> the problem of jaxb-api not able to find the real jaxb api implementation is documented.<br><br>The exception that identifies this problem looks like this<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">[java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory]<br>     \u2026<br><br> Caused by: javax.xml.bind.JAXBException: Implementation of JAXB-API has not been found on module path or classpath.<br>     at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:269) ~[na:na]<br>     \u2026 93 common frames omitted<br><br> Caused by: java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory<br>     at java.base\/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) ~[na:na]<br>     \u2026 97 common frames omitted<\/pre>\n\n\n\n<p>As far as I know, there are currently 2 solutions to this problem:<br><br>1. Add <em>Import-Package for com.sun.xml.bind.v2<\/em> for each bundle and adapt <em>JAXBContext.newInstance<\/em> to use a bundle local classloader<br><br>2. Provide a fragment bundle for java-api that adds the dependency to the jaxb-api implementation package.<\/p>\n\n\n\n<p>After trying the first approach, I though that I have to modify to much of the existing code &#8211; hence I moved to the second approach.<br><br>The first image in this blog post actually shows this fragment.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Starting with Java 11, several packages have been &#8222;hard-removed&#8220; from the JRE itself (For Java 9 and 10 they were simply re-activateable by using a parameter) &#8211; one of those being the javax.xml.bind package, which used to provide (together with others) the JAXB implementation. Updating our product to become Java 11 compatible, proved to be &hellip; <a href=\"http:\/\/www.descher.at\/descher-vu\/2019\/01\/java-11-jaxb-and-osgi\/\" class=\"more-link\"><span class=\"screen-reader-text\">Java 11, JAXB and osgi<\/span> weiterlesen <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":318,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[23,21,22,24],"_links":{"self":[{"href":"http:\/\/www.descher.at\/descher-vu\/wp-json\/wp\/v2\/posts\/289"}],"collection":[{"href":"http:\/\/www.descher.at\/descher-vu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.descher.at\/descher-vu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.descher.at\/descher-vu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.descher.at\/descher-vu\/wp-json\/wp\/v2\/comments?post=289"}],"version-history":[{"count":25,"href":"http:\/\/www.descher.at\/descher-vu\/wp-json\/wp\/v2\/posts\/289\/revisions"}],"predecessor-version":[{"id":319,"href":"http:\/\/www.descher.at\/descher-vu\/wp-json\/wp\/v2\/posts\/289\/revisions\/319"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/www.descher.at\/descher-vu\/wp-json\/wp\/v2\/media\/318"}],"wp:attachment":[{"href":"http:\/\/www.descher.at\/descher-vu\/wp-json\/wp\/v2\/media?parent=289"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.descher.at\/descher-vu\/wp-json\/wp\/v2\/categories?post=289"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.descher.at\/descher-vu\/wp-json\/wp\/v2\/tags?post=289"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}