[Release] GroupDocs.Search for Java 26.9

GroupDocs.Search Product Family
, ,
1

Dear GroupDocs users, we’re pleased to announce GroupDocs.Search for Java 26.9. This release introduces a new index format built on a multi-array tree, moves HTML extraction into the product itself, and fixes a group of defects that made index merging and document deletion unreliable — in one case impossible — on larger indexes. Existing indexes are upgraded rather than rebuilt, and the public API is unchanged, so no code changes are required.

Feature — new index format, with an upgrade path

The on-disk index format moves from 25.4 to 26.7. The term tree is now a multi-array tree with Huffman coded storage and lives in its own index1.info file, rather than a character tree stored inside index.info. Indexes written by 22.7 through 25.4 are upgraded by IndexUpdater, which copies the index directory and rewrites its metadata, rebuilding the term tree in the new layout while preserving the term-to-identifier mapping every segment depends on.

IndexUpdater.update(indexFolder);
Index index = new Index(indexFolder);

Scope.

  • Documents are not indexed again — only the index metadata and the term tree are rewritten.
  • Indexes older than 18.5 remain non-upgradable, as in previous releases.
  • Search behaviour and the public API are unchanged.

Feature — HTML extracted by the product itself

.html, .htm and .xhtml no longer go through GroupDocs.Parser. Tags, character entities, preformatted blocks, scripts, styles and table structure are handled by an extractor that ships with the product, which removes a round trip through the parser for what is often the bulk of a web content corpus.

Scope.

  • A custom extractor registered for any of these extensions still takes precedence, exactly as before.
  • Extracted text can differ in whitespace and in how markup edge cases are flattened, so a corpus indexed with 26.6 and the same corpus indexed with 26.9 are not guaranteed to be identical. Re-index if you compare extraction output between versions.

Fix — index merging, document deletion and large indexes

Four defects in the same area are fixed:

  • merging failed outright with ClassCastException: [[J cannot be cast to [J as soon as a merged node grew past its initial 32-child cache;
  • offsets are written one byte at a time and read back four at a time, and one reading site combined them as signed Java bytes. Any byte with its high bit set poisoned the offset, so indexes stayed healthy while offsets were below 128 and silently lost postings above it, whenever a segment was re-read on delete, on merge or when loading an in-memory index;
  • deleting documents could leave the index half updated, because Segment.loadOffsets never closed its file handle and the offset file could then not be renamed;
  • buffer growth multiplied the current length by 1.5 in int arithmetic and overflowed near the maximum array length, during merging, segment conversion and document removal alike. A stale reference to the same buffer produced an ArgumentException mid-merge.

Scope.

  • The offset defect shows up as missing search results rather than as an exception, so it can go unnoticed. If you hold a large index that was built, merged or had documents deleted under an affected version, rebuild it to be certain of its contents.
  • The other three are fixed in place and need no migration.

Fix — documents inside archives lost their inner path

A search that matched a document nested in an archive returned the archive itself with an empty inner path, so a match in Folder2/InnerArchive.zip/Folder371/report.docx reported only the outer file. The index held the nested entries all along, three levels deep through zip inside zip inside pst; only the lookup by document identifier discarded them. Existing indexes are unaffected and need no rebuild.

Fix — OneNote extraction failed in released builds

Text extraction from .one documents threw a NullPointerException raised inside the OneNote support that GroupDocs.Parser carries, in released builds only. The cause was in packaging rather than in extraction: the obfuscation step of our release build shrinks unreferenced code and removed library classes that are only reached reflectively, among them roughly half of the OneNote support. The release configuration now keeps GroupDocs.Parser whole, as it has always kept GroupDocs.Metadata. Behaviour and API are unchanged; the released jar is about 80 MB larger as a result.

Fix — one metadata property could cost a whole document

Indexing png, tif, tiff, asf and mpp failed with ArrayIndexOutOfBoundsException: Index 17 out of bounds for length 17 raised inside GroupDocs.Metadata before any value was read. It hands out properties, Exif.ExifIfd and Exif.GpsIfd among them, that its own value dispatch cannot handle, and a single such property used to take down the entire document. The value is now read through another accessor that still carries it, so nothing is lost.

Also in this release

.csv and .tsv are no longer forced on the parser as spreadsheets, which matters now that the release moves to GroupDocs.Parser 26.9 — from 26.4 on the parser refuses delimited text under that format while detecting it correctly by itself. The jar declares Automatic-Module-Name: com.groupdocs.search, so on Java 9 and later it resolves as a named automatic module; the published POM declares <licenses> and <developers>; a licence document for the redistributed Bouncy Castle library and a product-level third-party notice ship in the jar; and the jar no longer carries TestNG or resources orphaned by the relocation of its dependencies. GroupDocs.Metadata moves to 26.7 and the Aspose libraries to current versions.

Resources