[Release] GroupDocs.Assembly for Java 26.10

GroupDocs.Assembly Product Family
, ,
1

Dear GroupDocs users, we’re pleased to announce GroupDocs.Assembly for Java 26.10. This release fixes the defects found by running our public example suite against 26.9, most importantly the failure of plain Java data sources on JDK 17 and later. The bundled Aspose components and the Java 8 baseline are the same as in 26.9, and the public API only gains the barcode resolution setters, so no code changes are required.

Maven coordinates:

<dependency>
    <groupId>com.groupdocs</groupId>
    <artifactId>groupdocs-assembly</artifactId>
    <version>26.10</version>
</dependency>

Fix — plain Java data sources on JDK 17 and later

On JDK 17 and later every template that took its data from a plain Java object failed, although the same code worked on JDK 8 and 11:

Can not resolve method 'getCustomer' on type 'class Order'.

The engine generates a helper class per data type at run time, and until now it loaded that class through a JDK internal that is closed since JDK 16. It uses a public API for this now.

Scope.

  • Plain Java objects work as data sources on JDK 17, 21 and later with no JVM flags and no code changes.
  • The workarounds for earlier versions, DocumentAssembler.setUseReflectionOptimization(false) and --add-opens java.base/java.lang=ALL-UNNAMED, are no longer needed. They do no harm if you keep them.
  • Affects every earlier version running on JDK 16 or later, 26.9 included.

Fix — data models typed by an interface

A data object whose collection was typed by an interface, for example Collection<IItem>, could not be iterated at all and failed with IncompatibleClassChangeError: Found interface IItem, but class was expected.

Scope.

  • Iteration, where(...), count() and methods declared by a superinterface work on interface-typed models.

Feature — indexer syntax on Java objects

Templates written for GroupDocs.Assembly for .NET often use indexer syntax such as <<[root["Name"]]>>. In Java this syntax never resolved and failed with “Can not resolve an indexer”.

Scope.

  • obj["key"] resolves to a call of get_Item or get with the same arguments.
  • This covers java.util.Map (root["Name"]), java.util.List (root.getList()[1]) and any class that declares a get(String) or get(int) method.

Fix — nested JSON objects passed to a method taking a DataRow

A known-type method taking a single DataRow could not be called with a JSON object reached by name: <<[Funcs.rowName(root.person)]>> failed with “Can not resolve method ‘rowName’”, and only an overload taking Iterable<DataRow> worked. The fix made in GroupDocs.Assembly for .NET 26.7 is now in Java as well.

Scope.

  • A JSON object is passed as a DataRow when the method has no overload that accepts it as is.
  • An existing overload taking Iterable<DataRow> or Object keeps being called, so working templates, including the workarounds suggested earlier, are not affected.
  • A reference that yields several rows, such as a JSON array, is reported with “A single child data row is expected, but multiple child data rows are found”. (ASSEMBLYJAVA-257)

Fix — Boolean values in <<if>> and <<check>>

A Boolean passed as a data source printed fine with <<[flag]>>, but <<if [flag]>> and the documented <<check [conditional_expression]>> rejected it with “A conditional expression should return a Boolean value”.

Scope.

  • java.lang.Boolean data sources and getters returning Boolean are accepted by <<if>>, <<check>> and the removal flag of a chart series.
  • Expressions of other types are still rejected with the same message.

Fix — presentation charts whose title is deleted

A presentation chart with its title deleted brought the assembly down with an internal NullPointerException instead of being assembled.

Scope.

  • Such charts are assembled, and they keep having no title.
  • Problems in the tags of such a chart are reported with the regular template error messages.

Fix — UnsatisfiedLinkError in the log on Windows

Since 26.7 the first render that needed font data on Windows logged two UnsatisfiedLinkError stack traces at SEVERE level. The assembly itself completed correctly, but the entries looked like a fatal error to log monitoring.

Scope.

  • The stack traces are gone, and the assembled documents are the same.
  • A one-line notice “Aspose.Words native libs cannot be loaded” can still appear on System.err, without a stack trace. It is informational.

Fix — barcode resolution can be set

BarcodeSettings.setResolution, setXResolution and setYResolution were not public in Java, so the resolution of barcode images could not be set.

Scope.

  • The three setters are public, as in .NET:
DocumentAssembler assembler = new DocumentAssembler();
assembler.getBarcodeSettings().setResolution(300);

Resources