the jdk6-jdk5 copies - please use standard version numbers

[hazendaz]

Hi @raphw,

The current release looks like a mess (1.18.6-jdk6-jdk5 / 1.18.6-jdk5). The release notes say nothing. The commit history is hard to follow on what happened. If the long term plan is to support really legacy cuts for java 6 and/or java 5, can you use a classifier for that instead of causing tools like renovate / dependabot to pop such legacy versions by default? In this case there is no 1.18.6 so I think many would skip these entirely as it makes no sense to add such old support but that means telling the tools like dependabot / renovate to ignore them. So its really extra work. It would be nicer to get a quick proper cut of next version that puts it back on track. It seems you may be doing that already with 1.18.7.

FWIW - renovate prefers the 1.18.6-jdk6-jdk5 over 1.18.5 currently.

Thanks,

Jeremy

[raphw]

Yes, my appologies. Those two versions came out while working with the release pipeline, and I did not properly disarm the new branch, so I had no way of stopping them. I am close to a new working pipeline and semantically newer versions will come out the moment I reached a stable new pipeline. Likely sometime today.

[merks]

I was just wondering about this problem as well. The Eclipse Platform project's automatic version updater is picking up the unusual version so we're hoping for a version with a more expected version form:

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/3680/changes

This is a good opportunity to say thank you for providing, supporting, and maintaining such useful technology! ❣️ 🥇

[raphw]

New versions are released. You can now choose between the regular version which is baselined to JDK8, but reduces the jar size by half, including improved JVM startup time. Or you suffix with -jdk5 for compatibility with legacy JDKs.

[NersesAM]

Hi @raphw, one side effect of this is that tools like renovate are now suggesting -jdk5 as the latest version. While it is possible to restrict it to ignore -jdk5 versions. it feels like people using jdk5 need to take the inconvenient path rather than majority.

same in maven central

Isn't classifier a better fit here?

[merks]

Yes, we had to work around that too by filtering that suffix:

eclipse-platform/eclipse.platform.releng.aggregator@a5d6fb5

For Orbit I mostly ignore all versions with suffixes so generated this without a problem:

eclipse-orbit/orbit-simrel@a64fb59

[raphw]

Classifiers are resolved as distinct dependencies. If you have both transitively, both will be present and clash the class loader.

According to the Maven spec, a version with a suffix is an older version. I might need to switch the release order if tools like renovate consider timestamps instead, what would be incorrect resolution anyways, but would trigger correct behaviour.

[NersesAM]

but 1.18.5-jdk5 is also a distinct dependency, and poses same problem when suffix-less 1.18.5 is dragged transitively, isn't it?

[merks]

If you can make sense of the specification

https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification

I think it's like this case

A bunch of the qualifiers have special meaning and special order:

It quite different from OSGi versions.

When I doubt, I test with the implementation of org.apache.maven.artifact.versioning.DefaultArtifactVersion which we can assume implements the specification:

		System.out.println("###" + new TreeSet<ArtifactVersion>(Arrays.asList(new ArtifactVersion[] { //
				new DefaultArtifactVersion("1.18.7"), //
				new DefaultArtifactVersion("1.18.7.jdk5"), //
				new DefaultArtifactVersion("1.18.7-jdk5"), //
				new DefaultArtifactVersion("1.18.7-snapshot"), //
				new DefaultArtifactVersion("1.18.7-SNAPSHOT"), //
		})));

That prints:

###[1.18.7-snapshot, 1.18.7, 1.18.7.jdk5]

[raphw]

If both 1.2.3 and 1.2.3-jdk5 were on a class path, only the newest version would win. If I made the latter one a classifier dependency, Maven would add both. That's why I needed a versioning-based solution.

I did in fact not know about this versioning. I could resolve this by adding -jdk8 to the "regular" version. But it does not feel intuitive. Does Gradle resolve versions the same way? Semver specifies 1.2.3 to be newer than 1.2.3-jdk5, so in a way I would like to keep true to the specification.

[hazendaz]

Why 1.2.3-jdk5 is unconventional

In Maven, the - suffix is treated as a qualifier. So 1.2.3-jdk5 is just a version qualifier.

It works technically — Maven will accept it — but it does not follow the usual semantic versioning convention and can confuse dependency resolution:

Maven considers qualifiers in lexicographic order, so 1.2.3-jdk5 is “older” than 1.2.3 according to Maven ordering.

It conflates version and platform compatibility (JDK5), which Maven usually handles with classifiers or profiles, not the version itself.

The bots will send that qualified version first which wastes processing / time to know we need to skip it. I cannot think of any other library modernly doing this.

If concern is that users might add both...

Key principle: Classifiers are not inherited

Maven treats classifiers as part of the artifact identity, not part of the version.

If your dependency does not specify a classifier, Maven will always pick the non-classified artifact.

If a transitive dependency somewhere specifies a classifier, Maven does not automatically substitute your dependency with the classified one.

If that is still a concern, then its better to make the artifact name contain that detail like byte-buddy-jdk5.

I can confirm though, if I know to go update to the non qualified version, renovate has no trouble there but reality is a lot of devs will just merge in the qualified version. I don't know if renovate will then serve up the next but in big shops not tied to central directly, someone is bound to procure the wrong one, it gets used and many would not understand the why.

While this is generally unusual to do, like who is using java 5 or 6 or 7 at this point? Aside from that, bouncy castle does just this, they make the artifactId contain the extra information so users are explicit on usage. And tools such as renovate if its defined well are smart enough now to suggest replacements.

So while the messed up 1.18.5 release was way off, I don't see much of an improvement with 1.18.7 usage. In fact, I got blasted by dozens of repos to upgrade to the qualified version right out the gate.

If it were me, I would really just move the 'artifactId' then to list jdk5 on it like you have done. Users that are stuck in that world should be the ones to earn the pain. Users in the modern realm should not be forced to know about such legacy as its meaningless to them. So that balance forces the meaning on who actually needs it without it affecting engines that are going to jump on this. Also don't forget both dependabot and renovate can auto merge, so anyone setting that is suddenly getting non standard versions that directly indicate real old legacy (even if that is not the intent, I understand the intent with asm).

[merks]

Maven considers qualifiers in lexicographic order, so 1.2.3-jdk5 is “older” than 1.2.3 according to Maven ordering.

I gave an example and demonstrated with an code example that the opposite is true. Of course we are having this discussion because the opposite it true. I guess/assume you meant the opposite of what you actually stated.

---

As suggested bouncycastle uses a different artifactId for a similar purpose:

https://repo.maven.apache.org/maven2/org/bouncycastle/

Certainly if one considers versions to be semantic version, using a qualifier to indicate a significant semantic/functional difference is a point of confusion.

I just don't want to look a gift horse in the mouth here though. We can all be thankful that @raphw supports this technology without us paying him penny. He only has to listen to us complain when something isn't exactly as we think it should be. One might argue that the handy, dandy tools that do auto-updating should be smart enough to be configurable; maybe we should consider to go complain to the tool providers if that's not the case.