ASM does not specify upper bounds on import ranges

[jonahgraham]

😢 We have a uses constraint violation in our eco-system.

I think it will be fixed by Dec 10th when we release the new Eclipse IDE 2025-12, but until then anyone (since yesterday?) checking for updates may end up with a uses violation like this preventing using code coverage:

Details of uses violation

ENTRY org.eclipse.eclemma.core 4 0 2025-12-04 12:18:06.024
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.eclemma.core [167]
  Unresolved requirement: Require-Bundle: org.jacoco.core; bundle-version="[0.8.13,0.8.14)"
    -> Bundle-SymbolicName: org.jacoco.core; bundle-version="0.8.13.202504020838"
       org.jacoco.core [540]
  Unresolved requirement: Require-Bundle: org.jacoco.report; bundle-version="[0.8.13,0.8.14)"
    -> Bundle-SymbolicName: org.jacoco.report; bundle-version="0.8.13.202504020838"
       org.jacoco.report [541]
         Unresolved requirement: Import-Package: org.jacoco.core.data; version="[0.8.13,0.8.14)"
           -> Export-Package: org.jacoco.core.data; bundle-symbolic-name="org.jacoco.core"; bundle-version="0.8.13.202504020838"; version="0.8.13"; uses:="org.jacoco.core.internal.data"
         Unresolved requirement: Import-Package: org.jacoco.core.analysis; version="[0.8.13,0.8.14)"
           -> Export-Package: org.jacoco.core.analysis; bundle-symbolic-name="org.jacoco.core"; bundle-version="0.8.13.202504020838"; version="0.8.13"; uses:="org.jacoco.core.data,org.jacoco.core.internal.analysis"
         Unresolved requirement: Import-Package: org.jacoco.core.runtime; version="[0.8.13,0.8.14)"
           -> Export-Package: org.jacoco.core.runtime; bundle-symbolic-name="org.jacoco.core"; bundle-version="0.8.13.202504020838"; version="0.8.13"; uses:="org.jacoco.core.data,org.objectweb.asm"
         Unresolved requirement: Import-Package: org.jacoco.core; version="[0.8.13,0.8.14)"
           -> Export-Package: org.jacoco.core; bundle-symbolic-name="org.jacoco.core"; bundle-version="0.8.13.202504020838"; version="0.8.13"
  Bundle was not resolved because of a uses constraint violation.
  org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.jacoco.core [osgi.identity; type="osgi.bundle"; version:Version="0.8.13.202504020838"; osgi.identity="org.jacoco.core"] because it is exposed to package 'org.objectweb.asm' from resources org.objectweb.asm [osgi.identity; type="osgi.bundle"; version:Version="9.8.0"; osgi.identity="org.objectweb.asm"] and org.objectweb.asm [osgi.identity; type="osgi.bundle"; version:Version="9.9.0"; osgi.identity="org.objectweb.asm"] via two dependency chains.

Chain 1:
  org.jacoco.core [osgi.identity; type="osgi.bundle"; version:Version="0.8.13.202504020838"; osgi.identity="org.jacoco.core"]
    import: (&(osgi.wiring.package=org.objectweb.asm)(&(version>=9.8.0)(!(version>=9.9.0))))
     |
    export: osgi.wiring.package: org.objectweb.asm
  org.objectweb.asm [osgi.identity; type="osgi.bundle"; version:Version="9.8.0"; osgi.identity="org.objectweb.asm"]

Chain 2:
  org.jacoco.core [osgi.identity; type="osgi.bundle"; version:Version="0.8.13.202504020838"; osgi.identity="org.jacoco.core"]
    import: (&(osgi.wiring.package=org.objectweb.asm.commons)(&(version>=9.8.0)(!(version>=9.9.0))))
     |
    export: osgi.wiring.package=org.objectweb.asm.commons; uses:=org.objectweb.asm
  org.objectweb.asm.commons [osgi.identity; type="osgi.bundle"; version:Version="9.8.0"; osgi.identity="org.objectweb.asm.commons"]
    import: (&(osgi.wiring.package=org.objectweb.asm)(version>=9.8.0))
     |
    export: osgi.wiring.package: org.objectweb.asm
  org.objectweb.asm [osgi.identity; type="osgi.bundle"; version:Version="9.9.0"; osgi.identity="org.objectweb.asm"]
	at org.eclipse.osgi.container.Module.start(Module.java:495)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:2110)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:146)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2101)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2041)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:2003)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1915)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:341)

The underlying issue is in objectweb here - the Import Package has no upper bounds, meaning (e.g.) org.objectweb.asm.commons and org.objectweb.asm can be different versions in the same resolver. You can see that happen in the above uses violation.

The build.gradle linked produces a manifest that looks like this (showing only key parts for clarity):

Bundle-SymbolicName: org.objectweb.asm.commons
Bundle-Version: 9.8
Import-Package: org.objectweb.asm;version="9.8",org.objectweb.asm.signature;version="9.8",org.objectweb.asm.tree;version="9.8"

Note that the build.gradle was changed a few years ago, the older ones had the same problem as the upper bound is too wide:

Bundle-SymbolicName: org.objectweb.asm.commons
Bundle-Version: 9.0.0
Import-Package: org.objectweb.asm;version="[9.0,10)",org.objectweb.asm.signature;version="[9.0,10)",org.objectweb.asm.tree;version="[9.0,10)"

I am going to file the above to https://gitlab.ow2.org/asm/asm/-/issues also, but I am in the moderation queue for a new account.

Why is this a problem now?

Normally this mismatch isn't a problem because jacoco imports the most recent version of objectweb, and objectweb's "self" imports without a version range gets resolved to the latest version anyway.

However, if you have m2e installed at the moment, you also have https://download.eclipse.org/technology/m2e/releases/latest/ in available p2 sites, and yesterday m2e published a new release that contains a newer version of objectweb than jacoco imports.

This is why this problem probably resolves itself on 2025-12 release date because then the updated jacoco will be released that uses the objectweb.

Why wasn't this a problem in the past?

This also didn't used to be a problem in the past, because in the "old" orbit we re-bundled objectweb and had correct version constraints:

Bundle-SymbolicName: org.objectweb.asm.commons
Bundle-Version: 9.4.0.v20221107-1714
Import-Package: org.objectweb.asm;version="[9.4.0,9.5)",org.objectweb.asm.signature;version="[9.4.0,9.5)",org.objectweb.asm.tree;version="[9.4.0,9.5)"

There is the possibility that at other points in time between the 9.4 and current version that this problem may have happened because m2e release a few days before SimRel and that window could have been open in the past to cause this problem. It is mostly happenstance that I happened to run into this problem today.

[jonahgraham]

fyi

• @Godin maintainer of eclemma and historical maintainer of objectweb. You may see such errors from users reported?
• @HannesWell @kwin @laeubi as m2e maintainers - nothing I expect from m2e on this, but fyi as to the impact of releasing your SimRel related project a little early. I am sure there are many reasons for out of step release date and m2e isn't the only project that does, but this type of issue was one example why all projects went "live" the same day for simrel in the past.
• @merks because always 😜

I don't think there is much we can do about this issue in the short term - hopefully objectweb can fix up their manifests. This issue is to track that plan in the third-party project.

[jonahgraham]

I forgot to include steps to reproduce:

1. Unpack eclipse-committers-2025-09-R-linux-gtk-x86_64.tar.gz (any platform should probably work)
2. Check for updates
3. Restart

Note there is no Profiling available and error log will have message from issue.

[merks]

Such a tangled web. Even the can-update test kind of needs to be tested on every package it seems and is affected by more than just the contents of the train.

In any case there is literally nothing here that orbit can fix. We will automatically pick up a new version when available from maven central and the producer is responsible for the OSGi metadata.

We can leave this open until such an update arrives.

[jonahgraham]

Issue raised https://gitlab.ow2.org/asm/asm/-/issues/318037

[jonahgraham]

MR created https://gitlab.ow2.org/asm/asm/-/merge_requests/443

[HannesWell]

• as m2e maintainers - nothing I expect from m2e on this, but fyi as to the impact of releasing your SimRel related project a little early. I am sure there are many reasons for out of step release date and m2e isn't the only project that does, but this type of issue was one example why all projects went "live" the same day for simrel in the past.

Sorry for the trouble. At least for eclipse-platform etc. we just rely on already finally released artifacts, but for Orbit we use the repo for the current stream to be in sync.

I cannot really tell what we could do differently except from only going live on release date. But that would make our release process more complex (and we tried to keep it simple :/).

[jonahgraham]

Sorry for the trouble.

No worries - this kind of thing comes up occasionally and it is a pain.

I cannot really tell what we could do differently

I don't think you need to change anything, hopefully this particular area is resolved once #58 (comment) is done. I cc'ed you in fyi because who would have guessed that a minor version change for m2e would break coverage tools!

Personally I am fine with the trade-off to keep the m2e release process simpler.

