[Geoserver-devel] LibJPEGTurbo on OS X

Hi,

I was looking at LibJPEGTurbo on OS X and noticed a possible problem.

Over in TurboJpegUtilities#load()

public static final String LIBNAME = "turbojpeg";

static void load() {
        try {
            System.loadLibrary(LIBNAME); // If this method is called
more than once with the same library name, the second and subsequent
calls are ignored.
            if (LOGGER.isLoggable(Level.INFO)) {
                LOGGER.info("TurboJPEG library loaded ("+LIBNAME+")");
            }
        } catch (java.lang.UnsatisfiedLinkError e) {
            String os = System.getProperty("os.name").toLowerCase();
            if (os.indexOf("mac") >= 0) {
                System.load("/usr/lib/libturbojpeg.jnilib");
            } else {
                throw e;
            }
        }
    }

On OS X, the first System.loadLibrary(LIBNAME) fails, but it succeeds
with the System.load("/usr/lib/libturbojpeg.jnilib");

However, for the TurboImageWorkerTest#writer test, it eventually gets down to
   TurboJpegImageWriter line 196;

compressor = new TJCompressor();

However, TJCompressor (line 456) - part of the
turbojpeg-wrapper-1.2.1.1 jar - has a static initializer;

static {
    TJLoader.load();
  }

final class TJLoader {
  static void load() {
    System.loadLibrary("turbojpeg");
  }
};

This throws the UnsatisfiedLinkError exception (as above).

Is anyone getting the tests to run on OS X with libjepgturbo installed?

The API documentation for System.loadLibrary(name) says;
"
The call <code>System.loadLibrary(name)</code> is effectively
equivalent to the call
Runtime.getRuntime().loadLibrary(name) " which (as noted in the
comments, above) says "If this method is called more than once with
the same library name, the second and subsequent calls are ignored.".

However, this throws the exception twice;

         try {
             System.loadLibrary("turbojpeg");
        } catch (java.lang.UnsatisfiedLinkError e) {
            System.loadLibrary("turbojpeg");
        }

So does this;

        try{
            Runtime.getRuntime().loadLibrary("turbojpeg");
        }
        catch (java.lang.UnsatisfiedLinkError e)
        {
            Runtime.getRuntime().loadLibrary("turbojpeg");
        }

$ java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

Is anyone having troubles with LibJPEGTurbo on OS X? I expect it's
fine on other OSes.

Thanks,
Dave

I have not tried on OSX, how did you go about installing it Dave?

···

On 24 May 2016 at 18:06, Dave Blasby <dblasby@anonymised.com> wrote:

Hi,

I was looking at LibJPEGTurbo on OS X and noticed a possible problem.

Over in TurboJpegUtilities#load()

public static final String LIBNAME = “turbojpeg”;

static void load() {
try {
System.loadLibrary(LIBNAME); // If this method is called
more than once with the same library name, the second and subsequent
calls are ignored.
if (LOGGER.isLoggable(Level.INFO)) {
LOGGER.info(“TurboJPEG library loaded (”+LIBNAME+“)”);
}
} catch (java.lang.UnsatisfiedLinkError e) {
String os = System.getProperty(“os.name”).toLowerCase();
if (os.indexOf(“mac”) >= 0) {
System.load(“/usr/lib/libturbojpeg.jnilib”);
} else {
throw e;
}
}
}

On OS X, the first System.loadLibrary(LIBNAME) fails, but it succeeds
with the System.load(“/usr/lib/libturbojpeg.jnilib”);

However, for the TurboImageWorkerTest#writer test, it eventually gets down to
TurboJpegImageWriter line 196;

compressor = new TJCompressor();

However, TJCompressor (line 456) - part of the
turbojpeg-wrapper-1.2.1.1 jar - has a static initializer;

static {
TJLoader.load();
}

final class TJLoader {
static void load() {
System.loadLibrary(“turbojpeg”);
}
};

This throws the UnsatisfiedLinkError exception (as above).

