Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Missing Constraint: Import-Package: sun.misc #1981

Closed
JaroslavTulach opened this issue Sep 30, 2021 · 2 comments · Fixed by #1993
Closed

Missing Constraint: Import-Package: sun.misc #1981

JaroslavTulach opened this issue Sep 30, 2021 · 2 comments · Fixed by #1993
Labels
bug

Comments

@JaroslavTulach
Copy link

Gson version

The Apache NetBeans project has just tried to migrate from version 2.8.5 to version 2.8.8 in the pull request PR-3200 and the update fails with unsatisfied OSGi missing constraint: Import-Package: sun.misc.

Java / Android version

NetBeans project builds & runs primarily on JDK8.

Used tools

NetBeans is using home-made Ant based build system. I don't think it matters for this bug report.

Description

As PR-3200 states: The start of NetBeans fails with exception coming from an OSGi container (Apache NetBeans project is using OSGi behind the scene):

SEVERE [org.netbeans.modules.netbinox]: framework event com.google.gson type 2
org.osgi.framework.BundleException: The bundle "com.google.gson_2.8.8 [111]" could not be resolved. Reason: Missing Constraint: Import-Package: sun.misc; version="0.0.0"
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1332)
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1316)
	at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323)
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:390)
	at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1184)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
	at org.eclipse.osgi.framework.internal.core.EquinoxLauncher.internalStart(EquinoxLauncher.java:271)
	at org.eclipse.osgi.framework.internal.core.EquinoxLauncher$2.run(EquinoxLauncher.java:246)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.framework.internal.core.EquinoxLauncher.start(EquinoxLauncher.java:244)
	at org.eclipse.osgi.launch.Equinox.start(Equinox.java:258)
	at org.netbeans.core.netigso.Netigso.start(Netigso.java:184)
	at org.netbeans.NetigsoHandle.startFramework(NetigsoHandle.java:188)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:1458)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:1254)
	at org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:315)
	at org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:251)
	at org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:298)
	at org.netbeans.core.startup.Main.getModuleSystem(Main.java:156)
	at org.netbeans.core.startup.Main.getModuleSystem(Main.java:125)
	at org.netbeans.core.startup.Main.start(Main.java:282)
	at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:98)

Expected behavior

Version 2.8.5 starts. It's manifest doesn't have any unavoidable dependency on sun.misc package. There is

unzip -p netbeans/ide/modules/com-google-gson.jar META*MAN* | grep Import.*Package
Import-Package: com.google.gson.annotations

in NetBeans 12.5.

Actual behavior

However the new, 2.8.8 version contains explicit dependency on sun.misc:

Import-Package: com.google.gson.annotations,sun.misc

The Apache NetBeans project doesn't allow OSGi bundles to access sun.misc package and as such the OSGi container refuses to launch the GSON 2.8.8 bundle.

Reproduction steps

To reproduce I would:

  • apply PR-3200
  • ant build to build NetBeans
  • ant tryme to launch it

However I assume the problem is clear from the printed error. The sun.misc imported package is causing it. Any compliant OSGi container shall fail on similar error.

Exception stack trace

SEVERE [org.netbeans.modules.netbinox]: framework event com.google.gson type 2
org.osgi.framework.BundleException: The bundle "com.google.gson_2.8.8 [111]" could not be resolved. Reason: Missing Constraint: Import-Package: sun.misc; version="0.0.0"
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1332)
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1316)
	at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323)
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:390)
	at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1184)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
	at org.eclipse.osgi.framework.internal.core.EquinoxLauncher.internalStart(EquinoxLauncher.java:271)
	at org.eclipse.osgi.framework.internal.core.EquinoxLauncher$2.run(EquinoxLauncher.java:246)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.framework.internal.core.EquinoxLauncher.start(EquinoxLauncher.java:244)
	at org.eclipse.osgi.launch.Equinox.start(Equinox.java:258)
	at org.netbeans.core.netigso.Netigso.start(Netigso.java:184)
	at org.netbeans.NetigsoHandle.startFramework(NetigsoHandle.java:188)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:1458)
	at org.netbeans.ModuleManager.enable(ModuleManager.java:1254)
	at org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:315)
	at org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:251)
	at org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:298)
	at org.netbeans.core.startup.Main.getModuleSystem(Main.java:156)
	at org.netbeans.core.startup.Main.getModuleSystem(Main.java:125)
	at org.netbeans.core.startup.Main.start(Main.java:282)
	at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:98)

Workaround

OSGi specification defines a special property org.osgi.framework.system.packages.extra which makes additional boot classpath packages available to the OSGi bundles. Yes, setting it to:

$ netbeans/bin/netbeans -J-Dorg.osgi.framework.system.packages.extra=sun.misc

works. Yes, we can use it, if necessary. But it puzzles me:

Have you introduced the dependency intentionally? Or is it just an accidental by-product of other changes? I can see that the new version of GSON is built with JDK11 from its JAR manifest. Also the BND tools got upgraded to Bnd-5.3.0.202102221516 - maybe the added dependency on sun.misc is just a by-product of one of the build changes? It seems the sun.misc code is used just conditionally - e.g. the dependency could be optional:=true. Maybe specifying the optional dependency explicitly to BND is all that's needed to eliminate it?

Thanks for taking a look and helping Apache NetBeans (possibly others) resolve the upgrade issue.
@eamonnmcmanus
Copy link
Member

Hi Jaroslav!
Sorry you are having these problems. Unfortunately I'm not sure anyone currently active in this project has expertise in OSGi. If you or anyone else can propose a change that solves your problem we can look into applying it and re-releasing, but I don't think we'll be able to come up with such a change ourselves.
This RxJava issue from 2015 might be relevant.

JaroslavTulach pushed a commit to JaroslavTulach/gson that referenced this issue Oct 14, 2021
google#1981: Avoid OSGi bundle's dependency on sun.misc package
53db9e8
@JaroslavTulach JaroslavTulach mentioned this issue Oct 14, 2021
Merged
@JaroslavTulach
Copy link
Author

Hello Éamonn!
I believe #1993 is the right fix. Can you be my sponsor (again ;-) and help me get it into next version of GSON?

@JaroslavTulach JaroslavTulach mentioned this issue Oct 14, 2021
Merged
@eamonnmcmanus eamonnmcmanus mentioned this issue Oct 15, 2021
Merged
@Marcono1234 Marcono1234 mentioned this issue Oct 21, 2021
Closed
2 tasks
@eamonnmcmanus eamonnmcmanus linked a pull request Oct 25, 2021 that will close this issue
#1981: Optional OSGi bundle's dependency on sun.misc package #1993
Merged
eamonnmcmanus pushed a commit that referenced this issue Oct 25, 2021
@Marcono1234
#1981: Optional OSGi bundle's dependency on sun.misc package (#1993)
ca1df7f 
* #1981: Avoid OSGi bundle's dependency on sun.misc package

* Specify optional dependency on sun.misc.Unsafe

* Adjusting the test to sun.misc import being optional

* Using Collections.list and for loop

* Let the fail message include name of package

Co-authored-by: Marcono1234 <[email protected]>

* Closing the input stream

* Dedicated assertSubstring method

Co-authored-by: Marcono1234 <[email protected]>
@Marcono1234 Marcono1234 mentioned this issue Jul 26, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
2 participants
@eamonnmcmanus @JaroslavTulach