work in progress, cleaned up the directories and split them up into folder which make more sense, Still need to compile libvitaboy and all the tools

deps/libjpeg-turbo/java/README

@@ -0,0 +1,55 @@
+TurboJPEG/OSS Java 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 several
+classes located under org/libjpegturbo/turbojpeg.  The source code for these
+Java classes is licensed under a BSD-style license, so the files can be
+incorporated directly into both open source and proprietary projects without
+restriction.  A Java archive (JAR) file containing these classes is also
+shipped with the "official" distribution packages of libjpeg-turbo.
+
+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.
+
+
+Performance Pitfalls
+--------------------
+
+The TurboJPEG Java front end defines several convenience methods that can
+allocate image buffers or instantiate classes to hold the result of compress,
+decompress, or transform operations.  However, if you use these methods, then
+be mindful of the amount of new data you are creating on the heap.  It may be
+necessary to manually invoke the garbage collector to prevent heap exhaustion
+or to prevent performance degradation.  Background garbage collection can kill
+performance, particularly in a multi-threaded environment (Java pauses all
+threads when the GC runs.)
+
+The Java front end always gives you the option of pre-allocating your own
+source and destination buffers, which allows you to re-use these buffers for
+compressing/decompressing multiple images.  If the image sequence you are
+compressing or decompressing consists of images of the same size, then
+pre-allocating the buffers is recommended.
+
+
+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.