`Book::getIllustration(size)` return a `shared_ptr<Illustration>`.
The current `buildWrapper` was creating a wrapper on a
`shared_ptr<Illustration>` (so a `shared_ptr<shared_ptr<Illustration>>`)
but we was converting to a `shared_ptr<Illustration>` and so we were doing
wrong reads.
By specializing the buildWrapper for `shared_ptr<T>`, we avoid the
"double shared_ptr" and we are good.
Blob IS a `char[]`. C++ allow a char[] to be stored in a string but in
java, a String is associated to a encoding.
Content in a Blob may have no encoding so we cannot convert to a string.
Fix the test part.
Introduce a new set of wrapper (with a nice `2` postfix) with use a
constructor taking a handle as parameter.
It allow Book to have two constructor:
- One creating a default empty (cpp) book.
- One setting the wrapper around a exsiting cpp book.
Bookmark wrapper can be created using two ways:
- From a existing (cpp) bookmark (done internally by Library wrapper code)
- As a totally new one (empty) the java code will have to setup (using
`set*` methods).
If the `Bookmark` constructor always create an empty new cpp bookmark,
when we set the wrapper to point to the existing bookmark, we will have a
leak of the new created bookmark.
As we want to keep the "basic" constructor as the normal java api to
create an empty bookmark, we need another (private) constructor to avoid
the construction of an empty bookmark.
The new constructor take a handle and directly set the `nativeHandle`.
On `Library.getBookmarks` we cannot use the helper `BUILD_WRAPPER` and
we must use "internal" function to use the `(J)V` constructor instead of
the basic `()V`.
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).