Is anyone getting the tests to run on OS X with libjepgturbo installed?

The API documentation for System.loadLibrary(name) says;
"
The call System.loadLibrary(name) is effectively
equivalent to the call
Runtime.getRuntime().loadLibrary(name) " which (as noted in the
comments, above) says “If this method is called more than once with
the same library name, the second and subsequent calls are ignored.”.

However, this throws the exception twice;

try {
System.loadLibrary(“turbojpeg”);
} catch (java.lang.UnsatisfiedLinkError e) {
System.loadLibrary(“turbojpeg”);
}

So does this;

try{
Runtime.getRuntime().loadLibrary(“turbojpeg”);
}
catch (java.lang.UnsatisfiedLinkError e)
{
Runtime.getRuntime().loadLibrary(“turbojpeg”);
}

$ java -version
java version “1.8.0_60”
Java™ SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot™ 64-Bit Server VM (build 25.60-b23, mixed mode)

Is anyone having troubles with LibJPEGTurbo on OS X? I expect it’s
fine on other OSes.

Thanks,
Dave


Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Jody Garnett

Hi Dave,
just a quick mail as I see you did not get much follow up on this side of the pond… we simply don’t have OSX, sorry!

However it seems you might have tracked down the issue in the turbojpeg library wrapper itself, which is
(afaik) distributed by the turbojpeg project.
And that’s… interesting, look at the code here:

https://github.com/libjpeg-turbo/libjpeg-turbo/blob/master/java/org/libjpegturbo/turbojpeg/TJLoader.java.in

Wondering if OSX requires a jar file that’s different from the other operating systems?
That would be rather weird from a java standpoint (I would recognize the OS dynamically instead), and yet…

Cheers
Andrea

···

On Wed, May 25, 2016 at 3:06 AM, Dave Blasby <dblasby@anonymised.com> wrote:

Hi,

I was looking at LibJPEGTurbo on OS X and noticed a possible problem.

Over in TurboJpegUtilities#load()

public static final String LIBNAME = “turbojpeg”;

static void load() {
try {
System.loadLibrary(LIBNAME); // If this method is called
more than once with the same library name, the second and subsequent
calls are ignored.
if (LOGGER.isLoggable(Level.INFO)) {
LOGGER.info(“TurboJPEG library loaded (”+LIBNAME+“)”);
}
} catch (java.lang.UnsatisfiedLinkError e) {
String os = System.getProperty(“os.name”).toLowerCase();
if (os.indexOf(“mac”) >= 0) {
System.load(“/usr/lib/libturbojpeg.jnilib”);
} else {
throw e;
}
}
}

On OS X, the first System.loadLibrary(LIBNAME) fails, but it succeeds
with the System.load(“/usr/lib/libturbojpeg.jnilib”);

However, for the TurboImageWorkerTest#writer test, it eventually gets down to
TurboJpegImageWriter line 196;

compressor = new TJCompressor();

However, TJCompressor (line 456) - part of the
turbojpeg-wrapper-1.2.1.1 jar - has a static initializer;

static {
TJLoader.load();
}

final class TJLoader {
static void load() {
System.loadLibrary(“turbojpeg”);
}
};

This throws the UnsatisfiedLinkError exception (as above).

Is anyone getting the tests to run on OS X with libjepgturbo installed?

The API documentation for System.loadLibrary(name) says;
"
The call System.loadLibrary(name) is effectively
equivalent to the call
Runtime.getRuntime().loadLibrary(name) " which (as noted in the
comments, above) says “If this method is called more than once with
the same library name, the second and subsequent calls are ignored.”.

However, this throws the exception twice;

try {
System.loadLibrary(“turbojpeg”);
} catch (java.lang.UnsatisfiedLinkError e) {
System.loadLibrary(“turbojpeg”);
}

So does this;

try{
Runtime.getRuntime().loadLibrary(“turbojpeg”);
}
catch (java.lang.UnsatisfiedLinkError e)
{
Runtime.getRuntime().loadLibrary(“turbojpeg”);
}

