Dear GroupDocs users, we’re pleased to announce GroupDocs.Search for Java 26.9.1. This maintenance release fixes a packaging defect that made indexing on Windows log an UnsatisfiedLinkError from the font subsystem for almost every Word or PDF document, and left the Windows font registry unread. The release is backward compatible: search behaviour, results and the public API are unchanged, indexes created with 26.9 open as they are, and no code changes are required.
Fix — Windows font lookup failed with an UnsatisfiedLinkError
Indexing almost any Word or PDF document on Windows logged a SEVERE record carrying java.lang.UnsatisfiedLinkError: ... WindowsNativeCall.readRegistryStringValues(int, java.lang.String), usually twice per run, while indexing itself carried on. 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. Our 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.
- This is a packaging fix: no migration is needed, and upgrading from 26.9 is a drop-in replacement.
Resources