-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Finer snaploader implementation #1
Finer snaploader implementation #1
Conversation
This is analogous to the this example. This example essentially delegates the platform-dependent path formulation to the |
If you don't mind, I will create a PR on Jolt-jni to try this strategy since it works fine here. EDIT: final Path extractionPath = Paths.get(PropertiesProvider.USER_DIR.getSystemProperty(),
"libs", NativeVariant.OS_NAME.getProperty(), NativeVariant.OS_ARCH.getProperty()); On the Jolt-jni build, you have to build into these directories, by doing that, you will keep the Jolt-jni utilities clean and robust to new platform runtimes. |
I'm unclear what the purpose of the PR is. I see it changes the extraction path, from the working directory [user.dir] to the user's home directory [user.home] . Does it do anything else? |
This PR doesn't change the extraction directory path, but it changes the format of the code. This way is the best practiced way, and in case you want to define a custom extraction path, you will append it to the You asked me for the best practice code, and a better refinement for Jolt-jni loader. This is an initiative example of that. |
My request was for help with "the loading code in jolt-jni", not the code here in snap-jolt. |
In any case, I updated the Readme to reflect the basic practice, the best practice, and a customized approach. |
This PR adds the following:
java.nio.file.Path
andjava.nio.file.Paths
to formulate a platform-independent extraction path.