RFR : JDK-8203884 : Update libjpeg to version 9c
philip.race at oracle.com
Mon Oct 1 20:55:27 UTC 2018
The JDK has shipped a libjpeg since, well, forever.
For a long time it did export all the symbols, but what is now probably
an even longer time, it has exported only the JNI entry points.
We can do the same here.
The JDK approach used to be tediously maintained mapfiles. But recently it
was switched to use compiler directives. The default for such a library as
libjavafx_iio.so is that symbols aren't exported, and we don't need to touch
the imported source files, just add the JNIEXPORT directive to the
the JNI functions in the JDK's own source files which are compiled into
And of course some makefile work.
See https://bugs.openjdk.java.net/browse/JDK-8200178 and
We can do something like this for FX in a follow-on bug
Another follow-on bug opportunity, is for FX to do what JDK 11 does, which
is to defer to the system libjpeg on Linux (and Solaris, but not
relevant to FX).
So libjavafx_iio.so on Linux would become just a small entry point to the
platform JPEG library.
On 10/01/2018 10:59 AM, Johan Vos wrote:
> Unrelated to the patch, I wonder if there is a better way to include this
> If we bundle an application that uses JavaFX but also includes a native
> library that links with libjpeg, there will be issues due to duplicate
> symbols (this happens for example when running deeplearning4j on ios, where
> we build a static executable).
> Is it an option to prefix the public symbols?
> - Johan
> On Mon, Oct 1, 2018 at 5:59 PM Ambarish Rapte <ambarish.rapte at oracle.com>
>> Hi All,
>> Please review this change for updating libjpeg7 to
>> http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/ ->
>> Complete patch with changes in make files and Netbeans project files.
>> -> Partial patch, updated 9c files in earlier libjpeg7 folder for ease to
>> go through difference.
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8203884
More information about the openjfx-dev