Add bundled filter plugin directory to HDF5 plugin search path#478
Merged
Conversation
Datasets written with the HDF5 filter plugins bundled in an HDFView installation could not be read unless the user manually added the plugin directory under User Options. Trying to open such a dataset failed because the library had no registered plugin path pointing at the bundled filters (HDFGroup#477). This happened because HDFView never established a plugin-path policy of its own. At startup it read back whatever paths the HDF5 native library already had, via ViewProperties.loadPluginPaths() -> H5Plugins.getPluginPaths() -> H5PLget(). Those paths were just the defaults compiled into the native jarhdf5 library at compile time, persisting github-runner specific paths into the published builds. HDFView takes a prefix-built HDF5 library and relocates it into a jpackage bundle at $APPDIR. HDF5 has no $ORIGIN-relative plugin discovery, so the prefix-relative default points at a path that does not exist on the end user's machine. Installers copy the bundled filters into <root>/plugin (e.g. <install>/lib/app/plugin on Linux, where jpackage sets hdfview.root to $APPDIR; see hdfview/pom.xml), a location the library's compiled-in defaults can never name. Because only the running app knows its actual install location, the correct path can only be supplied at runtime, by the application. This PR gives HDFView an explicit plugin-path policy in initPluginPaths(), called once at startup. It loads the library's existing paths, then resolves <hdfview.root>/plugin and, if that directory exists and is not already registered, prepends it via ViewProperties.prependPluginPath() -> H5PLprepend() so the bundled filters take precedence over stale/system defaults. The path is recomputed from hdfview.root on every launch, so it should be accurate across multiple installs and reinstalls. It should also do no harm when no such directory exists. The prefix-relative default remains in the library-reported list but is harmless, since the correct location is present and searched first. Fixes HDFGroup#477
jhendersonHDF
approved these changes
Jul 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Datasets written with the HDF5 filter plugins bundled in an HDFView installation could not be read unless the user manually added the plugin directory under User Options. Trying to open such a dataset failed because the library had no registered plugin path pointing at the bundled filters (#477).
This happened because HDFView never established a plugin-path policy of its own. At startup it read back whatever paths the HDF5 native library already had, via ViewProperties.loadPluginPaths() -> H5Plugins.getPluginPaths() -> H5PLget(). Those paths were just the defaults compiled into the native jarhdf5 library at compile time, persisting github-runner specific paths into the published builds.
HDFView takes a prefix-built HDF5 library and relocates it into a jpackage bundle at $APPDIR. HDF5 has no $ORIGIN-relative plugin discovery, so the prefix-relative default points at a path that does not exist on the end user's machine. Installers copy the bundled filters into /plugin (e.g. /lib/app/plugin on Linux, where jpackage sets hdfview.root to $APPDIR; see hdfview/pom.xml), a location the library's compiled-in defaults can never name. Because only the running app knows its actual install location, the correct path can only be supplied at runtime, by the application.
This PR gives HDFView an explicit plugin-path policy in initPluginPaths(), called once at startup. It loads the library's existing paths, then resolves <hdfview.root>/plugin and, if that directory exists and is not already registered, prepends it via ViewProperties.prependPluginPath() -> H5PLprepend() so the bundled filters take precedence over stale/system defaults.
The path is recomputed from hdfview.root on every launch, so it should be accurate across multiple installs and reinstalls. It should also do no harm when no such directory exists. The prefix-relative default remains in the library-reported list but is harmless, since the correct location is present and searched first.
Fixes #477