Maybe someone can fix the resolver to find uses constraints solutions better. I think I have discussed almost identical issues in the past with @tjwatson and IIRC it is NP-complete and there isn't really going to be a solution to this anytime soon. So we just got to try to get projects and dependencies to publish the best meta data we can until then.

[laeubi]

😢 We have a uses constraint violation in our eco-system.

What kind of exactly? Can you export the system state and upload it here?

I just wanted to note that this usually indicates a bug in the resolver (see below), or missing use-constrains (not necessarily missing version bounds.

The build.gradle linked produces a manifest that looks like this (showing only key parts for clarity):

They key part is actually the export here. Even though unconstrained imports are bad, they are usually NOT the problem! If it is even the case here that asm is doing import/export the same package they should simply not do it! This is almost always bad practice.

Normally this mismatch isn't a problem because jacoco imports the most recent version of objectweb

How does jacoco imports objectweb? Maybe this should be improved as well.

nothing I expect from m2e on this, but fyi as to the impact of releasing your SimRel related project a little early. I am sure there are many reasons for out of step release date and m2e isn't the only project that does, but this type of issue was one example why all projects went "live" the same day for simrel in the past.

m2e is part of simrel, but we usually release quite late, and often release also in between. Also we inject a "latest" update-site into the installation as well. So one could expect "out of order" Updates anyways. In general im it only works if everyone release together because of third party dependencies, then something is fundamentally broken (see below). It should simply not matter except for when one project is using "latest" API from others (what m2e usually do not and uses current-release - 1)

Maybe someone can fix the resolver to find uses constraints solutions better.

This is they key problem we have for years, that the current felix resolver has some flaws:

1. It can get into a state where permutations explode
2. If it takes to long it simply falls back to a "simple" mode where constrains are not properly checked
3. When substituation packages occurs then it sometimes creates an "impossible" state with missing requirements

I analyzed all these in the past and tried to came up with some improvements but the general problem remains due to how the resolver works.

IIRC it is NP-complete and there isn't really going to be a solution to this anytime soon. So we just got to try to get projects and dependencies to publish the best meta data we can until then.

While this is true in general, the practical problem is much easier to solve because many things are simply "impossible" combinations. And I strongly believe we can do much better and faster than today as shown by some of my proof-of-concept PRs.

The main problem is that this requires some efforts and I'm currently only doing it on my free time as I literally found no one that find this important enough to invest much (more) money than to analyze their problem and fix it. And for SimRel there are enough dedicated people so it is not enough painful for most of the users.

But I also strongly believe that the resolver is a crucial part of Equinox/OSGi (if not that part), so I try to move the topic forward, its just a long path so nothing that will be done in a few days and due to mentioned time/budget constrains more a hobby of mine.

[jonahgraham]

The main problem is that this requires some efforts and I'm currently only doing it on my free time as I literally found no one that find this important enough to invest much (more) money than to analyze their problem and fix it. And for SimRel there are enough dedicated people so it is not enough painful for most of the users.

Yup - that is accurate.

---

MR created https://gitlab.ow2.org/asm/asm/-/merge_requests/443

This is now merged, and when ow2 publish a new version we will pick it up and benefit from it.

---

We can leave this open until such an update arrives.

☝️ I'll leave it open for now, hopefully if someone does come across this between now and Wednesday we can point them here.

[laeubi]

This is now merged, and when ow2 publish a new version we will pick it up and benefit from it.

Can you share how the final manifest now looks like? I don't fully get what they are doing in the gradle build and suspect there are more issues lingering around. Are they even using bnd to generated this or is it more or less hand crafted?

Also I'm still interested in the dump for my resolver experiments.

[jonahgraham]

https://gitlab.ow2.org/asm/asm/-/merge_requests/443#note_115757

[laeubi]

https://gitlab.ow2.org/asm/asm/-/merge_requests/443#note_115757

This is not the full manifest. As mentioned above, restricting the import is not enough and from your description they are probably still doing it wrong and the uses constraint violation is just a symptom. If the import is a problem you would more expect a ClassNotFound/MethodNotFoundException or similar but not a uses-constrain violation.

[jonahgraham]

I forgot to include steps to reproduce:

1. Unpack eclipse-committers-2025-09-R-linux-gtk-x86_64.tar.gz (any platform should probably work)

State at this point (gzipped) framework-state.dat.gz

2. Check for updates
3. Restart

I waited for IDE to open and then here is state at this point (gzipped) framework-state.dat.gz

[jonahgraham]

This is not the full manifest

Please have a look in the jar - its in the m2e repo.