You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to the usage of sun.misc package in com.google.gson.internal.UnsafeAllocator, we should explicitly specify sun.misc package in Import-Package. This applies to most of the OSGi runtimes since sun.misc is provided as a system package. Without sun.misc package in Import-Package, it can only work in runtimes where sun.misc is provided as part of boot delegation.
The boot delegation feature in OSGi is really intended as a workaround for some assumptions made in JRE implementations. Certain internal classes are expected to be visible from any classloader, which would not normally be the case in OSGi, and so they have to be added to boot delegation. You may also need to use boot delegation when you have a bytecode instrumentation tool, e.g. a code coverage or performance measurement tool that adds a little bit of code to every class. The instrumented code usually has dependencies, but you wouldn’t want to explicitly add to the Import-Package statement of every bundle because you will probably remove the instrumentation before the bundle goes into production.
The risks associated with boot delegation are quite severe. The first is that a bundle might seem to be working, but only accidentally due to the boot delegation setting of the platform you are running it on. When you move it to another OSGi application it suddenly throws NoClassDefFoundError. You should have imported the package because then it’s clear to everybody what needs to be done to make the bundle work.
The second problem is that boot delegation overrides the choices of every bundle. When you put a package in boot delegation, it’s not just that every bundle can use that package… in fact, every bundle must use that package, even if they had their own copy or if they wanted to import a different version, etc. In other words, it breaks the foundation of OSGi’s modularity.
The text was updated successfully, but these errors were encountered:
amitjoy
changed the title
Add sun.misc to Import-Package
Include sun.misc to Import-Package
Apr 25, 2019
Apparently at some point the Import-Package was added implicitly during build, but caused issues (#1981), so it was made explicitly optional in #1993. Hopefully that was the correct approach; thanks a lot for this detailed explanation!
Due to the usage of
sun.misc
package incom.google.gson.internal.UnsafeAllocator
, we should explicitly specifysun.misc
package inImport-Package
. This applies to most of the OSGi runtimes sincesun.misc
is provided as a system package. Withoutsun.misc
package inImport-Package
, it can only work in runtimes wheresun.misc
is provided as part of boot delegation.The boot delegation feature in OSGi is really intended as a workaround for some assumptions made in JRE implementations. Certain internal classes are expected to be visible from any classloader, which would not normally be the case in OSGi, and so they have to be added to boot delegation. You may also need to use boot delegation when you have a bytecode instrumentation tool, e.g. a code coverage or performance measurement tool that adds a little bit of code to every class. The instrumented code usually has dependencies, but you wouldn’t want to explicitly add to the
Import-Package
statement of every bundle because you will probably remove the instrumentation before the bundle goes into production.The risks associated with boot delegation are quite severe. The first is that a bundle might seem to be working, but only accidentally due to the boot delegation setting of the platform you are running it on. When you move it to another OSGi application it suddenly throws
NoClassDefFoundError
. You should have imported the package because then it’s clear to everybody what needs to be done to make the bundle work.The second problem is that boot delegation overrides the choices of every bundle. When you put a package in boot delegation, it’s not just that every bundle
can
use that package… in fact, every bundle must use that package, even if they had their own copy or if they wanted to import a different version, etc. In other words, it breaks the foundation of OSGi’s modularity.The text was updated successfully, but these errors were encountered: