Update to ASM 9.9

[merks]

#1964

[Godin]

For the record
here is a link to their changelog - https://asm.ow2.io/versions.html
and actual changes between versions - https://gitlab.ow2.org/asm/asm/-/compare/ASM_9_8...ASM_9_9

From this to me seems that this time there were no changes that could negatively impact us.

[Godin]

I did check that their license stayed unchanged.

[merks]

Yes, I did check the license file too

https://asm.ow2.io/license.html

I was a bit surprised that ASM is released under the following 3-Clause BSD License: was left out of the copy:

[iloveeclipse]

Apropos: will there be an Eclemma update soon?

[merks]

I'm still awaiting the Maven Central update for Orbit. I image the Maven Central publishing is a prerequisite for Eclemma as well.

I know that sometimes it can take a while from when it's published to when it's visible here:

https://repo.maven.apache.org/maven2/org/jacoco/org.jacoco.agent/

[Godin]

@merks we do not publish releases for every merge of every PR 😉 but we do publish snapshots at https://central.sonatype.com/repository/maven-snapshots/ which unfortunately as of now doesn't allow to get list of files in browser, but they are downloadable by Maven.

It took me quite some time, much more than usually 😪 , because of EOL of OSSRH service ( oss.sonatype.org ) and migration to Central Publisher Portal (central.sonatype.com) - #1896, but release has been staged - https://groups.google.com/g/jacoco-dev/c/wdKGT0rprS0/m/q9MlqmKzAQAJ

So hope it will reach Maven Central tomorrow (Oct 8) after successful validation by @marchof

Then after Orbit update, publishing of EclEmma milestone should not take long for me.

[merks]

Thanks for the update. Yes, the OSSRH thing has been a nightmare for me as well. 😱

[Godin]

hope it will reach Maven Central tomorrow (Oct 8)

@merks FYI unfortunately it is going to take longer, because fortunately we got report about regression - #1969
hope to fix it soon, and re-staging of release should go smoother and faster this time

[merks]

Thank you for your effort and for the updates. It's all very much appreciated. ❣️

[iloveeclipse]

hope it will reach Maven Central tomorrow (Oct 8)

@merks FYI unfortunately it is going to take longer, because fortunately we got report about regression - #1969 hope to fix it soon, and re-staging of release should go smoother and faster this time

I see #1969 is fixed.

Is there any ticket one can follow where one could see the state of the release tasks?

If I understood it right,

1. we wait for jacoco 0.8.14 to be published to maven before we can see it in Orbit.
2. After we have jacoco 0.8.14 in Orbit, ASM 9.9.0 can be added to Orbit too?

I have Xtext PR eclipse-xtext/xtext#3528 that waits for ASM 9.9.0 being in Orbit.
I'm right with the dependency chain here?
Why can't we add ASM 9.9.0 to Orbit without jacoco update?

[merks]

The Orbit builds are very careful to guarantee and test that the transitive closure of dependencies is complete, i.e., that everything in Orbit can be installed from what's in Orbit. (Much like is the case for the release train.) So the initial build step fails like this currently:

[ERROR] Missing requirement: org.jacoco.core 0.8.13.202504020838 requires 'java.package; org.objectweb.asm [9.8.0,9.9.0)' but it could not be found
[ERROR] Cannot satisfy dependency: org.eclipse.orbit.maven.osgi.all.feature.group 4.38.0.v20251010-1423 depends on: org.eclipse.equinox.p2.iu; org.jacoco.core [0.8.13.202504020838,0.8.13.202504020838]

Imagine if you are a project that uses jacoco and uses Orbit and then one day sudden your target platform can't be resolved (in planner mode) because of missing dependencies. You'd not be very happy. It's of course possible that I could add both version of ASM to Orbit for a while, but this is the first time it's taken more than two days to resolve the issue (and, as you are probably aware, I really have way too much to do already).

There's definitely a growing backlog of updates available. E.g., I noticed there is a new version of the following that I expect Xtext will want to consume.

        <dependency>
          <groupId>io.github.classgraph</groupId>
          <artifactId>classgraph</artifactId>
          <version>4.8.184</version>
          <type>jar</type>
        </dependency>

[iloveeclipse]

OK, I understand. So after we have jacoco 0.8.14 in Orbit, ASM 9.9.0 can be added to Orbit too, or are there other blocker?

[merks]

This is the only exceptional such case. It's rare to have such narrow bounds, I don't believe anyone has ever published an update for which the dependencies are not already available, and Orbit automatically updates everything that is available to update. Sometimes updates will have new dependencies, I think that happen with a recent batik update, but in that case I track them down and add them too. Yesterday I updated in the middle of Jetty 12.1.2 becoming visible; that was a little disconcerting to see a mix of version numbers

So yes as soon I see the jacoco update available I will build a full milestone of Orbit because Lucene is updated and that's consumed by the Platform. I'll try to remember to ping on the Xtext issue...

[Godin]

Is there any ticket one can follow where one could see the state of the release tasks?

Usually our release process is not tracked via ticket, but via mailing list - here is a link for 0.8.14 - https://groups.google.com/g/jacoco-dev/c/wdKGT0rprS0/m/q9MlqmKzAQAJ
However this time due to migration to Maven Central Publisher Portal you can also track it via #1896

Why can't we add ASM 9.9.0 to Orbit without jacoco update?

Eclipse EclEmma is part of Eclipse IDE distribution for Java, EclEmma requires JaCoCo, and JaCoCo requires strict version of ASM. And my understanding that for some reason multiple versions of ASM can't coexist in nowadays Eclipse IDE builds, whereas it was possible in past. And so while one can add multiple ASM versions to Orbit, this will break Eclipse IDE startup - AFAIR exactly this happened during ASM upgrade previous time. Maybe @merks can help to explain why? Personally I would really love to be able to have multiple ASM versions for one SimRel milestone, giving us a bit more time than 2 sleepless nights - there are a way too much pressure on us and hurry every time ASM releases. In past there were several examples of hard to diagnose regressions in JaCoCo due to changes in ASM behaivour and hurry with upgrade of it.

BTW looking at ASM changelog https://asm.ow2.io/versions.html and actual changes https://gitlab.ow2.org/asm/asm/-/compare/ASM_9_8...ASM_9_9 I don't understand at all from where hurry with its upgrade is coming from. The only notable change is V26 constant for Java version whose development just started. But I multiple times pointed out to various Eclipse projects that in absence of other real changes in bytecode, there is workaround for new class file versions without ASM upgrade - see

jacoco/org.jacoco.core/src/org/jacoco/core/internal/instr/InstrSupport.java

Lines 274 to 283 in 78d5eff

	public static ClassReader classReaderFor(final byte[] b) {
	final int originalVersion = getMajorVersion(b);
	if (originalVersion == Opcodes.V24 + 1) {
	// temporarily downgrade version to bypass check in ASM
	setMajorVersion(Opcodes.V24, b);
	}
	final ClassReader classReader = new ClassReader(b);
	setMajorVersion(originalVersion, b);
	return classReader;
	}

I see #1969 is fixed.

this is the first time it's taken more than two days to resolve the issue (and, as you are probably aware, I really have way too much to do already).

Please understand that we also have a lot of other important things to do - you know our primary job is not EclEmma and JaCoCo, not counting personal life.

[iloveeclipse]

I don't understand at all from where hurry with its upgrade is coming from.

ASM 9.9.0 is in the 4.38 platform already, and I have product that uses latest 4.38 Platform, Xtext & other ASM based bundle (org.apache.commons.commons-compress - not ASM version restricted, because it is not relevant for apache compress) and all together can't co-exist in same target with multiple ASM versions without OSGI error Unable to resolve resource XYZ 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.

So it is not about bytecode at all, it is about dependencies...

Please understand that we also have a lot of other important things to do ...

Sure, this applies for all of us, I believe.

[Godin]

So it is not about bytecode at all, it is about dependencies...

Why there was such a hurry for 4.38 platform to use ASM 9.9.0 if it is not about bytecode?
And again why two ASM versions can't coexist while this was possible before?

[merks]

This is why I asked about updating the Platform because I know this cycle exists:

eclipse-platform/eclipse.platform.releng.aggregator#3385 (comment)

I would not have agreed to the update the Platform if M1 were not already out. Now we have quite some weeks before M2 so I thought things would be quite relaxed and OK. I was not aware that would be some intrinsic pressure in Xtext. Does Xtext require ASM bundles in addition to those required by the Platform?

I can fully empathize with @Godin's situation. ❣️ There's always way too much to do. This is why I try to help as much as possible (create a PR), and why I avoid pressure because I believe everyone is doing the best they can within their capacity. None of us like being pressured, and rightfully so! I can only express my gratitude for @Godin's efforts. 🏆

[iloveeclipse]

And again why two ASM versions can't coexist while this was possible before?

It always depends on bundle dependencies in given bundles set in given application. Dependencies & bundles change and with them problems appear and disappear :-)

• Platform brings in ASM 9.9.0
• compress uses any ASM version, so gets 9.9.0
• Xtext uses [9.8.0,9.9.0) so gets 9.8.0
• XYZ bundle is forced to use Xtext so must use 9.8.0 but also uses compress that gets 9.9.0 and has the error above.

To unblock this, we can't change compress to limit to 9.8.0 because it doesn't actually care, it just needs some minimal ASM version. We also can't change XYZ bundle, because it needs both Xtext & compress.
So we must change Xtext to update it to 9.9.0.
Xtext can't update because there is no Orbit version.
And here we are.

[iloveeclipse]

Does Xtext require ASM bundles in addition to those required by the Platform?

No. So I've originally tried to use ASM from platform in Xtext "latest", but it looks like Xtext has multiple targets and all of them expect ASM from Orbit in same version.

[merks]

I see, just complex releng issues. Didn't realize Xtext like jacoco has such strict upper bounds:

It seems to me though that the latest platform should be okay to install only 9.8.0..

[Godin]

Re-staged https://groups.google.com/g/jacoco-dev/c/wdKGT0rprS0/m/jQog-peIAgAJ

[Godin]

@merks FYI 0.8.14 available in Maven Central