GroupDocs.Search for Java 26.9.1 Release Notes

Full list of changes in this release

IDSummaryCategory
SEARCHJAVAWindows font lookup no longer fails with UnsatisfiedLinkError in WindowsNativeCall.readRegistryStringValuesFix

Fix — Windows font lookup failed with an UnsatisfiedLinkError

Indexing almost any Word or PDF document on Windows logged a SEVERE record with this stack trace, usually twice per run, while indexing itself carried on:

java.lang.UnsatisfiedLinkError: 'java.util.Map com.groupdocs.search.internal.c.a.w.internal.a1.WindowsNativeCall.readRegistryStringValues(int, java.lang.String)'
  at com.groupdocs.search.internal.c.a.w.internal.a1.WindowsNativeCall.readRegistryStringValues(Native Method)
  ...
  at ...SystemFontSource.getFontDataInternal(Unknown Source)
  ...
  at ...FontSettings.resetFontSources(Unknown Source)

Because the call failed, the system font source could not read the Windows font registry, and font metrics fell back to whatever could be found another way.

The cause was in packaging rather than in indexing. The JVM derives the symbol of a native method from the fully qualified name of the class that declares it, and the native library shipped beside that class exports Java_com_aspose_words_internal_a1_WindowsNativeCall_readRegistryStringValues. The release build relocated the class out of com.aspose.words, so no exported symbol matched any more. The class now keeps its original name, which is how the library that ships it expects it to be packaged.

Scope.

  • Affects 26.6 and 26.9 on Windows. 24.6 and earlier are unaffected, and the native library involved exists only for Windows.
  • Nothing was thrown to the calling code and indexing completed, so the visible effect was a noisy log and fallback font metrics rather than failed indexing.
  • Search behaviour, results and the public API are unchanged; this is a packaging fix and no migration is needed. Indexes created with 26.9 open in 26.9.1 as they are. (SEARCHJAVA)

Resources