-
Notifications
You must be signed in to change notification settings - Fork 43
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
Comments
We could possibly use the existing "imports" mechanism for this? |
Yes. That's what I referred to in the description:
|
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. |
Agreed. |
Let's say that we have two methods
void foo(float a)
andvoid foo(double a)
. JNIgen generates these asvoid foo(double a)
andvoid 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 andfoo1
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.
The text was updated successfully, but these errors were encountered: