From philip.race at oracle.com Fri Mar 1 00:12:57 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Feb 2019 16:12:57 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8210782: Upgrade HarfBuzz to the latest 2.3.1 Message-ID: <5C787909.4090007@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8210782 Webrev: http://cr.openjdk.java.net/~prr/8210782/ This change upgrades JDK 13 from using harfbuzz v 1.8.1 to v 2.3.1 which is currently the latest release of harfbuzz harfbuzz is the 3rd party (external) C++ library used by OpenJDK for OpenType text layout. In this large upgrade - Many files were renamed following the pattern of "hb-foo-private.cc" becoming "hb-foo.cc" - Many new files were added - A couple of files were deleted. There are two additional changes on top of this I needed to import a published but un-released fix to enable building with Oracle Studio 12.6 on Solaris See https://github.com/harfbuzz/harfbuzz/commit/1e06282105a2d579aab32094cc7abc10ed231978 I needed to reapply a fix made in JDK as JDK-8218965 that mirrors upstream to support building with the latest AIX compilers See https://github.com/harfbuzz/harfbuzz/commit/5c2bb1de8de31fecf0dae2ef905b896e42d39f1d This doesn't show up as a "diff" in the JDK webrev which demonstrates that it is correctly re-applied as previously. There are two JDK files changed : (1) - The makefile has been updated to disable several new warnings. - To prevent harfbuzz from enabling warnings that were disabled - and avoid unknown pragma warnings we now define -DHB_NO_PRAGMA_GCC_DIAGNOSTIC See hb.hh for what harfbuzz is doing there, but without this -D option we cannot disable warnings from the build since they are enabled in the code itself. (2) - A couple of harfbuzz APIs were deprecated so I needed to make code changes in hb-jdk-font.cc to use the new API. I have tested that this builds cleanly with all the current devkits (via the build servers) and that it also builds with the in progress work to provide a gcc 8.2 devkit for Linux I have also run all the related automated tests and performed some manual testing too. -phil. From Sergey.Bylokhov at oracle.com Fri Mar 1 00:58:14 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 28 Feb 2019 16:58:14 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8210782: Upgrade HarfBuzz to the latest 2.3.1 In-Reply-To: <5C787909.4090007@oracle.com> References: <5C787909.4090007@oracle.com> Message-ID: <98ce3347-ad8f-960a-81b1-2d6ec7878d83@oracle.com> Hi, Phil. Should we update the "harfbuzz.md" file as well? On 28/02/2019 16:12, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8210782 > Webrev: http://cr.openjdk.java.net/~prr/8210782/ > > This change upgrades JDK 13 from using harfbuzz v 1.8.1 to v 2.3.1 which is currently the latest release of harfbuzz > > harfbuzz is the 3rd party (external) C++ library used by OpenJDK for OpenType text layout. > > In this large upgrade > - Many files were renamed following the pattern of "hb-foo-private.cc" becoming "hb-foo.cc" > - Many new files were added > - A couple of files were deleted. > > There are two additional changes on top of this > I needed to import a published but un-released fix to enable building with Oracle Studio 12.6 on Solaris > See https://github.com/harfbuzz/harfbuzz/commit/1e06282105a2d579aab32094cc7abc10ed231978 > I needed to reapply a fix made in JDK as JDK-8218965 that mirrors upstream to support building with the latest AIX compilers > See https://github.com/harfbuzz/harfbuzz/commit/5c2bb1de8de31fecf0dae2ef905b896e42d39f1d > This doesn't show up as a "diff" in the JDK webrev which demonstrates that it is correctly re-applied as previously. > > There are two JDK files changed : > (1) > - The makefile has been updated to disable several new warnings. > - To prevent harfbuzz from enabling warnings that were disabled - and avoid unknown pragma warnings we now define > > -DHB_NO_PRAGMA_GCC_DIAGNOSTIC > > > See hb.hh for what harfbuzz is doing there, but without this -D option we cannot > disable warnings from the build since they are enabled in the code itself. > > (2) > - A couple of harfbuzz APIs were deprecated so I needed to make code changes in hb-jdk-font.cc to use > the new API. > > I have tested that this builds cleanly with all the current devkits (via the build servers) and that it also builds > with the in progress work to provide a gcc 8.2 devkit for Linux > I have also run all the related automated tests and performed some manual testing too. > > -phil. -- Best regards, Sergey. From philip.race at oracle.com Fri Mar 1 01:55:38 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Feb 2019 17:55:38 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8210782: Upgrade HarfBuzz to the latest 2.3.1 In-Reply-To: <98ce3347-ad8f-960a-81b1-2d6ec7878d83@oracle.com> References: <5C787909.4090007@oracle.com> <98ce3347-ad8f-960a-81b1-2d6ec7878d83@oracle.com> Message-ID: <5C78911A.5040300@oracle.com> Oh yes we should :-). Good catch. The license isn't changed so its a small matter of changing what version we list in the file. http://cr.openjdk.java.net/~prr/8210782.1 -phil. On 2/28/19, 4:58 PM, Sergey Bylokhov wrote: > Hi, Phil. > Should we update the "harfbuzz.md" file as well? > > On 28/02/2019 16:12, Philip Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210782 >> Webrev: http://cr.openjdk.java.net/~prr/8210782/ >> >> This change upgrades JDK 13 from using harfbuzz v 1.8.1 to v 2.3.1 >> which is currently the latest release of harfbuzz >> >> harfbuzz is the 3rd party (external) C++ library used by OpenJDK for >> OpenType text layout. >> >> In this large upgrade >> - Many files were renamed following the pattern of >> "hb-foo-private.cc" becoming "hb-foo.cc" >> - Many new files were added >> - A couple of files were deleted. >> >> There are two additional changes on top of this >> I needed to import a published but un-released fix to enable building >> with Oracle Studio 12.6 on Solaris >> See >> https://github.com/harfbuzz/harfbuzz/commit/1e06282105a2d579aab32094cc7abc10ed231978 >> I needed to reapply a fix made in JDK as JDK-8218965 that mirrors >> upstream to support building with the latest AIX compilers >> See >> https://github.com/harfbuzz/harfbuzz/commit/5c2bb1de8de31fecf0dae2ef905b896e42d39f1d >> This doesn't show up as a "diff" in the JDK webrev which demonstrates >> that it is correctly re-applied as previously. >> >> There are two JDK files changed : >> (1) >> - The makefile has been updated to disable several new warnings. >> - To prevent harfbuzz from enabling warnings that were disabled - and >> avoid unknown pragma warnings we now define >> >> -DHB_NO_PRAGMA_GCC_DIAGNOSTIC >> >> >> See hb.hh for what harfbuzz is doing there, but without this -D >> option we cannot >> disable warnings from the build since they are enabled in the code >> itself. >> >> (2) >> - A couple of harfbuzz APIs were deprecated so I needed to make code >> changes in hb-jdk-font.cc to use >> the new API. >> >> I have tested that this builds cleanly with all the current devkits >> (via the build servers) and that it also builds >> with the in progress work to provide a gcc 8.2 devkit for Linux >> I have also run all the related automated tests and performed some >> manual testing too. >> >> -phil. > > From magnus.ihse.bursie at oracle.com Fri Mar 1 13:28:25 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 1 Mar 2019 14:28:25 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8210782: Upgrade HarfBuzz to the latest 2.3.1 In-Reply-To: <5C787909.4090007@oracle.com> References: <5C787909.4090007@oracle.com> Message-ID: <66f09936-1107-bbb2-2072-ad20f10d092c@oracle.com> On 2019-03-01 01:12, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8210782 > Webrev: http://cr.openjdk.java.net/~prr/8210782/ Looks good from a build PoV. /Magnus > > This change upgrades JDK 13 from using harfbuzz v 1.8.1 to v 2.3.1 > which is currently the latest release of harfbuzz > > harfbuzz is the 3rd party (external) C++ library used by OpenJDK for > OpenType text layout. > > In this large upgrade > - Many files were renamed following the pattern of > "hb-foo-private.cc"? becoming "hb-foo.cc" > - Many new files were added > - A couple of files were deleted. > > There are two additional changes on top of this > I needed to import a published but un-released fix to enable building > with Oracle Studio 12.6 on Solaris > See > https://github.com/harfbuzz/harfbuzz/commit/1e06282105a2d579aab32094cc7abc10ed231978 > I needed to reapply a fix made in JDK as JDK-8218965 that mirrors > upstream to support building with the latest AIX compilers > See > https://github.com/harfbuzz/harfbuzz/commit/5c2bb1de8de31fecf0dae2ef905b896e42d39f1d > This doesn't show up as a "diff" in the JDK webrev which demonstrates > that it is correctly re-applied as previously. > > There are two JDK files changed : > (1) > - The makefile has been updated to disable several new warnings. > - To prevent harfbuzz from enabling warnings that were disabled - and > avoid unknown pragma warnings we now define > > -DHB_NO_PRAGMA_GCC_DIAGNOSTIC > > > See hb.hh for what harfbuzz is doing there, but without this -D option > we cannot > disable warnings from the build since they are enabled in the code > itself. > > (2) > - A couple of harfbuzz APIs were deprecated so I needed to make code > changes in hb-jdk-font.cc to use > the new API. > > I have tested that this builds cleanly with all the current devkits > (via the build servers) and that it also builds > with the in progress work to provide a gcc 8.2 devkit for Linux > I have also run all the related automated tests and performed some > manual testing too. > > -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri Mar 1 15:02:31 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 Mar 2019 07:02:31 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8210782: Upgrade HarfBuzz to the latest 2.3.1 In-Reply-To: <5C787909.4090007@oracle.com> References: <5C787909.4090007@oracle.com> Message-ID: <609e3112-383a-224a-e01c-f51db19aa25a@oracle.com> Build changes look good. /Erik On 2019-02-28 16:12, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8210782 > Webrev: http://cr.openjdk.java.net/~prr/8210782/ > > This change upgrades JDK 13 from using harfbuzz v 1.8.1 to v 2.3.1 > which is currently the latest release of harfbuzz > > harfbuzz is the 3rd party (external) C++ library used by OpenJDK for > OpenType text layout. > > In this large upgrade > - Many files were renamed following the pattern of > "hb-foo-private.cc"? becoming "hb-foo.cc" > - Many new files were added > - A couple of files were deleted. > > There are two additional changes on top of this > I needed to import a published but un-released fix to enable building > with Oracle Studio 12.6 on Solaris > See > https://github.com/harfbuzz/harfbuzz/commit/1e06282105a2d579aab32094cc7abc10ed231978 > I needed to reapply a fix made in JDK as JDK-8218965 that mirrors > upstream to support building with the latest AIX compilers > See > https://github.com/harfbuzz/harfbuzz/commit/5c2bb1de8de31fecf0dae2ef905b896e42d39f1d > This doesn't show up as a "diff" in the JDK webrev which demonstrates > that it is correctly re-applied as previously. > > There are two JDK files changed : > (1) > - The makefile has been updated to disable several new warnings. > - To prevent harfbuzz from enabling warnings that were disabled - and > avoid unknown pragma warnings we now define > > -DHB_NO_PRAGMA_GCC_DIAGNOSTIC > > > See hb.hh for what harfbuzz is doing there, but without this -D option > we cannot > disable warnings from the build since they are enabled in the code > itself. > > (2) > - A couple of harfbuzz APIs were deprecated so I needed to make code > changes in hb-jdk-font.cc to use > the new API. > > I have tested that this builds cleanly with all the current devkits > (via the build servers) and that it also builds > with the in progress work to provide a gcc 8.2 devkit for Linux > I have also run all the related automated tests and performed some > manual testing too. > > -phil. From mbalao at redhat.com Fri Mar 1 15:28:46 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 1 Mar 2019 12:28:46 -0300 Subject: [OpenJDK 2D-Dev] RFR 8218854: FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth In-Reply-To: <5C76AAD4.2020806@oracle.com> References: <5C659C0E.3070307@oracle.com> <46dfa743-19c4-3b3e-d99d-299df7bb0a76@redhat.com> <5C6CAEB5.2060601@oracle.com> <539930ae-017a-3e92-de83-db80e73656dc@oracle.com> <5C6F54A7.80708@oracle.com> <5C6F54E5.2090705@oracle.com> <9157d658-ff76-a610-b2ee-461a2459ea2b@oracle.com> <3489d39e-8fdb-4106-b855-42f6b32357da@redhat.com> <5C76AAD4.2020806@oracle.com> Message-ID: <9b4ab6df-cf42-0c93-aa22-e319720e7b52@redhat.com> On 2/27/19 12:20 PM, Philip Race wrote: > The webrev still appears to be against jdk/jdk not jdk/client > > I had suggested excluding small point sizes since I don't think > the failures I saw can possibly be limited to Solaris ... it just > hasn't been reproduced elsewhere yet. Apologies for the misunderstanding. Webrev.04: * http://cr.openjdk.java.net/~mbalao/webrevs/8218854/8218854.webrev.04/ * http://cr.openjdk.java.net/~mbalao/webrevs/8218854/8218854.webrev.04.zip New: * Re-enabled Solaris * Changed font size to 10px * Unnecessary null check removed * Rebased against jdk/client Thanks, Martin.- From alexey.ivanov at oracle.com Fri Mar 1 19:32:24 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 1 Mar 2019 19:32:24 +0000 Subject: [OpenJDK 2D-Dev] RFR: JDK-8218682 + JDK-8198411: [TEST_BUG] DashOffset fails in mach5 + Two java2d tests are unstable in mach5 In-Reply-To: References: <050c8234-1222-fdd5-806d-e1a996aac0ed@oracle.com> <8645acca-e471-2fda-4bb1-c83a6cd5b4a2@oracle.com> <83dc49e5-53a6-f2d1-0324-8fc958cda49d@oracle.com> <4a389396-ddcc-f0af-d43a-50cd7e053309@oracle.com> <905907f4-0792-40e2-37d9-ce9fa27033f9@oracle.com> <977dc534-f011-3aec-b178-e4d1f0be8968@oracle.com> <9d064933-b188-fbdd-99af-325612b3dc04@oracle.com> Message-ID: On 21/02/2019 22:48, Sergey Bylokhov wrote: > On 21/02/2019 04:23, Alexey Ivanov wrote: >> Thank you, Sergey, for looking into this. >> I guess this case requires more investigation. At first sight, it >> does not look right, does it? > > Right, I am not sure that "IndexColorModel" is selected intentionally. > I have submitted: https://bugs.openjdk.java.net/browse/JDK-8219996 -- Regards, Alexey From Sergey.Bylokhov at oracle.com Sat Mar 2 00:10:44 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 1 Mar 2019 16:10:44 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8210782: Upgrade HarfBuzz to the latest 2.3.1 In-Reply-To: <5C78911A.5040300@oracle.com> References: <5C787909.4090007@oracle.com> <98ce3347-ad8f-960a-81b1-2d6ec7878d83@oracle.com> <5C78911A.5040300@oracle.com> Message-ID: Looks fine. On 28/02/2019 17:55, Philip Race wrote: > Oh yes we should :-). Good catch. > The license isn't changed so its a small matter of changing what version we list in the file. > http://cr.openjdk.java.net/~prr/8210782.1 > > -phil. > > On 2/28/19, 4:58 PM, Sergey Bylokhov wrote: >> Hi, Phil. >> Should we update the "harfbuzz.md" file as well? >> >> On 28/02/2019 16:12, Philip Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210782 >>> Webrev: http://cr.openjdk.java.net/~prr/8210782/ >>> >>> This change upgrades JDK 13 from using harfbuzz v 1.8.1 to v 2.3.1 which is currently the latest release of harfbuzz >>> >>> harfbuzz is the 3rd party (external) C++ library used by OpenJDK for OpenType text layout. >>> >>> In this large upgrade >>> - Many files were renamed following the pattern of "hb-foo-private.cc" becoming "hb-foo.cc" >>> - Many new files were added >>> - A couple of files were deleted. >>> >>> There are two additional changes on top of this >>> I needed to import a published but un-released fix to enable building with Oracle Studio 12.6 on Solaris >>> See https://github.com/harfbuzz/harfbuzz/commit/1e06282105a2d579aab32094cc7abc10ed231978 >>> I needed to reapply a fix made in JDK as JDK-8218965 that mirrors upstream to support building with the latest AIX compilers >>> See https://github.com/harfbuzz/harfbuzz/commit/5c2bb1de8de31fecf0dae2ef905b896e42d39f1d >>> This doesn't show up as a "diff" in the JDK webrev which demonstrates that it is correctly re-applied as previously. >>> >>> There are two JDK files changed : >>> (1) >>> - The makefile has been updated to disable several new warnings. >>> - To prevent harfbuzz from enabling warnings that were disabled - and avoid unknown pragma warnings we now define >>> >>> -DHB_NO_PRAGMA_GCC_DIAGNOSTIC >>> >>> >>> See hb.hh for what harfbuzz is doing there, but without this -D option we cannot >>> disable warnings from the build since they are enabled in the code itself. >>> >>> (2) >>> - A couple of harfbuzz APIs were deprecated so I needed to make code changes in hb-jdk-font.cc to use >>> the new API. >>> >>> I have tested that this builds cleanly with all the current devkits (via the build servers) and that it also builds >>> with the in progress work to provide a gcc 8.2 devkit for Linux >>> I have also run all the related automated tests and performed some manual testing too. >>> >>> -phil. >> >> -- Best regards, Sergey. From ecki at zusammenkunft.net Mon Mar 4 00:54:04 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 4 Mar 2019 01:54:04 +0100 Subject: [OpenJDK 2D-Dev] "java.lang.Error: Probable fatal error:No fonts found" does notshow on 11 In-Reply-To: References: <5c771cab.1c69fb81.bd016.d65b@mx.google.com>,<5C772127.9090706@oracle.com> Message-ID: <5c7c772c.1c69fb81.4eb17.6d3d@mx.google.com> Hello, the number of variations of this exception keeps increasing. When I use the RHEL8 beta with ist java-1.8.0-openjdk-headless.x86_64 (which has no fontconfig.* files and the libfontconfig is not installed) I get: [ecki at rhel8 ~]$ java -showversion FontTest openjdk version "1.8.0_181" OpenJDK Runtime Environment (build 1.8.0_181-b13) OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode) Are we headless? true g = sun.java2d.HeadlessGraphicsEnvironment headless: true Exception in thread "main" java.lang.NullPointerException at sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264) at sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:219) at sun.awt.FontConfiguration.init(FontConfiguration.java:107) at sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:774) at sun.font.SunFontManager$2.run(SunFontManager.java:431) at java.security.AccessController.doPrivileged(Native Method) at sun.font.SunFontManager.(SunFontManager.java:376) at sun.awt.FcFontManager.(FcFontManager.java:35) at sun.awt.X11FontManager.(X11FontManager.java:57) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:442) at sun.font.FontManagerFactory$1.run(FontManagerFactory.java:83) at java.security.AccessController.doPrivileged(Native Method) at sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) at sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:190) at sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:224) at sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:97) at FontTest.main(FontTest.java:15) [ecki at rhel8 ~]$ ls /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181.b13-9.el8.x86_64/jre/lib/*font* /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181.b13-9.el8.x86_64/jre/lib/psfontj2d.properties /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181.b13-9.el8.x86_64/jre/lib/psfont.properties.ja -- http://bernd.eckenfels.net Von: Bernd Eckenfels Gesendet: Donnerstag, 28. Februar 2019 09:56 An: 2d-dev Cc: Java Core Libs Betreff: Re: "java.lang.Error: Probable fatal error:No fonts found" does notshow on 11 Hello, I can confirm the same ugly error stack with 12-b33 EA, this time with debug: $ jdk-12/bin/java -cp . -Dsun.java2d.debugfonts=true FontTest Are we headless? true g = sun.java2d.HeadlessGraphicsEnvironment headless: true Feb 28, 2019 9:50:32 AM sun.awt.X11FontManager registerFontDir INFO: ParseFontDir /home/vagrant/jdk-12/lib/fonts Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration INFO: Creating standard Font Configuration Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.3.1611.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.3.1611.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.3.1611.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.3.1611.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findFontConfigFile INFO: Did not find a fontconfig file. Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration INFO: Creating standard Font Configuration Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.3.1611.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.3.1611.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.RedHat.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.3.1611.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.3.1611.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.7.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.properties Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /home/vagrant/jdk-12/lib/fontconfig.bfc Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findFontConfigFile INFO: Did not find a fontconfig file. Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for sans:regular:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for sans:bold:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for sans:regular:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for sans:bold:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for serif:regular:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for serif:bold:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for serif:regular:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for serif:bold:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for monospace:regular:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for monospace:bold:roman Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for monospace:regular:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no font for monospace:bold:italic Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts INFO: Fontconfig returned no fonts at all. Feb 28, 2019 9:50:32 AM sun.font.FcFontConfiguration warning WARNING: Failed to get info from libfontconfig Feb 28, 2019 9:50:32 AM sun.font.FcFontConfiguration warning WARNING: Failed to get info from libfontconfig Exception in thread "main" java.lang.InternalError: java.lang.reflect.InvocationTargetException ???????at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:86) ???????at java.base/java.security.AccessController.doPrivileged(AccessController.java:310) ???????at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) ???????at java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:189) ???????at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:223) ???????at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:251) ???????at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:75) Gruss Bernd -- http://bernd.eckenfels.net ? Von: Philip Race Gesendet: Donnerstag, Februar 28, 2019 12:45 AM An: Bernd Eckenfels; 2d-dev Cc: awt-dev at openjdk.java.net; Java Core Libs Betreff: Re: "java.lang.Error: Probable fatal error:No fonts found" does not show on 11 ? Wrong list. You want 2d-dev. -phil. On 2/27/19, 3:26 PM, Bernd Eckenfels wrote: > Hello, > > (please let me know in case I picked the wrong list.) > > Since OpenJDK does not ship Default *.ttf font files the change that a JRE is installed in a way that no System Fonts can be found is quite high. > > In OpenJDK8 it is a bit unfortunate that in this situation even for the headless graphics context that you can can a Java.lang.Error: > > I wonder if this is intentional. How About returnign an empty Array or Maybe a RntimeException instead? In my case by upgrading from Oracle JRE to Open JDK (in my case Azul) a perfectly fine working Installation is not aborting. > > The JasperReports component used is failing does not even need the System Fonts (which I will report to them seperately). For Zulu it is enough to install Dejavu Fonts in System Directory or copy them to JRE/lib/fonts/, but I have also seen OpenJDK builds which seem to use fontmanager libraries instead of fixed file path. Here I guess the dependency on System config is even higher. > > I tested on a minimal System with no X11: > >> ls /usr/share/fonts >> cat /etc/centos-release > CentOS Linux release 7.3.1611 (Core) > > And my test program (below) Returns for Java 8: > >> zulu8*x64/bin/java -cp . FontTest > Are we headless? true > g = sun.java2d.HeadlessGraphicsEnvironment headless: true > Exception in thread "main" java.lang.Error: Probable fatal error:No fonts found. > at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1236) > at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100) > ? > at sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1220) > at sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100) > at sun.font.SunFontManager.initialiseDeferredFonts(SunFontManager.java:927) > at sun.font.SunFontManager.loadFonts(SunFontManager.java:3302) > at sun.awt.X11FontManager.loadFonts(X11FontManager.java:466) > at sun.font.SunFontManager.loadFontFiles(SunFontManager.java:3429) > at sun.font.SunFontManager.getInstalledFontFamilyNames(SunFontManager.java:3766) > at sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:225) > at sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:252) > at sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:94) > at FontTest.main(FontTest.java:15) > > So the error in itself is one topic I wanted to inquire About. However, even worse in OpenJDK 11 the error seems to have degenerated quite a bit, it Looks for me: > >> zulu11*x64/bin/java -cp . FontTest > Are we headless? true > g = sun.java2d.HeadlessGraphicsEnvironment headless: true > Exception in thread "main" java.lang.InternalError: java.lang.reflect.InvocationTargetException > at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:86) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) > at java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:189) > at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:223) > at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:251) > at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:75) > at FontTest.main(FontTest.java:15) > Caused by: java.lang.reflect.InvocationTargetException > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) > at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:84) > ... 7 more > Caused by: java.lang.NullPointerException > at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1262) > at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:225) > at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:107) > at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:719) > at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:367) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.desktop/sun.font.SunFontManager.(SunFontManager.java:312) > at java.desktop/sun.awt.FcFontManager.(FcFontManager.java:35) > at java.desktop/sun.awt.X11FontManager.(X11FontManager.java:56) > ... 12 mor > > If there is no known issue for that, is it worth to file a Bug for it? (I Need to recreate it with a Oracle OpenJDK binary yet if it is only a fontconfig Problem ? but in that case a null check is probably also a good thing?) > > Gruss > Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: EA6736986DA24584AAEEB117A4BC8FAA.png Type: image/png Size: 144 bytes Desc: not available URL: From philip.race at oracle.com Mon Mar 4 15:47:49 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 04 Mar 2019 07:47:49 -0800 Subject: [OpenJDK 2D-Dev] "java.lang.Error: Probable fatal error:No fonts found" does notshow on 11 In-Reply-To: <5c7c772c.1c69fb81.4eb17.6d3d@mx.google.com> References: <5c771cab.1c69fb81.bd016.d65b@mx.google.com>, <5C772127.9090706@oracle.com> <5c7c772c.1c69fb81.4eb17.6d3d@mx.google.com> Message-ID: <5C7D48A5.4060208@oracle.com> This is getting into "why doesn't my app run if I remove things it needs to run ?" territory. A headless environment does not mean that fonts aren't needed. Headless environments are used to do text rendering. So whilst we could have a discussion about what form the error should take, at some point you should get an error. Silently returning from all text rendering related API calls without failing would be even worse. If you don't want to do anything with rendering, why is any kind of toolkit (headless or otherwise) being loaded ? The native fontconfig library isn't a runtime linker dependency only because we started using it before it could be guaranteed available for all the distro versions we support. If we were doing this today we'd almost certainly link at compile time and then if you did not install it your binary would not even start - even in headless mode. I say this not because it would somehow improve your situation, but to make clear that libfontconfig is not an optional library. So on Linux fonts need to be provided by at least one of : - the system + located using libfontconfig - in the JRE lib/fonts folder - in one of several unspecified system locations that are still searched by the code that pre-dates libfontconfig The 2nd + 3rd of these should be considered legacy. The 2nd applied to Oracle JDK when we shipped fonts, but adding your own fonts there is no longer supported by Oracle JDK or OpenJDK. The only scenario I can think of that might get by is where the app is supplying fonts using Font.createFont() and *only* those are used / needed I suspect that is a rare case and would help only a very specific controlled application where you knew you used those fonts and no other fonts. -phil. On 3/3/19, 4:54 PM, Bernd Eckenfels wrote: > > Hello, > > the number of variations of this exception keeps increasing. When I > use the RHEL8 beta with ist java-1.8.0-openjdk-headless.x86_64 (which > has no fontconfig.* files and the libfontconfig is not installed) I get: > > [ecki at rhel8 ~]$ java -showversion FontTest > > openjdk version "1.8.0_181" > > OpenJDK Runtime Environment (build 1.8.0_181-b13) > > OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode) > > Are we headless? true > > g = sun.java2d.HeadlessGraphicsEnvironment headless: true > > Exception in thread "main" java.lang.NullPointerException > > at > sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264) > > at > sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:219) > > at sun.awt.FontConfiguration.init(FontConfiguration.java:107) > > at > sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:774) > > at sun.font.SunFontManager$2.run(SunFontManager.java:431) > > at java.security.AccessController.doPrivileged(Native Method) > > at sun.font.SunFontManager.(SunFontManager.java:376) > > at sun.awt.FcFontManager.(FcFontManager.java:35) > > at sun.awt.X11FontManager.(X11FontManager.java:57) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > > at java.lang.Class.newInstance(Class.java:442) > > at sun.font.FontManagerFactory$1.run(FontManagerFactory.java:83) > > at java.security.AccessController.doPrivileged(Native Method) > > at > sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) > > at > sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:190) > > at > sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:224) > > at > sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:97) > > at FontTest.main(FontTest.java:15) > > [ecki at rhel8 ~]$ ls > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181.b13-9.el8.x86_64/jre/lib/*font* > > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181.b13-9.el8.x86_64/jre/lib/psfontj2d.properties > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.181.b13-9.el8.x86_64/jre/lib/psfont.properties.ja > > -- > http://bernd.eckenfels.net > > *Von: *Bernd Eckenfels > *Gesendet: *Donnerstag, 28. Februar 2019 09:56 > *An: *2d-dev > *Cc: *Java Core Libs > *Betreff: *Re: "java.lang.Error: Probable fatal error:No fonts found" > does notshow on 11 > > Hello, > > I can confirm the same ugly error stack with 12-b33 EA, this time with > debug: > > $ jdk-12/bin/java -cp . -Dsun.java2d.debugfonts=true FontTest > > Are we headless? true > > g = sun.java2d.HeadlessGraphicsEnvironment headless: true > > Feb 28, 2019 9:50:32 AM sun.awt.X11FontManager registerFontDir > > INFO: ParseFontDir /home/vagrant/jdk-12/lib/fonts > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration > > INFO: Creating standard Font Configuration > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.3.1611.properties > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.3.1611.bfc > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.properties > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.bfc > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.RedHat.properties > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.RedHat.bfc > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.7.3.1611.properties > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.7.3.1611.bfc > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.7.properties > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.7.bfc > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.properties > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.bfc > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findFontConfigFile > > INFO: Did not find a fontconfig file. > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration > > INFO: Creating standard Font Configuration > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.3.1611.properties > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.3.1611.bfc > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.properties > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.RedHat.7.bfc > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.RedHat.properties > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.RedHat.bfc > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.7.3.1611.properties > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.7.3.1611.bfc > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.7.properties > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.7.bfc > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.properties > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /home/vagrant/jdk-12/lib/fontconfig.bfc > > Feb 28, 2019 9:50:32 AM sun.awt.FontConfiguration findFontConfigFile > > INFO: Did not find a fontconfig file. > > Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts > > INFO: Fontconfig returned no font for sans:regular:roman > > Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts > > INFO: Fontconfig returned no font for sans:bold:roman > > Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts > > INFO: Fontconfig returned no font for sans:regular:italic > > Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts > > INFO: Fontconfig returned no font for sans:bold:italic > > Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts > > INFO: Fontconfig returned no font for serif:regular:roman > > Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts > > INFO: Fontconfig returned no font for serif:bold:roman > > Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts > > INFO: Fontconfig returned no font for serif:regular:italic > > Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts > > INFO: Fontconfig returned no font for serif:bold:italic > > Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts > > INFO: Fontconfig returned no font for monospace:regular:roman > > Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts > > INFO: Fontconfig returned no font for monospace:bold:roman > > Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts > > INFO: Fontconfig returned no font for monospace:regular:italic > > Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts > > INFO: Fontconfig returned no font for monospace:bold:italic > > Feb 28, 2019 9:50:32 AM sun.font.FontConfigManager initFontConfigFonts > > INFO: Fontconfig returned no fonts at all. > > Feb 28, 2019 9:50:32 AM sun.font.FcFontConfiguration warning > > WARNING: Failed to get info from libfontconfig > > Feb 28, 2019 9:50:32 AM sun.font.FcFontConfiguration warning > > WARNING: Failed to get info from libfontconfig > > Exception in thread "main" java.lang.InternalError: > java.lang.reflect.InvocationTargetException > > at > java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:86) > > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:310) > > at > java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) > > at > java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:189) > > at > java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:223) > > at > java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:251) > > at > java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:75) > > Gruss > > Bernd > > -- > > http://bernd.eckenfels.net > > *Von:*Philip Race > *Gesendet:* Donnerstag, Februar 28, 2019 12:45 AM > *An:* Bernd Eckenfels; 2d-dev > *Cc:* awt-dev at openjdk.java.net; Java Core Libs > *Betreff:* Re: "java.lang.Error: Probable fatal error:No fonts found" > does not show on 11 > > Wrong list. You want 2d-dev. > > -phil. > > On 2/27/19, 3:26 PM, Bernd Eckenfels wrote: > > Hello, > > > > (please let me know in case I picked the wrong list.) > > > > Since OpenJDK does not ship Default *.ttf font files the change that > a JRE is installed in a way that no System Fonts can be found is quite > high. > > > > In OpenJDK8 it is a bit unfortunate that in this situation even for > the headless graphics context that you can can a Java.lang.Error: > > > > I wonder if this is intentional. How About returnign an empty Array > or Maybe a RntimeException instead? In my case by upgrading from > Oracle JRE to Open JDK (in my case Azul) a perfectly fine working > Installation is not aborting. > > > > The JasperReports component used is failing does not even need the > System Fonts (which I will report to them seperately). For Zulu it is > enough to install Dejavu Fonts in System Directory or copy them to > JRE/lib/fonts/, but I have also seen OpenJDK builds which seem to use > fontmanager libraries instead of fixed file path. Here I guess the > dependency on System config is even higher. > > > > I tested on a minimal System with no X11: > > > >> ls /usr/share/fonts > >> cat /etc/centos-release > > CentOS Linux release 7.3.1611 (Core) > > > > And my test program (below) Returns for Java 8: > > > >> zulu8*x64/bin/java -cp . FontTest > > Are we headless? true > > g = sun.java2d.HeadlessGraphicsEnvironment headless: true > > Exception in thread "main" java.lang.Error: Probable fatal error:No > fonts found. > > at > sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1236) > > at > sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100) > > ? > > at > sun.font.SunFontManager.getDefaultPhysicalFont(SunFontManager.java:1220) > > at > sun.font.SunFontManager.initialiseDeferredFont(SunFontManager.java:1100) > > at > sun.font.SunFontManager.initialiseDeferredFonts(SunFontManager.java:927) > > at sun.font.SunFontManager.loadFonts(SunFontManager.java:3302) > > at sun.awt.X11FontManager.loadFonts(X11FontManager.java:466) > > at sun.font.SunFontManager.loadFontFiles(SunFontManager.java:3429) > > at > sun.font.SunFontManager.getInstalledFontFamilyNames(SunFontManager.java:3766) > > > at > sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:225) > > > at > sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:252) > > > at > sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:94) > > > at FontTest.main(FontTest.java:15) > > > > So the error in itself is one topic I wanted to inquire About. > However, even worse in OpenJDK 11 the error seems to have degenerated > quite a bit, it Looks for me: > > > >> zulu11*x64/bin/java -cp . FontTest > > Are we headless? true > > g = sun.java2d.HeadlessGraphicsEnvironment headless: true > > Exception in thread "main" java.lang.InternalError: > java.lang.reflect.InvocationTargetException > > at > java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:86) > > > at java.base/java.security.AccessController.doPrivileged(Native Method) > > at > java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) > > > at > java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:189) > > > at > java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:223) > > > at > java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:251) > > > at > java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:75) > > > at FontTest.main(FontTest.java:15) > > Caused by: java.lang.reflect.InvocationTargetException > > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > > > at > java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > > at > java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) > > at > java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:84) > > > ... 7 more > > Caused by: java.lang.NullPointerException > > at > java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1262) > > > at > java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:225) > > > at > java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:107) > > at > java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:719) > > > at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:367) > > at java.base/java.security.AccessController.doPrivileged(Native Method) > > at java.desktop/sun.font.SunFontManager.(SunFontManager.java:312) > > at java.desktop/sun.awt.FcFontManager.(FcFontManager.java:35) > > at java.desktop/sun.awt.X11FontManager.(X11FontManager.java:56) > > ... 12 mor > > > > If there is no known issue for that, is it worth to file a Bug for > it? (I Need to recreate it with a Oracle OpenJDK binary yet if it is > only a fontconfig Problem ? but in that case a null check is probably > also a good thing?) > > > > Gruss > > Bernd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.filippov at jetbrains.com Mon Mar 4 18:45:54 2019 From: mikhail.filippov at jetbrains.com (Mikhail Filippov) Date: Mon, 4 Mar 2019 21:45:54 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] 8218914: Support fonts installed per-user on Windows 10 In-Reply-To: <4e238824-5bd0-1734-9a64-20e8c2d206a7@oracle.com> References: <0C833624-5874-4B2F-A134-EBE98902EEE0@jetbrains.com> <5d7cee9a-fa57-4069-0c30-0de6f9992307@oracle.com> <4e238824-5bd0-1734-9a64-20e8c2d206a7@oracle.com> Message-ID: <1DE8890B-A08D-4CE2-A8F3-B9F013E56A36@jetbrains.com> Webrev with line-length fix: http://cr.openjdk.java.net/~dbatrak/8218914/webrev.03/ -- Mikhail Filippov Software Developer JetBrains http://jetbrains.com ?The Drive To Develop" > On 28 Feb 2019, at 00:35, Phil Race wrote: > > I have made sure this builds OK and that it passes at least basic tests. > Line 514 is MUCH more than 80 chars. Please break it. > > Once you get a 2nd review, your sponsor can push it to jdk/client. > > -phil > > On 2/19/19 5:57 AM, Mikhail Filippov wrote: >> New webrev with fixes: http://cr.openjdk.java.net/~dbatrak/8218914/webrev.02/ >> >> >>> On 15 Feb 2019, at 19:31, Phil Race > wrote: >>> >>> > 8218914: Handle the case when fonts are installed into user registry key. This is the default behaviour since Windows 10 1809. >>> >>> When you get to the point of preparing a changeset, this line should have the bug synopsis. >>> The text you have here is better placed on the "Summary:" line. >>> You seem to have lines > 80 chars. Please fix. >> I attached new webrev without commit message. >> >>> What does Windows do if a user installs a different version of a font already installed on the system ? >>> - Refuse to install it ? >>> - Use the system one ? >>> - Use the user one ? >>> >>> If it refuses to install it, we can ignore that problem. If it prefers one, we should make sure >>> we do the same. >> >> I check this case. If you have installed system-wide and user fonts system-wide font preferred. I changed call order in the patch to match this behaviour. >> >> >>> I think the comment >>> >>> /* Starting from Windows 10 Preview Build 17704 fonts are installed into user's home folder by default, >>> >>> can be misconstrued. It could be read as ALL fonts are installed into a user folder and >>> there is no more system location. I think you actually mean >>> >>> /* Starting from Windows 10 Preview Build 17704, when a user installs non-system fonts, >>> * then by default they are installed in a new per-user location as specified in a >>> * per user registry entry. >>> */ >> Comment fixed. >> >>> Have you tested this on a machine with at least several user fonts installed and >>> verified we still get ALL the same system fonts as well as the new user fonts ? >>> >>> Have you verified what this does on older OS versions ? >> On previous Windows version user fonts key not exists and fonts loading only from the system-wide key. >> >> >>> -phil. >>> >>> On 2/15/19 6:23 AM, Mikhail Filippov wrote: >>>> Hi. Please review the fix. >>>> >>>> patch: attached to message. >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8218914 >>>> webrev: http://cr.openjdk.java.net/~dbatrak/8218914/webrev.01/ >>>> >>>> Description: >>>> Starting from Windows 10 Preview Build 17704 fonts are installed into the user's home folder by default, and are listed in user's registry section. This is Microsoft blog post about it: "https://blogs.windows.com/windowsexperience/2018/06/27/announcing-windows-10-insider-preview-build-17704/ " I this patch I extract function for registry access and call it for two keys: HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. In original code fonts loading only from HKEY_LOCAL_MACHINE. >>>> >>>> >>>> >>>> -- >>>> Mikhail Filippov >>>> Software Developer >>>> JetBrains >>>> http://jetbrains.com >>>> ?The Drive To Develop" >>>> >>> >> >> -- >> Mikhail Filippov >> Software Developer >> JetBrains >> http://jetbrains.com >> ?The Drive To Develop" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Mon Mar 4 19:39:24 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 4 Mar 2019 20:39:24 +0100 Subject: [OpenJDK 2D-Dev] "java.lang.Error: Probable fatal error:No fontsfound" does notshow on 11 In-Reply-To: <5C7D48A5.4060208@oracle.com> References: <5c771cab.1c69fb81.bd016.d65b@mx.google.com>,<5C772127.9090706@oracle.com> <5c7c772c.1c69fb81.4eb17.6d3d@mx.google.com> <5C7D48A5.4060208@oracle.com> Message-ID: <5c7d7eec.1c69fb81.148d6.63f9@mx.google.com> Hello, Philip Race wrote: > This is getting into "why doesn't my app run if I remove > things it needs to run ?" territory. Yes and no, the errors are caused by missing dependency declarations in common OS as well as undocumented requirements ? no file delete caused those errors. > A headless environment does not mean that fonts aren't needed. > Headless environments are used to do text rendering. Agree. > So whilst we could have a discussion about what form the error > should take, at some point you should get an error. But: a) Different Java versions produce different types of throwables, Errors and Runtime exceptions. b) There is no specification which one can be expected (and catching Throwable is Pretty ugly in Terms of not suppressing real VM Errors) c) A NPE Looks like a condition which should not happen > Silently returning from all text rendering related API calls > without failing would be even worse. Ok, I can understand that it is probably too late to change this API. > If you don't want to do anything with rendering, why is any kind > of toolkit (headless or otherwise) being loaded ? I think JasperReport in that case _does_ want to render, but it uses user provided Fonts (it only merges the System font to make them available). But even if not, the component might also be deployed and crashes on initialization (which is certainly ugly but not uncommon in app servers). > The native fontconfig library isn't a runtime linker dependency only > because we started using it before it could be guaranteed available > for all the distro versions we support. At least Suse and Redhat do not define the dependency (which I understand is not a problem of OpenJDK upstream), but still a sign that the assumption could be documented a bit better. > If we were doing this today we'd almost certainly link at compile time > and then if you did not install it your binary would not even start - even in > headless mode. That decision would be clearer if there would be no Elaborate configuration system working around it. Maybe a good candidate for removal? > I say this not because it would somehow improve your situation, but > to make clear that libfontconfig is not an optional library. Well, if the moon is in the Right constellation it does works without. > So on Linux fonts need to be provided by at least one of : > -? the system + located using libfontconfig > - in the JRE lib/fonts folder > - in one of several? unspecified system locations that are still searched by > the Code that pre-dates libfontconfig > The 2nd + 3rd of these should be considered legacy. I figured that out (but it would be better to actually have a Statement in that direction) >The 2nd applied to Oracle JDK when we shipped fonts, but adding your own >fonts there is no longer supported by Oracle JDK or OpenJDK. Is there somewhere a deprecation notice? > The only scenario I can think of that might get by is where the app > is supplying fonts using Font.createFont() and *only* those are used / >needed >I suspect that is a rare case and would help only a very specific controlled >application where you knew you used those fonts and no other fonts. It is Pretty common on reporting Servers and other drawing-generating applications which don?t depend on System Fonts (but still want to enumerate them). For initial installations I guess it wont be that critical, you install it, it does not work, you add Fonts, done. However it does break when ?upgrading? a Oracle JDK with OpenJDK ? depending on the OS packages installed. (and some more weirdness like not having all known OS properties files in all variations of Java distributions (Zulu for example ships ?Fedora? but not ?RedHat? fontconfig properties) I feel I am done reporting, let me break down the issues so you can decide if any Needs addressing: a) The NullPointerException should probably be changed into an InternalError with helpful message b) The reflective wrappers in later versions should be unwrapped to get the formerly clean Error from Java 8. c) The Javadoc should Mention that you need to expect an error (and possibly how to catch it without swallowing other vmerrors) d) Somewhere the preferred way to deal with fontfonfig should be documented (and distributions should be made aware). e) If fontconfig properties should still be supported, provide a common set so that distributions which are for multiple OS have the Benefit of shared Knowledge. Gruss Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From neugens.limasoftware at gmail.com Mon Mar 4 21:23:04 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 4 Mar 2019 22:23:04 +0100 Subject: [OpenJDK 2D-Dev] "java.lang.Error: Probable fatal error:No fontsfound" does notshow on 11 In-Reply-To: <5c7d7eec.1c69fb81.148d6.63f9@mx.google.com> References: <5c771cab.1c69fb81.bd016.d65b@mx.google.com> <5C772127.9090706@oracle.com> <5c7c772c.1c69fb81.4eb17.6d3d@mx.google.com> <5C7D48A5.4060208@oracle.com> <5c7d7eec.1c69fb81.148d6.63f9@mx.google.com> Message-ID: Il giorno lun 4 mar 2019 alle ore 20:41 Bernd Eckenfels ha scritto: > > Hello, > > > > Philip Race wrote: > > > This is getting into "why doesn't my app run if I remove > > things it needs to run ?" territory. > > > > Yes and no, the errors are caused by missing dependency declarations in common OS as well as undocumented requirements ? no file delete caused those errors. > I agree with Phil here. Also, when you use the system RPM it should have a require dependency on one core x11 font package. Nevertheless, this is not a bug, but a user misconfiguration. > > A headless environment does not mean that fonts aren't needed. > > Headless environments are used to do text rendering. > > > > Agree. > > > So whilst we could have a discussion about what form the error > > should take, at some point you should get an error. > > But: > > > > Different Java versions produce different types of throwables, Errors and Runtime exceptions. > There is no specification which one can be expected (and catching Throwable is Pretty ugly in Terms of not suppressing real VM Errors) > A NPE Looks like a condition which should not happen > I think this is because different versions fail at different place? Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From dmitry.batrak at jetbrains.com Wed Mar 6 12:15:22 2019 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Wed, 6 Mar 2019 15:15:22 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls Message-ID: Hello, I'd like to submit a patch for JDK-8220231. I'm not a Committer, so I'll need someone to sponsor this change. The proposed approach is used without known issues in OpenJDK-based JetBrains Runtime for almost three years now. I've mentioned it previously on this mailing list ( https://mail.openjdk.java.net/pipermail/2d-dev/2017-August/008497.html). The change has been refactored as compared to the version mentioned above (the logic has been moved to SunLayoutEngine), and includes the removal of font tables caching (JDK-8186317). The latter, I believe, becomes redundant with this fix. Issue: https://bugs.openjdk.java.net/browse/JDK-8220231 Webrev: http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/ Best regards, Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Mar 8 00:21:40 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 08 Mar 2019 05:51:40 +0530 Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls In-Reply-To: References: Message-ID: <5C81B594.6060209@oracle.com> This looks good to me, if I understand correctly that we now create the face on first use and cache it fin Java or as long as the Font2D is alive. And the JNIEnv is always found on I think you are right that we don't need the caching of the tables since now the face will do it. The unfortunate thing is that the removal of this code is well over half the changes and as such it greatly muddied finding the changes that make the performance difference so my review was harder and less certain because of that. It could have been separated into a follow-on change I think so that it would have been easier to review the important change. The pScaler parameter looks like it is unused these days which is why I expect you removed it but also not directly relevant. I have run builds + some tests - but I'm not in a position to run more tests for a couple of weeks. A (mild) stress test re-using the same font from multiple threads eachmaking multiple calls into layout would be a good addition here. That should help tell us if there are any MT or re-entrancy problems. Can you provide such a test ? It will be a good thing to have automatically run to catch any problems introduced later either on the Java side or by an update to harfbuzz. -phil. On 3/6/19, 5:45 PM, Dmitry Batrak wrote: > Hello, > > I'd like to submit a patch for JDK-8220231. I'm not a Committer, so > I'll need someone to sponsor this change. > > The proposed approach is used without known issues in OpenJDK-based > JetBrains Runtime for almost three years now. I've mentioned it > previously on this mailing list > (https://mail.openjdk.java.net/pipermail/2d-dev/2017-August/008497.html). > The change has been refactored as compared to the version mentioned > above (the logic has been moved to SunLayoutEngine), and includes the > removal of font tables caching (JDK-8186317). The latter, I believe, > becomes redundant with this fix. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8220231 > Webrev: http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/ > > > Best regards, > Dmitry Batrak > From ebakke at ultorg.com Fri Mar 8 19:54:26 2019 From: ebakke at ultorg.com (Eirik Bakke) Date: Fri, 8 Mar 2019 19:54:26 +0000 Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls In-Reply-To: References: Message-ID: A random Java developer here passing by... great to see work on HarfBuzz performance! Thanks for your efforts to push JetBrains JDK improvements upstream. I wonder if this patch might also fix or improve https://bugs.openjdk.java.net/browse/JDK-8202131 ? In case it's of any use, I have a ready-made performance test for this at https://gist.github.com/eirikbakke/81eec72221c9d7d8fc0b4afa9c54a163 . -- Eirik From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Dmitry Batrak Sent: Wednesday, March 6, 2019 7:15 AM To: 2d-dev <2d-dev at openjdk.java.net> Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls Hello, I'd like to submit a patch for JDK-8220231. I'm not a Committer, so I'll need someone to sponsor this change. The proposed approach is used without known issues in OpenJDK-based JetBrains Runtime for almost three years now. I've mentioned it previously on this mailing list (https://mail.openjdk.java.net/pipermail/2d-dev/2017-August/008497.html). The change has been refactored as compared to the version mentioned above (the logic has been moved to SunLayoutEngine), and includes the removal of font tables caching (JDK-8186317). The latter, I believe, becomes redundant with this fix. Issue: https://bugs.openjdk.java.net/browse/JDK-8220231 Webrev: http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/ Best regards, Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sun Mar 10 07:07:39 2019 From: philip.race at oracle.com (Philip Race) Date: Sun, 10 Mar 2019 12:37:39 +0530 Subject: [OpenJDK 2D-Dev] RFR 8218854: FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth In-Reply-To: <9b4ab6df-cf42-0c93-aa22-e319720e7b52@redhat.com> References: <5C659C0E.3070307@oracle.com> <46dfa743-19c4-3b3e-d99d-299df7bb0a76@redhat.com> <5C6CAEB5.2060601@oracle.com> <539930ae-017a-3e92-de83-db80e73656dc@oracle.com> <5C6F54A7.80708@oracle.com> <5C6F54E5.2090705@oracle.com> <9157d658-ff76-a610-b2ee-461a2459ea2b@oracle.com> <3489d39e-8fdb-4106-b855-42f6b32357da@redhat.com> <5C76AAD4.2020806@oracle.com> <9b4ab6df-cf42-0c93-aa22-e319720e7b52@redhat.com> Message-ID: <5C84B7BB.7070905@oracle.com> +1 (approved) -phil. On 3/1/19, 8:58 PM, Martin Balao wrote: > On 2/27/19 12:20 PM, Philip Race wrote: >> The webrev still appears to be against jdk/jdk not jdk/client >> >> I had suggested excluding small point sizes since I don't think >> the failures I saw can possibly be limited to Solaris ... it just >> hasn't been reproduced elsewhere yet. > Apologies for the misunderstanding. > > Webrev.04: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8218854/8218854.webrev.04/ > > * http://cr.openjdk.java.net/~mbalao/webrevs/8218854/8218854.webrev.04.zip > > New: > > * Re-enabled Solaris > > * Changed font size to 10px > > * Unnecessary null check removed > > * Rebased against jdk/client > > Thanks, > Martin.- From philip.race at oracle.com Sun Mar 10 09:05:18 2019 From: philip.race at oracle.com (Philip Race) Date: Sun, 10 Mar 2019 14:35:18 +0530 Subject: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont In-Reply-To: References: Message-ID: <5C84D34E.2070601@oracle.com> I can sponsor this but first : You seem to have made "family" redundant but aren't removing it. There's no point in writing it out if nothing uses it on reading. So we should remove it unless you can explain why you think it should be kept. I don't think this (removing it) is a problem for backports or compatibility of the format since release name is part of the file name where we write the information, and such a file name will necessarily be a consequence of a feature or update release containing this fix. Where it might be an issue is testing on 13-ea builds since they all report that as the version string so for testing you may need to clean out your ~/.java/fonts/13-ea folder. The same is for your 13-internal private builds. I think this is your point when you wrote :- The cached font list is stored under ~/.java/fonts directory. We should delete it before applying the fix. So you don't need to clean everything - just your develop -internal and -ea folders. Meanwhile I tested it .. and it seemed OK but I am still trying to join up all the dots to make sure it is all correct code-wise. -phil On 2/28/19, 3:21 PM, Toshio 5 Nakamura wrote: > > Hi, > > Could you review the fix and may I have a sponsor for it? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219901 > Webrev: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.00/ > > > Issue: > Even if Google Noto fonts[1] were installed and listed by fontconfig > library > on Linux, CompositeFont couldn't contain it. > > Fix description: > "src/java.desktop/share/classes/sun/font/CompositeFont.java" (l. 296) > validates the target font by comparing names. But, the current code > compared FamilyName with FullName (Font.getFontName()). > Then, Noto font was treated as invalid. > "src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java" > should provide FullName. > > The cached font list is stored under ~/.java/fonts directory. > We should delete it before applying the fix. > > This fix is possible to change the default font, if CompositeFont > is used (especially under Ubuntu18.04 and East Asian settings). > But, I believe the fixed behavior is correct. > > [1] https://www.google.com/get/noto/ > > Thanks, > Toshio Nakamura > -------------- next part -------------- An HTML attachment was scrubbed... URL: From TOSHIONA at jp.ibm.com Mon Mar 11 12:57:47 2019 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Mon, 11 Mar 2019 21:57:47 +0900 Subject: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont In-Reply-To: <5C84D34E.2070601@oracle.com> References: <5C84D34E.2070601@oracle.com> Message-ID: Hi Phil, Thank you so much for your reviewing. Yes, "family" part can be removed with a few changes in "src/java.desktop/unix/classes/sun/awt/FcFontManager.java". The updated webrev is: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.01/ > So you don't need to clean everything - just your develop -internal > and -ea folders. Yes, thank you for the clarification. Thanks, Toshio Nakamura Philip Race wrote on 2019/03/10 18:05:18: > From: Philip Race > To: Toshio 5 Nakamura > Cc: 2d-dev <2d-dev at openjdk.java.net> > Date: 2019/03/10 18:05 > Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East > Asian countries cannot belong to CompositeFont > > I can sponsor this but first : > > You seem to have made "family" redundant but aren't removing it. > There's no point in writing it out if nothing uses it on reading. > So we should remove it unless you can explain why you think it should be kept. > > I don't think this (removing it) is a problem for backports or > compatibility of the > format since release name is part of the file name where we write > the information, > and such a file name will necessarily be a consequence of a feature > or update release > containing this fix. > > Where it might be an issue is testing on 13-ea builds since they all report > that as the version string so for testing you may need to clean out your > ~/.java/fonts/13-ea folder. The same is for your 13-internal private builds. > > I think this is your point when you wrote :- > >> The cached font list is stored under ~/.java/fonts directory. >> We should delete it before applying the fix. > > So you don't need to clean everything - just your develop -internal > and -ea folders. > > Meanwhile I tested it .. and it seemed OK but I am still trying to join > up all the dots to make sure it is all correct code-wise. > > -phil > > On 2/28/19, 3:21 PM, Toshio 5 Nakamura wrote: > Hi, > > Could you review the fix and may I have a sponsor for it? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219901 > Webrev: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.00/ > > Issue: > Even if Google Noto fonts[1] were installed and listed by fontconfig library > on Linux, CompositeFont couldn't contain it. > > Fix description: > "src/java.desktop/share/classes/sun/font/CompositeFont.java" (l. 296) > validates the target font by comparing names. But, the current code > compared FamilyName with FullName (Font.getFontName()). > Then, Noto font was treated as invalid. > "src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java" > should provide FullName. > > The cached font list is stored under ~/.java/fonts directory. > We should delete it before applying the fix. > > This fix is possible to change the default font, if CompositeFont > is used (especially under Ubuntu18.04 and East Asian settings). > But, I believe the fixed behavior is correct. > > [1] https://www.google.com/get/noto/ > > Thanks, > Toshio Nakamura -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Mar 12 04:38:51 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 11 Mar 2019 21:38:51 -0700 Subject: [OpenJDK 2D-Dev] RFR(S): 8214343: Handle the absence of Xrandr more generically In-Reply-To: References: Message-ID: <70d5f3d3-63b9-c9aa-8569-3a1131825b64@oracle.com> Hi, Volker. On 27/11/2018 05:52, Volker Simonis wrote: > Change JDK-8213944 fixed the build on AIX (which has no Xrandr) by > conditionally excluding the relevant parts on AIX with the help of > preprocessor defines. On the mailing lists the wish was expressed to > handle the absence of Xrandr more generically during the configure > step, so here comes the corresponding change. I am working on the fix for the multiscreen support in jdk, currently our code is based on the xinerama and has some issues. I have an option to migrate to xrandr. Can you please provide some info about xinerama support in the AIX or it is unsupported in the same way as xrandr? -- Best regards, Sergey. From dmitry.batrak at jetbrains.com Tue Mar 12 08:32:24 2019 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Tue, 12 Mar 2019 11:32:24 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls In-Reply-To: <5C81B594.6060209@oracle.com> References: <5C81B594.6060209@oracle.com> Message-ID: > This looks good to me, if I understand correctly that we now create > the face on first use and cache it fin Java or as long as the Font2D is > alive. > And the JNIEnv is always found on That's correct. The assumption is that HarfBuzz doesn't create its own threads, so HarfBuzz-related native code will always be invoked from a Java thread (as part of 'shape' call), and so JNIEnv will be available in that context. I've updated the webrev by including a stress test for multi-threaded behaviour testing. Apart from the test, webrev also has some cosmetic differences from the previous version (like a comment fix or parameter order changing), appeared during 'splitting' process. To simplify the review, I'm also providing the links to the 'split' version of the same webrev - three parts that produce the same result when combined. I've not tested the changes separately (except basic compilation check). Complete change: http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01/ Part 1 (caching hb_face_t): http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-1/ Part 2 (tables caching removal): http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-2/ Part 3 (scaler pointer passing removal): http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-3/ Best regards, Dmitry Batrak On Fri, Mar 8, 2019 at 3:21 AM Philip Race wrote: > This looks good to me, if I understand correctly that we now create > the face on first use and cache it fin Java or as long as the Font2D is > alive. > And the JNIEnv is always found on > > I think you are right that we don't need the caching of the tables since > now the face will do it. The unfortunate thing is that the removal of > this code is > well over half the changes and as such it greatly muddied finding the > changes > that make the performance difference so my review was harder and less > certain > because of that. > It could have been separated into a follow-on change I think so that it > would have > been easier to review the important change. > > The pScaler parameter looks like it is unused these days which is why I > expect you removed it but also not directly relevant. > > I have run builds + some tests - but I'm not in a position to run more > tests > for a couple of weeks. > > A (mild) stress test re-using the same font from multiple threads > eachmaking > multiple calls into layout would be a good addition here. That should > help tell > us if there are any MT or re-entrancy problems. Can you provide such a > test ? > It will be a good thing to have automatically run to catch any problems > introduced later either on the Java side or by an update to harfbuzz. > > -phil. > > > > On 3/6/19, 5:45 PM, Dmitry Batrak wrote: > > Hello, > > > > I'd like to submit a patch for JDK-8220231. I'm not a Committer, so > > I'll need someone to sponsor this change. > > > > The proposed approach is used without known issues in OpenJDK-based > > JetBrains Runtime for almost three years now. I've mentioned it > > previously on this mailing list > > (https://mail.openjdk.java.net/pipermail/2d-dev/2017-August/008497.html > ). > > The change has been refactored as compared to the version mentioned > > above (the logic has been moved to SunLayoutEngine), and includes the > > removal of font tables caching (JDK-8186317). The latter, I believe, > > becomes redundant with this fix. > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8220231 > > Webrev: http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/ > > > > > > Best regards, > > Dmitry Batrak > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.batrak at jetbrains.com Tue Mar 12 08:36:10 2019 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Tue, 12 Mar 2019 11:36:10 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls In-Reply-To: References: Message-ID: > I wonder if this patch might also fix or improve https://bugs.openjdk.java.net/browse/JDK-8202131 ? In case it's of any use, I have a ready-made performance test for this at https://gist.github.com/eirikbakke/81eec72221c9d7d8fc0b4afa9c54a163 . The proposed change improves the result of your performance test significantly, but it's still about two times slower as compared to 1.8.0_202 results on my machine. Best regards, Dmitry Batrak On Fri, Mar 8, 2019 at 10:54 PM Eirik Bakke wrote: > A random Java developer here passing by... great to see work on HarfBuzz > performance! Thanks for your efforts to push JetBrains JDK improvements > upstream. > > > > I wonder if this patch might also fix or improve > https://bugs.openjdk.java.net/browse/JDK-8202131 ? In case it's of any > use, I have a ready-made performance test for this at > https://gist.github.com/eirikbakke/81eec72221c9d7d8fc0b4afa9c54a163 . > > > > -- Eirik > > > > > > *From:* 2d-dev <2d-dev-bounces at openjdk.java.net> *On Behalf Of *Dmitry > Batrak > *Sent:* Wednesday, March 6, 2019 7:15 AM > *To:* 2d-dev <2d-dev at openjdk.java.net> > *Subject:* [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object > for same font's text layout calls > > > > Hello, > > I'd like to submit a patch for JDK-8220231. I'm not a Committer, so I'll > need someone to sponsor this change. > > The proposed approach is used without known issues in OpenJDK-based > JetBrains Runtime for almost three years now. I've mentioned it previously > on this mailing list ( > https://mail.openjdk.java.net/pipermail/2d-dev/2017-August/008497.html). > > The change has been refactored as compared to the version mentioned above > (the logic has been moved to SunLayoutEngine), and includes the removal of > font tables caching (JDK-8186317). The latter, I believe, becomes redundant > with this fix. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8220231 > Webrev: http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/ > > Best regards, > Dmitry Batrak > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Mar 12 17:37:52 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 12 Mar 2019 18:37:52 +0100 Subject: [OpenJDK 2D-Dev] RFR(S): 8214343: Handle the absence of Xrandr more generically In-Reply-To: <70d5f3d3-63b9-c9aa-8569-3a1131825b64@oracle.com> References: <70d5f3d3-63b9-c9aa-8569-3a1131825b64@oracle.com> Message-ID: On Tue, Mar 12, 2019 at 5:38 AM Sergey Bylokhov wrote: > > Hi, Volker. > > On 27/11/2018 05:52, Volker Simonis wrote: > > Change JDK-8213944 fixed the build on AIX (which has no Xrandr) by > > conditionally excluding the relevant parts on AIX with the help of > > preprocessor defines. On the mailing lists the wish was expressed to > > handle the absence of Xrandr more generically during the configure > > step, so here comes the corresponding change. > > I am working on the fix for the multiscreen support in jdk, > currently our code is based on the xinerama and has some issues. I have an > option to migrate to xrandr. > > Can you please provide some info about xinerama support in the AIX or > it is unsupported in the same way as xrandr? > Hi Sergey, yes, the good thing is that AIX has xinerama support, at least client-side (I don't know if the native Xserver is really supporting it but I don't think that many people are really sitting in front of an AIX server nowadays anyway :). The bad thing is that the xinerama support apparently never ever really worked on AIX. I've opened "8220528: [AIX] Fix basic Xinerama functionality" (https://bugs.openjdk.java.net/browse/JDK-8220528) for it and will post a fix tomorrow. Thank you and best regards, Volker > -- > Best regards, Sergey. From m.yamamoto at change-vision.com Tue Mar 12 23:47:55 2019 From: m.yamamoto at change-vision.com (Mitsuhiro Yamamoto) Date: Wed, 13 Mar 2019 08:47:55 +0900 Subject: [OpenJDK 2D-Dev] Fonts with embedded bitmaps are not always rotated Message-ID: Hi there, I found the bug "Fonts with embedded bitmaps are not always rotated" in Java8. It seems that this bug is fixed for Java11. ( https://bugs.openjdk.java.net/browse/JDK-8204929) There was the issue on this bug in Java8. But it is closed as duplicated. ( https://bugs.openjdk.java.net/browse/JDK-8163278) Now this bug is NOT fixed in Java8. I think this could perhaps be the right issue to reopen and fixed(backported). Best Regards Mit -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Wed Mar 13 00:09:23 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 12 Mar 2019 21:09:23 -0300 Subject: [OpenJDK 2D-Dev] RFR 8218854: FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth In-Reply-To: <5C84B7BB.7070905@oracle.com> References: <5C659C0E.3070307@oracle.com> <46dfa743-19c4-3b3e-d99d-299df7bb0a76@redhat.com> <5C6CAEB5.2060601@oracle.com> <539930ae-017a-3e92-de83-db80e73656dc@oracle.com> <5C6F54A7.80708@oracle.com> <5C6F54E5.2090705@oracle.com> <9157d658-ff76-a610-b2ee-461a2459ea2b@oracle.com> <3489d39e-8fdb-4106-b855-42f6b32357da@redhat.com> <5C76AAD4.2020806@oracle.com> <9b4ab6df-cf42-0c93-aa22-e319720e7b52@redhat.com> <5C84B7BB.7070905@oracle.com> Message-ID: <5d1606ca-b7b0-eed1-cd2c-e5128a063dc3@redhat.com> On 3/10/19 4:07 AM, Philip Race wrote: > +1 (approved) > > -phil. > Pushed to client [1]. Thanks! -- [1] - http://hg.openjdk.java.net/jdk/client/rev/0804f29e8be7 From philip.race at oracle.com Wed Mar 13 01:13:22 2019 From: philip.race at oracle.com (Philip Race) Date: Wed, 13 Mar 2019 06:43:22 +0530 Subject: [OpenJDK 2D-Dev] Fonts with embedded bitmaps are not always rotated In-Reply-To: References: Message-ID: <5C885932.5080405@oracle.com> Hi, 1) Issues are NOT re-opened to be backported. That is not how JBS works 2) The issue is not in Oracle JDK 8, it is only in OpenJDK 8. So long as you use Oracle JDK 8 you should not be seeing this. 3) This is not a bug report or support alias. Problems with a binary product should be sent to whoever provided you with the binary product. -phil. On 3/13/19, 5:17 AM, Mitsuhiro Yamamoto wrote: > Hi there, > I found the bug "Fonts with embedded bitmaps are not always rotated" > in Java8. > It seems that this bug is fixed for > Java11. (https://bugs.openjdk.java.net/browse/JDK-8204929) > There was the issue on this bug in Java8. But it is closed as > duplicated. (https://bugs.openjdk.java.net/browse/JDK-8163278) > Now this bug is NOT fixed in Java8. > I think this could perhaps be the right issue to reopen and > fixed(backported). > > Best Regards > Mit -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebakke at ultorg.com Wed Mar 13 02:09:16 2019 From: ebakke at ultorg.com (Eirik Bakke) Date: Wed, 13 Mar 2019 02:09:16 +0000 Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls In-Reply-To: References: Message-ID: Thanks for running the benchmark! I suspect your patch removed some of the "startup" portion of the cost that was previously associated with a call to layoutGlyphVector or LineBreakMeasurer--that's a very good step in the right direction. -- Eirik From: Dmitry Batrak Sent: Tuesday, March 12, 2019 4:36 AM To: Eirik Bakke Cc: 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls > I wonder if this patch might also fix or improve https://bugs.openjdk.java.net/browse/JDK-8202131 ? In case it's of any use, I have a ready-made performance test for this at https://gist.github.com/eirikbakke/81eec72221c9d7d8fc0b4afa9c54a163 . The proposed change improves the result of your performance test significantly, but it's still about two times slower as compared to 1.8.0_202 results on my machine. Best regards, Dmitry Batrak On Fri, Mar 8, 2019 at 10:54 PM Eirik Bakke > wrote: A random Java developer here passing by... great to see work on HarfBuzz performance! Thanks for your efforts to push JetBrains JDK improvements upstream. I wonder if this patch might also fix or improve https://bugs.openjdk.java.net/browse/JDK-8202131 ? In case it's of any use, I have a ready-made performance test for this at https://gist.github.com/eirikbakke/81eec72221c9d7d8fc0b4afa9c54a163 . -- Eirik From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Dmitry Batrak Sent: Wednesday, March 6, 2019 7:15 AM To: 2d-dev <2d-dev at openjdk.java.net> Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls Hello, I'd like to submit a patch for JDK-8220231. I'm not a Committer, so I'll need someone to sponsor this change. The proposed approach is used without known issues in OpenJDK-based JetBrains Runtime for almost three years now. I've mentioned it previously on this mailing list (https://mail.openjdk.java.net/pipermail/2d-dev/2017-August/008497.html). The change has been refactored as compared to the version mentioned above (the logic has been moved to SunLayoutEngine), and includes the removal of font tables caching (JDK-8186317). The latter, I believe, becomes redundant with this fix. Issue: https://bugs.openjdk.java.net/browse/JDK-8220231 Webrev: http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/ Best regards, Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.filippov at jetbrains.com Wed Mar 13 06:38:04 2019 From: mikhail.filippov at jetbrains.com (Mikhail Filippov) Date: Wed, 13 Mar 2019 09:38:04 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] 8218914: Support fonts installed per-user on Windows 10 In-Reply-To: <1DE8890B-A08D-4CE2-A8F3-B9F013E56A36@jetbrains.com> References: <0C833624-5874-4B2F-A134-EBE98902EEE0@jetbrains.com> <5d7cee9a-fa57-4069-0c30-0de6f9992307@oracle.com> <4e238824-5bd0-1734-9a64-20e8c2d206a7@oracle.com> <1DE8890B-A08D-4CE2-A8F3-B9F013E56A36@jetbrains.com> Message-ID: <00184337-A68E-490F-A417-219847DA4565@jetbrains.com> I looking for the second reviewer and sponsor for my font patch: http://cr.openjdk.java.net/~dbatrak/8218914/webrev.03/ -- Mikhail Filippov Software Developer JetBrains http://jetbrains.com ?The Drive To Develop" > On 4 Mar 2019, at 21:45, Mikhail Filippov wrote: > > Webrev with line-length fix: http://cr.openjdk.java.net/~dbatrak/8218914/webrev.03/ > -- > Mikhail Filippov > Software Developer > JetBrains > http://jetbrains.com > ?The Drive To Develop" > >> On 28 Feb 2019, at 00:35, Phil Race > wrote: >> >> I have made sure this builds OK and that it passes at least basic tests. >> Line 514 is MUCH more than 80 chars. Please break it. >> >> Once you get a 2nd review, your sponsor can push it to jdk/client. >> >> -phil >> >> On 2/19/19 5:57 AM, Mikhail Filippov wrote: >>> New webrev with fixes: http://cr.openjdk.java.net/~dbatrak/8218914/webrev.02/ >>> >>> >>>> On 15 Feb 2019, at 19:31, Phil Race > wrote: >>>> >>>> > 8218914: Handle the case when fonts are installed into user registry key. This is the default behaviour since Windows 10 1809. >>>> >>>> When you get to the point of preparing a changeset, this line should have the bug synopsis. >>>> The text you have here is better placed on the "Summary:" line. >>>> You seem to have lines > 80 chars. Please fix. >>> I attached new webrev without commit message. >>> >>>> What does Windows do if a user installs a different version of a font already installed on the system ? >>>> - Refuse to install it ? >>>> - Use the system one ? >>>> - Use the user one ? >>>> >>>> If it refuses to install it, we can ignore that problem. If it prefers one, we should make sure >>>> we do the same. >>> >>> I check this case. If you have installed system-wide and user fonts system-wide font preferred. I changed call order in the patch to match this behaviour. >>> >>> >>>> I think the comment >>>> >>>> /* Starting from Windows 10 Preview Build 17704 fonts are installed into user's home folder by default, >>>> >>>> can be misconstrued. It could be read as ALL fonts are installed into a user folder and >>>> there is no more system location. I think you actually mean >>>> >>>> /* Starting from Windows 10 Preview Build 17704, when a user installs non-system fonts, >>>> * then by default they are installed in a new per-user location as specified in a >>>> * per user registry entry. >>>> */ >>> Comment fixed. >>> >>>> Have you tested this on a machine with at least several user fonts installed and >>>> verified we still get ALL the same system fonts as well as the new user fonts ? >>>> >>>> Have you verified what this does on older OS versions ? >>> On previous Windows version user fonts key not exists and fonts loading only from the system-wide key. >>> >>> >>>> -phil. >>>> >>>> On 2/15/19 6:23 AM, Mikhail Filippov wrote: >>>>> Hi. Please review the fix. >>>>> >>>>> patch: attached to message. >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8218914 >>>>> webrev: http://cr.openjdk.java.net/~dbatrak/8218914/webrev.01/ >>>>> >>>>> Description: >>>>> Starting from Windows 10 Preview Build 17704 fonts are installed into the user's home folder by default, and are listed in user's registry section. This is Microsoft blog post about it: "https://blogs.windows.com/windowsexperience/2018/06/27/announcing-windows-10-insider-preview-build-17704/ " I this patch I extract function for registry access and call it for two keys: HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. In original code fonts loading only from HKEY_LOCAL_MACHINE. >>>>> >>>>> >>>>> >>>>> -- >>>>> Mikhail Filippov >>>>> Software Developer >>>>> JetBrains >>>>> http://jetbrains.com >>>>> ?The Drive To Develop" >>>>> >>>> >>> >>> -- >>> Mikhail Filippov >>> Software Developer >>> JetBrains >>> http://jetbrains.com >>> ?The Drive To Develop" >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Mar 13 10:09:13 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 13 Mar 2019 11:09:13 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic Xinerama and Xrender functionality Message-ID: Hi, can I please have a review for the following change which fixes Xinerama and Xrender support on AIX: http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/ https://bugs.openjdk.java.net/browse/JDK-8220528 The change basically fixes the way how the corresponding libraries (libXext and libXrender) get loaded on AIX and does some cleanups with regards to the various platform macros. I've also added some debug tracing to the Xrender initialization code similar to the Xinerama initialization. Thank you and best regards, Volker From christoph.langer at sap.com Wed Mar 13 13:11:45 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 13 Mar 2019 13:11:45 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic Xinerama and Xrender functionality In-Reply-To: References: Message-ID: Hi Volker, thanks for doing this fix. It looks good to me. I'd personally prefer if the #if switches would be in the form of #if defined(__solaris__) #elif defined(_AIX) #endif e.g. lines 441, 659 and 660. But other than that, I have no points. Best regards Christoph > -----Original Message----- > From: 2d-dev <2d-dev-bounces at openjdk.java.net> On Behalf Of Volker > Simonis > Sent: Mittwoch, 13. M?rz 2019 11:09 > To: 2d-dev <2d-dev at openjdk.java.net> > Subject: [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic Xinerama and > Xrender functionality > > Hi, > > can I please have a review for the following change which fixes > Xinerama and Xrender support on AIX: > > http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/ > https://bugs.openjdk.java.net/browse/JDK-8220528 > > The change basically fixes the way how the corresponding libraries > (libXext and libXrender) get loaded on AIX and does some cleanups with > regards to the various platform macros. I've also added some debug > tracing to the Xrender initialization code similar to the Xinerama > initialization. > > Thank you and best regards, > Volker From philip.race at oracle.com Thu Mar 14 08:00:12 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 14 Mar 2019 13:30:12 +0530 Subject: [OpenJDK 2D-Dev] CFV: New 2d Group Member : Jayathirth DV In-Reply-To: <5C8A09C9.8020401@oracle.com> References: <5C8A09C9.8020401@oracle.com> Message-ID: <5C8A0A0C.2010808@oracle.com> Vote: yes -phil. From philip.race at oracle.com Thu Mar 14 07:59:05 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 14 Mar 2019 13:29:05 +0530 Subject: [OpenJDK 2D-Dev] CFV: New 2d Group Member : Jayathirth DV Message-ID: <5C8A09C9.8020401@oracle.com> I hereby nominate Jaythirth D V (jdv) to Membership in the 2d Group. Jay has worked in the client team at Oracle since 2015 and in that time has contributed almost 50 2D and Image I/O fixes [1] and has been active on the 2d-dev [2] mailing list over that time. He is also a JDK committer and reviewer [3] Votes are due by 9am PDT Thursday 28th March 2019 //Only current Members of the 2d Group [4] are eligible to vote on this nomination. || Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. -Phil. [1] http://hg.openjdk.java.net/jdk/client/search/?rev=jdv&revcount=100 [2] http://mail.openjdk.java.net/pipermail/2d-dev/ [3] http://openjdk.java.net/census#jdv [4] http://openjdk.java.net/census#2d [5] http://openjdk.java.net/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Mar 14 22:48:34 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 14 Mar 2019 15:48:34 -0700 Subject: [OpenJDK 2D-Dev] CFV: New 2d Group Member : Jayathirth DV In-Reply-To: <5C8A09C9.8020401@oracle.com> References: <5C8A09C9.8020401@oracle.com> Message-ID: <19bfc672-e13b-b22d-da90-4239a48153ce@oracle.com> Vote: yes From Sergey.Bylokhov at oracle.com Sun Mar 17 01:26:09 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 16 Mar 2019 18:26:09 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] 8218914: Support fonts installed per-user on Windows 10 In-Reply-To: <00184337-A68E-490F-A417-219847DA4565@jetbrains.com> References: <0C833624-5874-4B2F-A134-EBE98902EEE0@jetbrains.com> <5d7cee9a-fa57-4069-0c30-0de6f9992307@oracle.com> <4e238824-5bd0-1734-9a64-20e8c2d206a7@oracle.com> <1DE8890B-A08D-4CE2-A8F3-B9F013E56A36@jetbrains.com> <00184337-A68E-490F-A417-219847DA4565@jetbrains.com> Message-ID: <35ba1826-a4f1-7cc3-23ae-fc2c6826e27a@oracle.com> Looks fine. Thank you for contribution! On 12/03/2019 23:38, Mikhail Filippov wrote: > I looking for the second reviewer and sponsor for my font patch: http://cr.openjdk.java.net/~dbatrak/8218914/webrev.03/ > -- > Mikhail Filippov > Software Developer > JetBrains > http://jetbrains.com > ?The Drive To Develop" > > >> On 4 Mar 2019, at 21:45, Mikhail Filippov > wrote: >> >> Webrev with line-length fix: http://cr.openjdk.java.net/~dbatrak/8218914/webrev.03/ >> -- >> Mikhail Filippov >> Software Developer >> JetBrains >> http://jetbrains.com >> ?The Drive To Develop" >> >>> On 28 Feb 2019, at 00:35, Phil Race > wrote: >>> >>> I have made sure this builds OK and that it passes at least basic tests. >>> Line 514 is MUCH more than 80 chars. Please break it. >>> >>> Once you get a 2nd review, your sponsor can push it to jdk/client. >>> >>> -phil >>> >>> On 2/19/19 5:57 AM, Mikhail Filippov wrote: >>>> New webrev with fixes: http://cr.openjdk.java.net/~dbatrak/8218914/webrev.02/ >>>> >>>> >>>>> On 15 Feb 2019, at 19:31, Phil Race > wrote: >>>>> >>>>> > 8218914: Handle the case when fonts are installed into user registry key. This is the default behaviour since Windows 10 1809. >>>>> >>>>> When you get to the point of preparing a changeset, this line should have the bug synopsis. >>>>> The text you have here is better placed on the "Summary:" line. >>>>> You seem to have lines > 80 chars. Please fix. >>>> I attached new webrev without commit message. >>>> >>>>> What does Windows do if a user installs a different version of a font already installed on the system ? >>>>> - Refuse to install it ? >>>>> - Use the system one ? >>>>> - Use the user one ? >>>>> >>>>> If it refuses to install it, we can ignore that problem. If it prefers one, we should make sure >>>>> we do the same. >>>> I check this case. If you have installed system-wide and user fonts system-wide font preferred. I changed call order in the patch to match this behaviour. >>>> >>>> >>>>> I think the comment >>>>> >>>>> /* Starting from Windows 10 Preview Build 17704 fonts are installed into user's home folder by default, >>>>> >>>>> can be misconstrued. It could be read as ALL fonts are installed into a user folder and >>>>> there is no more system location. I think you actually mean >>>>> >>>>> /* Starting from Windows 10 Preview Build 17704, when a user installs non-system fonts, * then by default they are installed in a new per-user location as specified in a * per user registry entry. */ >>>> Comment fixed. >>>> >>>>> Have you tested this on a machine with at least several user fonts installed and >>>>> verified we still get ALL the same system fonts as well as the new user fonts ? >>>>> >>>>> Have you verified what this does on older OS versions ? >>>> On previous Windows version user fonts key not exists and fonts loading only from the system-wide key. >>>> >>>> >>>>> -phil. >>>>> >>>>> On 2/15/19 6:23 AM, Mikhail Filippov wrote: >>>>>> Hi. Please review the fix. >>>>>> >>>>>> patch: attached to message. >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8218914 >>>>>> webrev: http://cr.openjdk.java.net/~dbatrak/8218914/webrev.01/ >>>>>> >>>>>> Description: >>>>>> Starting from Windows 10 Preview Build 17704 fonts are installed into the user's home folder by default, and are listed in user's registry section. This is Microsoft blog post about it: "https://blogs.windows.com/windowsexperience/2018/06/27/announcing-windows-10-insider-preview-build-17704/" I this patch I extract function for registry access and call it for two keys: HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. In original code fonts loading only from HKEY_LOCAL_MACHINE. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mikhail Filippov >>>>>> Software Developer >>>>>> JetBrains >>>>>> http://jetbrains.com >>>>>> ?The Drive To Develop" >>>>>> >>>>> >>>> -- >>>> Mikhail Filippov >>>> Software Developer >>>> JetBrains >>>> http://jetbrains.com >>>> ?The Drive To Develop" >>> >> > -- Best regards, Sergey. From volker.simonis at gmail.com Mon Mar 18 14:15:51 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 18 Mar 2019 15:15:51 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic Xinerama and Xrender functionality In-Reply-To: References: Message-ID: Ping... Can I please also get a review from the awt/2d group? Thanks, Volker On Wed, Mar 13, 2019 at 11:09 AM Volker Simonis wrote: > > Hi, > > can I please have a review for the following change which fixes > Xinerama and Xrender support on AIX: > > http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/ > https://bugs.openjdk.java.net/browse/JDK-8220528 > > The change basically fixes the way how the corresponding libraries > (libXext and libXrender) get loaded on AIX and does some cleanups with > regards to the various platform macros. I've also added some debug > tracing to the Xrender initialization code similar to the Xinerama > initialization. > > Thank you and best regards, > Volker From thomas.stuefe at gmail.com Mon Mar 18 19:59:15 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 18 Mar 2019 20:59:15 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic Xinerama and Xrender functionality In-Reply-To: References: Message-ID: Sorry, not awt/2d group, but to me it looks fine too. Only nit: the error printout at 495 I would put right after the associated dlsym at 456. You want to make sure dlerror() is not stale at the point where you call it, since it would return NULL. Cheers, Thomas On Mon, Mar 18, 2019 at 3:17 PM Volker Simonis wrote: > Ping... > > Can I please also get a review from the awt/2d group? > > Thanks, > Volker > > On Wed, Mar 13, 2019 at 11:09 AM Volker Simonis > wrote: > > > > Hi, > > > > can I please have a review for the following change which fixes > > Xinerama and Xrender support on AIX: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/ > > https://bugs.openjdk.java.net/browse/JDK-8220528 > > > > The change basically fixes the way how the corresponding libraries > > (libXext and libXrender) get loaded on AIX and does some cleanups with > > regards to the various platform macros. I've also added some debug > > tracing to the Xrender initialization code similar to the Xinerama > > initialization. > > > > Thank you and best regards, > > Volker > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Mar 22 04:20:19 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 21 Mar 2019 21:20:19 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java Message-ID: <5C946283.1020403@oracle.com> Problem list a test that fails on Mac + Solaris on just those platforms : Bug: https://bugs.openjdk.java.net/browse/JDK-8221304 diff : diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -219,6 +219,7 @@ java/awt/font/TextLayout/TextLayoutBounds.java 8169188 generic-all java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all java/awt/FontMetrics/FontCrash.java 8198336 windows-all +java/awt/FontMetrics/MaxAdvanceIsMax.java 8221304 solaris-all,macosx-all java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 generic-all java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java 8196025 windows-all java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java 8196025 windows-all https://bugs.openjdk.java.net/browse/JDK-8221305 has been filed to follow up on this. -phil. From Sergey.Bylokhov at oracle.com Fri Mar 22 04:27:53 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 21 Mar 2019 21:27:53 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java In-Reply-To: <5C946283.1020403@oracle.com> References: <5C946283.1020403@oracle.com> Message-ID: Hi, Phil. The fix looks fine, but I guess the ProblemList should use 8221305 instead of 8221304. On 21/03/2019 21:20, Philip Race wrote: > Problem list a test that fails on Mac + Solaris on just those platforms : > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221304 > diff : > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -219,6 +219,7 @@ > ?java/awt/font/TextLayout/TextLayoutBounds.java 8169188 generic-all > ?java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all > ?java/awt/FontMetrics/FontCrash.java 8198336 windows-all > +java/awt/FontMetrics/MaxAdvanceIsMax.java 8221304 solaris-all,macosx-all > ?java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 generic-all > ?java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java 8196025 windows-all > ?java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java 8196025 windows-all > > https://bugs.openjdk.java.net/browse/JDK-8221305 has been filed to > follow up on this. > > -phil. -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri Mar 22 04:27:43 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 22 Mar 2019 09:57:43 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java In-Reply-To: <5C946283.1020403@oracle.com> References: <5C946283.1020403@oracle.com> Message-ID: <5b63744b-1545-c03f-c8bd-5f4fc038502e@oracle.com> Shouldn't it be 8221305 in problemlist.txt as that is the actual bug which will solve the issue? Regards Prasanta On 22-Mar-19 9:50 AM, Philip Race wrote: > Problem list a test that fails on Mac + Solaris on just those platforms : > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221304 > diff : > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -219,6 +219,7 @@ > ?java/awt/font/TextLayout/TextLayoutBounds.java 8169188 generic-all > ?java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all > ?java/awt/FontMetrics/FontCrash.java 8198336 windows-all > +java/awt/FontMetrics/MaxAdvanceIsMax.java 8221304 solaris-all,macosx-all > ?java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 > generic-all > ?java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java 8196025 > windows-all > ?java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java > 8196025 windows-all > > https://bugs.openjdk.java.net/browse/JDK-8221305 has been filed to > follow up on this. > > -phil. From philip.race at oracle.com Fri Mar 22 04:30:02 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 21 Mar 2019 21:30:02 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java In-Reply-To: References: <5C946283.1020403@oracle.com> Message-ID: <5C9464CA.7040300@oracle.com> Ah yes .. diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -219,6 +219,7 @@ java/awt/font/TextLayout/TextLayoutBounds.java 8169188 generic-all java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all java/awt/FontMetrics/FontCrash.java 8198336 windows-all +java/awt/FontMetrics/MaxAdvanceIsMax.java 8221305 solaris-all,macosx-all java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 generic-all java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java 8196025 windows-all java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java 8196025 windows-all -phil. On 3/21/19, 9:27 PM, Sergey Bylokhov wrote: > Hi, Phil. > > The fix looks fine, but I guess the ProblemList should use 8221305 > instead of 8221304. > > On 21/03/2019 21:20, Philip Race wrote: >> Problem list a test that fails on Mac + Solaris on just those >> platforms : >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221304 >> diff : >> >> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt >> +++ b/test/jdk/ProblemList.txt >> @@ -219,6 +219,7 @@ >> java/awt/font/TextLayout/TextLayoutBounds.java 8169188 generic-all >> java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all >> java/awt/FontMetrics/FontCrash.java 8198336 windows-all >> +java/awt/FontMetrics/MaxAdvanceIsMax.java 8221304 >> solaris-all,macosx-all >> java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 >> generic-all >> java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java >> 8196025 windows-all >> java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java >> 8196025 windows-all >> >> https://bugs.openjdk.java.net/browse/JDK-8221305 has been filed to >> follow up on this. >> >> -phil. > > From Sergey.Bylokhov at oracle.com Fri Mar 22 04:31:19 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 21 Mar 2019 21:31:19 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java In-Reply-To: <5C9464CA.7040300@oracle.com> References: <5C946283.1020403@oracle.com> <5C9464CA.7040300@oracle.com> Message-ID: <23c8a407-f2ee-9f75-d8e8-3582f5a79531@oracle.com> +1 On 21/03/2019 21:30, Philip Race wrote: > Ah yes .. > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -219,6 +219,7 @@ > ?java/awt/font/TextLayout/TextLayoutBounds.java 8169188 generic-all > ?java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all > ?java/awt/FontMetrics/FontCrash.java 8198336 windows-all > +java/awt/FontMetrics/MaxAdvanceIsMax.java 8221305 solaris-all,macosx-all > ?java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 generic-all > ?java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java 8196025 windows-all > ?java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java 8196025 windows-all > > -phil. > > > On 3/21/19, 9:27 PM, Sergey Bylokhov wrote: >> Hi, Phil. >> >> The fix looks fine, but I guess the ProblemList should use 8221305 instead of 8221304. >> >> On 21/03/2019 21:20, Philip Race wrote: >>> Problem list a test that fails on Mac + Solaris on just those platforms : >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221304 >>> diff : >>> >>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>> --- a/test/jdk/ProblemList.txt >>> +++ b/test/jdk/ProblemList.txt >>> @@ -219,6 +219,7 @@ >>> ? java/awt/font/TextLayout/TextLayoutBounds.java 8169188 generic-all >>> ? java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all >>> ? java/awt/FontMetrics/FontCrash.java 8198336 windows-all >>> +java/awt/FontMetrics/MaxAdvanceIsMax.java 8221304 solaris-all,macosx-all >>> ? java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 generic-all >>> ? java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java 8196025 windows-all >>> ? java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java 8196025 windows-all >>> >>> https://bugs.openjdk.java.net/browse/JDK-8221305 has been filed to >>> follow up on this. >>> >>> -phil. >> >> -- Best regards, Sergey. From philip.race at oracle.com Fri Mar 22 04:41:12 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 21 Mar 2019 21:41:12 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java In-Reply-To: <5b63744b-1545-c03f-c8bd-5f4fc038502e@oracle.com> References: <5C946283.1020403@oracle.com> <5b63744b-1545-c03f-c8bd-5f4fc038502e@oracle.com> Message-ID: <5C946768.2010700@oracle.com> Yes. Sergey pointed this out already. I pushed the updated fix after his review. Sorry I did not notice your email earlier. -phil. On 3/21/19, 9:27 PM, Prasanta Sadhukhan wrote: > Shouldn't it be 8221305 in problemlist.txt as that is the actual bug > which will solve the issue? > > Regards > Prasanta > On 22-Mar-19 9:50 AM, Philip Race wrote: >> Problem list a test that fails on Mac + Solaris on just those >> platforms : >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221304 >> diff : >> >> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt >> +++ b/test/jdk/ProblemList.txt >> @@ -219,6 +219,7 @@ >> java/awt/font/TextLayout/TextLayoutBounds.java 8169188 generic-all >> java/awt/font/StyledMetrics/BoldSpace.java 8198422 linux-all >> java/awt/FontMetrics/FontCrash.java 8198336 windows-all >> +java/awt/FontMetrics/MaxAdvanceIsMax.java 8221304 >> solaris-all,macosx-all >> java/awt/image/DrawImage/IncorrectAlphaSurface2SW.java 8056077 >> generic-all >> java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java 8196025 >> windows-all >> java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java >> 8196025 windows-all >> >> https://bugs.openjdk.java.net/browse/JDK-8221305 has been filed to >> follow up on this. >> >> -phil. > From philip.race at oracle.com Sat Mar 23 19:13:42 2019 From: philip.race at oracle.com (Philip Race) Date: Sat, 23 Mar 2019 12:13:42 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8218077: Move src/java.desktop/share/legal/mesa3d.md to unix location Message-ID: <5C968566.7000207@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8218077 Webrev : http://cr.openjdk.java.net/~prr/8218077/ This fix does not change the file's contents, it just moves it to the unix specific location to match the usage. -phil. From Sergey.Bylokhov at oracle.com Sun Mar 24 10:17:36 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 24 Mar 2019 03:17:36 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8218077: Move src/java.desktop/share/legal/mesa3d.md to unix location In-Reply-To: <5C968566.7000207@oracle.com> References: <5C968566.7000207@oracle.com> Message-ID: Hi, Phil. Not sure that we can move it from the shared folder, because we use this license in the java.desktop/share/native/common/java2d/opengl/J2D_GL/gl.h On 23/03/2019 12:13, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8218077 > Webrev : http://cr.openjdk.java.net/~prr/8218077/ > > This fix does not change the file's contents, it just moves > it to the unix specific location to match the usage. > > -phil. > > -- Best regards, Sergey. From philip.race at oracle.com Sun Mar 24 16:53:16 2019 From: philip.race at oracle.com (Philip Race) Date: Sun, 24 Mar 2019 09:53:16 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8218077: Move src/java.desktop/share/legal/mesa3d.md to unix location In-Reply-To: References: <5C968566.7000207@oracle.com> Message-ID: <5C97B5FC.5000609@oracle.com> You are right. I didn't see that before. I'll close this one out. -phil On 3/24/19, 3:17 AM, Sergey Bylokhov wrote: > Hi, Phil. > > Not sure that we can move it from the shared folder, because we use > this license in the > java.desktop/share/native/common/java2d/opengl/J2D_GL/gl.h > > On 23/03/2019 12:13, Philip Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218077 >> Webrev : http://cr.openjdk.java.net/~prr/8218077/ >> >> This fix does not change the file's contents, it just moves >> it to the unix specific location to match the usage. >> >> -phil. >> >> > > From alexey.ivanov at oracle.com Sun Mar 24 19:18:43 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Sun, 24 Mar 2019 19:18:43 +0000 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8217707: JNICALL declaration breaks Splash screen functions Message-ID: <5fcbdb54-3b7d-48f8-7a9e-11d05021a0a2@oracle.com> Hi, Please review the fix for jdk 13. bug: https://bugs.openjdk.java.net/browse/JDK-8217707 webrev: http://cr.openjdk.java.net/~aivanov/8217707/webrev.0/ Description: Splash screen functionality is broken in 32 bit Windows. It's because the functions in splashscreen.dll are exported with decorated names now, yet they're looked up by the undecorated names. The easiest way to reproduce the problem is to run SwingSet2: java -jar SwingSet2.jar Fix: The fix removes JNICALL (__stdcall) declarations from splash screen functions. Thus the functions are exported undecorated. I've run SplashScreen jtreg tests, all tests pass. This is a follow-up fix to https://bugs.openjdk.java.net/browse/JDK-8201226 https://bugs.openjdk.java.net/browse/JDK-8202476 which re-enabled 32 bit Windows post removal of mapfiles / compiler options. Thank you in advance. Regards, Alexey From TOSHIONA at jp.ibm.com Mon Mar 25 07:29:54 2019 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Mon, 25 Mar 2019 07:29:54 +0000 Subject: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont In-Reply-To: References: , <5C84D34E.2070601@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Mon Mar 25 18:42:02 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Mar 2019 19:42:02 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic Xinerama and Xrender functionality In-Reply-To: References: Message-ID: Hi Thomas, Christoph, thanks for looking into my fix. I hope I've addressed all your concerns with my new webrev: http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528.v4 By the way, I've tested the new implementation by simulating a multi-screen environment on my Linux box with Xephyr: $ Xephyr +xinerama -screen 1024x768 -screen 1024x768+1024+0 -ac -listen tcp :1 And started a Swing application from AIX where I've redirected the DISPLAY to myhost:1: $ DISPLAY=myhost:1 ./images/jdk/bin/java -showversion -Dsun.awt.nativedebug=true -Dawtdebug.trace=true -Dawtdebug.on=true -Dawtdebug.ctrace=true -cp ~/Java HelloSwing The various debug properties will lead to the following output: openjdk version "13-internal" 2019-09-17 OpenJDK Runtime Environment (slowdebug build 13-internal+0-adhoc.xxx.jdk-jdk) OpenJDK 64-Bit Server VM (slowdebug build 13-internal+0-adhoc.xxx.jdk-jdk, mixed mode) Xinerama extension is available calling XineramaQueryScreens func Enabling Xinerama support num screens = 2 allocating 2 screens The Swing frame will appear on one of the Xinerama screens and can be move with the mouse between the two available screens. If I hear no further objections, I plan to push this by the end of the week. Thank you and best regards, Volker On Mon, Mar 18, 2019 at 8:59 PM Thomas St?fe wrote: > > Sorry, not awt/2d group, but to me it looks fine too. Only nit: the error printout at 495 I would put right after the associated dlsym at 456. You want to make sure dlerror() is not stale at the point where you call it, since it would return NULL. > > Cheers, Thomas > > > > On Mon, Mar 18, 2019 at 3:17 PM Volker Simonis wrote: >> >> Ping... >> >> Can I please also get a review from the awt/2d group? >> >> Thanks, >> Volker >> >> On Wed, Mar 13, 2019 at 11:09 AM Volker Simonis >> wrote: >> > >> > Hi, >> > >> > can I please have a review for the following change which fixes >> > Xinerama and Xrender support on AIX: >> > >> > http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/ >> > https://bugs.openjdk.java.net/browse/JDK-8220528 >> > >> > The change basically fixes the way how the corresponding libraries >> > (libXext and libXrender) get loaded on AIX and does some cleanups with >> > regards to the various platform macros. I've also added some debug >> > tracing to the Xrender initialization code similar to the Xinerama >> > initialization. >> > >> > Thank you and best regards, >> > Volker From thomas.stuefe at gmail.com Mon Mar 25 18:50:04 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Mar 2019 19:50:04 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic Xinerama and Xrender functionality In-Reply-To: References: Message-ID: On Mon 25. Mar 2019 at 19:42, Volker Simonis wrote: > Hi Thomas, Christoph, > > thanks for looking into my fix. I hope I've addressed all your > concerns with my new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528.v4 > > By the way, I've tested the new implementation by simulating a > multi-screen environment on my Linux box with Xephyr: > > $ Xephyr +xinerama -screen 1024x768 -screen 1024x768+1024+0 -ac -listen > tcp :1 > > And started a Swing application from AIX where I've redirected the > DISPLAY to myhost:1: > > $ DISPLAY=myhost:1 ./images/jdk/bin/java -showversion > -Dsun.awt.nativedebug=true -Dawtdebug.trace=true -Dawtdebug.on=true > -Dawtdebug.ctrace=true -cp ~/Java HelloSwing > > The various debug properties will lead to the following output: > > openjdk version "13-internal" 2019-09-17 > OpenJDK Runtime Environment (slowdebug build > 13-internal+0-adhoc.xxx.jdk-jdk) > OpenJDK 64-Bit Server VM (slowdebug build > 13-internal+0-adhoc.xxx.jdk-jdk, mixed mode) > Xinerama extension is available > calling XineramaQueryScreens func > Enabling Xinerama support > num screens = 2 > allocating 2 screens > > The Swing frame will appear on one of the Xinerama screens and can be > move with the mouse between the two available screens. > > If I hear no further objections, I plan to push this by the end of the > week. > All good now. Thank you. Strange that this error was not detected before, what with the masses of people running swing apps on AIX. Cheers, thomas > Thank you and best regards, > Volker > > > > On Mon, Mar 18, 2019 at 8:59 PM Thomas St?fe > wrote: > > > > Sorry, not awt/2d group, but to me it looks fine too. Only nit: the > error printout at 495 I would put right after the associated dlsym at 456. > You want to make sure dlerror() is not stale at the point where you call > it, since it would return NULL. > > > > Cheers, Thomas > > > > > > > > On Mon, Mar 18, 2019 at 3:17 PM Volker Simonis > wrote: > >> > >> Ping... > >> > >> Can I please also get a review from the awt/2d group? > >> > >> Thanks, > >> Volker > >> > >> On Wed, Mar 13, 2019 at 11:09 AM Volker Simonis > >> wrote: > >> > > >> > Hi, > >> > > >> > can I please have a review for the following change which fixes > >> > Xinerama and Xrender support on AIX: > >> > > >> > http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/ > >> > https://bugs.openjdk.java.net/browse/JDK-8220528 > >> > > >> > The change basically fixes the way how the corresponding libraries > >> > (libXext and libXrender) get loaded on AIX and does some cleanups with > >> > regards to the various platform macros. I've also added some debug > >> > tracing to the Xrender initialization code similar to the Xinerama > >> > initialization. > >> > > >> > Thank you and best regards, > >> > Volker > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Mar 25 20:19:11 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 25 Mar 2019 13:19:11 -0700 Subject: [OpenJDK 2D-Dev] [PATCH] 8220231: Cache HarfBuzz face object for same font's text layout calls In-Reply-To: References: <5C81B594.6060209@oracle.com> Message-ID: <5C9937BF.9010500@oracle.com> Sorry for the delay. I've now finished verifying this and it is a +1 from me. -phil. On 3/12/19, 1:32 AM, Dmitry Batrak wrote: > > This looks good to me, if I understand correctly that we now create > > the face on first use and cache it fin Java or as long as the Font2D is > > alive. > > And the JNIEnv is always found on > That's correct. The assumption is that HarfBuzz doesn't create its own > threads, > so HarfBuzz-related native code will always be invoked from a Java thread > (as part of 'shape' call), and so JNIEnv will be available in that > context. > > I've updated the webrev by including a stress test for multi-threaded > behaviour > testing. Apart from the test, webrev also has some cosmetic differences > from the previous version (like a comment fix or parameter order > changing), > appeared during 'splitting' process. To simplify the review, I'm also > providing > the links to the 'split' version of the same webrev - three parts that > produce > the same result when combined. I've not tested the changes separately > (except basic compilation check). > > Complete change: > http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01/ > > Part 1 (caching hb_face_t): > http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-1/ > > Part 2 (tables caching removal): > http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-2/ > > Part 3 (scaler pointer passing removal): > http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-3/ > > > Best regards, > Dmitry Batrak > > On Fri, Mar 8, 2019 at 3:21 AM Philip Race > wrote: > > This looks good to me, if I understand correctly that we now create > the face on first use and cache it fin Java or as long as the > Font2D is > alive. > And the JNIEnv is always found on > > I think you are right that we don't need the caching of the tables > since > now the face will do it. The unfortunate thing is that the removal of > this code is > well over half the changes and as such it greatly muddied finding the > changes > that make the performance difference so my review was harder and less > certain > because of that. > It could have been separated into a follow-on change I think so > that it > would have > been easier to review the important change. > > The pScaler parameter looks like it is unused these days which is > why I > expect you removed it but also not directly relevant. > > I have run builds + some tests - but I'm not in a position to run > more tests > for a couple of weeks. > > A (mild) stress test re-using the same font from multiple threads > eachmaking > multiple calls into layout would be a good addition here. That should > help tell > us if there are any MT or re-entrancy problems. Can you provide > such a > test ? > It will be a good thing to have automatically run to catch any > problems > introduced later either on the Java side or by an update to harfbuzz. > > -phil. > > > > On 3/6/19, 5:45 PM, Dmitry Batrak wrote: > > Hello, > > > > I'd like to submit a patch for JDK-8220231. I'm not a Committer, so > > I'll need someone to sponsor this change. > > > > The proposed approach is used without known issues in OpenJDK-based > > JetBrains Runtime for almost three years now. I've mentioned it > > previously on this mailing list > > > (https://mail.openjdk.java.net/pipermail/2d-dev/2017-August/008497.html). > > The change has been refactored as compared to the version mentioned > > above (the logic has been moved to SunLayoutEngine), and > includes the > > removal of font tables caching (JDK-8186317). The latter, I > believe, > > becomes redundant with this fix. > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8220231 > > Webrev: http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/ > > > > > > > Best regards, > > Dmitry Batrak > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Mar 26 08:56:45 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Mar 2019 09:56:45 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic Xinerama and Xrender functionality In-Reply-To: References: Message-ID: On Mon, Mar 25, 2019 at 7:50 PM Thomas St?fe wrote: > > > > On Mon 25. Mar 2019 at 19:42, Volker Simonis wrote: >> >> Hi Thomas, Christoph, >> >> thanks for looking into my fix. I hope I've addressed all your >> concerns with my new webrev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528.v4 >> >> By the way, I've tested the new implementation by simulating a >> multi-screen environment on my Linux box with Xephyr: >> >> $ Xephyr +xinerama -screen 1024x768 -screen 1024x768+1024+0 -ac -listen tcp :1 >> >> And started a Swing application from AIX where I've redirected the >> DISPLAY to myhost:1: >> >> $ DISPLAY=myhost:1 ./images/jdk/bin/java -showversion >> -Dsun.awt.nativedebug=true -Dawtdebug.trace=true -Dawtdebug.on=true >> -Dawtdebug.ctrace=true -cp ~/Java HelloSwing >> >> The various debug properties will lead to the following output: >> >> openjdk version "13-internal" 2019-09-17 >> OpenJDK Runtime Environment (slowdebug build 13-internal+0-adhoc.xxx.jdk-jdk) >> OpenJDK 64-Bit Server VM (slowdebug build >> 13-internal+0-adhoc.xxx.jdk-jdk, mixed mode) >> Xinerama extension is available >> calling XineramaQueryScreens func >> Enabling Xinerama support >> num screens = 2 >> allocating 2 screens >> >> The Swing frame will appear on one of the Xinerama screens and can be >> move with the mouse between the two available screens. >> >> If I hear no further objections, I plan to push this by the end of the week. > > > All good now. Thank you. > Thanks. > Strange that this error was not detected before, what with the masses of people running swing apps on AIX. > It was not really an error. Basic Swing/AWT worked (we actually passed the TCK). What did not work was some advanced transparency/translucency support (due to failing Xrender) and multiscreen support (due to failing Xinerama). > Cheers, thomas > > >> >> Thank you and best regards, >> Volker >> >> >> >> On Mon, Mar 18, 2019 at 8:59 PM Thomas St?fe wrote: >> > >> > Sorry, not awt/2d group, but to me it looks fine too. Only nit: the error printout at 495 I would put right after the associated dlsym at 456. You want to make sure dlerror() is not stale at the point where you call it, since it would return NULL. >> > >> > Cheers, Thomas >> > >> > >> > >> > On Mon, Mar 18, 2019 at 3:17 PM Volker Simonis wrote: >> >> >> >> Ping... >> >> >> >> Can I please also get a review from the awt/2d group? >> >> >> >> Thanks, >> >> Volker >> >> >> >> On Wed, Mar 13, 2019 at 11:09 AM Volker Simonis >> >> wrote: >> >> > >> >> > Hi, >> >> > >> >> > can I please have a review for the following change which fixes >> >> > Xinerama and Xrender support on AIX: >> >> > >> >> > http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/ >> >> > https://bugs.openjdk.java.net/browse/JDK-8220528 >> >> > >> >> > The change basically fixes the way how the corresponding libraries >> >> > (libXext and libXrender) get loaded on AIX and does some cleanups with >> >> > regards to the various platform macros. I've also added some debug >> >> > tracing to the Xrender initialization code similar to the Xinerama >> >> > initialization. >> >> > >> >> > Thank you and best regards, >> >> > Volker From alexey.ivanov at oracle.com Tue Mar 26 17:01:06 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 26 Mar 2019 17:01:06 +0000 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221412: lookupPrintServices() does not always update the list of Windows remote printers Message-ID: Hi, Please review the fix for jdk 13: bug: https://bugs.openjdk.java.net/browse/JDK-8221412 webrev: http://cr.openjdk.java.net/~aivanov/8221412/webrev.0/ Description: The list of printers is not updated in the situation where there are no remote printers on the system and later the user adds a remote printer. Root cause: JDK-8153732 [1] added a new thread which polls remote printers on the system and updates the list if it detects a change. In this case it does not update the print services because of this condition: 449 if (prevRemotePrinters != null && prevRemotePrinters.length > 0) prevRemotePrinters is not null but its length is zero because no remote printers were initially present on the system. Fix: I removed this if. We have to update the list printers if doCompare() returns true. Either prevRemotePrinters or currentRemotePrinters, or both can be null; doCompare() handles this situation gracefully after JDK-8212202 [2]. The listener called getRemotePrintersNames() twice: in constructor and in run() before entering the first sleep. Now it's done only once. I consolidated the implementation of getAllPrinterNames() and getRemotePrintersNames(). They were very similar. The old implementation of getRemotePrintersNames() got the list of both local and remote printers and then filtered out local ones. The new implementation gets the list of remote printers only. So the difference between the two is limited to the flags passed to EnumPrinters. If there are no remote printers, the new version getRemotePrintersNames() returns null instead of empty array. As mentioned earlier, doCompare() handles this situation. I'll add the bugid (8221412) to the regression test when fixing JDK-8221263 [3]. I'm currently working on it. Thank you in advance. Regards, Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8153732 [2] https://bugs.openjdk.java.net/browse/JDK-8212202 [3] https://bugs.openjdk.java.net/browse/JDK-8221263 From alexey.ivanov at oracle.com Tue Mar 26 20:22:34 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 26 Mar 2019 20:22:34 +0000 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221412: lookupPrintServices() does not always update the list of Windows remote printers In-Reply-To: References: Message-ID: Please see the updated webrev: http://cr.openjdk.java.net/~aivanov/8221412/webrev.1/ The difference between .0 and .1 is in some minor white-space adjustments, like parameter alignment. On 26/03/2019 17:01, Alexey Ivanov wrote: > Hi, > > Please review the fix for jdk 13: > > bug: https://bugs.openjdk.java.net/browse/JDK-8221412 > webrev: http://cr.openjdk.java.net/~aivanov/8221412/webrev.0/ > > Description: > The list of printers is not updated in the situation where there are > no remote printers on the system and later the user adds a remote > printer. > > Root cause: > JDK-8153732 [1] added a new thread which polls remote printers on the > system and updates the list if it detects a change. In this case it > does not update the print services because of this condition: > 449 if (prevRemotePrinters != null && prevRemotePrinters.length > 0) > prevRemotePrinters is not null but its length is zero because no > remote printers were initially present on the system. > > Fix: > I removed this if. We have to update the list printers if doCompare() > returns true. Either prevRemotePrinters or currentRemotePrinters, or > both can be null; doCompare() handles this situation gracefully after > JDK-8212202 [2]. > > The listener called getRemotePrintersNames() twice: in constructor and > in run() before entering the first sleep. Now it's done only once. > > I consolidated the implementation of getAllPrinterNames() and > getRemotePrintersNames(). They were very similar. The old > implementation of getRemotePrintersNames() got the list of both local > and remote printers and then filtered out local ones. The new > implementation gets the list of remote printers only. So the > difference between the two is limited to the flags passed to > EnumPrinters. > > If there are no remote printers, the new version > getRemotePrintersNames() returns null instead of empty array. As > mentioned earlier, doCompare() handles this situation. > > I'll add the bugid (8221412) to the regression test when fixing > JDK-8221263 [3]. I'm currently working on it. > > > Thank you in advance. > > Regards, > Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8153732 > [2] https://bugs.openjdk.java.net/browse/JDK-8212202 > [3] https://bugs.openjdk.java.net/browse/JDK-8221263 -- Regards, Alexey From Sergey.Bylokhov at oracle.com Tue Mar 26 21:04:34 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Mar 2019 14:04:34 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8220528: [AIX] Fix basic Xinerama and Xrender functionality In-Reply-To: References: Message-ID: v4 looks fine. On 25/03/2019 11:42, Volker Simonis wrote: > Hi Thomas, Christoph, > > thanks for looking into my fix. I hope I've addressed all your > concerns with my new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528.v4 > > By the way, I've tested the new implementation by simulating a > multi-screen environment on my Linux box with Xephyr: > > $ Xephyr +xinerama -screen 1024x768 -screen 1024x768+1024+0 -ac -listen tcp :1 > > And started a Swing application from AIX where I've redirected the > DISPLAY to myhost:1: > > $ DISPLAY=myhost:1 ./images/jdk/bin/java -showversion > -Dsun.awt.nativedebug=true -Dawtdebug.trace=true -Dawtdebug.on=true > -Dawtdebug.ctrace=true -cp ~/Java HelloSwing > > The various debug properties will lead to the following output: > > openjdk version "13-internal" 2019-09-17 > OpenJDK Runtime Environment (slowdebug build 13-internal+0-adhoc.xxx.jdk-jdk) > OpenJDK 64-Bit Server VM (slowdebug build > 13-internal+0-adhoc.xxx.jdk-jdk, mixed mode) > Xinerama extension is available > calling XineramaQueryScreens func > Enabling Xinerama support > num screens = 2 > allocating 2 screens > > The Swing frame will appear on one of the Xinerama screens and can be > move with the mouse between the two available screens. > > If I hear no further objections, I plan to push this by the end of the week. > > Thank you and best regards, > Volker > > > > On Mon, Mar 18, 2019 at 8:59 PM Thomas St?fe wrote: >> >> Sorry, not awt/2d group, but to me it looks fine too. Only nit: the error printout at 495 I would put right after the associated dlsym at 456. You want to make sure dlerror() is not stale at the point where you call it, since it would return NULL. >> >> Cheers, Thomas >> >> >> >> On Mon, Mar 18, 2019 at 3:17 PM Volker Simonis wrote: >>> >>> Ping... >>> >>> Can I please also get a review from the awt/2d group? >>> >>> Thanks, >>> Volker >>> >>> On Wed, Mar 13, 2019 at 11:09 AM Volker Simonis >>> wrote: >>>> >>>> Hi, >>>> >>>> can I please have a review for the following change which fixes >>>> Xinerama and Xrender support on AIX: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2019/8220528/ >>>> https://bugs.openjdk.java.net/browse/JDK-8220528 >>>> >>>> The change basically fixes the way how the corresponding libraries >>>> (libXext and libXrender) get loaded on AIX and does some cleanups with >>>> regards to the various platform macros. I've also added some debug >>>> tracing to the Xrender initialization code similar to the Xinerama >>>> initialization. >>>> >>>> Thank you and best regards, >>>> Volker -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Mar 26 21:03:02 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Mar 2019 14:03:02 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221412: lookupPrintServices() does not always update the list of Windows remote printers In-Reply-To: References: Message-ID: <2e0eafdf-c570-ffa4-e857-c11bb881aba4@oracle.com> Looks fine. On 26/03/2019 13:22, Alexey Ivanov wrote: > Please see the updated webrev: > http://cr.openjdk.java.net/~aivanov/8221412/webrev.1/ > > The difference between .0 and .1 is in some minor white-space adjustments, like parameter alignment. > > On 26/03/2019 17:01, Alexey Ivanov wrote: >> Hi, >> >> Please review the fix for jdk 13: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8221412 >> webrev: http://cr.openjdk.java.net/~aivanov/8221412/webrev.0/ >> >> Description: >> The list of printers is not updated in the situation where there are no remote printers on the system and later the user adds a remote printer. >> >> Root cause: >> JDK-8153732 [1] added a new thread which polls remote printers on the system and updates the list if it detects a change. In this case it does not update the print services because of this condition: >> 449 if (prevRemotePrinters != null && prevRemotePrinters.length > 0) >> prevRemotePrinters is not null but its length is zero because no remote printers were initially present on the system. >> >> Fix: >> I removed this if. We have to update the list printers if doCompare() returns true. Either prevRemotePrinters or currentRemotePrinters, or both can be null; doCompare() handles this situation gracefully after JDK-8212202 [2]. >> >> The listener called getRemotePrintersNames() twice: in constructor and in run() before entering the first sleep. Now it's done only once. >> >> I consolidated the implementation of getAllPrinterNames() and getRemotePrintersNames(). They were very similar. The old implementation of getRemotePrintersNames() got the list of both local and remote printers and then filtered out local ones. The new implementation gets the list of remote printers only. So the difference between the two is limited to the flags passed to EnumPrinters. >> >> If there are no remote printers, the new version getRemotePrintersNames() returns null instead of empty array. As mentioned earlier, doCompare() handles this situation. >> >> I'll add the bugid (8221412) to the regression test when fixing JDK-8221263 [3]. I'm currently working on it. >> >> >> Thank you in advance. >> >> Regards, >> Alexey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8153732 >> [2] https://bugs.openjdk.java.net/browse/JDK-8212202 >> [3] https://bugs.openjdk.java.net/browse/JDK-8221263 -- Best regards, Sergey. From philip.race at oracle.com Wed Mar 27 00:29:36 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 26 Mar 2019 17:29:36 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221412: lookupPrintServices() does not always update the list of Windows remote printers In-Reply-To: References: Message-ID: <5C9AC3F0.9030509@oracle.com> > The old implementation of getRemotePrintersNames() got the list of both local and remote printers and then filtered out local ones. The old implementation checked that if (info4->Attributes& PRINTER_ATTRIBUTE_NETWORK) { So you don't think this is needed ? -phil. On 3/26/19, 1:22 PM, Alexey Ivanov wrote: > Please see the updated webrev: > http://cr.openjdk.java.net/~aivanov/8221412/webrev.1/ > > The difference between .0 and .1 is in some minor white-space > adjustments, like parameter alignment. > > On 26/03/2019 17:01, Alexey Ivanov wrote: >> Hi, >> >> Please review the fix for jdk 13: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8221412 >> webrev: http://cr.openjdk.java.net/~aivanov/8221412/webrev.0/ >> >> Description: >> The list of printers is not updated in the situation where there are >> no remote printers on the system and later the user adds a remote >> printer. >> >> Root cause: >> JDK-8153732 [1] added a new thread which polls remote printers on the >> system and updates the list if it detects a change. In this case it >> does not update the print services because of this condition: >> 449 if (prevRemotePrinters != null && prevRemotePrinters.length > 0) >> prevRemotePrinters is not null but its length is zero because no >> remote printers were initially present on the system. >> >> Fix: >> I removed this if. We have to update the list printers if doCompare() >> returns true. Either prevRemotePrinters or currentRemotePrinters, or >> both can be null; doCompare() handles this situation gracefully after >> JDK-8212202 [2]. >> >> The listener called getRemotePrintersNames() twice: in constructor >> and in run() before entering the first sleep. Now it's done only once. >> >> I consolidated the implementation of getAllPrinterNames() and >> getRemotePrintersNames(). They were very similar. The old >> implementation of getRemotePrintersNames() got the list of both local >> and remote printers and then filtered out local ones. The new >> implementation gets the list of remote printers only. So the >> difference between the two is limited to the flags passed to >> EnumPrinters. >> >> If there are no remote printers, the new version >> getRemotePrintersNames() returns null instead of empty array. As >> mentioned earlier, doCompare() handles this situation. >> >> I'll add the bugid (8221412) to the regression test when fixing >> JDK-8221263 [3]. I'm currently working on it. >> >> >> Thank you in advance. >> >> Regards, >> Alexey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8153732 >> [2] https://bugs.openjdk.java.net/browse/JDK-8212202 >> [3] https://bugs.openjdk.java.net/browse/JDK-8221263 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Wed Mar 27 11:30:37 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 27 Mar 2019 11:30:37 +0000 Subject: [OpenJDK 2D-Dev] Request for Sponsor: 8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type In-Reply-To: <18244b29-3950-9d71-0ad9-3cd908323ba3@oracle.com> References: <18244b29-3950-9d71-0ad9-3cd908323ba3@oracle.com> Message-ID: Thanks Prasanta, moving to 2d-dev maillist... Hi, Please can I obtain a sponsor for this simple fix to correct the parseImage() jni parameter type? https://bugs.openjdk.java.net/browse/JDK-8217735 http://cr.openjdk.java.net/~aleonard/8217735/webrev.00/ The problem manifests itself most notably with OpenJ9 when running the SwingSet2 demo, depending on how the stack byte alignment resolves iteself. I've not seen an issue yet running SwingSet2 with Hotspot, possibly by luck of stack alignment. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Prasanta Sadhukhan To: Andrew Leonard , awt-dev at openjdk.java.net Date: 27/03/2019 09:57 Subject: Re: Request for Sponsor: 8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type I can sponsor this...But I guess this review should be going to 2d-dev instead of awt-dev. Regards Prasanta On 27-Mar-19 1:12 AM, Andrew Leonard wrote: Hi, Please can I obtain a sponsor for this simple fix to correct the parseImage() jni parameter type? https://bugs.openjdk.java.net/browse/JDK-8217735 http://cr.openjdk.java.net/~aleonard/8217735/webrev.00/ The problem manifests itself most notably with OpenJ9 when running the SwingSet2 demo, depending on how the stack byte alignment resolves iteself. I've not seen an issue yet running SwingSet2 with Hotspot, possibly by luck of stack alignment. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Mar 27 12:08:17 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 27 Mar 2019 17:38:17 +0530 Subject: [OpenJDK 2D-Dev] [13] JDK-8221411: NullPointerException in RasterPrinterJob without PrinterResolution Message-ID: <596d6ffc-343f-da64-1884-2a067d48a4d1@oracle.com> Hi All, Please review a fix for an issue where a NPE is seen when an attempt is made to print without PrinterResolution attributes in HP Deskjet 1510 printer. It seems when RasterPrinterJob#setAttributes() is called with no PrinterResolution attribute set, it first checks if PrinterResolution category is supported. If it is supported, then it sees if the supplied resolution value is supported. Now, since no PrinterResolution attribute is set, so isSupportedValue() returns false [as "printer resolution attribute" object is null] It then goes to get the default resolution attribute via getDefaultAttributeValue() which calls getDefaultPrinterSettings() and use yRes,Quality from this printer to construct a "PrinterResolution" object. JDK uses DocumentProperties function[1] to query the printer configuration data in windows and pDevMode->dmFields is initialized to 200bf43 which corresponds to DM_ORIENTATION | DM_PAPERSIZE | DM_COPIES | DM_DEFAULTSOURCE | DM_PRINTQUALITY | DM_COLOR | DM_DUPLEX? | DM_YRESOLUTION | DM_COLLATE | DM_NUP | DM_MEDIATYPE so even though DM_YRESOLUTION and DM_PRINTQUALITY indices are set, it seems for HP Deskjet 1510 printer returns? -3 for both pDevMode->dmYResolution and pDevMode->dmPrintQuality so then Win32PrintService#getDefaultAttributeValue() checks for yRes,Quality and if they are < 0 then it does not instantiate PrinterResolution class ie printerResAttr object is null if (res >0) { return new PrinterResolution(res, res, PrinterResolution.DPI); } causing RasterPrinterJob#setAttributes to cause an NPE when it tries to call printerResAttr.getCrossFeedResolution(ResolutionSyntax.DPI); We have seen similar issue for Brother HL-2240D series printer, where DM_YRESOLUTION and DM_PRINTQUALITY was not set in dmFields even though? pDevMode->dmYResolution and pDevMode->dmPrintQuality was populated so we check for those values and store that but here the values itself are -ve so it does not get stored and ultimately resulted in returning GETDEFAULT_ERROR(-50) Proposed fix is to check if printerResAttr is null or not so printerResAttr.getCrossFeedResolution(ResolutionSyntax.DPI); will not be called for bad values. Bug: https://bugs.openjdk.java.net/browse/JDK-8221411 webrev: http://cr.openjdk.java.net/~psadhukhan/8221411/webrev.0/ Regards Prasanta [1] [https://msdn.microsoft.com/en-us/library/windows/desktop/dd183576(v=vs.85).aspx] -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Wed Mar 27 12:10:09 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 27 Mar 2019 17:40:09 +0530 Subject: [OpenJDK 2D-Dev] Request for Sponsor: 8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type In-Reply-To: References: <18244b29-3950-9d71-0ad9-3cd908323ba3@oracle.com> Message-ID: <3af42fce-6f57-c9af-aecc-b7e86b1fcf01@oracle.com> +1 Regards Prasanta On 27-Mar-19 5:00 PM, Andrew Leonard wrote: > Thanks Prasanta, moving to 2d-dev maillist... > Hi, > Please can I obtain a sponsor for this simple fix to correct the > parseImage() jni parameter type?_ > __https://bugs.openjdk.java.net/browse/JDK-8217735__ > __http://cr.openjdk.java.net/~aleonard/8217735/webrev.00/_ > > > The problem manifests itself most notably with OpenJ9 when running the > SwingSet2 demo, depending on how the stack byte alignment resolves > iteself. > I've not seen an issue yet running SwingSet2 with Hotspot, possibly by > luck of stack alignment. > > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Prasanta Sadhukhan > To: Andrew Leonard , > awt-dev at openjdk.java.net > Date: 27/03/2019 09:57 > Subject: Re: Request for Sponsor: 8217735: > awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong > type > ------------------------------------------------------------------------ > > > > I can sponsor this...But I guess this review should be going to 2d-dev > instead of awt-dev. > > Regards > Prasanta > On 27-Mar-19 1:12 AM, Andrew Leonard wrote: > Hi, > Please can I obtain a sponsor for this simple fix to correct the > parseImage() jni parameter type?_ > __https://bugs.openjdk.java.net/browse/JDK-8217735__ > __http://cr.openjdk.java.net/~aleonard/8217735/webrev.00/_ > > > The problem manifests itself most notably with OpenJ9 when running the > SwingSet2 demo, depending on how the stack byte alignment resolves > iteself. > I've not seen an issue yet running SwingSet2 with Hotspot, possibly by > luck of stack alignment. > > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: _andrew_m_leonard at uk.ibm.com_ > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Mar 27 12:57:50 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Wed, 27 Mar 2019 18:27:50 +0530 Subject: [OpenJDK 2D-Dev] Request for Sponsor: 8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type In-Reply-To: References: <18244b29-3950-9d71-0ad9-3cd908323ba3@oracle.com> Message-ID: <17576AE0-4AAE-4C85-8F8F-3FAD98AD9298@oracle.com> Hi Andrew, Thanks for your contribution. I would be happy to sponsor this change. May be J9 by default has tighter checks for JNI parameter types or -XCheck:jni option(https://www.eclipse.org/openj9/docs/xcheck/ ) is enabled while running Swingset demo. I think if we enable non-standard option -XCheck:jni in hotspot(https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html#BABHDABI ) we might see similar issue. I think there is no need for regression test for this case and I will just add a label in bug. Change looks good to me. Thanks, Jay > On 27-Mar-2019, at 5:00 PM, Andrew Leonard wrote: > > Thanks Prasanta, moving to 2d-dev maillist... > Hi, > Please can I obtain a sponsor for this simple fix to correct the parseImage() jni parameter type? > https://bugs.openjdk.java.net/browse/JDK-8217735 > http://cr.openjdk.java.net/~aleonard/8217735/webrev.00/ > > The problem manifests itself most notably with OpenJ9 when running the SwingSet2 demo, depending on how the stack byte alignment resolves iteself. > I've not seen an issue yet running SwingSet2 with Hotspot, possibly by luck of stack alignment. > > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > > > > From: Prasanta Sadhukhan > To: Andrew Leonard , awt-dev at openjdk.java.net > Date: 27/03/2019 09:57 > Subject: Re: Request for Sponsor: 8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type > > > > I can sponsor this...But I guess this review should be going to 2d-dev instead of awt-dev. > Regards > Prasanta > On 27-Mar-19 1:12 AM, Andrew Leonard wrote: > Hi, > Please can I obtain a sponsor for this simple fix to correct the parseImage() jni parameter type? > https://bugs.openjdk.java.net/browse/JDK-8217735 > http://cr.openjdk.java.net/~aleonard/8217735/webrev.00/ > > The problem manifests itself most notably with OpenJ9 when running the SwingSet2 demo, depending on how the stack byte alignment resolves iteself. > I've not seen an issue yet running SwingSet2 with Hotspot, possibly by luck of stack alignment. > > Many thanks > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > Phone internal: 245913, external: 01962 815913 > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew_m_leonard at uk.ibm.com Wed Mar 27 14:29:38 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Wed, 27 Mar 2019 14:29:38 +0000 Subject: [OpenJDK 2D-Dev] Request for Sponsor: 8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type In-Reply-To: <17576AE0-4AAE-4C85-8F8F-3FAD98AD9298@oracle.com> References: <18244b29-3950-9d71-0ad9-3cd908323ba3@oracle.com> <17576AE0-4AAE-4C85-8F8F-3FAD98AD9298@oracle.com> Message-ID: Thanks Jay, Prasanta, I've obviously verified the fix with J9 and SwingSet2 demo, and all looks good. Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Jayathirth Rao To: Andrew Leonard Cc: 2d-dev at openjdk.java.net Date: 27/03/2019 12:59 Subject: Re: [OpenJDK 2D-Dev] Request for Sponsor: 8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type Hi Andrew, Thanks for your contribution. I would be happy to sponsor this change. May be J9 by default has tighter checks for JNI parameter types or -XCheck:jni option(https://www.eclipse.org/openj9/docs/xcheck/) is enabled while running Swingset demo. I think if we enable non-standard option -XCheck:jni in hotspot( https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html#BABHDABI ) we might see similar issue. I think there is no need for regression test for this case and I will just add a label in bug. Change looks good to me. Thanks, Jay On 27-Mar-2019, at 5:00 PM, Andrew Leonard wrote: Thanks Prasanta, moving to 2d-dev maillist... Hi, Please can I obtain a sponsor for this simple fix to correct the parseImage() jni parameter type? https://bugs.openjdk.java.net/browse/JDK-8217735 http://cr.openjdk.java.net/~aleonard/8217735/webrev.00/ The problem manifests itself most notably with OpenJ9 when running the SwingSet2 demo, depending on how the stack byte alignment resolves iteself. I've not seen an issue yet running SwingSet2 with Hotspot, possibly by luck of stack alignment. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Prasanta Sadhukhan To: Andrew Leonard , awt-dev at openjdk.java.net Date: 27/03/2019 09:57 Subject: Re: Request for Sponsor: 8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type I can sponsor this...But I guess this review should be going to 2d-dev instead of awt-dev. Regards Prasanta On 27-Mar-19 1:12 AM, Andrew Leonard wrote: Hi, Please can I obtain a sponsor for this simple fix to correct the parseImage() jni parameter type? https://bugs.openjdk.java.net/browse/JDK-8217735 http://cr.openjdk.java.net/~aleonard/8217735/webrev.00/ The problem manifests itself most notably with OpenJ9 when running the SwingSet2 demo, depending on how the stack byte alignment resolves iteself. I've not seen an issue yet running SwingSet2 with Hotspot, possibly by luck of stack alignment. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Mar 27 15:50:56 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 27 Mar 2019 08:50:56 -0700 Subject: [OpenJDK 2D-Dev] [13] JDK-8221411: NullPointerException in RasterPrinterJob without PrinterResolution In-Reply-To: <596d6ffc-343f-da64-1884-2a067d48a4d1@oracle.com> References: <596d6ffc-343f-da64-1884-2a067d48a4d1@oracle.com> Message-ID: <87d3a923-003a-3dac-6f64-7ca9e06db9ea@oracle.com> Printer drivers sometimes are hard to fathom. I don't know if this means we are missing something but the fix seems safe enough. +1 -phil. On 3/27/19 5:08 AM, Prasanta Sadhukhan wrote: > > Hi All, > > Please review a fix for an issue where a NPE is seen when an attempt > is made to print without PrinterResolution attributes in HP Deskjet > 1510 printer. > > It seems when RasterPrinterJob#setAttributes() is called with no > PrinterResolution attribute set, it first checks if PrinterResolution > category is supported. > If it is supported, then it sees if the supplied resolution value is > supported. Now, since no PrinterResolution attribute is set, so > isSupportedValue() returns false > [as "printer resolution attribute" object is null] > It then goes to get the default resolution attribute via > getDefaultAttributeValue() which calls getDefaultPrinterSettings() and > use yRes,Quality from this printer to construct a "PrinterResolution" > object. > > JDK uses DocumentProperties function[1] to query the printer > configuration data in windows and pDevMode->dmFields is initialized to > 200bf43 > which corresponds to > DM_ORIENTATION | DM_PAPERSIZE | DM_COPIES | DM_DEFAULTSOURCE | > DM_PRINTQUALITY | DM_COLOR | DM_DUPLEX? | DM_YRESOLUTION | DM_COLLATE > | DM_NUP | DM_MEDIATYPE > so even though DM_YRESOLUTION and DM_PRINTQUALITY indices are set, > it seems for HP Deskjet 1510 printer returns? -3 for both > pDevMode->dmYResolution and pDevMode->dmPrintQuality > > so then Win32PrintService#getDefaultAttributeValue() checks for > yRes,Quality and if they are < 0 then it does not instantiate > PrinterResolution class ie printerResAttr object is null > if (res >0) { > return new PrinterResolution(res, res, PrinterResolution.DPI); > } > causing RasterPrinterJob#setAttributes to cause an NPE when it tries > to call printerResAttr.getCrossFeedResolution(ResolutionSyntax.DPI); > > We have seen similar issue for Brother HL-2240D series printer, where > DM_YRESOLUTION and DM_PRINTQUALITY was not set in dmFields even > though? pDevMode->dmYResolution and pDevMode->dmPrintQuality was > populated so we check for those values and store that but here the > values itself are -ve so it does not get stored and ultimately > resulted in returning GETDEFAULT_ERROR(-50) > > Proposed fix is to check if printerResAttr is null or not so > printerResAttr.getCrossFeedResolution(ResolutionSyntax.DPI); will not > be called for bad values. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221411 > webrev: http://cr.openjdk.java.net/~psadhukhan/8221411/webrev.0/ > > Regards > Prasanta > [1] > [https://msdn.microsoft.com/en-us/library/windows/desktop/dd183576(v=vs.85).aspx] -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Wed Mar 27 18:12:50 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 27 Mar 2019 18:12:50 +0000 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221412: lookupPrintServices() does not always update the list of Windows remote printers In-Reply-To: <5C9AC3F0.9030509@oracle.com> References: <5C9AC3F0.9030509@oracle.com> Message-ID: <8901018c-1710-2e2d-2325-ab33f08245f3@oracle.com> Hi Phil, On 27/03/2019 00:29, Philip Race wrote: > > > The old implementation of getRemotePrintersNames() got the list of > both local and remote printers and then filtered out local ones. > > The old implementation checked that > if (info4->Attributes & PRINTER_ATTRIBUTE_NETWORK) { So you don't > think this is needed ? No, I don't. The old implementation asked for both local and remote printers: ::EnumPrinters(PRINTER_ENUM_LOCAL | PRINTER_ENUM_CONNECTIONS, ? Then it removed local printers from the array. In getRemotePrintersNames() I ask for remote printers only: ::EnumPrinters(PRINTER_ENUM_CONNECTIONS, ? If the list is not empty, it contains only remote printers. Nothing to filter. Regards, Alexey > -phil. > > On 3/26/19, 1:22 PM, Alexey Ivanov wrote: >> Please see the updated webrev: >> http://cr.openjdk.java.net/~aivanov/8221412/webrev.1/ >> >> The difference between .0 and .1 is in some minor white-space >> adjustments, like parameter alignment. >> >> On 26/03/2019 17:01, Alexey Ivanov wrote: >>> Hi, >>> >>> Please review the fix for jdk 13: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8221412 >>> webrev: http://cr.openjdk.java.net/~aivanov/8221412/webrev.0/ >>> >>> Description: >>> The list of printers is not updated in the situation where there are >>> no remote printers on the system and later the user adds a remote >>> printer. >>> >>> Root cause: >>> JDK-8153732 [1] added a new thread which polls remote printers on >>> the system and updates the list if it detects a change. In this case >>> it does not update the print services because of this condition: >>> 449 if (prevRemotePrinters != null && prevRemotePrinters.length > 0) >>> prevRemotePrinters is not null but its length is zero because no >>> remote printers were initially present on the system. >>> >>> Fix: >>> I removed this if. We have to update the list printers if >>> doCompare() returns true. Either prevRemotePrinters or >>> currentRemotePrinters, or both can be null; doCompare() handles this >>> situation gracefully after JDK-8212202 [2]. >>> >>> The listener called getRemotePrintersNames() twice: in constructor >>> and in run() before entering the first sleep. Now it's done only once. >>> >>> I consolidated the implementation of getAllPrinterNames() and >>> getRemotePrintersNames(). They were very similar. The old >>> implementation of getRemotePrintersNames() got the list of both >>> local and remote printers and then filtered out local ones. The new >>> implementation gets the list of remote printers only. So the >>> difference between the two is limited to the flags passed to >>> EnumPrinters. >>> >>> If there are no remote printers, the new version >>> getRemotePrintersNames() returns null instead of empty array. As >>> mentioned earlier, doCompare() handles this situation. >>> >>> I'll add the bugid (8221412) to the regression test when fixing >>> JDK-8221263 [3]. I'm currently working on it. >>> >>> >>> Thank you in advance. >>> >>> Regards, >>> Alexey >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8153732 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8212202 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8221263 From philip.race at oracle.com Wed Mar 27 19:23:35 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 27 Mar 2019 12:23:35 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221412: lookupPrintServices() does not always update the list of Windows remote printers In-Reply-To: <8901018c-1710-2e2d-2325-ab33f08245f3@oracle.com> References: <5C9AC3F0.9030509@oracle.com> <8901018c-1710-2e2d-2325-ab33f08245f3@oracle.com> Message-ID: <7f59acec-508c-ad30-67ef-ab10ad800bea@oracle.com> OK. Approved. -phil On 3/27/19 11:12 AM, Alexey Ivanov wrote: > Hi Phil, > > On 27/03/2019 00:29, Philip Race wrote: >> >> > The old implementation of getRemotePrintersNames() got the list of >> both local and remote printers and then filtered out local ones. >> >> The old implementation checked that >> if (info4->Attributes & PRINTER_ATTRIBUTE_NETWORK) { So you don't >> think this is needed ? > > No, I don't. > > The old implementation asked for both local and remote printers: > ::EnumPrinters(PRINTER_ENUM_LOCAL | PRINTER_ENUM_CONNECTIONS, ? > > Then it removed local printers from the array. > > In getRemotePrintersNames() I ask for remote printers only: > ::EnumPrinters(PRINTER_ENUM_CONNECTIONS, ? > If the list is not empty, it contains only remote printers. Nothing to > filter. > > > Regards, > Alexey > >> -phil. >> >> On 3/26/19, 1:22 PM, Alexey Ivanov wrote: >>> Please see the updated webrev: >>> http://cr.openjdk.java.net/~aivanov/8221412/webrev.1/ >>> >>> The difference between .0 and .1 is in some minor white-space >>> adjustments, like parameter alignment. >>> >>> On 26/03/2019 17:01, Alexey Ivanov wrote: >>>> Hi, >>>> >>>> Please review the fix for jdk 13: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8221412 >>>> webrev: http://cr.openjdk.java.net/~aivanov/8221412/webrev.0/ >>>> >>>> Description: >>>> The list of printers is not updated in the situation where there >>>> are no remote printers on the system and later the user adds a >>>> remote printer. >>>> >>>> Root cause: >>>> JDK-8153732 [1] added a new thread which polls remote printers on >>>> the system and updates the list if it detects a change. In this >>>> case it does not update the print services because of this condition: >>>> 449 if (prevRemotePrinters != null && prevRemotePrinters.length > 0) >>>> prevRemotePrinters is not null but its length is zero because no >>>> remote printers were initially present on the system. >>>> >>>> Fix: >>>> I removed this if. We have to update the list printers if >>>> doCompare() returns true. Either prevRemotePrinters or >>>> currentRemotePrinters, or both can be null; doCompare() handles >>>> this situation gracefully after JDK-8212202 [2]. >>>> >>>> The listener called getRemotePrintersNames() twice: in constructor >>>> and in run() before entering the first sleep. Now it's done only once. >>>> >>>> I consolidated the implementation of getAllPrinterNames() and >>>> getRemotePrintersNames(). They were very similar. The old >>>> implementation of getRemotePrintersNames() got the list of both >>>> local and remote printers and then filtered out local ones. The new >>>> implementation gets the list of remote printers only. So the >>>> difference between the two is limited to the flags passed to >>>> EnumPrinters. >>>> >>>> If there are no remote printers, the new version >>>> getRemotePrintersNames() returns null instead of empty array. As >>>> mentioned earlier, doCompare() handles this situation. >>>> >>>> I'll add the bugid (8221412) to the regression test when fixing >>>> JDK-8221263 [3]. I'm currently working on it. >>>> >>>> >>>> Thank you in advance. >>>> >>>> Regards, >>>> Alexey >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8153732 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8212202 >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8221263 > From andrew_m_leonard at uk.ibm.com Thu Mar 28 14:49:45 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Thu, 28 Mar 2019 14:49:45 +0000 Subject: [OpenJDK 2D-Dev] Request for Sponsor: 8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type In-Reply-To: <17576AE0-4AAE-4C85-8F8F-3FAD98AD9298@oracle.com> References: <18244b29-3950-9d71-0ad9-3cd908323ba3@oracle.com> <17576AE0-4AAE-4C85-8F8F-3FAD98AD9298@oracle.com> Message-ID: Thank you for merging :-) Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Jayathirth Rao To: Andrew Leonard Cc: 2d-dev at openjdk.java.net Date: 27/03/2019 12:59 Subject: Re: [OpenJDK 2D-Dev] Request for Sponsor: 8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type Hi Andrew, Thanks for your contribution. I would be happy to sponsor this change. May be J9 by default has tighter checks for JNI parameter types or -XCheck:jni option(https://www.eclipse.org/openj9/docs/xcheck/) is enabled while running Swingset demo. I think if we enable non-standard option -XCheck:jni in hotspot( https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html#BABHDABI ) we might see similar issue. I think there is no need for regression test for this case and I will just add a label in bug. Change looks good to me. Thanks, Jay On 27-Mar-2019, at 5:00 PM, Andrew Leonard wrote: Thanks Prasanta, moving to 2d-dev maillist... Hi, Please can I obtain a sponsor for this simple fix to correct the parseImage() jni parameter type? https://bugs.openjdk.java.net/browse/JDK-8217735 http://cr.openjdk.java.net/~aleonard/8217735/webrev.00/ The problem manifests itself most notably with OpenJ9 when running the SwingSet2 demo, depending on how the stack byte alignment resolves iteself. I've not seen an issue yet running SwingSet2 with Hotspot, possibly by luck of stack alignment. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com From: Prasanta Sadhukhan To: Andrew Leonard , awt-dev at openjdk.java.net Date: 27/03/2019 09:57 Subject: Re: Request for Sponsor: 8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type I can sponsor this...But I guess this review should be going to 2d-dev instead of awt-dev. Regards Prasanta On 27-Mar-19 1:12 AM, Andrew Leonard wrote: Hi, Please can I obtain a sponsor for this simple fix to correct the parseImage() jni parameter type? https://bugs.openjdk.java.net/browse/JDK-8217735 http://cr.openjdk.java.net/~aleonard/8217735/webrev.00/ The problem manifests itself most notably with OpenJ9 when running the SwingSet2 demo, depending on how the stack byte alignment resolves iteself. I've not seen an issue yet running SwingSet2 with Hotspot, possibly by luck of stack alignment. Many thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Thu Mar 28 16:07:26 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 28 Mar 2019 16:07:26 +0000 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use Message-ID: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> Hi, Please review the following fix for jdk 13: bug: https://bugs.openjdk.java.net/browse/JDK-8221263 webrev: http://cr.openjdk.java.net/~aivanov/8221263/webrev.0/ This is a complete re-write of the test. It's semi-automatic: the tester is to add or remove a remote printer and to make sure the change is reflected in the list of printers returned from PrintServiceLookup.lookupPrintServices(null, null). Added or removed printers are highlighted in the "Before" and "After" lists. I've attached the screenshots to the JBS issue. I'm adding 8221263 and 8221412 to @bug tag. Shall I remove @ignore tag from the test? If it's there, jtreg does not start the test, likely it will never be run. Thank you in advance. Regards, Alexey From alexey.ivanov at oracle.com Thu Mar 28 16:11:21 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 28 Mar 2019 16:11:21 +0000 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8217707: JNICALL declaration breaks Splash screen functions In-Reply-To: <5fcbdb54-3b7d-48f8-7a9e-11d05021a0a2@oracle.com> References: <5fcbdb54-3b7d-48f8-7a9e-11d05021a0a2@oracle.com> Message-ID: <965e2134-f4b0-82f5-0a1c-0f3193f619f9@oracle.com> Any volunteers for review? On 24/03/2019 19:18, Alexey Ivanov wrote: > Hi, > > Please review the fix for jdk 13. > > bug: https://bugs.openjdk.java.net/browse/JDK-8217707 > webrev: http://cr.openjdk.java.net/~aivanov/8217707/webrev.0/ > > Description: > Splash screen functionality is broken in 32 bit Windows. It's because > the functions in splashscreen.dll are exported with decorated names > now, yet they're looked up by the undecorated names. > > The easiest way to reproduce the problem is to run SwingSet2: > java -jar SwingSet2.jar > > > Fix: > The fix removes JNICALL (__stdcall) declarations from splash screen > functions. Thus the functions are exported undecorated. > > I've run SplashScreen jtreg tests, all tests pass. > > This is a follow-up fix to > https://bugs.openjdk.java.net/browse/JDK-8201226 > https://bugs.openjdk.java.net/browse/JDK-8202476 > which re-enabled 32 bit Windows post removal of mapfiles / compiler > options. > > > Thank you in advance. > > Regards, > Alexey From philip.race at oracle.com Thu Mar 28 16:44:28 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Mar 2019 09:44:28 -0700 Subject: [OpenJDK 2D-Dev] Result: New 2D Group Member: Jayathirth DV Message-ID: <5C9CF9EC.8010504@oracle.com> The vote [1] for Jayathirth DV is now closed. Yes: 2 Veto: 0 Abstain: 0 According to the OpenJDK Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. -phil. [1] https://mail.openjdk.java.net/pipermail/2d-dev/2019-March/009945.html [2] http://openjdk.java.net/bylaws#lazy-consensus From philip.race at oracle.com Thu Mar 28 17:15:02 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Mar 2019 10:15:02 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8217707: JNICALL declaration breaks Splash screen functions In-Reply-To: <965e2134-f4b0-82f5-0a1c-0f3193f619f9@oracle.com> References: <5fcbdb54-3b7d-48f8-7a9e-11d05021a0a2@oracle.com> <965e2134-f4b0-82f5-0a1c-0f3193f619f9@oracle.com> Message-ID: <5C9D0116.8010303@oracle.com> > I've run SplashScreen jtreg tests, all tests pass. I assume you mean you did this for 32 AND 64 bit builds ? If so, then +1 -phil. On 3/28/19, 9:11 AM, Alexey Ivanov wrote: > Any volunteers for review? > > On 24/03/2019 19:18, Alexey Ivanov wrote: >> Hi, >> >> Please review the fix for jdk 13. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8217707 >> webrev: http://cr.openjdk.java.net/~aivanov/8217707/webrev.0/ >> >> Description: >> Splash screen functionality is broken in 32 bit Windows. It's because >> the functions in splashscreen.dll are exported with decorated names >> now, yet they're looked up by the undecorated names. >> >> The easiest way to reproduce the problem is to run SwingSet2: >> java -jar SwingSet2.jar >> >> >> Fix: >> The fix removes JNICALL (__stdcall) declarations from splash screen >> functions. Thus the functions are exported undecorated. >> >> I've run SplashScreen jtreg tests, all tests pass. >> >> This is a follow-up fix to >> https://bugs.openjdk.java.net/browse/JDK-8201226 >> https://bugs.openjdk.java.net/browse/JDK-8202476 >> which re-enabled 32 bit Windows post removal of mapfiles / compiler >> options. >> >> >> Thank you in advance. >> >> Regards, >> Alexey > From thomas.stuefe at gmail.com Thu Mar 28 17:17:51 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Mar 2019 18:17:51 +0100 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8217707: JNICALL declaration breaks Splash screen functions In-Reply-To: <965e2134-f4b0-82f5-0a1c-0f3193f619f9@oracle.com> References: <5fcbdb54-3b7d-48f8-7a9e-11d05021a0a2@oracle.com> <965e2134-f4b0-82f5-0a1c-0f3193f619f9@oracle.com> Message-ID: Looks fine. Cheers, Thomas On Thu, Mar 28, 2019 at 5:11 PM Alexey Ivanov wrote: > Any volunteers for review? > > On 24/03/2019 19:18, Alexey Ivanov wrote: > > Hi, > > > > Please review the fix for jdk 13. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8217707 > > webrev: http://cr.openjdk.java.net/~aivanov/8217707/webrev.0/ > > > > Description: > > Splash screen functionality is broken in 32 bit Windows. It's because > > the functions in splashscreen.dll are exported with decorated names > > now, yet they're looked up by the undecorated names. > > > > The easiest way to reproduce the problem is to run SwingSet2: > > java -jar SwingSet2.jar > > > > > > Fix: > > The fix removes JNICALL (__stdcall) declarations from splash screen > > functions. Thus the functions are exported undecorated. > > > > I've run SplashScreen jtreg tests, all tests pass. > > > > This is a follow-up fix to > > https://bugs.openjdk.java.net/browse/JDK-8201226 > > https://bugs.openjdk.java.net/browse/JDK-8202476 > > which re-enabled 32 bit Windows post removal of mapfiles / compiler > > options. > > > > > > Thank you in advance. > > > > Regards, > > Alexey > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Thu Mar 28 17:25:49 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 28 Mar 2019 17:25:49 +0000 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8217707: JNICALL declaration breaks Splash screen functions In-Reply-To: <5C9D0116.8010303@oracle.com> References: <5fcbdb54-3b7d-48f8-7a9e-11d05021a0a2@oracle.com> <965e2134-f4b0-82f5-0a1c-0f3193f619f9@oracle.com> <5C9D0116.8010303@oracle.com> Message-ID: <4d216591-38ff-4acf-6957-4ba1f48d1d57@oracle.com> On 28/03/2019 17:15, Philip Race wrote: > > I've run SplashScreen jtreg tests, all tests pass. > > I assume you mean you did this for 32 AND 64 bit builds ? Yes, I ran the tests for both 32 and 64 bit builds. -- Alexey > > If so, then +1 > > -phil. > > On 3/28/19, 9:11 AM, Alexey Ivanov wrote: >> Any volunteers for review? >> >> On 24/03/2019 19:18, Alexey Ivanov wrote: >>> Hi, >>> >>> Please review the fix for jdk 13. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8217707 >>> webrev: http://cr.openjdk.java.net/~aivanov/8217707/webrev.0/ >>> >>> Description: >>> Splash screen functionality is broken in 32 bit Windows. It's >>> because the functions in splashscreen.dll are exported with >>> decorated names now, yet they're looked up by the undecorated names. >>> >>> The easiest way to reproduce the problem is to run SwingSet2: >>> java -jar SwingSet2.jar >>> >>> >>> Fix: >>> The fix removes JNICALL (__stdcall) declarations from splash screen >>> functions. Thus the functions are exported undecorated. >>> >>> I've run SplashScreen jtreg tests, all tests pass. >>> >>> This is a follow-up fix to >>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>> which re-enabled 32 bit Windows post removal of mapfiles / compiler >>> options. >>> >>> >>> Thank you in advance. >>> >>> Regards, >>> Alexey >> From Sergey.Bylokhov at oracle.com Fri Mar 29 00:52:51 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 28 Mar 2019 17:52:51 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> References: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> Message-ID: <7b303d4e-143c-8a2a-9998-5d016c88b26d@oracle.com> Hi, Alexey. I think it is ok to drop @ignore tag, but I wonder why did you add the step6 to the instruction. 197 + "updated.\n" 198 + "Step 6: If the list is not updated, wait for another " 199 + "4 minutes, and then click Refresh again.\n" On 28/03/2019 09:07, Alexey Ivanov wrote: > Hi, > > Please review the following fix for jdk 13: > > bug: https://bugs.openjdk.java.net/browse/JDK-8221263 > webrev: http://cr.openjdk.java.net/~aivanov/8221263/webrev.0/ > > This is a complete re-write of the test. > > It's semi-automatic: the tester is to add or remove a remote printer and to make sure the change is reflected in the list of printers returned from PrintServiceLookup.lookupPrintServices(null, null). Added or removed printers are highlighted in the "Before" and "After" lists. > > I've attached the screenshots to the JBS issue. > > I'm adding 8221263 and 8221412 to @bug tag. > > > Shall I remove @ignore tag from the test? If it's there, jtreg does not start the test, likely it will never be run. > > Thank you in advance. > > Regards, > Alexey -- Best regards, Sergey. From philip.race at oracle.com Fri Mar 29 01:09:08 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Mar 2019 18:09:08 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: <7b303d4e-143c-8a2a-9998-5d016c88b26d@oracle.com> References: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> <7b303d4e-143c-8a2a-9998-5d016c88b26d@oracle.com> Message-ID: <5C9D7034.9080703@oracle.com> Are you looking for a reason other than that the implementation is set to refresh the printer list every 4 minutes ? -phil. On 3/28/19, 5:52 PM, Sergey Bylokhov wrote: > Hi, Alexey. > > I think it is ok to drop @ignore tag, but I wonder why did you add the > step6 to the instruction. > 197 + "updated.\n" > 198 + "Step 6: If the list is not updated, wait > for another " > 199 + "4 minutes, and then click Refresh > again.\n" > > On 28/03/2019 09:07, Alexey Ivanov wrote: >> Hi, >> >> Please review the following fix for jdk 13: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8221263 >> webrev: http://cr.openjdk.java.net/~aivanov/8221263/webrev.0/ >> >> This is a complete re-write of the test. >> >> It's semi-automatic: the tester is to add or remove a remote printer >> and to make sure the change is reflected in the list of printers >> returned from PrintServiceLookup.lookupPrintServices(null, null). >> Added or removed printers are highlighted in the "Before" and "After" >> lists. >> >> I've attached the screenshots to the JBS issue. >> >> I'm adding 8221263 and 8221412 to @bug tag. >> >> >> Shall I remove @ignore tag from the test? If it's there, jtreg does >> not start the test, likely it will never be run. >> >> Thank you in advance. >> >> Regards, >> Alexey > > From alexey.ivanov at oracle.com Fri Mar 29 15:28:02 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 29 Mar 2019 15:28:02 +0000 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: <5C9D7034.9080703@oracle.com> References: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> <7b303d4e-143c-8a2a-9998-5d016c88b26d@oracle.com> <5C9D7034.9080703@oracle.com> Message-ID: <7440423b-c804-2262-e4f2-2196b7e21b32@oracle.com> Hi Sergey, Phil, Thank you for your review. Please take a look at the updated webrev where I've removed @ignore tag from the test: http://cr.openjdk.java.net/~aivanov/8221263/webrev.1/ On 29/03/2019 01:09, Philip Race wrote: > Are you looking for a reason other than that the implementation > is set to refresh the printer list every 4 minutes ? Yes, remote printer list is refreshed every 4 minutes on Windows. The reason why I added step 6 is that the user has no way of knowing when the refresh occurred. The refresh could happen just before the printer is added. Waiting for another refresh is to prevent false failures. If the list isn't updated in two refresh cycles, likely it won't be updated. In this case, the user will click Fail. Regards, Alexey > > -phil. > > > On 3/28/19, 5:52 PM, Sergey Bylokhov wrote: >> Hi, Alexey. >> >> I think it is ok to drop @ignore tag, but I wonder why did you add >> the step6 to the instruction. >> 197???????????????????? +????????? "updated.\n" >> 198???????????????????? + "Step 6: If the list is not updated, wait >> for another " >> 199???????????????????? +????????? "4 minutes, and then click Refresh >> again.\n" >> >> On 28/03/2019 09:07, Alexey Ivanov wrote: >>> Hi, >>> >>> Please review the following fix for jdk 13: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8221263 >>> webrev: http://cr.openjdk.java.net/~aivanov/8221263/webrev.0/ >>> >>> This is a complete re-write of the test. >>> >>> It's semi-automatic: the tester is to add or remove a remote printer >>> and to make sure the change is reflected in the list of printers >>> returned from PrintServiceLookup.lookupPrintServices(null, null). >>> Added or removed printers are highlighted in the "Before" and >>> "After" lists. >>> >>> I've attached the screenshots to the JBS issue. >>> >>> I'm adding 8221263 and 8221412 to @bug tag. >>> >>> >>> Shall I remove @ignore tag from the test? If it's there, jtreg does >>> not start the test, likely it will never be run. >>> >>> Thank you in advance. >>> >>> Regards, >>> Alexey From Sergey.Bylokhov at oracle.com Fri Mar 29 20:35:31 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 29 Mar 2019 13:35:31 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR: JDK-8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use In-Reply-To: <7440423b-c804-2262-e4f2-2196b7e21b32@oracle.com> References: <52c48572-4a4f-6131-f8ae-1d951b398345@oracle.com> <7b303d4e-143c-8a2a-9998-5d016c88b26d@oracle.com> <5C9D7034.9080703@oracle.com> <7440423b-c804-2262-e4f2-2196b7e21b32@oracle.com> Message-ID: <71919cfa-6c7d-d908-2fad-319a9b714c37@oracle.com> But it looks like an overkill to wait 8 minutes for one test, isn't it? Probably we can force the less timeout by the "sun.java2d.print.minRefreshTime"? On 29/03/2019 08:28, Alexey Ivanov wrote: > Please take a look at the updated webrev where I've removed @ignore tag from the test: > http://cr.openjdk.java.net/~aivanov/8221263/webrev.1/ > > On 29/03/2019 01:09, Philip Race wrote: >> Are you looking for a reason other than that the implementation >> is set to refresh the printer list every 4 minutes ? > > Yes, remote printer list is refreshed every 4 minutes on Windows. > > The reason why I added step 6 is that the user has no way of knowing when the refresh occurred. The refresh could happen just before the printer is added. Waiting for another refresh is to prevent false failures. If the list isn't updated in two refresh cycles, likely it won't be updated. In this case, the user will click Fail. > > Regards, > Alexey > >> >> -phil. >> >> >> On 3/28/19, 5:52 PM, Sergey Bylokhov wrote: >>> Hi, Alexey. >>> >>> I think it is ok to drop @ignore tag, but I wonder why did you add the step6 to the instruction. >>> 197???????????????????? +????????? "updated.\n" >>> 198???????????????????? + "Step 6: If the list is not updated, wait for another " >>> 199???????????????????? +????????? "4 minutes, and then click Refresh again.\n" >>> >>> On 28/03/2019 09:07, Alexey Ivanov wrote: >>>> Hi, >>>> >>>> Please review the following fix for jdk 13: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8221263 >>>> webrev: http://cr.openjdk.java.net/~aivanov/8221263/webrev.0/ >>>> >>>> This is a complete re-write of the test. >>>> >>>> It's semi-automatic: the tester is to add or remove a remote printer and to make sure the change is reflected in the list of printers returned from PrintServiceLookup.lookupPrintServices(null, null). Added or removed printers are highlighted in the "Before" and "After" lists. >>>> >>>> I've attached the screenshots to the JBS issue. >>>> >>>> I'm adding 8221263 and 8221412 to @bug tag. >>>> >>>> >>>> Shall I remove @ignore tag from the test? If it's there, jtreg does not start the test, likely it will never be run. >>>> >>>> Thank you in advance. >>>> >>>> Regards, >>>> Alexey -- Best regards, Sergey.