GroupDocs.Search for Java 26.9 Release Notes

Full list of changes in this release

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. The upgrade 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.
• The spelling corrector still uses a character tree, so a search context now keeps a fuzzy-searcher pool for each of the two tree kinds. This is internal and needs no action.
• 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.
• No public API changed, and nothing needs to be registered or enabled.

Fix — index merging did not work

Growing the branch cache beyond its initial 32 children called an array helper that picks its implementation by element type, and for a jagged long[][] it cast to long[]:

java.lang.ClassCastException: [[J cannot be cast to [J

Any merge that produced a node wider than the initial cache failed, so merging, safe update and everything built on them were affected.

Scope.

• Affects 26.6. Fixed on every merge path, including the one in the new multi-array tree.
• Indexes written before the fix are sound; no migration is needed.

Fix — large offsets were corrupted

Offset files are written little-endian one byte at a time and read back by combining four bytes. One reading site combined them as signed Java bytes, so as soon as a byte had its high bit set it sign-extended and poisoned the whole offset.

Offsets below 128 were unaffected, which is why small indexes looked healthy while larger ones silently lost postings whenever a segment was re-read from disk: on delete, on merge, and when loading an in-memory index.

Scope.

• The symptom is missing search results rather than 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.

Fix — deleting documents left the index half updated

Segment.loadOffsets opened a file stream and never closed it. Document removal reads the old segment’s offsets through that method, so by the time the offset file was renamed the handle was still open, the rename was refused, and the operation queue aborted:

IOException: File was not moved
  SegmentInFile.renameOffsetFile
  RenameOffsetFileOperation.executeProtected

Scope.

• Most visible on Windows, which refuses to rename an open file.

Fix — OverflowException and ArgumentException on large indexes

Buffer growth multiplied the current length by 1.5 in int arithmetic, which overflows as the buffer approaches the maximum array length. Segment merging, segment conversion, document removal and the inverted index each carried their own copy of that code. They now share one holder that grows safely and, at the array limit, reports the real condition:

InvalidOperationException: The array length has already reached its maximum value.

A second fault in the same area cached a reference to the index data buffer that went stale when the buffer was replaced mid-merge, producing an ArgumentException.

Scope.

• Only reachable on indexes large enough to grow a buffer into the region near Integer.MAX_VALUE.

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: walking getIndexedDocumentItems shows them with full paths, three levels deep through zip inside zip inside pst. Only the lookup by document identifier discarded them.

Scope.

• Existing indexes are unaffected and need no rebuild. The defect was in the lookup, not in what was written.

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, while the same documents indexed cleanly in development builds.

The cause was in packaging rather than in extraction. The obfuscation step of the release build shrinks unreferenced code, and it 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.

Scope.

• Extraction behaviour, results and public API are unchanged, so no migration is needed.
• 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
  at com.groupdocs.metadata.core.ValueAcceptor
  at com.groupdocs.metadata.core.PropertyValue.acceptValue

GroupDocs.Metadata 26.7 hands out properties, Exif.ExifIfd and Exif.GpsIfd among them, that its own value dispatch cannot handle, and the failure arrives before any value is read. A single such property used to take down the whole document. The value is now read through another accessor that still carries it, so nothing is lost.

Scope.

• The underlying defect is in GroupDocs.Metadata and reproduces with GroupDocs.Search out of the picture entirely; this release works around it.

Fix — delimited text is no longer forced to a spreadsheet format

.csv and .tsv were mapped to FileFormat.Spreadsheet and that format was passed to the parser explicitly. From GroupDocs.Parser 26.4 on, the parser refuses delimited text when it is told the format is a spreadsheet, while its own detection reads both correctly, so the map no longer forces a format.

Scope.

• Relevant to this release because it moves to GroupDocs.Parser 26.9. Under the parser used by 26.6 the forced format was still accepted.

Fix — packaging metadata, third-party licences and jar contents

The published artifact was missing metadata that dependency and compliance tooling expects, and carried files that do not belong in a product jar:

• the POM declared no <licenses>, so nothing stated the terms the artifact ships under, and no <developers>, so it had no documented owner. Both are now present, pointing at the GroupDocs License Agreement;
• the jar redistributes the Bouncy Castle cryptographic library but shipped no licence document covering it. META-INF/ThirdPartyLicenses-BouncyCastle.txt now carries its licence text, and META-INF/ThirdPartyLicenses.GroupDocs.Search.Java.txt lists the redistributed components;
• the jar contained TestNG together with its transitive files, and resources orphaned by the relocation of its dependencies. Unpacking the jar now yields com and META-INF, and nothing else;
• the manifest declares Automatic-Module-Name: com.groupdocs.search, so on Java 9 and later the jar resolves as a named automatic module instead of deriving a module name from the file name, which changed with every release:

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

Scope.

• Metadata, documentation and packaging only — no code, no behaviour and no API changed.
• Nothing changes for applications on the class path, or for Java 8.

Update — manifest copyright year

The manifest Copyright attribute is generated during the build rather than pinned, so it cannot fall behind the year the jar was built in.

Update — dependencies

Public API

No public class, interface or method was added, removed or changed in this release. The only compatibility consideration is the index format above, which the index updater handles.

Resources

• Downloads — GroupDocs.Search for Java
• GitHub — GroupDocs.Search for Java examples