[Geoserver-users] JAI and IMAGEIO on JRE11

Hello All,

I am currently using the latest GeoServer .war Build in a Docker Image; using Debian latest, Tomcat latest, and JRE8.

Its been working flawless for some time now, and i have been asked to move to OpenJDK JRE11. I was reading up on JAI and IMAGEIO and and came across this link in documentation.
https://docs.geoserver.org/latest/en/user/production/java.html

I noticed this “Outdated: install native JAI and ImageIO extensions”

Does the “outdated” at the bigining of the title mean with the newest builds of .war that i will no longer need to post install the JAI and IMAGIO? or is support now gone?

I’m trying to figure out what and if i need to do anything for JAI and IMAGEIO in JRE11. I noticed also where the path to put those in JRE8 is no longer a path location in JRE11. So also wondering if i need to make the path if i still need to figure out where to put those to files?

Thank you for the help,
Joe

We ship GeoServer with a pure java version of JAI. On Java 8 and older versions an extension mechanism was provided which allowed JAI to be installed as an “extension” to the JRE (and shared between applications). Companies like Sun and Apple used this as an opportunity to provide a copy with native code speeding up some of the operations. With Java 9 the java extension system was replaced with a module system called jigsaw (and the extensions no longer work).

The pure java JAI can still be used as a plain java library allowing you to run in Java 11. There will be some warnings (since the library assumes it can have access to some internal classes which strictly speaking it no longer in a privileged position to access).

Do you have any questions on the above? And do you have any suggestions on how we can tell that story better on the java.html page…

···


Jody Garnett

A few lines below it says: “Warning Users should take care that JAI native libraries remove support for NODATA pixels, provided instead by the pure Java JAI-EXT libraries.”

This is the main reason to call it outdated, regardless of the JDK you’re using. The Java 11 situation also adds on top of it.

Cheers
Andrea

···

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 ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

Hi Jody,
That explanation was pretty good, and i was able to understand it (I’m not a senior developer). That might make a great NOTE for the webpage right there.

So does that mean i will lose the rendering speed increase i got with the extension? Is the Pure Java JAI faster on JRE11 than JRE8? Has anyone had any experience with the speed differences?

https://blog.idrsolutions.com/2015/03/why-we-are-abandoning-imageio-and-jai-for-image-support-in-our-commercial-java-code/

I came across that the other day in my research to figure out JAI in JRE11. Any truth to their claims?

Any recommendations to keep the speed we had before on JRE8 would be greatly appreciated.

Joe

On Mon, Jun 3, 2019 at 8:13 PM Jody Garnett <jody.garnett@anonymised.com> wrote:

We ship GeoServer with a pure java version of JAI. On Java 8 and older versions an extension mechanism was provided which allowed JAI to be installed as an “extension” to the JRE (and shared between applications). Companies like Sun and Apple used this as an opportunity to provide a copy with native code speeding up some of the operations. With Java 9 the java extension system was replaced with a module system called jigsaw (and the extensions no longer work).

The pure java JAI can still be used as a plain java library allowing you to run in Java 11. There will be some warnings (since the library assumes it can have access to some internal classes which strictly speaking it no longer in a privileged position to access).

Do you have any questions on the above? And do you have any suggestions on how we can tell that story better on the java.html page…


Jody Garnett

On Mon, 3 Jun 2019 at 14:46, Joe Murphy <joseph.b.murphy1@anonymised.com> wrote:

Hello All,

I am currently using the latest GeoServer .war Build in a Docker Image; using Debian latest, Tomcat latest, and JRE8.

Its been working flawless for some time now, and i have been asked to move to OpenJDK JRE11. I was reading up on JAI and IMAGEIO and and came across this link in documentation.
https://docs.geoserver.org/latest/en/user/production/java.html

I noticed this “Outdated: install native JAI and ImageIO extensions”

Does the “outdated” at the bigining of the title mean with the newest builds of .war that i will no longer need to post install the JAI and IMAGIO? or is support now gone?

I’m trying to figure out what and if i need to do anything for JAI and IMAGEIO in JRE11. I noticed also where the path to put those in JRE8 is no longer a path location in JRE11. So also wondering if i need to make the path if i still need to figure out where to put those to files?

Thank you for the help,
Joe


Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

We took a similar road several years ago when imageio-ext and jai-ext have been created.

There is really no reason to use imageio native bindings left, GeoServer has faster PNG
encoding embedded since years (thanks to the PNGJ library) and faster JPEG encoding/decoding
tanks to the turbo-jpeg pluging. The TIFF reader has been replaced and the image streams too.

When it comes to jai-ext, which are the image processing operations like scaling/reprojecting,
the direction has been fixes, ROI support everywhere, and NODATA support.
Performance was still considered, but operations are generally not as fast as the native JAI equivalents
(they are normally as fast as the pure java JAI or faster, but providing improved correctness and features,
and when you really start using the extra features, there’s a performance penalty as there is more work involved).

It’s up to you to decide where you want to go. If you want highest possible performance and you don’t need
NODATA support, you have no masks, you reproject data very seldomly or see no white/black lines in the output,
then disable jai-ext and stick to Java 8 + native JAI. Mind this is a path that is going to eventually die out,
getting native JAI builds is harder and GeoServer tests are no longer checking proper functionality
under those conditions (since 2.15.0 was released). But it should be viable for a little while longer.

I’d suggest to run a benchmark comparing the two options, and see if you can live with the better supported version
(jai-ext) or actually need to go and use native JAI to get the required performance for your use case

Cheers
Andrea

···

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 ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

Joe we as a community have been looking at what it will take to replace JAI (as it was largely abandonded by Oracle). See review of open source alternatives and some planning here, recently we have had some progress (largely on my own time as a “hobby”) which I will be presenting at foss4g.

If you or your organization is interested I would love to talk with you offline … I have found that any speculation online makes folks think the problem is handled (and then there is no more funding or volunteer enthusiasm to address).

···


Jody Garnett