-
-
Notifications
You must be signed in to change notification settings - Fork 4
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
Adapt wrapper to new API of libzim/libkiwix #23
Conversation
3a2fa2d
to
c4b582c
Compare
9472116
to
c32bc00
Compare
This validate the build system has we now have a compiling wrapper around libzim.
Avoid the Handle and directly use a shared_ptr. This simplify a lot the wrapping code and potentially remove some bug.
JNIKiwix.java is not compiled as it needs modules not found. To be fixed.
(Adapt only libzim part)
c32bc00
to
d63b84a
Compare
I think we can start review this PR. Few information about how wrapping is done (please be carruful about that when reviewing) : From the java definition ( The same way, creating wrapper is made by creating java object, and to do so, we have to "search" for the java class. |
For better comparaison with the generated header.
The cpp method name is `getMimetype`, not `getMimeType`.
As `update` is overloaded, the jni method name include the argument type. And we have changed the type of one version of `update`, so we need to change its name.
A lot of methods are overloaded, so we must include the argument type in the name.
This make the JNI wrapping *somehow* NOT threadsafe. Few things are threadsafe "by nature": - A lot of native method in libzim are threadsafe. - Wrapping internal are threadsafe (shared_ptr). What is not threadsafe is accessing the SAME java object from different thread. But accessing the same wrapped cpp object using two different java wrapper in two different thread is ok (assuming that the called cpp method is threadsafe itself).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hi @mgautierfr, Since i'm not a c++ developer. But i have reviewed android related code. it succesfully generated the .so file.
and it's need lots of refactoring in android code according to latest changes in wrapper. i have stared refactoring code on android side.
- I have not reviewed testing part yet. Because its broken right now(after adapting the file structure and latest wrapper) and i think you have not work on that yet.
- Can you please check why codefactor is failing.
I have a questions.
- We have removed (JNIKiwixBool.java , JNIKiwixInt.java , JNIKiwixString.java). What is the alernative for these classes?
Indeed, I've not work on that. I think we should do it together. I'm not aware of testing tools in java.
There is no alternative. Those classes where use as out parameter in the old API (you pass a JNIKiwixBool to a method, and it will be modified to pass you a value). With the new api, you don't need them, so I remove them. |
Codefactor complain about the finalizer method which is deprecated. |
@mgautierfr Don't forget the bookmarks API |
This is WIP in #25 |
I think we are good now. At least as long as we don't try to run it. |
It seems I was wrong when I told JNIKiwix.java is fixed. |
hi @mgautierfr , you can try this code snippet in lib/gradle file
|
a15de34
to
8ce4ed1
Compare
8ce4ed1
to
929ae6d
Compare
Thanks @MohitMaliFtechiz. Now compilation is ok. |
This PR is the adaptation of the wrapper itself. Change in the build system is PR #22
The current version mainly "remove" existing wrapper (not compile it) and start a new wrapper (libzim only for now) using ground fondation made previously.
TODO:
Add wrapper around libkiwix (reusing previous wrapper)Finish libzim wrapper (search, iteration on items, ..)