summaryrefslogtreecommitdiff
path: root/trunk/java/README
blob: 8b6f5bcda1995146788b325fb428496c8683a3ce (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
TurboJPEG/OSS JNI Wrapper
=========================

TurboJPEG/OSS can optionally be built with a Java Native Interface wrapper,
which allows the TurboJPEG/OSS dynamic library to be loaded and used directly
from Java applications.  The Java front end for this is defined in
turbojpeg.java, which should be located in the same directory as this README
file.  turbojpeg.java is licensed under a BSD-style license, so it can be
incorporated directly into both open source and proprietary projects without
restriction.

tjexample.java, which should also be located in the same directory as this
README file, demonstrates how to use the TurboJPEG/OSS Java front end to
compress and decompress JPEG images in memory.

  javac *.java

builds .class files for both the front end and example code.


Note for OS X users
-------------------

/usr/lib, the directory under which libturbojpeg.dylib is installed on Mac
systems, is not part of the normal Java library path.  Thus, when running a
Java application that uses TurboJPEG/OSS on Mac systems, you will need to pass
an argument of -Djava.library.path=/usr/lib to java.


Note for Solaris users
----------------------

/opt/libjpeg-turbo/lib, the directory under which libturbojpeg.so is installed
on Solaris systems, is not part of the normal Java library path.  Thus, when
running a Java application that uses TurboJPEG/OSS on Solaris systems, you will
need to pass an argument of -Djava.library.path=/opt/libjpeg-turbo/lib to java.
If using a 64-bit data model, then instead pass an argument of
-Djava.library.path=/opt/libjpeg-turbo/lib/amd64 to use the 64-bit version of
libturbojpeg.so.


Note for MinGW users
--------------------

When libjpeg-turbo is built with MinGW, the TurboJPEG/OSS dynamic library is
named libturbojpeg.dll instead of turbojpeg.dll.  This is in keeping with the
convention of MinGW, and it also avoids a filename conflict when the GCC and
Visual C++ versions of the libjpeg-turbo SDK are installed on the same system.
However, the TurboJPEG/OSS JNI wrapper will not work on Windows unless the DLL
is named turbojpeg.dll.  You can work around this by renaming the DLL or by
simply changing the LoadLibrary() calls in turbojpeg.java so that they load
"libturbojpeg" instead of "turbojpeg".