JNA is not quite built on JNI, at least not in the sense of calling the
wrapped libraries functions.
JNA uses JNI to access libffi, and then uses libffi to call the library
you are wrapping. Calling methods through libffi is dynamic and has no
access to defines in header files. It is for this reason the widechar
definition cannot be accessed by JLouis, the python bindings (which use
CTypes), etc, and why they need the method to get the size of widechar.
In contrast though, this is why JLouis is able to dynamically change to
whatever size widechar is used in the liblouis installation it finds.
Using JNI to access the wrapped library means you are writing custom C
code to call the wrapped library. This means that the C part of the JNI
wrapper has all the same access as a C application would have (IE.
defines in header files, etc). If using the define of widechar, the size
is fixed at compile time so the JNI code needs matching with a similarly
compiled liblouis.
Yes a JNI wrapper could use the method to get the size of widechar at
runtime, but whether due to the compile time linking of the function
calls and the parameter types I still don't know whether it could be
done without something like libffi.
In my mind the two approaches are quite different.
Michael Whapples
On 06/01/2016 10:40, Bert Frees wrote:
As a matter of fact, very little code in liblouis-java has to do
with JNA. The little code that has to do with JNA is all about
converting values from one type to another, for those cases that
aren't handled by JNA out of the box. (Which I imagine needs to
be done in JNI too. Afterall, JNA is built on JNI.) All other
code either adds real functionality, or tries to make the library
more object-oriented/Java-like, as you do.
Regarding the localisations: It would indeed be nice to have them
available for all Java users, and by extension all users in
general. Your ideas are welcome. We've discussed this issue many
times before but never came to a conclusion.
We've often discussed the issue of localisation in the same
breath as the issue of metadata and discovery. The issues are
indeed somewhat related, but at one point we realized they might
require different approaches. I ended up adding a table lookup
function through a mechanism with metadata fields in table headers
(distributed approach).
For localisation we are still looking for a good solution. Some things
to be considered:
- native mechanism (custom, embedded in liblouis) vs. standard
cross-platform mechanism vs. several mechanisms for several
platforms (with conversion scripts for localisation data)
- distributed (in tables themselves) vs. centralized
Dave Mielke writes:
[quoted lines by Bert Frees on 2016/01/05 at 12:26 +0100]For a description of the software, to download it and links to
I also see the advantage of having 1000 lines of code as opposed toWhen we subtract out the 500 lines for enumerating the translation tables, and
including the whole JNA library.
the 100 lines that implement some tests, it's actually down to about 500 lines
of Java and about 100 lines of C. Then, we can even subtract out a bunch more
lines that are only needed on Android to unpack the table files from what
Android calls assets.
For liblouis-java I chose the convenience and maintainability over the size.This, I suppose, is a matter of opinion. My opinion, of course, was heavily
(I don't have much experience with JNI but as I remember it there was a lot of
boilerplate.)
weighted by the fact that I do know JNI. The code that needs to be in
liblouis-java in order to build it on top of JNA looked, to me, to be a whole
lot more complicated and voluminous than the JNI would be. Now that it's done,
my opinion is even more so.
Making it thread safe I also like. This could also be done in liblouis-java ifOf course.
needed.
What I don't really understand is what you mean by "presenting a Java viewI hadn't discovered jlouis. What I mean, though, is for the view to be fully
in Java", or rather: in what way your bindings are more Java-oriented than
my liblouis-java or Michael's jlouis.
object-based with no traces of an underlying C implementation. I also like
objects that accept or present data in a way that Java programmers would
expect. Again, some of this comes down to being a matter of opinion.
In the end - rightly or wrongly - I myself am content with the result. The code
is small, the JNI is minimal and straight forward, the implementation is simple
and easy to udnerstand, etc.
With a bit of work, it could even be unAndroided, and, therefore, be usable by
all Java users. The one big problem to that end is figuring out how to localize
the string descriptions of the tables. Right now, these strings are defined as
Android string resources, which is how Android does localization. I'm thinking
about it, though, as I think the goal should be that this code be usable by all
Java users.
Will you make your code publicly available at some point so we can have aAbsolutely! I just need to unbundle it (probbaly with git subtree) from the
look?
project that I developed it for. It's even, therefore, already publicly
available as part of that project. But, to avoid any confusion, I'm going to
unbundle it (probably, for now, as DaveMielke/liblouis-android).
project pages go to http://liblouis.org
