Jacoco don't track native methods, so our code coverage don't
include all the native methods, and it is exactly want we want to check.
By introducing a test package wrapping all native methods with a small
java function, we have the coverage of the wrapping methods.
`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`.
