GroupDocs.Comparison for Java 26.9 Release Notes

Full list of changes in this release

Fix — PDF comparison fails on documents that use a blend mode

Comparing any PDF whose content stream invokes an ExtGState containing /BM failed with

java.lang.IllegalArgumentException: com.groupdocs.comparison.internal.c.a.pd.D is not an enum type

The blend mode value was irrelevant — even /BM /Normal triggered it — and comparing an affected document against itself failed just as reliably. Since transparency groups and soft masks are emitted by most modern PDF producers, a large share of real-world documents were affected.

Root cause was in packaging, not in comparison. The obfuscation step of the release build removed the synthetic values() method from internal enum classes. Enum.valueOf() resolves values() reflectively through Class.enumConstantDirectory, so parsing such an enum by name could not succeed. com.aspose.pdf.BlendMode is parsed by name whenever /BM is present.

Scope.

• Affects 25.2 through 26.8.2. 24.7 and earlier are unaffected, because blend mode was not modelled as an enum in those builds.
• The defect was not limited to blend modes — it applied to every internal enum resolved from a string, so other is not an enum type failures are resolved by the same fix.
• Comparison behaviour, results and public API are unchanged; this is a packaging fix and no migration is needed.

Fix — failures while opening a PDF reported as a password error

Both code paths that open a PDF caught every exception raised during loading and rethrew it as

com.groupdocs.comparison.common.exceptions.ComparisonException: Incorrect password.

regardless of the actual cause, so an unencrypted document could report a password problem and the original error was lost.

The loading path now rethrows a ComparisonException unchanged instead of relabelling it, and wraps any other failure while preserving the original exception as the cause:

try (Comparer comparer = new Comparer(sourcePath)) {
    comparer.add(targetPath);
    comparer.compare(resultPath);
} catch (ComparisonException e) {
    System.out.println(e.getMessage());  // states what actually failed
    System.out.println(e.getCause());    // the underlying exception, previously discarded
}

Scope.

• Genuine password errors are unchanged: PasswordProtectedFileException and InvalidPdfPasswordException are still thrown as before, as is UnsupportedPdfFormatException for damaged or unsupported files.
• Only the catch-all path changed. Code that matched on the literal text Incorrect password. to detect unrelated failures will no longer match — which is the intent of the fix.

Feature — stable module name for JPMS

The jar now carries Automatic-Module-Name: com.groupdocs.comparison in its manifest. On Java 9 and later it therefore resolves as a named automatic module instead of deriving a module name from the file name, which changed with every release and could not be relied on in a module-info.java:

module com.example.app {
    requires com.groupdocs.comparison;
}

Scope.

• Nothing changes for applications on the class path, or for Java 8.

Fix — packaging metadata and third-party licences

The published artifact was missing metadata that dependency and compliance tooling expects:

• the POM declared no <licenses>, so nothing stated the terms the artifact ships under, and no <developers>, so it had no documented owner. Both are now present, pointing at the GroupDocs License Agreement;
• the jar redistributes the Bouncy Castle cryptographic library (embedded by Aspose.CAD) but shipped no licence document covering it. META-INF/ThirdPartyLicenses-BouncyCastle.txt now carries its MIT licence text;
• there was no third-party notice for the product itself. META-INF/ThirdPartyLicenses-GroupDocs.Comparison.txt now lists the redistributed components and points at the per-vendor documents already in the jar.

Scope.

• Metadata and documentation only — no code, no behaviour and no API changed. (COMPARISONJAVA)

Update — manifest copyright year

The manifest Copyright attribute ran to 2024 while the jar was being built in 2026. The end year is now generated during the build, so it cannot fall behind again.

Resources

• Downloads — GroupDocs.Comparison for Java
• GitHub — GroupDocs.Comparison for Java examples