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

[jnigen] Don't break method names #1529

Open
HosseinYousefi opened this issue Sep 6, 2024 · 4 comments
Open

[jnigen] Don't break method names #1529

HosseinYousefi opened this issue Sep 6, 2024 · 4 comments

Comments

@HosseinYousefi
Copy link
Member

Let's say that we have two methods void foo(float a) and void foo(double a). JNIgen generates these as void foo(double a) and void foo1(double a), the user can go ahead and use these methods as intended – using the first one for floats and the second one for doubles.

Now say an update of this code, swaps the order of the methods so now foo needs to be run on doubles and foo1 on floats. There will be no compilation error and the code fails in mysterious ways.

Once #746 lands, we can use the same generated yaml/json to see what the mappings signatures were before the regeneration and warn if the naming changes.

@liamappelbe Something to keep in mind for ffigen as well.

@dcharkes
Copy link
Collaborator

An alternative would be to make the generator "remember" the naming choices it made before and bootstrap from that naming choice when generating dependent code or code for updated JARs - making the choice sticky and therefore much less breaking.

We could possibly use the existing "imports" mechanism for this?

@HosseinYousefi
Copy link
Member Author

HosseinYousefi commented Sep 10, 2024

We could possibly use the existing "imports" mechanism for this?

Yes. That's what I referred to in the description:

Once #746 lands, we can use the same generated yaml/json to see what the mappings signatures were before the regeneration and warn if the naming changes.

s/warn if the/use the same/!

@johnmccutchan
Copy link

Once #746 lands, we can use the same generated yaml/json to see what the mappings signatures were before the regeneration and warn if the naming changes.

Warning developers is not an acceptable solution. We cannot break users of generated code just because a method was added to an existing class. Full stop.

It sounds like when we generate the bindings, we need to generate a snapshot (json or whatever) of the mapping and when generating bindings jnigen will open that snapshot and use it ensure stable mappings.

@HosseinYousefi
Copy link
Member Author

Warning developers is not an acceptable solution. We cannot break users of generated code just because a method was added to an existing class. Full stop.

Agreed.

@HosseinYousefi HosseinYousefi changed the title Warn if regeneration renames method overloads [jnigen] Don't break method names Oct 11, 2024
@HosseinYousefi HosseinYousefi self-assigned this Oct 23, 2024
@HosseinYousefi HosseinYousefi added this to the JNI / JNIgen Q4 24 milestone Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Todo
Development

No branches or pull requests

3 participants