GroupDocs.Assembly for Java 26.9 Release Notes

Full list of changes in this release

Aspose components moved to the versions .NET is built against

The GOLD test data is generated by GroupDocs.Assembly for .NET, so the Java build has to use the same Aspose components; until now it was three to six years behind. The reason was the embedded venture license rather than the code: its subscription ran out on 2024-09-18, so every component released later refused it — Words, Email, Slides and BarCode threw, which applyFullLicenses() turned into a bare IllegalStateException, and Aspose.Cells silently kept stamping the evaluation watermark into every spreadsheet it wrote. That last one is a defect a customer could hit with a perfectly valid license.

With the license renewed (subscription until 2027-04-29) Words, Cells, Slides, Email and BarCode are now at the versions the .NET product uses: 26.3, 26.3, 26.2, 26.1 and 26.6. Documents produced by this version therefore differ byte for byte from the ones 26.8 produced, in the ways newer Aspose engines differ — w14:paraId / w14:textId markers on every paragraph, more default attributes on the shape and paragraph properties of presentations, a different set of parts in workbooks. The documented API is unchanged and nothing was removed or renamed.

The embedded Aspose license

The cipher text of the venture license now lives in a resource rather than in the generated code of AsposeLicenseProvider, so renewing it means replacing one file. The key and the initial vector stay in the code, moved into getCryptoKey() and getInitialVector() so that there is a single source of truth. tools/AsposeLicenseResourceGenerator.java takes a .lic, prints the product and the subscription date being embedded, rewrites the resource and verifies the round trip through AsposeLicenseProvider.getBytes(); the procedure is documented in README.md. The subscription of that license remains the upper bound on the Aspose versions this product can carry.

Resources of the repackaged Aspose.Foundation

com.aspose.ResourceManager resolves a resource relative to the package of the calling class, walking up to the parent packages and appending /resources/. JARJAR used to move the Aspose.Words resources into com.groupdocs.assembly.internal.c.a.w.resources, while Aspose.Foundation itself lands in com.groupdocs.assembly.internal.c.a — a parent package, so the lookup never reached them, and every template that needs the font fallback settings failed:

Aspose.Words native libs cannot be loaded. ...
java.lang.ExceptionInInitializerError
Caused by: java.lang.IllegalStateException:
    Resurce not found Aspose.Resources.MsOfficeFallbackSetting.xml.

The resources are routed to com.groupdocs.assembly.internal.c.a.resources instead, a parent package for Aspose.Foundation and for the Aspose.Words classes alike. The same defect is present in the released 26.7 and 26.8 JARs.

Barcodes

The barcode fixes of ASSEMBLYNET-60 never made it to Java and are ported here: the code text location of Pdf417, a transparent colour counting as undefined with black and white as the defaults, the minimum dimension of Codabar, and dropping the exception on an image too small for its barcode. Two more are specific to this platform: BarCode needs a minimum dimension for MaxiCode as well, because the Java build gives up at the dimension the product’s own templates produce, and the code text of a valid ITF6 is five digits rather than six.

Tests, GOLD data and licenses

The test documents and the GOLD files live in the .NET repository (groupdocs/bravo/assembly/net, folder testdata) and are the single source of truth for both platforms; TestGoldJava only carries the files where Java differs from .NET. tools/provision-test-data.ps1 keeps a sparse checkout of that one folder on the machine, links TestData, TestGold and TestGoldJava into the project root as junctions, and brings in the licenses — from the internal license server the runners point at with GROUPDOCS_LIC_PATH, or from an ASPOSE_TOTAL_LICENSE / GROUPDOCS_ASSEMBLY_LICENSE file when one is given. The GroupDocs.Assembly license is placed in all three locations the tests read it from (TestData/Licenses/SHA1/, TestData/ and the test classpath), which is what TestSamples needs to run at all.

With the data, the licenses and the current components in place the whole suite runs on the runner: the run_tests job no longer passes -Dqa.skip.junit=true. Failing GOLD comparisons still do not fail the job while the remaining differences between the two platforms are worked through.

The published package

The rest comes from a verification of the published 26.8 package. The manifest carried no Automatic-Module-Name, so on the module path the module name was derived from the file name — precisely what the artifact id above changed; it is declared as com.groupdocs.assembly now. Of the five Aspose components merged into the jar only Slides and Email had their third party notice inside it, the other three being present in the zip distribution alone, and no document in the jar described the product itself; the three missing notices are copied into META-INF next to a NOTICE.GroupDocs.Assembly.txt that names the product, its license and what it embeds. Finally, the license URL of both poms and of the EULA pages shipped in the zip pointed at company.groupdocs.com, which is a CNAME to a CloudFront distribution that no longer exists and does not resolve at all; the same had happened to company.aspose.com in the Aspose EULA next to it. Both point at their about. addresses now.

Coverage and static analysis

Coverage is imported from the JaCoCo XML report now: sonar.jacoco.reportPath with the binary jacoco.exec was dropped by SonarJava 7 and is silently ignored by the 9.9 server this project is analysed on. Two more defects were in the way — the hardcoded surefire <argLine> overwrote the -javaagent of prepare-agent, and the test profile switched off the activeByDefault development one, which is where build-helper-maven-plugin was declared, so mvn test -Ptest did not even compile. Measured with the GOLD data and a license in place, src/main is covered at about 82%.

The analysis itself is now limited to the hand-written Java. Most of src/main/java is produced by JavaPorter from the .NET sources and carries the “THIS FILE IS AUTO PORTED” or “THIS FILE IS AUTO GENERATED” marker; those files cannot be edited on their own without diverging from .NET, and their logic is already analysed as C# in the .NET project, so sonar.issue.ignore.allfile skips them by that marker. What remains — the PAL helpers, FontLoader, NetInputStream, MeteredUtil and friends — is analysed as before, and the findings that were reviewed and accepted (the null guards of the ported code, the volatile caches of the licensing module, the widened integer arithmetic, the IEnumerator semantics of the enumerator adapters) carry their reasoning in the scanner configuration.