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

Add support for using versionned symbols #189

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

smortex
Copy link

@smortex smortex commented Apr 10, 2019

This is a follow-up to jnr/jffi#66 and use the new API to make it possible to access versioned symbols in a shared library.

Please note that I usually don't do Java. Instructions for improvements are welcome so that I can update the PR!

With my knowledge of Java, I could not find a better way to access two versions of the same function by assigning a new unique name for each function name and version combinaison. I therefore added 2 annotations that can be used on a function to indicate the actual function name (Function annotation) and the version to use (Version annotation).

The test suite therefore tests:

  • A function with it's normal exported name without setting a version: answer;
  • A function with it's normal exported name setting a specific version: answer (in another class);
  • An internal functions for the old implementation without setting a version: old_answer;
  • An internal functions for the new implementation without setting a version: new_answer;
  • Two function with a random name using a custom name (the normally used exported name) and specific versions: answer_1_0 and answer_1_1.

CI failures are expected at this stage since jffi changes have not been merged yet.

This is a follow-up to jnr/jffi#66 and use the
new API to make it possible to access versioned symbols in a shared
library.
@headius
Copy link
Member

headius commented Jun 12, 2020

Ok, waking this up again since it came up on #133.

The limiting factor here is still rebuilding everything. It may be possible to build only for some platforms if there's a way to guard against calling the new native binding, so for example we would use the existing Foreign.getVersion to check whether the library has been updated.

I need to double-check that, though, since I don't remember when JNI tries to actually bind the native functions in a given class. I think it's lazy.

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.

None yet

2 participants