[Release] GroupDocs.Comparison for Java 26.9

GroupDocs.Comparison Product Family
, ,
1

Dear GroupDocs users, we’re pleased to announce GroupDocs.Comparison for Java 26.9. This release fixes a packaging defect that made PDF comparison fail on documents using a blend mode — a large share of real-world PDFs — and removes a misleading Incorrect password. error that masked the actual cause of any failure while opening a PDF. It also gives the jar a stable module name for JPMS and completes its licence metadata. The release is backward compatible; comparison behaviour and the public API are unchanged, and no code changes are required.

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: ... is not an enum type. The blend mode value made no difference — even /BM /Normal triggered it — and comparing an affected document against itself failed just as reliably. Because transparency groups and soft masks are emitted by most modern PDF producers, many everyday documents were affected.

The cause was in packaging rather than in comparison. The obfuscation step of our release build removed the synthetic values() method from internal enum classes. Enum.valueOf() resolves values() reflectively through Class.enumConstantDirectory, so resolving such an enum by name could not succeed, and the PDF blend mode is resolved 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 specific 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 results and the public API are unchanged, so 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 ComparisonException: Incorrect password., regardless of the actual cause. An unencrypted document could therefore report a password problem, and the original error was discarded. The loading path now rethrows a ComparisonException unchanged instead of relabelling it, and wraps anything else 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 point of the fix. (COMPARISONJAVA)

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 resolves as a named automatic module instead of deriving a module name from the file name, which changed with every release and so could not be named in a module-info.java.

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

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 now declares <licenses> — pointing at the GroupDocs License Agreement — and <developers>. The jar now ships a licence document for the Bouncy Castle library it redistributes (embedded by Aspose.CAD), and a product-level third-party notice listing the redistributed components. This is metadata and documentation only: no code, behaviour or API changed. The manifest copyright year is now generated at build time as well, instead of being pinned to a year that had fallen behind.

Resources