jni: First attempt at generic JNI bindings.

The purpose of JNI bindings is to allow MuPDF to be driven from
Java. There are several possible use cases here.

Firstly, and most simply a java application can ask the core of MuPDF
to open a document and render it using the existing devices to
produce output on a standard Java bitmap.

Secondly, a java application might want to drive the device interface
itself, making use of the standard MuPDF devices (such as using the
rendering engine to render high quality graphics).

Thirdly, a java application might want to implement its own device
and then call MuPDF to run the document to that device (perhaps to do
custom text or image extraction).

The first of these cases requires a simple reflection of the main
document and standard device classes in JNI.

The second of these cases requires the actual device interface itself
to be made available as a java interface, together with the ability
to construct and manipulate data types like paths, text and fonts so
the Java code can build the required objects to pass to implementers
of the device interface.

The final case requires a reflection layer whereby calls through the
device interface in C can be turned into method calls to a Java
interface.

All of this is attempted in this commit. Some highlights:

For each type in the C (such as fz_colorspace) we have a corresponding
java class (such as ColorSpace).

Where the 'fz_' types are reference counted (such as an fz_colorspace),
the java objects (such as ColorSpace) simply take a reference to a
pointer to the underlying fz type. Java accessor methods are then
provided to manipulate these types.

Where the 'fz_' types are not reference counted (such as an fz_rect),
the data is actually contained within the Java object itself (such as
Rect, RectI and Transform).

We add a VS jni project. This doesn't do anything except make the
files accessible for editing in the IDE.

As much as possible, the Java layers do nothing (other than some
programmer friendly type overloading), construction (unavoidable,
as can't be done in JNI) and boiler-plate destruction. All the
smartness is done in the C.

Due to Java and C's differing approach to constness, we need to be
careful that a java device does not destructively alter objects
passed to it. For example, consider running a display list through
a device implemented in java. If the java device were to change a
Font object passed to it, this might affect other objects in the
display list that shared the same underlying fz_font.

Possibly we can achieve this by having an 'isConst' flag on java
objects that are created from device calls and passed to the Java
device (see the Text class, for an attempt at this currently).

This could alternatively be achieved by cloning every such
piece of data (see the path code for an example of this approach),
but this is probably slow. Better to clone 'just in time' as the
first write operation is done to the object.

0 files changed, 0 insertions, 0 deletions