From matthias.baesken at sap.com Tue Aug 7 15:04:55 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 7 Aug 2018 15:04:55 +0000 Subject: [OpenJDK 2D-Dev] libsplashscreen compilation on ppc64 ( le) - was : RE: RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update Message-ID: Hello, should I prepare a change setting the -DPNG_POWERPC_VSX=0 flag in the makefile (see below) ? Might make future libpng updates more simple . Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 2. August 2018 17:28 To: 'Phil Race' ; Doerr, Martin Cc: Simonis, Volker ; Lindenmaier, Goetz Subject: RE: RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update - was : RE: jdk-hs ppc64le build error, probably related to libpng update Hi Phil, I added -DPNG_POWERPC_VSX=0 to Awt2dLibraries.gmk for the sphlashscreen library build, and removed (uncommented) the workaround in pngpriv.h . Build on the head of jdk11 was fine on my linux ppc64le test machine . Best regards, Matthias Diff: /open_jdk/jdk11> hg diff diff -r 26cca23c165a make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk Thu Aug 02 09:49:04 2018 +0200 +++ b/make/lib/Awt2dLibraries.gmk Thu Aug 02 16:50:09 2018 +0200 @@ -794,7 +794,8 @@ LIBSPLASHSCREEN_EXCLUDE_SRC_PATTERNS := unix endif - LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 + # disable ppc64 opts + LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 -DPNG_POWERPC_VSX=0 ifeq ($(OPENJDK_TARGET_OS), macosx) LIBSPLASHSCREEN_CFLAGS += -DWITH_MACOSX diff -r 26cca23c165a src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h --- a/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Thu Aug 02 09:49:04 2018 +0200 +++ b/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Thu Aug 02 16:50:09 2018 +0200 @@ -290,12 +290,12 @@ # endif #endif /* PNG_MIPS_MSA_OPT > 0 */ -#ifdef PNG_POWERPC_VSX_API_SUPPORTED +/* #ifdef PNG_POWERPC_VSX_API_SUPPORTED */ #if PNG_POWERPC_VSX_OPT > 0 # define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_vsx # define PNG_POWERPC_VSX_IMPLEMENTATION 1 #endif -#endif +/* #endif */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Aug 7 15:14:58 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 07 Aug 2018 08:14:58 -0700 Subject: [OpenJDK 2D-Dev] libsplashscreen compilation on ppc64 ( le) - was : RE: RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update In-Reply-To: References: Message-ID: <5B69B772.1020706@oracle.com> Works for me. Include build-dev on the review. And splashscreen is considered an AWT feature so it should be awt-dev not 2d-dev although you may want to reference back to this earlier exchange. -phil. On 8/7/18, 8:04 AM, Baesken, Matthias wrote: > > Hello, should I prepare a change setting the -DPNG_POWERPC_VSX=0 > flag in the makefile (see below) ? > > Might make future libpng updates more simple . > > Best regards, Matthias > > *From:*Baesken, Matthias > *Sent:* Donnerstag, 2. August 2018 17:28 > *To:* 'Phil Race' ; Doerr, Martin > > *Cc:* Simonis, Volker ; Lindenmaier, Goetz > > *Subject:* RE: RFR 8195615 : libsplashscreen linux ppc64le build error > after libpng update - was : RE: jdk-hs ppc64le build error, probably > related to libpng update > > Hi Phil, I added -DPNG_POWERPC_VSX=0 to Awt2dLibraries.gmk for > the sphlashscreen library build, and removed (uncommented) the > workaround in pngpriv.h . > > Build on the head of jdk11 was fine on my linux ppc64le test > machine . > > Best regards, Matthias > > Diff: > > /open_jdk/jdk11> hg diff > > diff -r 26cca23c165a make/lib/Awt2dLibraries.gmk > > --- a/make/lib/Awt2dLibraries.gmk Thu Aug 02 09:49:04 2018 +0200 > > +++ b/make/lib/Awt2dLibraries.gmk Thu Aug 02 16:50:09 2018 +0200 > > @@ -794,7 +794,8 @@ > > LIBSPLASHSCREEN_EXCLUDE_SRC_PATTERNS := unix > > endif > > - LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE > -DPNG_ARM_NEON_OPT=0 > > + # disable ppc64 opts > > + LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE > -DPNG_ARM_NEON_OPT=0 -DPNG_POWERPC_VSX=0 > > ifeq ($(OPENJDK_TARGET_OS), macosx) > > LIBSPLASHSCREEN_CFLAGS += -DWITH_MACOSX > > diff -r 26cca23c165a > src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h > > --- > a/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h > Thu Aug 02 09:49:04 2018 +0200 > > +++ > b/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h > Thu Aug 02 16:50:09 2018 +0200 > > @@ -290,12 +290,12 @@ > > # endif > > #endif /* PNG_MIPS_MSA_OPT > 0 */ > > -#ifdef PNG_POWERPC_VSX_API_SUPPORTED > > +/* #ifdef PNG_POWERPC_VSX_API_SUPPORTED */ > > #if PNG_POWERPC_VSX_OPT > 0 > > # define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_vsx > > # define PNG_POWERPC_VSX_IMPLEMENTATION 1 > > #endif > > -#endif > > +/* #endif */ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fairoz.matte at oracle.com Fri Aug 10 13:44:02 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Fri, 10 Aug 2018 06:44:02 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [8u] RFR: 8182461: IndexOutOfBoundsException when reading indexed color BMP Message-ID: <386b7e93-3de5-4301-abba-e50b2a4d27a0@default> Hi, Kindly review a small fix for 8u Background: Issue exist only in 8 and it got fixed in 9 as part of "JDK-8033716 : Fix raw and unchecked lint warnings in com.sun.imageio" This is big changeset and not feasible to backport on 8. Patch contains only the fix for 8182461 JBS bug - https://bugs.openjdk.java.net/browse/JDK-8182461 Webrev - http://cr.openjdk.java.net/~fmatte/8182461/webrev.00/ Thanks, Fairoz From philip.race at oracle.com Fri Aug 10 18:14:49 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 10 Aug 2018 11:14:49 -0700 Subject: [OpenJDK 2D-Dev] [8u] RFR: 8182461: IndexOutOfBoundsException when reading indexed color BMP In-Reply-To: <386b7e93-3de5-4301-abba-e50b2a4d27a0@default> References: <386b7e93-3de5-4301-abba-e50b2a4d27a0@default> Message-ID: <77e55152-d69d-9b39-2a86-a73dc86ba979@oracle.com> +1 -phil. On 08/10/2018 06:44 AM, Fairoz Matte wrote: > Hi, > > Kindly review a small fix for 8u > > Background: > Issue exist only in 8 and it got fixed in 9 as part of "JDK-8033716 : Fix raw and unchecked lint warnings in com.sun.imageio" > This is big changeset and not feasible to backport on 8. > > Patch contains only the fix for 8182461 > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8182461 > Webrev - http://cr.openjdk.java.net/~fmatte/8182461/webrev.00/ > > Thanks, > Fairoz From Sergey.Bylokhov at oracle.com Fri Aug 10 18:58:38 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 10 Aug 2018 11:58:38 -0700 Subject: [OpenJDK 2D-Dev] [8u] RFR: 8182461: IndexOutOfBoundsException when reading indexed color BMP In-Reply-To: <386b7e93-3de5-4301-abba-e50b2a4d27a0@default> References: <386b7e93-3de5-4301-abba-e50b2a4d27a0@default> Message-ID: Looks fine. On 10/08/2018 06:44, Fairoz Matte wrote: > Hi, > > Kindly review a small fix for 8u > > Background: > Issue exist only in 8 and it got fixed in 9 as part of "JDK-8033716 : Fix raw and unchecked lint warnings in com.sun.imageio" > This is big changeset and not feasible to backport on 8. > > Patch contains only the fix for 8182461 > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8182461 > Webrev - http://cr.openjdk.java.net/~fmatte/8182461/webrev.00/ > > Thanks, > Fairoz > -- Best regards, Sergey. From fairoz.matte at oracle.com Mon Aug 13 04:37:26 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Sun, 12 Aug 2018 21:37:26 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [8u] RFR: 8182461: IndexOutOfBoundsException when reading indexed color BMP In-Reply-To: References: <386b7e93-3de5-4301-abba-e50b2a4d27a0@default> Message-ID: <18cc81cb-2162-4e88-b395-2b4a22e47b66@default> Thank you Phil and Sergey for the reviews. Thanks, Fairoz > -----Original Message----- > From: Sergey Bylokhov > Sent: Saturday, August 11, 2018 12:29 AM > To: Fairoz Matte ; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] [8u] RFR: 8182461: > IndexOutOfBoundsException when reading indexed color BMP > > Looks fine. > > On 10/08/2018 06:44, Fairoz Matte wrote: > > Hi, > > > > Kindly review a small fix for 8u > > > > Background: > > Issue exist only in 8 and it got fixed in 9 as part of "JDK-8033716 : Fix raw and > unchecked lint warnings in com.sun.imageio" > > This is big changeset and not feasible to backport on 8. > > > > Patch contains only the fix for 8182461 > > > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8182461 > > Webrev - http://cr.openjdk.java.net/~fmatte/8182461/webrev.00/ > > > > Thanks, > > Fairoz > > > > > -- > Best regards, Sergey. From krishna.addepalli at oracle.com Mon Aug 13 06:39:50 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Sun, 12 Aug 2018 23:39:50 -0700 (PDT) Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double) In-Reply-To: <5c6de6b53bb233009fa9216a445abcc3@hummeling.com> References: <5c6de6b53bb233009fa9216a445abcc3@hummeling.com> Message-ID: Dear Ralph, Thanks for pointing this out, could you also come up with a patch for the same? Thanks, Krishna -----Original Message----- From: Ralph Hummeling Sent: Friday, July 20, 2018 8:25 PM To: 2d-dev at openjdk.java.net Cc: james.graham at oracle.com Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double) Dear Java 2D dev team, I came across your java.awt.geom.ArcIterator class in which an arc Bezier control point segment length is determined in method btan(double). You arrive at the following equation: 4/3*(1 - cos(a/2))/(sin(a/2)) It is mentioned that this can return NaN for small "a" and so it is written as: 4/3*(sin(a/2))/(1 + cos(a/2)) Please note that this relation can also be written as follows: 4/3*tan(a/4) A performance increase and no NaN issues ;-) Kind regards, Ralph Hummeling +316 5758 1679 Hummeling Engineering BV www.hummeling.com From engineering at hummeling.com Tue Aug 14 14:28:46 2018 From: engineering at hummeling.com (Ralph Hummeling) Date: Tue, 14 Aug 2018 16:28:46 +0200 Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double) In-Reply-To: References: <5c6de6b53bb233009fa9216a445abcc3@hummeling.com> Message-ID: <3bb09ccc-f1e1-e6d0-9dad-9937d99099d3@hummeling.com> Dear Krishna, I'd love to. How do I best do that? Kind regards, Ralph Hummeling +316 5758 1679 Hummeling Engineering BV www.hummeling.com On 13/08/18 08:39, Krishna Addepalli wrote: > Dear Ralph, > > Thanks for pointing this out, could you also come up with a patch for the same? > > Thanks, > Krishna > > -----Original Message----- > From: Ralph Hummeling > Sent: Friday, July 20, 2018 8:25 PM > To: 2d-dev at openjdk.java.net > Cc: james.graham at oracle.com > Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double) > > Dear Java 2D dev team, > > I came across your java.awt.geom.ArcIterator class in which an arc Bezier control point segment length is determined in method btan(double). You arrive at the following equation: > 4/3*(1 - cos(a/2))/(sin(a/2)) > > It is mentioned that this can return NaN for small "a" and so it is written as: > 4/3*(sin(a/2))/(1 + cos(a/2)) > > Please note that this relation can also be written as follows: > 4/3*tan(a/4) > > A performance increase and no NaN issues ;-) > > > Kind regards, > > Ralph Hummeling > +316 5758 1679 > Hummeling Engineering BV > www.hummeling.com > From krishna.addepalli at oracle.com Tue Aug 14 14:33:40 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 14 Aug 2018 07:33:40 -0700 (PDT) Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double) In-Reply-To: <3bb09ccc-f1e1-e6d0-9dad-9937d99099d3@hummeling.com> References: <5c6de6b53bb233009fa9216a445abcc3@hummeling.com> <3bb09ccc-f1e1-e6d0-9dad-9937d99099d3@hummeling.com> Message-ID: I guess you would already have the code checked out? It is just a matter of updating the comments explaining how sin(a/2) / (1 + cos(a/2)) is equal to tan(a/4), and then change it in the code. I think you would need a test along with it. Thanks, Krishna -----Original Message----- From: Ralph Hummeling Sent: Tuesday, August 14, 2018 7:59 PM To: Krishna Addepalli ; 2d-dev at openjdk.java.net Cc: james.graham at oracle.com Subject: Re: [OpenJDK 2D-Dev] ArcIterator#btan(double) Dear Krishna, I'd love to. How do I best do that? Kind regards, Ralph Hummeling +316 5758 1679 Hummeling Engineering BV https://urldefense.proofpoint.com/v2/url?u=http-3A__www.hummeling.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=iFb2N0ZBD0EAiVLz7h0dhj41Ha2uquc9ZM_GpTwq_w8&s=ypabzzNLUNIyzlXJK9-g27W-gz6a1phXmPa771N3ZGU&e= On 13/08/18 08:39, Krishna Addepalli wrote: > Dear Ralph, > > Thanks for pointing this out, could you also come up with a patch for the same? > > Thanks, > Krishna > > -----Original Message----- > From: Ralph Hummeling > Sent: Friday, July 20, 2018 8:25 PM > To: 2d-dev at openjdk.java.net > Cc: james.graham at oracle.com > Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double) > > Dear Java 2D dev team, > > I came across your java.awt.geom.ArcIterator class in which an arc Bezier control point segment length is determined in method btan(double). You arrive at the following equation: > 4/3*(1 - cos(a/2))/(sin(a/2)) > > It is mentioned that this can return NaN for small "a" and so it is written as: > 4/3*(sin(a/2))/(1 + cos(a/2)) > > Please note that this relation can also be written as follows: > 4/3*tan(a/4) > > A performance increase and no NaN issues ;-) > > > Kind regards, > > Ralph Hummeling > +316 5758 1679 > Hummeling Engineering BV > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.hummeling.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=iFb2N0ZBD0EAiVLz7h0dhj41Ha2uquc9ZM_GpTwq_w8&s=ypabzzNLUNIyzlXJK9-g27W-gz6a1phXmPa771N3ZGU&e= > From engineering at hummeling.com Tue Aug 14 14:38:05 2018 From: engineering at hummeling.com (Ralph Hummeling) Date: Tue, 14 Aug 2018 16:38:05 +0200 Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double) In-Reply-To: References: <5c6de6b53bb233009fa9216a445abcc3@hummeling.com> <3bb09ccc-f1e1-e6d0-9dad-9937d99099d3@hummeling.com> Message-ID: <2066a803-0404-23d9-fa78-9031ac0a0df1@hummeling.com> Nope, didn't check-out the code with any version system. Just looked at it in NetBeans IDE. Kind regards, Ralph Hummeling +316 5758 1679 Hummeling Engineering BV www.hummeling.com On 14/08/18 16:33, Krishna Addepalli wrote: > I guess you would already have the code checked out? It is just a matter of updating the comments explaining how sin(a/2) / (1 + cos(a/2)) is equal to tan(a/4), and then change it in the code. > I think you would need a test along with it. > > Thanks, > Krishna > > -----Original Message----- > From: Ralph Hummeling > Sent: Tuesday, August 14, 2018 7:59 PM > To: Krishna Addepalli ; 2d-dev at openjdk.java.net > Cc: james.graham at oracle.com > Subject: Re: [OpenJDK 2D-Dev] ArcIterator#btan(double) > > Dear Krishna, > > I'd love to. How do I best do that? > > > Kind regards, > > Ralph Hummeling > +316 5758 1679 > Hummeling Engineering BV > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.hummeling.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=iFb2N0ZBD0EAiVLz7h0dhj41Ha2uquc9ZM_GpTwq_w8&s=ypabzzNLUNIyzlXJK9-g27W-gz6a1phXmPa771N3ZGU&e= > > On 13/08/18 08:39, Krishna Addepalli wrote: >> Dear Ralph, >> >> Thanks for pointing this out, could you also come up with a patch for the same? >> >> Thanks, >> Krishna >> >> -----Original Message----- >> From: Ralph Hummeling >> Sent: Friday, July 20, 2018 8:25 PM >> To: 2d-dev at openjdk.java.net >> Cc: james.graham at oracle.com >> Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double) >> >> Dear Java 2D dev team, >> >> I came across your java.awt.geom.ArcIterator class in which an arc Bezier control point segment length is determined in method btan(double). You arrive at the following equation: >> 4/3*(1 - cos(a/2))/(sin(a/2)) >> >> It is mentioned that this can return NaN for small "a" and so it is written as: >> 4/3*(sin(a/2))/(1 + cos(a/2)) >> >> Please note that this relation can also be written as follows: >> 4/3*tan(a/4) >> >> A performance increase and no NaN issues ;-) >> >> >> Kind regards, >> >> Ralph Hummeling >> +316 5758 1679 >> Hummeling Engineering BV >> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.hummeling.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=iFb2N0ZBD0EAiVLz7h0dhj41Ha2uquc9ZM_GpTwq_w8&s=ypabzzNLUNIyzlXJK9-g27W-gz6a1phXmPa771N3ZGU&e= >> From krishna.addepalli at oracle.com Tue Aug 14 14:38:16 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Tue, 14 Aug 2018 07:38:16 -0700 (PDT) Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double) In-Reply-To: References: <5c6de6b53bb233009fa9216a445abcc3@hummeling.com> <3bb09ccc-f1e1-e6d0-9dad-9937d99099d3@hummeling.com> Message-ID: <96443609-380b-429b-b06f-00eabc736a93@default> Sorry, I replied assuming certain things before actually clarifying. Are you asking about the process for submitting a patch? Could you be a bit more specific so that I can answer better? -----Original Message----- From: Krishna Addepalli Sent: Tuesday, August 14, 2018 8:04 PM To: Ralph Hummeling ; 2d-dev at openjdk.java.net Cc: james.graham at oracle.com Subject: Re: [OpenJDK 2D-Dev] ArcIterator#btan(double) I guess you would already have the code checked out? It is just a matter of updating the comments explaining how sin(a/2) / (1 + cos(a/2)) is equal to tan(a/4), and then change it in the code. I think you would need a test along with it. Thanks, Krishna -----Original Message----- From: Ralph Hummeling Sent: Tuesday, August 14, 2018 7:59 PM To: Krishna Addepalli ; 2d-dev at openjdk.java.net Cc: james.graham at oracle.com Subject: Re: [OpenJDK 2D-Dev] ArcIterator#btan(double) Dear Krishna, I'd love to. How do I best do that? Kind regards, Ralph Hummeling +316 5758 1679 Hummeling Engineering BV https://urldefense.proofpoint.com/v2/url?u=http-3A__www.hummeling.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=iFb2N0ZBD0EAiVLz7h0dhj41Ha2uquc9ZM_GpTwq_w8&s=ypabzzNLUNIyzlXJK9-g27W-gz6a1phXmPa771N3ZGU&e= On 13/08/18 08:39, Krishna Addepalli wrote: > Dear Ralph, > > Thanks for pointing this out, could you also come up with a patch for the same? > > Thanks, > Krishna > > -----Original Message----- > From: Ralph Hummeling > Sent: Friday, July 20, 2018 8:25 PM > To: 2d-dev at openjdk.java.net > Cc: james.graham at oracle.com > Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double) > > Dear Java 2D dev team, > > I came across your java.awt.geom.ArcIterator class in which an arc Bezier control point segment length is determined in method btan(double). You arrive at the following equation: > 4/3*(1 - cos(a/2))/(sin(a/2)) > > It is mentioned that this can return NaN for small "a" and so it is written as: > 4/3*(sin(a/2))/(1 + cos(a/2)) > > Please note that this relation can also be written as follows: > 4/3*tan(a/4) > > A performance increase and no NaN issues ;-) > > > Kind regards, > > Ralph Hummeling > +316 5758 1679 > Hummeling Engineering BV > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.hummeling.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=iFb2N0ZBD0EAiVLz7h0dhj41Ha2uquc9ZM_GpTwq_w8&s=ypabzzNLUNIyzlXJK9-g27W-gz6a1phXmPa771N3ZGU&e= > From engineering at hummeling.com Tue Aug 14 14:42:39 2018 From: engineering at hummeling.com (Ralph Hummeling) Date: Tue, 14 Aug 2018 16:42:39 +0200 Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double) In-Reply-To: <96443609-380b-429b-b06f-00eabc736a93@default> References: <5c6de6b53bb233009fa9216a445abcc3@hummeling.com> <3bb09ccc-f1e1-e6d0-9dad-9937d99099d3@hummeling.com> <96443609-380b-429b-b06f-00eabc736a93@default> Message-ID: No problem. Indeed, it's about the process of actually submitting a patch: where's your repo, on what branch, etc. I know how to use SVN and Git. Kind regards, Ralph Hummeling +316 5758 1679 Hummeling Engineering BV www.hummeling.com On 14/08/18 16:38, Krishna Addepalli wrote: > Sorry, I replied assuming certain things before actually clarifying. > Are you asking about the process for submitting a patch? Could you be a bit more specific so that I can answer better? > > -----Original Message----- > From: Krishna Addepalli > Sent: Tuesday, August 14, 2018 8:04 PM > To: Ralph Hummeling ; 2d-dev at openjdk.java.net > Cc: james.graham at oracle.com > Subject: Re: [OpenJDK 2D-Dev] ArcIterator#btan(double) > > I guess you would already have the code checked out? It is just a matter of updating the comments explaining how sin(a/2) / (1 + cos(a/2)) is equal to tan(a/4), and then change it in the code. > I think you would need a test along with it. > > Thanks, > Krishna > > -----Original Message----- > From: Ralph Hummeling > Sent: Tuesday, August 14, 2018 7:59 PM > To: Krishna Addepalli ; 2d-dev at openjdk.java.net > Cc: james.graham at oracle.com > Subject: Re: [OpenJDK 2D-Dev] ArcIterator#btan(double) > > Dear Krishna, > > I'd love to. How do I best do that? > > > Kind regards, > > Ralph Hummeling > +316 5758 1679 > Hummeling Engineering BV > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.hummeling.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=iFb2N0ZBD0EAiVLz7h0dhj41Ha2uquc9ZM_GpTwq_w8&s=ypabzzNLUNIyzlXJK9-g27W-gz6a1phXmPa771N3ZGU&e= > > On 13/08/18 08:39, Krishna Addepalli wrote: >> Dear Ralph, >> >> Thanks for pointing this out, could you also come up with a patch for the same? >> >> Thanks, >> Krishna >> >> -----Original Message----- >> From: Ralph Hummeling >> Sent: Friday, July 20, 2018 8:25 PM >> To: 2d-dev at openjdk.java.net >> Cc: james.graham at oracle.com >> Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double) >> >> Dear Java 2D dev team, >> >> I came across your java.awt.geom.ArcIterator class in which an arc Bezier control point segment length is determined in method btan(double). You arrive at the following equation: >> 4/3*(1 - cos(a/2))/(sin(a/2)) >> >> It is mentioned that this can return NaN for small "a" and so it is written as: >> 4/3*(sin(a/2))/(1 + cos(a/2)) >> >> Please note that this relation can also be written as follows: >> 4/3*tan(a/4) >> >> A performance increase and no NaN issues ;-) >> >> >> Kind regards, >> >> Ralph Hummeling >> +316 5758 1679 >> Hummeling Engineering BV >> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.hummeling.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=iFb2N0ZBD0EAiVLz7h0dhj41Ha2uquc9ZM_GpTwq_w8&s=ypabzzNLUNIyzlXJK9-g27W-gz6a1phXmPa771N3ZGU&e= >> From brian.burkhalter at oracle.com Tue Aug 14 15:39:54 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 14 Aug 2018 08:39:54 -0700 Subject: [OpenJDK 2D-Dev] ArcIterator#btan(double) In-Reply-To: References: <5c6de6b53bb233009fa9216a445abcc3@hummeling.com> <3bb09ccc-f1e1-e6d0-9dad-9937d99099d3@hummeling.com> <96443609-380b-429b-b06f-00eabc736a93@default> Message-ID: Hello, Background: http://openjdk.java.net/contribute/ http://openjdk.java.net/guide/ SCM repository: http://hg.openjdk.java.net/jdk/jdk Thanks, Brian On Aug 14, 2018, at 7:42 AM, Ralph Hummeling wrote: > No problem. Indeed, it's about the process of actually submitting a patch: where's your repo, on what branch, etc. > I know how to use SVN and Git. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.litvinov at oracle.com Fri Aug 17 19:42:34 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Fri, 17 Aug 2018 20:42:34 +0100 Subject: [OpenJDK 2D-Dev] [12] Review request for 8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object Message-ID: <5a09bce7-fa3d-b87f-a746-425423b13a6a@oracle.com> Hello, Could you please review the following fix for the bug. Bug: https://bugs.openjdk.java.net/browse/JDK-8201818 Webrev: http://cr.openjdk.java.net/~alitvinov/8201818/jdk12/webrev.00 The bug consists in the fact that, if any one printing attribute is contained in "PrintRequestAttributeSet" during the call to "java.awt.print.PrinterJob.print(PrintRequestAttributeSet)" method, a page size from "java.awt.print.PageFormat" object provided by "java.awt.print.Book" set to a printer job through "PrinterJob.setPageable(Pageable)" method is not respected and the printer job prints the document on a page of a size equal to a default page size of a selected printer. CAUSE OF THE BUG: The root cause of the bug is "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" method which returns "PageFormat" object constructed from default settings of the selected printer, if the attribute set in the printer job is not empty. For the case in this bug, when the user explicitly sets "Book" object for the printer job, this method should not return anything except for "null", because: 1. According to the documentation for the method "PrinterJob.print(PrintRequestAttributeSet)" from Java Platform SE 8 API Specification, if a user sets "java.awt.print.Pageable" object for "PrinterJob", then printing attributes related to media size, imageable area, page orientation will not influence anyhow the "PageFormat" object used for printing, and only "PageFormat" provided by the "Pageable" object will be used. Statement: "For clients of the Pageable interface, the PageFormat will always be as supplied by that interface, on a per page basis." Specification URL #1: https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet- 2. Documentation on the method "PrinterJob.printDialog(PrintRequestAttributeSet)" acknowledges the point #1 by the statement "If using the Pageable interface, clients which intend to use media selected by the user must create a PageFormat derived from the user's selections.". Specification URL #2: https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#printDialog-javax.print.attribute.PrintRequestAttributeSet- THE SOLUTION: The solution consists in changing the method "RasterPrinterJob.getPageFormatFromAttributes()" to return "null" for cases, when the "Pageable" object set in the printer job is not an instance of "sun.print.OpenBook" class, which is exclusively used by the printer job to wrap "Printable" object set by the user through "PrinterJob.setPrintable(Printable)". The fix affects only macOS platform, because "RasterPrinterJob.getPageFormatFromAttributes()" method is called only from the macOS specific native code in the file "src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m". Thank you, Anton From philip.race at oracle.com Mon Aug 20 23:37:44 2018 From: philip.race at oracle.com (Philip Race) Date: Mon, 20 Aug 2018 16:37:44 -0700 Subject: [OpenJDK 2D-Dev] [12] Review request for 8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object In-Reply-To: <5a09bce7-fa3d-b87f-a746-425423b13a6a@oracle.com> References: <5a09bce7-fa3d-b87f-a746-425423b13a6a@oracle.com> Message-ID: <5B7B50C8.8050501@oracle.com> Hi, The fix looks reasonable. But we've touched the code being touched here quite recently and the history there shows that this can be tricky to get right : 8167102: [macosx] PrintRequestAttributeSet breaks page size set using PageFormat caused 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs on macOS so then we had 8181659: Create an alternative fix for JDK-8167102, whose fix was backed out Is this new bug a regression caused by the previous fix ? Have you verified the previous fix is still functional ? What tests have been run ? Can you make sure this works in the cases of a) no dialog b) swing dialog c) native dialog. -phil. On 8/17/18, 12:42 PM, Anton Litvinov wrote: > Hello, > > Could you please review the following fix for the bug. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201818 > Webrev: http://cr.openjdk.java.net/~alitvinov/8201818/jdk12/webrev.00 > > The bug consists in the fact that, if any one printing attribute is > contained in "PrintRequestAttributeSet" during the call to > "java.awt.print.PrinterJob.print(PrintRequestAttributeSet)" method, a > page size from "java.awt.print.PageFormat" object provided by > "java.awt.print.Book" set to a printer job through > "PrinterJob.setPageable(Pageable)" method is not respected and the > printer job prints the document on a page of a size equal to a default > page size of a selected printer. > > CAUSE OF THE BUG: > The root cause of the bug is > "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" method > which returns "PageFormat" object constructed from default settings of > the selected printer, if the attribute set in the printer job is not > empty. For the case in this bug, when the user explicitly sets "Book" > object for the printer job, this method should not return anything > except for "null", because: > > 1. According to the documentation for the method > "PrinterJob.print(PrintRequestAttributeSet)" from Java Platform SE 8 > API Specification, if a user sets "java.awt.print.Pageable" object for > "PrinterJob", then printing attributes related to media size, > imageable area, page orientation will not influence anyhow the > "PageFormat" object used for printing, and only "PageFormat" provided > by the "Pageable" object will be used. > Statement: "For clients of the Pageable interface, the PageFormat will > always be as supplied by that interface, on a per page basis." > Specification URL #1: > https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet- > > 2. Documentation on the method > "PrinterJob.printDialog(PrintRequestAttributeSet)" acknowledges the > point #1 by the statement "If using the Pageable interface, clients > which intend to use media selected by the user must create a > PageFormat derived from the user's selections.". > Specification URL #2: > https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#printDialog-javax.print.attribute.PrintRequestAttributeSet- > > THE SOLUTION: > The solution consists in changing the method > "RasterPrinterJob.getPageFormatFromAttributes()" to return "null" for > cases, when the "Pageable" object set in the printer job is not an > instance of "sun.print.OpenBook" class, which is exclusively used by > the printer job to wrap "Printable" object set by the user through > "PrinterJob.setPrintable(Printable)". > > The fix affects only macOS platform, because > "RasterPrinterJob.getPageFormatFromAttributes()" method is called only > from the macOS specific native code in the file > "src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m". > > Thank you, > Anton From anton.litvinov at oracle.com Wed Aug 22 18:59:35 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Wed, 22 Aug 2018 19:59:35 +0100 Subject: [OpenJDK 2D-Dev] [12] Review request for 8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object In-Reply-To: <5B7B50C8.8050501@oracle.com> References: <5a09bce7-fa3d-b87f-a746-425423b13a6a@oracle.com> <5B7B50C8.8050501@oracle.com> Message-ID: Hello Phil, Thank you for review of this fix. It is correct, this code area was already touched by 3 fixes which you specified, but they are just 2 attempts to fix the same issue and 1 rollback of the 1st fix, which was dictated by the fact that at that time JDK 9 passed RDP 1. Answers to your questions are following: 1.? No, absolutely, this bug is not a regression from the fix for 8181659. This bug exists in JDK for a long time, this is proved by the fact that I was able to reproduce it with JDK 8u112 b16, while the fix for 8167102 was never released in GA JDK 8 update, except for 1 released build JDK 8u131 b32. I consider this bug as an independent issue from 8167102, because of a difference in a test scenario (in 8167102 "java.awt.print.Printable" interface is involved, in this bug "java.awt.print.Pageable" interface is involved), but at the same time they both have the same root cause. The end user, which reported 8167102 changed conditions by moving its application from setting "Printable" object to a printer job to setting "Pageable" object ("java.awt.print.Book") and encountered this issue. 2.? Yes, sure, I verified that the bug 8167102 is still not reproducible with this fix by using the existing "jtreg" regression test "test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java". 3.? Today I have run all available "jtreg" manual and automatic regression tests in the directories specified below and in our closed directories (total 189 tests) using both JDK 12 compiled without and with the fix, and verified that no new test failed on JDK 12 with the fix. Directories with the executed regression tests: - "test/jdk/java/awt/print" - "test/jdk/javax/print" 4. Yes, I verified that the fix works as expected for specified by you 3 cases: a)? no print dialog - attached to the bug record test case "PrintingAttributeBreaksBookPageSize.java" b)? native print dialog - the created regression test "test/jdk/java/awt/print/PageFormat/WrongPaperForBookPrintingTest.java" c)? swing print dialog - the regression test in point #b with modification in 1 line. Thank you, Anton On 21/08/2018 00:37, Philip Race wrote: > Hi, > > The fix looks reasonable. > But we've touched the code being touched here quite recently and the > history > there shows that this can be tricky to get right : > 8167102: [macosx] PrintRequestAttributeSet breaks page size set using > PageFormat > caused > 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs on macOS > so then we had > 8181659: Create an alternative fix for JDK-8167102, whose fix was > backed out > > Is this new bug a regression caused by the previous fix ? > Have you verified the previous fix is still functional ? > What tests have been run ? > Can you make sure this works in the cases of > a) no dialog > b) swing dialog > c) native dialog. > > -phil. > > On 8/17/18, 12:42 PM, Anton Litvinov wrote: >> Hello, >> >> Could you please review the following fix for the bug. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8201818 >> Webrev: http://cr.openjdk.java.net/~alitvinov/8201818/jdk12/webrev.00 >> >> The bug consists in the fact that, if any one printing attribute is >> contained in "PrintRequestAttributeSet" during the call to >> "java.awt.print.PrinterJob.print(PrintRequestAttributeSet)" method, a >> page size from "java.awt.print.PageFormat" object provided by >> "java.awt.print.Book" set to a printer job through >> "PrinterJob.setPageable(Pageable)" method is not respected and the >> printer job prints the document on a page of a size equal to a >> default page size of a selected printer. >> >> CAUSE OF THE BUG: >> The root cause of the bug is >> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" method >> which returns "PageFormat" object constructed from default settings >> of the selected printer, if the attribute set in the printer job is >> not empty. For the case in this bug, when the user explicitly sets >> "Book" object for the printer job, this method should not return >> anything except for "null", because: >> >> 1. According to the documentation for the method >> "PrinterJob.print(PrintRequestAttributeSet)" from Java Platform SE 8 >> API Specification, if a user sets "java.awt.print.Pageable" object >> for "PrinterJob", then printing attributes related to media size, >> imageable area, page orientation will not influence anyhow the >> "PageFormat" object used for printing, and only "PageFormat" provided >> by the "Pageable" object will be used. >> Statement: "For clients of the Pageable interface, the PageFormat >> will always be as supplied by that interface, on a per page basis." >> Specification URL #1: >> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet- >> >> 2. Documentation on the method >> "PrinterJob.printDialog(PrintRequestAttributeSet)" acknowledges the >> point #1 by the statement "If using the Pageable interface, clients >> which intend to use media selected by the user must create a >> PageFormat derived from the user's selections.". >> Specification URL #2: >> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#printDialog-javax.print.attribute.PrintRequestAttributeSet- >> >> THE SOLUTION: >> The solution consists in changing the method >> "RasterPrinterJob.getPageFormatFromAttributes()" to return "null" for >> cases, when the "Pageable" object set in the printer job is not an >> instance of "sun.print.OpenBook" class, which is exclusively used by >> the printer job to wrap "Printable" object set by the user through >> "PrinterJob.setPrintable(Printable)". >> >> The fix affects only macOS platform, because >> "RasterPrinterJob.getPageFormatFromAttributes()" method is called >> only from the macOS specific native code in the file >> "src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m". >> >> Thank you, >> Anton From prasanta.sadhukhan at oracle.com Thu Aug 23 05:40:15 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 23 Aug 2018 11:10:15 +0530 Subject: [OpenJDK 2D-Dev] [12] Review request for 8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object In-Reply-To: References: <5a09bce7-fa3d-b87f-a746-425423b13a6a@oracle.com> <5B7B50C8.8050501@oracle.com> Message-ID: Hi Anton, One thing I would like to know..since you told this fix will only affects macOS platform, did you check if this is not reproducible in windows or linux, if not why? If yes, then maybe we should put the fix in more generic place!! Regards Prasanta On 8/23/2018 12:29 AM, Anton Litvinov wrote: > Hello Phil, > > Thank you for review of this fix. It is correct, this code area was > already touched by 3 fixes which you specified, but they are just 2 > attempts to fix the same issue and 1 rollback of the 1st fix, which > was dictated by the fact that at that time JDK 9 passed RDP 1. Answers > to your questions are following: > > 1.? No, absolutely, this bug is not a regression from the fix for > 8181659. This bug exists in JDK for a long time, this is proved by the > fact that I was able to reproduce it with JDK 8u112 b16, while the fix > for 8167102 was never released in GA JDK 8 update, except for 1 > released build JDK 8u131 b32. I consider this bug as an independent > issue from 8167102, because of a difference in a test scenario (in > 8167102 "java.awt.print.Printable" interface is involved, in this bug > "java.awt.print.Pageable" interface is involved), but at the same time > they both have the same root cause. The end user, which reported > 8167102 changed conditions by moving its application from setting > "Printable" object to a printer job to setting "Pageable" object > ("java.awt.print.Book") and encountered this issue. > > 2.? Yes, sure, I verified that the bug 8167102 is still not > reproducible with this fix by using the existing "jtreg" regression > test "test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java". > > 3.? Today I have run all available "jtreg" manual and automatic > regression tests in the directories specified below and in our closed > directories (total 189 tests) using both JDK 12 compiled without and > with the fix, and verified that no new test failed on JDK 12 with the > fix. > > Directories with the executed regression tests: > - "test/jdk/java/awt/print" > - "test/jdk/javax/print" > > 4. Yes, I verified that the fix works as expected for specified by you > 3 cases: > a)? no print dialog - attached to the bug record test case > "PrintingAttributeBreaksBookPageSize.java" > b)? native print dialog - the created regression test > "test/jdk/java/awt/print/PageFormat/WrongPaperForBookPrintingTest.java" > c)? swing print dialog - the regression test in point #b with > modification in 1 line. > > Thank you, > Anton > > On 21/08/2018 00:37, Philip Race wrote: >> Hi, >> >> The fix looks reasonable. >> But we've touched the code being touched here quite recently and the >> history >> there shows that this can be tricky to get right : >> 8167102: [macosx] PrintRequestAttributeSet breaks page size set using >> PageFormat >> caused >> 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs on >> macOS >> so then we had >> 8181659: Create an alternative fix for JDK-8167102, whose fix was >> backed out >> >> Is this new bug a regression caused by the previous fix ? >> Have you verified the previous fix is still functional ? >> What tests have been run ? >> Can you make sure this works in the cases of >> a) no dialog >> b) swing dialog >> c) native dialog. >> >> -phil. >> >> On 8/17/18, 12:42 PM, Anton Litvinov wrote: >>> Hello, >>> >>> Could you please review the following fix for the bug. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201818 >>> Webrev: http://cr.openjdk.java.net/~alitvinov/8201818/jdk12/webrev.00 >>> >>> The bug consists in the fact that, if any one printing attribute is >>> contained in "PrintRequestAttributeSet" during the call to >>> "java.awt.print.PrinterJob.print(PrintRequestAttributeSet)" method, >>> a page size from "java.awt.print.PageFormat" object provided by >>> "java.awt.print.Book" set to a printer job through >>> "PrinterJob.setPageable(Pageable)" method is not respected and the >>> printer job prints the document on a page of a size equal to a >>> default page size of a selected printer. >>> >>> CAUSE OF THE BUG: >>> The root cause of the bug is >>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" method >>> which returns "PageFormat" object constructed from default settings >>> of the selected printer, if the attribute set in the printer job is >>> not empty. For the case in this bug, when the user explicitly sets >>> "Book" object for the printer job, this method should not return >>> anything except for "null", because: >>> >>> 1. According to the documentation for the method >>> "PrinterJob.print(PrintRequestAttributeSet)" from Java Platform SE 8 >>> API Specification, if a user sets "java.awt.print.Pageable" object >>> for "PrinterJob", then printing attributes related to media size, >>> imageable area, page orientation will not influence anyhow the >>> "PageFormat" object used for printing, and only "PageFormat" >>> provided by the "Pageable" object will be used. >>> Statement: "For clients of the Pageable interface, the PageFormat >>> will always be as supplied by that interface, on a per page basis." >>> Specification URL #1: >>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet- >>> >>> 2. Documentation on the method >>> "PrinterJob.printDialog(PrintRequestAttributeSet)" acknowledges the >>> point #1 by the statement "If using the Pageable interface, clients >>> which intend to use media selected by the user must create a >>> PageFormat derived from the user's selections.". >>> Specification URL #2: >>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#printDialog-javax.print.attribute.PrintRequestAttributeSet- >>> >>> THE SOLUTION: >>> The solution consists in changing the method >>> "RasterPrinterJob.getPageFormatFromAttributes()" to return "null" >>> for cases, when the "Pageable" object set in the printer job is not >>> an instance of "sun.print.OpenBook" class, which is exclusively used >>> by the printer job to wrap "Printable" object set by the user >>> through "PrinterJob.setPrintable(Printable)". >>> >>> The fix affects only macOS platform, because >>> "RasterPrinterJob.getPageFormatFromAttributes()" method is called >>> only from the macOS specific native code in the file >>> "src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m". >>> >>> Thank you, >>> Anton > From anton.litvinov at oracle.com Thu Aug 23 15:32:28 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Thu, 23 Aug 2018 16:32:28 +0100 Subject: [OpenJDK 2D-Dev] [12] Review request for 8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object In-Reply-To: References: <5a09bce7-fa3d-b87f-a746-425423b13a6a@oracle.com> <5B7B50C8.8050501@oracle.com> Message-ID: <790ef595-31d1-f0eb-5c05-ed1a12244d6b@oracle.com> Hello Prasanta, By your explicit request today I have verified and confirm that the bug is not reproducible on MS Windows 10 OS, Linux Ubuntu 16.04.2 x86_64 OS with JDK 11+28, therefore I confirm again that this bug is macOS specific. The root cause of the issue is described in my review request, I do not see a big reason to accomplish and provide here detailed comparisons of how printing area code related to this issue is implemented on all supported platforms; code for Windows, Linux, macOS platforms has differences. This fix is for this specific bug in macOS implementation of JDK. The bug is not reproducible on Windows and Linux, simply because JDK code for Windows, Linux does not involve calling the method "RasterPrinterJob.getPageFormatFromAttributes()". I do not want to alter any generic code under this bug record to address macOS specific issue, it will be certainly more error prone. Thank you, Anton On 23/08/2018 06:40, Prasanta Sadhukhan wrote: > Hi Anton, > > One thing I would like to know..since you told this fix will only > affects macOS platform, did you check if this is not reproducible in > windows or linux, if not why? If yes, then maybe we should put the fix > in more generic place!! > > Regards > Prasanta > On 8/23/2018 12:29 AM, Anton Litvinov wrote: >> Hello Phil, >> >> Thank you for review of this fix. It is correct, this code area was >> already touched by 3 fixes which you specified, but they are just 2 >> attempts to fix the same issue and 1 rollback of the 1st fix, which >> was dictated by the fact that at that time JDK 9 passed RDP 1. >> Answers to your questions are following: >> >> 1.? No, absolutely, this bug is not a regression from the fix for >> 8181659. This bug exists in JDK for a long time, this is proved by >> the fact that I was able to reproduce it with JDK 8u112 b16, while >> the fix for 8167102 was never released in GA JDK 8 update, except for >> 1 released build JDK 8u131 b32. I consider this bug as an independent >> issue from 8167102, because of a difference in a test scenario (in >> 8167102 "java.awt.print.Printable" interface is involved, in this bug >> "java.awt.print.Pageable" interface is involved), but at the same >> time they both have the same root cause. The end user, which reported >> 8167102 changed conditions by moving its application from setting >> "Printable" object to a printer job to setting "Pageable" object >> ("java.awt.print.Book") and encountered this issue. >> >> 2.? Yes, sure, I verified that the bug 8167102 is still not >> reproducible with this fix by using the existing "jtreg" regression >> test "test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java". >> >> 3.? Today I have run all available "jtreg" manual and automatic >> regression tests in the directories specified below and in our closed >> directories (total 189 tests) using both JDK 12 compiled without and >> with the fix, and verified that no new test failed on JDK 12 with the >> fix. >> >> Directories with the executed regression tests: >> - "test/jdk/java/awt/print" >> - "test/jdk/javax/print" >> >> 4. Yes, I verified that the fix works as expected for specified by >> you 3 cases: >> a)? no print dialog - attached to the bug record test case >> "PrintingAttributeBreaksBookPageSize.java" >> b)? native print dialog - the created regression test >> "test/jdk/java/awt/print/PageFormat/WrongPaperForBookPrintingTest.java" >> c)? swing print dialog - the regression test in point #b with >> modification in 1 line. >> >> Thank you, >> Anton >> >> On 21/08/2018 00:37, Philip Race wrote: >>> Hi, >>> >>> The fix looks reasonable. >>> But we've touched the code being touched here quite recently and the >>> history >>> there shows that this can be tricky to get right : >>> 8167102: [macosx] PrintRequestAttributeSet breaks page size set >>> using PageFormat >>> caused >>> 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs on >>> macOS >>> so then we had >>> 8181659: Create an alternative fix for JDK-8167102, whose fix was >>> backed out >>> >>> Is this new bug a regression caused by the previous fix ? >>> Have you verified the previous fix is still functional ? >>> What tests have been run ? >>> Can you make sure this works in the cases of >>> a) no dialog >>> b) swing dialog >>> c) native dialog. >>> >>> -phil. >>> >>> On 8/17/18, 12:42 PM, Anton Litvinov wrote: >>>> Hello, >>>> >>>> Could you please review the following fix for the bug. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201818 >>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8201818/jdk12/webrev.00 >>>> >>>> The bug consists in the fact that, if any one printing attribute is >>>> contained in "PrintRequestAttributeSet" during the call to >>>> "java.awt.print.PrinterJob.print(PrintRequestAttributeSet)" method, >>>> a page size from "java.awt.print.PageFormat" object provided by >>>> "java.awt.print.Book" set to a printer job through >>>> "PrinterJob.setPageable(Pageable)" method is not respected and the >>>> printer job prints the document on a page of a size equal to a >>>> default page size of a selected printer. >>>> >>>> CAUSE OF THE BUG: >>>> The root cause of the bug is >>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" method >>>> which returns "PageFormat" object constructed from default settings >>>> of the selected printer, if the attribute set in the printer job is >>>> not empty. For the case in this bug, when the user explicitly sets >>>> "Book" object for the printer job, this method should not return >>>> anything except for "null", because: >>>> >>>> 1. According to the documentation for the method >>>> "PrinterJob.print(PrintRequestAttributeSet)" from Java Platform SE >>>> 8 API Specification, if a user sets "java.awt.print.Pageable" >>>> object for "PrinterJob", then printing attributes related to media >>>> size, imageable area, page orientation will not influence anyhow >>>> the "PageFormat" object used for printing, and only "PageFormat" >>>> provided by the "Pageable" object will be used. >>>> Statement: "For clients of the Pageable interface, the PageFormat >>>> will always be as supplied by that interface, on a per page basis." >>>> Specification URL #1: >>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet- >>>> >>>> 2. Documentation on the method >>>> "PrinterJob.printDialog(PrintRequestAttributeSet)" acknowledges the >>>> point #1 by the statement "If using the Pageable interface, clients >>>> which intend to use media selected by the user must create a >>>> PageFormat derived from the user's selections.". >>>> Specification URL #2: >>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#printDialog-javax.print.attribute.PrintRequestAttributeSet- >>>> >>>> THE SOLUTION: >>>> The solution consists in changing the method >>>> "RasterPrinterJob.getPageFormatFromAttributes()" to return "null" >>>> for cases, when the "Pageable" object set in the printer job is not >>>> an instance of "sun.print.OpenBook" class, which is exclusively >>>> used by the printer job to wrap "Printable" object set by the user >>>> through "PrinterJob.setPrintable(Printable)". >>>> >>>> The fix affects only macOS platform, because >>>> "RasterPrinterJob.getPageFormatFromAttributes()" method is called >>>> only from the macOS specific native code in the file >>>> "src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m". >>>> >>>> Thank you, >>>> Anton >> > From anton.litvinov at oracle.com Thu Aug 23 15:33:50 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Thu, 23 Aug 2018 16:33:50 +0100 Subject: [OpenJDK 2D-Dev] [12] Review request for 8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object In-Reply-To: References: <5a09bce7-fa3d-b87f-a746-425423b13a6a@oracle.com> <5B7B50C8.8050501@oracle.com> Message-ID: <4d1261b3-ab8e-634f-9094-e0a1ca4628b0@oracle.com> Hello Phil, Do you approve this version of the fix? Thank you, Anton On 22/08/2018 19:59, Anton Litvinov wrote: > Hello Phil, > > Thank you for review of this fix. It is correct, this code area was > already touched by 3 fixes which you specified, but they are just 2 > attempts to fix the same issue and 1 rollback of the 1st fix, which > was dictated by the fact that at that time JDK 9 passed RDP 1. Answers > to your questions are following: > > 1.? No, absolutely, this bug is not a regression from the fix for > 8181659. This bug exists in JDK for a long time, this is proved by the > fact that I was able to reproduce it with JDK 8u112 b16, while the fix > for 8167102 was never released in GA JDK 8 update, except for 1 > released build JDK 8u131 b32. I consider this bug as an independent > issue from 8167102, because of a difference in a test scenario (in > 8167102 "java.awt.print.Printable" interface is involved, in this bug > "java.awt.print.Pageable" interface is involved), but at the same time > they both have the same root cause. The end user, which reported > 8167102 changed conditions by moving its application from setting > "Printable" object to a printer job to setting "Pageable" object > ("java.awt.print.Book") and encountered this issue. > > 2.? Yes, sure, I verified that the bug 8167102 is still not > reproducible with this fix by using the existing "jtreg" regression > test "test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java". > > 3.? Today I have run all available "jtreg" manual and automatic > regression tests in the directories specified below and in our closed > directories (total 189 tests) using both JDK 12 compiled without and > with the fix, and verified that no new test failed on JDK 12 with the > fix. > > Directories with the executed regression tests: > - "test/jdk/java/awt/print" > - "test/jdk/javax/print" > > 4. Yes, I verified that the fix works as expected for specified by you > 3 cases: > a)? no print dialog - attached to the bug record test case > "PrintingAttributeBreaksBookPageSize.java" > b)? native print dialog - the created regression test > "test/jdk/java/awt/print/PageFormat/WrongPaperForBookPrintingTest.java" > c)? swing print dialog - the regression test in point #b with > modification in 1 line. > > Thank you, > Anton > > On 21/08/2018 00:37, Philip Race wrote: >> Hi, >> >> The fix looks reasonable. >> But we've touched the code being touched here quite recently and the >> history >> there shows that this can be tricky to get right : >> 8167102: [macosx] PrintRequestAttributeSet breaks page size set using >> PageFormat >> caused >> 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs on >> macOS >> so then we had >> 8181659: Create an alternative fix for JDK-8167102, whose fix was >> backed out >> >> Is this new bug a regression caused by the previous fix ? >> Have you verified the previous fix is still functional ? >> What tests have been run ? >> Can you make sure this works in the cases of >> a) no dialog >> b) swing dialog >> c) native dialog. >> >> -phil. >> >> On 8/17/18, 12:42 PM, Anton Litvinov wrote: >>> Hello, >>> >>> Could you please review the following fix for the bug. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201818 >>> Webrev: http://cr.openjdk.java.net/~alitvinov/8201818/jdk12/webrev.00 >>> >>> The bug consists in the fact that, if any one printing attribute is >>> contained in "PrintRequestAttributeSet" during the call to >>> "java.awt.print.PrinterJob.print(PrintRequestAttributeSet)" method, >>> a page size from "java.awt.print.PageFormat" object provided by >>> "java.awt.print.Book" set to a printer job through >>> "PrinterJob.setPageable(Pageable)" method is not respected and the >>> printer job prints the document on a page of a size equal to a >>> default page size of a selected printer. >>> >>> CAUSE OF THE BUG: >>> The root cause of the bug is >>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" method >>> which returns "PageFormat" object constructed from default settings >>> of the selected printer, if the attribute set in the printer job is >>> not empty. For the case in this bug, when the user explicitly sets >>> "Book" object for the printer job, this method should not return >>> anything except for "null", because: >>> >>> 1. According to the documentation for the method >>> "PrinterJob.print(PrintRequestAttributeSet)" from Java Platform SE 8 >>> API Specification, if a user sets "java.awt.print.Pageable" object >>> for "PrinterJob", then printing attributes related to media size, >>> imageable area, page orientation will not influence anyhow the >>> "PageFormat" object used for printing, and only "PageFormat" >>> provided by the "Pageable" object will be used. >>> Statement: "For clients of the Pageable interface, the PageFormat >>> will always be as supplied by that interface, on a per page basis." >>> Specification URL #1: >>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet- >>> >>> 2. Documentation on the method >>> "PrinterJob.printDialog(PrintRequestAttributeSet)" acknowledges the >>> point #1 by the statement "If using the Pageable interface, clients >>> which intend to use media selected by the user must create a >>> PageFormat derived from the user's selections.". >>> Specification URL #2: >>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#printDialog-javax.print.attribute.PrintRequestAttributeSet- >>> >>> THE SOLUTION: >>> The solution consists in changing the method >>> "RasterPrinterJob.getPageFormatFromAttributes()" to return "null" >>> for cases, when the "Pageable" object set in the printer job is not >>> an instance of "sun.print.OpenBook" class, which is exclusively used >>> by the printer job to wrap "Printable" object set by the user >>> through "PrinterJob.setPrintable(Printable)". >>> >>> The fix affects only macOS platform, because >>> "RasterPrinterJob.getPageFormatFromAttributes()" method is called >>> only from the macOS specific native code in the file >>> "src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m". >>> >>> Thank you, >>> Anton > From anton.litvinov at oracle.com Thu Aug 23 16:19:40 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Thu, 23 Aug 2018 17:19:40 +0100 Subject: [OpenJDK 2D-Dev] [12] Review request for 8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object In-Reply-To: <790ef595-31d1-f0eb-5c05-ed1a12244d6b@oracle.com> References: <5a09bce7-fa3d-b87f-a746-425423b13a6a@oracle.com> <5B7B50C8.8050501@oracle.com> <790ef595-31d1-f0eb-5c05-ed1a12244d6b@oracle.com> Message-ID: <19806eb4-8b2a-b542-c633-26ab45c65fe3@oracle.com> I am sorry for an additional e-mail. In the previous e-mail I forgot to specify, that during the experiment not only JDK 11+28 was used, but also JDK 8u181 b13 was used. The correction in the first sentence below is marked with the bold font style. On 23/08/2018 16:32, Anton Litvinov wrote: > Hello Prasanta, > > By your explicit request today I have verified and confirm that the > bug is not reproducible on MS Windows 10 OS, Linux Ubuntu 16.04.2 > x86_64 OS with JDK 11+28*, JDK 8u181 b13*, therefore I confirm again > that this bug is macOS specific. > > The root cause of the issue is described in my review request, I do > not see a big reason to accomplish and provide here detailed > comparisons of how printing area code related to this issue is > implemented on all supported platforms; code for Windows, Linux, macOS > platforms has differences. This fix is for this specific bug in macOS > implementation of JDK. The bug is not reproducible on Windows and > Linux, simply because JDK code for Windows, Linux does not involve > calling the method "RasterPrinterJob.getPageFormatFromAttributes()". > > I do not want to alter any generic code under this bug record to > address macOS specific issue, it will be certainly more error prone. > > Thank you, > Anton > > On 23/08/2018 06:40, Prasanta Sadhukhan wrote: >> Hi Anton, >> >> One thing I would like to know..since you told this fix will only >> affects macOS platform, did you check if this is not reproducible in >> windows or linux, if not why? If yes, then maybe we should put the >> fix in more generic place!! >> >> Regards >> Prasanta >> On 8/23/2018 12:29 AM, Anton Litvinov wrote: >>> Hello Phil, >>> >>> Thank you for review of this fix. It is correct, this code area was >>> already touched by 3 fixes which you specified, but they are just 2 >>> attempts to fix the same issue and 1 rollback of the 1st fix, which >>> was dictated by the fact that at that time JDK 9 passed RDP 1. >>> Answers to your questions are following: >>> >>> 1.? No, absolutely, this bug is not a regression from the fix for >>> 8181659. This bug exists in JDK for a long time, this is proved by >>> the fact that I was able to reproduce it with JDK 8u112 b16, while >>> the fix for 8167102 was never released in GA JDK 8 update, except >>> for 1 released build JDK 8u131 b32. I consider this bug as an >>> independent issue from 8167102, because of a difference in a test >>> scenario (in 8167102 "java.awt.print.Printable" interface is >>> involved, in this bug "java.awt.print.Pageable" interface is >>> involved), but at the same time they both have the same root cause. >>> The end user, which reported 8167102 changed conditions by moving >>> its application from setting "Printable" object to a printer job to >>> setting "Pageable" object ("java.awt.print.Book") and encountered >>> this issue. >>> >>> 2.? Yes, sure, I verified that the bug 8167102 is still not >>> reproducible with this fix by using the existing "jtreg" regression >>> test "test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java". >>> >>> 3.? Today I have run all available "jtreg" manual and automatic >>> regression tests in the directories specified below and in our >>> closed directories (total 189 tests) using both JDK 12 compiled >>> without and with the fix, and verified that no new test failed on >>> JDK 12 with the fix. >>> >>> Directories with the executed regression tests: >>> - "test/jdk/java/awt/print" >>> - "test/jdk/javax/print" >>> >>> 4. Yes, I verified that the fix works as expected for specified by >>> you 3 cases: >>> a)? no print dialog - attached to the bug record test case >>> "PrintingAttributeBreaksBookPageSize.java" >>> b)? native print dialog - the created regression test >>> "test/jdk/java/awt/print/PageFormat/WrongPaperForBookPrintingTest.java" >>> c)? swing print dialog - the regression test in point #b with >>> modification in 1 line. >>> >>> Thank you, >>> Anton >>> >>> On 21/08/2018 00:37, Philip Race wrote: >>>> Hi, >>>> >>>> The fix looks reasonable. >>>> But we've touched the code being touched here quite recently and >>>> the history >>>> there shows that this can be tricky to get right : >>>> 8167102: [macosx] PrintRequestAttributeSet breaks page size set >>>> using PageFormat >>>> caused >>>> 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs on >>>> macOS >>>> so then we had >>>> 8181659: Create an alternative fix for JDK-8167102, whose fix was >>>> backed out >>>> >>>> Is this new bug a regression caused by the previous fix ? >>>> Have you verified the previous fix is still functional ? >>>> What tests have been run ? >>>> Can you make sure this works in the cases of >>>> a) no dialog >>>> b) swing dialog >>>> c) native dialog. >>>> >>>> -phil. >>>> >>>> On 8/17/18, 12:42 PM, Anton Litvinov wrote: >>>>> Hello, >>>>> >>>>> Could you please review the following fix for the bug. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201818 >>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8201818/jdk12/webrev.00 >>>>> >>>>> The bug consists in the fact that, if any one printing attribute >>>>> is contained in "PrintRequestAttributeSet" during the call to >>>>> "java.awt.print.PrinterJob.print(PrintRequestAttributeSet)" >>>>> method, a page size from "java.awt.print.PageFormat" object >>>>> provided by "java.awt.print.Book" set to a printer job through >>>>> "PrinterJob.setPageable(Pageable)" method is not respected and the >>>>> printer job prints the document on a page of a size equal to a >>>>> default page size of a selected printer. >>>>> >>>>> CAUSE OF THE BUG: >>>>> The root cause of the bug is >>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" method >>>>> which returns "PageFormat" object constructed from default >>>>> settings of the selected printer, if the attribute set in the >>>>> printer job is not empty. For the case in this bug, when the user >>>>> explicitly sets "Book" object for the printer job, this method >>>>> should not return anything except for "null", because: >>>>> >>>>> 1. According to the documentation for the method >>>>> "PrinterJob.print(PrintRequestAttributeSet)" from Java Platform SE >>>>> 8 API Specification, if a user sets "java.awt.print.Pageable" >>>>> object for "PrinterJob", then printing attributes related to media >>>>> size, imageable area, page orientation will not influence anyhow >>>>> the "PageFormat" object used for printing, and only "PageFormat" >>>>> provided by the "Pageable" object will be used. >>>>> Statement: "For clients of the Pageable interface, the PageFormat >>>>> will always be as supplied by that interface, on a per page basis." >>>>> Specification URL #1: >>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet- >>>>> >>>>> 2. Documentation on the method >>>>> "PrinterJob.printDialog(PrintRequestAttributeSet)" acknowledges >>>>> the point #1 by the statement "If using the Pageable interface, >>>>> clients which intend to use media selected by the user must create >>>>> a PageFormat derived from the user's selections.". >>>>> Specification URL #2: >>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#printDialog-javax.print.attribute.PrintRequestAttributeSet- >>>>> >>>>> THE SOLUTION: >>>>> The solution consists in changing the method >>>>> "RasterPrinterJob.getPageFormatFromAttributes()" to return "null" >>>>> for cases, when the "Pageable" object set in the printer job is >>>>> not an instance of "sun.print.OpenBook" class, which is >>>>> exclusively used by the printer job to wrap "Printable" object set >>>>> by the user through "PrinterJob.setPrintable(Printable)". >>>>> >>>>> The fix affects only macOS platform, because >>>>> "RasterPrinterJob.getPageFormatFromAttributes()" method is called >>>>> only from the macOS specific native code in the file >>>>> "src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m". >>>>> >>>>> Thank you, >>>>> Anton >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sun Aug 26 21:11:27 2018 From: philip.race at oracle.com (Philip Race) Date: Sun, 26 Aug 2018 14:11:27 -0700 Subject: [OpenJDK 2D-Dev] [12] Review request for 8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object In-Reply-To: <4d1261b3-ab8e-634f-9094-e0a1ca4628b0@oracle.com> References: <5a09bce7-fa3d-b87f-a746-425423b13a6a@oracle.com> <5B7B50C8.8050501@oracle.com> <4d1261b3-ab8e-634f-9094-e0a1ca4628b0@oracle.com> Message-ID: <5B83177F.40105@oracle.com> Approved. -phil. On 8/23/18, 8:33 AM, Anton Litvinov wrote: > Hello Phil, > > Do you approve this version of the fix? > > Thank you, > Anton > > On 22/08/2018 19:59, Anton Litvinov wrote: >> Hello Phil, >> >> Thank you for review of this fix. It is correct, this code area was >> already touched by 3 fixes which you specified, but they are just 2 >> attempts to fix the same issue and 1 rollback of the 1st fix, which >> was dictated by the fact that at that time JDK 9 passed RDP 1. >> Answers to your questions are following: >> >> 1. No, absolutely, this bug is not a regression from the fix for >> 8181659. This bug exists in JDK for a long time, this is proved by >> the fact that I was able to reproduce it with JDK 8u112 b16, while >> the fix for 8167102 was never released in GA JDK 8 update, except for >> 1 released build JDK 8u131 b32. I consider this bug as an independent >> issue from 8167102, because of a difference in a test scenario (in >> 8167102 "java.awt.print.Printable" interface is involved, in this bug >> "java.awt.print.Pageable" interface is involved), but at the same >> time they both have the same root cause. The end user, which reported >> 8167102 changed conditions by moving its application from setting >> "Printable" object to a printer job to setting "Pageable" object >> ("java.awt.print.Book") and encountered this issue. >> >> 2. Yes, sure, I verified that the bug 8167102 is still not >> reproducible with this fix by using the existing "jtreg" regression >> test "test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java". >> >> 3. Today I have run all available "jtreg" manual and automatic >> regression tests in the directories specified below and in our closed >> directories (total 189 tests) using both JDK 12 compiled without and >> with the fix, and verified that no new test failed on JDK 12 with the >> fix. >> >> Directories with the executed regression tests: >> - "test/jdk/java/awt/print" >> - "test/jdk/javax/print" >> >> 4. Yes, I verified that the fix works as expected for specified by >> you 3 cases: >> a) no print dialog - attached to the bug record test case >> "PrintingAttributeBreaksBookPageSize.java" >> b) native print dialog - the created regression test >> "test/jdk/java/awt/print/PageFormat/WrongPaperForBookPrintingTest.java" >> c) swing print dialog - the regression test in point #b with >> modification in 1 line. >> >> Thank you, >> Anton >> >> On 21/08/2018 00:37, Philip Race wrote: >>> Hi, >>> >>> The fix looks reasonable. >>> But we've touched the code being touched here quite recently and the >>> history >>> there shows that this can be tricky to get right : >>> 8167102: [macosx] PrintRequestAttributeSet breaks page size set >>> using PageFormat >>> caused >>> 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs on >>> macOS >>> so then we had >>> 8181659: Create an alternative fix for JDK-8167102, whose fix was >>> backed out >>> >>> Is this new bug a regression caused by the previous fix ? >>> Have you verified the previous fix is still functional ? >>> What tests have been run ? >>> Can you make sure this works in the cases of >>> a) no dialog >>> b) swing dialog >>> c) native dialog. >>> >>> -phil. >>> >>> On 8/17/18, 12:42 PM, Anton Litvinov wrote: >>>> Hello, >>>> >>>> Could you please review the following fix for the bug. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201818 >>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8201818/jdk12/webrev.00 >>>> >>>> The bug consists in the fact that, if any one printing attribute is >>>> contained in "PrintRequestAttributeSet" during the call to >>>> "java.awt.print.PrinterJob.print(PrintRequestAttributeSet)" method, >>>> a page size from "java.awt.print.PageFormat" object provided by >>>> "java.awt.print.Book" set to a printer job through >>>> "PrinterJob.setPageable(Pageable)" method is not respected and the >>>> printer job prints the document on a page of a size equal to a >>>> default page size of a selected printer. >>>> >>>> CAUSE OF THE BUG: >>>> The root cause of the bug is >>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" method >>>> which returns "PageFormat" object constructed from default settings >>>> of the selected printer, if the attribute set in the printer job is >>>> not empty. For the case in this bug, when the user explicitly sets >>>> "Book" object for the printer job, this method should not return >>>> anything except for "null", because: >>>> >>>> 1. According to the documentation for the method >>>> "PrinterJob.print(PrintRequestAttributeSet)" from Java Platform SE >>>> 8 API Specification, if a user sets "java.awt.print.Pageable" >>>> object for "PrinterJob", then printing attributes related to media >>>> size, imageable area, page orientation will not influence anyhow >>>> the "PageFormat" object used for printing, and only "PageFormat" >>>> provided by the "Pageable" object will be used. >>>> Statement: "For clients of the Pageable interface, the PageFormat >>>> will always be as supplied by that interface, on a per page basis." >>>> Specification URL #1: >>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet- >>>> >>>> 2. Documentation on the method >>>> "PrinterJob.printDialog(PrintRequestAttributeSet)" acknowledges the >>>> point #1 by the statement "If using the Pageable interface, clients >>>> which intend to use media selected by the user must create a >>>> PageFormat derived from the user's selections.". >>>> Specification URL #2: >>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#printDialog-javax.print.attribute.PrintRequestAttributeSet- >>>> >>>> THE SOLUTION: >>>> The solution consists in changing the method >>>> "RasterPrinterJob.getPageFormatFromAttributes()" to return "null" >>>> for cases, when the "Pageable" object set in the printer job is not >>>> an instance of "sun.print.OpenBook" class, which is exclusively >>>> used by the printer job to wrap "Printable" object set by the user >>>> through "PrinterJob.setPrintable(Printable)". >>>> >>>> The fix affects only macOS platform, because >>>> "RasterPrinterJob.getPageFormatFromAttributes()" method is called >>>> only from the macOS specific native code in the file >>>> "src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m". >>>> >>>> Thank you, >>>> Anton >> > From prasanta.sadhukhan at oracle.com Mon Aug 27 07:16:02 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 27 Aug 2018 12:46:02 +0530 Subject: [OpenJDK 2D-Dev] [12] Review request for 8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object In-Reply-To: <19806eb4-8b2a-b542-c633-26ab45c65fe3@oracle.com> References: <5a09bce7-fa3d-b87f-a746-425423b13a6a@oracle.com> <5B7B50C8.8050501@oracle.com> <790ef595-31d1-f0eb-5c05-ed1a12244d6b@oracle.com> <19806eb4-8b2a-b542-c633-26ab45c65fe3@oracle.com> Message-ID: <1d6dde74-b693-3290-5819-6e1c8432504f@oracle.com> looks good to me. Please add @key headful to test before pushing. Regards Prasanta On 8/23/2018 9:49 PM, Anton Litvinov wrote: > I am sorry for an additional e-mail. In the previous e-mail I forgot > to specify, that during the experiment not only JDK 11+28 was used, > but also JDK 8u181 b13 was used. The correction in the first sentence > below is marked with the bold font style. > > On 23/08/2018 16:32, Anton Litvinov wrote: >> Hello Prasanta, >> >> By your explicit request today I have verified and confirm that the >> bug is not reproducible on MS Windows 10 OS, Linux Ubuntu 16.04.2 >> x86_64 OS with JDK 11+28*, JDK 8u181 b13*, therefore I confirm again >> that this bug is macOS specific. >> >> The root cause of the issue is described in my review request, I do >> not see a big reason to accomplish and provide here detailed >> comparisons of how printing area code related to this issue is >> implemented on all supported platforms; code for Windows, Linux, >> macOS platforms has differences. This fix is for this specific bug in >> macOS implementation of JDK. The bug is not reproducible on Windows >> and Linux, simply because JDK code for Windows, Linux does not >> involve calling the method >> "RasterPrinterJob.getPageFormatFromAttributes()". >> >> I do not want to alter any generic code under this bug record to >> address macOS specific issue, it will be certainly more error prone. >> >> Thank you, >> Anton >> >> On 23/08/2018 06:40, Prasanta Sadhukhan wrote: >>> Hi Anton, >>> >>> One thing I would like to know..since you told this fix will only >>> affects macOS platform, did you check if this is not reproducible in >>> windows or linux, if not why? If yes, then maybe we should put the >>> fix in more generic place!! >>> >>> Regards >>> Prasanta >>> On 8/23/2018 12:29 AM, Anton Litvinov wrote: >>>> Hello Phil, >>>> >>>> Thank you for review of this fix. It is correct, this code area was >>>> already touched by 3 fixes which you specified, but they are just 2 >>>> attempts to fix the same issue and 1 rollback of the 1st fix, which >>>> was dictated by the fact that at that time JDK 9 passed RDP 1. >>>> Answers to your questions are following: >>>> >>>> 1.? No, absolutely, this bug is not a regression from the fix for >>>> 8181659. This bug exists in JDK for a long time, this is proved by >>>> the fact that I was able to reproduce it with JDK 8u112 b16, while >>>> the fix for 8167102 was never released in GA JDK 8 update, except >>>> for 1 released build JDK 8u131 b32. I consider this bug as an >>>> independent issue from 8167102, because of a difference in a test >>>> scenario (in 8167102 "java.awt.print.Printable" interface is >>>> involved, in this bug "java.awt.print.Pageable" interface is >>>> involved), but at the same time they both have the same root cause. >>>> The end user, which reported 8167102 changed conditions by moving >>>> its application from setting "Printable" object to a printer job to >>>> setting "Pageable" object ("java.awt.print.Book") and encountered >>>> this issue. >>>> >>>> 2.? Yes, sure, I verified that the bug 8167102 is still not >>>> reproducible with this fix by using the existing "jtreg" regression >>>> test "test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java". >>>> >>>> 3.? Today I have run all available "jtreg" manual and automatic >>>> regression tests in the directories specified below and in our >>>> closed directories (total 189 tests) using both JDK 12 compiled >>>> without and with the fix, and verified that no new test failed on >>>> JDK 12 with the fix. >>>> >>>> Directories with the executed regression tests: >>>> - "test/jdk/java/awt/print" >>>> - "test/jdk/javax/print" >>>> >>>> 4. Yes, I verified that the fix works as expected for specified by >>>> you 3 cases: >>>> a)? no print dialog - attached to the bug record test case >>>> "PrintingAttributeBreaksBookPageSize.java" >>>> b)? native print dialog - the created regression test >>>> "test/jdk/java/awt/print/PageFormat/WrongPaperForBookPrintingTest.java" >>>> >>>> c)? swing print dialog - the regression test in point #b with >>>> modification in 1 line. >>>> >>>> Thank you, >>>> Anton >>>> >>>> On 21/08/2018 00:37, Philip Race wrote: >>>>> Hi, >>>>> >>>>> The fix looks reasonable. >>>>> But we've touched the code being touched here quite recently and >>>>> the history >>>>> there shows that this can be tricky to get right : >>>>> 8167102: [macosx] PrintRequestAttributeSet breaks page size set >>>>> using PageFormat >>>>> caused >>>>> 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs >>>>> on macOS >>>>> so then we had >>>>> 8181659: Create an alternative fix for JDK-8167102, whose fix was >>>>> backed out >>>>> >>>>> Is this new bug a regression caused by the previous fix ? >>>>> Have you verified the previous fix is still functional ? >>>>> What tests have been run ? >>>>> Can you make sure this works in the cases of >>>>> a) no dialog >>>>> b) swing dialog >>>>> c) native dialog. >>>>> >>>>> -phil. >>>>> >>>>> On 8/17/18, 12:42 PM, Anton Litvinov wrote: >>>>>> Hello, >>>>>> >>>>>> Could you please review the following fix for the bug. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201818 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~alitvinov/8201818/jdk12/webrev.00 >>>>>> >>>>>> The bug consists in the fact that, if any one printing attribute >>>>>> is contained in "PrintRequestAttributeSet" during the call to >>>>>> "java.awt.print.PrinterJob.print(PrintRequestAttributeSet)" >>>>>> method, a page size from "java.awt.print.PageFormat" object >>>>>> provided by "java.awt.print.Book" set to a printer job through >>>>>> "PrinterJob.setPageable(Pageable)" method is not respected and >>>>>> the printer job prints the document on a page of a size equal to >>>>>> a default page size of a selected printer. >>>>>> >>>>>> CAUSE OF THE BUG: >>>>>> The root cause of the bug is >>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" method >>>>>> which returns "PageFormat" object constructed from default >>>>>> settings of the selected printer, if the attribute set in the >>>>>> printer job is not empty. For the case in this bug, when the user >>>>>> explicitly sets "Book" object for the printer job, this method >>>>>> should not return anything except for "null", because: >>>>>> >>>>>> 1. According to the documentation for the method >>>>>> "PrinterJob.print(PrintRequestAttributeSet)" from Java Platform >>>>>> SE 8 API Specification, if a user sets "java.awt.print.Pageable" >>>>>> object for "PrinterJob", then printing attributes related to >>>>>> media size, imageable area, page orientation will not influence >>>>>> anyhow the "PageFormat" object used for printing, and only >>>>>> "PageFormat" provided by the "Pageable" object will be used. >>>>>> Statement: "For clients of the Pageable interface, the PageFormat >>>>>> will always be as supplied by that interface, on a per page basis." >>>>>> Specification URL #1: >>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet- >>>>>> >>>>>> 2. Documentation on the method >>>>>> "PrinterJob.printDialog(PrintRequestAttributeSet)" acknowledges >>>>>> the point #1 by the statement "If using the Pageable interface, >>>>>> clients which intend to use media selected by the user must >>>>>> create a PageFormat derived from the user's selections.". >>>>>> Specification URL #2: >>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#printDialog-javax.print.attribute.PrintRequestAttributeSet- >>>>>> >>>>>> THE SOLUTION: >>>>>> The solution consists in changing the method >>>>>> "RasterPrinterJob.getPageFormatFromAttributes()" to return "null" >>>>>> for cases, when the "Pageable" object set in the printer job is >>>>>> not an instance of "sun.print.OpenBook" class, which is >>>>>> exclusively used by the printer job to wrap "Printable" object >>>>>> set by the user through "PrinterJob.setPrintable(Printable)". >>>>>> >>>>>> The fix affects only macOS platform, because >>>>>> "RasterPrinterJob.getPageFormatFromAttributes()" method is called >>>>>> only from the macOS specific native code in the file >>>>>> "src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m". >>>>>> >>>>>> Thank you, >>>>>> Anton >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.litvinov at oracle.com Mon Aug 27 15:44:17 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Mon, 27 Aug 2018 16:44:17 +0100 Subject: [OpenJDK 2D-Dev] [12] Review request for 8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object In-Reply-To: <1d6dde74-b693-3290-5819-6e1c8432504f@oracle.com> References: <5a09bce7-fa3d-b87f-a746-425423b13a6a@oracle.com> <5B7B50C8.8050501@oracle.com> <790ef595-31d1-f0eb-5c05-ed1a12244d6b@oracle.com> <19806eb4-8b2a-b542-c633-26ab45c65fe3@oracle.com> <1d6dde74-b693-3290-5819-6e1c8432504f@oracle.com> Message-ID: <09069cc0-dcd7-d92a-5714-24a142af127e@oracle.com> Hello Prasanta, Thank you for approval of the fix. Yes, sure, I will add "@key headful" to the regression test before integration of the fix. Thank you, Anton On 27/08/2018 08:16, Prasanta Sadhukhan wrote: > > looks good to me. Please add @key headful to test before pushing. > > Regards > Prasanta > On 8/23/2018 9:49 PM, Anton Litvinov wrote: >> I am sorry for an additional e-mail. In the previous e-mail I forgot >> to specify, that during the experiment not only JDK 11+28 was used, >> but also JDK 8u181 b13 was used. The correction in the first sentence >> below is marked with the bold font style. >> >> On 23/08/2018 16:32, Anton Litvinov wrote: >>> Hello Prasanta, >>> >>> By your explicit request today I have verified and confirm that the >>> bug is not reproducible on MS Windows 10 OS, Linux Ubuntu 16.04.2 >>> x86_64 OS with JDK 11+28*, JDK 8u181 b13*, therefore I confirm again >>> that this bug is macOS specific. >>> >>> The root cause of the issue is described in my review request, I do >>> not see a big reason to accomplish and provide here detailed >>> comparisons of how printing area code related to this issue is >>> implemented on all supported platforms; code for Windows, Linux, >>> macOS platforms has differences. This fix is for this specific bug >>> in macOS implementation of JDK. The bug is not reproducible on >>> Windows and Linux, simply because JDK code for Windows, Linux does >>> not involve calling the method >>> "RasterPrinterJob.getPageFormatFromAttributes()". >>> >>> I do not want to alter any generic code under this bug record to >>> address macOS specific issue, it will be certainly more error prone. >>> >>> Thank you, >>> Anton >>> >>> On 23/08/2018 06:40, Prasanta Sadhukhan wrote: >>>> Hi Anton, >>>> >>>> One thing I would like to know..since you told this fix will only >>>> affects macOS platform, did you check if this is not reproducible >>>> in windows or linux, if not why? If yes, then maybe we should put >>>> the fix in more generic place!! >>>> >>>> Regards >>>> Prasanta >>>> On 8/23/2018 12:29 AM, Anton Litvinov wrote: >>>>> Hello Phil, >>>>> >>>>> Thank you for review of this fix. It is correct, this code area >>>>> was already touched by 3 fixes which you specified, but they are >>>>> just 2 attempts to fix the same issue and 1 rollback of the 1st >>>>> fix, which was dictated by the fact that at that time JDK 9 passed >>>>> RDP 1. Answers to your questions are following: >>>>> >>>>> 1.? No, absolutely, this bug is not a regression from the fix for >>>>> 8181659. This bug exists in JDK for a long time, this is proved by >>>>> the fact that I was able to reproduce it with JDK 8u112 b16, while >>>>> the fix for 8167102 was never released in GA JDK 8 update, except >>>>> for 1 released build JDK 8u131 b32. I consider this bug as an >>>>> independent issue from 8167102, because of a difference in a test >>>>> scenario (in 8167102 "java.awt.print.Printable" interface is >>>>> involved, in this bug "java.awt.print.Pageable" interface is >>>>> involved), but at the same time they both have the same root >>>>> cause. The end user, which reported 8167102 changed conditions by >>>>> moving its application from setting "Printable" object to a >>>>> printer job to setting "Pageable" object ("java.awt.print.Book") >>>>> and encountered this issue. >>>>> >>>>> 2.? Yes, sure, I verified that the bug 8167102 is still not >>>>> reproducible with this fix by using the existing "jtreg" >>>>> regression test >>>>> "test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java". >>>>> >>>>> 3.? Today I have run all available "jtreg" manual and automatic >>>>> regression tests in the directories specified below and in our >>>>> closed directories (total 189 tests) using both JDK 12 compiled >>>>> without and with the fix, and verified that no new test failed on >>>>> JDK 12 with the fix. >>>>> >>>>> Directories with the executed regression tests: >>>>> - "test/jdk/java/awt/print" >>>>> - "test/jdk/javax/print" >>>>> >>>>> 4. Yes, I verified that the fix works as expected for specified by >>>>> you 3 cases: >>>>> a)? no print dialog - attached to the bug record test case >>>>> "PrintingAttributeBreaksBookPageSize.java" >>>>> b)? native print dialog - the created regression test >>>>> "test/jdk/java/awt/print/PageFormat/WrongPaperForBookPrintingTest.java" >>>>> >>>>> c)? swing print dialog - the regression test in point #b with >>>>> modification in 1 line. >>>>> >>>>> Thank you, >>>>> Anton >>>>> >>>>> On 21/08/2018 00:37, Philip Race wrote: >>>>>> Hi, >>>>>> >>>>>> The fix looks reasonable. >>>>>> But we've touched the code being touched here quite recently and >>>>>> the history >>>>>> there shows that this can be tricky to get right : >>>>>> 8167102: [macosx] PrintRequestAttributeSet breaks page size set >>>>>> using PageFormat >>>>>> caused >>>>>> 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs >>>>>> on macOS >>>>>> so then we had >>>>>> 8181659: Create an alternative fix for JDK-8167102, whose fix was >>>>>> backed out >>>>>> >>>>>> Is this new bug a regression caused by the previous fix ? >>>>>> Have you verified the previous fix is still functional ? >>>>>> What tests have been run ? >>>>>> Can you make sure this works in the cases of >>>>>> a) no dialog >>>>>> b) swing dialog >>>>>> c) native dialog. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 8/17/18, 12:42 PM, Anton Litvinov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you please review the following fix for the bug. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201818 >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~alitvinov/8201818/jdk12/webrev.00 >>>>>>> >>>>>>> The bug consists in the fact that, if any one printing attribute >>>>>>> is contained in "PrintRequestAttributeSet" during the call to >>>>>>> "java.awt.print.PrinterJob.print(PrintRequestAttributeSet)" >>>>>>> method, a page size from "java.awt.print.PageFormat" object >>>>>>> provided by "java.awt.print.Book" set to a printer job through >>>>>>> "PrinterJob.setPageable(Pageable)" method is not respected and >>>>>>> the printer job prints the document on a page of a size equal to >>>>>>> a default page size of a selected printer. >>>>>>> >>>>>>> CAUSE OF THE BUG: >>>>>>> The root cause of the bug is >>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" >>>>>>> method which returns "PageFormat" object constructed from >>>>>>> default settings of the selected printer, if the attribute set >>>>>>> in the printer job is not empty. For the case in this bug, when >>>>>>> the user explicitly sets "Book" object for the printer job, this >>>>>>> method should not return anything except for "null", because: >>>>>>> >>>>>>> 1. According to the documentation for the method >>>>>>> "PrinterJob.print(PrintRequestAttributeSet)" from Java Platform >>>>>>> SE 8 API Specification, if a user sets "java.awt.print.Pageable" >>>>>>> object for "PrinterJob", then printing attributes related to >>>>>>> media size, imageable area, page orientation will not influence >>>>>>> anyhow the "PageFormat" object used for printing, and only >>>>>>> "PageFormat" provided by the "Pageable" object will be used. >>>>>>> Statement: "For clients of the Pageable interface, the >>>>>>> PageFormat will always be as supplied by that interface, on a >>>>>>> per page basis." >>>>>>> Specification URL #1: >>>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet- >>>>>>> >>>>>>> 2. Documentation on the method >>>>>>> "PrinterJob.printDialog(PrintRequestAttributeSet)" acknowledges >>>>>>> the point #1 by the statement "If using the Pageable interface, >>>>>>> clients which intend to use media selected by the user must >>>>>>> create a PageFormat derived from the user's selections.". >>>>>>> Specification URL #2: >>>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#printDialog-javax.print.attribute.PrintRequestAttributeSet- >>>>>>> >>>>>>> THE SOLUTION: >>>>>>> The solution consists in changing the method >>>>>>> "RasterPrinterJob.getPageFormatFromAttributes()" to return >>>>>>> "null" for cases, when the "Pageable" object set in the printer >>>>>>> job is not an instance of "sun.print.OpenBook" class, which is >>>>>>> exclusively used by the printer job to wrap "Printable" object >>>>>>> set by the user through "PrinterJob.setPrintable(Printable)". >>>>>>> >>>>>>> The fix affects only macOS platform, because >>>>>>> "RasterPrinterJob.getPageFormatFromAttributes()" method is >>>>>>> called only from the macOS specific native code in the file >>>>>>> "src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m". >>>>>>> >>>>>>> Thank you, >>>>>>> Anton >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Aug 27 17:19:07 2018 From: philip.race at oracle.com (Phil Race) Date: Mon, 27 Aug 2018 10:19:07 -0700 Subject: [OpenJDK 2D-Dev] [12] Review request for 8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object In-Reply-To: <09069cc0-dcd7-d92a-5714-24a142af127e@oracle.com> References: <5a09bce7-fa3d-b87f-a746-425423b13a6a@oracle.com> <5B7B50C8.8050501@oracle.com> <790ef595-31d1-f0eb-5c05-ed1a12244d6b@oracle.com> <19806eb4-8b2a-b542-c633-26ab45c65fe3@oracle.com> <1d6dde74-b693-3290-5819-6e1c8432504f@oracle.com> <09069cc0-dcd7-d92a-5714-24a142af127e@oracle.com> Message-ID: <72c3ef21-e984-63de-147a-0b6ade589f7f@oracle.com> SFAIK that keyword is only necessary for automated tests. -phil. On 08/27/2018 08:44 AM, Anton Litvinov wrote: > Hello Prasanta, > > Thank you for approval of the fix. Yes, sure, I will add "@key > headful" to the regression test before integration of the fix. > > Thank you, > Anton > > On 27/08/2018 08:16, Prasanta Sadhukhan wrote: >> >> looks good to me. Please add @key headful to test before pushing. >> >> Regards >> Prasanta >> On 8/23/2018 9:49 PM, Anton Litvinov wrote: >>> I am sorry for an additional e-mail. In the previous e-mail I forgot >>> to specify, that during the experiment not only JDK 11+28 was used, >>> but also JDK 8u181 b13 was used. The correction in the first >>> sentence below is marked with the bold font style. >>> >>> On 23/08/2018 16:32, Anton Litvinov wrote: >>>> Hello Prasanta, >>>> >>>> By your explicit request today I have verified and confirm that the >>>> bug is not reproducible on MS Windows 10 OS, Linux Ubuntu 16.04.2 >>>> x86_64 OS with JDK 11+28*, JDK 8u181 b13*, therefore I confirm >>>> again that this bug is macOS specific. >>>> >>>> The root cause of the issue is described in my review request, I do >>>> not see a big reason to accomplish and provide here detailed >>>> comparisons of how printing area code related to this issue is >>>> implemented on all supported platforms; code for Windows, Linux, >>>> macOS platforms has differences. This fix is for this specific bug >>>> in macOS implementation of JDK. The bug is not reproducible on >>>> Windows and Linux, simply because JDK code for Windows, Linux does >>>> not involve calling the method >>>> "RasterPrinterJob.getPageFormatFromAttributes()". >>>> >>>> I do not want to alter any generic code under this bug record to >>>> address macOS specific issue, it will be certainly more error prone. >>>> >>>> Thank you, >>>> Anton >>>> >>>> On 23/08/2018 06:40, Prasanta Sadhukhan wrote: >>>>> Hi Anton, >>>>> >>>>> One thing I would like to know..since you told this fix will only >>>>> affects macOS platform, did you check if this is not reproducible >>>>> in windows or linux, if not why? If yes, then maybe we should put >>>>> the fix in more generic place!! >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 8/23/2018 12:29 AM, Anton Litvinov wrote: >>>>>> Hello Phil, >>>>>> >>>>>> Thank you for review of this fix. It is correct, this code area >>>>>> was already touched by 3 fixes which you specified, but they are >>>>>> just 2 attempts to fix the same issue and 1 rollback of the 1st >>>>>> fix, which was dictated by the fact that at that time JDK 9 >>>>>> passed RDP 1. Answers to your questions are following: >>>>>> >>>>>> 1. No, absolutely, this bug is not a regression from the fix for >>>>>> 8181659. This bug exists in JDK for a long time, this is proved >>>>>> by the fact that I was able to reproduce it with JDK 8u112 b16, >>>>>> while the fix for 8167102 was never released in GA JDK 8 update, >>>>>> except for 1 released build JDK 8u131 b32. I consider this bug as >>>>>> an independent issue from 8167102, because of a difference in a >>>>>> test scenario (in 8167102 "java.awt.print.Printable" interface is >>>>>> involved, in this bug "java.awt.print.Pageable" interface is >>>>>> involved), but at the same time they both have the same root >>>>>> cause. The end user, which reported 8167102 changed conditions by >>>>>> moving its application from setting "Printable" object to a >>>>>> printer job to setting "Pageable" object ("java.awt.print.Book") >>>>>> and encountered this issue. >>>>>> >>>>>> 2. Yes, sure, I verified that the bug 8167102 is still not >>>>>> reproducible with this fix by using the existing "jtreg" >>>>>> regression test >>>>>> "test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java". >>>>>> >>>>>> 3. Today I have run all available "jtreg" manual and automatic >>>>>> regression tests in the directories specified below and in our >>>>>> closed directories (total 189 tests) using both JDK 12 compiled >>>>>> without and with the fix, and verified that no new test failed on >>>>>> JDK 12 with the fix. >>>>>> >>>>>> Directories with the executed regression tests: >>>>>> - "test/jdk/java/awt/print" >>>>>> - "test/jdk/javax/print" >>>>>> >>>>>> 4. Yes, I verified that the fix works as expected for specified >>>>>> by you 3 cases: >>>>>> a) no print dialog - attached to the bug record test case >>>>>> "PrintingAttributeBreaksBookPageSize.java" >>>>>> b) native print dialog - the created regression test >>>>>> "test/jdk/java/awt/print/PageFormat/WrongPaperForBookPrintingTest.java" >>>>>> >>>>>> c) swing print dialog - the regression test in point #b with >>>>>> modification in 1 line. >>>>>> >>>>>> Thank you, >>>>>> Anton >>>>>> >>>>>> On 21/08/2018 00:37, Philip Race wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The fix looks reasonable. >>>>>>> But we've touched the code being touched here quite recently and >>>>>>> the history >>>>>>> there shows that this can be tricky to get right : >>>>>>> 8167102: [macosx] PrintRequestAttributeSet breaks page size set >>>>>>> using PageFormat >>>>>>> caused >>>>>>> 8181192: [macos] javafx.print.PrinterJob.showPrintDialog() hangs >>>>>>> on macOS >>>>>>> so then we had >>>>>>> 8181659: Create an alternative fix for JDK-8167102, whose fix >>>>>>> was backed out >>>>>>> >>>>>>> Is this new bug a regression caused by the previous fix ? >>>>>>> Have you verified the previous fix is still functional ? >>>>>>> What tests have been run ? >>>>>>> Can you make sure this works in the cases of >>>>>>> a) no dialog >>>>>>> b) swing dialog >>>>>>> c) native dialog. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 8/17/18, 12:42 PM, Anton Litvinov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you please review the following fix for the bug. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201818 >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~alitvinov/8201818/jdk12/webrev.00 >>>>>>>> >>>>>>>> The bug consists in the fact that, if any one printing >>>>>>>> attribute is contained in "PrintRequestAttributeSet" during the >>>>>>>> call to >>>>>>>> "java.awt.print.PrinterJob.print(PrintRequestAttributeSet)" >>>>>>>> method, a page size from "java.awt.print.PageFormat" object >>>>>>>> provided by "java.awt.print.Book" set to a printer job through >>>>>>>> "PrinterJob.setPageable(Pageable)" method is not respected and >>>>>>>> the printer job prints the document on a page of a size equal >>>>>>>> to a default page size of a selected printer. >>>>>>>> >>>>>>>> CAUSE OF THE BUG: >>>>>>>> The root cause of the bug is >>>>>>>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" >>>>>>>> method which returns "PageFormat" object constructed from >>>>>>>> default settings of the selected printer, if the attribute set >>>>>>>> in the printer job is not empty. For the case in this bug, when >>>>>>>> the user explicitly sets "Book" object for the printer job, >>>>>>>> this method should not return anything except for "null", because: >>>>>>>> >>>>>>>> 1. According to the documentation for the method >>>>>>>> "PrinterJob.print(PrintRequestAttributeSet)" from Java Platform >>>>>>>> SE 8 API Specification, if a user sets >>>>>>>> "java.awt.print.Pageable" object for "PrinterJob", then >>>>>>>> printing attributes related to media size, imageable area, page >>>>>>>> orientation will not influence anyhow the "PageFormat" object >>>>>>>> used for printing, and only "PageFormat" provided by the >>>>>>>> "Pageable" object will be used. >>>>>>>> Statement: "For clients of the Pageable interface, the >>>>>>>> PageFormat will always be as supplied by that interface, on a >>>>>>>> per page basis." >>>>>>>> Specification URL #1: >>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#print-javax.print.attribute.PrintRequestAttributeSet- >>>>>>>> >>>>>>>> 2. Documentation on the method >>>>>>>> "PrinterJob.printDialog(PrintRequestAttributeSet)" acknowledges >>>>>>>> the point #1 by the statement "If using the Pageable interface, >>>>>>>> clients which intend to use media selected by the user must >>>>>>>> create a PageFormat derived from the user's selections.". >>>>>>>> Specification URL #2: >>>>>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#printDialog-javax.print.attribute.PrintRequestAttributeSet- >>>>>>>> >>>>>>>> THE SOLUTION: >>>>>>>> The solution consists in changing the method >>>>>>>> "RasterPrinterJob.getPageFormatFromAttributes()" to return >>>>>>>> "null" for cases, when the "Pageable" object set in the printer >>>>>>>> job is not an instance of "sun.print.OpenBook" class, which is >>>>>>>> exclusively used by the printer job to wrap "Printable" object >>>>>>>> set by the user through "PrinterJob.setPrintable(Printable)". >>>>>>>> >>>>>>>> The fix affects only macOS platform, because >>>>>>>> "RasterPrinterJob.getPageFormatFromAttributes()" method is >>>>>>>> called only from the macOS specific native code in the file >>>>>>>> "src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m". >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Anton >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Aug 30 22:37:47 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 30 Aug 2018 15:37:47 -0700 Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux In-Reply-To: References: <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com> <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com> Message-ID: <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com> Hi Andrew, As noted in the issue comments, the fdlibm C code is obsolescent and eventually to be superseded by equivalent Java implementations. As for the mediaLib code being moribund I cannot speak but am copying 2d-dev which owns java.desktop. Thanks, Brian On Aug 30, 2018, at 6:03 AM, Andrew Leonard wrote: > Thanks Magnus, > Yes, these libraries are moribound it seems, hence their preference for compile options.. > 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: Magnus Ihse Bursie > To: Andrew Leonard , Brian Burkhalter > Cc: core-libs-dev at openjdk.java.net, build-dev > Date: 30/08/2018 13:49 > Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux > > > > Andrew, > > If you want to make changes to the build system (files in make/*), > please always include build-dev in the reviews. > > From a build point, this fix looks okay. My general preference is to > fix shady code instead of disabling warnings, but in this case it's in > two libraries that are either external or moribound, so if the > maintainer's of the respective libraries want to avoid code changes, I > accept that. > > /Magnus > > > On 2018-08-30 14:18, Andrew Leonard wrote: > > Hi Brian, > > Thanks for taking a look at this, I have just done a rebuild with a new > > patch with appropriate gcc disable warnings for these libraries: > > http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/ > > This works fine, so if you think this is a more favourable approach for > > these libraries? i'd like to get this merged please. > > 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: Brian Burkhalter > > To: Andrew Leonard > > Cc: core-libs-dev at openjdk.java.net > > Date: 28/08/2018 15:52 > > Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux > > > > > > > > Hi Andrew, > > > > It was suggested that it would be preferable to dial down the compilation > > settings for the fdlibm code rather than make a source code change. Was > > this investigated? > > > > Thanks, > > > > Brian > > > > On Aug 28, 2018, at 7:18 AM, Andrew Leonard > > wrote: > > > > We have discovered issues with gcc 7.3 on zLinux, combined with OpenJDK's > > default compiler options has highlighted a couple of native code issues, > > with undefined behaviours: > > - validating loop test array bounds > > - left shifts of negative values > > I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786 > > and attached the webrev fix here: > > http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ > > > > This has already been discussed and refined on the "s390x-port-dev" > > maillist > > and as it was pointed out, it should have been posted here... > > > > I'd like to request a sponsor for this fix please? > > > > > > > > > > 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 Thu Aug 30 23:28:09 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 30 Aug 2018 16:28:09 -0700 Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux In-Reply-To: <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com> References: <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com> <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com> <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com> Message-ID: <5B887D89.9070201@oracle.com> Some day, I'd like to replace a lot of medialib functionality with something like the proposed Vector API. But that is far enough away that medialib needs to be maintained, and unlike a previous discussion about a similar issue in the JPEG library, we are on the hook for maintaining medialib. So if there is an actual logic error in medialib, I'd prefer to fix it. If the issue is a false positive, I'd be OK to disable the warning, but wrapped in a platform-specific manner. So is it a real error here ? -phil. On 8/30/18, 3:37 PM, Brian Burkhalter wrote: > Hi Andrew, > > As noted in the issue comments, the fdlibm C code is obsolescent and > eventually to be superseded by equivalent Java implementations. As for > the mediaLib code being moribund I cannot speak but am copying 2d-dev > which owns java.desktop. > > Thanks, > > Brian > > On Aug 30, 2018, at 6:03 AM, Andrew Leonard > > wrote: > >> Thanks Magnus, >> Yes, these libraries are moribound it seems, hence their preference >> for compile options.. >> 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: Magnus Ihse Bursie > > >> To: Andrew Leonard > >, Brian Burkhalter >> > >> Cc: core-libs-dev at openjdk.java.net >> , build-dev >> > >> Date: 30/08/2018 13:49 >> Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux >> ------------------------------------------------------------------------ >> >> >> >> Andrew, >> >> If you want to make changes to the build system (files in make/*), >> please always include build-dev in the reviews. >> >> From a build point, this fix looks okay. My general preference is to >> fix shady code instead of disabling warnings, but in this case it's in >> two libraries that are either external or moribound, so if the >> maintainer's of the respective libraries want to avoid code changes, I >> accept that. >> >> /Magnus >> >> >> On 2018-08-30 14:18, Andrew Leonard wrote: >> > Hi Brian, >> > Thanks for taking a look at this, I have just done a rebuild with a new >> > patch with appropriate gcc disable warnings for these libraries: >> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/ >> >> > This works fine, so if you think this is a more favourable approach for >> > these libraries? i'd like to get this merged please. >> > 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: Brian Burkhalter > > >> > To: Andrew Leonard > > >> > Cc: core-libs-dev at openjdk.java.net >> >> > Date: 28/08/2018 15:52 >> > Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux >> > >> > >> > >> > Hi Andrew, >> > >> > It was suggested that it would be preferable to dial down the >> compilation >> > settings for the fdlibm code rather than make a source code change. Was >> > this investigated? >> > >> > Thanks, >> > >> > Brian >> > >> > On Aug 28, 2018, at 7:18 AM, Andrew Leonard >> > >> > wrote: >> > >> > We have discovered issues with gcc 7.3 on zLinux, combined with >> OpenJDK's >> > default compiler options has highlighted a couple of native code issues, >> > with undefined behaviours: >> > - validating loop test array bounds >> > - left shifts of negative values >> > I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786 >> > and attached the webrev fix here: >> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ >> >> > >> > This has already been discussed and refined on the "s390x-port-dev" >> > maillist >> > and as it was pointed out, it should have been posted here... >> > >> > I'd like to request a sponsor for this fix please? >> > >> > >> > >> > >> > 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 magnus.ihse.bursie at oracle.com Fri Aug 31 08:27:26 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 31 Aug 2018 10:27:26 +0200 Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux In-Reply-To: <5B887D89.9070201@oracle.com> References: <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com> <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com> <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com> <5B887D89.9070201@oracle.com> Message-ID: <6163c668-1584-bc17-de92-26e518830cdf@oracle.com> On 2018-08-31 01:28, Philip Race wrote: > Some day, I'd like to replace a lot of medialib functionality with > something > like the proposed Vector API. But that is far enough away that > medialib needs > to be maintained, and unlike a previous discussion about a similar > issue in > the JPEG library, we are on the hook for maintaining medialib. > So if there is an actual logic error in medialib, I'd prefer to fix it. > If the issue is a false positive, I'd be OK to disable the warning, > but wrapped > in a platform-specific manner. So is it a real error here ? Gcc is emitting a warning due to shifting of negative values, which is deemed undefined behavior by the spec. Is this a real error? Well. Undefined behavior is no good. It can work for now and then suddenly start breaking. The originally suggested code change (http://cr.openjdk.java.net/~aleonard/8209786/webrev.00) seems reasonable to me. It is at the very least much clearer what the intention is. And it's conformant with the spec. So I'd advocate using that fix, if you want to continue supporting the library. /Magnus > > -phil. > > On 8/30/18, 3:37 PM, Brian Burkhalter wrote: >> Hi Andrew, >> >> As noted in the issue comments, the fdlibm C code is obsolescent and >> eventually to be superseded by equivalent Java implementations. As >> for the mediaLib code being moribund I cannot speak but am copying >> 2d-dev which owns java.desktop. >> >> Thanks, >> >> Brian >> >> On Aug 30, 2018, at 6:03 AM, Andrew Leonard >> > >> wrote: >> >>> Thanks Magnus, >>> Yes, these libraries are moribound it seems, hence their preference >>> for compile options.. >>> 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: Magnus Ihse Bursie >> > >>> To: Andrew Leonard >> >, Brian Burkhalter >>> > >>> Cc: core-libs-dev at openjdk.java.net >>> , build-dev >>> > >>> Date: 30/08/2018 13:49 >>> Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> Andrew, >>> >>> If you want to make changes to the build system (files in make/*), >>> please always include build-dev in the reviews. >>> >>> From a build point, this fix looks okay. My general preference is to >>> fix shady code instead of disabling warnings, but in this case it's in >>> two libraries that are either external or moribound, so if the >>> maintainer's of the respective libraries want to avoid code changes, I >>> accept that. >>> >>> /Magnus >>> >>> >>> On 2018-08-30 14:18, Andrew Leonard wrote: >>> > Hi Brian, >>> > Thanks for taking a look at this, I have just done a rebuild with >>> a new >>> > patch with appropriate gcc disable warnings for these libraries: >>> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/ >>> >>> > This works fine, so if you think this is a more favourable >>> approach for >>> > these libraries? i'd like to get this merged please. >>> > 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:?? Brian Burkhalter >> > >>> > To:???? Andrew Leonard >> > >>> > Cc: core-libs-dev at openjdk.java.net >>> >>> > Date:?? 28/08/2018 15:52 >>> > Subject:??????? Re: RFR JDK-8209786: gcc 7.3 compiler errors on >>> zLinux >>> > >>> > >>> > >>> > Hi Andrew, >>> > >>> > It was suggested that it would be preferable to dial down the >>> compilation >>> > settings for the fdlibm code rather than make a source code >>> change. Was >>> > this investigated? >>> > >>> > Thanks, >>> > >>> > Brian >>> > >>> > On Aug 28, 2018, at 7:18 AM, Andrew Leonard >>> > >>> > wrote: >>> > >>> > We have discovered issues with gcc 7.3 on zLinux, combined with >>> OpenJDK's >>> > default compiler options has highlighted a couple of native code >>> issues, >>> > with undefined behaviours: >>> >?? - validating loop test array bounds >>> >?? - left shifts of negative values >>> > I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786 >>> > and attached the webrev fix here: >>> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ >>> >>> > >>> > This has already been discussed and refined on the "s390x-port-dev" >>> > maillist >>> > and as it was pointed out, it should have been posted here... >>> > >>> > I'd like to request a sponsor for this fix please? >>> > >>> > >>> > >>> > >>> > 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 >> From andrew_m_leonard at uk.ibm.com Fri Aug 31 09:14:34 2018 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Fri, 31 Aug 2018 10:14:34 +0100 Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux In-Reply-To: <6163c668-1584-bc17-de92-26e518830cdf@oracle.com> References: <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com> <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com> <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com> <5B887D89.9070201@oracle.com> <6163c668-1584-bc17-de92-26e518830cdf@oracle.com> Message-ID: Hi, So there seems to be varying opinion here, taking the 2D view point since it is going to be maintained, the opinion seems to be more with the fix ( http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/). This would be my personal preference also, but previous comments seemed to prefer compiler options. Looking at each error: - /libfdlibm/k_rem_pio2.c : This is a simple "for" loop bound check, which with good programming practice should really have been there to prevent ArrayOutOfBounds.. or native overwrites.. Simple fix. - libmlib_image/mlib_ImageLookUp_Bit.c : This is -ve bit shifting which is spec undefined, which in theory could mean it breaks in the future if we upgrade/change compiler... However, this is complex code, we need to be very sure the new fix is "correct", myself and my colleague here have examined it closely and are happy, but i'd appreciate your in-depth analysis please. Magnus, Philip, Brian, Goetz, can we have a vote? => "Fix" or "DisableWarnings" ? 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: Magnus Ihse Bursie To: Philip Race , Brian Burkhalter Cc: 2d-dev <2d-dev at openjdk.java.net>, build-dev , Andrew Leonard , core-libs-dev Date: 31/08/2018 09:27 Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux On 2018-08-31 01:28, Philip Race wrote: > Some day, I'd like to replace a lot of medialib functionality with > something > like the proposed Vector API. But that is far enough away that > medialib needs > to be maintained, and unlike a previous discussion about a similar > issue in > the JPEG library, we are on the hook for maintaining medialib. > So if there is an actual logic error in medialib, I'd prefer to fix it. > If the issue is a false positive, I'd be OK to disable the warning, > but wrapped > in a platform-specific manner. So is it a real error here ? Gcc is emitting a warning due to shifting of negative values, which is deemed undefined behavior by the spec. Is this a real error? Well. Undefined behavior is no good. It can work for now and then suddenly start breaking. The originally suggested code change ( http://cr.openjdk.java.net/~aleonard/8209786/webrev.00 ) seems reasonable to me. It is at the very least much clearer what the intention is. And it's conformant with the spec. So I'd advocate using that fix, if you want to continue supporting the library. /Magnus > > -phil. > > On 8/30/18, 3:37 PM, Brian Burkhalter wrote: >> Hi Andrew, >> >> As noted in the issue comments, the fdlibm C code is obsolescent and >> eventually to be superseded by equivalent Java implementations. As >> for the mediaLib code being moribund I cannot speak but am copying >> 2d-dev which owns java.desktop. >> >> Thanks, >> >> Brian >> >> On Aug 30, 2018, at 6:03 AM, Andrew Leonard >> > >> wrote: >> >>> Thanks Magnus, >>> Yes, these libraries are moribound it seems, hence their preference >>> for compile options.. >>> 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: Magnus Ihse Bursie >> > >>> To: Andrew Leonard >> >, Brian Burkhalter >>> > >>> Cc: core-libs-dev at openjdk.java.net >>> , build-dev >>> > >>> Date: 30/08/2018 13:49 >>> Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> Andrew, >>> >>> If you want to make changes to the build system (files in make/*), >>> please always include build-dev in the reviews. >>> >>> From a build point, this fix looks okay. My general preference is to >>> fix shady code instead of disabling warnings, but in this case it's in >>> two libraries that are either external or moribound, so if the >>> maintainer's of the respective libraries want to avoid code changes, I >>> accept that. >>> >>> /Magnus >>> >>> >>> On 2018-08-30 14:18, Andrew Leonard wrote: >>> > Hi Brian, >>> > Thanks for taking a look at this, I have just done a rebuild with >>> a new >>> > patch with appropriate gcc disable warnings for these libraries: >>> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/ >>> < http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.01/ > >>> > This works fine, so if you think this is a more favourable >>> approach for >>> > these libraries? i'd like to get this merged please. >>> > 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: Brian Burkhalter >> > >>> > To: Andrew Leonard >> > >>> > Cc: core-libs-dev at openjdk.java.net >>> >>> > Date: 28/08/2018 15:52 >>> > Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on >>> zLinux >>> > >>> > >>> > >>> > Hi Andrew, >>> > >>> > It was suggested that it would be preferable to dial down the >>> compilation >>> > settings for the fdlibm code rather than make a source code >>> change. Was >>> > this investigated? >>> > >>> > Thanks, >>> > >>> > Brian >>> > >>> > On Aug 28, 2018, at 7:18 AM, Andrew Leonard >>> > >>> > wrote: >>> > >>> > We have discovered issues with gcc 7.3 on zLinux, combined with >>> OpenJDK's >>> > default compiler options has highlighted a couple of native code >>> issues, >>> > with undefined behaviours: >>> > - validating loop test array bounds >>> > - left shifts of negative values >>> > I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786 >>> > and attached the webrev fix here: >>> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ >>> < http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.00/ > >>> > >>> > This has already been discussed and refined on the "s390x-port-dev" >>> > maillist >>> > and as it was pointed out, it should have been posted here... >>> > >>> > I'd like to request a sponsor for this fix please? >>> > >>> > >>> > >>> > >>> > 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 magnus.ihse.bursie at oracle.com Fri Aug 31 09:28:23 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 31 Aug 2018 11:28:23 +0200 Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux In-Reply-To: References: <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com> <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com> <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com> <5B887D89.9070201@oracle.com> <6163c668-1584-bc17-de92-26e518830cdf@oracle.com> Message-ID: <4382b94a-9716-135d-25ae-0edcb975dd50@oracle.com> On 2018-08-31 11:14, Andrew Leonard wrote: > Hi, > So there seems to be varying opinion here, taking the 2D view point > since it is going to be maintained, the opinion seems to be more with > the fix (http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ > ). This > would be my personal preference also, but previous comments seemed to > prefer compiler options. > > Looking at each error: > - */libfdlibm/k_rem_pio2.c* : This is a simple "for" loop bound check, > which with good programming practice should really have been there to > prevent ArrayOutOfBounds.. or native overwrites.. Simple fix. > - *libmlib_image/mlib_ImageLookUp_Bit.c* : This is -ve bit shifting > which is spec undefined, which in theory could mean it breaks in the > future if we upgrade/change compiler... However, this is complex code, > we need to be very sure the new fix is "correct", myself and my > colleague here have examined it closely and are happy, but i'd > appreciate your in-depth analysis please. It looks good. The intention of the old code has clearly been to have an 32 or 64-bit wide all-1s bitmask, and this is what your fix delivers as well. > > > Magnus, Philip, Brian, Goetz, can we have a vote? => "Fix" or > "DisableWarnings" ? Note that this decision can be different for the two libraries. I'd argue that the maintainer of each library decides. And if so, it seems to be "compiler fix" for libfdlibm, and "source fix" for libmlib_image. /Magnus > > > 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: Magnus Ihse Bursie > To: Philip Race , Brian Burkhalter > > Cc: 2d-dev <2d-dev at openjdk.java.net>, build-dev > , Andrew Leonard > , core-libs-dev > > Date: 31/08/2018 09:27 > Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors > on zLinux > ------------------------------------------------------------------------ > > > > On 2018-08-31 01:28, Philip Race wrote: > > Some day, I'd like to replace a lot of medialib functionality with > > something > > like the proposed Vector API. But that is far enough away that > > medialib needs > > to be maintained, and unlike a previous discussion about a similar > > issue in > > the JPEG library, we are on the hook for maintaining medialib. > > So if there is an actual logic error in medialib, I'd prefer to fix it. > > If the issue is a false positive, I'd be OK to disable the warning, > > but wrapped > > in a platform-specific manner. So is it a real error here ? > > Gcc is emitting a warning due to shifting of negative values, which is > deemed undefined behavior by the spec. > > Is this a real error? Well. Undefined behavior is no good. It can work > for now and then suddenly start breaking. > > The originally suggested code change > (http://cr.openjdk.java.net/~aleonard/8209786/webrev.00 > ) seems > reasonable to me. It is at the very least much clearer what the > intention is. And it's conformant with the spec. > > So I'd advocate using that fix, if you want to continue supporting the > library. > > /Magnus > > > > > > > > -phil. > > > > On 8/30/18, 3:37 PM, Brian Burkhalter wrote: > >> Hi Andrew, > >> > >> As noted in the issue comments, the fdlibm C code is obsolescent and > >> eventually to be superseded by equivalent Java implementations. As > >> for the mediaLib code being moribund I cannot speak but am copying > >> 2d-dev which owns java.desktop. > >> > >> Thanks, > >> > >> Brian > >> > >> On Aug 30, 2018, at 6:03 AM, Andrew Leonard > >> > > >> wrote: > >> > >>> Thanks Magnus, > >>> Yes, these libraries are moribound it seems, hence their preference > >>> for compile options.. > >>> 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: Magnus Ihse Bursie >>> > > >>> To: Andrew Leonard >>> >, Brian Burkhalter > >>> > > >>> Cc: core-libs-dev at openjdk.java.net > >>> , build-dev > >>> > > >>> Date: 30/08/2018 13:49 > >>> Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux > >>> > ------------------------------------------------------------------------ > >>> > >>> > >>> > >>> > >>> Andrew, > >>> > >>> If you want to make changes to the build system (files in make/*), > >>> please always include build-dev in the reviews. > >>> > >>> From a build point, this fix looks okay. My general preference is to > >>> fix shady code instead of disabling warnings, but in this case it's in > >>> two libraries that are either external or moribound, so if the > >>> maintainer's of the respective libraries want to avoid code changes, I > >>> accept that. > >>> > >>> /Magnus > >>> > >>> > >>> On 2018-08-30 14:18, Andrew Leonard wrote: > >>> > Hi Brian, > >>> > Thanks for taking a look at this, I have just done a rebuild with > >>> a new > >>> > patch with appropriate gcc disable warnings for these libraries: > >>> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/ > > >>> > >>> > This works fine, so if you think this is a more favourable > >>> approach for > >>> > these libraries? i'd like to get this merged please. > >>> > 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:?? Brian Burkhalter >>> > > >>> > To:???? Andrew Leonard >>> > > >>> > Cc: core-libs-dev at openjdk.java.net > >>> > >>> > Date:?? 28/08/2018 15:52 > >>> > Subject:??????? Re: RFR JDK-8209786: gcc 7.3 compiler errors on > >>> zLinux > >>> > > >>> > > >>> > > >>> > Hi Andrew, > >>> > > >>> > It was suggested that it would be preferable to dial down the > >>> compilation > >>> > settings for the fdlibm code rather than make a source code > >>> change. Was > >>> > this investigated? > >>> > > >>> > Thanks, > >>> > > >>> > Brian > >>> > > >>> > On Aug 28, 2018, at 7:18 AM, Andrew Leonard > >>> > > >>> > wrote: > >>> > > >>> > We have discovered issues with gcc 7.3 on zLinux, combined with > >>> OpenJDK's > >>> > default compiler options has highlighted a couple of native code > >>> issues, > >>> > with undefined behaviours: > >>> >?? - validating loop test array bounds > >>> >?? - left shifts of negative values > >>> > I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786 > >>> > and attached the webrev fix here: > >>> > http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ > > >>> > >>> > > >>> > This has already been discussed and refined on the "s390x-port-dev" > >>> > maillist > >>> > and as it was pointed out, it should have been posted here... > >>> > > >>> > I'd like to request a sponsor for this fix please? > >>> > > >>> > > >>> > > >>> > > >>> > 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 brian.burkhalter at oracle.com Fri Aug 31 14:43:29 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 31 Aug 2018 07:43:29 -0700 Subject: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux In-Reply-To: <4382b94a-9716-135d-25ae-0edcb975dd50@oracle.com> References: <75FE655E-1239-442D-9078-CFF0C827758B@oracle.com> <1df30641-e770-4fc3-e318-2fb666ec07b3@oracle.com> <1E113109-5D54-4AE2-BAE2-5ACBC5FE11A9@oracle.com> <5B887D89.9070201@oracle.com> <6163c668-1584-bc17-de92-26e518830cdf@oracle.com> <4382b94a-9716-135d-25ae-0edcb975dd50@oracle.com> Message-ID: <7BF23440-41CE-43DB-AA68-BE250D286C1E@oracle.com> On Aug 31, 2018, at 2:28 AM, Magnus Ihse Bursie wrote: >> Magnus, Philip, Brian, Goetz, can we have a vote? => "Fix" or "DisableWarnings" ? > > Note that this decision can be different for the two libraries. I'd argue that the maintainer of each library decides. And if so, it seems to be "compiler fix" for libfdlibm, and "source fix" for libmlib_image. I think we can safely say ?disable compiler errors? for fdlibm as indicated by Joe Darcy?s comment in the issue (he owns fdlibm), and source code change for mediaLib as Phil indicated in e-mail. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: