Migrating Java UI Client Applications to Openjdk 11 25Th October, 2018
Total Page:16
File Type:pdf, Size:1020Kb
Migrating Java UI Client Applications to OpenJDK 11 25th October, 2018 Phil Race, Sergey Bylokhov, Java Platform Group Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, timing, and pricing of any features or functionality described for Oracle’s products may change and remains at the sole discretion of Oracle Corporation. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Introduction • Lots of things have changed between 8u to 11 – For lots of different reasons. • Most desktop applications are still using JDK8u • Most applications will want to move to 11u and later soon as JDK 8 End Of Public Updates occurs for commercial and personal use. • This session is to help you understand what has changed that affects UI client applications, and what steps you can (or must) take to move your code to JDK 11 and later. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 3 Topics • OpenJDK and Oracle JDK • Desktop application migration issues in JDK11 • JavaFX removal from JDK11 • The deployment technologies removal from JDK11 Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 4 Oracle JDK and OpenJDK • OpenJDK project launched by Sun Microsystems in 2007 • All OpenJDK source had to be under an Open Source license – GPL v2 (+/- ClassPath Exception) where possible. • Lots of component code could not be so-licensed – Eg 3rd party commercially licensed libraries – Stayed as closed sources – Open source alternatives not used by Sun (now Oracle) JDK, only by OpenJDK • Plugin + Webstart not included in OpenJDK – closed source • JavaFX not part of OpenJDK – even when it became open source. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 5 Oracle JDK and OpenJDK • JDK7 was the first simultaneous release of both. • OpenJDK was a source code project – no binaries except an RI build. • Most users want binaries so still download and use Sun / Oracle JDK – Oracle JDK 7 ”behaviourally” compatible with previous releases, since it uses the same closed source components as before – Included Plugin + Webstart deployment technologies – Included JavaFX – And it was free (of charge) for commercial enterprise use etc. – Free update support of feature releases for several years – All still the case for JDK 8u (to date, but will be changing). Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 6 Oracle JDK and OpenJDK • Upshot of the preceding is that – Not many applications tested against OpenJDK – Few applications deployed on OpenJDK – Oracle focused on testing Oracle JDK • This is now all changing. – Oracle JDK is converging on OpenJDK in JDK 11 – Closed source components dropped • And this is against the backdrop of other disruptive changes which can affect applications Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 7 Changes in Oracle JDK 11 internals due to convergence with OpenJDK • Font Rasterization: T2K -> freetype • Lucida fonts removed. • Anti-aliased rendering : Ductus -> Marlin • JPEG encoding & decoding : Removal of closed libjpeg enhancements • Image processing -> Kodak CMS -> Little CMS – Removal of proprietary ICC profiles : impacts on color space conversion • Other updates : – Complex Text Layout : ICU -> harfbuzz • More info on some of these in upcoming slides. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 8 Changes in Oracle JDK 11 due to features etc • Java Module System (jigsaw) • 32 bit JDK is no more – no “client” VM , only “server” VM, startup time impacted, larger footprint. • HiDPI support for Windows (and Linux although less of a common client problem). Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 9 What are the potential impact of changes ? • Source code incompatiBilities • Binary incompatiBilities (!) • Module system impact • Behavioural changes • Performance changes • Removal of components / functionality • New features which require you to update your code for the best results. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 10 Text Rendering, Measurement and Performance • Some releases / builds of freetype are not consistent in text measurement across rendering modes • Freetype rasterization seems to be slower than T2K (investigation TBD). • JDK 11 uses the platform (system) installed freetype on Solaris & Linux, but a JDK bundled one on Mac and Windows • System freetype means it should render similarly to native apps (a +) • But may be different from the bundled version (a - ?) Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 11 Text Rendering, Measurement and Performance • We know from many discussions that Text Quality is – a) important – b) subjective. • Oracle JDK 11 now uses freetype (open source) instead of the closed source T2K rasterizer • T2K was not perfect as we know from many complaints, but – sometimes better the devil you know • Outside of bi-level instructed hinting there is no strict specification of how an OpenType rasterizer should behave. – So freetype may just be “different”, not wrong. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 12 Text Rendering, Measurement and Performance • Layout of Complex Text (Arabic, Indic, Thai, etc) – All releases / JDKs up to and including JDK 8u use “ICU” for opentype layout – JDK 9 and above all use “harfbuzz” – Both are open source, but harfbuzz is newer and maintained, supports far more features, is more secure etc. – Harfbuzz theoretically should be at least “as fast” as ICU, but some teething troubles • Known performance regressions in an area that is quite performance sensitive. • Working on isolating these issues. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 13 Lucida fonts removed from Oracle JDK 11 • Lucida Sans/Bright/Console have been shipped since JDK 1.2 • Many apps use them directly because they are always there – Except now they aren’t • Typically you will fall back to Dialog – using a Sans font instead of – getting a fixed width font when asking for Lucida Console – getting a Serif font when asking for Lucida Bright • Lucida Sans supported Arabic & Thai & Devanagari – Used as a fallback for logical fonts – Now without it you may get missing glyphs (blank space, or boxes) Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 14 JPEG reading & writing • If you haven’t already migrated from com.sun.jpeg.codec to javax.imageio do so now ! – The old non-standard one is completely removed • Oracle JDK used Kodak proprietary extensions to IJG JPEG to support additional color spaces. – These are removed. Use open source versions, system library where available – Most likely impact is that Oracle JDK previously would read and write 4 component ARGB images. Now these are rejected. – Applications will need to convert images to 3 component RGB to write them or use PNG encoding instead to keep transparency. – No good answer for reading but likely only JDK created such images. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 15 Image Processing • Closed source Kodak CMS was replaced by default with open source Little CMS for color space conversion of images. • Both shipped until JDK 10. Non-advertised system property to use KCMS • Existence proof of apps (pdfbox) that reQuest KCMS explicitly • Why ? When LCMS is modern and up to date? • Performance – KCMS would spawn up to 4 native threads to partition the work. Helps a lot on large images. • No immediate likelihood of LCMS doing the same so what can you do? Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 16 Image Processing – cont’d. • Application can process subimages in separate threads. • Split large image into bands and process concurrently int w = image.getWidth(null); int sub_hgt = image.getHeight(null) / 4; // Simplifying assumption hgt is multiple of 4 int y = 0; for (int i=0; i<sub_hgt; i++) { subImage[i] = image.getSubImage(0, i*sub_hgt, w, sub_hgt); processImageOnNewThread(i); // need to “join” to make sure all work is complete. } public void run() { // Runnable body new ColorConvertOp(null).filter(subImage[i], resImage[i]); } Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 17 Image Processing – cont’d. • ColorSpace conversion doesn’t use just a library – ICC Color profiles are data that define that characteristic of a color space. – JDK ships with profiles for common color spaces • sRGB, Linear RGB, Grayscale, PhotoYCC, CIEXYZ • JDK 11 removed those used since JDK 1.2 which were licensed under a commercial contract. – Replaced with ones that can be used in open source. • Color space conversion results will not be exactly as before. – Most applications won’t notice, either don’t use it or are not sensitive to the differences. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 18 Marlin anti-aliasing rasterizer • Marlin is a fork of the old OpenJDK Pisces rasterizer – Developed and maintained by an open source contributor, Laurent Bourges • Replaces old closed source Ductus Rasterizer as of JDK 9 – Mostly Java code but heavily tuned for performance – Much better multi-threaded performance