Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.25.6 to 0.26.0

[dependabot]

Bumps com.github.siom79.japicmp:japicmp-maven-plugin from 0.25.6 to 0.26.0.

Release notes

Sourced from com.github.siom79.japicmp:japicmp-maven-plugin's releases.

japicmp-base-0.26.0

• No NPE when using Markdown-Processsor with byte-based archive #516

japicmp-base-0.25.7

• Report incompatiblity in case a class changes from implementing a generic interface with raw types to concrete type parameters #507

Commits

• aa07518 [maven-release-plugin] prepare release japicmp-base-0.26.0
• c194aee upgraded version in *.md files to 0.26.0
• 8103fe2 mvn set version to 0.26.0-SNAPSHOT
• fc65dbc Fix link format in ReleaseNotes.md
• 8a4609e Update ReleaseNotes.md for version 0.26.0
• 1766fed Merge pull request #518 from siom79/release-v0.25.7
• 915b232 Merge pull request #517 from siom79/claude/optional-file-methods-oSmHD
• 1aa1018 Fix NPE in MarkdownOutputGenerator for byte-based JApiCmpArchive (issue #516)
• c01b2c7 Merge pull request #515 from siom79/siom79-patch-1
• 86d3b50 Remove build status badge from README
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[Bukama]

Caused by: org.apache.maven.plugin.MojoFailureException: There is at least one incompatibility: org.eclipse.aether.util.version.GenericVersionScheme.parseVersion(java.lang.String):METHOD_RETURN_TYPE_CHANGED,org.eclipse.aether.util.version.GenericVersionScheme.parseVersionConstraint(java.lang.String):METHOD_RETURN_TYPE_CHANGED,org.eclipse.aether.util.version.GenericVersionScheme.parseVersionRange(java.lang.String):METHOD_RETURN_TYPE_CHANGED

[cstamas]

@siom79 can you shed any light what happens here?

[siom79]

The logs say:

Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.26.0:cmp (default-source-cmp) on project maven-resolver-util: There is at least one incompatibility: org.eclipse.aether.util.version.GenericVersionScheme.parseVersion(java.lang.String):METHOD_RETURN_TYPE_CHANGED,org.eclipse.aether.util.version.GenericVersionScheme.parseVersionConstraint(java.lang.String):METHOD_RETURN_TYPE_CHANGED,org.eclipse.aether.util.version.GenericVersionScheme.parseVersionRange(java.lang.String):METHOD_RETURN_TYPE_CHANGED

Version 0.26.0 did not change anything regarding change detection, only a fix in the markdown report.

[siom79]

And between 0.25.6 and 0.25.7 there was this issue fixed.

[siom79]

Root Cause

The errors stem from two independent changes that interact with each other:

1. A deliberate API change in GenericVersionScheme (February 2023, commit 7872699c, PR #242)

The three methods were changed from returning the abstract interface types to returning their
concrete implementations (covariant return types):

Method	Old return type	New return type
parseVersion(String)	Version	GenericVersion
parseVersionRange(String)	VersionRange	GenericVersionRange
parseVersionConstraint(String)	VersionConstraint	GenericVersionConstraint

The motivation was explicitly documented in the commit message: "generic scheme creates
generic components: usually is directly instantiated, this just made a lot of casting issues."
This is a legitimate and intentional improvement.

2. A bug fix in japicmp 0.25.7 (issue #507, PR #508)

Prior to 0.25.7, japicmp incorrectly matched non-bridge methods against compiler-generated
bridge methods when comparing class versions. This caused the covariant return type change
above to go undetected for years. The fix in 0.25.7 corrected the bridge-method matching
logic, which now surfaces the 2023 change as METHOD_RETURN_TYPE_CHANGED.

Is This a Real Binary Incompatibility?

No. Covariant return types are explicitly supported by the Java Language Specification
(JLS §8.4.5) and are designed to be backward-compatible. When GenericVersionScheme
declares GenericVersion parseVersion(String), the Java compiler automatically generates
a bridge method:

// real method (new callers use this)
public GenericVersion parseVersion(String) { ... }
// compiler-generated bridge (preserves binary compatibility for old callers)
public synthetic bridge Version parseVersion(String) {
return this.parseVersion(String);  // delegates to real method
}

Any code compiled against the old API that calls Version v = scheme.parseVersion(...) will
find the bridge method at runtime and continue to work without recompilation. A
NoSuchMethodError cannot occur.

The only scenario where this change can cause a real (silent) breakage is subclassing:
if a third party extends GenericVersionScheme and overrides parseVersion with the old
Version return type, that override no longer overrides the non-bridge method. This is a
legitimate concern, but it is a different and narrower category than a full binary
incompatibility.

Relationship to japicmp

The detection itself is correct — the API did change in 2023 and japicmp 0.25.6 was
silently missing it due to its own bug. However, japicmp classifies covariant return type
changes in the same category as genuinely incompatible return type changes, which is
overly strict.

A dedicated issue has been filed with the japicmp project to introduce a separate, less
severe classification for this pattern (METHOD_RETURN_TYPE_COVARIANT_CHANGED), treated
as compatible by default:
👉 siom79/japicmp#522

Recommended Fix for This Project

Until japicmp handles covariant return type changes natively, the appropriate fix on the
maven-resolver side is to add explicit exclusion rules in the japicmp configuration for
these three methods. The 2023 change was intentional, well-motivated, and binary-safe:

<excludes>
  <exclude>
    org.eclipse.aether.util.version.GenericVersionScheme#parseVersion(java.lang.String)
  </exclude>
  <exclude>
    org.eclipse.aether.util.version.GenericVersionScheme#parseVersionRange(java.lang.String)
  </exclude>
  <exclude>
    org.eclipse.aether.util.version.GenericVersionScheme#parseVersionConstraint(java.lang.String)
  </exclude>
</excludes>

[cstamas]

@siom79 Many thanks!

[cstamas]

I propose to postpone japicmp update until siom79/japicmp#522 is fixed.

[siom79]

Just released 0.26.1. That should fix this issue.

[dependabot]

Superseded by #1893.