Skip to content
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

Closed

Conversation

pavly-gerges
Copy link
Contributor

@pavly-gerges pavly-gerges commented Jul 27, 2024

This PR adds the following:

  • The use of the java.nio.file.Path and java.nio.file.Paths to formulate a platform-independent extraction path.
  • A placeholder code for the Jar compression path code.

@pavly-gerges
Copy link
Contributor Author

pavly-gerges commented Jul 27, 2024

This is analogous to the this example.

This example essentially delegates the platform-dependent path formulation to the java.nio.file APIs, in which the path formulation depends on the JRE implementation, and not specifically on hard-coded platform path. This is deemed the best way to extract, and load native binaries in a cross-platform API, and you could embed it in a Java utility for sure.

@pavly-gerges
Copy link
Contributor Author

pavly-gerges commented Jul 27, 2024

If you don't mind, I will create a PR on Jolt-jni to try this strategy since it works fine here.

EDIT:
Well, looking back on the TestUtils, it seems that the files are on the local disk in some arbitrary file names, in that case, for an easier use, I recommend using the same directory names as the one from "OS_NAME + ARCH" from the properties provider, so that you will bypass the manual conditional statements... Just like this:

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.

@stephengold
Copy link
Owner

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?

@pavly-gerges
Copy link
Contributor Author

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 USER_DIR property, as the documented code explains...

You asked me for the best practice code, and a better refinement for Jolt-jni loader. This is an initiative example of that.

@stephengold
Copy link
Owner

My request was for help with "the loading code in jolt-jni", not the code here in snap-jolt.
Sorry for the misunderstanding.

@pavly-gerges pavly-gerges deleted the snaploader-finer-impl branch July 28, 2024 04:17
@pavly-gerges
Copy link
Contributor Author

In any case, I updated the Readme to reflect the basic practice, the best practice, and a customized approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants