Skip to content

Fix UnSatisfiedLinkError when trying to load non-existent libraries - #47

Open
pavly-gerges wants to merge 7 commits into
masterfrom
fix-ule-load
Open

pavly-gerges wants to merge 7 commits into
masterfrom
fix-ule-load

Conversation

@pavly-gerges

Copy link
Copy Markdown
Member

This PR introduces LibraryNotFoundException as a guard against directly loading non-existent file regardless of whether they are actual binaries or corrupted files.

Furthermore, the PR introduces a way to antagonize the effect of initializing a FileOutputStream by the FileExtractor API that by default creates a blank file (or opaque file); bypassing the formerly mentioned "LibraryNotFoundException".

In addition, it also introduces an example that shows how to deal with broken features using FileExtractionListener interface.

@pavly-gerges pavly-gerges added enhancement New feature or request core Core API related stuff examples Stressful testing the functionalities labels Oct 4, 2026
@codacy-production

codacy-production Bot commented Oct 4, 2026 •

Copy link
Copy Markdown

Not up to standards ⛔

🔴 Issues 2 minor

Alerts:
⚠ 2 issues (≤ 0 issues of at least minor severity)

Results:
2 new issues

Category Results
Documentation 2 minor

View in Codacy

🟢 Metrics 101 complexity · 3 duplication

Metric Results
Complexity 101
Duplication 3

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@pavly-gerges

pavly-gerges commented Oct 4, 2026 •

Copy link
Copy Markdown
Member Author

@stephengold You shouldn't catch exceptions anymore, the standard way to deal with exceptions and errors thrown from the API is to use both NativeBinaryLoadingListener and the FileExtractionListener instead. This removes the burden of trying to identify which exception or error is thrown.

EDIT:
Diagnostics could be built upon examining the causative error/exception and the calling stack from these listeners. FileExtractionListener deals with the part that is responsible for locating and extracting the binary from the compression. (NB: there exists FileLocalizingListener; it appears that it is redundant at the NativeBinaryLoader level and its instance is subjected for removal).

Btw, it appears that the techdemos that demonstrate the library features using jolt-jni are broken. Will you please consider submitting a fix for them after this PR?

@stephengold

Copy link
Copy Markdown
Contributor

it appears that the techdemos that demonstrate the library features using jolt-jni are broken. Will you please consider submitting a fix for them after this PR?

Of course. I have many projects that use jSnapLoader. Can you be specific about which projects are broken and how they are broken?

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

core Core API related stuff enhancement New feature or request examples Stressful testing the functionalities

Projects

None yet

Development

Successfully merging this pull request may close these issues.

NativeBinaryLoader.loadLibrary() fails silently if clean extraction fails

2 participants