From chien.yang at oracle.com Mon May 2 06:55:36 2016 From: chien.yang at oracle.com (Chien Yang) Date: Sun, 01 May 2016 23:55:36 -0700 Subject: Code Review Request For 8155757: Encapsulate impl_ methods in animation, canvas, image, input, layout, paint, and text packages In-Reply-To: References: <5723AD0A.9030407@oracle.com> Message-ID: <5726F9E8.5050503@oracle.com> Hi Jim, Thanks for sharing this information and your thought. I'm not sure is this saving worth violating the principle of minimizing scope in code. I guess you did bring up a good point let me think over it and discuss with Kevin tomorrow. - Chien On 4/29/16, 4:04 PM, Jim Graham wrote: > One comment on the implementation. For the methods used by an > accessor inner class, if you make them private in the outer class then > that inner class will need a hidden accessor method to be added in the > bytecodes. If you make them package-private then they can access the > method directly. > > Basically, an inner class is really "just another class in the > package, but with a special name" and actually have no access to > private methods in their outer classes at all, but javac works around > this by adding a hidden method that has more open access and using that. > > An example is Image.getPlatformImage() - you turned it from "public > and impl_" into private. Why not just leave it > package-private/default access? > > For example, compiling this class: > > public class InnerPrivateTest { > private void foo() {} > public class InnerClass { > public void bar() { foo(); } > } > } > > yields this byte code for InnerPrivateTest.class: > > public class InnerPrivateTest { > public InnerPrivateTest(); > Code: > 0: aload_0 > 1: invokespecial #2 // Method > java/lang/Object."":()V > 4: return > > private void foo(); > Code: > 0: return > > static void access$000(InnerPrivateTest); > Code: > 0: aload_0 > 1: invokespecial #1 // Method foo:()V > 4: return > } > > and this for the InnerClass: > > public class InnerPrivateTest$InnerClass { > final InnerPrivateTest this$0; > > public InnerPrivateTest$InnerClass(InnerPrivateTest); > Code: > 0: aload_0 > 1: aload_1 > 2: putfield #1 // Field > this$0:LInnerPrivateTest; > 5: aload_0 > 6: invokespecial #2 // Method > java/lang/Object."":()V > 9: return > > public void bar(); > Code: > 0: aload_0 > 1: getfield #1 // Field > this$0:LInnerPrivateTest; > 4: invokestatic #3 // Method > InnerPrivateTest.access$000:(LInnerPrivateTest;)V > 7: return > } > > Changing the access on foo() to default (package private), yields this > byte code: > > public class InnerPackageTest { > public InnerPackageTest(); > Code: > 0: aload_0 > 1: invokespecial #1 // Method > java/lang/Object."":()V > 4: return > > void foo(); > Code: > 0: return > } > > public class InnerPackageTest$InnerClass { > final InnerPackageTest this$0; > > public InnerPackageTest$InnerClass(InnerPackageTest); > Code: > 0: aload_0 > 1: aload_1 > 2: putfield #1 // Field > this$0:LInnerPackageTest; > 5: aload_0 > 6: invokespecial #2 // Method > java/lang/Object."":()V > 9: return > > public void bar(); > Code: > 0: aload_0 > 1: getfield #1 // Field > this$0:LInnerPackageTest; > 4: invokevirtual #3 // Method > InnerPackageTest.foo:()V > 7: return > } > > ...jim > > On 4/29/16 11:50 AM, Chien Yang wrote: >> Hi Kevin, >> >> Please review the proposed fix: >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8155757 >> Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8155757/webrev.00/ >> >> Thanks, >> - Chien From murali.billa at oracle.com Mon May 2 09:52:18 2016 From: murali.billa at oracle.com (Murali Billa) Date: Mon, 2 May 2016 02:52:18 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Guru Hb In-Reply-To: References: <5722294E.5050909@oracle.com> Message-ID: <3dbf6a3f-5446-44f1-abea-5eebd9d70b8e@default> VOTE: YES -- Murali On 4/28/16 8:16 AM, Kevin Rushforth wrote: > I hereby nominate Guru Hb [1] to OpenJFX Committer. > > Guru is a member of JavaFX team at Oracle working on WebKit, who has > contributed 10 changesets [5] to OpenJFX, at least 8 of which are > significant. > > Votes are due by May 12, 2016. > > Only current OpenJFX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a > project Committer is described in [4]. > > Thanks, > > -- Kevin > > [1] http://openjdk.java.net/census#ghb > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of changesets: > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/1ec63f261e9f > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/fb4c37073893 > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/3ccf14ef836f > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/45efd3d83bf1 > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/08a57f273c76 > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/bd97f8ca31fc > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/0576d7a6f137 > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/d4f8c9496683 > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/620f5c6b4383 > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/aa51df7e1d41 > From David.Hill at Oracle.com Mon May 2 16:29:56 2016 From: David.Hill at Oracle.com (David Hill) Date: Mon, 02 May 2016 12:29:56 -0400 Subject: review for minor changes to build.gradle Message-ID: <57278084.5070001@Oracle.com> Kevin, a couple of proposed changes to build.gradle. Diffs are inline in the bugs. Provide for extra jvm arguments for gradle test task https://bugs.openjdk.java.net/browse/JDK-8155831 Allow disabling :web:test https://bugs.openjdk.java.net/browse/JDK-8155832 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From james.graham at oracle.com Mon May 2 20:07:07 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 2 May 2016 13:07:07 -0700 Subject: Code Review Request For 8155757: Encapsulate impl_ methods in animation, canvas, image, input, layout, paint, and text packages In-Reply-To: <5726F9E8.5050503@oracle.com> References: <5723AD0A.9030407@oracle.com> <5726F9E8.5050503@oracle.com> Message-ID: Maybe we could ask someone in Hotspot if they recognize these bytecode patterns and optimize out the helper methods. If that's the case, then it is really just down to a bundled size issue... ...jim On 5/1/2016 11:55 PM, Chien Yang wrote: > Hi Jim, > > Thanks for sharing this information and your thought. I'm not sure is > this saving worth violating the principle of minimizing scope in code. I > guess you did bring up a good point let me think over it and discuss > with Kevin tomorrow. > > - Chien > > On 4/29/16, 4:04 PM, Jim Graham wrote: >> One comment on the implementation. For the methods used by an >> accessor inner class, if you make them private in the outer class then >> that inner class will need a hidden accessor method to be added in the >> bytecodes. If you make them package-private then they can access the >> method directly. >> >> Basically, an inner class is really "just another class in the >> package, but with a special name" and actually have no access to >> private methods in their outer classes at all, but javac works around >> this by adding a hidden method that has more open access and using that. >> >> An example is Image.getPlatformImage() - you turned it from "public >> and impl_" into private. Why not just leave it >> package-private/default access? >> >> For example, compiling this class: >> >> public class InnerPrivateTest { >> private void foo() {} >> public class InnerClass { >> public void bar() { foo(); } >> } >> } >> >> yields this byte code for InnerPrivateTest.class: >> >> public class InnerPrivateTest { >> public InnerPrivateTest(); >> Code: >> 0: aload_0 >> 1: invokespecial #2 // Method >> java/lang/Object."":()V >> 4: return >> >> private void foo(); >> Code: >> 0: return >> >> static void access$000(InnerPrivateTest); >> Code: >> 0: aload_0 >> 1: invokespecial #1 // Method foo:()V >> 4: return >> } >> >> and this for the InnerClass: >> >> public class InnerPrivateTest$InnerClass { >> final InnerPrivateTest this$0; >> >> public InnerPrivateTest$InnerClass(InnerPrivateTest); >> Code: >> 0: aload_0 >> 1: aload_1 >> 2: putfield #1 // Field >> this$0:LInnerPrivateTest; >> 5: aload_0 >> 6: invokespecial #2 // Method >> java/lang/Object."":()V >> 9: return >> >> public void bar(); >> Code: >> 0: aload_0 >> 1: getfield #1 // Field >> this$0:LInnerPrivateTest; >> 4: invokestatic #3 // Method >> InnerPrivateTest.access$000:(LInnerPrivateTest;)V >> 7: return >> } >> >> Changing the access on foo() to default (package private), yields this >> byte code: >> >> public class InnerPackageTest { >> public InnerPackageTest(); >> Code: >> 0: aload_0 >> 1: invokespecial #1 // Method >> java/lang/Object."":()V >> 4: return >> >> void foo(); >> Code: >> 0: return >> } >> >> public class InnerPackageTest$InnerClass { >> final InnerPackageTest this$0; >> >> public InnerPackageTest$InnerClass(InnerPackageTest); >> Code: >> 0: aload_0 >> 1: aload_1 >> 2: putfield #1 // Field >> this$0:LInnerPackageTest; >> 5: aload_0 >> 6: invokespecial #2 // Method >> java/lang/Object."":()V >> 9: return >> >> public void bar(); >> Code: >> 0: aload_0 >> 1: getfield #1 // Field >> this$0:LInnerPackageTest; >> 4: invokevirtual #3 // Method >> InnerPackageTest.foo:()V >> 7: return >> } >> >> ...jim >> >> On 4/29/16 11:50 AM, Chien Yang wrote: >>> Hi Kevin, >>> >>> Please review the proposed fix: >>> >>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8155757 >>> Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8155757/webrev.00/ >>> >>> Thanks, >>> - Chien From kevin.rushforth at oracle.com Mon May 2 20:10:38 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 02 May 2016 13:10:38 -0700 Subject: 9-dev unlocked following sanity testing Message-ID: <5727B43E.5030706@oracle.com> From kevin.rushforth at oracle.com Mon May 2 21:47:20 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 02 May 2016 14:47:20 -0700 Subject: Code Review Request For 8155757: Encapsulate impl_ methods in animation, canvas, image, input, layout, paint, and text packages In-Reply-To: References: <5723AD0A.9030407@oracle.com> <5726F9E8.5050503@oracle.com> Message-ID: <5727CAE8.4040706@oracle.com> That sounds like a good idea. I like the idea of keeping the reduced scope (private where possible) for clarity if there isn't a noticeable performance penalty for doing so. Also, it matches our pattern for existing accessor methods, some of which directly access private property fields; changing them would be at odds with our pattern for declaring properties. -- Kevin Jim Graham wrote: > Maybe we could ask someone in Hotspot if they recognize these bytecode > patterns and optimize out the helper methods. If that's the case, > then it is really just down to a bundled size issue... > > ...jim > > On 5/1/2016 11:55 PM, Chien Yang wrote: >> Hi Jim, >> >> Thanks for sharing this information and your thought. I'm not sure is >> this saving worth violating the principle of minimizing scope in code. I >> guess you did bring up a good point let me think over it and discuss >> with Kevin tomorrow. >> >> - Chien >> >> On 4/29/16, 4:04 PM, Jim Graham wrote: >>> One comment on the implementation. For the methods used by an >>> accessor inner class, if you make them private in the outer class then >>> that inner class will need a hidden accessor method to be added in the >>> bytecodes. If you make them package-private then they can access the >>> method directly. >>> >>> Basically, an inner class is really "just another class in the >>> package, but with a special name" and actually have no access to >>> private methods in their outer classes at all, but javac works around >>> this by adding a hidden method that has more open access and using >>> that. >>> >>> An example is Image.getPlatformImage() - you turned it from "public >>> and impl_" into private. Why not just leave it >>> package-private/default access? >>> >>> For example, compiling this class: >>> >>> public class InnerPrivateTest { >>> private void foo() {} >>> public class InnerClass { >>> public void bar() { foo(); } >>> } >>> } >>> >>> yields this byte code for InnerPrivateTest.class: >>> >>> public class InnerPrivateTest { >>> public InnerPrivateTest(); >>> Code: >>> 0: aload_0 >>> 1: invokespecial #2 // Method >>> java/lang/Object."":()V >>> 4: return >>> >>> private void foo(); >>> Code: >>> 0: return >>> >>> static void access$000(InnerPrivateTest); >>> Code: >>> 0: aload_0 >>> 1: invokespecial #1 // Method foo:()V >>> 4: return >>> } >>> >>> and this for the InnerClass: >>> >>> public class InnerPrivateTest$InnerClass { >>> final InnerPrivateTest this$0; >>> >>> public InnerPrivateTest$InnerClass(InnerPrivateTest); >>> Code: >>> 0: aload_0 >>> 1: aload_1 >>> 2: putfield #1 // Field >>> this$0:LInnerPrivateTest; >>> 5: aload_0 >>> 6: invokespecial #2 // Method >>> java/lang/Object."":()V >>> 9: return >>> >>> public void bar(); >>> Code: >>> 0: aload_0 >>> 1: getfield #1 // Field >>> this$0:LInnerPrivateTest; >>> 4: invokestatic #3 // Method >>> InnerPrivateTest.access$000:(LInnerPrivateTest;)V >>> 7: return >>> } >>> >>> Changing the access on foo() to default (package private), yields this >>> byte code: >>> >>> public class InnerPackageTest { >>> public InnerPackageTest(); >>> Code: >>> 0: aload_0 >>> 1: invokespecial #1 // Method >>> java/lang/Object."":()V >>> 4: return >>> >>> void foo(); >>> Code: >>> 0: return >>> } >>> >>> public class InnerPackageTest$InnerClass { >>> final InnerPackageTest this$0; >>> >>> public InnerPackageTest$InnerClass(InnerPackageTest); >>> Code: >>> 0: aload_0 >>> 1: aload_1 >>> 2: putfield #1 // Field >>> this$0:LInnerPackageTest; >>> 5: aload_0 >>> 6: invokespecial #2 // Method >>> java/lang/Object."":()V >>> 9: return >>> >>> public void bar(); >>> Code: >>> 0: aload_0 >>> 1: getfield #1 // Field >>> this$0:LInnerPackageTest; >>> 4: invokevirtual #3 // Method >>> InnerPackageTest.foo:()V >>> 7: return >>> } >>> >>> ...jim >>> >>> On 4/29/16 11:50 AM, Chien Yang wrote: >>>> Hi Kevin, >>>> >>>> Please review the proposed fix: >>>> >>>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8155757 >>>> Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8155757/webrev.00/ >>>> >>>> Thanks, >>>> - Chien From Sergey.Bylokhov at oracle.com Mon May 2 21:56:10 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 3 May 2016 00:56:10 +0300 Subject: Code Review Request For 8155757: Encapsulate impl_ methods in animation, canvas, image, input, layout, paint, and text packages In-Reply-To: <5727CAE8.4040706@oracle.com> References: <5723AD0A.9030407@oracle.com> <5726F9E8.5050503@oracle.com> <5727CAE8.4040706@oracle.com> Message-ID: <78b10e23-35d8-6a8d-3091-8359b755a86f@oracle.com> Just FYI. Sometimes the size is matter: https://youtrack.jetbrains.com/issue/IDEA-74599 On 03.05.16 0:47, Kevin Rushforth wrote: > That sounds like a good idea. I like the idea of keeping the reduced > scope (private where possible) for clarity if there isn't a noticeable > performance penalty for doing so. Also, it matches our pattern for > existing accessor methods, some of which directly access private > property fields; changing them would be at odds with our pattern for > declaring properties. > > -- Kevin > > > Jim Graham wrote: >> Maybe we could ask someone in Hotspot if they recognize these bytecode >> patterns and optimize out the helper methods. If that's the case, >> then it is really just down to a bundled size issue... >> >> ...jim >> >> On 5/1/2016 11:55 PM, Chien Yang wrote: >>> Hi Jim, >>> >>> Thanks for sharing this information and your thought. I'm not sure is >>> this saving worth violating the principle of minimizing scope in code. I >>> guess you did bring up a good point let me think over it and discuss >>> with Kevin tomorrow. >>> >>> - Chien >>> >>> On 4/29/16, 4:04 PM, Jim Graham wrote: >>>> One comment on the implementation. For the methods used by an >>>> accessor inner class, if you make them private in the outer class then >>>> that inner class will need a hidden accessor method to be added in the >>>> bytecodes. If you make them package-private then they can access the >>>> method directly. >>>> >>>> Basically, an inner class is really "just another class in the >>>> package, but with a special name" and actually have no access to >>>> private methods in their outer classes at all, but javac works around >>>> this by adding a hidden method that has more open access and using >>>> that. >>>> >>>> An example is Image.getPlatformImage() - you turned it from "public >>>> and impl_" into private. Why not just leave it >>>> package-private/default access? >>>> >>>> For example, compiling this class: >>>> >>>> public class InnerPrivateTest { >>>> private void foo() {} >>>> public class InnerClass { >>>> public void bar() { foo(); } >>>> } >>>> } >>>> >>>> yields this byte code for InnerPrivateTest.class: >>>> >>>> public class InnerPrivateTest { >>>> public InnerPrivateTest(); >>>> Code: >>>> 0: aload_0 >>>> 1: invokespecial #2 // Method >>>> java/lang/Object."":()V >>>> 4: return >>>> >>>> private void foo(); >>>> Code: >>>> 0: return >>>> >>>> static void access$000(InnerPrivateTest); >>>> Code: >>>> 0: aload_0 >>>> 1: invokespecial #1 // Method foo:()V >>>> 4: return >>>> } >>>> >>>> and this for the InnerClass: >>>> >>>> public class InnerPrivateTest$InnerClass { >>>> final InnerPrivateTest this$0; >>>> >>>> public InnerPrivateTest$InnerClass(InnerPrivateTest); >>>> Code: >>>> 0: aload_0 >>>> 1: aload_1 >>>> 2: putfield #1 // Field >>>> this$0:LInnerPrivateTest; >>>> 5: aload_0 >>>> 6: invokespecial #2 // Method >>>> java/lang/Object."":()V >>>> 9: return >>>> >>>> public void bar(); >>>> Code: >>>> 0: aload_0 >>>> 1: getfield #1 // Field >>>> this$0:LInnerPrivateTest; >>>> 4: invokestatic #3 // Method >>>> InnerPrivateTest.access$000:(LInnerPrivateTest;)V >>>> 7: return >>>> } >>>> >>>> Changing the access on foo() to default (package private), yields this >>>> byte code: >>>> >>>> public class InnerPackageTest { >>>> public InnerPackageTest(); >>>> Code: >>>> 0: aload_0 >>>> 1: invokespecial #1 // Method >>>> java/lang/Object."":()V >>>> 4: return >>>> >>>> void foo(); >>>> Code: >>>> 0: return >>>> } >>>> >>>> public class InnerPackageTest$InnerClass { >>>> final InnerPackageTest this$0; >>>> >>>> public InnerPackageTest$InnerClass(InnerPackageTest); >>>> Code: >>>> 0: aload_0 >>>> 1: aload_1 >>>> 2: putfield #1 // Field >>>> this$0:LInnerPackageTest; >>>> 5: aload_0 >>>> 6: invokespecial #2 // Method >>>> java/lang/Object."":()V >>>> 9: return >>>> >>>> public void bar(); >>>> Code: >>>> 0: aload_0 >>>> 1: getfield #1 // Field >>>> this$0:LInnerPackageTest; >>>> 4: invokevirtual #3 // Method >>>> InnerPackageTest.foo:()V >>>> 7: return >>>> } >>>> >>>> ...jim >>>> >>>> On 4/29/16 11:50 AM, Chien Yang wrote: >>>>> Hi Kevin, >>>>> >>>>> Please review the proposed fix: >>>>> >>>>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8155757 >>>>> Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8155757/webrev.00/ >>>>> >>>>> Thanks, >>>>> - Chien -- Best regards, Sergey. From ali.ebrahimi1781 at gmail.com Tue May 3 06:00:37 2016 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Tue, 3 May 2016 10:30:37 +0430 Subject: Code Review Request For 8155757: Encapsulate impl_ methods in animation, canvas, image, input, layout, paint, and text packages In-Reply-To: <5727CAE8.4040706@oracle.com> References: <5723AD0A.9030407@oracle.com> <5726F9E8.5050503@oracle.com> <5727CAE8.4040706@oracle.com> Message-ID: Hi, The guys at valhalla land considering mechanisms for eliminating these garbage accessor methods under new proposal "Nestmates" for java10: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2016-January/000060.html On Tue, May 3, 2016 at 2:17 AM, Kevin Rushforth wrote: > That sounds like a good idea. I like the idea of keeping the reduced scope > (private where possible) for clarity if there isn't a noticeable > performance penalty for doing so. Also, it matches our pattern for existing > accessor methods, some of which directly access private property fields; > changing them would be at odds with our pattern for declaring properties. > > -- Kevin > > > > Jim Graham wrote: > >> Maybe we could ask someone in Hotspot if they recognize these bytecode >> patterns and optimize out the helper methods. If that's the case, then it >> is really just down to a bundled size issue... >> >> ...jim >> >> On 5/1/2016 11:55 PM, Chien Yang wrote: >> >>> Hi Jim, >>> >>> Thanks for sharing this information and your thought. I'm not sure is >>> this saving worth violating the principle of minimizing scope in code. I >>> guess you did bring up a good point let me think over it and discuss >>> with Kevin tomorrow. >>> >>> - Chien >>> >>> On 4/29/16, 4:04 PM, Jim Graham wrote: >>> >>>> One comment on the implementation. For the methods used by an >>>> accessor inner class, if you make them private in the outer class then >>>> that inner class will need a hidden accessor method to be added in the >>>> bytecodes. If you make them package-private then they can access the >>>> method directly. >>>> >>>> Basically, an inner class is really "just another class in the >>>> package, but with a special name" and actually have no access to >>>> private methods in their outer classes at all, but javac works around >>>> this by adding a hidden method that has more open access and using that. >>>> >>>> An example is Image.getPlatformImage() - you turned it from "public >>>> and impl_" into private. Why not just leave it >>>> package-private/default access? >>>> >>>> For example, compiling this class: >>>> >>>> public class InnerPrivateTest { >>>> private void foo() {} >>>> public class InnerClass { >>>> public void bar() { foo(); } >>>> } >>>> } >>>> >>>> yields this byte code for InnerPrivateTest.class: >>>> >>>> public class InnerPrivateTest { >>>> public InnerPrivateTest(); >>>> Code: >>>> 0: aload_0 >>>> 1: invokespecial #2 // Method >>>> java/lang/Object."":()V >>>> 4: return >>>> >>>> private void foo(); >>>> Code: >>>> 0: return >>>> >>>> static void access$000(InnerPrivateTest); >>>> Code: >>>> 0: aload_0 >>>> 1: invokespecial #1 // Method foo:()V >>>> 4: return >>>> } >>>> >>>> and this for the InnerClass: >>>> >>>> public class InnerPrivateTest$InnerClass { >>>> final InnerPrivateTest this$0; >>>> >>>> public InnerPrivateTest$InnerClass(InnerPrivateTest); >>>> Code: >>>> 0: aload_0 >>>> 1: aload_1 >>>> 2: putfield #1 // Field >>>> this$0:LInnerPrivateTest; >>>> 5: aload_0 >>>> 6: invokespecial #2 // Method >>>> java/lang/Object."":()V >>>> 9: return >>>> >>>> public void bar(); >>>> Code: >>>> 0: aload_0 >>>> 1: getfield #1 // Field >>>> this$0:LInnerPrivateTest; >>>> 4: invokestatic #3 // Method >>>> InnerPrivateTest.access$000:(LInnerPrivateTest;)V >>>> 7: return >>>> } >>>> >>>> Changing the access on foo() to default (package private), yields this >>>> byte code: >>>> >>>> public class InnerPackageTest { >>>> public InnerPackageTest(); >>>> Code: >>>> 0: aload_0 >>>> 1: invokespecial #1 // Method >>>> java/lang/Object."":()V >>>> 4: return >>>> >>>> void foo(); >>>> Code: >>>> 0: return >>>> } >>>> >>>> public class InnerPackageTest$InnerClass { >>>> final InnerPackageTest this$0; >>>> >>>> public InnerPackageTest$InnerClass(InnerPackageTest); >>>> Code: >>>> 0: aload_0 >>>> 1: aload_1 >>>> 2: putfield #1 // Field >>>> this$0:LInnerPackageTest; >>>> 5: aload_0 >>>> 6: invokespecial #2 // Method >>>> java/lang/Object."":()V >>>> 9: return >>>> >>>> public void bar(); >>>> Code: >>>> 0: aload_0 >>>> 1: getfield #1 // Field >>>> this$0:LInnerPackageTest; >>>> 4: invokevirtual #3 // Method >>>> InnerPackageTest.foo:()V >>>> 7: return >>>> } >>>> >>>> ...jim >>>> >>>> On 4/29/16 11:50 AM, Chien Yang wrote: >>>> >>>>> Hi Kevin, >>>>> >>>>> Please review the proposed fix: >>>>> >>>>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8155757 >>>>> Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8155757/webrev.00/ >>>>> >>>>> Thanks, >>>>> - Chien >>>>> >>>> -- Best Regards, Ali Ebrahimi From David.Hill at Oracle.com Tue May 3 14:24:58 2016 From: David.Hill at Oracle.com (David Hill) Date: Tue, 03 May 2016 10:24:58 -0400 Subject: review: [JavaFX] Conditional support for GTK 3 on Linux Message-ID: <5728B4BA.2040108@Oracle.com> Kevin, Phil, https://bugs.openjdk.java.net/browse/JDK-8087516 [JavaFX] Conditional support for GTK 3 on Linux Here is the latest version of the changes. This addresses the issues raised by Kevin, as well as some other minor cleanups. This passes a FULL_TEST and Robot manual tests with GTK 2 & 3 for me. http://cr.openjdk.java.net/~ddhill/8087516.2/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From David.Hill at Oracle.com Tue May 3 16:45:21 2016 From: David.Hill at Oracle.com (David Hill) Date: Tue, 03 May 2016 12:45:21 -0400 Subject: review: Message-ID: <5728D5A1.8090007@Oracle.com> Kevin, please review this fix to update our handling of -Xpatch with tests and provide a @xpatch.args for general developement. https://bugs.openjdk.java.net/browse/JDK-8155862 http://cr.openjdk.java.net/~ddhill/8155862 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From chien.yang at oracle.com Wed May 4 06:24:19 2016 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 03 May 2016 23:24:19 -0700 Subject: [9] Code Review Request For 8155762: Encapsulate JavaFX impl_* implementation methods in transform package Message-ID: <57299593.2080905@oracle.com> Kevin and Jim, Please review the proposed fix: Webrev: https://bugs.openjdk.java.net/browse/JDK-8155762 JIRA: http://cr.openjdk.java.net/~ckyang/JDK-8155762/webrev.00/ Thanks, - Chien From kevin.rushforth at oracle.com Wed May 4 17:06:02 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 04 May 2016 10:06:02 -0700 Subject: [9] review request: 8091308: Define fine-grained permissions for JavaFX Message-ID: <572A2BFA.2070806@oracle.com> Jonathan and Chien, Please review the following, which adds fine-grained permissions to FX (following a similar pattern to that of AWT). https://bugs.openjdk.java.net/browse/JDK-8091308 http://cr.openjdk.java.net/~kcr/8091308/webrev.02/ http://cr.openjdk.java.net/~kcr/8091308/docs.02/javafx/util/FXPermission.html -- Kevin From David.Hill at Oracle.com Wed May 4 18:56:22 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 04 May 2016 14:56:22 -0400 Subject: review v3: [JavaFX] Conditional support for GTK 3 on Linux Message-ID: <572A45D6.7000301@Oracle.com> version 3: http://cr.openjdk.java.net/~ddhill/8087516.3/ This reworks the loading of the gtk symbols, providing for trying .so.0 first, and falling forward or back between 2 & 3. The meat of the change in the rework in wrapper_main.c I also removed the block of code mentioned by Serge in GlassApplication.cpp -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From arunprasad.rajkumar at oracle.com Thu May 5 08:57:33 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Thu, 5 May 2016 14:27:33 +0530 Subject: [graphics] [9] Review request for 8155903: Crash while running imported/w3c/canvas/2d.gradient.interpolate.overlap2.html Message-ID: <572B0AFD.5070606@oracle.com> Hello Jim, Please review the below patch. JIRA: https://bugs.openjdk.java.net/browse/JDK-8155903 Webrev: http://cr.openjdk.java.net/~arajkumar/8155903/webrev.01 Issue: Divide by zero while adding multiple gradient stops at same offset. Regards, Arun From David.Hill at Oracle.com Thu May 5 13:42:39 2016 From: David.Hill at Oracle.com (David Hill) Date: Thu, 05 May 2016 09:42:39 -0400 Subject: JFX - Running with Jigsaw in development Message-ID: <572B4DCF.7000104@Oracle.com> We have a new trick in the FX repo to help with running FX apps backed by a Jigsaw enabled build. If you build FX with JIGSAW_HOME set to a JDK 9 build later than build 110, then the Jigsaw modules will be generated. These modules can be used with -Xpatch to override the modules in JDK9. Unfortunately each module must be listed separately, and we need a -Djava.library.path to find the built native libraries - a very verbose command line... But... recently added to the build, a new file is now created: build/xpatch.args that has all of this for you. export JIGSAW_HOME="path_to_top_of_JDK9" export JFX_BUILD="path_to_top_of_your_repo" alias javafx='$JIGSAW_HOME/bin/java @$JFX_BUILD/build/xpatch.args' This alias uses the @argfile mechanism to include all that Xpatch/java.library.path verbosity to create a single command to run FX backed by your recently built binaries. Get your Jigsaw enabled JDK9 preview here: https://jdk9.java.net/download/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From N.C.C.Brown at kent.ac.uk Thu May 5 14:19:17 2016 From: N.C.C.Brown at kent.ac.uk (Neil Brown) Date: Thu, 5 May 2016 15:19:17 +0100 Subject: Linux SwingNode focus work around? Message-ID: <572B5665.1040403@kent.ac.uk> Hi, I recently found what seems to be a bug involving SwingNode and new windows on Linux. Essentially, when you have a SwingNode in an FX window, and show a new pure-Swing window, components in the new window will not receive focus even when clicked on, unless you focus away to another application and back again. I've confirmed it on several Ubuntu machines, using Oracle JDKs including 8u77, 8u91 and 9-ea+115. The problem is not present on Windows or Mac. I have filed this as a bug in the Java bug tracker (JI-9036410), but this will make a big difference to our plans as it prevents us from using SwingNode as part of a plan to slowly transition our application across to FX until the bug gets fixed. So I wondered if anyone here might have an idea for a work-around? No fix too hacky! I've tried all sorts of requestFocus calls but that doesn't seem to do it. It's not a mouse issue: a mouse listener receives the clicks, but focus is not correctly transferred to the new window. Making the new window an FX window with SwingNode inside can be used to avoid the problem, but that would mean transitioning all our Swing windows to FX or FX/SwingNode, which is a lot to do in one step. So I wondered if anyone here had any better ideas, or had encountered the same bug and already worked around it. Thanks, Neil. P.S. Code to reproduce -- using either the FX menu or Swing button to show the new window has the same issue: ///////////////////////////////////////// import javax.swing.*; import javafx.application.Application; import javafx.embed.swing.SwingNode; import javafx.scene.Scene; import javafx.scene.control.Menu; import javafx.scene.control.MenuBar; import javafx.scene.control.MenuItem; import javafx.scene.layout.BorderPane; import javafx.stage.Stage; public class TestSwingNodeWindow extends Application { @Override public void start(Stage primaryStage) throws Exception { SwingNode swingNode = new SwingNode(); BorderPane root = new BorderPane(swingNode); SwingUtilities.invokeAndWait(() -> { JPanel panel = new JPanel(); JButton button = new JButton("Open window"); button.addActionListener(e -> { showSwingTextFieldWindow(); // This makes it work (but not a realistic solution): //Platform.runLater(() -> root.getChildren().clear()); }); panel.add(button); swingNode.setContent(panel); }); MenuItem menuItem = new MenuItem("Show window"); menuItem.setOnAction(e -> SwingUtilities.invokeLater(this::showSwingTextFieldWindow)); root.setTop(new MenuBar(new Menu("Menu", null, menuItem))); primaryStage.setScene(new Scene(root, 400, 400)); primaryStage.show(); } private void showSwingTextFieldWindow() { JFrame window = new JFrame("The new window"); window.add(new JTextField("text field")); window.pack(); window.setVisible(true); } } ///////////////////////////////////////////// From kevin.rushforth at oracle.com Thu May 5 15:24:43 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 May 2016 08:24:43 -0700 Subject: JFX - Running with Jigsaw in development In-Reply-To: <572B4DCF.7000104@Oracle.com> References: <572B4DCF.7000104@Oracle.com> Message-ID: <572B65BB.6080903@oracle.com> Thanks, Dave. This is a great step forward and is a necessary piece to enable us to eventually move to a later JDK 9 for building JavaFX (we are stuck at build 109 for now). -- Kevin David Hill wrote: > > We have a new trick in the FX repo to help with running FX apps backed > by a Jigsaw enabled build. > > If you build FX with JIGSAW_HOME set to a JDK 9 build later than build > 110, then the Jigsaw modules will be generated. These modules can be > used with -Xpatch to override the modules in JDK9. Unfortunately each > module must be listed separately, and we need a -Djava.library.path to > find the built native libraries - a very verbose command line... > > But... recently added to the build, a new file is now created: > build/xpatch.args that has all of this for you. > > export JIGSAW_HOME="path_to_top_of_JDK9" > export JFX_BUILD="path_to_top_of_your_repo" > alias javafx='$JIGSAW_HOME/bin/java @$JFX_BUILD/build/xpatch.args' > > This alias uses the @argfile mechanism to include all that > Xpatch/java.library.path verbosity to create a single command to run > FX backed by your recently built binaries. > > Get your Jigsaw enabled JDK9 preview here: > https://jdk9.java.net/download/ > From philip.race at oracle.com Thu May 5 18:12:08 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 05 May 2016 11:12:08 -0700 Subject: RFR: 8152423: Generated temp files (+JXF...temp) for custom fonts not deleted on exit. Message-ID: <572B8CF8.40109@oracle.com> Please review :- Bug : https://bugs.openjdk.java.net/browse/JDK-8152423 Fix : http://cr.openjdk.java.net/~prr/8152423/ "Release" was not being called on the DirectWrite font object so it held a reference to the file, which on Windows prevents the file from being deleted. -phil From james.graham at oracle.com Thu May 5 18:21:23 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 5 May 2016 11:21:23 -0700 Subject: [graphics] [9] Review request for 8155903: Crash while running imported/w3c/canvas/2d.gradient.interpolate.overlap2.html In-Reply-To: <572B0AFD.5070606@oracle.com> References: <572B0AFD.5070606@oracle.com> Message-ID: <572B8F23.1000601@oracle.com> Hi Arun, The change you made to the calculateSingleArray method looks like it produces a bad array of color stops for the case where Imin is 0. You should fall into the calculateMultipleArray method instead which should not have any trouble with zero length intervals. At that point you don't have to have any code in calculateSingleArray that deals with Imin being zero because that can be part of its calling contract. That is the quick fix. The harder fix that would let us maintain speed when there is a zero interval would be to teach the code what to do in that special case. Basically a zero interval means that we have a case where approaching the interval point from the left is interpolating towards colorA, but leaving that point from the right is interpolating from colorB, with a sudden transition between those 2. In that case, a zero interval shouldn't affect the Imin, since the Imin is trying to determine the size of each interpolated region and we don't interpolate across a zero-sized interval. So, the scan for Imin would simply ignore zero length intervals. Later, the code that populates the array in the calculateSingleArray function would know that the zero length interval simply means swap in a new "from color" without any actual interpolation. Getting that harder fix right would require a lot of testing, so it may be better to do the quick fix now to stop the exceptions and then deal with the optimization as a tweak filed for later... ...jim On 05/05/2016 01:57 AM, Arunprasad Rajkumar wrote: > Hello Jim, > > Please review the below patch. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8155903 > > Webrev: http://cr.openjdk.java.net/~arajkumar/8155903/webrev.01 > > Issue: Divide by zero while adding multiple gradient stops at same offset. > > Regards, > Arun > > > From james.graham at oracle.com Thu May 5 18:26:40 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 5 May 2016 11:26:40 -0700 Subject: RFR: 8152423: Generated temp files (+JXF...temp) for custom fonts not deleted on exit. In-Reply-To: <572B8CF8.40109@oracle.com> References: <572B8CF8.40109@oracle.com> Message-ID: <572B9060.3090909@oracle.com> Is this true of any other objects managed by DWDisposer? Would it be better to simply run through the DWDisposer queue on shutdown and force it to dispose (i.e. release) everything it has? ...jim On 05/05/2016 11:12 AM, Phil Race wrote: > Please review :- > Bug : https://bugs.openjdk.java.net/browse/JDK-8152423 > Fix : http://cr.openjdk.java.net/~prr/8152423/ > > > "Release" was not being called on the DirectWrite font object > so it held a reference to the file, which on Windows prevents > the file from being deleted. > > -phil From philip.race at oracle.com Thu May 5 18:40:28 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 05 May 2016 11:40:28 -0700 Subject: RFR: 8152423: Generated temp files (+JXF...temp) for custom fonts not deleted on exit. In-Reply-To: <572B9060.3090909@oracle.com> References: <572B8CF8.40109@oracle.com> <572B9060.3090909@oracle.com> Message-ID: <572B939C.5000609@oracle.com> On 05/05/2016 11:26 AM, Jim Graham wrote: > Is this true of any other objects managed by DWDisposer? DWDisposer is only the class used to implement "dispose()" of a single DWFontFile that occurs during running/gc. It doesn't really "manage" anything and I don't see it used to dispose any other resource. > Would it be better to simply run through the DWDisposer queue on > shutdown and force it to dispose (i.e. release) everything it has? There isn't a "DWDisposer" queue - it is the shared disposer queue for all resources across Prism - so far as I can tell anyway. This clean up on exit of font files is initiated from a shutdown hook specific to the temporary font files (shared, not DW specific). To be able to delete the files we need to be sure that Release() was called before File.delete(). So we either would need the font file shutdown hook to take ownership of first releasing other Prism resources as well or find a way to kick off a different hook specific to DWDisposer and ensure it runs before the deletion hook. I am not sure there is any way to guarantee that order. Also if we do an 8ux backport I'd want to do it this simpler way there even if something different were done for 9. -phil. > > ...jim > > On 05/05/2016 11:12 AM, Phil Race wrote: >> Please review :- >> Bug : https://bugs.openjdk.java.net/browse/JDK-8152423 >> Fix : http://cr.openjdk.java.net/~prr/8152423/ >> >> >> "Release" was not being called on the DirectWrite font object >> so it held a reference to the file, which on Windows prevents >> the file from being deleted. >> >> -phil From james.graham at oracle.com Thu May 5 19:16:08 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 5 May 2016 12:16:08 -0700 Subject: RFR: 8152423: Generated temp files (+JXF...temp) for custom fonts not deleted on exit. In-Reply-To: <572B939C.5000609@oracle.com> References: <572B8CF8.40109@oracle.com> <572B9060.3090909@oracle.com> <572B939C.5000609@oracle.com> Message-ID: <572B9BF8.3090605@oracle.com> In that case, in order to avoid race conditions (GC could be accidentally triggered by this or subsequent shutdown hooks in the system), it should be released by calling disposer.dispose() instead of directly calling Release (still setting fontFace to null just in case). That will ensure only one release per fontFace. Also, in the constructor it looks like we'll construct a disposer for a null fontFace. I don't think it hurts anything, and probably shouldn't happen in practice, but still seems odd... ...jim On 05/05/2016 11:40 AM, Phil Race wrote: > > On 05/05/2016 11:26 AM, Jim Graham wrote: >> Is this true of any other objects managed by DWDisposer? > > DWDisposer is only the class used to implement "dispose()" of > a single DWFontFile that occurs during running/gc. > > It doesn't really "manage" anything and I don't see it used > to dispose any other resource. > >> Would it be better to simply run through the DWDisposer queue on >> shutdown and force it to dispose (i.e. release) everything it has? > > There isn't a "DWDisposer" queue - it is the shared disposer queue for > all resources across Prism - so far as I can tell anyway. > > This clean up on exit of font files is initiated from a shutdown > hook specific to the temporary font files (shared, not DW specific). > To be able to delete the files we need to be sure that Release() was > called before File.delete(). > So we either would need the font file shutdown hook to take ownership > of first releasing other Prism resources as well or find a way to kick > off a different > hook specific to DWDisposer and ensure it runs before the deletion hook. > I am not sure there is any way to guarantee that order. > > Also if we do an 8ux backport I'd want to do it this simpler way there > even if something different were done for 9. > > -phil. > >> >> ...jim >> >> On 05/05/2016 11:12 AM, Phil Race wrote: >>> Please review :- >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8152423 >>> Fix : http://cr.openjdk.java.net/~prr/8152423/ >>> >>> >>> "Release" was not being called on the DirectWrite font object >>> so it held a reference to the file, which on Windows prevents >>> the file from being deleted. >>> >>> -phil > From vadim.pakhnushev at oracle.com Fri May 6 14:30:28 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 6 May 2016 17:30:28 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <572CAA84.1030600@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From kevin.rushforth at oracle.com Fri May 6 15:28:02 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 06 May 2016 08:28:02 -0700 Subject: Result: New OpenJFX Committer: Arunprasad Rajkumar Message-ID: <572CB802.2020404@oracle.com> Voting for Arunprasad Rajkumar [1] to OpenJFX Committer [2] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] http://openjdk.java.net/census#arajkumar [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2016-April/019017.html From David.Hill at Oracle.com Fri May 6 18:45:52 2016 From: David.Hill at Oracle.com (David Hill) Date: Fri, 06 May 2016 14:45:52 -0400 Subject: review v4: [JavaFX] Conditional support for GTK 3 on Linux Message-ID: <572CE660.2000109@Oracle.com> Minor cleanups version 4: http://cr.openjdk.java.net/~ddhill/8087516.4/ changes from 3: http://cr.openjdk.java.net/~ddhill/8087516.4d/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From chien.yang at oracle.com Fri May 6 21:34:11 2016 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 6 May 2016 14:34:11 -0700 Subject: [9] Code Review Request For 8156170: Clean up Stage and StageHelper Message-ID: <572D0DD3.2080002@oracle.com> Hi Kevin and Jonathan, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8156170 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8156170/webrev.00/ - Chien From alexander.matveev at oracle.com Sat May 7 02:04:09 2016 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 6 May 2016 19:04:09 -0700 Subject: [8u, 9] Review request for 8154287: Intermittent crash when disposing MediaPlayer Message-ID: <2979dd03-2164-32ee-ab28-7879b5d13980@oracle.com> Hi Kevin and David, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8154287 Fixed intermittent crash when disposing MediaPlayer. Thanks, Alexander From alexander.matveev at oracle.com Sat May 7 02:33:48 2016 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 6 May 2016 19:33:48 -0700 Subject: [8u, 9] Review request for 8153534: Intermittent hang in GSTMedia.gstDispose Message-ID: <99f79eaa-978f-d511-3f4c-7c757cc210f1@oracle.com> Hi Kevin and David, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8153534 Fixed intermittent hang in GSTMedia.gstDispose. Thanks, Alexander From james.graham at oracle.com Sat May 7 03:10:03 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 6 May 2016 20:10:03 -0700 Subject: [9] Code Review Request For 8155762: Encapsulate JavaFX impl_* implementation methods in transform package In-Reply-To: <57299593.2080905@oracle.com> References: <57299593.2080905@oracle.com> Message-ID: TransformUtils.java - can't this class be deleted now since all it exists to do is to forward to TransformHelper? Alternatively, why create TransformHelper in the first place when it is 90% just a copy of what TransformUtils used to be (ignoring the inner class that got moved to Transform) with an accessor interface thrown in for good measure? Just to change the name? That could be done by using a source rename rather than gutting the old file and creating the new one from scratch...? And we don't need both of them, do we? Transform.java, line 2172 & 2187 - is there a reason to forward to the factory rather than just instantiating directly? Transform.java, line 2177 & 2189 - I suppose the reason that the arguments are not declared to be Immutable in the first place is that some of these are used from other packages that have no visibility to the Immutable. I was going to say that we should protect against them not being Immutables, but I guess these uses are hidden so it doesn't really affect anything by doing the cast - but it seems sloppy when looking at the code without looking everywhere to see how they are used (which I suppose is short-hand for "someone in the future might mess up because it's not obvious that these can't deal with any other type"). TransformHelper.java, line 108 & 112 - [formatting] perhaps move the m[xyz],tx to the next line for consistency between the two (like 68 & 76)? The implementation of ImmutableTransform copies a fair bit of internals from Affine, but it could just wrap an Affine and save itself all of that work. Arguably, we could make it a super-class of Affine and then it would own all of that code and Affine would subclass only for the modification methods, but we'd either have to expose it as a public class or have an unexplained inaccessible superclass on Affine...? (Also, it's not clear if public methods on a non-public superclass of Affine would be visible through Affine so Affine would either have to have forwarding methods or we'd have to make the super class public). On the other hand, what would be wrong with having a public BaseAffine that was Affine without its modification methods, and having Affine subclass it? It would be effectively Immutable, but using the word Immutable in its name might sound like a promise which would be violated by its subclass - better to leave that property implied by its lack of mutating methods and possibly mentioning the intent in the javadoc... ...jim On 5/3/2016 11:24 PM, Chien Yang wrote: > Kevin and Jim, > > Please review the proposed fix: > > Webrev: https://bugs.openjdk.java.net/browse/JDK-8155762 > JIRA: http://cr.openjdk.java.net/~ckyang/JDK-8155762/webrev.00/ > > Thanks, > - Chien From james.graham at oracle.com Sat May 7 07:06:29 2016 From: james.graham at oracle.com (Jim Graham) Date: Sat, 7 May 2016 00:06:29 -0700 Subject: [8u, 9] Review request for 8156094: ContextMenu shown at wrong position on Windows10 with Extended Screen Message-ID: <97a4c5b2-598a-e1be-dc20-257225971be7@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8156094 webrev for 9-dev: http://cr.openjdk.java.net/~flar/JDK-8156094/9-dev/webrev.00/ webrev for 8u-dev: http://cr.openjdk.java.net/~flar/JDK-8156094/8u-dev/webrev.00/ The two fixes ended up being closer than I thought due to an idiosyncrasy of how Windows arranges screens for system-dpi apps... ...jim From chien.yang at oracle.com Sat May 7 16:23:58 2016 From: chien.yang at oracle.com (Chien Yang) Date: Sat, 07 May 2016 09:23:58 -0700 Subject: [9] Code Review Request For 8155762: Encapsulate JavaFX impl_* implementation methods in transform package In-Reply-To: References: <57299593.2080905@oracle.com> Message-ID: <572E169E.6050100@oracle.com> Hi Jim, Just quick reply to some of your questions. 1) TransformUtils.java: My initial take was to delete this class but after chatting with Kevin, we decided to keep it in the interest of limiting the scope of this change. Moving those methods will touch much more files. We have about 2 weeks to finish the whole encapsulation of all JavaFX impl_* methods. 2) TransformHelper.java: This is the class naming pattern we use to encapsulate all accessor interface classes. Also only less than half of TransformUtils.java was moved into TransformHelper.java. A big portion, ImmutableTransform, has to move into Transform.java. 3) ImmutableTransform: Yes, this is unclean in my opinion when I was reading it. However this is design/implementation cleanup work is out of the scope of this JIRA. I would suggest we file a separate JIRA for it and since you are the code owner of Transform you can have it too! :-) Lastly, JavaFX code review is done in the JIRA so that discussion of that issue will stay in that JIRA. Thanks, - Chien On 5/6/16, 8:10 PM, Jim Graham wrote: > TransformUtils.java - can't this class be deleted now since all it > exists to do is to forward to TransformHelper? > > Alternatively, why create TransformHelper in the first place when it > is 90% just a copy of what TransformUtils used to be (ignoring the > inner class that got moved to Transform) with an accessor interface > thrown in for good measure? Just to change the name? That could be > done by using a source rename rather than gutting the old file and > creating the new one from scratch...? And we don't need both of them, > do we? > > Transform.java, line 2172 & 2187 - is there a reason to forward to the > factory rather than just instantiating directly? > > Transform.java, line 2177 & 2189 - I suppose the reason that the > arguments are not declared to be Immutable in the first place is that > some of these are used from other packages that have no visibility to > the Immutable. I was going to say that we should protect against them > not being Immutables, but I guess these uses are hidden so it doesn't > really affect anything by doing the cast - but it seems sloppy when > looking at the code without looking everywhere to see how they are > used (which I suppose is short-hand for "someone in the future might > mess up because it's not obvious that these can't deal with any other > type"). > > TransformHelper.java, line 108 & 112 - [formatting] perhaps move the > m[xyz],tx to the next line for consistency between the two (like 68 & > 76)? > > The implementation of ImmutableTransform copies a fair bit of > internals from Affine, but it could just wrap an Affine and save > itself all of that work. Arguably, we could make it a super-class of > Affine and then it would own all of that code and Affine would > subclass only for the modification methods, but we'd either have to > expose it as a public class or have an unexplained inaccessible > superclass on Affine...? (Also, it's not clear if public methods on a > non-public superclass of Affine would be visible through Affine so > Affine would either have to have forwarding methods or we'd have to > make the super class public). > > On the other hand, what would be wrong with having a public BaseAffine > that was Affine without its modification methods, and having Affine > subclass it? It would be effectively Immutable, but using the word > Immutable in its name might sound like a promise which would be > violated by its subclass - better to leave that property implied by > its lack of mutating methods and possibly mentioning the intent in the > javadoc... > > ...jim > > On 5/3/2016 11:24 PM, Chien Yang wrote: >> Kevin and Jim, >> >> Please review the proposed fix: >> >> Webrev: https://bugs.openjdk.java.net/browse/JDK-8155762 >> JIRA: http://cr.openjdk.java.net/~ckyang/JDK-8155762/webrev.00/ >> >> Thanks, >> - Chien From arunprasad.rajkumar at oracle.com Mon May 9 13:16:39 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Mon, 9 May 2016 18:46:39 +0530 Subject: [graphics] [9] Review request for 8155903: Crash while running imported/w3c/canvas/2d.gradient.interpolate.overlap2.html In-Reply-To: <572B8F23.1000601@oracle.com> References: <572B0AFD.5070606@oracle.com> <572B8F23.1000601@oracle.com> Message-ID: <57308DB7.5080805@oracle.com> Hello Jim, Thanks for your suggestions. As of now I taking an easy way to fix the issue, New changes are available at http://cr.openjdk.java.net/~arajkumar/8155903/webrev.02 I couldn't write a reliable test case using public javafx APIs, the behavior is intermittent. However I could consistently produce the issue using our DRT internal test case which is based on W3C functional test[1]. [1] http://w3c-test.org/2dcontext/fill-and-stroke-styles/2d.gradient.interpolate.overlap2.html Thanks, Arun On 5/5/2016 11:51 PM, Jim Graham wrote: > Hi Arun, > > The change you made to the calculateSingleArray method looks like it > produces a bad array of color stops for the case where Imin is 0. You > should fall into the calculateMultipleArray method instead which > should not have any trouble with zero length intervals. At that point > you don't have to have any code in calculateSingleArray that deals > with Imin being zero because that can be part of its calling contract. > > That is the quick fix. > > The harder fix that would let us maintain speed when there is a zero > interval would be to teach the code what to do in that special case. > Basically a zero interval means that we have a case where approaching > the interval point from the left is interpolating towards colorA, but > leaving that point from the right is interpolating from colorB, with a > sudden transition between those 2. In that case, a zero interval > shouldn't affect the Imin, since the Imin is trying to determine the > size of each interpolated region and we don't interpolate across a > zero-sized interval. So, the scan for Imin would simply ignore zero > length intervals. Later, the code that populates the array in the > calculateSingleArray function would know that the zero length interval > simply means swap in a new "from color" without any actual interpolation. > > Getting that harder fix right would require a lot of testing, so it > may be better to do the quick fix now to stop the exceptions and then > deal with the optimization as a tweak filed for later... > > ...jim > > On 05/05/2016 01:57 AM, Arunprasad Rajkumar wrote: >> Hello Jim, >> >> Please review the below patch. >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8155903 >> >> Webrev: http://cr.openjdk.java.net/~arajkumar/8155903/webrev.01 >> >> Issue: Divide by zero while adding multiple gradient stops at same >> offset. >> >> Regards, >> Arun >> >> >> From David.Hill at Oracle.com Mon May 9 13:18:14 2016 From: David.Hill at Oracle.com (David Hill) Date: Mon, 09 May 2016 09:18:14 -0400 Subject: Support for GTK 2 & 3 now in JFX Message-ID: <57308E16.4090905@Oracle.com> I added a new feature Friday and would like some help testing it. This new feature (8087516: Conditional support for GTK 3 on Linux) allows us to use either GTK v2 or 3 with JavaFX. The default has not changed - we will use gtk 2 by preference. The help I need is for anyone doing testing on Linux with the current tree - like todays sanity testing. Adding -Djdk.gtk.verbose=true should output the version detected and used. I would appreciate a paste of that along with the OS version. -Djdk.gtk.version=3 toggles the preferred version to GTK 3. Testing using that toggled would also be appreciated, along with a note to me with the OS version. thanks! -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From derijcke.erik at gmail.com Mon May 9 13:39:29 2016 From: derijcke.erik at gmail.com (Erik De Rijcke) Date: Mon, 9 May 2016 15:39:29 +0200 Subject: Support for GTK 2 & 3 now in JFX In-Reply-To: <57308E16.4090905@Oracle.com> References: <57308E16.4090905@Oracle.com> Message-ID: Hi, Are there any known limitations on the gtk3 backends (html5, wayland, ...) that could be used? regards, Erik On Mon, May 9, 2016 at 3:18 PM, David Hill wrote: > > I added a new feature Friday and would like some help testing it. > > This new feature (8087516: Conditional support for GTK 3 on Linux) allows > us to use either GTK v2 or 3 with JavaFX. > > The default has not changed - we will use gtk 2 by preference. > > The help I need is for anyone doing testing on Linux with the current tree > - like todays sanity testing. Adding > > -Djdk.gtk.verbose=true > > should output the version detected and used. I would appreciate a paste of > that along with the OS version. > > -Djdk.gtk.version=3 > > toggles the preferred version to GTK 3. Testing using that toggled would > also be appreciated, along with a note to me with the OS version. > > thanks! > > -- > David Hill > Java Embedded Development > > "A man's feet should be planted in his country, but his eyes should survey > the world." > -- George Santayana (1863 - 1952) > > From David.Hill at Oracle.com Mon May 9 13:50:25 2016 From: David.Hill at Oracle.com (David Hill) Date: Mon, 09 May 2016 09:50:25 -0400 Subject: Support for GTK 2 & 3 now in JFX In-Reply-To: References: <57308E16.4090905@Oracle.com> Message-ID: <573095A1.7020705@Oracle.com> On 5/9/16, 9:39 AM, Erik De Rijcke wrote: > Hi, > > Are there any known limitations on the gtk3 backends (html5, wayland, ...) that could be used? In short - no, but do tell if you find some :-) The problem before was that you can't mix GTK2 & 3 in the same application, so SWT for example that is using GTK3 would crash and burn. With the addition of dynamic loading of GTK we can at least avoid that issue - at least as long as you tell the app which version to use. I have a task to investigate detecting if a version is already in use , but that has some portability issues and might not make the final product. I am not aware of any reason why there would be an issue - unless there is something with the GTK event loop. Let me know if you give it a try. Dave > > regards, > > Erik > > On Mon, May 9, 2016 at 3:18 PM, David Hill > wrote: > > > I added a new feature Friday and would like some help testing it. > > This new feature (8087516: Conditional support for GTK 3 on Linux) allows us to use either GTK v2 or 3 with JavaFX. > > The default has not changed - we will use gtk 2 by preference. > > The help I need is for anyone doing testing on Linux with the current tree - like todays sanity testing. Adding > > -Djdk.gtk.verbose=true > > should output the version detected and used. I would appreciate a paste of that along with the OS version. > > -Djdk.gtk.version=3 > > toggles the preferred version to GTK 3. Testing using that toggled would also be appreciated, along with a note to me with the OS version. > > thanks! > > -- > David Hill > Java Embedded Development > > "A man's feet should be planted in his country, but his eyes should survey the world." > -- George Santayana (1863 - 1952) > > -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From james.graham at oracle.com Mon May 9 18:21:25 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 9 May 2016 11:21:25 -0700 Subject: [graphics] [9] Review request for 8155903: Crash while running imported/w3c/canvas/2d.gradient.interpolate.overlap2.html In-Reply-To: <57308DB7.5080805@oracle.com> References: <572B0AFD.5070606@oracle.com> <572B8F23.1000601@oracle.com> <57308DB7.5080805@oracle.com> Message-ID: <7c032b64-adb4-bf84-e7a4-1a8f4545d9d9@oracle.com> That looks good for the case where Imin is zero, but it appears that we could also have overflow as well, with a single very tiny Imin the accumulation of estimatedSize with an "int" type could easily overflow and become essentially a random number. Changing the estimatedSize variable to a float should prevent that related issue... ...jim On 5/9/16 6:16 AM, Arunprasad Rajkumar wrote: > Hello Jim, > > Thanks for your suggestions. As of now I taking an easy way to fix the issue, New changes are available at > http://cr.openjdk.java.net/~arajkumar/8155903/webrev.02 > > I couldn't write a reliable test case using public javafx APIs, the behavior is intermittent. However I could > consistently produce the issue using our DRT internal test case which is based on W3C functional test[1]. > > [1] http://w3c-test.org/2dcontext/fill-and-stroke-styles/2d.gradient.interpolate.overlap2.html > > Thanks, > Arun > > On 5/5/2016 11:51 PM, Jim Graham wrote: >> Hi Arun, >> >> The change you made to the calculateSingleArray method looks like it produces a bad array of color stops for the case >> where Imin is 0. You should fall into the calculateMultipleArray method instead which should not have any trouble >> with zero length intervals. At that point you don't have to have any code in calculateSingleArray that deals with >> Imin being zero because that can be part of its calling contract. >> >> That is the quick fix. >> >> The harder fix that would let us maintain speed when there is a zero interval would be to teach the code what to do in >> that special case. Basically a zero interval means that we have a case where approaching the interval point from the >> left is interpolating towards colorA, but leaving that point from the right is interpolating from colorB, with a >> sudden transition between those 2. In that case, a zero interval shouldn't affect the Imin, since the Imin is trying >> to determine the size of each interpolated region and we don't interpolate across a zero-sized interval. So, the scan >> for Imin would simply ignore zero length intervals. Later, the code that populates the array in the >> calculateSingleArray function would know that the zero length interval simply means swap in a new "from color" without >> any actual interpolation. >> >> Getting that harder fix right would require a lot of testing, so it may be better to do the quick fix now to stop the >> exceptions and then deal with the optimization as a tweak filed for later... >> >> ...jim >> >> On 05/05/2016 01:57 AM, Arunprasad Rajkumar wrote: >>> Hello Jim, >>> >>> Please review the below patch. >>> >>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8155903 >>> >>> Webrev: http://cr.openjdk.java.net/~arajkumar/8155903/webrev.01 >>> >>> Issue: Divide by zero while adding multiple gradient stops at same offset. >>> >>> Regards, >>> Arun >>> >>> >>> > From r.lichtenberger at gmail.com Mon May 9 18:25:55 2016 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Mon, 9 May 2016 20:25:55 +0200 Subject: Request for backport of JDK-8144501 Message-ID: <5730D633.4080100@gmail.com> We are currently experience null pointer problems that have their root cause in https://bugs.openjdk.java.net/browse/JDK-8144501. The attached example demonstrates the problem: Click the first row, then Ctrl-Click the second row, then Ctrl-Click (i.e. deselect) the first row. Up to jdk1.8.0_51 the output was (correct): 1Doe 1 --- but from jdk1.8.0_60 on the output is: null 1 --- jdk-9-ea+116_linux-x64_bin.tar.gz shows correct output again. Is there a way to backport the fixes (from http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/9b7e677b5314)? Best regards, Robert From kevin.rushforth at oracle.com Mon May 9 18:28:39 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 09 May 2016 11:28:39 -0700 Subject: Request for backport of JDK-8144501 In-Reply-To: <5730D633.4080100@gmail.com> References: <5730D633.4080100@gmail.com> Message-ID: <5730D6D7.2020706@oracle.com> So this suggests that this is a regression introduced in 8u60 (which isn't reflected in the bug). If so, then that could be a justification for the backport. -- Kevin Robert Lichtenberger wrote: > We are currently experience null pointer problems that have their root > cause in https://bugs.openjdk.java.net/browse/JDK-8144501. > > The attached example demonstrates the problem: Click the first row, > then Ctrl-Click the second row, then Ctrl-Click (i.e. deselect) the > first row. > > Up to jdk1.8.0_51 the output was (correct): > 1Doe > 1 > --- > > but from jdk1.8.0_60 on the output is: > null > 1 > --- > > jdk-9-ea+116_linux-x64_bin.tar.gz shows correct output again. > > Is there a way to backport the fixes (from > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/9b7e677b5314)? > > Best regards, > Robert > > From jonathan.giles at oracle.com Mon May 9 18:30:15 2016 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 10 May 2016 06:30:15 +1200 Subject: Request for backport of JDK-8144501 In-Reply-To: <5730D633.4080100@gmail.com> References: <5730D633.4080100@gmail.com> Message-ID: Unfortunately openjfx-dev stripped the attachment, so please send that directly to me. Are you certain that the linked changeset is the only change necessary to resolve the issue? A lot of code has changed in the selection models, and whilst the linked changeset is small enough that it can be backported, I'd be worried that it wasn't sufficient. If you haven't made a build with this change I can do it at some point, but please do flick through your test app. Thanks, -- Jonathan On 10/05/16 6:25 AM, Robert Lichtenberger wrote: > We are currently experience null pointer problems that have their root > cause in https://bugs.openjdk.java.net/browse/JDK-8144501. > > The attached example demonstrates the problem: Click the first row, > then Ctrl-Click the second row, then Ctrl-Click (i.e. deselect) the > first row. > > Up to jdk1.8.0_51 the output was (correct): > 1Doe > 1 > --- > > but from jdk1.8.0_60 on the output is: > null > 1 > --- > > jdk-9-ea+116_linux-x64_bin.tar.gz shows correct output again. > > Is there a way to backport the fixes (from > http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/9b7e677b5314)? > > Best regards, > Robert > > From murali.billa at oracle.com Mon May 9 18:35:29 2016 From: murali.billa at oracle.com (Murali Billa) Date: Mon, 9 May 2016 11:35:29 -0700 (PDT) Subject: [9] Review request for 8150800: NullPointer exception in WebView In-Reply-To: <354fbb80-24ac-40d3-96de-7afb18f9940c@default> References: <2efd6ecd-2204-4d66-8ecc-0bb2977f1a09@default> <15a2a081-054d-4d82-8fff-632d43936d90@default> <24e1299d-e6d4-4b1f-bf32-9d1932418c3c@default> <354fbb80-24ac-40d3-96de-7afb18f9940c@default> Message-ID: Hi Kevin, Alexander Please review below fix. JBS : https://bugs.openjdk.java.net/browse/JDK-8150800 Webrev : http://cr.openjdk.java.net/~mbilla/8150800/webrev.00/ Thanks, Murali From james.graham at oracle.com Mon May 9 18:56:04 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 9 May 2016 11:56:04 -0700 Subject: Support for GTK 2 & 3 now in JFX In-Reply-To: <57308E16.4090905@Oracle.com> References: <57308E16.4090905@Oracle.com> Message-ID: <4747c057-cf20-2c67-73ee-9cb19d1f65da@oracle.com> Should we integrate that into prism.verbose output? ...jim On 5/9/16 6:18 AM, David Hill wrote: > > I added a new feature Friday and would like some help testing it. > > This new feature (8087516: Conditional support for GTK 3 on Linux) allows us to use either GTK v2 or 3 with JavaFX. > > The default has not changed - we will use gtk 2 by preference. > > The help I need is for anyone doing testing on Linux with the current tree - like todays sanity testing. Adding > > -Djdk.gtk.verbose=true > > should output the version detected and used. I would appreciate a paste of that along with the OS version. > > -Djdk.gtk.version=3 > > toggles the preferred version to GTK 3. Testing using that toggled would also be appreciated, along with a note to me > with the OS version. > > thanks! > From kevin.rushforth at oracle.com Mon May 9 20:07:08 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 09 May 2016 13:07:08 -0700 Subject: 9-dev unlocked following sanity testing Message-ID: <5730EDEC.6040603@oracle.com> From kevin.rushforth at oracle.com Mon May 9 23:05:54 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 09 May 2016 16:05:54 -0700 Subject: [9] review request: 8156591: IllegalAccessError in JFXPanel after fix for JDK-8080395 Message-ID: <573117D2.3040607@oracle.com> Phil or Semyon, Please review the following simple fix to comment out JFXPanel's use of the (now package-private) sun.awt.CausedFocusEvent class: https://bugs.openjdk.java.net/browse/JDK-8156591 http://cr.openjdk.java.net/~kcr/8156591/webrev.00/ -- Kevin From tai.hu at veroanalytics.com Tue May 10 02:55:37 2016 From: tai.hu at veroanalytics.com (Tai Hu) Date: Mon, 9 May 2016 22:55:37 -0400 Subject: Create Self Contained Package on Mac Randomly Fail Message-ID: I used ANT script to make self contained package for our JavaFX application (JDK 8u77). On both Windows 64bit and 32bit. I could generate .exe without any issue. However, on Mac OS X, my script randomly fail with a message as follows, Error: Bundler "DMG Installer" (dmg) failed to produce a bundle. Now I have to repeatedly build 4-5 times. Then one of them will succeed. Does anyone have idea on this issue? I have Apple Developer certificate installed, so my package is signed. I tried to turn of gate keeper on my MAC. But it did not help on build success rate at all. Tai From arunprasad.rajkumar at oracle.com Tue May 10 07:23:17 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 10 May 2016 12:53:17 +0530 Subject: [graphics] [9] Review request for 8155903: Crash while running imported/w3c/canvas/2d.gradient.interpolate.overlap2.html In-Reply-To: <7c032b64-adb4-bf84-e7a4-1a8f4545d9d9@oracle.com> References: <572B0AFD.5070606@oracle.com> <572B8F23.1000601@oracle.com> <57308DB7.5080805@oracle.com> <7c032b64-adb4-bf84-e7a4-1a8f4545d9d9@oracle.com> Message-ID: <57318C65.7060602@oracle.com> Hello Jim, Thank you. Incorporated your review comments in http://cr.openjdk.java.net/~arajkumar/8155903/webrev.03 Please take a look. -- Arun On 5/9/2016 11:51 PM, Jim Graham wrote: > That looks good for the case where Imin is zero, but it appears that > we could also have overflow as well, with a single very tiny Imin the > accumulation of estimatedSize with an "int" type could easily overflow > and become essentially a random number. Changing the estimatedSize > variable to a float should prevent that related issue... > > ...jim > > On 5/9/16 6:16 AM, Arunprasad Rajkumar wrote: >> Hello Jim, >> >> Thanks for your suggestions. As of now I taking an easy way to fix >> the issue, New changes are available at >> http://cr.openjdk.java.net/~arajkumar/8155903/webrev.02 >> >> I couldn't write a reliable test case using public javafx APIs, the >> behavior is intermittent. However I could >> consistently produce the issue using our DRT internal test case which >> is based on W3C functional test[1]. >> >> [1] >> http://w3c-test.org/2dcontext/fill-and-stroke-styles/2d.gradient.interpolate.overlap2.html >> >> Thanks, >> Arun >> >> On 5/5/2016 11:51 PM, Jim Graham wrote: >>> Hi Arun, >>> >>> The change you made to the calculateSingleArray method looks like it >>> produces a bad array of color stops for the case >>> where Imin is 0. You should fall into the calculateMultipleArray >>> method instead which should not have any trouble >>> with zero length intervals. At that point you don't have to have >>> any code in calculateSingleArray that deals with >>> Imin being zero because that can be part of its calling contract. >>> >>> That is the quick fix. >>> >>> The harder fix that would let us maintain speed when there is a zero >>> interval would be to teach the code what to do in >>> that special case. Basically a zero interval means that we have a >>> case where approaching the interval point from the >>> left is interpolating towards colorA, but leaving that point from >>> the right is interpolating from colorB, with a >>> sudden transition between those 2. In that case, a zero interval >>> shouldn't affect the Imin, since the Imin is trying >>> to determine the size of each interpolated region and we don't >>> interpolate across a zero-sized interval. So, the scan >>> for Imin would simply ignore zero length intervals. Later, the code >>> that populates the array in the >>> calculateSingleArray function would know that the zero length >>> interval simply means swap in a new "from color" without >>> any actual interpolation. >>> >>> Getting that harder fix right would require a lot of testing, so it >>> may be better to do the quick fix now to stop the >>> exceptions and then deal with the optimization as a tweak filed for >>> later... >>> >>> ...jim >>> >>> On 05/05/2016 01:57 AM, Arunprasad Rajkumar wrote: >>>> Hello Jim, >>>> >>>> Please review the below patch. >>>> >>>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8155903 >>>> >>>> Webrev: http://cr.openjdk.java.net/~arajkumar/8155903/webrev.01 >>>> >>>> Issue: Divide by zero while adding multiple gradient stops at same >>>> offset. >>>> >>>> Regards, >>>> Arun >>>> >>>> >>>> >> From vadim.pakhnushev at oracle.com Tue May 10 14:52:57 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 10 May 2016 17:52:57 +0300 Subject: [9] Review request for 8134655: SortedList wrapping a FilteredList causes AIOOBE Message-ID: <9dd81653-afa5-e01a-2236-88f01ba0ad15@oracle.com> Kevin, Chien, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8134655 http://cr.openjdk.java.net/~vadim/8134655/webrev.00/ Thanks, Vadim From kevin.rushforth at oracle.com Tue May 10 22:20:18 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 May 2016 15:20:18 -0700 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. Message-ID: <57325EA2.5090405@oracle.com> All, As a heads-up, we plan to push an updated WebKit to FX 9-dev early next week [1]. If there are no build problems, they will be integrated to 9 master the following week for jdk-9+119. We then plan to backport the newer WebKit (to keep them in sync) to 8u-dev a couple weeks later. The only new tool needed to build this is CMake [2] version 3.4 or later (we will use 3.4.1 to build). Let me know if you have any questions. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8156698 [2] http://cmake.org/ From felix.bembrick at gmail.com Tue May 10 23:24:10 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Wed, 11 May 2016 09:24:10 +1000 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: <57325EA2.5090405@oracle.com> References: <57325EA2.5090405@oracle.com> Message-ID: <324A50CE-B381-4FCB-A354-9022C09AE410@gmail.com> Will this new WebKit finally support WebGL? Just by supporting WebGL in the JavaFX WebView will instantly enable an entire new set of 3D features and access to a plethora of JavaScript 3D libraries for "free". And, Google Maps will finally work too. > On 11 May 2016, at 08:20, Kevin Rushforth wrote: > > All, > > As a heads-up, we plan to push an updated WebKit to FX 9-dev early next week [1]. If there are no build problems, they will be integrated to 9 master the following week for jdk-9+119. We then plan to backport the newer WebKit (to keep them in sync) to 8u-dev a couple weeks later. > > The only new tool needed to build this is CMake [2] version 3.4 or later (we will use 3.4.1 to build). > > Let me know if you have any questions. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8156698 > > [2] http://cmake.org/ > From kevin.rushforth at oracle.com Wed May 11 15:11:48 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 11 May 2016 08:11:48 -0700 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: <324A50CE-B381-4FCB-A354-9022C09AE410@gmail.com> References: <57325EA2.5090405@oracle.com> <324A50CE-B381-4FCB-A354-9022C09AE410@gmail.com> Message-ID: <57334BB4.9080405@oracle.com> No. WebGL support is not planned for JDK 9. We will look at this for JDK 10. -- Kevin Felix Bembrick wrote: > Will this new WebKit finally support WebGL? > > Just by supporting WebGL in the JavaFX WebView will instantly enable an entire new set of 3D features and access to a plethora of JavaScript 3D libraries for "free". > > And, Google Maps will finally work too. > > >> On 11 May 2016, at 08:20, Kevin Rushforth wrote: >> >> All, >> >> As a heads-up, we plan to push an updated WebKit to FX 9-dev early next week [1]. If there are no build problems, they will be integrated to 9 master the following week for jdk-9+119. We then plan to backport the newer WebKit (to keep them in sync) to 8u-dev a couple weeks later. >> >> The only new tool needed to build this is CMake [2] version 3.4 or later (we will use 3.4.1 to build). >> >> Let me know if you have any questions. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8156698 >> >> [2] http://cmake.org/ >> >> From vadim.pakhnushev at oracle.com Wed May 11 15:55:19 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 11 May 2016 18:55:19 +0300 Subject: [9] Review request for 8139848: SortedList should provide a way to map source index to view index Message-ID: <19c01b9a-8bbe-3300-bc6e-f1f4a336f55d@oracle.com> Kevin, Chien, Could you please review the enhancement: https://bugs.openjdk.java.net/browse/JDK-8139848 http://cr.openjdk.java.net/~vadim/8139848/webrev.00/ Thanks, Vadim From felix.bembrick at gmail.com Wed May 11 17:36:39 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Thu, 12 May 2016 03:36:39 +1000 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: <57334BB4.9080405@oracle.com> References: <57325EA2.5090405@oracle.com> <324A50CE-B381-4FCB-A354-9022C09AE410@gmail.com> <57334BB4.9080405@oracle.com> Message-ID: Do you mind if I ask what the rationale behind such a decision is? From an admittedly perhaps totally ignorant outside observer, it would seem to me that any cost/benefit analysis would basically put this feature in the "no brainer" category and should have been implemented at the very least since JFX 8. > On 12 May 2016, at 01:11, Kevin Rushforth wrote: > > No. WebGL support is not planned for JDK 9. We will look at this for JDK 10. > > -- Kevin > > > Felix Bembrick wrote: >> Will this new WebKit finally support WebGL? >> >> Just by supporting WebGL in the JavaFX WebView will instantly enable an entire new set of 3D features and access to a plethora of JavaScript 3D libraries for "free". >> >> And, Google Maps will finally work too. >> >> >>> On 11 May 2016, at 08:20, Kevin Rushforth wrote: >>> >>> All, >>> >>> As a heads-up, we plan to push an updated WebKit to FX 9-dev early next week [1]. If there are no build problems, they will be integrated to 9 master the following week for jdk-9+119. We then plan to backport the newer WebKit (to keep them in sync) to 8u-dev a couple weeks later. >>> >>> The only new tool needed to build this is CMake [2] version 3.4 or later (we will use 3.4.1 to build). >>> >>> Let me know if you have any questions. >>> >>> -- Kevin >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8156698 >>> >>> [2] http://cmake.org/ >>> >>> From kevin.rushforth at oracle.com Thu May 12 15:52:05 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 May 2016 08:52:05 -0700 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: References: <57325EA2.5090405@oracle.com> <324A50CE-B381-4FCB-A354-9022C09AE410@gmail.com> <57334BB4.9080405@oracle.com> Message-ID: <5734A6A5.9050508@oracle.com> It was an issue of resources versus priority and scope. JDK 9 is focused on Jigsaw modularity and a few other minor features. It is more of a "smoothing out" release than a big feature release (except for Jigsaw). We expect JDK 10 to be a somewhat more feature-oriented release. -- Kevin Felix Bembrick wrote: > Do you mind if I ask what the rationale behind such a decision is? > > From an admittedly perhaps totally ignorant outside observer, it would seem to me that any cost/benefit analysis would basically put this feature in the "no brainer" category and should have been implemented at the very least since JFX 8. > > >> On 12 May 2016, at 01:11, Kevin Rushforth wrote: >> >> No. WebGL support is not planned for JDK 9. We will look at this for JDK 10. >> >> -- Kevin >> >> >> Felix Bembrick wrote: >> >>> Will this new WebKit finally support WebGL? >>> >>> Just by supporting WebGL in the JavaFX WebView will instantly enable an entire new set of 3D features and access to a plethora of JavaScript 3D libraries for "free". >>> >>> And, Google Maps will finally work too. >>> >>> >>> >>>> On 11 May 2016, at 08:20, Kevin Rushforth wrote: >>>> >>>> All, >>>> >>>> As a heads-up, we plan to push an updated WebKit to FX 9-dev early next week [1]. If there are no build problems, they will be integrated to 9 master the following week for jdk-9+119. We then plan to backport the newer WebKit (to keep them in sync) to 8u-dev a couple weeks later. >>>> >>>> The only new tool needed to build this is CMake [2] version 3.4 or later (we will use 3.4.1 to build). >>>> >>>> Let me know if you have any questions. >>>> >>>> -- Kevin >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8156698 >>>> >>>> [2] http://cmake.org/ >>>> >>>> >>>> From kevin.rushforth at oracle.com Thu May 12 16:44:01 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 May 2016 09:44:01 -0700 Subject: [9] review request: 8156809: Remove obsolete com.sun.javafx.robot package Message-ID: <5734B2D1.6090302@oracle.com> Hi Chien, Please review the following. https://bugs.openjdk.java.net/browse/JDK-8156809 http://cr.openjdk.java.net/~kcr/8156809/webrev.00/ This is a simple fix to cleanup some dead code that was discovered as part of the review of the encapsulation work you are doing. -- Kevin From felix.bembrick at gmail.com Thu May 12 18:32:58 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 13 May 2016 04:32:58 +1000 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: <5734A6A5.9050508@oracle.com> References: <57325EA2.5090405@oracle.com> <324A50CE-B381-4FCB-A354-9022C09AE410@gmail.com> <57334BB4.9080405@oracle.com> <5734A6A5.9050508@oracle.com> Message-ID: <1AD675BD-C241-4678-9457-AA538654C113@gmail.com> Thanks Kevin. I was more curious as to why WebGL support hasn't been there since day 1, given that WebKit itself supports it. Felix > On 13 May 2016, at 01:52, Kevin Rushforth wrote: > > It was an issue of resources versus priority and scope. JDK 9 is focused on Jigsaw modularity and a few other minor features. It is more of a "smoothing out" release than a big feature release (except for Jigsaw). We expect JDK 10 to be a somewhat more feature-oriented release. > > -- Kevin > > > Felix Bembrick wrote: >> Do you mind if I ask what the rationale behind such a decision is? >> >> From an admittedly perhaps totally ignorant outside observer, it would seem to me that any cost/benefit analysis would basically put this feature in the "no brainer" category and should have been implemented at the very least since JFX 8. >> >> >>> On 12 May 2016, at 01:11, Kevin Rushforth wrote: >>> >>> No. WebGL support is not planned for JDK 9. We will look at this for JDK 10. >>> >>> -- Kevin >>> >>> >>> Felix Bembrick wrote: >>> >>>> Will this new WebKit finally support WebGL? >>>> >>>> Just by supporting WebGL in the JavaFX WebView will instantly enable an entire new set of 3D features and access to a plethora of JavaScript 3D libraries for "free". >>>> >>>> And, Google Maps will finally work too. >>>> >>>> >>>>> On 11 May 2016, at 08:20, Kevin Rushforth wrote: >>>>> >>>>> All, >>>>> >>>>> As a heads-up, we plan to push an updated WebKit to FX 9-dev early next week [1]. If there are no build problems, they will be integrated to 9 master the following week for jdk-9+119. We then plan to backport the newer WebKit (to keep them in sync) to 8u-dev a couple weeks later. >>>>> >>>>> The only new tool needed to build this is CMake [2] version 3.4 or later (we will use 3.4.1 to build). >>>>> >>>>> Let me know if you have any questions. >>>>> >>>>> -- Kevin >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8156698 >>>>> >>>>> [2] http://cmake.org/ >>>>> >>>>> From james.graham at oracle.com Thu May 12 21:43:56 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 12 May 2016 14:43:56 -0700 Subject: [9] Review request for 8137050: Support Linux settings for HiDPI scaling Message-ID: <1401edc2-79ba-6b3d-22ad-7af321335db3@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8137050 webrev: http://cr.openjdk.java.net/~flar/JDK-8137050/webrev-00/ The order of taking scaling parameters in order of higher to lower priority is: - -Dglass.gtk.uiScale system property - Same property in the environment - GDK_SCALE in the environment (optional in Gnome) - g_settings (the typical way to set scaling...) As noted in the bug report, I'll delete the old lines in the Screen constructor in glass_screen.cpp that are currently commented out if there are no other changes noted in the review... I was able to run dev-build-full.sh and got the same errors as I did without the fix. I ran SwingNode toys and none of them scaled despite the fact that I was running on jdk9 and AWT was supposed to support scaling, but they worked fine in that I could manipulate all of the Swing controls. ...jim From Sergey.Bylokhov at oracle.com Thu May 12 22:07:58 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 13 May 2016 01:07:58 +0300 Subject: [9] Review request for 8137050: Support Linux settings for HiDPI scaling In-Reply-To: <1401edc2-79ba-6b3d-22ad-7af321335db3@oracle.com> References: <1401edc2-79ba-6b3d-22ad-7af321335db3@oracle.com> Message-ID: <8e173702-4147-67c9-76c7-30d940b9552f@oracle.com> Hi Jim. Do you plan to implement the new HiDPI API for the Robot class? On 13.05.16 0:43, Jim Graham wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8137050 > webrev: http://cr.openjdk.java.net/~flar/JDK-8137050/webrev-00/ > > The order of taking scaling parameters in order of higher to lower > priority is: > - -Dglass.gtk.uiScale system property > - Same property in the environment > - GDK_SCALE in the environment (optional in Gnome) > - g_settings (the typical way to set scaling...) > > As noted in the bug report, I'll delete the old lines in the Screen > constructor in glass_screen.cpp that are currently commented out if > there are no other changes noted in the review... > > I was able to run dev-build-full.sh and got the same errors as I did > without the fix. > > I ran SwingNode toys and none of them scaled despite the fact that I was > running on jdk9 and AWT was supposed to support scaling, but they worked > fine in that I could manipulate all of the Swing controls. > > ...jim -- Best regards, Sergey. From james.graham at oracle.com Thu May 12 23:53:40 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 12 May 2016 16:53:40 -0700 Subject: [9] Review request for 8137050: Support Linux settings for HiDPI scaling In-Reply-To: <8e173702-4147-67c9-76c7-30d940b9552f@oracle.com> References: <1401edc2-79ba-6b3d-22ad-7af321335db3@oracle.com> <8e173702-4147-67c9-76c7-30d940b9552f@oracle.com> Message-ID: <36b80852-813c-e5ce-847a-956b81b257cb@oracle.com> It is implemented in the FX Robot in that webrev...? ...jim On 5/12/16 3:07 PM, Sergey Bylokhov wrote: > Hi Jim. > Do you plan to implement the new HiDPI API for the Robot class? > > On 13.05.16 0:43, Jim Graham wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8137050 >> webrev: http://cr.openjdk.java.net/~flar/JDK-8137050/webrev-00/ >> >> The order of taking scaling parameters in order of higher to lower >> priority is: >> - -Dglass.gtk.uiScale system property >> - Same property in the environment >> - GDK_SCALE in the environment (optional in Gnome) >> - g_settings (the typical way to set scaling...) >> >> As noted in the bug report, I'll delete the old lines in the Screen >> constructor in glass_screen.cpp that are currently commented out if >> there are no other changes noted in the review... >> >> I was able to run dev-build-full.sh and got the same errors as I did >> without the fix. >> >> I ran SwingNode toys and none of them scaled despite the fact that I was >> running on jdk9 and AWT was supposed to support scaling, but they worked >> fine in that I could manipulate all of the Swing controls. >> >> ...jim > > From Sergey.Bylokhov at oracle.com Fri May 13 03:10:12 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 13 May 2016 06:10:12 +0300 Subject: [9] Review request for 8137050: Support Linux settings for HiDPI scaling In-Reply-To: <36b80852-813c-e5ce-847a-956b81b257cb@oracle.com> References: <1401edc2-79ba-6b3d-22ad-7af321335db3@oracle.com> <8e173702-4147-67c9-76c7-30d940b9552f@oracle.com> <36b80852-813c-e5ce-847a-956b81b257cb@oracle.com> Message-ID: <31db30c1-54e4-522f-c261-c5cc8cbbb222@oracle.com> On 13.05.16 2:53, Jim Graham wrote: > It is implemented in the FX Robot in that webrev...? No, I meant the Robot class itself.I tried to find getHidpiScreenCapture method..., but now I recognized that there is a method+hidpi parameter. >> On 13.05.16 0:43, Jim Graham wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8137050 >>> webrev: http://cr.openjdk.java.net/~flar/JDK-8137050/webrev-00/ >>> >>> The order of taking scaling parameters in order of higher to lower >>> priority is: >>> - -Dglass.gtk.uiScale system property >>> - Same property in the environment >>> - GDK_SCALE in the environment (optional in Gnome) >>> - g_settings (the typical way to set scaling...) >>> >>> As noted in the bug report, I'll delete the old lines in the Screen >>> constructor in glass_screen.cpp that are currently commented out if >>> there are no other changes noted in the review... >>> >>> I was able to run dev-build-full.sh and got the same errors as I did >>> without the fix. >>> >>> I ran SwingNode toys and none of them scaled despite the fact that I was >>> running on jdk9 and AWT was supposed to support scaling, but they worked >>> fine in that I could manipulate all of the Swing controls. >>> >>> ...jim >> >> -- Best regards, Sergey. From hastebrot at gmail.com Fri May 13 04:53:04 2016 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Fri, 13 May 2016 06:53:04 +0200 Subject: Removal of com.sun.javafx.robot Message-ID: Hey, yesterday a code change was made [1, 2] which removes FXRobot and the com.sun.javafx.robot package in JavaFX 9. >The com.sun.javafx.robot package contains obsolete, unused Prism functionality that was intended for testing automation. It was superseded long ago by glass Robot and should be removed as dead code. Unfortunately FXRobot allows a use-case which is not covered by the glass robot. In TestFX we use the FXRobot to fire keytyped events that allow to type arbitrary (Unicode) characters. This solves multiple issues related to non-english keyboards and special characters and simplifies simulation of keyboard input greatly. There is also a commercial JavaFX framework that uses FXRobot to solve this issue; I spoke with the developers a while ago. If possible, could this change be reverted? [1] https://bugs.openjdk.java.net/browse/JDK-8156809 [2] http://cr.openjdk.java.net/~kcr/8156809/webrev.00/ Regards, Benjamin From hastebrot at gmail.com Fri May 13 05:47:51 2016 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Fri, 13 May 2016 07:47:51 +0200 Subject: Removal of com.sun.javafx.robot In-Reply-To: References: Message-ID: **Update:** I've found a work-around and quickly tested it on our test suite. Previously we needed `FXRobot::keyPress()`, `FXRobot::keyType()`, and `FXRobot::keyRelease()`. Since Java 8 it is possible to use `Event.fireEvent()` and create three `KeyEvent`s (PRESS, TYPE, RELEASE). ~~~java Platform.runLater(() -> { Event.fireEvent(scene.getFocusOwner(), keyEvent); }); ~~~ The amount of needed changes for this work-around is small. No revert is needed. Thanks, Benjamin On Fri, May 13, 2016 at 6:53 AM, Benjamin Gudehus wrote: > Hey, > > yesterday a code change was made [1, 2] which removes FXRobot and the > com.sun.javafx.robot package in JavaFX 9. > > >The com.sun.javafx.robot package contains obsolete, unused Prism > functionality that was intended for testing automation. It was superseded > long ago by glass Robot and should be removed as dead code. > > Unfortunately FXRobot allows a use-case which is not covered by the glass > robot. In TestFX we use the FXRobot to fire keytyped events that allow to > type arbitrary (Unicode) characters. This solves multiple issues related to > non-english keyboards and special characters and simplifies simulation of > keyboard input greatly. There is also a commercial JavaFX framework that > uses FXRobot to solve this issue; I spoke with the developers a while ago. > > If possible, could this change be reverted? > > [1] https://bugs.openjdk.java.net/browse/JDK-8156809 > [2] http://cr.openjdk.java.net/~kcr/8156809/webrev.00/ > > Regards, > Benjamin > > From vadim.pakhnushev at oracle.com Fri May 13 14:07:40 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 13 May 2016 17:07:40 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <69cd212e-2f31-ec56-fcf7-b3930c85c5f4@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From kevin.rushforth at oracle.com Fri May 13 14:19:00 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 13 May 2016 07:19:00 -0700 Subject: New OpenJFX Committer: Guru Hb Message-ID: <5735E254.30608@oracle.com> Voting for Guru Hb [1] to OpenJFX Committer [2] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] http://openjdk.java.net/census#ghb [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2016-April/019049.html From kevin.rushforth at oracle.com Fri May 13 14:47:09 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 13 May 2016 07:47:09 -0700 Subject: Removal of com.sun.javafx.robot In-Reply-To: References: Message-ID: <5735E8ED.9050009@oracle.com> I didn't realize that anyone was using the old FXRobot. I don't remember this showing up on Jonathan's list of internal APIs that apps were using, but I may have missed it. I see two choices: 1) revert the change as you suggested...the cost of keeping this code around isn't all that heavy; 2) add the missing functionality into glass robot. The former might be easier in the short term, but the latter is preferable. -- Kevin Benjamin Gudehus wrote: > Hey, > > yesterday a code change was made [1, 2] which removes FXRobot and the > com.sun.javafx.robot package in JavaFX 9. > > >> The com.sun.javafx.robot package contains obsolete, unused Prism >> > functionality that was intended for testing automation. It was superseded > long ago by glass Robot and should be removed as dead code. > > Unfortunately FXRobot allows a use-case which is not covered by the glass > robot. In TestFX we use the FXRobot to fire keytyped events that allow to > type arbitrary (Unicode) characters. This solves multiple issues related to > non-english keyboards and special characters and simplifies simulation of > keyboard input greatly. There is also a commercial JavaFX framework that > uses FXRobot to solve this issue; I spoke with the developers a while ago. > > If possible, could this change be reverted? > > [1] https://bugs.openjdk.java.net/browse/JDK-8156809 > [2] http://cr.openjdk.java.net/~kcr/8156809/webrev.00/ > > Regards, > Benjamin > From kevin.rushforth at oracle.com Fri May 13 14:47:35 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 13 May 2016 07:47:35 -0700 Subject: Removal of com.sun.javafx.robot In-Reply-To: References: Message-ID: <5735E907.9060801@oracle.com> Ah, that's good. -- Kevin Benjamin Gudehus wrote: > **Update:** I've found a work-around and quickly tested it on our test > suite. Previously we needed `FXRobot::keyPress()`, `FXRobot::keyType()`, > and `FXRobot::keyRelease()`. Since Java 8 it is possible to use > `Event.fireEvent()` and create three `KeyEvent`s (PRESS, TYPE, RELEASE). > > ~~~java > Platform.runLater(() -> { > Event.fireEvent(scene.getFocusOwner(), keyEvent); > }); > ~~~ > > The amount of needed changes for this work-around is small. No revert is > needed. > > Thanks, > Benjamin > > > > > On Fri, May 13, 2016 at 6:53 AM, Benjamin Gudehus > wrote: > > >> Hey, >> >> yesterday a code change was made [1, 2] which removes FXRobot and the >> com.sun.javafx.robot package in JavaFX 9. >> >> >>> The com.sun.javafx.robot package contains obsolete, unused Prism >>> >> functionality that was intended for testing automation. It was superseded >> long ago by glass Robot and should be removed as dead code. >> >> Unfortunately FXRobot allows a use-case which is not covered by the glass >> robot. In TestFX we use the FXRobot to fire keytyped events that allow to >> type arbitrary (Unicode) characters. This solves multiple issues related to >> non-english keyboards and special characters and simplifies simulation of >> keyboard input greatly. There is also a commercial JavaFX framework that >> uses FXRobot to solve this issue; I spoke with the developers a while ago. >> >> If possible, could this change be reverted? >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8156809 >> [2] http://cr.openjdk.java.net/~kcr/8156809/webrev.00/ >> >> Regards, >> Benjamin >> >> >> From philip.race at oracle.com Fri May 13 18:53:59 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 13 May 2016 11:53:59 -0700 Subject: RFR: 8152423: Generated temp files (+JXF...temp) for custom fonts not deleted on exit. In-Reply-To: <572B9BF8.3090605@oracle.com> References: <572B8CF8.40109@oracle.com> <572B9060.3090909@oracle.com> <572B939C.5000609@oracle.com> <572B9BF8.3090605@oracle.com> Message-ID: <573622C7.3010808@oracle.com> See updated webrev and comments at https://bugs.openjdk.java.net/browse/JDK-8152423 -phil. On 05/05/2016 12:16 PM, Jim Graham wrote: > In that case, in order to avoid race conditions (GC could be > accidentally triggered by this or subsequent shutdown hooks in the > system), it should be released by calling disposer.dispose() instead > of directly calling Release (still setting fontFace to null just in > case). That will ensure only one release per fontFace. > > Also, in the constructor it looks like we'll construct a disposer for > a null fontFace. I don't think it hurts anything, and probably > shouldn't happen in practice, but still seems odd... > > ...jim > > On 05/05/2016 11:40 AM, Phil Race wrote: >> >> On 05/05/2016 11:26 AM, Jim Graham wrote: >>> Is this true of any other objects managed by DWDisposer? >> >> DWDisposer is only the class used to implement "dispose()" of >> a single DWFontFile that occurs during running/gc. >> >> It doesn't really "manage" anything and I don't see it used >> to dispose any other resource. >> >>> Would it be better to simply run through the DWDisposer queue on >>> shutdown and force it to dispose (i.e. release) everything it has? >> >> There isn't a "DWDisposer" queue - it is the shared disposer queue for >> all resources across Prism - so far as I can tell anyway. >> >> This clean up on exit of font files is initiated from a shutdown >> hook specific to the temporary font files (shared, not DW specific). >> To be able to delete the files we need to be sure that Release() was >> called before File.delete(). >> So we either would need the font file shutdown hook to take ownership >> of first releasing other Prism resources as well or find a way to kick >> off a different >> hook specific to DWDisposer and ensure it runs before the deletion hook. >> I am not sure there is any way to guarantee that order. >> >> Also if we do an 8ux backport I'd want to do it this simpler way there >> even if something different were done for 9. >> >> -phil. >> >>> >>> ...jim >>> >>> On 05/05/2016 11:12 AM, Phil Race wrote: >>>> Please review :- >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8152423 >>>> Fix : http://cr.openjdk.java.net/~prr/8152423/ >>>> >>>> >>>> "Release" was not being called on the DirectWrite font object >>>> so it held a reference to the file, which on Windows prevents >>>> the file from being deleted. >>>> >>>> -phil >> From chien.yang at oracle.com Mon May 16 04:41:43 2016 From: chien.yang at oracle.com (Chien Yang) Date: Sun, 15 May 2016 21:41:43 -0700 Subject: [9] Code Review Request For 8155998: Encapsulate JavaFX impl_* implementation methods in stage package Message-ID: <57394F87.6050808@oracle.com> Hi Jonathan and Kevin, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8155998 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8155998/webrev.00/ Thanks, - Chien From derijcke.erik at gmail.com Mon May 16 12:15:37 2016 From: derijcke.erik at gmail.com (Erik De Rijcke) Date: Mon, 16 May 2016 14:15:37 +0200 Subject: Support for GTK 2 & 3 now in JFX In-Reply-To: <4747c057-cf20-2c67-73ee-9cb19d1f65da@oracle.com> References: <57308E16.4090905@Oracle.com> <4747c057-cf20-2c67-73ee-9cb19d1f65da@oracle.com> Message-ID: I ran into several issues, however I'm not sure they are related to gtk3 first of all it seems there is a dependency on: gsettings-desktop-schemas. I'm not sure how desirable this is (I did not have it installed, installing it fixed the error but I can image people not wanting to install it?) Second, and this seems unrelated to gtk(3?), the screen initialization fails (test was done using gentoo linux on virtualbox with windows 7 as host): Exception in thread "JavaFX Application Thread" java.lang.IllegalArgumentException: Both width and height must be >= 0 at javafx.geometry.Rectangle2D.(Rectangle2D.java:104) at javafx.stage.Screen.nativeToScreen(Screen.java:152) at javafx.stage.Screen.updateConfiguration(Screen.java:88) at javafx.stage.Screen.checkDirty(Screen.java:82) at javafx.stage.Screen.getPrimary(Screen.java:185) at com.sun.javafx.tk.quantum.QuantumToolkit.initSceneGraph(QuantumToolkit.java:298) at com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:340) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:257) at com.sun.glass.ui.Application.lambda$run$1(Application.java:155) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$7(GtkApplication.java:194) at java.lang.Thread.run(Thread.java:804) Nearly all values seem to be -2147483648 I used openjdk9 109 as per instructions of the wiki, and the latest javafx dev. On Mon, May 9, 2016 at 8:56 PM, Jim Graham wrote: > Should we integrate that into prism.verbose output? > > ...jim > > > On 5/9/16 6:18 AM, David Hill wrote: > >> >> I added a new feature Friday and would like some help testing it. >> >> This new feature (8087516: Conditional support for GTK 3 on Linux) allows >> us to use either GTK v2 or 3 with JavaFX. >> >> The default has not changed - we will use gtk 2 by preference. >> >> The help I need is for anyone doing testing on Linux with the current >> tree - like todays sanity testing. Adding >> >> -Djdk.gtk.verbose=true >> >> should output the version detected and used. I would appreciate a paste >> of that along with the OS version. >> >> -Djdk.gtk.version=3 >> >> toggles the preferred version to GTK 3. Testing using that toggled would >> also be appreciated, along with a note to me >> with the OS version. >> >> thanks! >> >> From kevin.rushforth at oracle.com Mon May 16 17:40:05 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 16 May 2016 10:40:05 -0700 Subject: [9] review request: 8157060: [Linux] sandboxed applications fail with AccessControlException Message-ID: <573A05F5.8030109@oracle.com> Jim, Chien, or Dave, Please review: https://bugs.openjdk.java.net/browse/JDK-8157060 http://cr.openjdk.java.net/~kcr/8157060/webrev.00/ Simple fix to use existing pattern to read system properties. -- Kevin From james.graham at oracle.com Mon May 16 20:01:19 2016 From: james.graham at oracle.com (Jim Graham) Date: Mon, 16 May 2016 13:01:19 -0700 Subject: Support for GTK 2 & 3 now in JFX In-Reply-To: References: <57308E16.4090905@Oracle.com> <4747c057-cf20-2c67-73ee-9cb19d1f65da@oracle.com> Message-ID: <573A270F.5080706@oracle.com> These may both be related to the HiDPI fix instead. I added a usage of g_settings in that fix that went in on Friday. It looks like I'll have to check for the schema existing before I access it. Can you file a bug report? (On a side note, the call that grabs the schema does not have a "schema not known" return value - if you ask for a schema that doesn't exist they abort your application. Seems kind of drastic, but the bug reports that request that they simply return null were met with push back because the developers couldn't imagine why anyone would want such a thing (huh?) and later an attempt to return NULL on unrecognized schemas and keys had to be backed out because of the huge disaster the NULL values caused (and somehow ABORT'ing on behalf of the application is better in that case?). Unfortunately I don't see much sanity in those APIs or any support for a case like this of "I'd like to get that value, but if you haven't heard of it, that's fine as I have a backup plan". The only way around this will be to enumerate all schemas and all keys and see if the ones we want are found in the list - a rather extreme workaround for bad error handling behavior in their APIs...) ...jim On 05/16/2016 05:15 AM, Erik De Rijcke wrote: > I ran into several issues, however I'm not sure they are related to gtk3 > > first of all it seems there is a dependency on: gsettings-desktop-schemas. > I'm not sure how desirable this is (I did not have it installed, installing > it fixed the error but I can image people not wanting to install it?) > > Second, and this seems unrelated to gtk(3?), the screen initialization > fails (test was done using gentoo linux on virtualbox with windows 7 as > host): > > Exception in thread "JavaFX Application Thread" > java.lang.IllegalArgumentException: Both width and height must be >= 0 > > at javafx.geometry.Rectangle2D.(Rectangle2D.java:104) > at javafx.stage.Screen.nativeToScreen(Screen.java:152) > at javafx.stage.Screen.updateConfiguration(Screen.java:88) > at javafx.stage.Screen.checkDirty(Screen.java:82) > at javafx.stage.Screen.getPrimary(Screen.java:185) > at > com.sun.javafx.tk.quantum.QuantumToolkit.initSceneGraph(QuantumToolkit.java:298) > at > com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:340) > at > com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:257) > at com.sun.glass.ui.Application.lambda$run$1(Application.java:155) > at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) > at > com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$7(GtkApplication.java:194) > at java.lang.Thread.run(Thread.java:804) > > > Nearly all values seem to be -2147483648 > > > I used openjdk9 109 as per instructions of the wiki, and the latest javafx > dev. > > > On Mon, May 9, 2016 at 8:56 PM, Jim Graham wrote: > >> Should we integrate that into prism.verbose output? >> >> ...jim >> >> >> On 5/9/16 6:18 AM, David Hill wrote: >> >>> >>> I added a new feature Friday and would like some help testing it. >>> >>> This new feature (8087516: Conditional support for GTK 3 on Linux) allows >>> us to use either GTK v2 or 3 with JavaFX. >>> >>> The default has not changed - we will use gtk 2 by preference. >>> >>> The help I need is for anyone doing testing on Linux with the current >>> tree - like todays sanity testing. Adding >>> >>> -Djdk.gtk.verbose=true >>> >>> should output the version detected and used. I would appreciate a paste >>> of that along with the OS version. >>> >>> -Djdk.gtk.version=3 >>> >>> toggles the preferred version to GTK 3. Testing using that toggled would >>> also be appreciated, along with a note to me >>> with the OS version. >>> >>> thanks! >>> >>> From kevin.rushforth at oracle.com Mon May 16 20:25:18 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 16 May 2016 13:25:18 -0700 Subject: 9-dev unlocked following sanity testing Message-ID: <573A2CAE.2010709@oracle.com> From chien.yang at oracle.com Tue May 17 22:14:08 2016 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 17 May 2016 15:14:08 -0700 Subject: [9] Code Review Request For 8157186: Remove unnecessary @treatasprivate tag in source code Message-ID: <573B97B0.6050807@oracle.com> Hi Jonathan and Kevin, Please review this simple clean up fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8157186 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8157186/webrev.00/index.html From james.graham at oracle.com Wed May 18 01:06:30 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 17 May 2016 18:06:30 -0700 Subject: Support for GTK 2 & 3 now in JFX In-Reply-To: <573A270F.5080706@oracle.com> References: <57308E16.4090905@Oracle.com> <4747c057-cf20-2c67-73ee-9cb19d1f65da@oracle.com> <573A270F.5080706@oracle.com> Message-ID: <573BC016.40206@oracle.com> Hi Erik, I tried testing our build under a Gentoo LiveCD. Even the minimal environment of the LiveCD has the org.gnome.desktop.interface schema defined so I'm not sure how minimal your environment was. I did discover that, although the schema was there, it had a value of "0" for the scaling-factor which caused us to create bogus logical screen sizes that probably caused the exception you saw, so simply finding that schema and key is not enough for us to trust the value. I'll add some protection for bad data from the key, but I'm curious to find out how minimal your install was and whether we should simply state our dependency, or if your configuration is likely to be common enough that we should protect against it in our code...? Also, what does: % gsettings get org.gnome.desktop.interface scaling-factor return for your system? If you set it to "1", does FX come up fine? ...jim On 05/16/2016 01:01 PM, Jim Graham wrote: > These may both be related to the HiDPI fix instead. I added a usage of > g_settings in that fix that went in on Friday. It looks like I'll have > to check for the schema existing before I access it. > > Can you file a bug report? > > (On a side note, the call that grabs the schema does not have a "schema > not known" return value - if you ask for a schema that doesn't exist > they abort your application. Seems kind of drastic, but the bug reports > that request that they simply return null were met with push back > because the developers couldn't imagine why anyone would want such a > thing (huh?) and later an attempt to return NULL on unrecognized schemas > and keys had to be backed out because of the huge disaster the NULL > values caused (and somehow ABORT'ing on behalf of the application is > better in that case?). Unfortunately I don't see much sanity in those > APIs or any support for a case like this of "I'd like to get that value, > but if you haven't heard of it, that's fine as I have a backup plan". > The only way around this will be to enumerate all schemas and all keys > and see if the ones we want are found in the list - a rather extreme > workaround for bad error handling behavior in their APIs...) > > ...jim > > On 05/16/2016 05:15 AM, Erik De Rijcke wrote: >> I ran into several issues, however I'm not sure they are related to gtk3 >> >> first of all it seems there is a dependency on: >> gsettings-desktop-schemas. >> I'm not sure how desirable this is (I did not have it installed, >> installing >> it fixed the error but I can image people not wanting to install it?) >> >> Second, and this seems unrelated to gtk(3?), the screen initialization >> fails (test was done using gentoo linux on virtualbox with windows 7 as >> host): >> >> Exception in thread "JavaFX Application Thread" >> java.lang.IllegalArgumentException: Both width and height must be >= 0 >> >> at javafx.geometry.Rectangle2D.(Rectangle2D.java:104) >> at javafx.stage.Screen.nativeToScreen(Screen.java:152) >> at javafx.stage.Screen.updateConfiguration(Screen.java:88) >> at javafx.stage.Screen.checkDirty(Screen.java:82) >> at javafx.stage.Screen.getPrimary(Screen.java:185) >> at >> com.sun.javafx.tk.quantum.QuantumToolkit.initSceneGraph(QuantumToolkit.java:298) >> >> at >> com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:340) >> >> at >> com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:257) >> >> at com.sun.glass.ui.Application.lambda$run$1(Application.java:155) >> at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) >> at >> com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$7(GtkApplication.java:194) >> >> at java.lang.Thread.run(Thread.java:804) >> >> >> Nearly all values seem to be -2147483648 >> >> >> I used openjdk9 109 as per instructions of the wiki, and the latest >> javafx >> dev. >> >> >> On Mon, May 9, 2016 at 8:56 PM, Jim Graham >> wrote: >> >>> Should we integrate that into prism.verbose output? >>> >>> ...jim >>> >>> >>> On 5/9/16 6:18 AM, David Hill wrote: >>> >>>> >>>> I added a new feature Friday and would like some help testing it. >>>> >>>> This new feature (8087516: Conditional support for GTK 3 on Linux) >>>> allows >>>> us to use either GTK v2 or 3 with JavaFX. >>>> >>>> The default has not changed - we will use gtk 2 by preference. >>>> >>>> The help I need is for anyone doing testing on Linux with the current >>>> tree - like todays sanity testing. Adding >>>> >>>> -Djdk.gtk.verbose=true >>>> >>>> should output the version detected and used. I would appreciate a paste >>>> of that along with the OS version. >>>> >>>> -Djdk.gtk.version=3 >>>> >>>> toggles the preferred version to GTK 3. Testing using that toggled >>>> would >>>> also be appreciated, along with a note to me >>>> with the OS version. >>>> >>>> thanks! >>>> >>>> From james.graham at oracle.com Wed May 18 03:52:23 2016 From: james.graham at oracle.com (Jim Graham) Date: Tue, 17 May 2016 20:52:23 -0700 Subject: [9] Review request for 8157213: HiDPI support for Linux creates unnecessary dependency Message-ID: bug: https://bugs.openjdk.java.net/browse/JDK-8157213 webrev: http://cr.openjdk.java.net/~flar/JDK-8157213/webrev-00/ Details of what was fixed are listed in the bug report. This will hopefully fix all of the dependencies that Erik ran into in his Gentoo environment... ...jim From derijcke.erik at gmail.com Wed May 18 18:59:58 2016 From: derijcke.erik at gmail.com (Erik De Rijcke) Date: Wed, 18 May 2016 20:59:58 +0200 Subject: [9] Review request for 8157213: HiDPI support for Linux creates unnecessary dependency In-Reply-To: References: Message-ID: I tested the patch. Without the dependency I get a an enormous stage (I explicitly set it to be 100x100). Debugging shows me the screen is initialized with these values: Screen: ptr:0 adapter:0 depth:24 x:0 y:0 width:0 height:0 platformX:0 platformY:0 platformWidth:1680 platformHeight:946 visibleX:0 visibleY:0 visibleWidth:0 visibleHeight:0 platformScaleX:4.2949673E9 platformScaleY:4.2949673E9 outputScaleX:4.2949673E9 outputScaleY:4.2949673E9 resolutionX:0 resolutionY:0 I assume the scaling factor is not what it should be? With the dependency installed the stage looks fine. On Wed, May 18, 2016 at 5:52 AM, Jim Graham wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8157213 > webrev: http://cr.openjdk.java.net/~flar/JDK-8157213/webrev-00/ > > Details of what was fixed are listed in the bug report. This will > hopefully fix all of the dependencies that Erik ran into in his Gentoo > environment... > > ...jim > > From james.graham at oracle.com Wed May 18 19:55:54 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 18 May 2016 12:55:54 -0700 Subject: [9] Review request for 8157213: HiDPI support for Linux creates unnecessary dependency In-Reply-To: References: Message-ID: <451594ff-bdc1-9a89-bf0e-f08988a8387e@oracle.com> Ah, this is probably me returning a -1 as an uint. If you change the "defval" used (line 167) in the call to query the property from -1 to 0 does it work as intended? ...jim On 5/18/16 11:59 AM, Erik De Rijcke wrote: > I tested the patch. > > Without the dependency I get a an enormous stage (I explicitly set it to be 100x100). Debugging shows me the screen is > initialized with these values: > > Screen: > ptr:0 > adapter:0 > depth:24 > x:0 > y:0 > width:0 > height:0 > platformX:0 > platformY:0 > platformWidth:1680 > platformHeight:946 > visibleX:0 > visibleY:0 > visibleWidth:0 > visibleHeight:0 > platformScaleX:4.2949673E9 > platformScaleY:4.2949673E9 > outputScaleX:4.2949673E9 > outputScaleY:4.2949673E9 > resolutionX:0 > resolutionY:0 > > > I assume the scaling factor is not what it should be? > > With the dependency installed the stage looks fine. > > On Wed, May 18, 2016 at 5:52 AM, Jim Graham > wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8157213 > webrev: http://cr.openjdk.java.net/~flar/JDK-8157213/webrev-00/ > > Details of what was fixed are listed in the bug report. This will hopefully fix all of the dependencies that Erik > ran into in his Gentoo environment... > > ...jim > > From derijcke.erik at gmail.com Wed May 18 20:16:57 2016 From: derijcke.erik at gmail.com (Erik De Rijcke) Date: Wed, 18 May 2016 22:16:57 +0200 Subject: Support for GTK 2 & 3 now in JFX In-Reply-To: <573BC016.40206@oracle.com> References: <57308E16.4090905@Oracle.com> <4747c057-cf20-2c67-73ee-9cb19d1f65da@oracle.com> <573A270F.5080706@oracle.com> <573BC016.40206@oracle.com> Message-ID: Hi, I tried using the gtk3 broadway backend. This results in a segfault. Current thread (0x00007fe8cc0c2000): JavaThread "GtkNativeMainLoopThread" [_thread_in_native, id=21171, stack(0x00007fe8abcad000,0x00007fe8abdae000)] Stack: [0x00007fe8abcad000,0x00007fe8abdae000], sp=0x00007fe8abdac1c0, free space=1020k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libX11.so.6+0x2d32a] XInternAtom+0x2a Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j com.sun.glass.ui.gtk.GtkApplication.staticScreen_getScreens()[Lcom/sun/glass/ui/Screen;+0 j com.sun.glass.ui.Screen.initScreens()V+6 j com.sun.glass.ui.Application.lambda$run$1(Ljava/lang/Runnable;)V+0 j com.sun.glass.ui.Application$$Lambda$44.run()V+4 v ~StubRoutines::call_stub j com.sun.glass.ui.gtk.GtkApplication._runLoop(Ljava/lang/Runnable;Z)V+0 j com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$8(Ljava/lang/Runnable;Z)V+7 j com.sun.glass.ui.gtk.GtkApplication$$Lambda$48.run()V+12 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub It looks like there are still some hard dependencies on X which will obviously not work using a non X gtk back-end. (I verified the broadway backend works by running the gtk3-demo app in my browser first). On Wed, May 18, 2016 at 3:06 AM, Jim Graham wrote: > Hi Erik, > > I tried testing our build under a Gentoo LiveCD. Even the minimal > environment of the LiveCD has the org.gnome.desktop.interface schema > defined so I'm not sure how minimal your environment was. I did discover > that, although the schema was there, it had a value of "0" for the > scaling-factor which caused us to create bogus logical screen sizes that > probably caused the exception you saw, so simply finding that schema and > key is not enough for us to trust the value. I'll add some protection for > bad data from the key, but I'm curious to find out how minimal your install > was and whether we should simply state our dependency, or if your > configuration is likely to be common enough that we should protect against > it in our code...? > > Also, what does: > > % gsettings get org.gnome.desktop.interface scaling-factor > > return for your system? If you set it to "1", does FX come up fine? > > ...jim > > > On 05/16/2016 01:01 PM, Jim Graham wrote: > >> These may both be related to the HiDPI fix instead. I added a usage of >> g_settings in that fix that went in on Friday. It looks like I'll have >> to check for the schema existing before I access it. >> >> Can you file a bug report? >> >> (On a side note, the call that grabs the schema does not have a "schema >> not known" return value - if you ask for a schema that doesn't exist >> they abort your application. Seems kind of drastic, but the bug reports >> that request that they simply return null were met with push back >> because the developers couldn't imagine why anyone would want such a >> thing (huh?) and later an attempt to return NULL on unrecognized schemas >> and keys had to be backed out because of the huge disaster the NULL >> values caused (and somehow ABORT'ing on behalf of the application is >> better in that case?). Unfortunately I don't see much sanity in those >> APIs or any support for a case like this of "I'd like to get that value, >> but if you haven't heard of it, that's fine as I have a backup plan". >> The only way around this will be to enumerate all schemas and all keys >> and see if the ones we want are found in the list - a rather extreme >> workaround for bad error handling behavior in their APIs...) >> >> ...jim >> >> On 05/16/2016 05:15 AM, Erik De Rijcke wrote: >> >>> I ran into several issues, however I'm not sure they are related to gtk3 >>> >>> first of all it seems there is a dependency on: >>> gsettings-desktop-schemas. >>> I'm not sure how desirable this is (I did not have it installed, >>> installing >>> it fixed the error but I can image people not wanting to install it?) >>> >>> Second, and this seems unrelated to gtk(3?), the screen initialization >>> fails (test was done using gentoo linux on virtualbox with windows 7 as >>> host): >>> >>> Exception in thread "JavaFX Application Thread" >>> java.lang.IllegalArgumentException: Both width and height must be >= 0 >>> >>> at javafx.geometry.Rectangle2D.(Rectangle2D.java:104) >>> at javafx.stage.Screen.nativeToScreen(Screen.java:152) >>> at javafx.stage.Screen.updateConfiguration(Screen.java:88) >>> at javafx.stage.Screen.checkDirty(Screen.java:82) >>> at javafx.stage.Screen.getPrimary(Screen.java:185) >>> at >>> >>> com.sun.javafx.tk.quantum.QuantumToolkit.initSceneGraph(QuantumToolkit.java:298) >>> >>> at >>> >>> com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:340) >>> >>> at >>> >>> com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:257) >>> >>> at com.sun.glass.ui.Application.lambda$run$1(Application.java:155) >>> at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) >>> at >>> >>> com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$7(GtkApplication.java:194) >>> >>> at java.lang.Thread.run(Thread.java:804) >>> >>> >>> Nearly all values seem to be -2147483648 >>> >>> >>> I used openjdk9 109 as per instructions of the wiki, and the latest >>> javafx >>> dev. >>> >>> >>> On Mon, May 9, 2016 at 8:56 PM, Jim Graham >>> wrote: >>> >>> Should we integrate that into prism.verbose output? >>>> >>>> ...jim >>>> >>>> >>>> On 5/9/16 6:18 AM, David Hill wrote: >>>> >>>> >>>>> I added a new feature Friday and would like some help testing it. >>>>> >>>>> This new feature (8087516: Conditional support for GTK 3 on Linux) >>>>> allows >>>>> us to use either GTK v2 or 3 with JavaFX. >>>>> >>>>> The default has not changed - we will use gtk 2 by preference. >>>>> >>>>> The help I need is for anyone doing testing on Linux with the current >>>>> tree - like todays sanity testing. Adding >>>>> >>>>> -Djdk.gtk.verbose=true >>>>> >>>>> should output the version detected and used. I would appreciate a paste >>>>> of that along with the OS version. >>>>> >>>>> -Djdk.gtk.version=3 >>>>> >>>>> toggles the preferred version to GTK 3. Testing using that toggled >>>>> would >>>>> also be appreciated, along with a note to me >>>>> with the OS version. >>>>> >>>>> thanks! >>>>> >>>>> >>>>> From derijcke.erik at gmail.com Wed May 18 20:28:26 2016 From: derijcke.erik at gmail.com (Erik De Rijcke) Date: Wed, 18 May 2016 22:28:26 +0200 Subject: [9] Review request for 8157213: HiDPI support for Linux creates unnecessary dependency In-Reply-To: <451594ff-bdc1-9a89-bf0e-f08988a8387e@oracle.com> References: <451594ff-bdc1-9a89-bf0e-f08988a8387e@oracle.com> Message-ID: Yes that seems to fix it. On Wed, May 18, 2016 at 9:55 PM, Jim Graham wrote: > Ah, this is probably me returning a -1 as an uint. If you change the > "defval" used (line 167) in the call to query the property from -1 to 0 > does it work as intended? > > ...jim > > > On 5/18/16 11:59 AM, Erik De Rijcke wrote: > >> I tested the patch. >> >> Without the dependency I get a an enormous stage (I explicitly set it to >> be 100x100). Debugging shows me the screen is >> initialized with these values: >> >> Screen: >> ptr:0 >> adapter:0 >> depth:24 >> x:0 >> y:0 >> width:0 >> height:0 >> platformX:0 >> platformY:0 >> platformWidth:1680 >> platformHeight:946 >> visibleX:0 >> visibleY:0 >> visibleWidth:0 >> visibleHeight:0 >> platformScaleX:4.2949673E9 >> platformScaleY:4.2949673E9 >> outputScaleX:4.2949673E9 >> outputScaleY:4.2949673E9 >> resolutionX:0 >> resolutionY:0 >> >> >> I assume the scaling factor is not what it should be? >> >> With the dependency installed the stage looks fine. >> >> On Wed, May 18, 2016 at 5:52 AM, Jim Graham > > wrote: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8157213 >> webrev: http://cr.openjdk.java.net/~flar/JDK-8157213/webrev-00/ >> >> Details of what was fixed are listed in the bug report. This will >> hopefully fix all of the dependencies that Erik >> ran into in his Gentoo environment... >> >> ...jim >> >> >> From james.graham at oracle.com Wed May 18 20:47:55 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 18 May 2016 13:47:55 -0700 Subject: [9] Review request for 8157213: HiDPI support for Linux creates unnecessary dependency In-Reply-To: References: <451594ff-bdc1-9a89-bf0e-f08988a8387e@oracle.com> Message-ID: New updated webrevs with the new default value at: http://cr.openjdk.java.net/~flar/JDK-8157213/webrev-01/ I also found a way to remove the schema from the Gentoo LiveCD environment and tested that way as well... ...jim On 5/18/16 1:28 PM, Erik De Rijcke wrote: > Yes that seems to fix it. > > On Wed, May 18, 2016 at 9:55 PM, Jim Graham wrote: > >> Ah, this is probably me returning a -1 as an uint. If you change the >> "defval" used (line 167) in the call to query the property from -1 to 0 >> does it work as intended? >> >> ...jim >> >> >> On 5/18/16 11:59 AM, Erik De Rijcke wrote: >> >>> I tested the patch. >>> >>> Without the dependency I get a an enormous stage (I explicitly set it to >>> be 100x100). Debugging shows me the screen is >>> initialized with these values: >>> >>> Screen: >>> ptr:0 >>> adapter:0 >>> depth:24 >>> x:0 >>> y:0 >>> width:0 >>> height:0 >>> platformX:0 >>> platformY:0 >>> platformWidth:1680 >>> platformHeight:946 >>> visibleX:0 >>> visibleY:0 >>> visibleWidth:0 >>> visibleHeight:0 >>> platformScaleX:4.2949673E9 >>> platformScaleY:4.2949673E9 >>> outputScaleX:4.2949673E9 >>> outputScaleY:4.2949673E9 >>> resolutionX:0 >>> resolutionY:0 >>> >>> >>> I assume the scaling factor is not what it should be? >>> >>> With the dependency installed the stage looks fine. >>> >>> On Wed, May 18, 2016 at 5:52 AM, Jim Graham >> > wrote: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8157213 >>> webrev: http://cr.openjdk.java.net/~flar/JDK-8157213/webrev-00/ >>> >>> Details of what was fixed are listed in the bug report. This will >>> hopefully fix all of the dependencies that Erik >>> ran into in his Gentoo environment... >>> >>> ...jim >>> >>> >>> From David.Hill at Oracle.com Thu May 19 00:12:53 2016 From: David.Hill at Oracle.com (David Hill) Date: Wed, 18 May 2016 17:12:53 -0700 Subject: review: remove use of GetPropertyAction Message-ID: <573D0505.5000302@Oracle.com> Kevin, https://bugs.openjdk.java.net/browse/JDK-8157280 webrev: http://cr.openjdk.java.net/~ddhill/8157280 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From chien.yang at oracle.com Thu May 19 05:40:27 2016 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 18 May 2016 22:40:27 -0700 Subject: [9] Code Review Request For 8157295: Encapsulate impl_ methods in Scene and KeyValue classes Message-ID: <573D51CB.4000401@oracle.com> Hi Jonathan and Kevin, Please review the proposed fix: Webrev: https://bugs.openjdk.java.net/browse/JDK-8157295 JIRA: http://cr.openjdk.java.net/~ckyang/JDK-8157295/webrev.00/ Thanks, - Chien From matthieu at brouillard.fr Thu May 19 09:25:28 2016 From: matthieu at brouillard.fr (Matthieu BROUILLARD) Date: Thu, 19 May 2016 11:25:28 +0200 Subject: Problems with multiple WebView Message-ID: Hi all, Inside our application we are integrating web applications using JavaFX WebViews. We are facing issues when opening several webviews on the same URLs (even with different parameters). The states reported to listeners registered using *view.getEngine().getLoadWorker().stateProperty().addListener(...)* become totally incoherent. I have created a simple reproducer test class to demo the issue (1). The gist contains also different executions results in the 3 tested 'modes': - multiple views opening the exact same URL - multiple views opening the same URL with different parameters (html app scenario) - multiple views opening different URLs Only the later is working correctly. Did someone already faced that? I have not found bugs (or only closed ones JDK-8094208, JDK-8129398) related to that, shall I open one? (1): https://gist.github.com/AWXGX/1ee902256169c612d97f0722b79f47c6#file-multiplewebviewbug-java From guru.hb at oracle.com Thu May 19 12:27:00 2016 From: guru.hb at oracle.com (Guru Hb) Date: Thu, 19 May 2016 17:57:00 +0530 Subject: Problems with multiple WebView In-Reply-To: References: Message-ID: Hi Matthieu Brouillard, Please file a bug at http://bugreport.java.com/bugreport/ along with JDK/JRE version and on which platform Windows / Linux / OS X details. Instructions : https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report Thanks, Guru On 19/5/16 2:55 PM, Matthieu BROUILLARD wrote: > Hi all, > > Inside our application we are integrating web applications using JavaFX > WebViews. > > We are facing issues when opening several webviews on the same URLs (even > with different parameters). > The states reported to listeners registered using > > *view.getEngine().getLoadWorker().stateProperty().addListener(...)* > > become totally incoherent. > > I have created a simple reproducer test class to demo the issue > > (1). > > The gist contains also different executions results in the 3 tested 'modes': > - multiple views opening the exact same URL > - multiple views opening the same URL with different parameters (html app > scenario) > - multiple views opening different URLs > > Only the later is working correctly. > > Did someone already faced that? > I have not found bugs (or only closed ones JDK-8094208, JDK-8129398) > related to that, shall I open one? > > (1): > https://gist.github.com/AWXGX/1ee902256169c612d97f0722b79f47c6#file-multiplewebviewbug-java From matthieu at brouillard.fr Thu May 19 13:17:38 2016 From: matthieu at brouillard.fr (Matthieu BROUILLARD) Date: Thu, 19 May 2016 15:17:38 +0200 Subject: Problems with multiple WebView In-Reply-To: References: Message-ID: Done under : JI-9037986. Thanks for the support. On Thu, May 19, 2016 at 2:27 PM, Guru Hb wrote: > Hi Matthieu Brouillard, > > Please file a bug at http://bugreport.java.com/bugreport/ > along with JDK/JRE version and on > which platform Windows / Linux / OS X details. > > Instructions : > https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report > Thanks, > Guru > > On 19/5/16 2:55 PM, Matthieu BROUILLARD wrote: > > Hi all, > > Inside our application we are integrating web applications using JavaFX > WebViews. > > We are facing issues when opening several webviews on the same URLs (even > with different parameters). > The states reported to listeners registered using > > *view.getEngine().getLoadWorker().stateProperty().addListener(...)* > > become totally incoherent. > > I have created a simple reproducer test class to demo the issue > (1). > > The gist contains also different executions results in the 3 tested 'modes': > - multiple views opening the exact same URL > - multiple views opening the same URL with different parameters (html app > scenario) > - multiple views opening different URLs > > Only the later is working correctly. > > Did someone already faced that? > I have not found bugs (or only closed ones JDK-8094208, JDK-8129398) > related to that, shall I open one? > > (1):https://gist.github.com/AWXGX/1ee902256169c612d97f0722b79f47c6#file-multiplewebviewbug-java > > > From philip.race at oracle.com Thu May 19 22:00:32 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 19 May 2016 15:00:32 -0700 Subject: 8139838: Bug in PrismFontFactory generates NullPointerException when loading .ttc font Message-ID: <573E3780.3010901@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8139838 webrev : http://cr.openjdk.java.net/~prr/8139838/ Adds loadFonts() equivalents of the existing loadFont(). The existing loadFont() will now not NPE and will just return the first font in the collection. I have tested this on Mac, Linux and Windows using the included manual LoadFonts.java test and supplying fonts that are not platform fonts. I also verified the temp files are cleaned up. -phil. From David.Hill at Oracle.com Fri May 20 03:31:16 2016 From: David.Hill at Oracle.com (David Hill) Date: Thu, 19 May 2016 20:31:16 -0700 Subject: review: Correct unused import in FXDnD Message-ID: <573E8504.4080003@Oracle.com> Kevin, https://bugs.openjdk.java.net/browse/JDK-8157390 webrev: http://cr.openjdk.java.net/~ddhill/8157390 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From thomas.kruse at jug-muenster.de Fri May 20 15:22:06 2016 From: thomas.kruse at jug-muenster.de (Thomas Kruse) Date: Fri, 20 May 2016 17:22:06 +0200 Subject: JDK9 build 119 fails on Ubuntu Gnome 16.04 Message-ID: <573F2B9E.2030307@jug-muenster.de> Hi, I tested the latest build 119 of JDK9. I was curious to try out the WebKit update, but even a very simple JavaFX class threw the following exception. I tried to force GTK2, since I suspected GTK3 support as the culprit, but this did not help. java -Djdk.gtk.version=2 -Djdk.gtk.verbose=true -cp target/classes sample.Basic Loading GTK libraries version 2 trying GTK library set libgtk-x11-2.0.so.0, libgdk-x11-2.0.so.0, libgdk_pixbuf-2.0.so failed to load libgdk_pixbuf-2.0.so trying GTK library set libgtk-x11-2.0.so, libgdk-x11-2.0.so, libgdk_pixbuf-2.0.so failed to load libgtk-x11-2.0.so trying GTK library set libgtk-3.so.0, libgdk-3.so.0, libgdk_pixbuf-2.0.so.0 using GTK library set libgtk-3.so.0, libgdk-3.so.0, libgdk_pixbuf-2.0.so.0 Exception in thread "JavaFX Application Thread" java.lang.IllegalArgumentException: Both width and height must be >= 0 at javafx.geometry.Rectangle2D.(javafx.graphics at 9-ea/Rectangle2D.java:104) at javafx.stage.Screen.nativeToScreen(javafx.graphics at 9-ea/Screen.java:152) at javafx.stage.Screen.updateConfiguration(javafx.graphics at 9-ea/Screen.java:88) at javafx.stage.Screen.checkDirty(javafx.graphics at 9-ea/Screen.java:82) at javafx.stage.Screen.getPrimary(javafx.graphics at 9-ea/Screen.java:185) at com.sun.javafx.tk.quantum.QuantumToolkit.initSceneGraph(javafx.graphics at 9-ea/QuantumToolkit.java:298) at com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(javafx.graphics at 9-ea/QuantumToolkit.java:340) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(javafx.graphics at 9-ea/QuantumToolkit.java:257) at com.sun.glass.ui.Application.lambda$run$1(javafx.graphics at 9-ea/Application.java:155) at com.sun.glass.ui.gtk.GtkApplication._runLoop(javafx.graphics at 9-ea/Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$8(javafx.graphics at 9-ea/GtkApplication.java:195) at java.lang.Thread.run(java.base at 9-ea/Thread.java:804) -- Java Usergroup Muenster http://www.jug-muenster.de/ From kevin.rushforth at oracle.com Fri May 20 15:30:11 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 May 2016 08:30:11 -0700 Subject: JDK9 build 119 fails on Ubuntu Gnome 16.04 In-Reply-To: <573F2B9E.2030307@jug-muenster.de> References: <573F2B9E.2030307@jug-muenster.de> Message-ID: <573F2D83.8010604@oracle.com> Jim can comment further, but this might be related to the recent Hi-DPI support for Linux that went into build 119. Btw, the updated WebKit will be in build 120. -- Kevin Thomas Kruse wrote: > Hi, > > I tested the latest build 119 of JDK9. I was curious to try out the > WebKit update, but even a very simple JavaFX class threw the following > exception. I tried to force GTK2, since I suspected GTK3 support as the > culprit, but this did not help. > > java -Djdk.gtk.version=2 -Djdk.gtk.verbose=true -cp target/classes > sample.Basic > Loading GTK libraries version 2 > trying GTK library set libgtk-x11-2.0.so.0, libgdk-x11-2.0.so.0, > libgdk_pixbuf-2.0.so > failed to load libgdk_pixbuf-2.0.so > trying GTK library set libgtk-x11-2.0.so, libgdk-x11-2.0.so, > libgdk_pixbuf-2.0.so > failed to load libgtk-x11-2.0.so > trying GTK library set libgtk-3.so.0, libgdk-3.so.0, libgdk_pixbuf-2.0.so.0 > using GTK library set libgtk-3.so.0, libgdk-3.so.0, libgdk_pixbuf-2.0.so.0 > Exception in thread "JavaFX Application Thread" > java.lang.IllegalArgumentException: Both width and height must be >= 0 > at > javafx.geometry.Rectangle2D.(javafx.graphics at 9-ea/Rectangle2D.java:104) > at javafx.stage.Screen.nativeToScreen(javafx.graphics at 9-ea/Screen.java:152) > at > javafx.stage.Screen.updateConfiguration(javafx.graphics at 9-ea/Screen.java:88) > at javafx.stage.Screen.checkDirty(javafx.graphics at 9-ea/Screen.java:82) > at javafx.stage.Screen.getPrimary(javafx.graphics at 9-ea/Screen.java:185) > at > com.sun.javafx.tk.quantum.QuantumToolkit.initSceneGraph(javafx.graphics at 9-ea/QuantumToolkit.java:298) > at > com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(javafx.graphics at 9-ea/QuantumToolkit.java:340) > at > com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(javafx.graphics at 9-ea/QuantumToolkit.java:257) > at > com.sun.glass.ui.Application.lambda$run$1(javafx.graphics at 9-ea/Application.java:155) > at > com.sun.glass.ui.gtk.GtkApplication._runLoop(javafx.graphics at 9-ea/Native > Method) > at > com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$8(javafx.graphics at 9-ea/GtkApplication.java:195) > at java.lang.Thread.run(java.base at 9-ea/Thread.java:804) > > > From David.Hill at Oracle.com Fri May 20 18:47:18 2016 From: David.Hill at Oracle.com (David Hill) Date: Fri, 20 May 2016 11:47:18 -0700 Subject: review: missing export to fxml in base module Message-ID: <573F5BB6.5030805@Oracle.com> Kevin, a patch inline: https://bugs.openjdk.java.net/browse/JDK-8157473 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From David.Hill at Oracle.com Fri May 20 18:58:14 2016 From: David.Hill at Oracle.com (David Hill) Date: Fri, 20 May 2016 11:58:14 -0700 Subject: review: remove old annotations from web Message-ID: <573F5E46.9080609@Oracle.com> Kevin, another inline diff: https://bugs.openjdk.java.net/browse/JDK-8157477 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From chien.yang at oracle.com Fri May 20 21:11:30 2016 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 20 May 2016 14:11:30 -0700 Subject: [9] Code Review Request For 8157350: Encapsulate impl_ methods in Shapes related classes Message-ID: <573F7D82.3080500@oracle.com> Hi Kevin, Please review the proposed fix as we have discussed. JIRA: https://bugs.openjdk.java.net/browse/JDK-8157350 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8157350/webrev.00/ Thanks, - Chien From james.graham at oracle.com Fri May 20 21:27:37 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 20 May 2016 14:27:37 -0700 Subject: JDK9 build 119 fails on Ubuntu Gnome 16.04 In-Reply-To: <573F2D83.8010604@oracle.com> References: <573F2B9E.2030307@jug-muenster.de> <573F2D83.8010604@oracle.com> Message-ID: <53619a77-f0c5-472c-fb81-eccc650d52d9@oracle.com> This should be fixed in the next build (fix is already pushed to our 9-dev FX repo). It was caused by getting a "0" from the GDK APIs that specify the scaling factor. We now protect against that uninitialized value... ...jim On 5/20/16 8:30 AM, Kevin Rushforth wrote: > Jim can comment further, but this might be related to the recent Hi-DPI support for Linux that went into build 119. > > Btw, the updated WebKit will be in build 120. > > -- Kevin > > > Thomas Kruse wrote: >> Hi, >> >> I tested the latest build 119 of JDK9. I was curious to try out the >> WebKit update, but even a very simple JavaFX class threw the following >> exception. I tried to force GTK2, since I suspected GTK3 support as the >> culprit, but this did not help. >> >> java -Djdk.gtk.version=2 -Djdk.gtk.verbose=true -cp target/classes >> sample.Basic >> Loading GTK libraries version 2 >> trying GTK library set libgtk-x11-2.0.so.0, libgdk-x11-2.0.so.0, >> libgdk_pixbuf-2.0.so >> failed to load libgdk_pixbuf-2.0.so >> trying GTK library set libgtk-x11-2.0.so, libgdk-x11-2.0.so, >> libgdk_pixbuf-2.0.so >> failed to load libgtk-x11-2.0.so >> trying GTK library set libgtk-3.so.0, libgdk-3.so.0, libgdk_pixbuf-2.0.so.0 >> using GTK library set libgtk-3.so.0, libgdk-3.so.0, libgdk_pixbuf-2.0.so.0 >> Exception in thread "JavaFX Application Thread" >> java.lang.IllegalArgumentException: Both width and height must be >= 0 >> at >> javafx.geometry.Rectangle2D.(javafx.graphics at 9-ea/Rectangle2D.java:104) >> at javafx.stage.Screen.nativeToScreen(javafx.graphics at 9-ea/Screen.java:152) >> at >> javafx.stage.Screen.updateConfiguration(javafx.graphics at 9-ea/Screen.java:88) >> at javafx.stage.Screen.checkDirty(javafx.graphics at 9-ea/Screen.java:82) >> at javafx.stage.Screen.getPrimary(javafx.graphics at 9-ea/Screen.java:185) >> at >> com.sun.javafx.tk.quantum.QuantumToolkit.initSceneGraph(javafx.graphics at 9-ea/QuantumToolkit.java:298) >> at >> com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(javafx.graphics at 9-ea/QuantumToolkit.java:340) >> at >> com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(javafx.graphics at 9-ea/QuantumToolkit.java:257) >> at >> com.sun.glass.ui.Application.lambda$run$1(javafx.graphics at 9-ea/Application.java:155) >> at >> com.sun.glass.ui.gtk.GtkApplication._runLoop(javafx.graphics at 9-ea/Native >> Method) >> at >> com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$8(javafx.graphics at 9-ea/GtkApplication.java:195) >> at java.lang.Thread.run(java.base at 9-ea/Thread.java:804) >> >> >> From james.graham at oracle.com Fri May 20 21:43:15 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 20 May 2016 14:43:15 -0700 Subject: [9] Code Review Request For 8157350: Encapsulate impl_ methods in Shapes related classes In-Reply-To: <573F7D82.3080500@oracle.com> References: <573F7D82.3080500@oracle.com> Message-ID: It feels like there is extra indirection for the code that sets the helpers. Is there a reason it isn't as simple as "this.shapeHelper = FooHelper.instance"? Or, even a package-private Shape(ShapeHelper) constructor on Shape? (*) Also, many of the helper classes have argument names that were obviously cut and pasted from a different shape class. The names don't functionally matter, but seeing the ArcHelper manipulate variables called "quadThisOrThat" is a little jarring... ...jim (*) Note that since Shape currently has a public empty constructor that is added implicitly by the fact that it includes no explicit constructors you have to make sure to make an explicit one if you ever add an explicit constructor... On 5/20/16 2:11 PM, Chien Yang wrote: > Hi Kevin, > > Please review the proposed fix as we have discussed. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8157350 > Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8157350/webrev.00/ > > Thanks, > - Chien From vadim.pakhnushev at oracle.com Fri May 20 22:25:59 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Sat, 21 May 2016 01:25:59 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <3b544dee-e1dd-1a39-ec37-7a6ca05128a2@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From kevin.rushforth at oracle.com Fri May 20 22:33:18 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 May 2016 15:33:18 -0700 Subject: [9] Code Review Request For 8157350: Encapsulate impl_ methods in Shapes related classes In-Reply-To: References: <573F7D82.3080500@oracle.com> Message-ID: <573F90AE.1010700@oracle.com> This is needed for those cases where we need to encapsulate a method in the base Shape class that used to be public and overridden in the subclasses, not all of which are in the same package. It may seem like overkill, but we need a way to associate the the Shape instance of a particular subtype with the helper instance of the correct subtype. Each class in the hierarchy calls the specific XxxxxHelper.initHelper(this) method so that it can store back an instance of the right helper in the base class. A package-private method wouldn't work given that some shapes (e.g., Text) are in different packages. As for "Arc quadCurve" that looks like cut and paste errors; I missed that in my review, so will go back and look at the rest. Good reminder about the implicit "public Shape()" constructor. Chien already had to add an explicit public no-arg constructor in two classes. We really shouldn't rely on the implicit constructor in our public classes, since it makes it easy to make such a mistake. -- Kevin Jim Graham wrote: > It feels like there is extra indirection for the code that sets the > helpers. Is there a reason it isn't as simple as "this.shapeHelper = > FooHelper.instance"? Or, even a package-private Shape(ShapeHelper) > constructor on Shape? (*) > > Also, many of the helper classes have argument names that were > obviously cut and pasted from a different shape class. The names don't > functionally matter, but seeing the ArcHelper manipulate variables > called "quadThisOrThat" is a little jarring... > > ...jim > > (*) Note that since Shape currently has a public empty constructor > that is added implicitly by the fact that it includes no explicit > constructors you have to make sure to make an explicit one if you ever > add an explicit constructor... > > On 5/20/16 2:11 PM, Chien Yang wrote: >> Hi Kevin, >> >> Please review the proposed fix as we have discussed. >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8157350 >> Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8157350/webrev.00/ >> >> Thanks, >> - Chien From james.graham at oracle.com Fri May 20 22:38:58 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 20 May 2016 15:38:58 -0700 Subject: [9] Code Review Request For 8157350: Encapsulate impl_ methods in Shapes related classes In-Reply-To: <573F90AE.1010700@oracle.com> References: <573F7D82.3080500@oracle.com> <573F90AE.1010700@oracle.com> Message-ID: <01cadff0-1d57-b972-cab2-c0798b0d8899@oracle.com> On 5/20/16 3:33 PM, Kevin Rushforth wrote: > This is needed for those cases where we need to encapsulate a method in the base Shape class that used to be public and > overridden in the subclasses, not all of which are in the same package. It may seem like overkill, but we need a way to > associate the the Shape instance of a particular subtype with the helper instance of the correct subtype. Each class in > the hierarchy calls the specific XxxxxHelper.initHelper(this) method so that it can store back an instance of the right > helper in the base class. A package-private method wouldn't work given that some shapes (e.g., Text) are in different > packages. Right, but (taking Arc as an example) Arc makes a specific reference to ArcHelper which turns around and hands a specific instance to its own instance field to a method that stores the value in the shapeHelper field. How is that any different from just putting shapeHelper = ArcHelper.instance without 2 method calls and an accessor in the way? Also, what if someone creates a custom sub-class of Shape? (Not sure if that is supported or possible, but it is a public class with a public constructor so I don't think it is impossible.) > Good reminder about the implicit "public Shape()" constructor. Chien already had to add an explicit public no-arg > constructor in two classes. We really shouldn't rely on the implicit constructor in our public classes, since it makes > it easy to make such a mistake. It would be good to have a tool and/or automated test that warns about this. Another reason is that the implicit constructor has no javadocs associated with it... ...jim From kevin.rushforth at oracle.com Fri May 20 22:56:22 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 May 2016 15:56:22 -0700 Subject: [9] Code Review Request For 8157350: Encapsulate impl_ methods in Shapes related classes In-Reply-To: <01cadff0-1d57-b972-cab2-c0798b0d8899@oracle.com> References: <573F7D82.3080500@oracle.com> <573F90AE.1010700@oracle.com> <01cadff0-1d57-b972-cab2-c0798b0d8899@oracle.com> Message-ID: <573F9616.80809@oracle.com> Jim Graham wrote: > > > On 5/20/16 3:33 PM, Kevin Rushforth wrote: >> This is needed for those cases where we need to encapsulate a method >> in the base Shape class that used to be public and >> overridden in the subclasses, not all of which are in the same >> package. It may seem like overkill, but we need a way to >> associate the the Shape instance of a particular subtype with the >> helper instance of the correct subtype. Each class in >> the hierarchy calls the specific XxxxxHelper.initHelper(this) method >> so that it can store back an instance of the right >> helper in the base class. A package-private method wouldn't work >> given that some shapes (e.g., Text) are in different >> packages. > > Right, but (taking Arc as an example) Arc makes a specific reference > to ArcHelper which turns around and hands a specific instance to its > own instance field to a method that stores the value in the > shapeHelper field. How is that any different from just putting > shapeHelper = ArcHelper.instance without 2 method calls and an > accessor in the way? But the shapeHelper field is in the base Shape class not in the Arc class. If we wanted a different pattern for classes in the same package as the base class from classes in a different package then I guess I can see how this is solvable by making the ArcHelper.getInstance() method public and having the Arc() constructors call the package-scope setHelper(ShapeHelper) method in Shape, but as soon as Chien move the stored helper instance up to Node (which is the next step) it would stop working. > Also, what if someone creates a custom sub-class of Shape? (Not sure > if that is supported or possible, but it is a public class with a > public constructor so I don't think it is impossible.) Since we don't have public API for many of the things they would need even today, an application isn't able to do that. They couldn't really do it anyway before this change, since impl_getPeer() and several other methods aren't implementable by an application (NGNode is not publicly exported for example). >> Good reminder about the implicit "public Shape()" constructor. Chien >> already had to add an explicit public no-arg >> constructor in two classes. We really shouldn't rely on the implicit >> constructor in our public classes, since it makes >> it easy to make such a mistake. > > It would be good to have a tool and/or automated test that warns about > this. Another reason is that the implicit constructor has no javadocs > associated with it... Indeed. I wonder if doclint will help (we are in the process of making our docs doclint clean). -- Kevin > > ...jim From james.graham at oracle.com Fri May 20 23:23:42 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 20 May 2016 16:23:42 -0700 Subject: [9] Code Review Request For 8157350: Encapsulate impl_ methods in Shapes related classes In-Reply-To: <573F9616.80809@oracle.com> References: <573F7D82.3080500@oracle.com> <573F90AE.1010700@oracle.com> <01cadff0-1d57-b972-cab2-c0798b0d8899@oracle.com> <573F9616.80809@oracle.com> Message-ID: <1a8c4ab3-e41e-5e5f-57b3-ac8ab7da2617@oracle.com> Sounds good... ...jim On 5/20/16 3:56 PM, Kevin Rushforth wrote: > > > Jim Graham wrote: >> >> >> On 5/20/16 3:33 PM, Kevin Rushforth wrote: >>> This is needed for those cases where we need to encapsulate a method in the base Shape class that used to be public and >>> overridden in the subclasses, not all of which are in the same package. It may seem like overkill, but we need a way to >>> associate the the Shape instance of a particular subtype with the helper instance of the correct subtype. Each class in >>> the hierarchy calls the specific XxxxxHelper.initHelper(this) method so that it can store back an instance of the right >>> helper in the base class. A package-private method wouldn't work given that some shapes (e.g., Text) are in different >>> packages. >> >> Right, but (taking Arc as an example) Arc makes a specific reference to ArcHelper which turns around and hands a >> specific instance to its own instance field to a method that stores the value in the shapeHelper field. How is that >> any different from just putting shapeHelper = ArcHelper.instance without 2 method calls and an accessor in the way? > > But the shapeHelper field is in the base Shape class not in the Arc class. If we wanted a different pattern for classes > in the same package as the base class from classes in a different package then I guess I can see how this is solvable by > making the ArcHelper.getInstance() method public and having the Arc() constructors call the package-scope > setHelper(ShapeHelper) method in Shape, but as soon as Chien move the stored helper instance up to Node (which is the > next step) it would stop working. > >> Also, what if someone creates a custom sub-class of Shape? (Not sure if that is supported or possible, but it is a >> public class with a public constructor so I don't think it is impossible.) > > Since we don't have public API for many of the things they would need even today, an application isn't able to do that. > They couldn't really do it anyway before this change, since impl_getPeer() and several other methods aren't > implementable by an application (NGNode is not publicly exported for example). > > >>> Good reminder about the implicit "public Shape()" constructor. Chien already had to add an explicit public no-arg >>> constructor in two classes. We really shouldn't rely on the implicit constructor in our public classes, since it makes >>> it easy to make such a mistake. >> >> It would be good to have a tool and/or automated test that warns about this. Another reason is that the implicit >> constructor has no javadocs associated with it... > > Indeed. I wonder if doclint will help (we are in the process of making our docs doclint clean). > > -- Kevin > > >> >> ...jim From chien.yang at oracle.com Fri May 20 23:31:34 2016 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 20 May 2016 16:31:34 -0700 Subject: [9] Code Review Request For 8091874: Need API in GridPane to get row count, column count, and cell bounds Message-ID: <573F9E56.6010508@oracle.com> Hi Kevin, Please review the suggested fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8091874 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8091874/webrev.00/ Thanks, - Chien From kevin.rushforth at oracle.com Sat May 21 00:39:52 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 May 2016 17:39:52 -0700 Subject: [9] Review request: Message-ID: <573FAE58.3070603@oracle.com> Hi Chien, Please review the following to deprecate the HostServices.getWebContext() method in JDK 9: https://bugs.openjdk.java.net/browse/JDK-8156963 http://cr.openjdk.java.net/~kcr/8156963/webrev.00/ This is being done as part of JEP 289 [1][2]. Thanks. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8149502 From kevin.rushforth at oracle.com Sat May 21 00:41:32 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 May 2016 17:41:32 -0700 Subject: [9] Review request: 8156963: Add @Deprecated annotation to HostServices.getWebContext method In-Reply-To: <573FAE58.3070603@oracle.com> References: <573FAE58.3070603@oracle.com> Message-ID: <573FAEBC.1000109@oracle.com> [resend with correct subject line] Hi Chien, Please review the following to deprecate the HostServices.getWebContext() method in JDK 9: https://bugs.openjdk.java.net/browse/JDK-8156963 http://cr.openjdk.java.net/~kcr/8156963/webrev.00/ This is being done as part of JEP 289 [1][2]. Thanks. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8149502 From guru.hb at oracle.com Mon May 23 05:04:08 2016 From: guru.hb at oracle.com (Guru Hb) Date: Mon, 23 May 2016 10:34:08 +0530 Subject: [9] Review request: 8157145: DRT crash at fast/css-generated-content/initial-letter-basic.html In-Reply-To: <13ed18a4-86a3-c5a1-c37d-db60272b77fd@oracle.com> References: <13ed18a4-86a3-c5a1-c37d-db60272b77fd@oracle.com> Message-ID: <682af7fd-2426-a61f-4000-40403b647ca0@oracle.com> Hi Arun & Kevin, Please review the fix : JBS : https://bugs.openjdk.java.net/browse/JDK-8157145 Webrev : http://cr.openjdk.java.net/~ghb/8157145/webrev.00/ RC and Solution updated in JBS. Thanks, Guru From andrey.rusakov at oracle.com Mon May 23 12:11:59 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Mon, 23 May 2016 15:11:59 +0300 Subject: Review request for Ensemble. Message-ID: <5742F38F.1070709@oracle.com> Hello, everyone. There were a couple of small bugs that annoyed me while analysing manual tests, so I decided to fix them myself. Bug: https://bugs.openjdk.java.net/browse/JDK-8088078 Webrev: http://cr.openjdk.java.net/~arusakov/8088078/webrev.00/ Please look and confirm. This diff resolves both 8088078 and 8088786 and applicable for 8 and 9 openjfx. From a.ankit.srivastava at oracle.com Mon May 23 16:21:12 2016 From: a.ankit.srivastava at oracle.com (Ankit Srivastava) Date: Mon, 23 May 2016 09:21:12 -0700 (PDT) Subject: [9] Review Request: 8157559: Linux: Javascript Timing Events stop work on system clock changes at past Message-ID: <525aa287-cf0a-4b84-ac7c-920892a729a7@default> Hi Arun & Kevin, Please review the fix: JBS: https://bugs.openjdk.java.net/browse/JDK-8157559 Webrev: http://cr.openjdk.java.net/~asrivastava/8157559/webrev.00/ Root cause and Solution updated in JBS. Regards, Ankit From kevin.rushforth at oracle.com Mon May 23 21:00:47 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 May 2016 14:00:47 -0700 Subject: 9-dev unlocked following sanity testing Message-ID: <57436F7F.2060700@oracle.com> From arunprasad.rajkumar at oracle.com Tue May 24 18:38:27 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 25 May 2016 00:08:27 +0530 Subject: [webkit] [9] Review request for 8149045: Debug build is not working after new WebKit upgrade In-Reply-To: <572B0AFD.5070606@oracle.com> References: <572B0AFD.5070606@oracle.com> Message-ID: <57449FA3.9080508@oracle.com> Hello Kevin, Guru, Murali, Please review the simple fix to make debug build usable after new WebKit upgrade. JIRA: https://bugs.openjdk.java.net/browse/JDK-8149045 Webrev: http://cr.openjdk.java.net/~arajkumar/8149045/webrev.00 Issue: 1. JS Promise(similar to java Futures) is enabled by default, but new merge disables in few places which causes crash. 2. Assigning from Raw Pointer to RefPtr should use adoptRef instead of direct assignment. Regards, Arun From cnewland at chrisnewland.com Wed May 25 08:10:46 2016 From: cnewland at chrisnewland.com (Chris Newland) Date: Wed, 25 May 2016 09:10:46 +0100 Subject: OSX+Radeon crash VideoDataBuffer.convert YCbCr_422 -> BGRA_PRE Message-ID: Hi, This is really just an FYI as I'm doing funky stuff with multiple MediaPlayers and using the deprecated impl_getLatestFrame() method to grab frames. I can grab frames fine with a single MediaPlayer instance but when I use multiple MediaPlayer objects each with an AnimationTimer calling this code: public void snapshotVideo() { VideoDataBuffer buf = player.impl_getLatestFrame(); if (buf != null) { VideoFormat newFormat = VideoFormat.BGRA_PRE; buf = buf.convertToFormat(newFormat); ByteBuffer bb = buf.getBufferForPlane(VideoDataBuffer.PACKED_FORMAT_PLANE); int pixel = 0; int max = bb.remaining() / 4; for (int i = 0; i < max; i++) { rawFrameData[pixel++] = bb.getInt(); } buf.releaseFrame(); } } then it crashes hard on OSX El Capitan with AMD Radeon HD 6970M with this dump: https://gist.github.com/chriswhocodes/5516d24078205dc218dead870853e018 I'm guessing the native frame conversion from YCbCr_422 to BGRA_PRE is not thread-safe but some naive attempts to lock around this haven't solved the problem. This same code + videos works fine on a MacBook Pro with Intel Iris graphics so it's a tiny hardware+OS corner case but thought it might be worth a mention. The only thing I'd add is that I'd love to have an official API for grabbing single frames from video. I've been doing some cool real-time video effects in JavaFX and it's a shame to have to use a deprecated method which will probably go away. Cheers, Chris From andrey.rusakov at oracle.com Wed May 25 11:23:47 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Wed, 25 May 2016 14:23:47 +0300 Subject: Review request for JDK-8141385 Message-ID: <57458B43.3020805@oracle.com> Hello, Everyone. Please look at my fix for JDK-8141385 : http://cr.openjdk.java.net/~arusakov/8141385/webrev.00 Actually, that is Jonathan's bug, I've occasionally meet it during testing and decided to fix it. From kevin.rushforth at oracle.com Wed May 25 12:29:14 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 May 2016 05:29:14 -0700 Subject: OSX+Radeon crash VideoDataBuffer.convert YCbCr_422 -> BGRA_PRE In-Reply-To: References: Message-ID: <57459A9A.7000103@oracle.com> I'm not surprised this causes problems, as it is almost certainly not thread-safe. FWIW, this impl_ method is already inaccessible in JDK 9 because it returns a type that is not exported from the javafx.media module. Further, this methods will go away very soon as part of the ongoing encapsulation of all impl_ methods. Can you file an RFE for a public API to do this? We can consider it for a future version of JavaFX. -- Kevin Chris Newland wrote: > Hi, > > This is really just an FYI as I'm doing funky stuff with multiple > MediaPlayers and using the deprecated impl_getLatestFrame() method to grab > frames. > > I can grab frames fine with a single MediaPlayer instance but when I use > multiple MediaPlayer objects each with an AnimationTimer calling this > code: > > public void snapshotVideo() > { > VideoDataBuffer buf = player.impl_getLatestFrame(); > > if (buf != null) > { > VideoFormat newFormat = VideoFormat.BGRA_PRE; > buf = buf.convertToFormat(newFormat); > > ByteBuffer bb = > buf.getBufferForPlane(VideoDataBuffer.PACKED_FORMAT_PLANE); > > int pixel = 0; > > int max = bb.remaining() / 4; > > for (int i = 0; i < max; i++) > { > rawFrameData[pixel++] = bb.getInt(); > } > > buf.releaseFrame(); > } > } > > then it crashes hard on OSX El Capitan with AMD Radeon HD 6970M with this > dump: > https://gist.github.com/chriswhocodes/5516d24078205dc218dead870853e018 > > I'm guessing the native frame conversion from YCbCr_422 to BGRA_PRE is not > thread-safe but some naive attempts to lock around this haven't solved the > problem. > > This same code + videos works fine on a MacBook Pro with Intel Iris > graphics so it's a tiny hardware+OS corner case but thought it might be > worth a mention. > > The only thing I'd add is that I'd love to have an official API for > grabbing single frames from video. I've been doing some cool real-time > video effects in JavaFX and it's a shame to have to use a deprecated > method which will probably go away. > > Cheers, > > Chris > > From Ignatiamus at gmail.com Wed May 25 12:36:07 2016 From: Ignatiamus at gmail.com (Herrmann Maier) Date: Wed, 25 May 2016 14:36:07 +0200 Subject: Memory Leak in Ubuntu 16.04 Message-ID: Good day, I run Ubuntu 16.04 in 64 bit, with free Radeon graphics driver (AMD Radeon HD 6450 graphics card), and with Oracle's JDK version 1.8.0_92 . When I run JavaFX applications, like the JDK's Ensemble demo or my own programs, there's a memory leak when FX shows some "action" like animated or otherwise active FX components. Firstly, FX's animation loop doesn't run with 60 but 120 fps, and secondly the needed memory for the Java task grows until my physical RAM size is reached, then the system starts to swap memory until it stalls. The memory leak only appears when the FX application does do something, e.g. when there's a JavaFX animation loop or when I click a FX button. When I just start the Ensemble demo and don't press any key or mouse button, the memory is OK. Also Swing and other Java programs work fine on the same system. When I manually invoke "System.gc() at the end of my FX's animation loop, the memory gets released, i.e. no memory leak. But the downside is that the FX program then runs very slow because of the manual gc() at each frame. I also tried to use different garbage collection parameters with "java -X...", but it didn't help. How can I encircle the problem, please? Thanks in advance. Regards, Herrmann From cnewland at chrisnewland.com Wed May 25 14:22:54 2016 From: cnewland at chrisnewland.com (Chris Newland) Date: Wed, 25 May 2016 15:22:54 +0100 Subject: OSX+Radeon crash VideoDataBuffer.convert YCbCr_422 -> BGRA_PRE In-Reply-To: <57459A9A.7000103@oracle.com> References: <57459A9A.7000103@oracle.com> Message-ID: <3f42a1dcade6ee4a67f96b84561f00a8.squirrel@excalibur.xssl.net> Thanks Kevin, filed RFE with Review ID: JI-9038459. I've found this was a really powerful way to do things like real-time chroma keying (green screening) in JavaFX so will keep an OpenJFX snapshot around to preserve this functionality. Will be releasing another JavaFX tech demo soon :) Cheers, Chris On Wed, May 25, 2016 13:29, Kevin Rushforth wrote: > I'm not surprised this causes problems, as it is almost certainly not > thread-safe. > > FWIW, this impl_ method is already inaccessible in JDK 9 because it > returns a type that is not exported from the javafx.media module. Further, > this methods will go away very soon as part of the ongoing encapsulation > of all impl_ methods. > > Can you file an RFE for a public API to do this? We can consider it for > a future version of JavaFX. > > -- Kevin > > > > Chris Newland wrote: > >> Hi, >> >> >> This is really just an FYI as I'm doing funky stuff with multiple >> MediaPlayers and using the deprecated impl_getLatestFrame() method to >> grab frames. >> >> I can grab frames fine with a single MediaPlayer instance but when I >> use multiple MediaPlayer objects each with an AnimationTimer calling >> this code: >> >> >> public void snapshotVideo() { >> VideoDataBuffer buf = player.impl_getLatestFrame(); >> >> >> if (buf != null) { >> VideoFormat newFormat = VideoFormat.BGRA_PRE; >> buf = buf.convertToFormat(newFormat); >> >> ByteBuffer bb = >> buf.getBufferForPlane(VideoDataBuffer.PACKED_FORMAT_PLANE); >> >> int pixel = 0; >> >> int max = bb.remaining() / 4; >> >> for (int i = 0; i < max; i++) { >> rawFrameData[pixel++] = bb.getInt(); } >> >> >> buf.releaseFrame(); } >> } >> >> >> then it crashes hard on OSX El Capitan with AMD Radeon HD 6970M with >> this dump: >> https://gist.github.com/chriswhocodes/5516d24078205dc218dead870853e018 >> >> >> I'm guessing the native frame conversion from YCbCr_422 to BGRA_PRE is >> not thread-safe but some naive attempts to lock around this haven't >> solved the problem. >> >> This same code + videos works fine on a MacBook Pro with Intel Iris >> graphics so it's a tiny hardware+OS corner case but thought it might be >> worth a mention. >> >> The only thing I'd add is that I'd love to have an official API for >> grabbing single frames from video. I've been doing some cool real-time >> video effects in JavaFX and it's a shame to have to use a deprecated >> method which will probably go away. >> >> Cheers, >> >> >> Chris >> >> >> > From kevin.rushforth at oracle.com Wed May 25 22:38:29 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 May 2016 15:38:29 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 Message-ID: <57462965.7070806@oracle.com> Please review the following: https://bugs.openjdk.java.net/browse/JDK-8131888 http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). Details are in JBS. -- Kevin From elina.kleyman at oracle.com Thu May 26 11:32:22 2016 From: elina.kleyman at oracle.com (Elina Kleyman Matok) Date: Thu, 26 May 2016 04:32:22 -0700 (PDT) Subject: [9] Review request for 8090255 - Fix doclint errors in JavaFX API docs Message-ID: <97f65414-7d0f-4b58-ad65-ddf68312825a@default> Kevin, guys, Please review first part of fix for javadoc issue: JIRA: https://bugs.openjdk.java.net/browse/JDK-8090255 WEBREV: http://cr.openjdk.java.net/~ekleyman/RT-8090255/ The webrev includes also Kevin's and Felipe's patches. Thanks, Elina From andrey.rusakov at oracle.com Thu May 26 13:27:45 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Thu, 26 May 2016 16:27:45 +0300 Subject: Review request for JDK-8141385 In-Reply-To: <57458B43.3020805@oracle.com> References: <57458B43.3020805@oracle.com> Message-ID: <5746F9D1.9070903@oracle.com> I've updated my diff according to Jonathan's recommendations: http://cr.openjdk.java.net/~arusakov/8141385/webrev.01 25.05.2016 14:23, Andrey Rusakov ?????: > Hello, Everyone. Please look at my fix for JDK-8141385 > : > http://cr.openjdk.java.net/~arusakov/8141385/webrev.00 > > Actually, that is Jonathan's bug, I've occasionally meet it during > testing and decided to fix it. From mandy.chung at oracle.com Thu May 26 00:43:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 17:43:53 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <57462965.7070806@oracle.com> References: <57462965.7070806@oracle.com> Message-ID: <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> > On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8131888 > http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ > > This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. FXCanvas.java 247 System.err.println("FXCanvas class successfully initialized?); 294 System.err.println("FXCanvas: FX platform is initlialized?); PlatformImpl.java 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); 309 ex.printStackTrace(); I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. ModuleHelper.java 57 // ignore This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. Otherwise, look fine to me. Mandy From kevin.rushforth at oracle.com Thu May 26 14:50:01 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 May 2016 07:50:01 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> Message-ID: <57470D19.6000303@oracle.com> Mandy, Thanks for your feedback. Comments inline. Mandy Chung wrote: > >> On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8131888 >> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >> >> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). >> > > The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. > Filenames with two dots are a little odd, so I went with the dash. It doesn't much matter, though. > I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. > > FXCanvas.java > 247 System.err.println("FXCanvas class successfully initialized?); > 294 System.err.println("FXCanvas: FX platform is initlialized?); > > PlatformImpl.java > 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); > 309 ex.printStackTrace(); > Right. I noted this in the JBS evaluation and will remove all when I post the final webrev. > I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. > I had considered adding the check for the module name, but was concerned about the OSGi case, as mentioned by Tom Schindl in the bug report, in which they add the jar file via a custom classloader; the concern is that there is no support in the JDK to make it an automatic module in this case. I will file a follow-up issue to improve the integrity checking. > ModuleHelper.java > 57 // ignore > > This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. > Actually, we can't do this yet, because we still build and test with JDK 9 build 109 which doesn't have support for the module system. Until we upgrade to a JDK with the module system enabled we need this to be a silent no-op or all of our tests will fail. -- Kevin > Otherwise, look fine to me. > Mandy From tom.schindl at bestsolution.at Thu May 26 14:51:04 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 26 May 2016 16:51:04 +0200 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> Message-ID: <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> Hi, I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage. The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? Tom Von meinem iPhone gesendet > Am 26.05.2016 um 02:43 schrieb Mandy Chung : > > > >> On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8131888 >> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >> >> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). > > The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. > > I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. > > FXCanvas.java > 247 System.err.println("FXCanvas class successfully initialized?); > 294 System.err.println("FXCanvas: FX platform is initlialized?); > > PlatformImpl.java > 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); > 309 ex.printStackTrace(); > > I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. > > ModuleHelper.java > 57 // ignore > > This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. > > Otherwise, look fine to me. > Mandy From kevin.rushforth at oracle.com Thu May 26 15:17:42 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 May 2016 08:17:42 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> Message-ID: <57471396.6020601@oracle.com> If you add javafx-swt.jar to the custom classpath created by the OSGI container it should work in the same way it does today when you add jfxswt.jar. Can you suggest an easy way that I can test this? -- Kevin Tom Schindl wrote: > Hi, > > I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage. > > The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? > > Tom > > Von meinem iPhone gesendet > > >> Am 26.05.2016 um 02:43 schrieb Mandy Chung : >> >> >> >> >>> On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8131888 >>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >>> >>> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). >>> >> The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. >> >> I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. >> >> FXCanvas.java >> 247 System.err.println("FXCanvas class successfully initialized?); >> 294 System.err.println("FXCanvas: FX platform is initlialized?); >> >> PlatformImpl.java >> 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); >> 309 ex.printStackTrace(); >> >> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. >> >> ModuleHelper.java >> 57 // ignore >> >> This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. >> >> Otherwise, look fine to me. >> Mandy >> > > From tom.schindl at bestsolution.at Thu May 26 15:30:24 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 26 May 2016 17:30:24 +0200 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> Message-ID: <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> Rereading the jira it take that back if javafx.swt can still be loaded as a simple jar things will work Tom Von meinem iPhone gesendet > Am 26.05.2016 um 16:51 schrieb Tom Schindl : > > Hi, > > I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage. > > The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? > > Tom > > Von meinem iPhone gesendet > >> Am 26.05.2016 um 02:43 schrieb Mandy Chung : >> >> >> >>> On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8131888 >>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >>> >>> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). >> >> The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. >> >> I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. >> >> FXCanvas.java >> 247 System.err.println("FXCanvas class successfully initialized?); >> 294 System.err.println("FXCanvas: FX platform is initlialized?); >> >> PlatformImpl.java >> 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); >> 309 ex.printStackTrace(); >> >> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. >> >> ModuleHelper.java >> 57 // ignore >> >> This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. >> >> Otherwise, look fine to me. >> Mandy > From kevin.rushforth at oracle.com Thu May 26 15:38:46 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 May 2016 08:38:46 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> Message-ID: <57471886.10703@oracle.com> Yes, I've tested it in both modes (with a simple HelloFXCanvas program) -- as an automatic jar file and as just an ordinary jar on the classpath. -- Kevin Tom Schindl wrote: > Rereading the jira it take that back if javafx.swt can still be loaded as a simple jar things will work > > Tom > > Von meinem iPhone gesendet > > >> Am 26.05.2016 um 16:51 schrieb Tom Schindl : >> >> Hi, >> >> I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage. >> >> The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? >> >> Tom >> >> Von meinem iPhone gesendet >> >> >>> Am 26.05.2016 um 02:43 schrieb Mandy Chung : >>> >>> >>> >>> >>>> On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8131888 >>>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >>>> >>>> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). >>>> >>> The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. >>> >>> I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. >>> >>> FXCanvas.java >>> 247 System.err.println("FXCanvas class successfully initialized?); >>> 294 System.err.println("FXCanvas: FX platform is initlialized?); >>> >>> PlatformImpl.java >>> 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); >>> 309 ex.printStackTrace(); >>> >>> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. >>> >>> ModuleHelper.java >>> 57 // ignore >>> >>> This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. >>> >>> Otherwise, look fine to me. >>> Mandy >>> > > From mandy.chung at oracle.com Thu May 26 15:47:16 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 26 May 2016 08:47:16 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <57471886.10703@oracle.com> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> <57471886.10703@oracle.com> Message-ID: > On May 26, 2016, at 8:38 AM, Kevin Rushforth wrote: > > Yes, I've tested it in both modes (with a simple HelloFXCanvas program) -- as an automatic jar file and as just an ordinary jar on the classpath. an automatic module needs to be on modulepath. For container-like environment, it can create a Layer to load javafx.swt with a parent class loader that loads SWT classes - would that be feasible? Mandy > > -- Kevin > > > Tom Schindl wrote: >> Rereading the jira it take that back if javafx.swt can still be loaded as a simple jar things will work >> >> Tom >> >> Von meinem iPhone gesendet >> >> >> >>> Am 26.05.2016 um 16:51 schrieb Tom Schindl >>> : >>> >>> Hi, >>> >>> I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage. >>> >>> The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? >>> >>> Tom >>> >>> Von meinem iPhone gesendet >>> >>> >>> >>>> Am 26.05.2016 um 02:43 schrieb Mandy Chung >>>> : >>>> >>>> >>>> >>>> >>>> >>>>> On May 25, 2016, at 3:38 PM, Kevin Rushforth >>>>> wrote: >>>>> >>>>> Please review the following: >>>>> >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8131888 >>>>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >>>>> >>>>> >>>>> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). >>>>> >>>>> >>>> The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. >>>> >>>> I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. >>>> >>>> FXCanvas.java >>>> 247 System.err.println("FXCanvas class successfully initialized?); >>>> 294 System.err.println("FXCanvas: FX platform is initlialized?); >>>> >>>> PlatformImpl.java >>>> 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); >>>> 309 ex.printStackTrace(); >>>> >>>> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. >>>> >>>> ModuleHelper.java >>>> 57 // ignore >>>> >>>> This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. >>>> >>>> Otherwise, look fine to me. >>>> Mandy >>>> >>>> >> >> >> From tom.schindl at bestsolution.at Thu May 26 15:53:58 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 26 May 2016 17:53:58 +0200 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <57471886.10703@oracle.com> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> <57471886.10703@oracle.com> Message-ID: <94C22365-098C-4481-8718-3B40F9B196A5@bestsolution.at> I'll prepare a simple osgi swt test app Tom Von meinem iPhone gesendet > Am 26.05.2016 um 17:38 schrieb Kevin Rushforth : > > Yes, I've tested it in both modes (with a simple HelloFXCanvas program) -- as an automatic jar file and as just an ordinary jar on the classpath. > > -- Kevin > > > Tom Schindl wrote: >> >> Rereading the jira it take that back if javafx.swt can still be loaded as a simple jar things will work >> >> Tom >> >> Von meinem iPhone gesendet >> >> >>>> Am 26.05.2016 um 16:51 schrieb Tom Schindl : >>>> >>>> Hi, >>>> >>>> I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage. >>>> >>>> The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? >>>> >>>> Tom >>>> >>>> Von meinem iPhone gesendet >>>> >>>> >>>>> Am 26.05.2016 um 02:43 schrieb Mandy Chung : >>>>> >>>>> >>>>> >>>>> >>>>> On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: >>>>> >>>>> Please review the following: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8131888 >>>>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >>>>> >>>>> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). >>>>> >>>> The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. >>>> >>>> I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. >>>> >>>> FXCanvas.java >>>> 247 System.err.println("FXCanvas class successfully initialized?); >>>> 294 System.err.println("FXCanvas: FX platform is initlialized?); >>>> >>>> PlatformImpl.java >>>> 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); >>>> 309 ex.printStackTrace(); >>>> >>>> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. >>>> >>>> ModuleHelper.java >>>> 57 // ignore >>>> >>>> This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. >>>> >>>> Otherwise, look fine to me. >>>> Mandy >>>> From chien.yang at oracle.com Thu May 26 23:20:34 2016 From: chien.yang at oracle.com (Chien Yang) Date: Thu, 26 May 2016 16:20:34 -0700 Subject: [9] Code Review Request For 8157900: Encapsulate JavaFX impl_* implementation methods in Node (peer and dirty) Message-ID: <574784C2.6050602@oracle.com> Hi Kevin, Jonathon and Vadim, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8157900 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8157900/webrev.00/ PS: This is a huge webrev and touches many components. I believe most component owners would want to do a quick cursory review except those that I tagged. Thanks, - Chien From james.graham at oracle.com Fri May 27 00:43:21 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 26 May 2016 17:43:21 -0700 Subject: [9] Review request for 8157600: Failed to launch hello.HelloSanity due to libglass.so: undefined symbol Message-ID: <7b1adea7-7e20-c044-96c8-54c7adf40cd8@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8157600 webrev: http://cr.openjdk.java.net/~flar/JDK-8157600/webrev.00/ ...jim From robert.fisher.ext at zeiss.com Fri May 27 08:06:39 2016 From: robert.fisher.ext at zeiss.com (Fisher, Robert) Date: Fri, 27 May 2016 08:06:39 +0000 Subject: Mouse events blocked during DnD inside JFXPanel - bug or limitation? Message-ID: <025E25CA98F8AE46BE306AB33F6A38D5012D1EE5@ADEFUE01SMS003.cznet.zeiss.org> Hi all, When inside a JFXPanel, after DnD has been started on a node and content put the dragboard, mouse-exited events for the node do not fire until the drag gesture is over. Is this a known bug, new bug, or a limitation of using Swing + FX together? Check out the test program below. Any input would be appreciated. Cheers, Rob public class Main extends Application { // Set to true to test behaviour when embedded inside a JFXPanel. private static final boolean EMBED_IN_SWING = true; public static void main(String[] args) { if (EMBED_IN_SWING) { SwingUtilities.invokeLater(() -> { JFXPanel jfxPanel = new JFXPanel(); JFrame frame = new JFrame(); frame.add(jfxPanel); frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); frame.setSize(800, 600); frame.setVisible(true); Platform.runLater(() -> { Scene scene = createScene(); jfxPanel.setScene(scene); }); }); } else { launch(args); } } @Override public void start(Stage primaryStage) { Scene scene = createScene(); primaryStage.setScene(scene); primaryStage.show(); } private static Scene createScene() { Rectangle rectangle = new Rectangle(50, 50); rectangle.hoverProperty().addListener((v, o, n) -> System.out.println("Hover property: " + n)); rectangle.addEventFilter(MouseEvent.MOUSE_ENTERED, event -> System.out.println("Mouse entered")); rectangle.addEventFilter(MouseEvent.MOUSE_EXITED, event -> System.out.println("Mouse exited")); rectangle.setOnDragDetected(event -> { Dragboard db = rectangle.startDragAndDrop(TransferMode.COPY); ClipboardContent content = new ClipboardContent(); content.putString("Hello World"); db.setContent(content); event.consume(); }); StackPane stackPane = new StackPane(rectangle); return new Scene(stackPane, 800, 600); } } From robert.fisher.ext at zeiss.com Fri May 27 08:10:15 2016 From: robert.fisher.ext at zeiss.com (Fisher, Robert) Date: Fri, 27 May 2016 08:10:15 +0000 Subject: Mouse events blocked during DnD inside JFXPanel - bug or limitation? In-Reply-To: <025E25CA98F8AE46BE306AB33F6A38D5012D1EE5@ADEFUE01SMS003.cznet.zeiss.org> References: <025E25CA98F8AE46BE306AB33F6A38D5012D1EE5@ADEFUE01SMS003.cznet.zeiss.org> Message-ID: <025E25CA98F8AE46BE306AB33F6A38D5012D1EF7@ADEFUE01SMS003.cznet.zeiss.org> Sorry I forgot to add - I'm using 1.8.0_66 on Windows 7. Cheers, Rob -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Fisher, Robert Sent: Freitag, 27. Mai 2016 10:07 To: openjfx-dev at openjdk.java.net Subject: Mouse events blocked during DnD inside JFXPanel - bug or limitation? Hi all, When inside a JFXPanel, after DnD has been started on a node and content put the dragboard, mouse-exited events for the node do not fire until the drag gesture is over. Is this a known bug, new bug, or a limitation of using Swing + FX together? Check out the test program below. Any input would be appreciated. Cheers, Rob public class Main extends Application { // Set to true to test behaviour when embedded inside a JFXPanel. private static final boolean EMBED_IN_SWING = true; public static void main(String[] args) { if (EMBED_IN_SWING) { SwingUtilities.invokeLater(() -> { JFXPanel jfxPanel = new JFXPanel(); JFrame frame = new JFrame(); frame.add(jfxPanel); frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); frame.setSize(800, 600); frame.setVisible(true); Platform.runLater(() -> { Scene scene = createScene(); jfxPanel.setScene(scene); }); }); } else { launch(args); } } @Override public void start(Stage primaryStage) { Scene scene = createScene(); primaryStage.setScene(scene); primaryStage.show(); } private static Scene createScene() { Rectangle rectangle = new Rectangle(50, 50); rectangle.hoverProperty().addListener((v, o, n) -> System.out.println("Hover property: " + n)); rectangle.addEventFilter(MouseEvent.MOUSE_ENTERED, event -> System.out.println("Mouse entered")); rectangle.addEventFilter(MouseEvent.MOUSE_EXITED, event -> System.out.println("Mouse exited")); rectangle.setOnDragDetected(event -> { Dragboard db = rectangle.startDragAndDrop(TransferMode.COPY); ClipboardContent content = new ClipboardContent(); content.putString("Hello World"); db.setContent(content); event.consume(); }); StackPane stackPane = new StackPane(rectangle); return new Scene(stackPane, 800, 600); } } From tom.schindl at bestsolution.at Fri May 27 08:30:23 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 27 May 2016 10:30:23 +0200 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> <57471886.10703@oracle.com> Message-ID: Do you have an example how to construct such a Layer? Tom Von meinem iPhone gesendet > Am 26.05.2016 um 17:47 schrieb Mandy Chung : > > >> On May 26, 2016, at 8:38 AM, Kevin Rushforth wrote: >> >> Yes, I've tested it in both modes (with a simple HelloFXCanvas program) -- as an automatic jar file and as just an ordinary jar on the classpath. > > an automatic module needs to be on modulepath. > > For container-like environment, it can create a Layer to load javafx.swt with a parent class loader that loads SWT classes - would that be feasible? > > Mandy > >> >> -- Kevin >> >> >> Tom Schindl wrote: >>> Rereading the jira it take that back if javafx.swt can still be loaded as a simple jar things will work >>> >>> Tom >>> >>> Von meinem iPhone gesendet >>> >>> >>> >>>> Am 26.05.2016 um 16:51 schrieb Tom Schindl >>>> : >>>> >>>> Hi, >>>> >>>> I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage. >>>> >>>> The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? >>>> >>>> Tom >>>> >>>> Von meinem iPhone gesendet >>>> >>>> >>>> >>>>> Am 26.05.2016 um 02:43 schrieb Mandy Chung >>>>> : >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On May 25, 2016, at 3:38 PM, Kevin Rushforth >>>>>> wrote: >>>>>> >>>>>> Please review the following: >>>>>> >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8131888 >>>>>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >>>>>> >>>>>> >>>>>> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). >>>>> The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. >>>>> >>>>> I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. >>>>> >>>>> FXCanvas.java >>>>> 247 System.err.println("FXCanvas class successfully initialized?); >>>>> 294 System.err.println("FXCanvas: FX platform is initlialized?); >>>>> >>>>> PlatformImpl.java >>>>> 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); >>>>> 309 ex.printStackTrace(); >>>>> >>>>> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. >>>>> >>>>> ModuleHelper.java >>>>> 57 // ignore >>>>> >>>>> This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. >>>>> >>>>> Otherwise, look fine to me. >>>>> Mandy > From arunprasad.rajkumar at oracle.com Fri May 27 12:18:19 2016 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Fri, 27 May 2016 17:48:19 +0530 Subject: [webkit] [9] Review request for 8157509: UserDataDirectoryTest fails on Windows platforms with updated WebKit In-Reply-To: <57449FA3.9080508@oracle.com> References: <57449FA3.9080508@oracle.com> Message-ID: <57483B0B.5010106@oracle.com> Hello Kevin, Guru, Murali, Please review the fix for UserDataDirectoryTest failure. JIRA: https://bugs.openjdk.java.net/browse/JDK-8157509 Webrev: http://cr.openjdk.java.net/~arajkumar/8157509/webrev.00 Issue: New WebKit takes around 5 mins to close the sqlite-db file associated with localStorage. Problem is evident in Windows because of the file system behavior. Solution: Try File.delete(..), if it fails defer the deletion task to VM shutdown using File.deleteOnExit(..). Regards, Arun From felix.bembrick at gmail.com Fri May 27 12:24:28 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 27 May 2016 22:24:28 +1000 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: <1AD675BD-C241-4678-9457-AA538654C113@gmail.com> References: <57325EA2.5090405@oracle.com> <324A50CE-B381-4FCB-A354-9022C09AE410@gmail.com> <57334BB4.9080405@oracle.com> <5734A6A5.9050508@oracle.com> <1AD675BD-C241-4678-9457-AA538654C113@gmail.com> Message-ID: <91AF1100-562B-4D09-A5F9-6DE1F6AC661B@gmail.com> Any comments on this? Isn't it time to move to Blink? > On 13 May 2016, at 04:32, Felix Bembrick wrote: > > Thanks Kevin. > > I was more curious as to why WebGL support hasn't been there since day 1, given that WebKit itself supports it. > > Felix > >> On 13 May 2016, at 01:52, Kevin Rushforth wrote: >> >> It was an issue of resources versus priority and scope. JDK 9 is focused on Jigsaw modularity and a few other minor features. It is more of a "smoothing out" release than a big feature release (except for Jigsaw). We expect JDK 10 to be a somewhat more feature-oriented release. >> >> -- Kevin >> >> >> Felix Bembrick wrote: >>> Do you mind if I ask what the rationale behind such a decision is? >>> >>> From an admittedly perhaps totally ignorant outside observer, it would seem to me that any cost/benefit analysis would basically put this feature in the "no brainer" category and should have been implemented at the very least since JFX 8. >>> >>> >>>> On 12 May 2016, at 01:11, Kevin Rushforth wrote: >>>> >>>> No. WebGL support is not planned for JDK 9. We will look at this for JDK 10. >>>> >>>> -- Kevin >>>> >>>> >>>> Felix Bembrick wrote: >>>> >>>>> Will this new WebKit finally support WebGL? >>>>> >>>>> Just by supporting WebGL in the JavaFX WebView will instantly enable an entire new set of 3D features and access to a plethora of JavaScript 3D libraries for "free". >>>>> >>>>> And, Google Maps will finally work too. >>>>> >>>>> >>>>>> On 11 May 2016, at 08:20, Kevin Rushforth wrote: >>>>>> >>>>>> All, >>>>>> >>>>>> As a heads-up, we plan to push an updated WebKit to FX 9-dev early next week [1]. If there are no build problems, they will be integrated to 9 master the following week for jdk-9+119. We then plan to backport the newer WebKit (to keep them in sync) to 8u-dev a couple weeks later. >>>>>> >>>>>> The only new tool needed to build this is CMake [2] version 3.4 or later (we will use 3.4.1 to build). >>>>>> >>>>>> Let me know if you have any questions. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8156698 >>>>>> >>>>>> [2] http://cmake.org/ >>>>>> >>>>>> From Alan.Bateman at oracle.com Fri May 27 11:01:59 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 May 2016 12:01:59 +0100 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <57471886.10703@oracle.com> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> <57471886.10703@oracle.com> Message-ID: <57482927.8030808@oracle.com> On 26/05/2016 16:38, Kevin Rushforth wrote: > Yes, I've tested it in both modes (with a simple HelloFXCanvas > program) -- as an automatic jar file and as just an ordinary jar on > the classpath. Just curious, if there are qualified exports to javafx.swt then how it does when on the class path? -Alan From kevin.rushforth at oracle.com Fri May 27 12:47:49 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 May 2016 05:47:49 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <57482927.8030808@oracle.com> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> <57471886.10703@oracle.com> <57482927.8030808@oracle.com> Message-ID: <574841F5.8010306@oracle.com> Alan Bateman wrote: > > On 26/05/2016 16:38, Kevin Rushforth wrote: >> Yes, I've tested it in both modes (with a simple HelloFXCanvas >> program) -- as an automatic jar file and as just an ordinary jar on >> the classpath. > Just curious, if there are qualified exports to javafx.swt then how it > does when on the class path? The qualified exports are done using reflection to the calling module that contains the javafx.embed.swt.FXCanvas class, irrespective of the name of the module (so it works even when the javafx.embed.swt package is in the unnamed module). I plan to file a follow-on bug to tighten the integrity checks, which may or may not include requiring it to be in a module named "javafx.swt", depending on whether all of the use cases can be done with javafx-swt.jar being loaded in a named module (e.g., Mandy's recommendation of using the Layer API). -- Kevin From kevin.rushforth at oracle.com Fri May 27 12:51:43 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 May 2016 05:51:43 -0700 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: <91AF1100-562B-4D09-A5F9-6DE1F6AC661B@gmail.com> References: <57325EA2.5090405@oracle.com> <324A50CE-B381-4FCB-A354-9022C09AE410@gmail.com> <57334BB4.9080405@oracle.com> <5734A6A5.9050508@oracle.com> <1AD675BD-C241-4678-9457-AA538654C113@gmail.com> <91AF1100-562B-4D09-A5F9-6DE1F6AC661B@gmail.com> Message-ID: <574842DF.8010102@oracle.com> No, I don't have anything further to add about WebGL, if that's what you are asking. As for moving to Blink, that would be a very large effort. We do not currently plan to do this for JDK 10, but could reevaluate it in the future if something changes. -- Kevin Felix Bembrick wrote: > Any comments on this? Isn't it time to move to Blink? > > >> On 13 May 2016, at 04:32, Felix Bembrick wrote: >> >> Thanks Kevin. >> >> I was more curious as to why WebGL support hasn't been there since day 1, given that WebKit itself supports it. >> >> Felix >> >> >>> On 13 May 2016, at 01:52, Kevin Rushforth wrote: >>> >>> It was an issue of resources versus priority and scope. JDK 9 is focused on Jigsaw modularity and a few other minor features. It is more of a "smoothing out" release than a big feature release (except for Jigsaw). We expect JDK 10 to be a somewhat more feature-oriented release. >>> >>> -- Kevin >>> >>> >>> Felix Bembrick wrote: >>> >>>> Do you mind if I ask what the rationale behind such a decision is? >>>> >>>> From an admittedly perhaps totally ignorant outside observer, it would seem to me that any cost/benefit analysis would basically put this feature in the "no brainer" category and should have been implemented at the very least since JFX 8. >>>> >>>> >>>> >>>>> On 12 May 2016, at 01:11, Kevin Rushforth wrote: >>>>> >>>>> No. WebGL support is not planned for JDK 9. We will look at this for JDK 10. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Felix Bembrick wrote: >>>>> >>>>> >>>>>> Will this new WebKit finally support WebGL? >>>>>> >>>>>> Just by supporting WebGL in the JavaFX WebView will instantly enable an entire new set of 3D features and access to a plethora of JavaScript 3D libraries for "free". >>>>>> >>>>>> And, Google Maps will finally work too. >>>>>> >>>>>> >>>>>> >>>>>>> On 11 May 2016, at 08:20, Kevin Rushforth wrote: >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> As a heads-up, we plan to push an updated WebKit to FX 9-dev early next week [1]. If there are no build problems, they will be integrated to 9 master the following week for jdk-9+119. We then plan to backport the newer WebKit (to keep them in sync) to 8u-dev a couple weeks later. >>>>>>> >>>>>>> The only new tool needed to build this is CMake [2] version 3.4 or later (we will use 3.4.1 to build). >>>>>>> >>>>>>> Let me know if you have any questions. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8156698 >>>>>>> >>>>>>> [2] http://cmake.org/ >>>>>>> >>>>>>> >>>>>>> From paskokv at gmail.com Fri May 27 13:10:39 2016 From: paskokv at gmail.com (Konstantin Pasko) Date: Fri, 27 May 2016 15:10:39 +0200 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: <574842DF.8010102@oracle.com> References: <57325EA2.5090405@oracle.com> <324A50CE-B381-4FCB-A354-9022C09AE410@gmail.com> <57334BB4.9080405@oracle.com> <5734A6A5.9050508@oracle.com> <1AD675BD-C241-4678-9457-AA538654C113@gmail.com> <91AF1100-562B-4D09-A5F9-6DE1F6AC661B@gmail.com> <574842DF.8010102@oracle.com> Message-ID: Hi Kevin, sorry for the offtopic, but as you just mentioned JDK 10, could you please tell us what is planned for that release? Something from the high level? New/missing features, controls, huge bugfixes? Googling "javafx road map" or "javafx jdk10" gives no results and looking through https://bugs.openjdk.java.net/projects/JDK/versions/16302 is quite time-consuming. With best regards, Konstantin 2016-05-27 14:51 GMT+02:00 Kevin Rushforth : > No, I don't have anything further to add about WebGL, if that's what you > are asking. > > As for moving to Blink, that would be a very large effort. We do not > currently plan to do this for JDK 10, but could reevaluate it in the future > if something changes. > > > -- Kevin > > > Felix Bembrick wrote: > >> Any comments on this? Isn't it time to move to Blink? >> >> >> >>> On 13 May 2016, at 04:32, Felix Bembrick >>> wrote: >>> >>> Thanks Kevin. >>> >>> I was more curious as to why WebGL support hasn't been there since day >>> 1, given that WebKit itself supports it. >>> >>> Felix >>> >>> >>> >>>> On 13 May 2016, at 01:52, Kevin Rushforth >>>> wrote: >>>> >>>> It was an issue of resources versus priority and scope. JDK 9 is >>>> focused on Jigsaw modularity and a few other minor features. It is more of >>>> a "smoothing out" release than a big feature release (except for Jigsaw). >>>> We expect JDK 10 to be a somewhat more feature-oriented release. >>>> >>>> -- Kevin >>>> >>>> >>>> Felix Bembrick wrote: >>>> >>>> >>>>> Do you mind if I ask what the rationale behind such a decision is? >>>>> >>>>> From an admittedly perhaps totally ignorant outside observer, it would >>>>> seem to me that any cost/benefit analysis would basically put this feature >>>>> in the "no brainer" category and should have been implemented at the very >>>>> least since JFX 8. >>>>> >>>>> >>>>> >>>>> >>>>>> On 12 May 2016, at 01:11, Kevin Rushforth >>>>>> wrote: >>>>>> >>>>>> No. WebGL support is not planned for JDK 9. We will look at this for >>>>>> JDK 10. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Felix Bembrick wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Will this new WebKit finally support WebGL? >>>>>>> >>>>>>> Just by supporting WebGL in the JavaFX WebView will instantly enable >>>>>>> an entire new set of 3D features and access to a plethora of JavaScript 3D >>>>>>> libraries for "free". >>>>>>> >>>>>>> And, Google Maps will finally work too. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 11 May 2016, at 08:20, Kevin Rushforth < >>>>>>>> kevin.rushforth at oracle.com> wrote: >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> As a heads-up, we plan to push an updated WebKit to FX 9-dev early >>>>>>>> next week [1]. If there are no build problems, they will be integrated to 9 >>>>>>>> master the following week for jdk-9+119. We then plan to backport the newer >>>>>>>> WebKit (to keep them in sync) to 8u-dev a couple weeks later. >>>>>>>> >>>>>>>> The only new tool needed to build this is CMake [2] version 3.4 or >>>>>>>> later (we will use 3.4.1 to build). >>>>>>>> >>>>>>>> Let me know if you have any questions. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8156698 >>>>>>>> >>>>>>>> [2] http://cmake.org/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> From Alan.Bateman at oracle.com Fri May 27 13:12:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 May 2016 14:12:13 +0100 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <574841F5.8010306@oracle.com> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> <57471886.10703@oracle.com> <57482927.8030808@oracle.com> <574841F5.8010306@oracle.com> Message-ID: <574847AD.2050807@oracle.com> On 27/05/2016 13:47, Kevin Rushforth wrote: > > The qualified exports are done using reflection to the calling module > that contains the javafx.embed.swt.FXCanvas class, irrespective of the > name of the module (so it works even when the javafx.embed.swt package > is in the unnamed module). I plan to file a follow-on bug to tighten > the integrity checks, which may or may not include requiring it to be > in a module named "javafx.swt", depending on whether all of the use > cases can be done with javafx-swt.jar being loaded in a named module > (e.g., Mandy's recommendation of using the Layer API). Okay and using addExports is really the only way this will work when javafx.swt is a child layer. As regards the mixing of code in named modules and unnamed modules then it should work fine. javafx.swt will read all modules in the boot layer. Code this module will also link to SWT types and for that to work then they must be visible by means of its class loader. The simplest is to just specify that loader as the parent class loader when creating the child layer. -Alan From kevin.rushforth at oracle.com Fri May 27 13:24:07 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 May 2016 06:24:07 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <574847AD.2050807@oracle.com> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> <57471886.10703@oracle.com> <57482927.8030808@oracle.com> <574841F5.8010306@oracle.com> <574847AD.2050807@oracle.com> Message-ID: <57484A77.1000207@oracle.com> Thanks for confirming. So it sounds like we have a workable plan. -- Kevin Alan Bateman wrote: > > > On 27/05/2016 13:47, Kevin Rushforth wrote: >> >> The qualified exports are done using reflection to the calling module >> that contains the javafx.embed.swt.FXCanvas class, irrespective of >> the name of the module (so it works even when the javafx.embed.swt >> package is in the unnamed module). I plan to file a follow-on bug to >> tighten the integrity checks, which may or may not include requiring >> it to be in a module named "javafx.swt", depending on whether all of >> the use cases can be done with javafx-swt.jar being loaded in a named >> module (e.g., Mandy's recommendation of using the Layer API). > Okay and using addExports is really the only way this will work when > javafx.swt is a child layer. > > As regards the mixing of code in named modules and unnamed modules > then it should work fine. javafx.swt will read all modules in the boot > layer. Code this module will also link to SWT types and for that to > work then they must be visible by means of its class loader. The > simplest is to just specify that loader as the parent class loader > when creating the child layer. > > -Alan From felix.bembrick at gmail.com Fri May 27 13:34:30 2016 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 27 May 2016 23:34:30 +1000 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: <574842DF.8010102@oracle.com> References: <57325EA2.5090405@oracle.com> <324A50CE-B381-4FCB-A354-9022C09AE410@gmail.com> <57334BB4.9080405@oracle.com> <5734A6A5.9050508@oracle.com> <1AD675BD-C241-4678-9457-AA538654C113@gmail.com> <91AF1100-562B-4D09-A5F9-6DE1F6AC661B@gmail.com> <574842DF.8010102@oracle.com> Message-ID: <57BF8724-5D91-4B51-A52C-2AABE9780AAD@gmail.com> Can you at least let me know why the JavaFX usage of WebKit does *not* support WebGL when native WebKit itself always has? Is there some technical or architectural barrier? > On 27 May 2016, at 22:51, Kevin Rushforth wrote: > > No, I don't have anything further to add about WebGL, if that's what you are asking. > > As for moving to Blink, that would be a very large effort. We do not currently plan to do this for JDK 10, but could reevaluate it in the future if something changes. > > -- Kevin > > > Felix Bembrick wrote: >> Any comments on this? Isn't it time to move to Blink? >> >> >>> On 13 May 2016, at 04:32, Felix Bembrick wrote: >>> >>> Thanks Kevin. >>> >>> I was more curious as to why WebGL support hasn't been there since day 1, given that WebKit itself supports it. >>> >>> Felix >>> >>> >>>> On 13 May 2016, at 01:52, Kevin Rushforth wrote: >>>> >>>> It was an issue of resources versus priority and scope. JDK 9 is focused on Jigsaw modularity and a few other minor features. It is more of a "smoothing out" release than a big feature release (except for Jigsaw). We expect JDK 10 to be a somewhat more feature-oriented release. >>>> >>>> -- Kevin >>>> >>>> >>>> Felix Bembrick wrote: >>>> >>>>> Do you mind if I ask what the rationale behind such a decision is? >>>>> >>>>> From an admittedly perhaps totally ignorant outside observer, it would seem to me that any cost/benefit analysis would basically put this feature in the "no brainer" category and should have been implemented at the very least since JFX 8. >>>>> >>>>> >>>>> >>>>>> On 12 May 2016, at 01:11, Kevin Rushforth wrote: >>>>>> >>>>>> No. WebGL support is not planned for JDK 9. We will look at this for JDK 10. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Felix Bembrick wrote: >>>>>> >>>>>> >>>>>>> Will this new WebKit finally support WebGL? >>>>>>> >>>>>>> Just by supporting WebGL in the JavaFX WebView will instantly enable an entire new set of 3D features and access to a plethora of JavaScript 3D libraries for "free". >>>>>>> >>>>>>> And, Google Maps will finally work too. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 11 May 2016, at 08:20, Kevin Rushforth wrote: >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> As a heads-up, we plan to push an updated WebKit to FX 9-dev early next week [1]. If there are no build problems, they will be integrated to 9 master the following week for jdk-9+119. We then plan to backport the newer WebKit (to keep them in sync) to 8u-dev a couple weeks later. >>>>>>>> >>>>>>>> The only new tool needed to build this is CMake [2] version 3.4 or later (we will use 3.4.1 to build). >>>>>>>> >>>>>>>> Let me know if you have any questions. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8156698 >>>>>>>> >>>>>>>> [2] http://cmake.org/ >>>>>>>> >>>>>>>> >>>>>>>> From mp at jugs.org Fri May 27 14:04:36 2016 From: mp at jugs.org (Dr. Michael Paus) Date: Fri, 27 May 2016 16:04:36 +0200 Subject: JavaFX with Eclipse and JDK9 Message-ID: I recently tried to get a JavaFX application running with the latest EA build of JDK9 from within Eclipse but I failed. Can anybody on this list tell me what I have to do to get that working? I have the latest milestone release of Eclipse Neon installed together with the latest JDK9 and I have also installed the Java 9 Support (BETA) for Neon. I also installed e(fx)clipse if that should matter. The problem is that I cannot access any of the JavaFX packages. I even added a module-info.java file to the project which explicitly requires the JavaFX modules but nothing helped so far. The JRE System Library only contains the modules which are in the java.* namespace but none of the other modules especially the javafx.* modules and I don't find any option to add these. Did anybody ever try this and succeeded? Thanks, Michael From kevin.rushforth at oracle.com Fri May 27 14:11:36 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 May 2016 07:11:36 -0700 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: <57BF8724-5D91-4B51-A52C-2AABE9780AAD@gmail.com> References: <57325EA2.5090405@oracle.com> <324A50CE-B381-4FCB-A354-9022C09AE410@gmail.com> <57334BB4.9080405@oracle.com> <5734A6A5.9050508@oracle.com> <1AD675BD-C241-4678-9457-AA538654C113@gmail.com> <91AF1100-562B-4D09-A5F9-6DE1F6AC661B@gmail.com> <574842DF.8010102@oracle.com> <57BF8724-5D91-4B51-A52C-2AABE9780AAD@gmail.com> Message-ID: <57485598.4080908@oracle.com> As I mentioned before, it is a non-trivial amount of work to integrate it into FX. We don't use the WebKit native renderer, rather the WebKit renderer is implemented by calling into Prism. Further, we use DirectX on Windows, which adds an additional complication (yes I know that WebGL has a solution for that, but integrating it will require a fair bit of work). Having said that, WebGL support in JavaFX is a likely JDK 10 feature. -- Kevin Felix Bembrick wrote: > Can you at least let me know why the JavaFX usage of WebKit does *not* support WebGL when native WebKit itself always has? > > Is there some technical or architectural barrier? > > >> On 27 May 2016, at 22:51, Kevin Rushforth wrote: >> >> No, I don't have anything further to add about WebGL, if that's what you are asking. >> >> As for moving to Blink, that would be a very large effort. We do not currently plan to do this for JDK 10, but could reevaluate it in the future if something changes. >> >> -- Kevin >> >> >> Felix Bembrick wrote: >> >>> Any comments on this? Isn't it time to move to Blink? >>> >>> >>> >>>> On 13 May 2016, at 04:32, Felix Bembrick wrote: >>>> >>>> Thanks Kevin. >>>> >>>> I was more curious as to why WebGL support hasn't been there since day 1, given that WebKit itself supports it. >>>> >>>> Felix >>>> >>>> >>>> >>>>> On 13 May 2016, at 01:52, Kevin Rushforth wrote: >>>>> >>>>> It was an issue of resources versus priority and scope. JDK 9 is focused on Jigsaw modularity and a few other minor features. It is more of a "smoothing out" release than a big feature release (except for Jigsaw). We expect JDK 10 to be a somewhat more feature-oriented release. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Felix Bembrick wrote: >>>>> >>>>> >>>>>> Do you mind if I ask what the rationale behind such a decision is? >>>>>> >>>>>> From an admittedly perhaps totally ignorant outside observer, it would seem to me that any cost/benefit analysis would basically put this feature in the "no brainer" category and should have been implemented at the very least since JFX 8. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On 12 May 2016, at 01:11, Kevin Rushforth wrote: >>>>>>> >>>>>>> No. WebGL support is not planned for JDK 9. We will look at this for JDK 10. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Felix Bembrick wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Will this new WebKit finally support WebGL? >>>>>>>> >>>>>>>> Just by supporting WebGL in the JavaFX WebView will instantly enable an entire new set of 3D features and access to a plethora of JavaScript 3D libraries for "free". >>>>>>>> >>>>>>>> And, Google Maps will finally work too. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 11 May 2016, at 08:20, Kevin Rushforth wrote: >>>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> As a heads-up, we plan to push an updated WebKit to FX 9-dev early next week [1]. If there are no build problems, they will be integrated to 9 master the following week for jdk-9+119. We then plan to backport the newer WebKit (to keep them in sync) to 8u-dev a couple weeks later. >>>>>>>>> >>>>>>>>> The only new tool needed to build this is CMake [2] version 3.4 or later (we will use 3.4.1 to build). >>>>>>>>> >>>>>>>>> Let me know if you have any questions. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8156698 >>>>>>>>> >>>>>>>>> [2] http://cmake.org/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> From kevin.rushforth at oracle.com Fri May 27 14:13:36 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 May 2016 07:13:36 -0700 Subject: JavaFX with Eclipse and JDK9 In-Reply-To: References: Message-ID: <57485610.40900@oracle.com> Where did you download it from? What build is it (i.e., what is the output of "java -version")? Can you run "java -listmods" and see whether the javafx.* modules are there? -- Kevin Dr. Michael Paus wrote: > I recently tried to get a JavaFX application running with the latest > EA build of JDK9 from > within Eclipse but I failed. Can anybody on this list tell me what I > have to do to get that > working? I have the latest milestone release of Eclipse Neon installed > together with the > latest JDK9 and I have also installed the Java 9 Support (BETA) for > Neon. I also installed > e(fx)clipse if that should matter. The problem is that I cannot access > any of the JavaFX > packages. I even added a module-info.java file to the project which > explicitly requires the > JavaFX modules but nothing helped so far. The JRE System Library only > contains the modules > which are in the java.* namespace but none of the other modules > especially the javafx.* > modules and I don't find any option to add these. Did anybody ever try > this and succeeded? > > Thanks, Michael > From andrey.rusakov at oracle.com Fri May 27 14:55:58 2016 From: andrey.rusakov at oracle.com (Andrey Rusakov) Date: Fri, 27 May 2016 17:55:58 +0300 Subject: Open test development: JDK-8139764 In-Reply-To: <57458B43.3020805@oracle.com> References: <57458B43.3020805@oracle.com> Message-ID: <57485FFE.9060109@oracle.com> Please look at my new test for regression JDK-8139764 http://cr.openjdk.java.net/~arusakov/8139764/webrev.00/ From kevin.rushforth at oracle.com Fri May 27 15:59:22 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 May 2016 08:59:22 -0700 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: References: <57325EA2.5090405@oracle.com> <324A50CE-B381-4FCB-A354-9022C09AE410@gmail.com> <57334BB4.9080405@oracle.com> <5734A6A5.9050508@oracle.com> <1AD675BD-C241-4678-9457-AA538654C113@gmail.com> <91AF1100-562B-4D09-A5F9-6DE1F6AC661B@gmail.com> <574842DF.8010102@oracle.com> Message-ID: <57486EDA.40107@oracle.com> We're too focused on JDK 9 to think about JDK 10 yet. After we stabilize JDK 9 we'll start planning. At that time we will solicit feedback from the openjfx-dev community to help prioritize. -- Kevin Konstantin Pasko wrote: > Hi Kevin, > > sorry for the offtopic, but as you just mentioned JDK 10, could you > please tell us what is planned for that release? > Something from the high level? New/missing features, controls, huge > bugfixes? > Googling "javafx road map" or "javafx jdk10" gives no results and > looking > through https://bugs.openjdk.java.net/projects/JDK/versions/16302 is > quite time-consuming. > > > With best regards, > Konstantin > > 2016-05-27 14:51 GMT+02:00 Kevin Rushforth >: > > No, I don't have anything further to add about WebGL, if that's > what you are asking. > > As for moving to Blink, that would be a very large effort. We do > not currently plan to do this for JDK 10, but could reevaluate it > in the future if something changes. > > > -- Kevin > > > Felix Bembrick wrote: > > Any comments on this? Isn't it time to move to Blink? > > > > On 13 May 2016, at 04:32, Felix Bembrick > > wrote: > > Thanks Kevin. > > I was more curious as to why WebGL support hasn't been > there since day 1, given that WebKit itself supports it. > > Felix > > > > On 13 May 2016, at 01:52, Kevin Rushforth > > wrote: > > It was an issue of resources versus priority and > scope. JDK 9 is focused on Jigsaw modularity and a few > other minor features. It is more of a "smoothing out" > release than a big feature release (except for > Jigsaw). We expect JDK 10 to be a somewhat more > feature-oriented release. > > -- Kevin > > > Felix Bembrick wrote: > > > Do you mind if I ask what the rationale behind > such a decision is? > > From an admittedly perhaps totally ignorant > outside observer, it would seem to me that any > cost/benefit analysis would basically put this > feature in the "no brainer" category and should > have been implemented at the very least since JFX 8. > > > > > On 12 May 2016, at 01:11, Kevin Rushforth > > wrote: > > No. WebGL support is not planned for JDK 9. We > will look at this for JDK 10. > > -- Kevin > > > Felix Bembrick wrote: > > > > Will this new WebKit finally support WebGL? > > Just by supporting WebGL in the JavaFX > WebView will instantly enable an entire > new set of 3D features and access to a > plethora of JavaScript 3D libraries for > "free". > > And, Google Maps will finally work too. > > > > > On 11 May 2016, at 08:20, Kevin > Rushforth > > wrote: > > All, > > As a heads-up, we plan to push an > updated WebKit to FX 9-dev early next > week [1]. If there are no build > problems, they will be integrated to 9 > master the following week for > jdk-9+119. We then plan to backport > the newer WebKit (to keep them in > sync) to 8u-dev a couple weeks later. > > The only new tool needed to build this > is CMake [2] version 3.4 or later (we > will use 3.4.1 to build). > > Let me know if you have any questions. > > -- Kevin > > [1] > https://bugs.openjdk.java.net/browse/JDK-8156698 > > [2] http://cmake.org/ > > > > > From mandy.chung at oracle.com Fri May 27 16:58:59 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 27 May 2016 09:58:59 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> <57471886.10703@oracle.com> Message-ID: > On May 27, 2016, at 1:30 AM, Tom Schindl wrote: > > Do you have an example how to construct such a Layer? // path is the path to javafx-swt.jar ModuleFinder finder = ModuleFinder.of(path); Configuration cf = Layer.boot() .configuration() .resolveRequires(finder, ModuleFinder.of(), Set.of("javafx.swt")); // ?parent? is the class loader to which SWT types are visible Layer layer = Layer.boot().defineModulesWithOneLoader(cf, parent); // the class loader defining javafx.swt module ClassLoader loader = layer.findLoader("javafx.swt?); [1] will show more examples of Layer. Mandy [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/df35a805b405/test/java/lang/reflect/Layer/LayerAndLoadersTest.java From vadim.pakhnushev at oracle.com Fri May 27 17:10:04 2016 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 27 May 2016 20:10:04 +0300 Subject: In(Sanity) Testing Mondays Message-ID: Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From kevin.rushforth at oracle.com Fri May 27 17:18:29 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 27 May 2016 10:18:29 -0700 Subject: In(Sanity) Testing Mondays In-Reply-To: References: Message-ID: <57488165.9050203@oracle.com> Please note that Monday is a US holiday, so the testing will be a bit lighter than usual. As I won't be around to send the "unlock" message, consider it unlocked at 1pm Pacific on Monday. Thanks. -- Kevin Vadim Pakhnushev wrote: > Reminder, Monday is our weekly sanity testing. > > You can find your testing assignment at: > https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing > > Also please remember that the repo will be locked from 1am PST until > 1pm PST. > > Happy testing! > > Thanks, > Vadim From james.graham at oracle.com Fri May 27 22:02:51 2016 From: james.graham at oracle.com (Jim Graham) Date: Fri, 27 May 2016 15:02:51 -0700 Subject: [9] Review request for 8157600: Failed to launch hello.HelloSanity due to libglass.so: undefined symbol In-Reply-To: <7b1adea7-7e20-c044-96c8-54c7adf40cd8@oracle.com> References: <7b1adea7-7e20-c044-96c8-54c7adf40cd8@oracle.com> Message-ID: <27f2c051-75ef-5c30-224a-c9a6cb287070@oracle.com> A new webrev is available now that hopes to make sure the new functions have C-style external dependency names regardless of how gio.h is included: http://cr.openjdk.java.net/~flar/JDK-8157600/webrev.01/ ...jim On 5/26/16 5:43 PM, Jim Graham wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8157600 > webrev: http://cr.openjdk.java.net/~flar/JDK-8157600/webrev.00/ > > ...jim > From dalibor.topic at oracle.com Mon May 30 15:02:18 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 30 May 2016 17:02:18 +0200 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: References: <57325EA2.5090405@oracle.com> <324A50CE-B381-4FCB-A354-9022C09AE410@gmail.com> <57334BB4.9080405@oracle.com> <5734A6A5.9050508@oracle.com> <1AD675BD-C241-4678-9457-AA538654C113@gmail.com> <91AF1100-562B-4D09-A5F9-6DE1F6AC661B@gmail.com> <574842DF.8010102@oracle.com> Message-ID: <4cc21842-fb97-eba2-51a2-cc8f5c90dbb0@oracle.com> On 27.05.2016 15:10, Konstantin Pasko wrote: > Hi Kevin, > > sorry for the offtopic, but as you just mentioned JDK 10, could you please > tell us what is planned for that release? You can track JEPs being drafted for 10 at http://openjdk.java.net/jeps/0 . cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From matthieu at brouillard.fr Mon May 30 19:50:50 2016 From: matthieu at brouillard.fr (Matthieu BROUILLARD) Date: Mon, 30 May 2016 21:50:50 +0200 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: <57325EA2.5090405@oracle.com> References: <57325EA2.5090405@oracle.com> Message-ID: @Kevin will this upate finally find On Wed, May 11, 2016 at 12:20 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > All, > > As a heads-up, we plan to push an updated WebKit to FX 9-dev early next > week [1]. If there are no build problems, they will be integrated to 9 > master the following week for jdk-9+119. We then plan to backport the newer > WebKit (to keep them in sync) to 8u-dev a couple weeks later. > > The only new tool needed to build this is CMake [2] version 3.4 or later > (we will use 3.4.1 to build). > > Let me know if you have any questions. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8156698 > > [2] http://cmake.org/ > > From matthieu at brouillard.fr Mon May 30 19:52:25 2016 From: matthieu at brouillard.fr (Matthieu BROUILLARD) Date: Mon, 30 May 2016 21:52:25 +0200 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: <57325EA2.5090405@oracle.com> References: <57325EA2.5090405@oracle.com> Message-ID: Sorry previous mail sent before fully written. :-( Will this enhancement be backported to JDK8? Matthieu On Wed, May 11, 2016 at 12:20 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > All, > > As a heads-up, we plan to push an updated WebKit to FX 9-dev early next > week [1]. If there are no build problems, they will be integrated to 9 > master the following week for jdk-9+119. We then plan to backport the newer > WebKit (to keep them in sync) to 8u-dev a couple weeks later. > > The only new tool needed to build this is CMake [2] version 3.4 or later > (we will use 3.4.1 to build). > > Let me know if you have any questions. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8156698 > > [2] http://cmake.org/ > > From jonathan.giles at oracle.com Mon May 30 20:00:40 2016 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 31 May 2016 08:00:40 +1200 Subject: HEADS-UP: plan to integrate a newer WebKit into 9-dev next week. In-Reply-To: References: <57325EA2.5090405@oracle.com> Message-ID: <3557F4BC-E672-4D2E-B33A-B26B47E39AD2@oracle.com> I'm not involved in WebKit work at all (so I'm no authority on this), but it sounds like what you're asking is already answered in Kevin's email that you quoted. -- Jonathan Sent from a touch device. Please excuse my brevity. On 31 May 2016 07:52:25 GMT+12:00, Matthieu BROUILLARD wrote: >Sorry previous mail sent before fully written. :-( > >Will this enhancement be backported to JDK8? > >Matthieu > >On Wed, May 11, 2016 at 12:20 AM, Kevin Rushforth < >kevin.rushforth at oracle.com> wrote: > >> All, >> >> As a heads-up, we plan to push an updated WebKit to FX 9-dev early >next >> week [1]. If there are no build problems, they will be integrated to >9 >> master the following week for jdk-9+119. We then plan to backport the >newer >> WebKit (to keep them in sync) to 8u-dev a couple weeks later. >> >> The only new tool needed to build this is CMake [2] version 3.4 or >later >> (we will use 3.4.1 to build). >> >> Let me know if you have any questions. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8156698 >> >> [2] http://cmake.org/ >> >>