$ java -version
java version “1.8.0_60”
Java™ SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot™ 64-Bit Server VM (build 25.60-b23, mixed mode)

Is anyone having troubles with LibJPEGTurbo on OS X? I expect it’s
fine on other OSes.

Thanks,
Dave


Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


Hi, Andrea,

Thanks for the reply. I agree - the geosever code (with the os x
specific code) is likely an addition to be more friendly but clashes
with the TJ code. Although, the documentation for the loadLibrary()
would indicate that calling it twice wouldn't produce the 2nd error
(although, that behavior is also likely correct as well!).

I will try to move the /usr/lib/libturbojpeg.jnilib file to a
java.library.path location and see if the loadLibrary() picks it up or
not. I'm pretty sure that Suite 4.8 on OS X had this working - so its
likely a path issue. I believe that /usr/lib/libturbojpeg.jnilib is
the default install location on OS X.

Will investigate a bit more...

Thanks,
Dave

On Wed, May 25, 2016 at 7:35 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

Hi Dave,
just a quick mail as I see you did not get much follow up on this side of
the pond... we simply don't have OSX, sorry!

However it seems you might have tracked down the issue in the turbojpeg
library wrapper itself, which is
(afaik) distributed by the turbojpeg project.
And that's.. interesting, look at the code here:
https://github.com/libjpeg-turbo/libjpeg-turbo/blob/master/java/org/libjpegturbo/turbojpeg/TJLoader.java.in

Wondering if OSX requires a jar file that's different from the other
operating systems?
That would be rather weird from a java standpoint (I would recognize the OS
dynamically instead), and yet...

Cheers
Andrea

On Wed, May 25, 2016 at 3:06 AM, Dave Blasby <dblasby@anonymised.com>
wrote:

Hi,

I was looking at LibJPEGTurbo on OS X and noticed a possible problem.

Over in TurboJpegUtilities#load()

public static final String LIBNAME = "turbojpeg";

static void load() {
        try {
            System.loadLibrary(LIBNAME); // If this method is called
more than once with the same library name, the second and subsequent
calls are ignored.
            if (LOGGER.isLoggable(Level.INFO)) {
                LOGGER.info("TurboJPEG library loaded ("+LIBNAME+")");
            }
        } catch (java.lang.UnsatisfiedLinkError e) {
            String os = System.getProperty("os.name").toLowerCase();
            if (os.indexOf("mac") >= 0) {
                System.load("/usr/lib/libturbojpeg.jnilib");
            } else {
                throw e;
            }
        }
    }

On OS X, the first System.loadLibrary(LIBNAME) fails, but it succeeds
with the System.load("/usr/lib/libturbojpeg.jnilib");

However, for the TurboImageWorkerTest#writer test, it eventually gets down
to
   TurboJpegImageWriter line 196;

compressor = new TJCompressor();

However, TJCompressor (line 456) - part of the
turbojpeg-wrapper-1.2.1.1 jar - has a static initializer;

static {
    TJLoader.load();
  }

final class TJLoader {
  static void load() {
    System.loadLibrary("turbojpeg");
  }
};

This throws the UnsatisfiedLinkError exception (as above).

Is anyone getting the tests to run on OS X with libjepgturbo installed?

The API documentation for System.loadLibrary(name) says;
"
The call <code>System.loadLibrary(name)</code> is effectively
equivalent to the call
Runtime.getRuntime().loadLibrary(name) " which (as noted in the
comments, above) says "If this method is called more than once with
the same library name, the second and subsequent calls are ignored.".

However, this throws the exception twice;

         try {
             System.loadLibrary("turbojpeg");
        } catch (java.lang.UnsatisfiedLinkError e) {
            System.loadLibrary("turbojpeg");
        }

So does this;

        try{
            Runtime.getRuntime().loadLibrary("turbojpeg");
        }
        catch (java.lang.UnsatisfiedLinkError e)
        {
            Runtime.getRuntime().loadLibrary("turbojpeg");
        }

