Metered license activation throws IllegalAccessError (GroupDocs.Comparison for Java 26.8)

GroupDocs.Comparison Product Family
1

Hi,

I was about to update GroupDocs.Comparison for Java to version 26.8, as it should fix a bug I reported earlier. However, the new version crashes when a metered license key is provided.

AI analysis below.

GroupDocs.Comparison for Java 26.8: metered license activation throws IllegalAccessError

Summary

Metered.setMeteredKey crashes with a message-less java.lang.IllegalAccessError on GroupDocs.Comparison for Java 26.8. Version 25.2 works with the same keys and environment. The cause is a resource path that the jar’s shading step did not relocate, so the failure is in the released artifact itself, not in user code or the JVM setup.

Environment

  • groupdocs-comparison 26.8 (Maven, from releases.groupdocs.com/java/repo/)
  • Java 21 (reproduced on Temurin 21.0.11 Linux x64 and 21.0.12.1 macOS arm64)
  • Valid metered license keys

Stack trace

Caused by: java.lang.IllegalAccessError
    at com.groupdocs.comparison.internal.c.a.t.rr.a(Unknown Source)
    at com.groupdocs.comparison.internal.c.a.t.rr.<clinit>(Unknown Source)
    at com.groupdocs.comparison.internal.c.a.t.Mm.<clinit>(Unknown Source)
    at com.groupdocs.comparison.internal.c.a.t.bX.setLicense(Unknown Source)
    ...
    at com.groupdocs.comparison.license.License.BiV(Unknown Source)
    at com.groupdocs.comparison.license.Metered.setMeteredKey(Unknown Source)

Root cause

Disassembling com.groupdocs.comparison.internal.c.a.t.rr (the shaded Aspose.Tasks licensing class) shows its static initializer reading 20 bytes at offset 315 from a classpath resource whose path is assembled from a byte array at runtime. The bytes decode to:

/com/aspose/tasks/resources/New project 2010.zip

The 26.8 jar ships this file only at the relocated path com/groupdocs/comparison/internal/c/a/t/resources/New project 2010.zip. Because the original path is built from bytes instead of a string constant, the relocation step could not rewrite it. getResourceAsStream returns null, the resulting NPE is caught, and the catch block rethrows new IllegalAccessError() with no message.

Reproduction

import com.groupdocs.comparison.license.Metered;

public class Repro {
  public static void main(String[] args) {
    // Valid metered keys are required: with invalid keys the call fails earlier
    // ("Authentication failed") and never reaches the broken code path.
    new Metered().setMeteredKey("<valid public key>", "<valid private key>");
  }
}

On 26.8 this throws the IllegalAccessError above after authentication succeeds. On 25.2 the same call succeeds.

Workaround

Copy com/groupdocs/comparison/internal/c/a/t/resources/New project 2010.zip out of the jar and place it on the application classpath at com/aspose/tasks/resources/New project 2010.zip. License activation and document comparison then work normally.

Suggested fix

Ship the resource at the path the licensing code reads, or rewrite the dynamically built path during relocation.

2

Hello,

Thank you for reporting this issue. We’re currently looking into it and will keep you updated as we make progress.

1 Like
3

Hi,

Thank you for the detailed report — your analysis was spot on, and it saved us a lot of time. We
reproduced the crash and it is now fixed.

What was happening. Applying a license reaches the bundled Aspose.Tasks engine, which loads one of its own resources from a path it assembles at run time instead of from a string constant. Because the path is built dynamically, our packaging step — which moves the bundled engines into the com.groupdocs.comparison.internal namespace — could not rewrite it, so the lookup missed the moved file and the failure surfaced as an IllegalAccessError with no message, exactly as you traced it.

One clarification worth adding: the resource layout itself did not change in 26.8. What changed is the version of the bundled Aspose.Tasks engine, and the newer engine reads that resource while a license is being applied, where the previous one did not. That is why 25.2 works for you — and 26.5 is unaffected as well, in case you need a stopgap.

Fix. The packaged jar now also ships that resource at the path the engine actually requests. Fixed
in 26.8.1.

<dependency>
    <groupId>com.groupdocs</groupId>
    <artifactId>groupdocs-comparison</artifactId>
    <version>26.8.1</version>
</dependency>

Once you are on 26.8.1 you can drop the workaround — the copy of New project 2010.zip on your application classpath is no longer needed (leaving it in place does no harm either).

The same release also restores a few public types and members that had been renamed by obfuscation and were therefore not resolvable against the published jar: ILogger, ConsoleLogger, CultureInfo, FontsHelper, Path, TemporaryFileManager (and its Default/Factory companions), IgnoreChangeSensitivitySettings, plus ComparerSettings.getLogger()/setLogger(), ComparisonLogger.setLogger(), CompareOptions.getIgnoreChangeSettings()/setIgnoreChangeSettings()
and SupportedLocales.isLocaleSupported(CultureInfo). Nothing was removed or renamed, so no migration is needed.

Could you give 26.8.1 a try with your metered keys and let us know how it goes? Two things in
particular would help us:

  1. Confirm that license activation now succeeds in your environment (Temurin 21 on Linux and macOS arm64).
  2. Confirm that the original issue you were upgrading for — IllegalStateException: unexpected node type 5 when comparing DOCX documents with many identical tables — is resolved on your documents.

If anything is still off, please let us know and we will look into it right away.