$ java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

Is anyone having troubles with LibJPEGTurbo on OS X? I expect it's
fine on other OSes.

Thanks,
Dave

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data
untouched!
Download Mobile Device Manager Plus | Mobile Device Manager Plus
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

GeoServer Professional Services from the experts! Visit
GeoSolutions Enterprise Support Services for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
x.com

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
file/s allegato/i sono da considerarsi strettamente riservate. Il loro
utilizzo è consentito esclusivamente al destinatario del messaggio, per le
finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio
senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia
via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo
anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per
finalità diverse, costituisce comportamento contrario ai principi dettati
dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender does
not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

Hi,

I was able to confirm that I moded the TJ files (libturbojpeg.a,
libturbojpeg.dylib, libturbojpeg.jnilib) from /usr/lib to one of the
directories in System.getProperty("java.library.path", "") and now
everything works!

I think this code;
catch (java.lang.UnsatisfiedLinkError e) {
            String os = System.getProperty("os.name").toLowerCase();
            if (os.indexOf("mac") >= 0) {
                System.load("/usr/lib/libturbojpeg.jnilib");
            } else {
                throw e;
            }
        }
Should be removed from TurboJpegUtilities#load() and perhaps replaced
with a message telling them to move the files to one of the
java.library.path directories? I expect this code;

final class TJLoader {
  static void load() {
    System.loadLibrary("turbojpeg");
  }
};

Is auto-generated.

Comments?

Thanks,
Dave

On Wed, May 25, 2016 at 7:57 AM, Dave Blasby <dblasby@anonymised.com> wrote:

Hi, Andrea,

Thanks for the reply. I agree - the geosever code (with the os x
specific code) is likely an addition to be more friendly but clashes
with the TJ code. Although, the documentation for the loadLibrary()
would indicate that calling it twice wouldn't produce the 2nd error
(although, that behavior is also likely correct as well!).

I will try to move the /usr/lib/libturbojpeg.jnilib file to a
java.library.path location and see if the loadLibrary() picks it up or
not. I'm pretty sure that Suite 4.8 on OS X had this working - so its
likely a path issue. I believe that /usr/lib/libturbojpeg.jnilib is
the default install location on OS X.

Will investigate a bit more...

Thanks,
Dave

On Wed, May 25, 2016 at 7:35 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

Hi Dave,
just a quick mail as I see you did not get much follow up on this side of
the pond... we simply don't have OSX, sorry!

However it seems you might have tracked down the issue in the turbojpeg
library wrapper itself, which is
(afaik) distributed by the turbojpeg project.
And that's.. interesting, look at the code here:
https://github.com/libjpeg-turbo/libjpeg-turbo/blob/master/java/org/libjpegturbo/turbojpeg/TJLoader.java.in

Wondering if OSX requires a jar file that's different from the other
operating systems?
That would be rather weird from a java standpoint (I would recognize the OS
dynamically instead), and yet...

Cheers
Andrea

On Wed, May 25, 2016 at 3:06 AM, Dave Blasby <dblasby@anonymised.com>
wrote:

Hi,

I was looking at LibJPEGTurbo on OS X and noticed a possible problem.

Over in TurboJpegUtilities#load()

public static final String LIBNAME = "turbojpeg";

static void load() {
        try {
            System.loadLibrary(LIBNAME); // If this method is called
more than once with the same library name, the second and subsequent
calls are ignored.
            if (LOGGER.isLoggable(Level.INFO)) {
                LOGGER.info("TurboJPEG library loaded ("+LIBNAME+")");
            }
        } catch (java.lang.UnsatisfiedLinkError e) {
            String os = System.getProperty("os.name").toLowerCase();
            if (os.indexOf("mac") >= 0) {
                System.load("/usr/lib/libturbojpeg.jnilib");
            } else {
                throw e;
            }
        }
    }

On OS X, the first System.loadLibrary(LIBNAME) fails, but it succeeds
with the System.load("/usr/lib/libturbojpeg.jnilib");

However, for the TurboImageWorkerTest#writer test, it eventually gets down
to
   TurboJpegImageWriter line 196;

compressor = new TJCompressor();

However, TJCompressor (line 456) - part of the
turbojpeg-wrapper-1.2.1.1 jar - has a static initializer;

static {
    TJLoader.load();
  }

final class TJLoader {
  static void load() {
    System.loadLibrary("turbojpeg");
  }
};

This throws the UnsatisfiedLinkError exception (as above).

Is anyone getting the tests to run on OS X with libjepgturbo installed?

The API documentation for System.loadLibrary(name) says;
"
The call <code>System.loadLibrary(name)</code> is effectively
equivalent to the call
Runtime.getRuntime().loadLibrary(name) " which (as noted in the
comments, above) says "If this method is called more than once with
the same library name, the second and subsequent calls are ignored.".

However, this throws the exception twice;

         try {
             System.loadLibrary("turbojpeg");
        } catch (java.lang.UnsatisfiedLinkError e) {
            System.loadLibrary("turbojpeg");
        }

So does this;

        try{
            Runtime.getRuntime().loadLibrary("turbojpeg");
        }
        catch (java.lang.UnsatisfiedLinkError e)
        {
            Runtime.getRuntime().loadLibrary("turbojpeg");
        }

$ java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

Is anyone having troubles with LibJPEGTurbo on OS X? I expect it's
fine on other OSes.

Thanks,
Dave

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data
untouched!
Download Mobile Device Manager Plus | Mobile Device Manager Plus
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

GeoServer Professional Services from the experts! Visit
GeoSolutions Enterprise Support Services for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
x.com

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
file/s allegato/i sono da considerarsi strettamente riservate. Il loro
utilizzo è consentito esclusivamente al destinatario del messaggio, per le
finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio
senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia
via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo
anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per
finalità diverse, costituisce comportamento contrario ai principi dettati
dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender does
not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

So if you make that change does it work for you? If so can we package this up with a bug report and pull request? I expect the code in question would of been added by Justin or another OSX developer.

···

On 25 May 2016 at 12:02, Dave Blasby <dblasby@anonymised.com> wrote:

Hi,

I was able to confirm that I moded the TJ files (libturbojpeg.a,
libturbojpeg.dylib, libturbojpeg.jnilib) from /usr/lib to one of the
directories in System.getProperty(“java.library.path”, “”) and now
everything works!

I think this code;
catch (java.lang.UnsatisfiedLinkError e) {
String os = System.getProperty(“os.name”).toLowerCase();
if (os.indexOf(“mac”) >= 0) {
System.load(“/usr/lib/libturbojpeg.jnilib”);
} else {
throw e;
}
}
Should be removed from TurboJpegUtilities#load() and perhaps replaced
with a message telling them to move the files to one of the
java.library.path directories? I expect this code;

final class TJLoader {
static void load() {
System.loadLibrary(“turbojpeg”);
}
};

Is auto-generated.

Comments?

Thanks,
Dave

On Wed, May 25, 2016 at 7:57 AM, Dave Blasby <dblasby@anonymised.com> wrote:

Hi, Andrea,

Thanks for the reply. I agree - the geosever code (with the os x
specific code) is likely an addition to be more friendly but clashes
with the TJ code. Although, the documentation for the loadLibrary()
would indicate that calling it twice wouldn’t produce the 2nd error
(although, that behavior is also likely correct as well!).

I will try to move the /usr/lib/libturbojpeg.jnilib file to a
java.library.path location and see if the loadLibrary() picks it up or
not. I’m pretty sure that Suite 4.8 on OS X had this working - so its
likely a path issue. I believe that /usr/lib/libturbojpeg.jnilib is
the default install location on OS X.

Will investigate a bit more…

Thanks,
Dave

On Wed, May 25, 2016 at 7:35 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

Hi Dave,
just a quick mail as I see you did not get much follow up on this side of
the pond… we simply don’t have OSX, sorry!

However it seems you might have tracked down the issue in the turbojpeg
library wrapper itself, which is
(afaik) distributed by the turbojpeg project.
And that’s… interesting, look at the code here:
https://github.com/libjpeg-turbo/libjpeg-turbo/blob/master/java/org/libjpegturbo/turbojpeg/TJLoader.java.in

Wondering if OSX requires a jar file that’s different from the other
operating systems?
That would be rather weird from a java standpoint (I would recognize the OS
dynamically instead), and yet…

Cheers
Andrea

On Wed, May 25, 2016 at 3:06 AM, Dave Blasby <dblasby@anonymised.com>
wrote:

Hi,

I was looking at LibJPEGTurbo on OS X and noticed a possible problem.

Over in TurboJpegUtilities#load()

public static final String LIBNAME = “turbojpeg”;

static void load() {
try {
System.loadLibrary(LIBNAME); // If this method is called
more than once with the same library name, the second and subsequent
calls are ignored.
if (LOGGER.isLoggable(Level.INFO)) {
LOGGER.info(“TurboJPEG library loaded (”+LIBNAME+“)”);
}
} catch (java.lang.UnsatisfiedLinkError e) {
String os = System.getProperty(“os.name”).toLowerCase();
if (os.indexOf(“mac”) >= 0) {
System.load(“/usr/lib/libturbojpeg.jnilib”);
} else {
throw e;
}
}
}

On OS X, the first System.loadLibrary(LIBNAME) fails, but it succeeds
with the System.load(“/usr/lib/libturbojpeg.jnilib”);

However, for the TurboImageWorkerTest#writer test, it eventually gets down
to
TurboJpegImageWriter line 196;

compressor = new TJCompressor();

However, TJCompressor (line 456) - part of the
turbojpeg-wrapper-1.2.1.1 jar - has a static initializer;

static {
TJLoader.load();
}

final class TJLoader {
static void load() {
System.loadLibrary(“turbojpeg”);
}
};

This throws the UnsatisfiedLinkError exception (as above).

Is anyone getting the tests to run on OS X with libjepgturbo installed?

The API documentation for System.loadLibrary(name) says;
"
The call System.loadLibrary(name) is effectively
equivalent to the call
Runtime.getRuntime().loadLibrary(name) " which (as noted in the
comments, above) says “If this method is called more than once with
the same library name, the second and subsequent calls are ignored.”.

However, this throws the exception twice;

try {
System.loadLibrary(“turbojpeg”);
} catch (java.lang.UnsatisfiedLinkError e) {
System.loadLibrary(“turbojpeg”);
}

So does this;

try{
Runtime.getRuntime().loadLibrary(“turbojpeg”);
}
catch (java.lang.UnsatisfiedLinkError e)
{
Runtime.getRuntime().loadLibrary(“turbojpeg”);
}

$ java -version
java version “1.8.0_60”
Java™ SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot™ 64-Bit Server VM (build 25.60-b23, mixed mode)

Is anyone having troubles with LibJPEGTurbo on OS X? I expect it’s
fine on other OSes.

Thanks,
Dave


Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data
untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
file/s allegato/i sono da considerarsi strettamente riservate. Il loro
utilizzo è consentito esclusivamente al destinatario del messaggio, per le
finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio
senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia
via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo
anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per
finalità diverse, costituisce comportamento contrario ai principi dettati
dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender does
not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.



Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Jody Garnett

I created a ticket - [GEOS-7560] - JIRA

My proposed solution is to just remove the "smart" code in
TurboJpegUtilities#load() and let it throw an error. See Ticket.

NOTE: this is an imageio-ext PR

On Wed, May 25, 2016 at 1:37 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

So if you make that change does it work for you? If so can we package this
up with a bug report and pull request? I expect the code in question would
of been added by Justin or another OSX developer.

--
Jody Garnett

On 25 May 2016 at 12:02, Dave Blasby <dblasby@anonymised.com> wrote:

Hi,

I was able to confirm that I moded the TJ files (libturbojpeg.a,
libturbojpeg.dylib, libturbojpeg.jnilib) from /usr/lib to one of the
directories in System.getProperty("java.library.path", "") and now
everything works!

I think this code;
catch (java.lang.UnsatisfiedLinkError e) {
            String os = System.getProperty("os.name").toLowerCase();
            if (os.indexOf("mac") >= 0) {
                System.load("/usr/lib/libturbojpeg.jnilib");
            } else {
                throw e;
            }
        }
Should be removed from TurboJpegUtilities#load() and perhaps replaced
with a message telling them to move the files to one of the
java.library.path directories? I expect this code;

final class TJLoader {
  static void load() {
    System.loadLibrary("turbojpeg");
  }
};

Is auto-generated.

Comments?

Thanks,
Dave

On Wed, May 25, 2016 at 7:57 AM, Dave Blasby <dblasby@anonymised.com>
wrote:
> Hi, Andrea,
>
> Thanks for the reply. I agree - the geosever code (with the os x
> specific code) is likely an addition to be more friendly but clashes
> with the TJ code. Although, the documentation for the loadLibrary()
> would indicate that calling it twice wouldn't produce the 2nd error
> (although, that behavior is also likely correct as well!).
>
> I will try to move the /usr/lib/libturbojpeg.jnilib file to a
> java.library.path location and see if the loadLibrary() picks it up or
> not. I'm pretty sure that Suite 4.8 on OS X had this working - so its
> likely a path issue. I believe that /usr/lib/libturbojpeg.jnilib is
> the default install location on OS X.
>
> Will investigate a bit more...
>
> Thanks,
> Dave
>
> On Wed, May 25, 2016 at 7:35 AM, Andrea Aime
> <andrea.aime@anonymised.com> wrote:
>> Hi Dave,
>> just a quick mail as I see you did not get much follow up on this side
>> of
>> the pond... we simply don't have OSX, sorry!
>>
>> However it seems you might have tracked down the issue in the turbojpeg
>> library wrapper itself, which is
>> (afaik) distributed by the turbojpeg project.
>> And that's.. interesting, look at the code here:
>>
>> https://github.com/libjpeg-turbo/libjpeg-turbo/blob/master/java/org/libjpegturbo/turbojpeg/TJLoader.java.in
>>
>> Wondering if OSX requires a jar file that's different from the other
>> operating systems?
>> That would be rather weird from a java standpoint (I would recognize
>> the OS
>> dynamically instead), and yet...
>>
>> Cheers
>> Andrea
>>
>>
>> On Wed, May 25, 2016 at 3:06 AM, Dave Blasby <dblasby@anonymised.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I was looking at LibJPEGTurbo on OS X and noticed a possible problem.
>>>
>>> Over in TurboJpegUtilities#load()
>>>
>>> public static final String LIBNAME = "turbojpeg";
>>>
>>> static void load() {
>>> try {
>>> System.loadLibrary(LIBNAME); // If this method is called
>>> more than once with the same library name, the second and subsequent
>>> calls are ignored.
>>> if (LOGGER.isLoggable(Level.INFO)) {
>>> LOGGER.info("TurboJPEG library loaded ("+LIBNAME+")");
>>> }
>>> } catch (java.lang.UnsatisfiedLinkError e) {
>>> String os = System.getProperty("os.name").toLowerCase();
>>> if (os.indexOf("mac") >= 0) {
>>> System.load("/usr/lib/libturbojpeg.jnilib");
>>> } else {
>>> throw e;
>>> }
>>> }
>>> }
>>>
>>> On OS X, the first System.loadLibrary(LIBNAME) fails, but it succeeds
>>> with the System.load("/usr/lib/libturbojpeg.jnilib");
>>>
>>> However, for the TurboImageWorkerTest#writer test, it eventually gets
>>> down
>>> to
>>> TurboJpegImageWriter line 196;
>>>
>>> compressor = new TJCompressor();
>>>
>>> However, TJCompressor (line 456) - part of the
>>> turbojpeg-wrapper-1.2.1.1 jar - has a static initializer;
>>>
>>> static {
>>> TJLoader.load();
>>> }
>>>
>>> final class TJLoader {
>>> static void load() {
>>> System.loadLibrary("turbojpeg");
>>> }
>>> };
>>>
>>> This throws the UnsatisfiedLinkError exception (as above).
>>>
>>> Is anyone getting the tests to run on OS X with libjepgturbo
>>> installed?
>>>
>>>
>>>
>>>
>>> The API documentation for System.loadLibrary(name) says;
>>> "
>>> The call <code>System.loadLibrary(name)</code> is effectively
>>> equivalent to the call
>>> Runtime.getRuntime().loadLibrary(name) " which (as noted in the
>>> comments, above) says "If this method is called more than once with
>>> the same library name, the second and subsequent calls are ignored.".
>>>
>>> However, this throws the exception twice;
>>>
>>> try {
>>> System.loadLibrary("turbojpeg");
>>> } catch (java.lang.UnsatisfiedLinkError e) {
>>> System.loadLibrary("turbojpeg");
>>> }
>>>
>>> So does this;
>>>
>>> try{
>>> Runtime.getRuntime().loadLibrary("turbojpeg");
>>> }
>>> catch (java.lang.UnsatisfiedLinkError e)
>>> {
>>> Runtime.getRuntime().loadLibrary("turbojpeg");
>>> }
>>>
>>> $ java -version
>>> java version "1.8.0_60"
>>> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
>>> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
>>>
>>>
>>>
>>> Is anyone having troubles with LibJPEGTurbo on OS X? I expect it's
>>> fine on other OSes.
>>>
>>> Thanks,
>>> Dave
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Mobile security can be enabling, not merely restricting. Employees who
>>> bring their own devices (BYOD) to work are irked by the imposition of
>>> MDM
>>> restrictions. Mobile Device Manager Plus allows you to control only
>>> the
>>> apps on BYO-devices by containerizing them, leaving personal data
>>> untouched!
>>> Download Mobile Device Manager Plus | Mobile Device Manager Plus
>>> _______________________________________________
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>>
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> GeoSolutions Enterprise Support Services for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054 Massarosa (LU)
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39 339 8844549
>>
>> http://www.geo-solutions.it
>> x.com
>>
>> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
>>
>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>> nel/i
>> file/s allegato/i sono da considerarsi strettamente riservate. Il loro
>> utilizzo è consentito esclusivamente al destinatario del messaggio, per
>> le
>> finalità indicate nel messaggio stesso. Qualora riceviate questo
>> messaggio
>> senza esserne il destinatario, Vi preghiamo cortesemente di darcene
>> notizia
>> via e-mail e di procedere alla distruzione del messaggio stesso,
>> cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>> divulgarlo
>> anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>> utilizzarlo per
>> finalità diverse, costituisce comportamento contrario ai principi
>> dettati
>> dal D.Lgs. 196/2003.
>>
>>
>>
>> The information in this message and/or attachments, is intended solely
>> for
>> the attention and use of the named addressee(s) and may be confidential
>> or
>> proprietary in nature or covered by the provisions of privacy act
>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>> Code).Any use not in accord with its purpose, any disclosure,
>> reproduction,
>> copying, distribution, or either dissemination, either whole or
>> partial, is
>> strictly forbidden except previous formal approval of the named
>> addressee(s). If you are not the intended recipient, please contact
>> immediately the sender by telephone, fax or e-mail and delete the
>> information in this message that has been received in error. The sender
>> does
>> not give any warranty or accept liability as the content, accuracy or
>> completeness of sent messages and accepts no responsibility for
>> changes
>> made after they were sent or for other risks which arise as a result of
>> e-mail transmission, viruses, etc.
>>
>>
>> -------------------------------------------------------

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data
untouched!
Download Mobile Device Manager Plus | Mobile Device Manager Plus
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel