From nlisker at gmail.com Mon Apr 2 09:52:56 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 2 Apr 2018 12:52:56 +0300 Subject: Prism documentation Message-ID: Hi Kevin, Since Prism is only used internally it has no publicly available documentation (none that I could fine). I was wondering if there are any design materials or writeups that exist internally and can be released for development purpose. Specifically, I was looking at the d3d pipeline was was baffled by the use of self-defined classes (like D3DLight) when d3d already offers classes with these classes (D3DLight9). - Nir From paulrussell70 at gmail.com Mon Apr 2 13:07:05 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Mon, 2 Apr 2018 14:07:05 +0100 Subject: Prism documentation (Nir Lisker) Message-ID: Yes please for some documentation. And the way that Prism renderer fails: for example if you supply an OpenGL or D3D texture > max GPU texture size is difficult to deal with. There should be a set of catchable Prism Renderer errors. On 2 April 2018 at 13:00, wrote: > Send openjfx-dev mailing list submissions to > openjfx-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > or, via email, send a message with subject or body 'help' to > openjfx-dev-request at openjdk.java.net > > You can reach the person managing the list at > openjfx-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openjfx-dev digest..." > > > Today's Topics: > > 1. Prism documentation (Nir Lisker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 2 Apr 2018 12:52:56 +0300 > From: Nir Lisker > To: Kevin Rushforth > Cc: "openjfx-dev at openjdk.java.net Mailing" > > Subject: Prism documentation > Message-ID: > mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi Kevin, > > Since Prism is only used internally it has no publicly available > documentation (none that I could fine). I was wondering if there are any > design materials or writeups that exist internally and can be released for > development purpose. > > Specifically, I was looking at the d3d pipeline was was baffled by the use > of self-defined classes (like D3DLight) when d3d already offers classes > with these classes (D3DLight9). > > - Nir > > > End of openjfx-dev Digest, Vol 77, Issue 1 > ****************************************** > From nlisker at gmail.com Mon Apr 2 18:58:15 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 2 Apr 2018 21:58:15 +0300 Subject: JDK-8200587: Fix mistakes in FX API docs Message-ID: Hi all, Iv'e created another issue for collecting JavaDoc corrections: https://bugs.openjdk.java.net/browse/JDK-8200587. If you found any, please add them to this issue and I'll fix them along with what's there already. Kevin, * Different items on the list affect different versions, but they are all relevant for the latest 11ea build. If there are plans to backport they would need to be sorted out. One of them is a regression from 8 (in Dialog), but it's trivial. * I collected 2 recent issues into this one (links in the issue), so should I close them as duplicates? Thanks, Nir From kevin.rushforth at oracle.com Mon Apr 2 19:11:23 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 02 Apr 2018 12:11:23 -0700 Subject: JDK-8200587: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: <5AC2805B.8030606@oracle.com> Nir Lisker wrote: > Hi all, > > Iv'e created another issue for collecting JavaDoc > corrections: https://bugs.openjdk.java.net/browse/JDK-8200587. If you > found any, please add them to this issue and I'll fix them along with > what's there already. Thanks for creating this bug and providing a fix. I'll take a look in the next day or so. > Kevin, > > * Different items on the list affect different versions, but they are > all relevant for the latest 11ea build. If there are plans to backport > they would need to be sorted out. One of them is a regression from 8 > (in Dialog), but it's trivial. OK, thanks for the info. We have no plans to backport any of these. > * I collected 2 recent issues into this one (links in the issue), so > should I close them as duplicates? Yes, please. -- Kevin > Thanks, > Nir From nlisker at gmail.com Mon Apr 2 19:44:25 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 2 Apr 2018 22:44:25 +0300 Subject: JDK-8200587: Fix mistakes in FX API docs In-Reply-To: <5AC2805B.8030606@oracle.com> References: <5AC2805B.8030606@oracle.com> Message-ID: > > Thanks for creating this bug and providing a fix. I'll take a look in the > next day or so. I actually didn't link a Webrev yet as I'm waiting a couple of days to see if someone want to add something. I'll sent a review request when I upload the fix. - Nir On Mon, Apr 2, 2018 at 10:11 PM, Kevin Rushforth wrote: > > > Nir Lisker wrote: > >> Hi all, >> >> Iv'e created another issue for collecting JavaDoc corrections: >> https://bugs.openjdk.java.net/browse/JDK-8200587. If you found any, >> please add them to this issue and I'll fix them along with what's there >> already. >> > > Thanks for creating this bug and providing a fix. I'll take a look in the > next day or so. > > > Kevin, >> >> * Different items on the list affect different versions, but they are all >> relevant for the latest 11ea build. If there are plans to backport they >> would need to be sorted out. One of them is a regression from 8 (in >> Dialog), but it's trivial. >> > > OK, thanks for the info. We have no plans to backport any of these. > > * I collected 2 recent issues into this one (links in the issue), so >> should I close them as duplicates? >> > > Yes, please. > > -- Kevin > > > Thanks, >> Nir >> > From kevin.rushforth at oracle.com Mon Apr 2 19:49:26 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 02 Apr 2018 12:49:26 -0700 Subject: JDK-8200587: Fix mistakes in FX API docs In-Reply-To: References: <5AC2805B.8030606@oracle.com> Message-ID: <5AC28946.8090902@oracle.com> That sounds like a good idea. -- Kevin Nir Lisker wrote: > > Thanks for creating this bug and providing a fix. I'll take a look > in the next day or so. > > > I actually didn't link a Webrev yet as I'm waiting a couple of days to > see if someone want to add something. I'll sent a review request when > I upload the fix. > > - Nir > > On Mon, Apr 2, 2018 at 10:11 PM, Kevin Rushforth > > wrote: > > > > Nir Lisker wrote: > > Hi all, > > Iv'e created another issue for collecting JavaDoc corrections: > https://bugs.openjdk.java.net/browse/JDK-8200587 > . If you > found any, please add them to this issue and I'll fix them > along with what's there already. > > > Thanks for creating this bug and providing a fix. I'll take a look > in the next day or so. > > > Kevin, > > * Different items on the list affect different versions, but > they are all relevant for the latest 11ea build. If there are > plans to backport they would need to be sorted out. One of > them is a regression from 8 (in Dialog), but it's trivial. > > > OK, thanks for the info. We have no plans to backport any of these. > > * I collected 2 recent issues into this one (links in the > issue), so should I close them as duplicates? > > > Yes, please. > > -- Kevin > > > Thanks, > Nir > > From prem.balakrishnan at oracle.com Tue Apr 3 04:49:25 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Mon, 2 Apr 2018 21:49:25 -0700 (PDT) Subject: [11] Review Request: JDK 8152187 Make fitWidth of ImageView stylable as fit-width Message-ID: Hi Kevin, Ajit Request you to review following fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8152187 Webrev: http://cr.openjdk.java.net/~pkbalakr/fx/8152187/webrev.00/ Regards, Prem From ajit.ghaisas at oracle.com Tue Apr 3 06:33:10 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Mon, 2 Apr 2018 23:33:10 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5ABD1766.8020204@oracle.com> References: <5ABD1766.8020204@oracle.com> Message-ID: Vote: Yes Regards, Ajit -----Original Message----- From: Kevin Rushforth Sent: Thursday, March 29, 2018 10:12 PM To: openjfx-dev at openjdk.java.net; Rajath Kamath Subject: CFV: New OpenJFX Committer: Rajath Kamath I hereby nominate Rajath Kamath [1] to OpenJFX Committer. Rajath is a member of JavaFX team at Oracle, who has contributed 17 changesets [2][3] to OpenJFX. Votes are due by April 12, 2018. Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. By way of background, an earlier nomination failed [7]. Since then, Rajath has contributed 2 more test fixes and 1 more product fix. Thanks. -- Kevin [1] http://openjdk.java.net/census#rkamath [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28rkamath%29 [3] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=rajath.kamath [4] http://openjdk.java.net/census#openjfx [5] http://openjdk.java.net/bylaws#lazy-consensus [6] http://openjdk.java.net/projects#project-committer [7] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021499.html From guru.hb at oracle.com Tue Apr 3 08:42:17 2018 From: guru.hb at oracle.com (Guru) Date: Tue, 3 Apr 2018 14:12:17 +0530 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5ABD1766.8020204@oracle.com> References: <5ABD1766.8020204@oracle.com> Message-ID: <740FDD88-E570-4141-9FC1-529B0272CDF2@oracle.com> Vote: YES > On 29-Mar-2018, at 10:12 PM, Kevin Rushforth wrote: > > I hereby nominate Rajath Kamath [1] to OpenJFX Committer. > > Rajath is a member of JavaFX team at Oracle, who has contributed 17 changesets [2][3] to OpenJFX. > > Votes are due by April 12, 2018. > > Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. > > By way of background, an earlier nomination failed [7]. Since then, Rajath has contributed 2 more test fixes and 1 more product fix. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#rkamath > > [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=author%28rkamath%29 > [3] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=rajath.kamath > > [4] http://openjdk.java.net/census#openjfx > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > [6] http://openjdk.java.net/projects#project-committer > > [7] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021499.html > From johan.vos at gluonhq.com Tue Apr 3 12:46:00 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 03 Apr 2018 12:46:00 +0000 Subject: Add missing styleable properties to ImageView? Message-ID: There is a discussion on an issue at github whether some properties on ImageView need to be css-styleable: https://github.com/javafxports/openjdk-jfx/issues/29 As not everybody is checking those issues, I want to bring this under the attention of the list, as it has important consequences (once we do this, what other properties might follow?) There is a related PR at https://github.com/javafxports/openjdk-jfx/pull/30 I don't have a particular opinion on this topic, but I want to hear what others think. - Johan From prem.balakrishnan at oracle.com Wed Apr 4 06:44:13 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Tue, 3 Apr 2018 23:44:13 -0700 (PDT) Subject: Add missing styleable properties to ImageView? In-Reply-To: References: Message-ID: <2cc2c2f9-73ab-4786-99c0-121cae340379@default> Hi Johan, I was not aware of this PR and hence worked on this RFE separately. Thanks for bringing it to my notice. I am watching the thread now and I will let Andres take it forward. Regards, Prem -----Original Message----- From: Johan Vos Sent: Tuesday, April 03, 2018 6:16 PM To: openjfx-dev at openjdk.java.net List Subject: Add missing styleable properties to ImageView? There is a discussion on an issue at github whether some properties on ImageView need to be css-styleable: https://github.com/javafxports/openjdk-jfx/issues/29 As not everybody is checking those issues, I want to bring this under the attention of the list, as it has important consequences (once we do this, what other properties might follow?) There is a related PR at https://github.com/javafxports/openjdk-jfx/pull/30 I don't have a particular opinion on this topic, but I want to hear what others think. - Johan From ajit.ghaisas at oracle.com Wed Apr 4 12:12:32 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 4 Apr 2018 05:12:32 -0700 (PDT) Subject: [11] Review request : JDK-8185854 : [JavaFX 9] NPE on non-editable ComboBox in TabPane with custom Skin Message-ID: Hi, Please review below fix. Bug : https://bugs.openjdk.java.net/browse/JDK-8185854 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8185854/webrev.0/ Request you to review. Regards, Ajit From kevin.rushforth at oracle.com Wed Apr 4 13:14:44 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 04 Apr 2018 06:14:44 -0700 Subject: OpenJFX GitHub mirror In-Reply-To: References: <5ABC43E6.10504@oracle.com> <055d45e1-1c38-6f82-2d9e-8f62a10d77d4@bestsolution.at> Message-ID: <5AC4CFC4.7080301@oracle.com> Any further comments on this? If not, then I propose we start using the JBS label: github-bug To identify JBS issues that are linked to guthub issues and/or PRs -- Kevin Nir Lisker wrote: > I think that the labels should be succinct, so one label should suffice. > Either github-link or github-bug are fine for me, the latter because there > is webbug label already. If a PR needs review just use the review-request > existing label. > > As for issues and PRs, the issue links section in the JIRA ticket could > reflect what exists in GitHub, so there can be 2 web links named "GitHub > issue" and "GitHub PR" if need be. > > - Nir > > On Thu, Mar 29, 2018 at 10:08 AM, Tom Schindl > wrote: > > >> well could we have 2: >> * github-issue >> * github-pr >> >> The first one indicates someone is working on it over at github, whereas >> the second means there's a PR that needs to be review. >> >> Tom >> >> On 29.03.18 08:42, Laurent Bourg?s wrote: >> >>> Hi, >>> >>> As such github references point to either issue or PR, I recommend using >>> the term 'github-link'. >>> >>> Laurent >>> >>> Le jeu. 29 mars 2018 ? 03:40, Kevin Rushforth < >>> >> kevin.rushforth at oracle.com> >> >>> a ?crit : >>> >>> >>>> I think this would be fine. We would want something that didn't conflict >>>> with anything else and wasn't confusing. Possible choices: >>>> >>>> github-link >>>> github-bug >>>> gitbug-issue >>>> >>>> Any preferences? >>>> >>>> -- Kevin >>>> >>>> >>>> Nir Lisker wrote: >>>> >>>>> Kevin, can we get a label for this? >>>>> >>>>> - Nir >>>>> >>>>> On Mon, Mar 26, 2018 at 4:37 PM, Johan Vos >>>>> >>>> wrote: >>>> >>>>> >>>>>> Hi Nir, >>>>>> >>>>>> About 4. (jfx-dev): you're right, I just removed that repository. That >>>>>> >>>> was >>>> >>>>>> just some testing before we did the real thing. >>>>>> >>>>>> As for the other points: I agree >>>>>> >>>>>> - Johan >>>>>> >>>>>> On Mon, Mar 26, 2018 at 12:03 PM Nir Lisker >>>>>> >> wrote: >> >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> A few comments about the mirror and JBS: >>>>>>> >>>>>>> 1. In PRs and issues on GitHub, I strongly suggest that the link to >>>>>>> >>>> JBS be >>>> >>>>>>> included in the top comment. If the JBS issue was created after a >>>>>>> discussion, edit it in. >>>>>>> >>>>>>> 2. In JBS, I suggest to link to the GitHub mirror via More > Link > >>>>>>> >> Web >> >>>>>>> Link and in the Link Text use something like "GitHub mirror" (open >>>>>>> >> for >> >>>>>>> suggestions). JIRA renders the link in an easy to see way (easier >>>>>>> >> than >> >>>>>>> looking at URLs). Iv'e tried it in a couple of issues, e.g., >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8198795 and it seems >>>>>>> >>>> preferable >>>> >>>>>>> to >>>>>>> me. >>>>>>> >>>>>>> 3. In JBS, I suggest a new label will be used for issues which are >>>>>>> >>>> linked >>>> >>>>>>> to GitHub for search purposes. This is similar to the webbug label. >>>>>>> >>>>>>> If these are agreeable, please add them to the contribution >>>>>>> >>>> instructions. >>>> >>>>>>> 4. What is https://github.com/javafxports/jfx-dev? Newcomers can >>>>>>> >>>> confuse >>>> >>>>>>> it >>>>>>> with javafxports/openjdk-jfx. >>>>>>> >>>>>>> 5. When the mirror is fully ready and operational, we should >>>>>>> >> advertise >> >>>> on >>>> >>>>>>> community pages (like Reddit) to gather up contributors. Please keep >>>>>>> >> a >> >>>>>>> mental reminder when the time comes. >>>>>>> >>>>>>> Thanks to all who are working on this. >>>>>>> >>>>>>> - Nir >>>>>>> >>>>>>> >>>>>>> From johan.vos at gluonhq.com Wed Apr 4 13:43:45 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 04 Apr 2018 13:43:45 +0000 Subject: OpenJFX GitHub mirror In-Reply-To: <5AC4CFC4.7080301@oracle.com> References: <5ABC43E6.10504@oracle.com> <055d45e1-1c38-6f82-2d9e-8f62a10d77d4@bestsolution.at> <5AC4CFC4.7080301@oracle.com> Message-ID: +1 On Wed, Apr 4, 2018 at 3:30 PM Kevin Rushforth wrote: > Any further comments on this? If not, then I propose we start using the > JBS label: > > github-bug > > To identify JBS issues that are linked to guthub issues and/or PRs > > -- Kevin > > > Nir Lisker wrote: > > I think that the labels should be succinct, so one label should suffice. > > Either github-link or github-bug are fine for me, the latter because > there > > is webbug label already. If a PR needs review just use the review-request > > existing label. > > > > As for issues and PRs, the issue links section in the JIRA ticket could > > reflect what exists in GitHub, so there can be 2 web links named "GitHub > > issue" and "GitHub PR" if need be. > > > > - Nir > > > > On Thu, Mar 29, 2018 at 10:08 AM, Tom Schindl < > tom.schindl at bestsolution.at> > > wrote: > > > > > >> well could we have 2: > >> * github-issue > >> * github-pr > >> > >> The first one indicates someone is working on it over at github, whereas > >> the second means there's a PR that needs to be review. > >> > >> Tom > >> > >> On 29.03.18 08:42, Laurent Bourg?s wrote: > >> > >>> Hi, > >>> > >>> As such github references point to either issue or PR, I recommend > using > >>> the term 'github-link'. > >>> > >>> Laurent > >>> > >>> Le jeu. 29 mars 2018 ? 03:40, Kevin Rushforth < > >>> > >> kevin.rushforth at oracle.com> > >> > >>> a ?crit : > >>> > >>> > >>>> I think this would be fine. We would want something that didn't > conflict > >>>> with anything else and wasn't confusing. Possible choices: > >>>> > >>>> github-link > >>>> github-bug > >>>> gitbug-issue > >>>> > >>>> Any preferences? > >>>> > >>>> -- Kevin > >>>> > >>>> > >>>> Nir Lisker wrote: > >>>> > >>>>> Kevin, can we get a label for this? > >>>>> > >>>>> - Nir > >>>>> > >>>>> On Mon, Mar 26, 2018 at 4:37 PM, Johan Vos > >>>>> > >>>> wrote: > >>>> > >>>>> > >>>>>> Hi Nir, > >>>>>> > >>>>>> About 4. (jfx-dev): you're right, I just removed that repository. > That > >>>>>> > >>>> was > >>>> > >>>>>> just some testing before we did the real thing. > >>>>>> > >>>>>> As for the other points: I agree > >>>>>> > >>>>>> - Johan > >>>>>> > >>>>>> On Mon, Mar 26, 2018 at 12:03 PM Nir Lisker > >>>>>> > >> wrote: > >> > >>>>>> > >>>>>>> Hi All, > >>>>>>> > >>>>>>> A few comments about the mirror and JBS: > >>>>>>> > >>>>>>> 1. In PRs and issues on GitHub, I strongly suggest that the link to > >>>>>>> > >>>> JBS be > >>>> > >>>>>>> included in the top comment. If the JBS issue was created after a > >>>>>>> discussion, edit it in. > >>>>>>> > >>>>>>> 2. In JBS, I suggest to link to the GitHub mirror via More > Link > > >>>>>>> > >> Web > >> > >>>>>>> Link and in the Link Text use something like "GitHub mirror" (open > >>>>>>> > >> for > >> > >>>>>>> suggestions). JIRA renders the link in an easy to see way (easier > >>>>>>> > >> than > >> > >>>>>>> looking at URLs). Iv'e tried it in a couple of issues, e.g., > >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8198795 and it seems > >>>>>>> > >>>> preferable > >>>> > >>>>>>> to > >>>>>>> me. > >>>>>>> > >>>>>>> 3. In JBS, I suggest a new label will be used for issues which are > >>>>>>> > >>>> linked > >>>> > >>>>>>> to GitHub for search purposes. This is similar to the webbug label. > >>>>>>> > >>>>>>> If these are agreeable, please add them to the contribution > >>>>>>> > >>>> instructions. > >>>> > >>>>>>> 4. What is https://github.com/javafxports/jfx-dev? Newcomers can > >>>>>>> > >>>> confuse > >>>> > >>>>>>> it > >>>>>>> with javafxports/openjdk-jfx. > >>>>>>> > >>>>>>> 5. When the mirror is fully ready and operational, we should > >>>>>>> > >> advertise > >> > >>>> on > >>>> > >>>>>>> community pages (like Reddit) to gather up contributors. Please > keep > >>>>>>> > >> a > >> > >>>>>>> mental reminder when the time comes. > >>>>>>> > >>>>>>> Thanks to all who are working on this. > >>>>>>> > >>>>>>> - Nir > >>>>>>> > >>>>>>> > >>>>>>> > From matthew.james.elliot at gmail.com Wed Apr 4 14:03:12 2018 From: matthew.james.elliot at gmail.com (Matthew Elliot) Date: Wed, 4 Apr 2018 16:03:12 +0200 Subject: CSSParser Color.parse() for unexpected CSS properties Message-ID: Hi all, (first post). I was profiling our PROD JavaFX application recently I discovered something rather peculiar in the CSSParser. (jdk1.8.0_151) I noticed several hundred IllegalArgumentExceptions on the JavaApplicationThread where for various unrelated css properties the CSSParser is trying to parse a color. While the exception is subsequently caught and swallowed silently doing this hundred of times on this thread is rather ugly and caused *minor* delays in the application thread. This happened for alignment, shape, and a few other properties where no-lookup case was found and it ended on approx. line 900 of the CSSParser in colorValueOfString() with a value like 'center'; clearly no color. // if the property value is another property, then it needs to be looked up. boolean needsLookup = isIdent && properties.containsKey(text); if (needsLookup || ((value = colorValueOfString(str)) == null )) { // If the value is a lookup, make sure to use the lower-case text so it matches the property // in the Declaration. If the value is not a lookup, then use str since the value might // be a string which could have some case sensitive meaning // // TODO: isIdent is needed here because of RT-38345. This effectively undoes RT-38201 value = new ParsedValueImpl(needsLookup ? text : str, null, isIdent || needsLookup); } I had a look in the bug tracker https://bugs.openjdk.java.net/ but didn't find much in this regard so thought I would post in case it has come up before. I saw some of the css properties are from our application and some from e(fx)clipse which I can raise to Tom Schindl separately if it is a stylesheet issue, however it would appear that for example -fx-alignment in a layout VBOX/HBOX component should be valid according to JavaFX docs. More generally, is it expected that a property such as -fx-alignment should fall into this else {} catch all case, and why does JavaFX try to parse a Color by default? -fx-alignment: center; Any input much appreciated. Regards, Matt From david.grieve at oracle.com Wed Apr 4 14:20:12 2018 From: david.grieve at oracle.com (David Grieve) Date: Wed, 4 Apr 2018 10:20:12 -0400 Subject: CSSParser Color.parse() for unexpected CSS properties In-Reply-To: References: Message-ID: The parser doesn't have any concept of what the property is or value it might have. This allows the addition of new properties (such as an user might add for their own CSS styles) without having to modify the parser to handle them. On 4/4/18 10:03 AM, Matthew Elliot wrote: > Hi all, (first post). > > I was profiling our PROD JavaFX application recently I discovered something > rather peculiar in the CSSParser. (jdk1.8.0_151) > > I noticed several hundred IllegalArgumentExceptions on the > JavaApplicationThread where for various unrelated css properties the > CSSParser is trying to parse a color. While the exception is subsequently > caught and swallowed silently doing this hundred of times on this thread is > rather ugly and caused *minor* delays in the application thread. > > This happened for alignment, shape, and a few other properties where > no-lookup case was found and it ended on approx. line 900 of the CSSParser > in > > colorValueOfString() > > with a value like 'center'; clearly no color. > > // if the property value is another property, then it needs to be looked up. > boolean needsLookup = isIdent && properties.containsKey(text); > if (needsLookup || ((value = colorValueOfString(str)) == null )) { > // If the value is a lookup, make sure to use the lower-case text > so it matches the property > // in the Declaration. If the value is not a lookup, then use str > since the value might > // be a string which could have some case sensitive meaning > // > // TODO: isIdent is needed here because of RT-38345. This > effectively undoes RT-38201 > value = new ParsedValueImpl(needsLookup ? text : > str, null, isIdent || needsLookup); > } > > I had a look in the bug tracker https://bugs.openjdk.java.net/ but didn't > find much in this regard so thought I would post in case it has come up > before. > > I saw some of the css properties are from our application and some from > e(fx)clipse which I can raise to Tom Schindl separately if it is a > stylesheet issue, however it would appear that for example -fx-alignment in > a layout VBOX/HBOX component should be valid according to JavaFX docs. > > More generally, is it expected that a property such as -fx-alignment should > fall into this else {} catch all case, and why does JavaFX try to parse a > Color by default? > > -fx-alignment: center; > > Any input much appreciated. > > Regards, > Matt From matthew.james.elliot at gmail.com Wed Apr 4 14:44:04 2018 From: matthew.james.elliot at gmail.com (Matthew Elliot) Date: Wed, 4 Apr 2018 16:44:04 +0200 Subject: CSSParser Color.parse() for unexpected CSS properties In-Reply-To: References: Message-ID: Hi David, thanks for the quick response, the parser does seem to have knowledge of the property and values as in the method ... ParsedValueImpl valueFor(String property, Term root, CSSLexer lexer) throws ParseException {} it looks for particular properties for parsing... e.g. } else if ("-fx-background-color".equals(prop)) { return parsePaintLayers(root); } else if ("-fx-background-image".equals(prop)) { return parseURILayers(root); } else if ("-fx-background-insets".equals(prop)) { return parseInsetsLayers(root); ... but fx-alignment and fx-shape for example aren't listed here and fall into this strange catch all place I noted in my previous email. My follow up questions would be: 1. Why does it hit this for standard css properties as defined for JavaFX components(fx-alignment, fx-shape, etc) I.e. https://docs.oracle.com/javafx/2/api/javafx/scene/doc-files/cssref.html (hbox, vbox have -fx-alignment) 2. Even if it is wanted to be extensible, isn't by default attempting to parse a color where the property is not known and therefore triggering exception throw / catch on the thread critical to UI perf a less than optimal solution? Could it be changed to handle this more gracefully than catch / ignore exceptions? Is it worth raising a ticket for such a topic, would it ever be considered for improvement. Thanks again, Matt On 4 April 2018 at 16:20, David Grieve wrote: > The parser doesn't have any concept of what the property is or value it > might have. This allows the addition of new properties (such as an user > might add for their own CSS styles) without having to modify the parser to > handle them. > > > > On 4/4/18 10:03 AM, Matthew Elliot wrote: > >> Hi all, (first post). >> >> I was profiling our PROD JavaFX application recently I discovered >> something >> rather peculiar in the CSSParser. (jdk1.8.0_151) >> >> I noticed several hundred IllegalArgumentExceptions on the >> JavaApplicationThread where for various unrelated css properties the >> CSSParser is trying to parse a color. While the exception is subsequently >> caught and swallowed silently doing this hundred of times on this thread >> is >> rather ugly and caused *minor* delays in the application thread. >> >> This happened for alignment, shape, and a few other properties where >> no-lookup case was found and it ended on approx. line 900 of the CSSParser >> in >> >> colorValueOfString() >> >> with a value like 'center'; clearly no color. >> >> // if the property value is another property, then it needs to be looked >> up. >> boolean needsLookup = isIdent && properties.containsKey(text); >> if (needsLookup || ((value = colorValueOfString(str)) == null )) { >> // If the value is a lookup, make sure to use the lower-case text >> so it matches the property >> // in the Declaration. If the value is not a lookup, then use str >> since the value might >> // be a string which could have some case sensitive meaning >> // >> // TODO: isIdent is needed here because of RT-38345. This >> effectively undoes RT-38201 >> value = new ParsedValueImpl(needsLookup ? text : >> str, null, isIdent || needsLookup); >> } >> >> I had a look in the bug tracker https://bugs.openjdk.java.net/ but didn't >> find much in this regard so thought I would post in case it has come up >> before. >> >> I saw some of the css properties are from our application and some from >> e(fx)clipse which I can raise to Tom Schindl separately if it is a >> stylesheet issue, however it would appear that for example -fx-alignment >> in >> a layout VBOX/HBOX component should be valid according to JavaFX docs. >> >> More generally, is it expected that a property such as -fx-alignment >> should >> fall into this else {} catch all case, and why does JavaFX try to parse a >> Color by default? >> >> -fx-alignment: center; >> >> Any input much appreciated. >> >> Regards, >> Matt >> > > From david.grieve at oracle.com Wed Apr 4 15:21:11 2018 From: david.grieve at oracle.com (David Grieve) Date: Wed, 4 Apr 2018 11:21:11 -0400 Subject: CSSParser Color.parse() for unexpected CSS properties In-Reply-To: References: Message-ID: <4623a4ad-13f6-ca90-4aab-daa91eb79406@oracle.com> On 4/4/18 10:44 AM, Matthew Elliot wrote: > Hi David, thanks for the quick response, the parser does seem to have > knowledge of the property and values as in the method ... > ParsedValueImpl valueFor(String property, Term root, CSSLexer lexer)throws ParseException {} > it looks for particular properties for parsing... e.g. > } else if ("-fx-background-color".equals(prop)) { > return parsePaintLayers(root); > }else if ("-fx-background-image".equals(prop)) { > return parseURILayers(root); > }else if ("-fx-background-insets".equals(prop)) { > return parseInsetsLayers(root); > ... but fx-alignment and fx-shape for example aren't listed here and > fall into this strange catch all place I noted in my previous email. > > My follow up questions would be: > > 1. Why does it hit this for standard css properties as defined for > JavaFX components(fx-alignment, fx-shape, etc) I.e. > https://docs.oracle.com/javafx/2/api/javafx/scene/doc-files/cssref.html > (hbox, vbox have -fx-alignment) > 2. Even if it is wanted to be extensible, isn't by default attempting > to parse a color where the property is not known and therefore > triggering exception throw / catch on the thread critical to UI perf a > less than optimal solution? Could it be changed to handle this more > gracefully than catch / ignore exceptions? > > Is it worth raising a ticket for such a topic, would it ever be > considered for improvement. I think it is worth raising a ticket. > > Thanks again, > Matt > > > On 4 April 2018 at 16:20, David Grieve > wrote: > > The parser doesn't have any concept of what the property is or > value it might have. This allows the addition of new properties > (such as an user might add for their own CSS styles) without > having to modify the parser to handle them. > > > > On 4/4/18 10:03 AM, Matthew Elliot wrote: > > Hi all, (first post). > > I was profiling our PROD JavaFX application recently I > discovered something > rather peculiar in the CSSParser. (jdk1.8.0_151) > > I noticed several hundred IllegalArgumentExceptions on the > JavaApplicationThread where for various unrelated css > properties the > CSSParser is trying to parse a color. While the exception is > subsequently > caught and swallowed silently doing this hundred of times on > this thread is > rather ugly and caused *minor* delays in the application thread. > > This happened for alignment, shape, and a few other properties > where > no-lookup case was found and it ended on approx. line 900 of > the CSSParser > in > > colorValueOfString() > > with a value like 'center'; clearly no color. > > // if the property value is another property, then it needs to > be looked up. > boolean needsLookup = isIdent && properties.containsKey(text); > if (needsLookup || ((value = colorValueOfString(str)) == null )) { > ? ? ?// If the value is a lookup, make sure to use the > lower-case text > so it matches the property > ? ? ?// in the Declaration. If the value is not a lookup, then > use str > since the value might > ? ? ?// be a string which could have some case sensitive meaning > ? ? ?// > ? ? ?// TODO: isIdent is needed here because of RT-38345. This > effectively undoes RT-38201 > ? ? ?value = new ParsedValueImpl(needsLookup ? > text : > str, null, isIdent || needsLookup); > } > > I had a look in the bug tracker https://bugs.openjdk.java.net/ > but didn't > find much in this regard so thought I would post in case it > has come up > before. > > I saw some of the css properties are from our application and > some from > e(fx)clipse which I can raise to Tom Schindl separately if it is a > stylesheet issue, however it would appear that for example > -fx-alignment in > a layout VBOX/HBOX component should be valid according to > JavaFX docs. > > More generally, is it expected that a property such as > -fx-alignment should > fall into this else {} catch all case, and why does JavaFX try > to parse a > Color by default? > > -fx-alignment: center; > > Any input much appreciated. > > Regards, > Matt > > > From matthew.james.elliot at gmail.com Wed Apr 4 15:50:37 2018 From: matthew.james.elliot at gmail.com (Matthew Elliot) Date: Wed, 4 Apr 2018 17:50:37 +0200 Subject: CSSParser Color.parse() for unexpected CSS properties In-Reply-To: <4623a4ad-13f6-ca90-4aab-daa91eb79406@oracle.com> References: <4623a4ad-13f6-ca90-4aab-daa91eb79406@oracle.com> Message-ID: Hey David, thanks. I have filed a bug via the Oracle website. internal review ID : 9053225 Hopefully this was correct as it was also my first time. Matt On 4 April 2018 at 17:21, David Grieve wrote: > On 4/4/18 10:44 AM, Matthew Elliot wrote: > > Hi David, thanks for the quick response, the parser does seem to have > knowledge of the property and values as in the method ... > > ParsedValueImpl valueFor(String property, Term root, CSSLexer lexer) throws ParseException {} > > it looks for particular properties for parsing... e.g. > > } else if ("-fx-background-color".equals(prop)) { > return parsePaintLayers(root); > } else if ("-fx-background-image".equals(prop)) { > return parseURILayers(root); > } else if ("-fx-background-insets".equals(prop)) { > return parseInsetsLayers(root); > > ... but fx-alignment and fx-shape for example aren't listed here and fall > into this strange catch all place I noted in my previous email. > > My follow up questions would be: > > 1. Why does it hit this for standard css properties as defined for JavaFX > components(fx-alignment, fx-shape, etc) I.e. https://docs.oracle.com/ > javafx/2/api/javafx/scene/doc-files/cssref.html (hbox, vbox have > -fx-alignment) > 2. Even if it is wanted to be extensible, isn't by default attempting to > parse a color where the property is not known and therefore triggering > exception throw / catch on the thread critical to UI perf a less than > optimal solution? Could it be changed to handle this more gracefully than > catch / ignore exceptions? > > Is it worth raising a ticket for such a topic, would it ever be considered > for improvement. > > I think it is worth raising a ticket. > > > Thanks again, > Matt > > > On 4 April 2018 at 16:20, David Grieve wrote: > >> The parser doesn't have any concept of what the property is or value it >> might have. This allows the addition of new properties (such as an user >> might add for their own CSS styles) without having to modify the parser to >> handle them. >> >> >> >> On 4/4/18 10:03 AM, Matthew Elliot wrote: >> >>> Hi all, (first post). >>> >>> I was profiling our PROD JavaFX application recently I discovered >>> something >>> rather peculiar in the CSSParser. (jdk1.8.0_151) >>> >>> I noticed several hundred IllegalArgumentExceptions on the >>> JavaApplicationThread where for various unrelated css properties the >>> CSSParser is trying to parse a color. While the exception is subsequently >>> caught and swallowed silently doing this hundred of times on this thread >>> is >>> rather ugly and caused *minor* delays in the application thread. >>> >>> This happened for alignment, shape, and a few other properties where >>> no-lookup case was found and it ended on approx. line 900 of the >>> CSSParser >>> in >>> >>> colorValueOfString() >>> >>> with a value like 'center'; clearly no color. >>> >>> // if the property value is another property, then it needs to be looked >>> up. >>> boolean needsLookup = isIdent && properties.containsKey(text); >>> if (needsLookup || ((value = colorValueOfString(str)) == null )) { >>> // If the value is a lookup, make sure to use the lower-case text >>> so it matches the property >>> // in the Declaration. If the value is not a lookup, then use str >>> since the value might >>> // be a string which could have some case sensitive meaning >>> // >>> // TODO: isIdent is needed here because of RT-38345. This >>> effectively undoes RT-38201 >>> value = new ParsedValueImpl(needsLookup ? text : >>> str, null, isIdent || needsLookup); >>> } >>> >>> I had a look in the bug tracker https://bugs.openjdk.java.net/ but >>> didn't >>> find much in this regard so thought I would post in case it has come up >>> before. >>> >>> I saw some of the css properties are from our application and some from >>> e(fx)clipse which I can raise to Tom Schindl separately if it is a >>> stylesheet issue, however it would appear that for example -fx-alignment >>> in >>> a layout VBOX/HBOX component should be valid according to JavaFX docs. >>> >>> More generally, is it expected that a property such as -fx-alignment >>> should >>> fall into this else {} catch all case, and why does JavaFX try to parse a >>> Color by default? >>> >>> -fx-alignment: center; >>> >>> Any input much appreciated. >>> >>> Regards, >>> Matt >>> >> >> > > From kevin.rushforth at oracle.com Wed Apr 4 16:06:45 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 04 Apr 2018 09:06:45 -0700 Subject: CSSParser Color.parse() for unexpected CSS properties In-Reply-To: References: <4623a4ad-13f6-ca90-4aab-daa91eb79406@oracle.com> Message-ID: <5AC4F815.5020903@oracle.com> Hi Matt, Thank you for filing this bug. Can you provide a standalone test case that reproduces this (a .java and a .css file), so we can attach it to the bug? Our WebBugs triage engineer will ask for this, and it will save time if you can provide it now. Otherwise the bug report looks fine. -- Kevin Matthew Elliot wrote: > Hey David, thanks. > I have filed a bug via the Oracle website. > > internal review ID : 9053225 > > Hopefully this was correct as it was also my first time. > Matt > > > On 4 April 2018 at 17:21, David Grieve wrote: > > >> On 4/4/18 10:44 AM, Matthew Elliot wrote: >> >> Hi David, thanks for the quick response, the parser does seem to have >> knowledge of the property and values as in the method ... >> >> ParsedValueImpl valueFor(String property, Term root, CSSLexer lexer) throws ParseException {} >> >> it looks for particular properties for parsing... e.g. >> >> } else if ("-fx-background-color".equals(prop)) { >> return parsePaintLayers(root); >> } else if ("-fx-background-image".equals(prop)) { >> return parseURILayers(root); >> } else if ("-fx-background-insets".equals(prop)) { >> return parseInsetsLayers(root); >> >> ... but fx-alignment and fx-shape for example aren't listed here and fall >> into this strange catch all place I noted in my previous email. >> >> My follow up questions would be: >> >> 1. Why does it hit this for standard css properties as defined for JavaFX >> components(fx-alignment, fx-shape, etc) I.e. https://docs.oracle.com/ >> javafx/2/api/javafx/scene/doc-files/cssref.html (hbox, vbox have >> -fx-alignment) >> 2. Even if it is wanted to be extensible, isn't by default attempting to >> parse a color where the property is not known and therefore triggering >> exception throw / catch on the thread critical to UI perf a less than >> optimal solution? Could it be changed to handle this more gracefully than >> catch / ignore exceptions? >> >> Is it worth raising a ticket for such a topic, would it ever be considered >> for improvement. >> >> I think it is worth raising a ticket. >> >> >> Thanks again, >> Matt >> >> >> On 4 April 2018 at 16:20, David Grieve wrote: >> >> >>> The parser doesn't have any concept of what the property is or value it >>> might have. This allows the addition of new properties (such as an user >>> might add for their own CSS styles) without having to modify the parser to >>> handle them. >>> >>> >>> >>> On 4/4/18 10:03 AM, Matthew Elliot wrote: >>> >>> >>>> Hi all, (first post). >>>> >>>> I was profiling our PROD JavaFX application recently I discovered >>>> something >>>> rather peculiar in the CSSParser. (jdk1.8.0_151) >>>> >>>> I noticed several hundred IllegalArgumentExceptions on the >>>> JavaApplicationThread where for various unrelated css properties the >>>> CSSParser is trying to parse a color. While the exception is subsequently >>>> caught and swallowed silently doing this hundred of times on this thread >>>> is >>>> rather ugly and caused *minor* delays in the application thread. >>>> >>>> This happened for alignment, shape, and a few other properties where >>>> no-lookup case was found and it ended on approx. line 900 of the >>>> CSSParser >>>> in >>>> >>>> colorValueOfString() >>>> >>>> with a value like 'center'; clearly no color. >>>> >>>> // if the property value is another property, then it needs to be looked >>>> up. >>>> boolean needsLookup = isIdent && properties.containsKey(text); >>>> if (needsLookup || ((value = colorValueOfString(str)) == null )) { >>>> // If the value is a lookup, make sure to use the lower-case text >>>> so it matches the property >>>> // in the Declaration. If the value is not a lookup, then use str >>>> since the value might >>>> // be a string which could have some case sensitive meaning >>>> // >>>> // TODO: isIdent is needed here because of RT-38345. This >>>> effectively undoes RT-38201 >>>> value = new ParsedValueImpl(needsLookup ? text : >>>> str, null, isIdent || needsLookup); >>>> } >>>> >>>> I had a look in the bug tracker https://bugs.openjdk.java.net/ but >>>> didn't >>>> find much in this regard so thought I would post in case it has come up >>>> before. >>>> >>>> I saw some of the css properties are from our application and some from >>>> e(fx)clipse which I can raise to Tom Schindl separately if it is a >>>> stylesheet issue, however it would appear that for example -fx-alignment >>>> in >>>> a layout VBOX/HBOX component should be valid according to JavaFX docs. >>>> >>>> More generally, is it expected that a property such as -fx-alignment >>>> should >>>> fall into this else {} catch all case, and why does JavaFX try to parse a >>>> Color by default? >>>> >>>> -fx-alignment: center; >>>> >>>> Any input much appreciated. >>>> >>>> Regards, >>>> Matt >>>> >>>> >>> >> From nlisker at gmail.com Wed Apr 4 17:08:10 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 04 Apr 2018 17:08:10 +0000 Subject: OpenJFX GitHub mirror In-Reply-To: References: <5ABC43E6.10504@oracle.com> <055d45e1-1c38-6f82-2d9e-8f62a10d77d4@bestsolution.at> <5AC4CFC4.7080301@oracle.com> Message-ID: github-bug is fine by me. What about external links, name them or leave them as URLs? On Wed, Apr 4, 2018, 16:43 Johan Vos wrote: > +1 > > On Wed, Apr 4, 2018 at 3:30 PM Kevin Rushforth > wrote: > >> Any further comments on this? If not, then I propose we start using the >> JBS label: >> >> github-bug >> >> To identify JBS issues that are linked to guthub issues and/or PRs >> >> -- Kevin >> >> >> Nir Lisker wrote: >> > I think that the labels should be succinct, so one label should suffice. >> > Either github-link or github-bug are fine for me, the latter because >> there >> > is webbug label already. If a PR needs review just use the >> review-request >> > existing label. >> > >> > As for issues and PRs, the issue links section in the JIRA ticket could >> > reflect what exists in GitHub, so there can be 2 web links named "GitHub >> > issue" and "GitHub PR" if need be. >> > >> > - Nir >> > >> > On Thu, Mar 29, 2018 at 10:08 AM, Tom Schindl < >> tom.schindl at bestsolution.at> >> > wrote: >> > >> > >> >> well could we have 2: >> >> * github-issue >> >> * github-pr >> >> >> >> The first one indicates someone is working on it over at github, >> whereas >> >> the second means there's a PR that needs to be review. >> >> >> >> Tom >> >> >> >> On 29.03.18 08:42, Laurent Bourg?s wrote: >> >> >> >>> Hi, >> >>> >> >>> As such github references point to either issue or PR, I recommend >> using >> >>> the term 'github-link'. >> >>> >> >>> Laurent >> >>> >> >>> Le jeu. 29 mars 2018 ? 03:40, Kevin Rushforth < >> >>> >> >> kevin.rushforth at oracle.com> >> >> >> >>> a ?crit : >> >>> >> >>> >> >>>> I think this would be fine. We would want something that didn't >> conflict >> >>>> with anything else and wasn't confusing. Possible choices: >> >>>> >> >>>> github-link >> >>>> github-bug >> >>>> gitbug-issue >> >>>> >> >>>> Any preferences? >> >>>> >> >>>> -- Kevin >> >>>> >> >>>> >> >>>> Nir Lisker wrote: >> >>>> >> >>>>> Kevin, can we get a label for this? >> >>>>> >> >>>>> - Nir >> >>>>> >> >>>>> On Mon, Mar 26, 2018 at 4:37 PM, Johan Vos >> >>>>> >> >>>> wrote: >> >>>> >> >>>>> >> >>>>>> Hi Nir, >> >>>>>> >> >>>>>> About 4. (jfx-dev): you're right, I just removed that repository. >> That >> >>>>>> >> >>>> was >> >>>> >> >>>>>> just some testing before we did the real thing. >> >>>>>> >> >>>>>> As for the other points: I agree >> >>>>>> >> >>>>>> - Johan >> >>>>>> >> >>>>>> On Mon, Mar 26, 2018 at 12:03 PM Nir Lisker >> >>>>>> >> >> wrote: >> >> >> >>>>>> >> >>>>>>> Hi All, >> >>>>>>> >> >>>>>>> A few comments about the mirror and JBS: >> >>>>>>> >> >>>>>>> 1. In PRs and issues on GitHub, I strongly suggest that the link >> to >> >>>>>>> >> >>>> JBS be >> >>>> >> >>>>>>> included in the top comment. If the JBS issue was created after a >> >>>>>>> discussion, edit it in. >> >>>>>>> >> >>>>>>> 2. In JBS, I suggest to link to the GitHub mirror via More > Link >> > >> >>>>>>> >> >> Web >> >> >> >>>>>>> Link and in the Link Text use something like "GitHub mirror" (open >> >>>>>>> >> >> for >> >> >> >>>>>>> suggestions). JIRA renders the link in an easy to see way (easier >> >>>>>>> >> >> than >> >> >> >>>>>>> looking at URLs). Iv'e tried it in a couple of issues, e.g., >> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8198795 and it seems >> >>>>>>> >> >>>> preferable >> >>>> >> >>>>>>> to >> >>>>>>> me. >> >>>>>>> >> >>>>>>> 3. In JBS, I suggest a new label will be used for issues which are >> >>>>>>> >> >>>> linked >> >>>> >> >>>>>>> to GitHub for search purposes. This is similar to the webbug >> label. >> >>>>>>> >> >>>>>>> If these are agreeable, please add them to the contribution >> >>>>>>> >> >>>> instructions. >> >>>> >> >>>>>>> 4. What is https://github.com/javafxports/jfx-dev? Newcomers can >> >>>>>>> >> >>>> confuse >> >>>> >> >>>>>>> it >> >>>>>>> with javafxports/openjdk-jfx. >> >>>>>>> >> >>>>>>> 5. When the mirror is fully ready and operational, we should >> >>>>>>> >> >> advertise >> >> >> >>>> on >> >>>> >> >>>>>>> community pages (like Reddit) to gather up contributors. Please >> keep >> >>>>>>> >> >> a >> >> >> >>>>>>> mental reminder when the time comes. >> >>>>>>> >> >>>>>>> Thanks to all who are working on this. >> >>>>>>> >> >>>>>>> - Nir >> >>>>>>> >> >>>>>>> >> >>>>>>> >> > From kevin.rushforth at oracle.com Wed Apr 4 17:10:33 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 04 Apr 2018 10:10:33 -0700 Subject: OpenJFX GitHub mirror In-Reply-To: References: <5ABC43E6.10504@oracle.com> <055d45e1-1c38-6f82-2d9e-8f62a10d77d4@bestsolution.at> <5AC4CFC4.7080301@oracle.com> Message-ID: <5AC50709.6080006@oracle.com> I don't have a strong preference. The URL contains either "issue" or "pull" already, so there should be no confusion if we just use the URL. -- Kevin Nir Lisker wrote: > github-bug is fine by me. What about external links, name them or > leave them as URLs? > > On Wed, Apr 4, 2018, 16:43 Johan Vos > wrote: > > +1 > > On Wed, Apr 4, 2018 at 3:30 PM Kevin Rushforth > > > wrote: > > Any further comments on this? If not, then I propose we start > using the > JBS label: > > github-bug > > To identify JBS issues that are linked to guthub issues and/or PRs > > -- Kevin > > > Nir Lisker wrote: > > I think that the labels should be succinct, so one label > should suffice. > > Either github-link or github-bug are fine for me, the latter > because there > > is webbug label already. If a PR needs review just use the > review-request > > existing label. > > > > As for issues and PRs, the issue links section in the JIRA > ticket could > > reflect what exists in GitHub, so there can be 2 web links > named "GitHub > > issue" and "GitHub PR" if need be. > > > > - Nir > > > > On Thu, Mar 29, 2018 at 10:08 AM, Tom Schindl > > > > wrote: > > > > > >> well could we have 2: > >> * github-issue > >> * github-pr > >> > >> The first one indicates someone is working on it over at > github, whereas > >> the second means there's a PR that needs to be review. > >> > >> Tom > >> > >> On 29.03.18 08:42, Laurent Bourg?s wrote: > >> > >>> Hi, > >>> > >>> As such github references point to either issue or PR, I > recommend using > >>> the term 'github-link'. > >>> > >>> Laurent > >>> > >>> Le jeu. 29 mars 2018 ? 03:40, Kevin Rushforth < > >>> > >> kevin.rushforth at oracle.com > > >> > >>> a ?crit : > >>> > >>> > >>>> I think this would be fine. We would want something that > didn't conflict > >>>> with anything else and wasn't confusing. Possible choices: > >>>> > >>>> github-link > >>>> github-bug > >>>> gitbug-issue > >>>> > >>>> Any preferences? > >>>> > >>>> -- Kevin > >>>> > >>>> > >>>> Nir Lisker wrote: > >>>> > >>>>> Kevin, can we get a label for this? > >>>>> > >>>>> - Nir > >>>>> > >>>>> On Mon, Mar 26, 2018 at 4:37 PM, Johan Vos > > > >>>>> > >>>> wrote: > >>>> > >>>>> > >>>>>> Hi Nir, > >>>>>> > >>>>>> About 4. (jfx-dev): you're right, I just removed that > repository. That > >>>>>> > >>>> was > >>>> > >>>>>> just some testing before we did the real thing. > >>>>>> > >>>>>> As for the other points: I agree > >>>>>> > >>>>>> - Johan > >>>>>> > >>>>>> On Mon, Mar 26, 2018 at 12:03 PM Nir Lisker > > > >>>>>> > >> wrote: > >> > >>>>>> > >>>>>>> Hi All, > >>>>>>> > >>>>>>> A few comments about the mirror and JBS: > >>>>>>> > >>>>>>> 1. In PRs and issues on GitHub, I strongly suggest > that the link to > >>>>>>> > >>>> JBS be > >>>> > >>>>>>> included in the top comment. If the JBS issue was > created after a > >>>>>>> discussion, edit it in. > >>>>>>> > >>>>>>> 2. In JBS, I suggest to link to the GitHub mirror via > More > Link > > >>>>>>> > >> Web > >> > >>>>>>> Link and in the Link Text use something like "GitHub > mirror" (open > >>>>>>> > >> for > >> > >>>>>>> suggestions). JIRA renders the link in an easy to see > way (easier > >>>>>>> > >> than > >> > >>>>>>> looking at URLs). Iv'e tried it in a couple of issues, > e.g., > >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8198795 and > it seems > >>>>>>> > >>>> preferable > >>>> > >>>>>>> to > >>>>>>> me. > >>>>>>> > >>>>>>> 3. In JBS, I suggest a new label will be used for > issues which are > >>>>>>> > >>>> linked > >>>> > >>>>>>> to GitHub for search purposes. This is similar to the > webbug label. > >>>>>>> > >>>>>>> If these are agreeable, please add them to the > contribution > >>>>>>> > >>>> instructions. > >>>> > >>>>>>> 4. What is https://github.com/javafxports/jfx-dev? > Newcomers can > >>>>>>> > >>>> confuse > >>>> > >>>>>>> it > >>>>>>> with javafxports/openjdk-jfx. > >>>>>>> > >>>>>>> 5. When the mirror is fully ready and operational, we > should > >>>>>>> > >> advertise > >> > >>>> on > >>>> > >>>>>>> community pages (like Reddit) to gather up > contributors. Please keep > >>>>>>> > >> a > >> > >>>>>>> mental reminder when the time comes. > >>>>>>> > >>>>>>> Thanks to all who are working on this. > >>>>>>> > >>>>>>> - Nir > >>>>>>> > >>>>>>> > >>>>>>> > From pedro.duquevieira at gmail.com Wed Apr 4 23:19:34 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 5 Apr 2018 00:19:34 +0100 Subject: Add missing styleable properties to ImageView? Message-ID: I'd say position, size, color, etc are all part of the design and CSS is about design so this type of properties should be accessible via CSS. I don't see why JavaFX should be any different from the web CSS, in this respect. There's something I'd like to bring to your attention, we already have "-fx-pref-width", "-fx-max-width", "-fx-min-width" and the corresponding height CSS properties coming from Region, should we re-use them? I think it will be better if we have a standard way to change a Node's size rather than properties with different names for different Nodes that do the same thing. Also having "-fx-pref-width" and also "-fit-width" might be kind of strange, specially if the former doesn't do anything. Main point is, I think we should have a standard API (same CSS properties) for every node if these properties have the same meaning. Kind regards, -- Pedro Duque Vieira From nlisker at gmail.com Thu Apr 5 01:33:15 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 5 Apr 2018 04:33:15 +0300 Subject: gradle :web:test fails Message-ID: I'm running :web:test in revision 10889 and getting the following failing test: test.javafx.scene.web.MiscellaneousTest > testUserAgentString FAILED java.lang.AssertionError: UserAgentString does not contain JavaFX/11 at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at test.javafx.scene.web.MiscellaneousTest.lambda$testUserAgentString$12(MiscellaneousTest.java:441) 379 tests completed, 1 failed, 12 skipped :web:test FAILED Is this known? - Nir From nlisker at gmail.com Thu Apr 5 02:43:04 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 5 Apr 2018 05:43:04 +0300 Subject: JDK-8199560: Dynamic evaluation for binding.When In-Reply-To: <5ABC4333.3010700@oracle.com> References: <5AAC47A9.20004@oracle.com> <5ABC4333.3010700@oracle.com> Message-ID: I don't see any opinions, so should I investigate option 2? - Nir On Thu, Mar 29, 2018 at 4:36 AM, Kevin Rushforth wrote: > Breaking existing apps is the one thing I worried about with the > suggestion of doing it without API changes. So to summarize I think there > are three possiblities: > > 1. Just make the current API lazy for observables with no resource for the > developer. This seems unwise for the reasons you point out. > > 2. Keep the existing API, but add new When(ObservableXxxxx condition, > boolean lazyEval) constructors (we can discuss whether the default should > be eager to preserve compatibility for apps that rely on the side effect of > eager evaluation or lazy to match what many developers might expect). > > 3. Something else. > > Unless there is a problem implementing #2 (ignoring the default for now), > that might be the way to go. It would be good to get some opinions about > this from other developers. > > -- Kevin > > > Nir Lisker wrote: > > Iv'e given the idea of using existing API some thought. > > When using primitives, the evaluation is always eager. A method that > returns a boolean (for example) will always be evaluated before it is > passed to When, regardless of the condition value. This precludes the > possibility of lazy evaluation in the scenario I've shown in the issue. > > When using observables, it's probably possible to do this. The > observable's value is computed (that is, computeValue() is called) during > the call to otherwise(...), specifically, when the invalidation listener > WhenListener is registered on the observable. I think it's possible to > register and deregister the listener depending on the condition's value. > Using this approach, a developer can wrap a method call in an observable, > as done in Bindings.createXxxBinding(Callable...). This is a bit of extra > work for the developer, having to create a binding. It'll also break > current behavior unless we do something like adding a constructor > When(ObservableBooleanValue condition, boolean lazyEval) and default the > current one to lazyEval=false. We could also use the "we told you so" line > for developers who rely on the current undocumented behavior. > > - Nir > > On Sat, Mar 17, 2018 at 1:39 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Conceptually what you describe sounds like a good approach to explore. >> >> Another approach worth exploring is to see whether this can be done >> without API change, using the existing API. I took a (very quick) look and >> didn't see anything that would preclude fixing this using the existing API, >> nor does the specification (javadoc-generated API docs) mandate the current >> behavior of eagerly evaluating both the "then" and "otherwise" conditions. >> Since it was only a quick look, I can't be sure. >> >> -- Kevin >> >> >> Nir Lisker wrote: >> >>> Hello, >>> >>> I've proposed to work on a public API for binding.When that adds >>> capabilities for dynamic evaluation of the 'then' and 'otherwise' >>> arguments. Any comments? >>> >>> https://bugs.openjdk.java.net/browse/JDK-8199560 >>> >>> - Nir >>> >>> >> > From murali.billa at oracle.com Thu Apr 5 04:49:05 2018 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 4 Apr 2018 21:49:05 -0700 (PDT) Subject: gradle :web:test fails In-Reply-To: References: Message-ID: Hi Lisker, Can you print the value of useragentString ? Looks like you are using fxversion as 11 (you can print this value from System.getProperty("javafx.runtime.version");) but the useragentstring does not contain 11. final WebView webView = new WebView(); final WebEngine webEngine = webView.getEngine(); System.out.println(webEngine.getUserAgent()); Thanks, Murali -----Original Message----- From: Nir Lisker Sent: Thursday, April 05, 2018 7:03 AM To: openjfx-dev at openjdk.java.net Mailing Subject: gradle :web:test fails I'm running :web:test in revision 10889 and getting the following failing test: test.javafx.scene.web.MiscellaneousTest > testUserAgentString FAILED java.lang.AssertionError: UserAgentString does not contain JavaFX/11 at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at test.javafx.scene.web.MiscellaneousTest.lambda$testUserAgentString$12(MiscellaneousTest.java:441) 379 tests completed, 1 failed, 12 skipped :web:test FAILED Is this known? - Nir From ambarish.rapte at oracle.com Thu Apr 5 06:11:24 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Wed, 4 Apr 2018 23:11:24 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <740FDD88-E570-4141-9FC1-529B0272CDF2@oracle.com> References: <5ABD1766.8020204@oracle.com> <740FDD88-E570-4141-9FC1-529B0272CDF2@oracle.com> Message-ID: Vote: Yes -----Original Message----- From: Guru Sent: Tuesday, April 03, 2018 2:12 PM To: Kevin Rushforth Cc: openjfx-dev at openjdk.java.net Subject: Re: CFV: New OpenJFX Committer: Rajath Kamath Vote: YES > On 29-Mar-2018, at 10:12 PM, Kevin Rushforth wrote: > > I hereby nominate Rajath Kamath [1] to OpenJFX Committer. > > Rajath is a member of JavaFX team at Oracle, who has contributed 17 changesets [2][3] to OpenJFX. > > Votes are due by April 12, 2018. > > Only current OpenJFX Committers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. Nomination to a project Committer is described in [6]. > > By way of background, an earlier nomination failed [7]. Since then, Rajath has contributed 2 more test fixes and 1 more product fix. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#rkamath > > [2] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=auth > or%28rkamath%29 [3] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20&rev=raja > th.kamath > > [4] http://openjdk.java.net/census#openjfx > > [5] http://openjdk.java.net/bylaws#lazy-consensus > > [6] http://openjdk.java.net/projects#project-committer > > [7] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/02149 > 9.html > From murali.billa at oracle.com Thu Apr 5 06:57:17 2018 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 4 Apr 2018 23:57:17 -0700 (PDT) Subject: gradle :web:test fails In-Reply-To: References: Message-ID: <466f0e61-1398-4017-9e9f-171b0a87cf65@default> Hi Lisker, +one more point: I think you are not compiling webkit . The command "gradle :web:test" picks the webkit dll from JDK (which can have older versions like 10 / 9) . You can compile webkit with command " gradle -PCOMPILE_WEBKIT=true :web:test" and in this case webkit dll will be picked up from your source code repo (not from JDK). Thanks, Murali -----Original Message----- From: Murali Billa Sent: Thursday, April 05, 2018 10:19 AM To: Nir Lisker ; openjfx-dev at openjdk.java.net Mailing Subject: RE: gradle :web:test fails Hi Lisker, Can you print the value of useragentString ? Looks like you are using fxversion as 11 (you can print this value from System.getProperty("javafx.runtime.version");) but the useragentstring does not contain 11. final WebView webView = new WebView(); final WebEngine webEngine = webView.getEngine(); System.out.println(webEngine.getUserAgent()); Thanks, Murali -----Original Message----- From: Nir Lisker Sent: Thursday, April 05, 2018 7:03 AM To: openjfx-dev at openjdk.java.net Mailing Subject: gradle :web:test fails I'm running :web:test in revision 10889 and getting the following failing test: test.javafx.scene.web.MiscellaneousTest > testUserAgentString FAILED java.lang.AssertionError: UserAgentString does not contain JavaFX/11 at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at test.javafx.scene.web.MiscellaneousTest.lambda$testUserAgentString$12(MiscellaneousTest.java:441) 379 tests completed, 1 failed, 12 skipped :web:test FAILED Is this known? - Nir From matthew.james.elliot at gmail.com Thu Apr 5 08:02:06 2018 From: matthew.james.elliot at gmail.com (Matthew Elliot) Date: Thu, 5 Apr 2018 10:02:06 +0200 Subject: CSSParser Color.parse() for unexpected CSS properties In-Reply-To: <5AC4F815.5020903@oracle.com> References: <4623a4ad-13f6-ca90-4aab-daa91eb79406@oracle.com> <5AC4F815.5020903@oracle.com> Message-ID: Hi Kevin, Priyanka from Oracle beat me to it and this small example hit the nail on the head immediately. The below will throw and swallow and IllegalArgumentException in CSSParser in the following method. private ParsedValueImpl colorValueOfString(String str) { import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class CssParserTest extends Application { @Override public void start(Stage primaryStage) throws Exception { primaryStage.setTitle("HBox Experiment 1"); Button button1 = new Button("Button Number 1"); Button button2 = new Button("Button Number 2"); VBox vbox = new VBox(button1, button2); vbox.setStyle("-fx-alignment: top-center;"); Scene scene = new Scene(vbox, 200, 100); primaryStage.setScene(scene); primaryStage.show(); } public static void main(String[] args) { Application.launch(args); } } There are at least 3 properties I have seen doing this and depending on the complexity of the CSS, in our case quite extensive it leads to a lot of throw/catch/ignore. :) M. ? On 4 April 2018 at 18:06, Kevin Rushforth wrote: > Hi Matt, > > Thank you for filing this bug. > > Can you provide a standalone test case that reproduces this (a .java and a > .css file), so we can attach it to the bug? Our WebBugs triage engineer > will ask for this, and it will save time if you can provide it now. > Otherwise the bug report looks fine. > > -- Kevin > > > > Matthew Elliot wrote: > >> Hey David, thanks. >> I have filed a bug via the Oracle website. >> >> internal review ID : 9053225 >> >> Hopefully this was correct as it was also my first time. >> Matt >> >> >> On 4 April 2018 at 17:21, David Grieve wrote: >> >> >> >>> On 4/4/18 10:44 AM, Matthew Elliot wrote: >>> >>> Hi David, thanks for the quick response, the parser does seem to have >>> knowledge of the property and values as in the method ... >>> >>> ParsedValueImpl valueFor(String property, Term root, CSSLexer lexer) >>> throws ParseException {} >>> >>> it looks for particular properties for parsing... e.g. >>> >>> } else if ("-fx-background-color".equals(prop)) { >>> return parsePaintLayers(root); >>> } else if ("-fx-background-image".equals(prop)) { >>> return parseURILayers(root); >>> } else if ("-fx-background-insets".equals(prop)) { >>> return parseInsetsLayers(root); >>> >>> ... but fx-alignment and fx-shape for example aren't listed here and fall >>> into this strange catch all place I noted in my previous email. >>> >>> My follow up questions would be: >>> >>> 1. Why does it hit this for standard css properties as defined for JavaFX >>> components(fx-alignment, fx-shape, etc) I.e. https://docs.oracle.com/ >>> javafx/2/api/javafx/scene/doc-files/cssref.html (hbox, vbox have >>> -fx-alignment) >>> 2. Even if it is wanted to be extensible, isn't by default attempting to >>> parse a color where the property is not known and therefore triggering >>> exception throw / catch on the thread critical to UI perf a less than >>> optimal solution? Could it be changed to handle this more gracefully than >>> catch / ignore exceptions? >>> >>> Is it worth raising a ticket for such a topic, would it ever be >>> considered >>> for improvement. >>> >>> I think it is worth raising a ticket. >>> >>> >>> Thanks again, >>> Matt >>> >>> >>> On 4 April 2018 at 16:20, David Grieve wrote: >>> >>> >>> >>>> The parser doesn't have any concept of what the property is or value it >>>> might have. This allows the addition of new properties (such as an user >>>> might add for their own CSS styles) without having to modify the parser >>>> to >>>> handle them. >>>> >>>> >>>> >>>> On 4/4/18 10:03 AM, Matthew Elliot wrote: >>>> >>>> >>>> >>>>> Hi all, (first post). >>>>> >>>>> I was profiling our PROD JavaFX application recently I discovered >>>>> something >>>>> rather peculiar in the CSSParser. (jdk1.8.0_151) >>>>> >>>>> I noticed several hundred IllegalArgumentExceptions on the >>>>> JavaApplicationThread where for various unrelated css properties the >>>>> CSSParser is trying to parse a color. While the exception is >>>>> subsequently >>>>> caught and swallowed silently doing this hundred of times on this >>>>> thread >>>>> is >>>>> rather ugly and caused *minor* delays in the application thread. >>>>> >>>>> This happened for alignment, shape, and a few other properties where >>>>> no-lookup case was found and it ended on approx. line 900 of the >>>>> CSSParser >>>>> in >>>>> >>>>> colorValueOfString() >>>>> >>>>> with a value like 'center'; clearly no color. >>>>> >>>>> // if the property value is another property, then it needs to be >>>>> looked >>>>> up. >>>>> boolean needsLookup = isIdent && properties.containsKey(text); >>>>> if (needsLookup || ((value = colorValueOfString(str)) == null )) { >>>>> // If the value is a lookup, make sure to use the lower-case text >>>>> so it matches the property >>>>> // in the Declaration. If the value is not a lookup, then use str >>>>> since the value might >>>>> // be a string which could have some case sensitive meaning >>>>> // >>>>> // TODO: isIdent is needed here because of RT-38345. This >>>>> effectively undoes RT-38201 >>>>> value = new ParsedValueImpl(needsLookup ? text : >>>>> str, null, isIdent || needsLookup); >>>>> } >>>>> >>>>> I had a look in the bug tracker https://bugs.openjdk.java.net/ but >>>>> didn't >>>>> find much in this regard so thought I would post in case it has come up >>>>> before. >>>>> >>>>> I saw some of the css properties are from our application and some from >>>>> e(fx)clipse which I can raise to Tom Schindl separately if it is a >>>>> stylesheet issue, however it would appear that for example >>>>> -fx-alignment >>>>> in >>>>> a layout VBOX/HBOX component should be valid according to JavaFX docs. >>>>> >>>>> More generally, is it expected that a property such as -fx-alignment >>>>> should >>>>> fall into this else {} catch all case, and why does JavaFX try to >>>>> parse a >>>>> Color by default? >>>>> >>>>> -fx-alignment: center; >>>>> >>>>> Any input much appreciated. >>>>> >>>>> Regards, >>>>> Matt >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> From kevin.rushforth at oracle.com Thu Apr 5 11:39:55 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 Apr 2018 04:39:55 -0700 Subject: CSSParser Color.parse() for unexpected CSS properties In-Reply-To: References: <4623a4ad-13f6-ca90-4aab-daa91eb79406@oracle.com> <5AC4F815.5020903@oracle.com> Message-ID: <5AC60B0B.4040904@oracle.com> OK, thanks. For the benefit of others who might be interested, this bug is now visible here: https://bugs.openjdk.java.net/browse/JDK-8201135 -- Kevin Matthew Elliot wrote: > Hi Kevin, > > Priyanka from Oracle beat me to it and this small example hit the nail > on the head immediately. The below will throw and swallow and > IllegalArgumentException in CSSParser in the following method. > > private ParsedValueImpl colorValueOfString(String str) { > > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > > public class CssParserTest extends Application { > > > @Override > public void start(Stage primaryStage) throws Exception { > primaryStage.setTitle("HBox Experiment 1"); > > Button button1 = new Button("Button Number 1"); > Button button2 = new Button("Button Number 2"); > > VBox vbox = new VBox(button1, button2); > vbox.setStyle("-fx-alignment: top-center;"); > > Scene scene = new Scene(vbox, 200, 100); > > primaryStage.setScene(scene); > primaryStage.show(); > } > > public static void main(String[] args) { > Application.launch(args); > } > } > > There are at least 3 properties I have seen doing this and depending > on the complexity of the CSS, in our case quite extensive it leads to > a lot of throw/catch/ignore. :) > > M. > ? > > On 4 April 2018 at 18:06, Kevin Rushforth > wrote: > > Hi Matt, > > Thank you for filing this bug. > > Can you provide a standalone test case that reproduces this (a > .java and a .css file), so we can attach it to the bug? Our > WebBugs triage engineer will ask for this, and it will save time > if you can provide it now. Otherwise the bug report looks fine. > > -- Kevin > > > > Matthew Elliot wrote: > > Hey David, thanks. > I have filed a bug via the Oracle website. > > internal review ID : 9053225 > > Hopefully this was correct as it was also my first time. > Matt > > > On 4 April 2018 at 17:21, David Grieve > > wrote: > > > > On 4/4/18 10:44 AM, Matthew Elliot wrote: > > Hi David, thanks for the quick response, the parser does > seem to have > knowledge of the property and values as in the method ... > > ParsedValueImpl valueFor(String property, Term root, > CSSLexer lexer) throws ParseException {} > > it looks for particular properties for parsing... e.g. > > } else if ("-fx-background-color".equals(prop)) { > return parsePaintLayers(root); > } else if ("-fx-background-image".equals(prop)) { > return parseURILayers(root); > } else if ("-fx-background-insets".equals(prop)) { > return parseInsetsLayers(root); > > ... but fx-alignment and fx-shape for example aren't > listed here and fall > into this strange catch all place I noted in my previous > email. > > My follow up questions would be: > > 1. Why does it hit this for standard css properties as > defined for JavaFX > components(fx-alignment, fx-shape, etc) I.e. > https://docs.oracle.com/ > javafx/2/api/javafx/scene/doc-files/cssref.html (hbox, > vbox have > -fx-alignment) > 2. Even if it is wanted to be extensible, isn't by default > attempting to > parse a color where the property is not known and > therefore triggering > exception throw / catch on the thread critical to UI perf > a less than > optimal solution? Could it be changed to handle this more > gracefully than > catch / ignore exceptions? > > Is it worth raising a ticket for such a topic, would it > ever be considered > for improvement. > > I think it is worth raising a ticket. > > > Thanks again, > Matt > > > On 4 April 2018 at 16:20, David Grieve > > > wrote: > > > > The parser doesn't have any concept of what the > property is or value it > might have. This allows the addition of new properties > (such as an user > might add for their own CSS styles) without having to > modify the parser to > handle them. > > > > On 4/4/18 10:03 AM, Matthew Elliot wrote: > > > > Hi all, (first post). > > I was profiling our PROD JavaFX application > recently I discovered > something > rather peculiar in the CSSParser. (jdk1.8.0_151) > > I noticed several hundred > IllegalArgumentExceptions on the > JavaApplicationThread where for various unrelated > css properties the > CSSParser is trying to parse a color. While the > exception is subsequently > caught and swallowed silently doing this hundred > of times on this thread > is > rather ugly and caused *minor* delays in the > application thread. > > This happened for alignment, shape, and a few > other properties where > no-lookup case was found and it ended on approx. > line 900 of the > CSSParser > in > > colorValueOfString() > > with a value like 'center'; clearly no color. > > // if the property value is another property, then > it needs to be looked > up. > boolean needsLookup = isIdent && > properties.containsKey(text); > if (needsLookup || ((value = > colorValueOfString(str)) == null )) { > // If the value is a lookup, make sure to use > the lower-case text > so it matches the property > // in the Declaration. If the value is not a > lookup, then use str > since the value might > // be a string which could have some case > sensitive meaning > // > // TODO: isIdent is needed here because of > RT-38345. This > effectively undoes RT-38201 > value = new > ParsedValueImpl(needsLookup ? text : > str, null, isIdent || needsLookup); > } > > I had a look in the bug tracker > https://bugs.openjdk.java.net/ but > didn't > find much in this regard so thought I would post > in case it has come up > before. > > I saw some of the css properties are from our > application and some from > e(fx)clipse which I can raise to Tom Schindl > separately if it is a > stylesheet issue, however it would appear that for > example -fx-alignment > in > a layout VBOX/HBOX component should be valid > according to JavaFX docs. > > More generally, is it expected that a property > such as -fx-alignment > should > fall into this else {} catch all case, and why > does JavaFX try to parse a > Color by default? > > -fx-alignment: center; > > Any input much appreciated. > > Regards, > Matt > > > > > > > > From kevin.rushforth at oracle.com Thu Apr 5 12:01:13 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 Apr 2018 05:01:13 -0700 Subject: gradle :web:test fails In-Reply-To: <466f0e61-1398-4017-9e9f-171b0a87cf65@default> References: <466f0e61-1398-4017-9e9f-171b0a87cf65@default> Message-ID: <5AC61009.9080104@oracle.com> Yes, this is very likely the issue. If you take the jfxwebkit.dll from the latest EA build of JDK 11 then you should be fine. Alternatively, if you have the patience to build webkit from source (at least once) then you can use that. Johan had a good idea that gradle :web:test should produce a warning if COMPILE_WEBKIT is false [1]. I just now filed a bug [2] to track this. -- Kevin [1] https://github.com/javafxports/openjdk-jfx/issues/19#issuecomment-378521501 [2] https://bugs.openjdk.java.net/browse/JDK-8201176 Murali Billa wrote: > Hi Lisker, > > +one more point: > > I think you are not compiling webkit . The command "gradle :web:test" picks the webkit dll from JDK (which can have older versions like 10 / 9) . > > You can compile webkit with command " gradle -PCOMPILE_WEBKIT=true :web:test" and in this case webkit dll will be picked up from your source code repo (not from JDK). > > Thanks, > Murali > > -----Original Message----- > From: Murali Billa > Sent: Thursday, April 05, 2018 10:19 AM > To: Nir Lisker ; openjfx-dev at openjdk.java.net Mailing > Subject: RE: gradle :web:test fails > > Hi Lisker, > > Can you print the value of useragentString ? Looks like you are using fxversion as 11 (you can print this value from System.getProperty("javafx.runtime.version");) but the useragentstring does not contain 11. > > final WebView webView = new WebView(); > final WebEngine webEngine = webView.getEngine(); System.out.println(webEngine.getUserAgent()); > > > Thanks, > Murali > -----Original Message----- > From: Nir Lisker > Sent: Thursday, April 05, 2018 7:03 AM > To: openjfx-dev at openjdk.java.net Mailing > Subject: gradle :web:test fails > > I'm running :web:test in revision 10889 and getting the following failing > test: > > test.javafx.scene.web.MiscellaneousTest > testUserAgentString FAILED > java.lang.AssertionError: UserAgentString does not contain JavaFX/11 > at org.junit.Assert.fail(Assert.java:91) > at org.junit.Assert.assertTrue(Assert.java:43) > at > test.javafx.scene.web.MiscellaneousTest.lambda$testUserAgentString$12(MiscellaneousTest.java:441) > > 379 tests completed, 1 failed, 12 skipped :web:test FAILED > > Is this known? > > - Nir > From Mikael.Christensen at qiagen.com Thu Apr 5 12:12:32 2018 From: Mikael.Christensen at qiagen.com (Mikael Christensen - QIAGEN) Date: Thu, 5 Apr 2018 12:12:32 +0000 Subject: Will OpenJFX have a release ready in time for the Java 11 launch? Message-ID: Hi, This is a question about Oracle's statement that JavaFX will no longer be part of the SDK starting from Java 11: https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates Is the plan, that when Java 11 is released (scheduled for September 2018), it will be possible to download a (prebuilt) JavaFX component from the OpenJFX? Best, Mikael. From kevin.rushforth at oracle.com Thu Apr 5 12:21:46 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 Apr 2018 05:21:46 -0700 Subject: Will OpenJFX have a release ready in time for the Java 11 launch? In-Reply-To: References: Message-ID: <5AC614DA.1090803@oracle.com> Yes, this is the plan. There has been quite a lot of discussion on this, so I invite you to search the email archives [1]. Specifically, the recent "modules versus SDK's" thread [2]. You are welcome to join the mailing list [3] and contribute to the discussion if you like. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/ [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-March/021624.html [3] http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev Mikael Christensen - QIAGEN wrote: > Hi, > > This is a question about Oracle's statement that JavaFX will no longer be part of the SDK starting from Java 11: > https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates > > Is the plan, that when Java 11 is released (scheduled for September 2018), it will be possible to download a (prebuilt) JavaFX component from the OpenJFX? > > Best, Mikael. > > From johan.vos at gluonhq.com Thu Apr 5 12:29:54 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 05 Apr 2018 12:29:54 +0000 Subject: Will OpenJFX have a release ready in time for the Java 11 launch? In-Reply-To: References: Message-ID: Yes, that is the plan. Actually, there are 2 paths: 1. create a JavaFX SDK (see https://bugs.openjdk.java.net/browse/JDK-8198329 ) 2. create and upload the JavaFX modules to the traditional, popular repositories (maven central, bintray) and make sure developers can use the API's using maven/gradle (see https://github.com/javafxports/openjdk-jfx/issues/52) This is imo the most important work right now, and a number of people are working on it. I am very positive this [both paths] will be realised before the Java 11 release date. - Johan On Thu, Apr 5, 2018 at 2:25 PM Mikael Christensen - QIAGEN < Mikael.Christensen at qiagen.com> wrote: > Hi, > > This is a question about Oracle's statement that JavaFX will no longer be > part of the SDK starting from Java 11: > > https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates > > Is the plan, that when Java 11 is released (scheduled for September 2018), > it will be possible to download a (prebuilt) JavaFX component from the > OpenJFX? > > Best, Mikael. > > From nlisker at gmail.com Thu Apr 5 23:14:14 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 6 Apr 2018 02:14:14 +0300 Subject: gradle :web:test fails In-Reply-To: <5AC61009.9080104@oracle.com> References: <466f0e61-1398-4017-9e9f-171b0a87cf65@default> <5AC61009.9080104@oracle.com> Message-ID: Yes, I didn't build Webkit and the JDK is 10, but I thought the Webkit tests would be skipped if it weren't built. The filed bug should do it. Thanks. - Nir On Thu, Apr 5, 2018, 15:01 Kevin Rushforth wrote: > Yes, this is very likely the issue. If you take the jfxwebkit.dll from > the latest EA build of JDK 11 then you should be fine. Alternatively, if > you have the patience to build webkit from source (at least once) then > you can use that. > > Johan had a good idea that gradle :web:test should produce a warning if > COMPILE_WEBKIT is false [1]. > > I just now filed a bug [2] to track this. > > -- Kevin > > [1] > https://github.com/javafxports/openjdk-jfx/issues/19#issuecomment- > 378521501 > [2] https://bugs.openjdk.java.net/browse/JDK-8201176 > > > Murali Billa wrote: > > Hi Lisker, > > > > +one more point: > > > > I think you are not compiling webkit . The command "gradle :web:test" > picks the webkit dll from JDK (which can have older versions like 10 / 9) . > > > > You can compile webkit with command " gradle -PCOMPILE_WEBKIT=true > :web:test" and in this case webkit dll will be picked up from your source > code repo (not from JDK). > > > > Thanks, > > Murali > > > > -----Original Message----- > > From: Murali Billa > > Sent: Thursday, April 05, 2018 10:19 AM > > To: Nir Lisker ; openjfx-dev at openjdk.java.net > Mailing > > Subject: RE: gradle :web:test fails > > > > Hi Lisker, > > > > Can you print the value of useragentString ? Looks like you are using > fxversion as 11 (you can print this value from System.getProperty("javafx.runtime.version");) > but the useragentstring does not contain 11. > > > > final WebView webView = new WebView(); > > final WebEngine webEngine = webView.getEngine(); > System.out.println(webEngine.getUserAgent()); > > > > > > Thanks, > > Murali > > -----Original Message----- > > From: Nir Lisker > > Sent: Thursday, April 05, 2018 7:03 AM > > To: openjfx-dev at openjdk.java.net Mailing > > Subject: gradle :web:test fails > > > > I'm running :web:test in revision 10889 and getting the following failing > > test: > > > > test.javafx.scene.web.MiscellaneousTest > testUserAgentString FAILED > > java.lang.AssertionError: UserAgentString does not contain JavaFX/11 > > at org.junit.Assert.fail(Assert.java:91) > > at org.junit.Assert.assertTrue(Assert.java:43) > > at > > test.javafx.scene.web.MiscellaneousTest.lambda$testUserAgentString$12( > MiscellaneousTest.java:441) > > > > 379 tests completed, 1 failed, 12 skipped :web:test FAILED > > > > Is this known? > > > > - Nir > > > From kevin.rushforth at oracle.com Fri Apr 6 00:21:02 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 Apr 2018 17:21:02 -0700 Subject: HEADS-UP: Proposal to bump the minimum boot JDK for FX to JDK 10 In-Reply-To: <5ABD33C0.9@oracle.com> References: <5ABD33C0.9@oracle.com> Message-ID: <5AC6BD6E.5090302@oracle.com> I created a pull request [3] for this, and discovered that the CI builds for the GitHub sandbox are using JDK 9.0.4. Michael Ennen is fixing this by switching both the Travis and Appveyor CI builds to use JDK 10 [4]. Given the disruptive nature of bumping the minimum, I think it is wise to wait another day or two before taking any action on my proposal to bump the minimum (we can and should still proceed to upgrade the CI builds to use JDK 10). This will give others who might have concerns a chance to comment. Comments? -- Kevin [3] https://github.com/javafxports/openjdk-jfx/pull/61 [4] https://github.com/javafxports/openjdk-jfx/pull/63 Kevin Rushforth wrote: > As mentioned in another thread [1] we should update the minimum boot > JDK used to build FX to 10, which will allow the use of JDK 10 > langauge features, such as 'var', as well as JDK 10 APIs. It's also > the right time to do this in general. I filed a new RFE [2] to track > this and plan to send it out for review next week. > > Please let me know if there are any concerns. We already use JDK 10 to > build FX 11 ea bits. I presume that the travis and appveyor CI builds > of the github mirror do the same? > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-March/021671.html > > [2] https://bugs.openjdk.java.net/browse/JDK-8200446 > From nlisker at gmail.com Fri Apr 6 00:57:26 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 6 Apr 2018 03:57:26 +0300 Subject: Review Request: JDK-8200587: Fix mistakes in FX API docs Message-ID: Hi Kevin, After JDK-8200749 is committed, please review the fixes for documentation mistakes: https://bugs.openjdk.java.net/browse/JDK-8200587 http://cr.openjdk.java.net/~nlisker/8200587/webrev.00/ Thanks, Nir From paulrussell70 at gmail.com Fri Apr 6 07:28:35 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Fri, 6 Apr 2018 08:28:35 +0100 Subject: Will OpenJFX have a release ready in time for the Java 11 launch? Message-ID: +1 :) "This is imo the most important work right now, and a number of people are working on it. I am very positive this [both paths] will be realised before the Java 11 release date. " On 6 April 2018 at 01:21, wrote: > Send openjfx-dev mailing list submissions to > openjfx-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > or, via email, send a message with subject or body 'help' to > openjfx-dev-request at openjdk.java.net > > You can reach the person managing the list at > openjfx-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openjfx-dev digest..." > > > Today's Topics: > > 1. Re: gradle :web:test fails (Kevin Rushforth) > 2. Will OpenJFX have a release ready in time for the Java 11 > launch? (Mikael Christensen - QIAGEN) > 3. Re: Will OpenJFX have a release ready in time for the Java 11 > launch? (Kevin Rushforth) > 4. Re: Will OpenJFX have a release ready in time for the Java 11 > launch? (Johan Vos) > 5. Re: gradle :web:test fails (Nir Lisker) > 6. Re: HEADS-UP: Proposal to bump the minimum boot JDK for FX to > JDK 10 (Kevin Rushforth) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 05 Apr 2018 05:01:13 -0700 > From: Kevin Rushforth > To: Murali Billa > Cc: "openjfx-dev at openjdk.java.net Mailing" > > Subject: Re: gradle :web:test fails > Message-ID: <5AC61009.9080104 at oracle.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Yes, this is very likely the issue. If you take the jfxwebkit.dll from > the latest EA build of JDK 11 then you should be fine. Alternatively, if > you have the patience to build webkit from source (at least once) then > you can use that. > > Johan had a good idea that gradle :web:test should produce a warning if > COMPILE_WEBKIT is false [1]. > > I just now filed a bug [2] to track this. > > -- Kevin > > [1] > https://github.com/javafxports/openjdk-jfx/issues/19#issuecomment- > 378521501 > [2] https://bugs.openjdk.java.net/browse/JDK-8201176 > > > Murali Billa wrote: > > Hi Lisker, > > > > +one more point: > > > > I think you are not compiling webkit . The command "gradle :web:test" > picks the webkit dll from JDK (which can have older versions like 10 / 9) . > > > > You can compile webkit with command " gradle -PCOMPILE_WEBKIT=true > :web:test" and in this case webkit dll will be picked up from your source > code repo (not from JDK). > > > > Thanks, > > Murali > > > > -----Original Message----- > > From: Murali Billa > > Sent: Thursday, April 05, 2018 10:19 AM > > To: Nir Lisker ; openjfx-dev at openjdk.java.net > Mailing > > Subject: RE: gradle :web:test fails > > > > Hi Lisker, > > > > Can you print the value of useragentString ? Looks like you are using > fxversion as 11 (you can print this value from System.getProperty("javafx.runtime.version");) > but the useragentstring does not contain 11. > > > > final WebView webView = new WebView(); > > final WebEngine webEngine = webView.getEngine(); > System.out.println(webEngine.getUserAgent()); > > > > > > Thanks, > > Murali > > -----Original Message----- > > From: Nir Lisker > > Sent: Thursday, April 05, 2018 7:03 AM > > To: openjfx-dev at openjdk.java.net Mailing > > Subject: gradle :web:test fails > > > > I'm running :web:test in revision 10889 and getting the following failing > > test: > > > > test.javafx.scene.web.MiscellaneousTest > testUserAgentString FAILED > > java.lang.AssertionError: UserAgentString does not contain JavaFX/11 > > at org.junit.Assert.fail(Assert.java:91) > > at org.junit.Assert.assertTrue(Assert.java:43) > > at > > test.javafx.scene.web.MiscellaneousTest.lambda$testUserAgentString$12( > MiscellaneousTest.java:441) > > > > 379 tests completed, 1 failed, 12 skipped :web:test FAILED > > > > Is this known? > > > > - Nir > > > > > ------------------------------ > > Message: 2 > Date: Thu, 5 Apr 2018 12:12:32 +0000 > From: Mikael Christensen - QIAGEN > To: "openjfx-dev at openjdk.java.net" > Subject: Will OpenJFX have a release ready in time for the Java 11 > launch? > Message-ID: > eurprd05.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi, > > This is a question about Oracle's statement that JavaFX will no longer be > part of the SDK starting from Java 11: > https://blogs.oracle.com/java-platform-group/the-future-of- > javafx-and-other-java-client-roadmap-updates > > Is the plan, that when Java 11 is released (scheduled for September 2018), > it will be possible to download a (prebuilt) JavaFX component from the > OpenJFX? > > Best, Mikael. > > > > ------------------------------ > > Message: 3 > Date: Thu, 05 Apr 2018 05:21:46 -0700 > From: Kevin Rushforth > To: Mikael Christensen - QIAGEN > Cc: "openjfx-dev at openjdk.java.net" > Subject: Re: Will OpenJFX have a release ready in time for the Java 11 > launch? > Message-ID: <5AC614DA.1090803 at oracle.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Yes, this is the plan. There has been quite a lot of discussion on this, > so I invite you to search the email archives [1]. Specifically, the > recent "modules versus SDK's" thread [2]. You are welcome to join the > mailing list [3] and contribute to the discussion if you like. > > -- Kevin > > [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/ > [2] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-March/021624.html > [3] http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > > > Mikael Christensen - QIAGEN wrote: > > Hi, > > > > This is a question about Oracle's statement that JavaFX will no longer > be part of the SDK starting from Java 11: > > https://blogs.oracle.com/java-platform-group/the-future-of- > javafx-and-other-java-client-roadmap-updates > > > > Is the plan, that when Java 11 is released (scheduled for September > 2018), it will be possible to download a (prebuilt) JavaFX component from > the OpenJFX? > > > > Best, Mikael. > > > > > > > ------------------------------ > > Message: 4 > Date: Thu, 05 Apr 2018 12:29:54 +0000 > From: Johan Vos > To: Mikael Christensen - QIAGEN > Cc: "openjfx-dev at openjdk.java.net" > Subject: Re: Will OpenJFX have a release ready in time for the Java 11 > launch? > Message-ID: > mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Yes, that is the plan. > > Actually, there are 2 paths: > 1. create a JavaFX SDK (see https://bugs.openjdk.java.net/ > browse/JDK-8198329 > ) > 2. create and upload the JavaFX modules to the traditional, popular > repositories (maven central, bintray) and make sure developers can use the > API's using maven/gradle (see > https://github.com/javafxports/openjdk-jfx/issues/52) > > This is imo the most important work right now, and a number of people are > working on it. > > I am very positive this [both paths] will be realised before the Java 11 > release date. > > - Johan > > On Thu, Apr 5, 2018 at 2:25 PM Mikael Christensen - QIAGEN < > Mikael.Christensen at qiagen.com> wrote: > > > Hi, > > > > This is a question about Oracle's statement that JavaFX will no longer be > > part of the SDK starting from Java 11: > > > > https://blogs.oracle.com/java-platform-group/the-future-of- > javafx-and-other-java-client-roadmap-updates > > > > Is the plan, that when Java 11 is released (scheduled for September > 2018), > > it will be possible to download a (prebuilt) JavaFX component from the > > OpenJFX? > > > > Best, Mikael. > > > > > > > ------------------------------ > > Message: 5 > Date: Fri, 6 Apr 2018 02:14:14 +0300 > From: Nir Lisker > To: Kevin Rushforth > Cc: "openjfx-dev at openjdk.java.net Mailing" > > Subject: Re: gradle :web:test fails > Message-ID: > -mtyF9YAYezYg at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Yes, I didn't build Webkit and the JDK is 10, but I thought the Webkit > tests would be skipped if it weren't built. > > The filed bug should do it. Thanks. > > - Nir > > On Thu, Apr 5, 2018, 15:01 Kevin Rushforth > wrote: > > > Yes, this is very likely the issue. If you take the jfxwebkit.dll from > > the latest EA build of JDK 11 then you should be fine. Alternatively, if > > you have the patience to build webkit from source (at least once) then > > you can use that. > > > > Johan had a good idea that gradle :web:test should produce a warning if > > COMPILE_WEBKIT is false [1]. > > > > I just now filed a bug [2] to track this. > > > > -- Kevin > > > > [1] > > https://github.com/javafxports/openjdk-jfx/issues/19#issuecomment- > > 378521501 > > [2] https://bugs.openjdk.java.net/browse/JDK-8201176 > > > > > > Murali Billa wrote: > > > Hi Lisker, > > > > > > +one more point: > > > > > > I think you are not compiling webkit . The command "gradle :web:test" > > picks the webkit dll from JDK (which can have older versions like 10 / > 9) . > > > > > > You can compile webkit with command " gradle -PCOMPILE_WEBKIT=true > > :web:test" and in this case webkit dll will be picked up from your source > > code repo (not from JDK). > > > > > > Thanks, > > > Murali > > > > > > -----Original Message----- > > > From: Murali Billa > > > Sent: Thursday, April 05, 2018 10:19 AM > > > To: Nir Lisker ; openjfx-dev at openjdk.java.net > > Mailing > > > Subject: RE: gradle :web:test fails > > > > > > Hi Lisker, > > > > > > Can you print the value of useragentString ? Looks like you are using > > fxversion as 11 (you can print this value from > System.getProperty("javafx.runtime.version");) > > but the useragentstring does not contain 11. > > > > > > final WebView webView = new WebView(); > > > final WebEngine webEngine = webView.getEngine(); > > System.out.println(webEngine.getUserAgent()); > > > > > > > > > Thanks, > > > Murali > > > -----Original Message----- > > > From: Nir Lisker > > > Sent: Thursday, April 05, 2018 7:03 AM > > > To: openjfx-dev at openjdk.java.net Mailing > > > > Subject: gradle :web:test fails > > > > > > I'm running :web:test in revision 10889 and getting the following > failing > > > test: > > > > > > test.javafx.scene.web.MiscellaneousTest > testUserAgentString FAILED > > > java.lang.AssertionError: UserAgentString does not contain > JavaFX/11 > > > at org.junit.Assert.fail(Assert.java:91) > > > at org.junit.Assert.assertTrue(Assert.java:43) > > > at > > > test.javafx.scene.web.MiscellaneousTest.lambda$testUserAgentString$12( > > MiscellaneousTest.java:441) > > > > > > 379 tests completed, 1 failed, 12 skipped :web:test FAILED > > > > > > Is this known? > > > > > > - Nir > > > > > > > > ------------------------------ > > Message: 6 > Date: Thu, 05 Apr 2018 17:21:02 -0700 > From: Kevin Rushforth > To: "openjfx-dev at openjdk.java.net" > Subject: Re: HEADS-UP: Proposal to bump the minimum boot JDK for FX to > JDK 10 > Message-ID: <5AC6BD6E.5090302 at oracle.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I created a pull request [3] for this, and discovered that the CI builds > for the GitHub sandbox are using JDK 9.0.4. Michael Ennen is fixing this > by switching both the Travis and Appveyor CI builds to use JDK 10 [4]. > > Given the disruptive nature of bumping the minimum, I think it is wise > to wait another day or two before taking any action on my proposal to > bump the minimum (we can and should still proceed to upgrade the CI > builds to use JDK 10). This will give others who might have concerns a > chance to comment. > > Comments? > > -- Kevin > > [3] https://github.com/javafxports/openjdk-jfx/pull/61 > > [4] https://github.com/javafxports/openjdk-jfx/pull/63 > > > Kevin Rushforth wrote: > > As mentioned in another thread [1] we should update the minimum boot > > JDK used to build FX to 10, which will allow the use of JDK 10 > > langauge features, such as 'var', as well as JDK 10 APIs. It's also > > the right time to do this in general. I filed a new RFE [2] to track > > this and plan to send it out for review next week. > > > > Please let me know if there are any concerns. We already use JDK 10 to > > build FX 11 ea bits. I presume that the travis and appveyor CI builds > > of the github mirror do the same? > > > > -- Kevin > > > > [1] > > http://mail.openjdk.java.net/pipermail/openjfx-dev/2018- > March/021671.html > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8200446 > > > > > End of openjfx-dev Digest, Vol 77, Issue 9 > ****************************************** > From murali.billa at oracle.com Fri Apr 6 18:09:33 2018 From: murali.billa at oracle.com (Murali Billa) Date: Fri, 6 Apr 2018 11:09:33 -0700 (PDT) Subject: [11] Review request for 8201176: gradle :web:test should print a warning if COMPILE_WEBKIT is false Message-ID: <0d631f73-66dc-4e8f-bbf3-f88eb05cb02c@default> Hi Kevin, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8201176 ? webrev:? http://cr.openjdk.java.net/~mbilla/8201176/webrev.00/ Thanks, Murali From nlisker at gmail.com Sat Apr 7 03:44:58 2018 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 7 Apr 2018 06:44:58 +0300 Subject: OpenJFX GitHub mirror In-Reply-To: <5AC50709.6080006@oracle.com> References: <5ABC43E6.10504@oracle.com> <055d45e1-1c38-6f82-2d9e-8f62a10d77d4@bestsolution.at> <5AC4CFC4.7080301@oracle.com> <5AC50709.6080006@oracle.com> Message-ID: Iv'e done some house cleaning and linked whatever I found. Should have caused a decent amount of notification spam... - Nir On Wed, Apr 4, 2018 at 8:10 PM, Kevin Rushforth wrote: > I don't have a strong preference. The URL contains either "issue" or > "pull" already, so there should be no confusion if we just use the URL. > > > -- Kevin > > > Nir Lisker wrote: > > github-bug is fine by me. What about external links, name them or leave > them as URLs? > > On Wed, Apr 4, 2018, 16:43 Johan Vos wrote: > >> +1 >> >> On Wed, Apr 4, 2018 at 3:30 PM Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> Any further comments on this? If not, then I propose we start using the >>> JBS label: >>> >>> github-bug >>> >>> To identify JBS issues that are linked to guthub issues and/or PRs >>> >>> -- Kevin >>> >>> >>> Nir Lisker wrote: >>> > I think that the labels should be succinct, so one label should >>> suffice. >>> > Either github-link or github-bug are fine for me, the latter because >>> there >>> > is webbug label already. If a PR needs review just use the >>> review-request >>> > existing label. >>> > >>> > As for issues and PRs, the issue links section in the JIRA ticket could >>> > reflect what exists in GitHub, so there can be 2 web links named >>> "GitHub >>> > issue" and "GitHub PR" if need be. >>> > >>> > - Nir >>> > >>> > On Thu, Mar 29, 2018 at 10:08 AM, Tom Schindl < >>> tom.schindl at bestsolution.at> >>> > wrote: >>> > >>> > >>> >> well could we have 2: >>> >> * github-issue >>> >> * github-pr >>> >> >>> >> The first one indicates someone is working on it over at github, >>> whereas >>> >> the second means there's a PR that needs to be review. >>> >> >>> >> Tom >>> >> >>> >> On 29.03.18 08:42, Laurent Bourg?s wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> As such github references point to either issue or PR, I recommend >>> using >>> >>> the term 'github-link'. >>> >>> >>> >>> Laurent >>> >>> >>> >>> Le jeu. 29 mars 2018 ? 03:40, Kevin Rushforth < >>> >>> >>> >> kevin.rushforth at oracle.com> >>> >> >>> >>> a ?crit : >>> >>> >>> >>> >>> >>>> I think this would be fine. We would want something that didn't >>> conflict >>> >>>> with anything else and wasn't confusing. Possible choices: >>> >>>> >>> >>>> github-link >>> >>>> github-bug >>> >>>> gitbug-issue >>> >>>> >>> >>>> Any preferences? >>> >>>> >>> >>>> -- Kevin >>> >>>> >>> >>>> >>> >>>> Nir Lisker wrote: >>> >>>> >>> >>>>> Kevin, can we get a label for this? >>> >>>>> >>> >>>>> - Nir >>> >>>>> >>> >>>>> On Mon, Mar 26, 2018 at 4:37 PM, Johan Vos >>> >>>>> >>> >>>> wrote: >>> >>>> >>> >>>>> >>> >>>>>> Hi Nir, >>> >>>>>> >>> >>>>>> About 4. (jfx-dev): you're right, I just removed that repository. >>> That >>> >>>>>> >>> >>>> was >>> >>>> >>> >>>>>> just some testing before we did the real thing. >>> >>>>>> >>> >>>>>> As for the other points: I agree >>> >>>>>> >>> >>>>>> - Johan >>> >>>>>> >>> >>>>>> On Mon, Mar 26, 2018 at 12:03 PM Nir Lisker >>> >>>>>> >>> >> wrote: >>> >> >>> >>>>>> >>> >>>>>>> Hi All, >>> >>>>>>> >>> >>>>>>> A few comments about the mirror and JBS: >>> >>>>>>> >>> >>>>>>> 1. In PRs and issues on GitHub, I strongly suggest that the link >>> to >>> >>>>>>> >>> >>>> JBS be >>> >>>> >>> >>>>>>> included in the top comment. If the JBS issue was created after a >>> >>>>>>> discussion, edit it in. >>> >>>>>>> >>> >>>>>>> 2. In JBS, I suggest to link to the GitHub mirror via More > >>> Link > >>> >>>>>>> >>> >> Web >>> >> >>> >>>>>>> Link and in the Link Text use something like "GitHub mirror" >>> (open >>> >>>>>>> >>> >> for >>> >> >>> >>>>>>> suggestions). JIRA renders the link in an easy to see way (easier >>> >>>>>>> >>> >> than >>> >> >>> >>>>>>> looking at URLs). Iv'e tried it in a couple of issues, e.g., >>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8198795 and it seems >>> >>>>>>> >>> >>>> preferable >>> >>>> >>> >>>>>>> to >>> >>>>>>> me. >>> >>>>>>> >>> >>>>>>> 3. In JBS, I suggest a new label will be used for issues which >>> are >>> >>>>>>> >>> >>>> linked >>> >>>> >>> >>>>>>> to GitHub for search purposes. This is similar to the webbug >>> label. >>> >>>>>>> >>> >>>>>>> If these are agreeable, please add them to the contribution >>> >>>>>>> >>> >>>> instructions. >>> >>>> >>> >>>>>>> 4. What is https://github.com/javafxports/jfx-dev? Newcomers can >>> >>>>>>> >>> >>>> confuse >>> >>>> >>> >>>>>>> it >>> >>>>>>> with javafxports/openjdk-jfx. >>> >>>>>>> >>> >>>>>>> 5. When the mirror is fully ready and operational, we should >>> >>>>>>> >>> >> advertise >>> >> >>> >>>> on >>> >>>> >>> >>>>>>> community pages (like Reddit) to gather up contributors. Please >>> keep >>> >>>>>>> >>> >> a >>> >> >>> >>>>>>> mental reminder when the time comes. >>> >>>>>>> >>> >>>>>>> Thanks to all who are working on this. >>> >>>>>>> >>> >>>>>>> - Nir >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >> From kevin.rushforth at oracle.com Sat Apr 7 12:28:53 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 07 Apr 2018 05:28:53 -0700 Subject: OpenJFX GitHub mirror In-Reply-To: References: <5ABC43E6.10504@oracle.com> <055d45e1-1c38-6f82-2d9e-8f62a10d77d4@bestsolution.at> <5AC4CFC4.7080301@oracle.com> <5AC50709.6080006@oracle.com> Message-ID: <5AC8B985.8080202@oracle.com> Hi Nir, Thank you for taking care of this. -- Kevin Nir Lisker wrote: > Iv'e done some house cleaning and linked whatever I found. Should have > caused a decent amount of notification spam... > > - Nir > > On Wed, Apr 4, 2018 at 8:10 PM, Kevin Rushforth > > wrote: > > I don't have a strong preference. The URL contains either "issue" > or "pull" already, so there should be no confusion if we just use > the URL. > > > -- Kevin > > > Nir Lisker wrote: >> github-bug is fine by me. What about external links, name them or >> leave them as URLs? >> >> On Wed, Apr 4, 2018, 16:43 Johan Vos > > wrote: >> >> +1 >> >> On Wed, Apr 4, 2018 at 3:30 PM Kevin Rushforth >> > > wrote: >> >> Any further comments on this? If not, then I propose we >> start using the >> JBS label: >> >> github-bug >> >> To identify JBS issues that are linked to guthub issues >> and/or PRs >> >> -- Kevin >> >> >> Nir Lisker wrote: >> > I think that the labels should be succinct, so one >> label should suffice. >> > Either github-link or github-bug are fine for me, the >> latter because there >> > is webbug label already. If a PR needs review just use >> the review-request >> > existing label. >> > >> > As for issues and PRs, the issue links section in the >> JIRA ticket could >> > reflect what exists in GitHub, so there can be 2 web >> links named "GitHub >> > issue" and "GitHub PR" if need be. >> > >> > - Nir >> > >> > On Thu, Mar 29, 2018 at 10:08 AM, Tom Schindl >> > > >> > wrote: >> > >> > >> >> well could we have 2: >> >> * github-issue >> >> * github-pr >> >> >> >> The first one indicates someone is working on it over >> at github, whereas >> >> the second means there's a PR that needs to be review. >> >> >> >> Tom >> >> >> >> On 29.03.18 08:42, Laurent Bourg?s wrote: >> >> >> >>> Hi, >> >>> >> >>> As such github references point to either issue or >> PR, I recommend using >> >>> the term 'github-link'. >> >>> >> >>> Laurent >> >>> >> >>> Le jeu. 29 mars 2018 ? 03:40, Kevin Rushforth < >> >>> >> >> kevin.rushforth at oracle.com >> > >> >> >> >>> a ?crit : >> >>> >> >>> >> >>>> I think this would be fine. We would want something >> that didn't conflict >> >>>> with anything else and wasn't confusing. Possible >> choices: >> >>>> >> >>>> github-link >> >>>> github-bug >> >>>> gitbug-issue >> >>>> >> >>>> Any preferences? >> >>>> >> >>>> -- Kevin >> >>>> >> >>>> >> >>>> Nir Lisker wrote: >> >>>> >> >>>>> Kevin, can we get a label for this? >> >>>>> >> >>>>> - Nir >> >>>>> >> >>>>> On Mon, Mar 26, 2018 at 4:37 PM, Johan Vos >> > >> >>>>> >> >>>> wrote: >> >>>> >> >>>>> >> >>>>>> Hi Nir, >> >>>>>> >> >>>>>> About 4. (jfx-dev): you're right, I just removed >> that repository. That >> >>>>>> >> >>>> was >> >>>> >> >>>>>> just some testing before we did the real thing. >> >>>>>> >> >>>>>> As for the other points: I agree >> >>>>>> >> >>>>>> - Johan >> >>>>>> >> >>>>>> On Mon, Mar 26, 2018 at 12:03 PM Nir Lisker >> > >> >>>>>> >> >> wrote: >> >> >> >>>>>> >> >>>>>>> Hi All, >> >>>>>>> >> >>>>>>> A few comments about the mirror and JBS: >> >>>>>>> >> >>>>>>> 1. In PRs and issues on GitHub, I strongly >> suggest that the link to >> >>>>>>> >> >>>> JBS be >> >>>> >> >>>>>>> included in the top comment. If the JBS issue was >> created after a >> >>>>>>> discussion, edit it in. >> >>>>>>> >> >>>>>>> 2. In JBS, I suggest to link to the GitHub mirror >> via More > Link > >> >>>>>>> >> >> Web >> >> >> >>>>>>> Link and in the Link Text use something like >> "GitHub mirror" (open >> >>>>>>> >> >> for >> >> >> >>>>>>> suggestions). JIRA renders the link in an easy to >> see way (easier >> >>>>>>> >> >> than >> >> >> >>>>>>> looking at URLs). Iv'e tried it in a couple of >> issues, e.g., >> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8198795 >> and it >> seems >> >>>>>>> >> >>>> preferable >> >>>> >> >>>>>>> to >> >>>>>>> me. >> >>>>>>> >> >>>>>>> 3. In JBS, I suggest a new label will be used for >> issues which are >> >>>>>>> >> >>>> linked >> >>>> >> >>>>>>> to GitHub for search purposes. This is similar to >> the webbug label. >> >>>>>>> >> >>>>>>> If these are agreeable, please add them to the >> contribution >> >>>>>>> >> >>>> instructions. >> >>>> >> >>>>>>> 4. What is https://github.com/javafxports/jfx-dev >> ? Newcomers can >> >>>>>>> >> >>>> confuse >> >>>> >> >>>>>>> it >> >>>>>>> with javafxports/openjdk-jfx. >> >>>>>>> >> >>>>>>> 5. When the mirror is fully ready and >> operational, we should >> >>>>>>> >> >> advertise >> >> >> >>>> on >> >>>> >> >>>>>>> community pages (like Reddit) to gather up >> contributors. Please keep >> >>>>>>> >> >> a >> >> >> >>>>>>> mental reminder when the time comes. >> >>>>>>> >> >>>>>>> Thanks to all who are working on this. >> >>>>>>> >> >>>>>>> - Nir >> >>>>>>> >> >>>>>>> >> >>>>>>> >> > From javalists at cbfiddle.com Sat Apr 7 16:50:51 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Sat, 7 Apr 2018 09:50:51 -0700 Subject: a program that fails only when run as a macOS bundled app Message-ID: I?ve run into a strange situation, a tiny Java Swing program that works when run from the command line (java -jar) but fails when run as a macOS bundled app created by the packager. I am using Java 10: java version "10" 2018-03-20 Java(TM) SE Runtime Environment 18.3 (build 10+46) Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode) The specific error appears to involve creating a window with an unsupported set of style bits. A similar error is described in JDK-8181476 [1]. NSWindow logs an assertion error. The problem does not arise in Java 8, probably because it uses a different set of style bits. Does anyone have an idea why the behavior would be different for the bundled app vs the command line? Anyone willing to take a look at it? Alan [1] https://bugs.openjdk.java.net/browse/JDK-8181476 package test; import javax.swing.JFrame; import javax.swing.SwingUtilities; public class Test { public Test() { // This frame is always displayed: JFrame fr1 = new JFrame("Test 1"); fr1.getRootPane().putClientProperty("Window.style", "small"); fr1.setResizable(false); fr1.setBounds(0, 0, 200, 200); fr1.setVisible(true); // This frame fails to display when run as a Java 10 bundled app: JFrame fr2 = new JFrame("Test 2"); fr2.getRootPane().putClientProperty("Window.style", "small"); fr2.setBounds(300, 0, 200, 200); fr2.setVisible(true); } public static void main(String[] args) { SwingUtilities.invokeLater(new Runnable() { public void run() { new Test(); } }); } } From ajit.ghaisas at oracle.com Tue Apr 10 10:10:35 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 10 Apr 2018 03:10:35 -0700 (PDT) Subject: [11] Review request : JDK-8177380 : Add standard colors in ColorPicker color palette Message-ID: Hi, Request you to review this simple RFE. RFE : https://bugs.openjdk.java.net/browse/JDK-8177380 Fix : http://cr.openjdk.java.net/~aghaisas/fx/e8177380/webrev.0/ Regards, Ajit From arunprasad.rajkumar at oracle.com Tue Apr 10 15:42:27 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 10 Apr 2018 21:12:27 +0530 Subject: [11] Review request for 8200629: Update SQLite to version 3.23.0 Message-ID: <8495BA41-C2CA-44D5-B89D-B348B2A9EEB3@oracle.com> Hi, Please review the following fix for JDK-8200629 , cmake related changes: http://cr.openjdk.java.net/~arajkumar/8200629/webrev/cmake changeset (includes cmake & sqlite upstream changes): http://cr.openjdk.java.net/~arajkumar/8200629/webrev/sqlite.changeset Thanks, Arun From kevin.rushforth at oracle.com Tue Apr 10 22:45:52 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Apr 2018 15:45:52 -0700 Subject: [11] Review request: 8199357: Remove references to applets and Java Web Start from FX Message-ID: Phil & Ajit, Please review these changes: https://bugs.openjdk.java.net/browse/JDK-8199357 http://cr.openjdk.java.net/~kcr/8199357/webrev.00/ Details are in JBS. -- Kevin From ajit.ghaisas at oracle.com Wed Apr 11 10:22:24 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 11 Apr 2018 03:22:24 -0700 (PDT) Subject: [8u-dev] Review Request : JDK-8189677 : RadioMenuItem fires extra NULL value in property Message-ID: <73e89b9f-8421-4627-b458-43738ef64ac1@default> Hi Kevin, Request you to review this 8u-dev backport : Bug : https://bugs.openjdk.java.net/browse/JDK-8189677 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8189677/8u/webrev.0/ Regards, Ajit From michael.dever at icloud.com Wed Apr 11 12:13:54 2018 From: michael.dever at icloud.com (Michael Dever) Date: Wed, 11 Apr 2018 08:13:54 -0400 Subject: [11] Review request: 8199357: Remove references to applets and Java Web Start from FX In-Reply-To: References: Message-ID: <2B58316A-ED14-4A91-8545-0F702A6A5BE1@icloud.com> Removing Applets from Java, an easy programming model, to put web objects up on the internet. A Blunder of a decision. But, sure clean it up. On Apr 10, 2018, at 6:45 PM, Kevin Rushforth wrote: Phil & Ajit, Please review these changes: https://bugs.openjdk.java.net/browse/JDK-8199357 http://cr.openjdk.java.net/~kcr/8199357/webrev.00/ Details are in JBS. -- Kevin From prem.balakrishnan at oracle.com Thu Apr 12 11:52:45 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Thu, 12 Apr 2018 04:52:45 -0700 (PDT) Subject: [8u-dev]Review Request : JDK-8198200 : Table auto resize ignores column resize policy Message-ID: <62592923-83a2-4459-860f-c85e02a067f8@default> Hi Kevin, Ajit Request you to review this 8u-dev backport : Bug : https://bugs.openjdk.java.net/browse/JDK-8192800 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/fx/8192800/8u/webrev.01/"http://cr.openjdk.java.net/~pkbalakr/fx/8192800/8u/webrev.01/ Regards, Prem From kevin.rushforth at oracle.com Fri Apr 13 16:00:01 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 13 Apr 2018 09:00:01 -0700 Subject: Result: New OpenJFX Committer: Rajath Kamath Message-ID: <1c3b4534-50d3-291c-78f6-825bb18f21bb@oracle.com> Voting for Rajath Kamath [1] to OpenJFX Committer [2] is now closed. Yes: 8 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#rkamath [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-March/021663.html From mirchord at gmail.com Sat Apr 14 16:45:44 2018 From: mirchord at gmail.com (Mirco) Date: Sat, 14 Apr 2018 18:45:44 +0200 Subject: WebView: in jfx9 the ENTER key from keyboard does not add new lines on textareas (but works correctly on jfx8) Message-ID: Hi, please forgive me if this is not the appropriate place for such kind of reports. I've encountered what seems a regression from jfx8, at least on "Ubuntu 16.04". As stated in the mail object the ENTER key produces no effects inside any editable components of a webpage. Note: the CTRL-M works instead. What follows is a very simple example to illustrate the issue: import javafx.application.Application; import javafx.scene.Node; import javafx.scene.Scene; import javafx.scene.web.WebEngine; import javafx.scene.web.WebView; import javafx.stage.Stage; import javafx.scene.layout.VBox; import javafx.scene.input.KeyEvent; public class WebViewSample extends Application { private Scene scene; @Override public void start(Stage stage) { stage.setTitle("Web View"); WebView editor = new WebView(); WebEngine engine = editor.getEngine(); engine.setJavaScriptEnabled(true); engine.loadContent(""); editor.setContextMenuEnabled(false); editor.addEventFilter(KeyEvent.KEY_PRESSED, (KeyEvent evt) -> { System.out.println(evt.getCode()); }); VBox root = new VBox(); root.getChildren().add(editor); scene = new Scene(root,750,500); stage.setScene(scene); stage.show(); } public static void main(String[] args){ launch(WebViewSample.class, args); } } As you can see the ENTER event is intercepted and printed out by the filter but no newline is added. This problem should not be confused with an old bug related to the JFXPanel (here no swing is involved). I have not tried with the latest builds of openjfx so just in case you are aware of that and/or the problem is already resolved please ignore this email. Kind regards, Mirco From murali.billa at oracle.com Sat Apr 14 17:22:24 2018 From: murali.billa at oracle.com (Murali Billa) Date: Sat, 14 Apr 2018 10:22:24 -0700 (PDT) Subject: WebView: in jfx9 the ENTER key from keyboard does not add new lines on textareas (but works correctly on jfx8) In-Reply-To: References: Message-ID: Hi Mirco, I tried the below sample code with JDK9+180 in Ubuntu and able to reproduce this issue. I tried with latest JDK build in Ubuntu (and in windows too) and not able to reproduce this issue (i can see new lines are being added upon entering ENTER key) I suggest you can verify with latest JDK build. Thanks, Murali -----Original Message----- From: Mirco Sent: Saturday, April 14, 2018 10:16 PM To: openjfx-dev at openjdk.java.net Subject: WebView: in jfx9 the ENTER key from keyboard does not add new lines on textareas (but works correctly on jfx8) Hi, please forgive me if this is not the appropriate place for such kind of reports. I've encountered what seems a regression from jfx8, at least on "Ubuntu 16.04". As stated in the mail object the ENTER key produces no effects inside any editable components of a webpage. Note: the CTRL-M works instead. What follows is a very simple example to illustrate the issue: import javafx.application.Application; import javafx.scene.Node; import javafx.scene.Scene; import javafx.scene.web.WebEngine; import javafx.scene.web.WebView; import javafx.stage.Stage; import javafx.scene.layout.VBox; import javafx.scene.input.KeyEvent; public class WebViewSample extends Application { private Scene scene; @Override public void start(Stage stage) { stage.setTitle("Web View"); WebView editor = new WebView(); WebEngine engine = editor.getEngine(); engine.setJavaScriptEnabled(true); engine.loadContent(""); editor.setContextMenuEnabled(false); editor.addEventFilter(KeyEvent.KEY_PRESSED, (KeyEvent evt) -> { System.out.println(evt.getCode()); }); VBox root = new VBox(); root.getChildren().add(editor); scene = new Scene(root,750,500); stage.setScene(scene); stage.show(); } public static void main(String[] args){ launch(WebViewSample.class, args); } } As you can see the ENTER event is intercepted and printed out by the filter but no newline is added. This problem should not be confused with an old bug related to the JFXPanel (here no swing is involved). I have not tried with the latest builds of openjfx so just in case you are aware of that and/or the problem is already resolved please ignore this email. Kind regards, Mirco From mirchord at gmail.com Sun Apr 15 14:58:09 2018 From: mirchord at gmail.com (Mirco) Date: Sun, 15 Apr 2018 16:58:09 +0200 Subject: WebView: in jfx9 the ENTER key from keyboard does not add new lines on textareas (but works correctly on jfx8) In-Reply-To: References: Message-ID: Hi Murali, thank you for the quick answer. Glad to hear the problem does not show up anymore with the latest build. I will check out again when in the future the official openjfx 11 binaries will be released. Thanks, Mirco On Sat, Apr 14, 2018 at 7:22 PM, Murali Billa wrote: > Hi Mirco, > > I tried the below sample code with JDK9+180 in Ubuntu and able to > reproduce this issue. > > I tried with latest JDK build in Ubuntu (and in windows too) and not able > to reproduce this issue (i can see new lines are being added upon entering > ENTER key) > > I suggest you can verify with latest JDK build. > > Thanks, > Murali > > -----Original Message----- > From: Mirco > Sent: Saturday, April 14, 2018 10:16 PM > To: openjfx-dev at openjdk.java.net > Subject: WebView: in jfx9 the ENTER key from keyboard does not add new > lines on textareas (but works correctly on jfx8) > > Hi, > please forgive me if this is not the appropriate place for such kind of > reports. > I've encountered what seems a regression from jfx8, at least on "Ubuntu > 16.04". > As stated in the mail object the ENTER key produces no effects inside any > editable components of a webpage. > Note: the CTRL-M works instead. > > What follows is a very simple example to illustrate the issue: > > import javafx.application.Application; > import javafx.scene.Node; > import javafx.scene.Scene; > import javafx.scene.web.WebEngine; > import javafx.scene.web.WebView; > import javafx.stage.Stage; > import javafx.scene.layout.VBox; > import javafx.scene.input.KeyEvent; > > public class WebViewSample extends Application { > private Scene scene; > > @Override public void start(Stage stage) { > stage.setTitle("Web View"); > WebView editor = new WebView(); > WebEngine engine = editor.getEngine(); > engine.setJavaScriptEnabled(true); > engine.loadContent(""); editor.setContextMenuEnabled(false); > editor.addEventFilter(KeyEvent.KEY_PRESSED, (KeyEvent evt) -> { > System.out.println(evt.getCode()); }); > VBox root = new VBox(); > root.getChildren().add(editor); > scene = new Scene(root,750,500); > stage.setScene(scene); > stage.show(); > } > > public static void main(String[] args){ > launch(WebViewSample.class, args); > } > } > > As you can see the ENTER event is intercepted and printed out by the > filter but no newline is added. > This problem should not be confused with an old bug related to the > JFXPanel (here no swing is involved). > I have not tried with the latest builds of openjfx so just in case you are > aware of that and/or the problem is already resolved please ignore this > email. > > Kind regards, > > Mirco > From mirchord at gmail.com Sun Apr 15 15:10:40 2018 From: mirchord at gmail.com (Mirco) Date: Sun, 15 Apr 2018 17:10:40 +0200 Subject: WebView: in jfx9 the ENTER key from keyboard does not add new lines on textareas (but works correctly on jfx8) In-Reply-To: References: Message-ID: Just as additional information, I noticed that currently in jfx10 the problem is still present. Regards, Mirco On Sun, Apr 15, 2018 at 4:58 PM, Mirco wrote: > Hi Murali, > thank you for the quick answer. > Glad to hear the problem does not show up anymore with the latest build. > I will check out again when in the future the official openjfx 11 binaries > will be released. > > Thanks, > Mirco > > On Sat, Apr 14, 2018 at 7:22 PM, Murali Billa > wrote: > >> Hi Mirco, >> >> I tried the below sample code with JDK9+180 in Ubuntu and able to >> reproduce this issue. >> >> I tried with latest JDK build in Ubuntu (and in windows too) and not able >> to reproduce this issue (i can see new lines are being added upon entering >> ENTER key) >> >> I suggest you can verify with latest JDK build. >> >> Thanks, >> Murali >> >> -----Original Message----- >> From: Mirco >> Sent: Saturday, April 14, 2018 10:16 PM >> To: openjfx-dev at openjdk.java.net >> Subject: WebView: in jfx9 the ENTER key from keyboard does not add new >> lines on textareas (but works correctly on jfx8) >> >> Hi, >> please forgive me if this is not the appropriate place for such kind of >> reports. >> I've encountered what seems a regression from jfx8, at least on "Ubuntu >> 16.04". >> As stated in the mail object the ENTER key produces no effects inside any >> editable components of a webpage. >> Note: the CTRL-M works instead. >> >> What follows is a very simple example to illustrate the issue: >> >> import javafx.application.Application; >> import javafx.scene.Node; >> import javafx.scene.Scene; >> import javafx.scene.web.WebEngine; >> import javafx.scene.web.WebView; >> import javafx.stage.Stage; >> import javafx.scene.layout.VBox; >> import javafx.scene.input.KeyEvent; >> >> public class WebViewSample extends Application { >> private Scene scene; >> >> @Override public void start(Stage stage) { >> stage.setTitle("Web View"); >> WebView editor = new WebView(); >> WebEngine engine = editor.getEngine(); >> engine.setJavaScriptEnabled(true); >> engine.loadContent(""); editor.setContextMenuEnabled(false); >> editor.addEventFilter(KeyEvent.KEY_PRESSED, (KeyEvent evt) -> { >> System.out.println(evt.getCode()); }); >> VBox root = new VBox(); >> root.getChildren().add(editor); >> scene = new Scene(root,750,500); >> stage.setScene(scene); >> stage.show(); >> } >> >> public static void main(String[] args){ >> launch(WebViewSample.class, args); >> } >> } >> >> As you can see the ENTER event is intercepted and printed out by the >> filter but no newline is added. >> This problem should not be confused with an old bug related to the >> JFXPanel (here no swing is involved). >> I have not tried with the latest builds of openjfx so just in case you >> are aware of that and/or the problem is already resolved please ignore this >> email. >> >> Kind regards, >> >> Mirco >> > > From murali.billa at oracle.com Sun Apr 15 17:13:25 2018 From: murali.billa at oracle.com (Murali Billa) Date: Sun, 15 Apr 2018 10:13:25 -0700 (PDT) Subject: WebView: in jfx9 the ENTER key from keyboard does not add new lines on textareas (but works correctly on jfx8) In-Reply-To: References: Message-ID: <0d26896a-bb57-4459-8f6b-7f6f86cdf5c8@default> Hi Mirco, ? Yes..Issue is present in JDK 10 (verified ?with? JDK 10+46). ? I tested with JDK 11 and issue is not reproducible. ? Thanks, Murali ? From: Mirco Sent: Sunday, April 15, 2018 8:41 PM To: Murali Billa Cc: openjfx-dev at openjdk.java.net Subject: Re: WebView: in jfx9 the ENTER key from keyboard does not add new lines on textareas (but works correctly on jfx8) ? Just as additional information, I noticed that? currently?in jfx10 the problem is still present. ? Regards, ? Mirco ? On Sun, Apr 15, 2018 at 4:58 PM, Mirco wrote: Hi Murali, thank you for the quick answer.? Glad to hear the problem does not show up anymore with the latest build.? I will check out again when in the future the official openjfx 11 binaries will be released. ? Thanks, Mirco ? On Sat, Apr 14, 2018 at 7:22 PM, Murali Billa wrote: Hi Mirco, I tried the below sample code with JDK9+180 in Ubuntu and able to reproduce this issue. I tried with latest JDK build in Ubuntu (and in windows too) and not able to reproduce this issue (i can see new lines are being added upon entering ENTER key) I suggest you can verify? with latest JDK build. Thanks, Murali -----Original Message----- From: Mirco Sent: Saturday, April 14, 2018 10:16 PM To: HYPERLINK "mailto:openjfx-dev at openjdk.java.net"openjfx-dev at openjdk.java.net Subject: WebView: in jfx9 the ENTER key from keyboard does not add new lines on textareas (but works correctly on jfx8) Hi, please forgive me if this is not the appropriate place for such kind of reports. I've encountered what seems a regression from jfx8, at least on "Ubuntu 16.04". As stated in the mail object the ENTER key produces no effects inside any editable components of a webpage. Note: the CTRL-M works instead. What follows is a very simple example to illustrate the issue: import javafx.application.Application; import javafx.scene.Node; import javafx.scene.Scene; import javafx.scene.web.WebEngine; import javafx.scene.web.WebView; import javafx.stage.Stage; import javafx.scene.layout.VBox; import javafx.scene.input.KeyEvent; public class WebViewSample extends Application { ? ? private Scene scene; ? ? @Override public void start(Stage stage) { ? ? ? ? stage.setTitle("Web View"); WebView editor = new WebView(); WebEngine engine = editor.getEngine(); ? ? ? ? engine.setJavaScriptEnabled(true); engine.loadContent(""); editor.setContextMenuEnabled(false); editor.addEventFilter(KeyEvent.KEY_PRESSED, (KeyEvent evt) -> { System.out.println(evt.getCode()); }); ? ? ? ? VBox root = new VBox(); root.getChildren().add(editor); ? ? ? ? scene = new Scene(root,750,500); ? ? ? ? stage.setScene(scene); ? ? ? ? stage.show(); ? ? } ? ? public static void main(String[] args){ ? ? ? ? launch(WebViewSample.class, args); ? ? } } As you can see the ENTER event is intercepted and printed out by the filter but no newline is added. This problem should not be confused with an old bug related to the JFXPanel (here no swing is involved). I have not tried with the latest builds of openjfx so just in case you are aware of that and/or the problem is already resolved please ignore this email. Kind regards, Mirco ? ? From john at status6.com Mon Apr 16 17:25:43 2018 From: john at status6.com (John Neffenger) Date: Mon, 16 Apr 2018 10:25:43 -0700 Subject: Monocle Headless BufferOverflowException (Issue + Fix) In-Reply-To: References: <5A909763.3070003@oracle.com> Message-ID: <4de1c8e3-fe4e-33a5-00fd-28fff6b8c65f@status6.com> On 02/23/2018 03:12 PM, Michael Ennen wrote: > Good point about the OCA, I have sent an email just now to > John Neffenger. Hopefully he is still interested in this topic :). I filed the bug report yesterday, along with two others. It was assigned the internal review ID 9053385 and has the synopsis, "QuantumRenderer modifies buffer in use by JavaFX Application Thread." The problem happens on the Monocle VNC and Headless platforms, along with any other NativeScreen implementation that happens to use a non-direct buffer to back the Framebuffer. I created two short videos showing the problem before and after a fix is applied: Before: Waving and Jumping Duke (one minute) https://youtu.be/mfSzSMDIEIM After: Waving Duke (10 seconds) https://youtu.be/pUXPL_Gm8Qw Thank you, John From john at status6.com Mon Apr 16 17:46:42 2018 From: john at status6.com (John Neffenger) Date: Mon, 16 Apr 2018 10:46:42 -0700 Subject: Monocle Headless BufferOverflowException (Issue + Fix) In-Reply-To: References: Message-ID: On 02/23/2018 02:29 PM, Michael Ennen wrote: > When doing some testing with TestFX running in headless mode > via Monocle I came across a BufferOverflowException. One thing to check: make sure your JavaFX Scene is not exceeding the screen size of the Monocle Headless platform, which is 1280 ? 800 px. Otherwise, you'll get a BufferOverflowException like the following, where I exceeded the height by one pixel: Starting application on Headless platform (1280 ? 801 px) ... java.nio.BufferOverflowException at java.nio.DirectIntBufferU.put(DirectIntBufferU.java:363) at com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:153) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) at java.lang.Thread.run(Thread.java:748) The maximum screen sizes for some Monocle platforms are: Linux: The framebuffer size Headless: 1280 ? 800 px VNC: 1024 ? 600 px You can use the "fbset" command to find or change the Linux framebuffer size: $ sudo fbset mode "1024x768-76" # D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz geometry 1024 768 1024 768 32 timings 12714 128 32 16 4 128 4 rgba 8/16,8/8,8/0,8/24 endmode John From nlisker at gmail.com Mon Apr 16 18:41:18 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 16 Apr 2018 18:41:18 +0000 Subject: Monocle Headless BufferOverflowException (Issue + Fix) In-Reply-To: <4de1c8e3-fe4e-33a5-00fd-28fff6b8c65f@status6.com> References: <5A909763.3070003@oracle.com> <4de1c8e3-fe4e-33a5-00fd-28fff6b8c65f@status6.com> Message-ID: It was moved to https://bugs.openjdk.java.net/browse/JDK-8201567. On Mon, Apr 16, 2018, 20:26 John Neffenger wrote: > On 02/23/2018 03:12 PM, Michael Ennen wrote: > > Good point about the OCA, I have sent an email just now to > > John Neffenger. Hopefully he is still interested in this topic :). > > I filed the bug report yesterday, along with two others. It was assigned > the internal review ID 9053385 and has the synopsis, "QuantumRenderer > modifies buffer in use by JavaFX Application Thread." > > The problem happens on the Monocle VNC and Headless platforms, along > with any other NativeScreen implementation that happens to use a > non-direct buffer to back the Framebuffer. > > I created two short videos showing the problem before and after a fix is > applied: > > Before: Waving and Jumping Duke (one minute) > https://youtu.be/mfSzSMDIEIM > > After: Waving Duke (10 seconds) > https://youtu.be/pUXPL_Gm8Qw > > Thank you, > John > From mike.ennen at gmail.com Mon Apr 16 20:10:57 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 16 Apr 2018 13:10:57 -0700 Subject: Monocle Headless BufferOverflowException (Issue + Fix) In-Reply-To: References: <5A909763.3070003@oracle.com> <4de1c8e3-fe4e-33a5-00fd-28fff6b8c65f@status6.com> Message-ID: I note in the issue Kevin said: " I note that if this really is Monocle-specific, then we will likely need someone from the community to provide a fix. " Just want to make sure it is clear, John has already provided the fix: https://gitlab.com/openjfxepd/jfxpatch/commit/f7c341775e5258 e790a049f3fdce4a956ef665c7 On Mon, Apr 16, 2018 at 11:41 AM, Nir Lisker wrote: > It was moved to https://bugs.openjdk.java.net/browse/JDK-8201567. > > On Mon, Apr 16, 2018, 20:26 John Neffenger wrote: > > > On 02/23/2018 03:12 PM, Michael Ennen wrote: > > > Good point about the OCA, I have sent an email just now to > > > John Neffenger. Hopefully he is still interested in this topic :). > > > > I filed the bug report yesterday, along with two others. It was assigned > > the internal review ID 9053385 and has the synopsis, "QuantumRenderer > > modifies buffer in use by JavaFX Application Thread." > > > > The problem happens on the Monocle VNC and Headless platforms, along > > with any other NativeScreen implementation that happens to use a > > non-direct buffer to back the Framebuffer. > > > > I created two short videos showing the problem before and after a fix is > > applied: > > > > Before: Waving and Jumping Duke (one minute) > > https://youtu.be/mfSzSMDIEIM > > > > After: Waving Duke (10 seconds) > > https://youtu.be/pUXPL_Gm8Qw > > > > Thank you, > > John > > > -- Michael Ennen From kevin.rushforth at oracle.com Mon Apr 16 20:17:21 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 16 Apr 2018 13:17:21 -0700 Subject: Monocle Headless BufferOverflowException (Issue + Fix) In-Reply-To: References: <5A909763.3070003@oracle.com> <4de1c8e3-fe4e-33a5-00fd-28fff6b8c65f@status6.com> Message-ID: <782a0bea-6678-1c65-abb9-32a4ee3e778a@oracle.com> OK, in that case once the OCA is in place we can evaluate the proposed fix. Thanks. -- Kevin On 4/16/2018 1:10 PM, Michael Ennen wrote: > I note in the issue Kevin said: > > " I note that if this really is Monocle-specific, then we will likely need > someone from the community to provide a fix. " > > Just want to make sure it is clear, John has already provided the fix: > > https://gitlab.com/openjfxepd/jfxpatch/commit/f7c341775e5258 > e790a049f3fdce4a956ef665c7 > > > > On Mon, Apr 16, 2018 at 11:41 AM, Nir Lisker wrote: > >> It was moved to https://bugs.openjdk.java.net/browse/JDK-8201567. >> >> On Mon, Apr 16, 2018, 20:26 John Neffenger wrote: >> >>> On 02/23/2018 03:12 PM, Michael Ennen wrote: >>>> Good point about the OCA, I have sent an email just now to >>>> John Neffenger. Hopefully he is still interested in this topic :). >>> I filed the bug report yesterday, along with two others. It was assigned >>> the internal review ID 9053385 and has the synopsis, "QuantumRenderer >>> modifies buffer in use by JavaFX Application Thread." >>> >>> The problem happens on the Monocle VNC and Headless platforms, along >>> with any other NativeScreen implementation that happens to use a >>> non-direct buffer to back the Framebuffer. >>> >>> I created two short videos showing the problem before and after a fix is >>> applied: >>> >>> Before: Waving and Jumping Duke (one minute) >>> https://youtu.be/mfSzSMDIEIM >>> >>> After: Waving Duke (10 seconds) >>> https://youtu.be/pUXPL_Gm8Qw >>> >>> Thank you, >>> John >>> > > From murali.billa at oracle.com Tue Apr 17 12:35:51 2018 From: murali.billa at oracle.com (Murali Billa) Date: Tue, 17 Apr 2018 12:35:51 +0000 (UTC) Subject: [11] Review request for 8200418: webPage.executeCommand("removeFormat", null) removes the style of the body element Message-ID: <707c96f0-f945-40a0-8561-ffbfe6cba8de@default> ? Hi Kevin, Arun Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8200418 ? webrev:? http://cr.openjdk.java.net/~mbilla/8200418/webrev.00/ Thanks, Murali From nlisker at gmail.com Wed Apr 18 10:29:36 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 18 Apr 2018 13:29:36 +0300 Subject: JDK-8198795: Remove IDE specific files from the source code repository Message-ID: Hi all, There were several discussion in GitHub about removing IDE files (they are linked from the JBS issue [1]). At the end, I didn't see any decision or any change. I would like to update the Eclipse files soon since the cleanup [2] is almost done. These files allow anyone who checks out OpenJFX to start working immediately. If these files are not provided, they would need to manually configure them and currently that's a bit tricky. I would like to know the current stand on this. Thanks, Nir [1] https://bugs.openjdk.java.net/browse/JDK-8198795 [2] https://bugs.openjdk.java.net/browse/JDK-8195798 From tom.schindl at bestsolution.at Wed Apr 18 12:29:21 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 18 Apr 2018 14:29:21 +0200 Subject: JDK-8198795: Remove IDE specific files from the source code repository In-Reply-To: References: Message-ID: <1f7d3f67-d91b-51df-2ae6-a47898d00010@bestsolution.at> Hi, I've also worked on the Eclipse specific files. We should compare yours and mine (I've been doing this on Photon-builds against JDK-10). Tom On 18.04.18 12:29, Nir Lisker wrote: > Hi all, > > There were several discussion in GitHub about removing IDE files (they are > linked from the JBS issue [1]). At the end, I didn't see any decision or > any change. > > I would like to update the Eclipse files soon since the cleanup [2] is > almost done. These files allow anyone who checks out OpenJFX to start > working immediately. If these files are not provided, they would need to > manually configure them and currently that's a bit tricky. > > I would like to know the current stand on this. > > Thanks, > Nir > > [1] https://bugs.openjdk.java.net/browse/JDK-8198795 > > [2] https://bugs.openjdk.java.net/browse/JDK-8195798 > From nlisker at gmail.com Wed Apr 18 13:39:14 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 18 Apr 2018 16:39:14 +0300 Subject: JDK-8198795: Remove IDE specific files from the source code repository In-Reply-To: <1f7d3f67-d91b-51df-2ae6-a47898d00010@bestsolution.at> References: <1f7d3f67-d91b-51df-2ae6-a47898d00010@bestsolution.at> Message-ID: Hi Tom, Iv'e been using the same setup. We first need to fix https://bugs.openjdk.java.net/browse/JDK-8195974. Iv'e addressed a comment there to you. Then we can discuss and compare files, but I'm not clear on whether they should be committed. - Nir On Wed, Apr 18, 2018 at 3:29 PM, Tom Schindl wrote: > Hi, > > I've also worked on the Eclipse specific files. We should compare yours > and mine (I've been doing this on Photon-builds against JDK-10). > > Tom > > On 18.04.18 12:29, Nir Lisker wrote: > > Hi all, > > > > There were several discussion in GitHub about removing IDE files (they > are > > linked from the JBS issue [1]). At the end, I didn't see any decision or > > any change. > > > > I would like to update the Eclipse files soon since the cleanup [2] is > > almost done. These files allow anyone who checks out OpenJFX to start > > working immediately. If these files are not provided, they would need to > > manually configure them and currently that's a bit tricky. > > > > I would like to know the current stand on this. > > > > Thanks, > > Nir > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8198795 > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8195798 > > > From tom.schindl at bestsolution.at Wed Apr 18 21:31:33 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 18 Apr 2018 23:31:33 +0200 Subject: JDK-8198795: Remove IDE specific files from the source code repository In-Reply-To: References: <1f7d3f67-d91b-51df-2ae6-a47898d00010@bestsolution.at> Message-ID: <68e85083-e080-6027-54f6-5840ac919efe@bestsolution.at> Hi, Well until someone proofs that those setups can be generated I think should maintain them. My current Eclipse-Setup changes can been seen at [1]. The compile error I still see are: * base: because of jul (i fixed that in my module-info.java) with "requires static java.logging;" * controls: - Dialog: see https://bugs.eclipse.org/bugs/show_bug.cgi?id=532850 - jul with "requires static java.logging;" in module-info.java * fxml: - adding "requires static javafx.controls;" to compile Junit * web: - adding "requires static java.management;" to compile Tom [1]https://github.com/javafxports/openjdk-jfx/compare/master...BestSolution-at:eclipse-setup?expand=1 On 18.04.18 15:39, Nir Lisker wrote: > Hi Tom, > > Iv'e been using the same setup. We first need to > fix?https://bugs.openjdk.java.net/browse/JDK-8195974. Iv'e addressed a > comment there to you. > Then we can discuss and compare files, but I'm not clear on whether they > should be committed. > > - Nir > > On Wed, Apr 18, 2018 at 3:29 PM, Tom Schindl > > wrote: > > Hi, > > I've also worked on the Eclipse specific files. We should compare yours > and mine (I've been doing this on Photon-builds against JDK-10). > > Tom > > On 18.04.18 12:29, Nir Lisker wrote: > > Hi all, > > > > There were several discussion in GitHub about removing IDE files > (they are > > linked from the JBS issue [1]). At the end, I didn't see any > decision or > > any change. > > > > I would like to update the Eclipse files soon since the cleanup [2] is > > almost done. These files allow anyone who checks out OpenJFX to start > > working immediately. If these files are not provided, they would > need to > > manually configure them and currently that's a bit tricky. > > > > I would like to know the current stand on this. > > > > Thanks, > > Nir > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8198795 > > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8195798 > > > > > From johan.vos at gluonhq.com Thu Apr 19 06:18:53 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 19 Apr 2018 06:18:53 +0000 Subject: fix for https://bugs.openjdk.java.net/browse/JDK-8199765 Message-ID: Can someone review/ack the simple PR for https://bugs.openjdk.java.net/browse/JDK-8199765 ? Thanks, - Johan From wookey.dean at gmail.com Thu Apr 19 09:57:41 2018 From: wookey.dean at gmail.com (Dean Wookey) Date: Thu, 19 Apr 2018 11:57:41 +0200 Subject: EM Font Size Performance Message-ID: Hi All, In our application we add and remove a lot of nodes to the scene graph regularly, and also make use of em font sizes to scale certain parts of our application. We've noticed performance issues when adding nodes to the scene, and it seems to be related to em sizes in our css. As a test we added a chain of 20 stackpanes to a root stackpane. On the root, we set a font size of 8pt via inline css. We then added and removed a new tableview from the deepest stackpane 500 times, waiting for the node to render after each add and remove. In each of the experiments, we compared adding tableviews without css and adding tableviews with an inline css font size of 8pt. We then tried setting different font sizes in the stackpane chain. I've attached sample code for these experiments. The results (on jdk 9.0.4 - jdk 10 was similar) are as follows: Setting a 1em font size on all stackpanes except the root. With font on tableview: 14707ms Without font on tableview: 27725ms Setting a 1em font size on the first child of the root only. With font on tableview: 14221ms Without font on tableview: 19187ms Using the original setup with no additional fonts. With font on tableview: 13990ms Without font on tableview: 13847ms It looks like using a relative font size has a large effect performance wise on descendant nodes. I would expect some amount of font size caching in the chain of stackpanes since I'm reusing the same chain and adding/removing nodes from that chain repeatedly. I'm not sure how valid my test is, or how much of an issue this really is in practice? Dean From david.grieve at oracle.com Thu Apr 19 10:42:47 2018 From: david.grieve at oracle.com (David Grieve) Date: Thu, 19 Apr 2018 06:42:47 -0400 Subject: EM Font Size Performance In-Reply-To: References: Message-ID: <6197cbbe-5152-6e1d-d3d0-a38f3556dc8d@oracle.com> Resolving the relative size involves a lot of lookup. You have to go up the scene-graph from the child to find a font style. If you get to the root and haven't found a font style, then use the default font. Performance in this area could be vastly improved by passing the size from either a font style or the default font down the scene-graph as styles are evaluated. There are other style lookups that could benefit from this as well, resolving looked-up colors for example. I believe I created a bug for this a long time ago. On 4/19/18 5:57 AM, Dean Wookey wrote: > Hi All, > > In our application we add and remove a lot of nodes to the scene graph > regularly, and also make use of em font sizes to scale certain parts of our > application. We've noticed performance issues when adding nodes to the > scene, and it seems to be related to em sizes in our css. > > As a test we added a chain of 20 stackpanes to a root stackpane. On the > root, we set a font size of 8pt via inline css. We then added and removed a > new tableview from the deepest stackpane 500 times, waiting for the node to > render after each add and remove. > > In each of the experiments, we compared adding tableviews without css and > adding tableviews with an inline css font size of 8pt. We then tried > setting different font sizes in the stackpane chain. > > I've attached sample code for these experiments. > > The results (on jdk 9.0.4 - jdk 10 was similar) are as follows: > > Setting a 1em font size on all stackpanes except the root. > With font on tableview: 14707ms > Without font on tableview: 27725ms > > Setting a 1em font size on the first child of the root only. > With font on tableview: 14221ms > Without font on tableview: 19187ms > > Using the original setup with no additional fonts. > With font on tableview: 13990ms > Without font on tableview: 13847ms > > It looks like using a relative font size has a large effect performance > wise on descendant nodes. I would expect some amount of font size caching > in the chain of stackpanes since I'm reusing the same chain and > adding/removing nodes from that chain repeatedly. > > I'm not sure how valid my test is, or how much of an issue this really is > in practice? > > Dean From kevin.rushforth at oracle.com Thu Apr 19 11:38:47 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Apr 2018 04:38:47 -0700 Subject: fix for https://bugs.openjdk.java.net/browse/JDK-8199765 In-Reply-To: References: Message-ID: +1 On 4/18/2018 11:18 PM, Johan Vos wrote: > Can someone review/ack the simple PR for > https://bugs.openjdk.java.net/browse/JDK-8199765 ? > > Thanks, > > - Johan From johan.vos at gluonhq.com Thu Apr 19 15:10:09 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 19 Apr 2018 15:10:09 +0000 Subject: COMPILE_SWING defaults to false Message-ID: Before pushing http://cr.openjdk.java.net/~jvos/8195669/webrev.00/rt.patch as a fix for JDK-8195669 (see https://github.com/javafxports/openjdk-jfx/pull/58) I want to double check that it is fine that COMPILE_SWING defaults to false ? - Johan From kevin.rushforth at oracle.com Thu Apr 19 15:21:51 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Apr 2018 08:21:51 -0700 Subject: COMPILE_SWING defaults to false In-Reply-To: References: Message-ID: For all platforms or just for arm? The latter should be fine. The former would break the build, but fortunately, that flag defaults to true on desktop platforms. buildSrc/linux.gradle:LINUX.compileSwing = true; buildSrc/mac.gradle:MAC.compileSwing = true; buildSrc/win.gradle:WIN.compileSwing = true; Note that COMPILE_SWING is not intended to be set on the command line (e.g., not with 'gradle -P') but in the platform-specific buildSrc/XXX.gradle file. -- Kevin On 4/19/2018 8:10 AM, Johan Vos wrote: > Before pushing > http://cr.openjdk.java.net/~jvos/8195669/webrev.00/rt.patch > as a fix for JDK-8195669 > (see https://github.com/javafxports/openjdk-jfx/pull/58) I want to double > check that it is fine that COMPILE_SWING defaults to false ? > > - Johan From kevin.rushforth at oracle.com Thu Apr 19 15:22:41 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Apr 2018 08:22:41 -0700 Subject: COMPILE_SWING defaults to false In-Reply-To: References: Message-ID: I guess I should say "for non-desktop platforms" since COMPILE_SWING is also false for iOS and dalvik platforms. -- Kevin On 4/19/2018 8:21 AM, Kevin Rushforth wrote: > For all platforms or just for arm? The latter should be fine. The > former would break the build, but fortunately, that flag defaults to > true on desktop platforms. > > buildSrc/linux.gradle:LINUX.compileSwing = true; > buildSrc/mac.gradle:MAC.compileSwing = true; > buildSrc/win.gradle:WIN.compileSwing = true; > > Note that COMPILE_SWING is not intended to be set on the command line > (e.g., not with 'gradle -P') but in the platform-specific > buildSrc/XXX.gradle file. > > -- Kevin > > > On 4/19/2018 8:10 AM, Johan Vos wrote: >> Before pushing >> http://cr.openjdk.java.net/~jvos/8195669/webrev.00/rt.patch >> as a fix for JDK-8195669 >> >> ? (see https://github.com/javafxports/openjdk-jfx/pull/58) I want to >> double >> check that it is fine that COMPILE_SWING defaults to false ? >> >> - Johan > From nlisker at gmail.com Thu Apr 19 19:02:44 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 19 Apr 2018 22:02:44 +0300 Subject: EM Font Size Performance In-Reply-To: <6197cbbe-5152-6e1d-d3d0-a38f3556dc8d@oracle.com> References: <6197cbbe-5152-6e1d-d3d0-a38f3556dc8d@oracle.com> Message-ID: I think this is the issue: https://bugs.openjdk.java.net/browse/JDK-8088615. There's also https://bugs.openjdk.java.net/browse/JDK-8193445. - Nir On Thu, Apr 19, 2018 at 1:42 PM, David Grieve wrote: > Resolving the relative size involves a lot of lookup. You have to go up > the scene-graph from the child to find a font style. If you get to the root > and haven't found a font style, then use the default font. Performance in > this area could be vastly improved by passing the size from either a font > style or the default font down the scene-graph as styles are evaluated. > There are other style lookups that could benefit from this as well, > resolving looked-up colors for example. I believe I created a bug for this > a long time ago. > > > > On 4/19/18 5:57 AM, Dean Wookey wrote: > >> Hi All, >> >> In our application we add and remove a lot of nodes to the scene graph >> regularly, and also make use of em font sizes to scale certain parts of >> our >> application. We've noticed performance issues when adding nodes to the >> scene, and it seems to be related to em sizes in our css. >> >> As a test we added a chain of 20 stackpanes to a root stackpane. On the >> root, we set a font size of 8pt via inline css. We then added and removed >> a >> new tableview from the deepest stackpane 500 times, waiting for the node >> to >> render after each add and remove. >> >> In each of the experiments, we compared adding tableviews without css and >> adding tableviews with an inline css font size of 8pt. We then tried >> setting different font sizes in the stackpane chain. >> >> I've attached sample code for these experiments. >> >> The results (on jdk 9.0.4 - jdk 10 was similar) are as follows: >> >> Setting a 1em font size on all stackpanes except the root. >> With font on tableview: 14707ms >> Without font on tableview: 27725ms >> >> Setting a 1em font size on the first child of the root only. >> With font on tableview: 14221ms >> Without font on tableview: 19187ms >> >> Using the original setup with no additional fonts. >> With font on tableview: 13990ms >> Without font on tableview: 13847ms >> >> It looks like using a relative font size has a large effect performance >> wise on descendant nodes. I would expect some amount of font size caching >> in the chain of stackpanes since I'm reusing the same chain and >> adding/removing nodes from that chain repeatedly. >> >> I'm not sure how valid my test is, or how much of an issue this really is >> in practice? >> >> Dean >> > > From david.grieve at oracle.com Thu Apr 19 19:51:48 2018 From: david.grieve at oracle.com (David Grieve) Date: Thu, 19 Apr 2018 15:51:48 -0400 Subject: EM Font Size Performance In-Reply-To: References: <6197cbbe-5152-6e1d-d3d0-a38f3556dc8d@oracle.com> Message-ID: <6bc18460-15a8-74d7-3cff-082c87aee1c4@oracle.com> I was thinking about https://bugs.openjdk.java.net/browse/JDK-8177635 and https://bugs.openjdk.java.net/browse/JDK-8090462 There is also https://bugs.openjdk.java.net/browse/JDK-8187955 On 4/19/18 3:02 PM, Nir Lisker wrote: > I think this is the issue: > https://bugs.openjdk.java.net/browse/JDK-8088615. There's also > https://bugs.openjdk.java.net/browse/JDK-8193445. > > - Nir > > On Thu, Apr 19, 2018 at 1:42 PM, David Grieve > wrote: > > Resolving the relative size involves a lot of lookup. You have to > go up the scene-graph from the child to find a font style. If you > get to the root and haven't found a font style, then use the > default font. Performance in this area could be vastly improved by > passing the size from either a font style or the default font down > the scene-graph as styles are evaluated. There are other style > lookups that could benefit from this as well, resolving looked-up > colors for example. I believe I created a bug for this a long time > ago. > > > > On 4/19/18 5:57 AM, Dean Wookey wrote: > > Hi All, > > In our application we add and remove a lot of nodes to the > scene graph > regularly, and also make use of em font sizes to scale certain > parts of our > application. We've noticed performance issues when adding > nodes to the > scene, and it seems to be related to em sizes in our css. > > As a test we added a chain of 20 stackpanes to a root > stackpane. On the > root, we set a font size of 8pt via inline css. We then added > and removed a > new tableview from the deepest stackpane 500 times, waiting > for the node to > render after each add and remove. > > In each of the experiments, we compared adding tableviews > without css and > adding tableviews with an inline css font size of 8pt. We then > tried > setting different font sizes in the stackpane chain. > > I've attached sample code for these experiments. > > The results (on jdk 9.0.4 - jdk 10 was similar) are as follows: > > Setting a 1em font size on all stackpanes except the root. > With font on tableview: 14707ms > Without font on tableview: 27725ms > > Setting a 1em font size on the first child of the root only. > With font on tableview: 14221ms > Without font on tableview: 19187ms > > Using the original setup with no additional fonts. > With font on tableview: 13990ms > Without font on tableview: 13847ms > > It looks like using a relative font size has a large effect > performance > wise on descendant nodes. I would expect some amount of font > size caching > in the chain of stackpanes since I'm reusing the same chain and > adding/removing nodes from that chain repeatedly. > > I'm not sure how valid my test is, or how much of an issue > this really is > in practice? > > Dean > > > From nlisker at gmail.com Thu Apr 19 21:26:14 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 20 Apr 2018 00:26:14 +0300 Subject: JDK-8198795: Remove IDE specific files from the source code repository In-Reply-To: <68e85083-e080-6027-54f6-5840ac919efe@bestsolution.at> References: <1f7d3f67-d91b-51df-2ae6-a47898d00010@bestsolution.at> <68e85083-e080-6027-54f6-5840ac919efe@bestsolution.at> Message-ID: So you're adding read edges in the module-info files via "requires". I didn't do this because these files are shared and we can't have 2 versions of them. I added the read edges via "--add-reads" in the .classpath files. This way Eclipse solves its own problems without external changes. However, since Eclipse modular support is still in progress, it's impossible to create a valid run configuration with these modules. There are several bugs being tracked regarding this approach (I can dig them up if you're interested). Once the java.logging dependency is removed we will be able to simplify our solutions and I'll post my .classpaths. Well until someone proofs that those setups can be generated I think should > maintain them. If no one disagrees by the time java.logging is removed I'll file an issue to update the Eclipse files. Dialog: see https://bugs.eclipse.org/bugs/show_bug.cgi?id=532850 > I assume it's the "The blank final field dialog may not have been initialized" error. It doesn't stop the building at least, unlike the module stuff. - Nir On Thu, Apr 19, 2018 at 12:31 AM, Tom Schindl wrote: > Hi, > > Well until someone proofs that those setups can be generated I think > should maintain them. > > My current Eclipse-Setup changes can been seen at [1]. The compile error > I still see are: > > * base: because of jul (i fixed that in my module-info.java) with > "requires static java.logging;" > > * controls: > - Dialog: see https://bugs.eclipse.org/bugs/show_bug.cgi?id=532850 > - jul with "requires static java.logging;" in module-info.java > > * fxml: > - adding "requires static javafx.controls;" to compile Junit > > * web: > - adding "requires static java.management;" to compile > > Tom > > [1]https://github.com/javafxports/openjdk-jfx/ > compare/master...BestSolution-at:eclipse-setup?expand=1 > > On 18.04.18 15:39, Nir Lisker wrote: > > Hi Tom, > > > > Iv'e been using the same setup. We first need to > > fix https://bugs.openjdk.java.net/browse/JDK-8195974. Iv'e addressed a > > comment there to you. > > Then we can discuss and compare files, but I'm not clear on whether they > > should be committed. > > > > - Nir > > > > On Wed, Apr 18, 2018 at 3:29 PM, Tom Schindl > > > > wrote: > > > > Hi, > > > > I've also worked on the Eclipse specific files. We should compare > yours > > and mine (I've been doing this on Photon-builds against JDK-10). > > > > Tom > > > > On 18.04.18 12:29, Nir Lisker wrote: > > > Hi all, > > > > > > There were several discussion in GitHub about removing IDE files > > (they are > > > linked from the JBS issue [1]). At the end, I didn't see any > > decision or > > > any change. > > > > > > I would like to update the Eclipse files soon since the cleanup > [2] is > > > almost done. These files allow anyone who checks out OpenJFX to > start > > > working immediately. If these files are not provided, they would > > need to > > > manually configure them and currently that's a bit tricky. > > > > > > I would like to know the current stand on this. > > > > > > Thanks, > > > Nir > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8198795 > > > > > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8195798 > > > > > > > > > > From arunprasad.rajkumar at oracle.com Fri Apr 20 09:46:37 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Fri, 20 Apr 2018 15:16:37 +0530 Subject: [11] Review request for 8197987: Update libxslt to version 1.1.32 Message-ID: <56CBB1A4-EAD6-4F59-A916-3EF756546D3B@oracle.com> Hi Kevin, Please review the following fix for JDK-8197987 , JavaFX specific file changes: http://cr.openjdk.java.net/~arajkumar/8197987/webrev/jfx_changes Changeset (includes JFX changes & libxslt upstream changes): http://cr.openjdk.java.net/~arajkumar/8197987/webrev/libxslt.changeset Thanks, Arun From tom.schindl at bestsolution.at Fri Apr 20 17:51:01 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 20 Apr 2018 19:51:01 +0200 Subject: JDK-8198795: Remove IDE specific files from the source code repository In-Reply-To: References: <1f7d3f67-d91b-51df-2ae6-a47898d00010@bestsolution.at> <68e85083-e080-6027-54f6-5840ac919efe@bestsolution.at> Message-ID: Hi On 19.04.18 23:26, Nir Lisker wrote: > So you're adding read edges in the module-info files via "requires". I > didn't do this because these files are shared and we can't have 2 > versions of them. Yes as a temporary workaround. This way I could launch the JUnit-Tests! > I added the read edges via "--add-reads" in the .classpath files. This > way Eclipse solves its own problems without external changes. However, > since Eclipse modular support is still in progress, it's impossible to > create a valid run configuration with these modules. There are several > bugs being tracked regarding this approach (I can dig them up if you're > interested). Right hence I used the static trickery! If you CC me on the tickets I can bug the JDT-Team a bit to get them sorted out ;-) Most of the problems are anyways because of the logging stuff. I anyways wonder what the proposed setup for JUnit-Tests is in a JPMS world. Should they really be part of the same application-module? > > Once the?java.logging?dependency is removed we will be able to simplify > our solutions and I'll post my .classpaths.? > Right this is the biggest blocker! > Well until someone proofs that those setups can be generated I > think?should maintain them. > > > If no one disagrees by the time?java.logging is removed I'll file an > issue to update the Eclipse files. > Yes please do so. Can you share yours? As I said with my "requires static" trick I can run JUnit-Tests, ... from within my Eclipse Photon install (install is the wrong term because I'm running inside an Inner-Eclipse with JDT from master check out!) > Dialog: see?https://bugs.eclipse.org/bugs/show_bug.cgi?id=532850 > > > > I assume it's the "The blank final field dialog may not have > been?initialized" error. It doesn't stop the building at least, unlike > the module stuff. > Right. As you can see in the bug-report this is an edge case for compilers. Tom From kevin.rushforth at oracle.com Fri Apr 20 18:14:18 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Apr 2018 11:14:18 -0700 Subject: [11] Review request: 8202036: Update OpenJFX license files to match OpenJDK Message-ID: Phil, Please review the following simple patch to update the OpenJFX license files to match the JDK project (including adding two missing files). https://bugs.openjdk.java.net/browse/JDK-8202036 http://cr.openjdk.java.net/~kcr/8202036/webrev/ Thanks. -- Kevin From philip.race at oracle.com Fri Apr 20 18:19:47 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 20 Apr 2018 11:19:47 -0700 Subject: [11] Review request: 8202036: Update OpenJFX license files to match OpenJDK In-Reply-To: References: Message-ID: +1 -phil. On 04/20/2018 11:14 AM, Kevin Rushforth wrote: > Phil, > > Please review the following simple patch to update the OpenJFX license > files to match the JDK project (including adding two missing files). > > https://bugs.openjdk.java.net/browse/JDK-8202036 > http://cr.openjdk.java.net/~kcr/8202036/webrev/ > > Thanks. > > -- Kevin > From kevin.rushforth at oracle.com Tue Apr 24 22:43:34 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Apr 2018 15:43:34 -0700 Subject: [11] Review request: 8198329: Support FX build / test using JDK that doesn't include javafx.* modules Message-ID: Please review this RFE to add support for creating a standalone FX SDK and supporting building / running apps and tests using OpenJDK (without FX modules) + the FX standalone SDK. https://bugs.openjdk.java.net/browse/JDK-8198329 http://cr.openjdk.java.net/~kcr/8198329/webrev.00/ Details are in JBS. -- Kevin From sverre.moe at gmail.com Thu Apr 26 19:35:39 2018 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 26 Apr 2018 21:35:39 +0200 Subject: JavaFX dialog window size regression Message-ID: I filed a bug report a while back. Since I didn't have access I could not comment or update in that issue. https://bugs.openjdk.java.net/browse/JDK-8179073 With Java 9, a JavaFX dialogs got tiny and did not size up to its content. This worked fine when I was running JDK 9 build 161, but after JDK 9 build 165 the dialog window did not size up to show any of its content. The code exampled I provided with that bug report still produces a tiny dialog window with both jdk-9.0.4 and jdk-10.0.1 Setting the Dialog size to fixed width/height does not work, but if with setResizable(true) the Dialog gets its full size. It has been a while since I have used Java 9. Today I got the same problem while trying to exit SceneBuilder 9 downloaded from Gluon. I was wondering if I should re-create this bug report on the GitHub OpenJFX repository? From sebastien.deries at gmail.com Fri Apr 27 13:33:01 2018 From: sebastien.deries at gmail.com (sebastien deries) Date: Fri, 27 Apr 2018 15:33:01 +0200 Subject: linux separate screen configuration issue Message-ID: Greetings, I develop an application on linux on a Red Hat 6.8 x64 using java 8u162 and an NVidia GPU (and its latest driver), with 2 full HD Screens. I got an issue retrieving the number of physical screens: - when the X server is in extended desktop mode (2 physical screens, but a single logical one from 0 to 3840 pixels), Screen.getScreens() returns 2 Screen (which is normal) - When the X server is in separate desktop mode (2 physical screens and 2 logical screens from 0 to 1920 pixels), Screen.getScreens() returns 1 Screen ==> is this normal or a bug? I compared the JavaFX API to the AWT API: GraphicsEnvironment env = GraphicsEnvironment.getLocalGraphicsEnvironment(); GraphicsDevice[] gdev = env.getScreenDevices(); AWT returns 2 screen devices in both configuration mode. I Also checked on java 9 and java 10 using a ubuntu x64 machine and got the same issue with JavaFX. I tried debugging this and it seems that the issue is in libglass.so in native code. What do you think about this ? Thank you for your help. Regards Sebastien Here is the code that reproduces the issue: public class ScreenTest extends Application { private static final int SIZE = 1600; private final AnchorPane root = new AnchorPane(); @Override public void start(Stage primaryStage) throws Exception { root.backgroundProperty().set(new Background(new BackgroundFill(Color.BEIGE, null, null))); Scene scene = new Scene(root, SIZE, SIZE); primaryStage.show(); Screen.getScreens().forEach(screen -> System.out.println("JAVAFX :" + screen)); GraphicsEnvironment env = GraphicsEnvironment.getLocalGraphicsEnvironment(); GraphicsDevice[] gdev = env.getScreenDevices(); for (GraphicsDevice d : gdev) { System.out.println("AWT:" + d); } } public static void main(String... strings) { launch(strings); } } here is the X11 Xorg.conf: Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" 0 0 Screen 1 "Screen1" RightOf "Screen0" InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Mouse0" "CorePointer" Option "Xinerama" "0" EndSection Section "Files" EndSection Section "InputDevice" # generated from default Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/psaux" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" # generated from default Identifier "Keyboard0" Driver "kbd" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Unknown" ModelName "CMN" HorizSync 53.0 - 66.0 VertRefresh 48.0 - 60.0 Option "DPMS" EndSection Section "Monitor" Identifier "Monitor1" VendorName "Unknown" ModelName "DELL C7017T" HorizSync 30.0 - 83.0 VertRefresh 56.0 - 76.0 EndSection Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "Quadro K3100M" BusID "PCI:1:0:0" Screen 0 EndSection Section "Device" Identifier "Device1" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "Quadro K3100M" BusID "PCI:1:0:0" Screen 1 EndSection From nlisker at gmail.com Fri Apr 27 19:36:15 2018 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 27 Apr 2018 22:36:15 +0300 Subject: JDK-8195974: Replace use of java.util.logging in javafx with System logger Message-ID: Hi Murali, Can you have a look at https://bugs.openjdk.java.net/browse/JDK-8195974 please? There are some usages of j.u.l in the web module I'd like your opinion on. I'm not familiar with the intent of these pieces of code and would like to know what the options are for advancing with this issue on that front. Thanks, Nir From johan.vos at gluonhq.com Sun Apr 29 17:05:51 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 29 Apr 2018 17:05:51 +0000 Subject: native libs in modules Message-ID: Now that the OpenJFX SDK that works with Java 11 is about to be released in EA, we should think about releasing the modules. In case you download the OpenJFX SDK, running an app goes like java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app If you use gradle or maven, the same should be achieved using e.g. dependencies { compile 'javafx:javafx.controls:11.0.0' } (ignore the naming and versioning for now) This will download the javafx controls module and its dependencies from e.g. maven central. The javafx controls module info declares a requires entry for javafx.base and javafx.graphics so those will be downloaded. The question is how the native libs should be downloaded. It is possible to bundle the native libs with the modules, but there are a number of options for dealing with platform-specific libraries: 1. javafx.graphics contains all native libraries for all platforms. 2. a generic javafx.graphics module containing java code only, plus N platform-specific modules (or jar) containing the native code. An example of how this is used is ND4J: https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j-native/1.0.0-SNAPSHOT/ To make it more complex, there are a number of options for e.g. prims leading to a number of native libs. Do we want to include all relevant options for all platforms? - Johan From tbee at tbee.org Sun Apr 29 18:25:02 2018 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 29 Apr 2018 20:25:02 +0200 Subject: WaitForPaintPulse Message-ID: Is there a way in J9+ to wait for a paint pulse? I'm having problems getting my unit tests stable. Tom From philip.race at oracle.com Sun Apr 29 23:19:10 2018 From: philip.race at oracle.com (Philip Race) Date: Sun, 29 Apr 2018 16:19:10 -0700 Subject: native libs in modules In-Reply-To: References: Message-ID: <5AE652EE.8080606@oracle.com> On 4/29/18, 10:05 AM, Johan Vos wrote: > Now that the OpenJFX SDK that works with Java 11 is about to be released in > EA, we should think about releasing the modules. > > In case you download the OpenJFX SDK, running an app goes like > java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app > > If you use gradle or maven, the same should be achieved using e.g. > dependencies { > compile 'javafx:javafx.controls:11.0.0' > } > > (ignore the naming and versioning for now) > > This will download the javafx controls module and its dependencies from > e.g. maven central. The javafx controls module info declares a requires > entry for javafx.base and javafx.graphics so those will be downloaded. > > The question is how the native libs should be downloaded. It is possible to > bundle the native libs with the modules, but there are a number of options > for dealing with platform-specific libraries: > > 1. javafx.graphics contains all native libraries for all platforms. > 2. a generic javafx.graphics module containing java code only, plus N > platform-specific modules (or jar) containing the native code. An example > of how this is used is ND4J: > https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j-native/1.0.0-SNAPSHOT/ The java code is platform-specific too .. so I don't see how #1 would work and #2 would seem to require some large amount of work and I don't think will work either because you can't split packages acrosss modules which is what it would probably mean. -phil. > > To make it more complex, there are a number of options for e.g. prims > leading to a number of native libs. Do we want to include all relevant > options for all platforms? > > - Johan From paulrussell70 at gmail.com Mon Apr 30 15:07:42 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Mon, 30 Apr 2018 16:07:42 +0100 Subject: native libs in modules Message-ID: >If you use gradle or maven, the same should be achieved using e.g. >dependencies { > compile 'javafx:javafx.controls:11.0.0' >} So does this mean there a plan to offer this as pure Maven build - or will it require Gradle? If pure Maven, are the native libs going to be packaged inside a JAR file? Best, Paul On 30 April 2018 at 13:00, wrote: > Send openjfx-dev mailing list submissions to > openjfx-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > or, via email, send a message with subject or body 'help' to > openjfx-dev-request at openjdk.java.net > > You can reach the person managing the list at > openjfx-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openjfx-dev digest..." > > > Today's Topics: > > 1. native libs in modules (Johan Vos) > 2. WaitForPaintPulse (Tom Eugelink) > 3. Re: native libs in modules (Philip Race) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 29 Apr 2018 17:05:51 +0000 > From: Johan Vos > To: "openjfx-dev at openjdk.java.net List" > Subject: native libs in modules > Message-ID: > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Now that the OpenJFX SDK that works with Java 11 is about to be released in > EA, we should think about releasing the modules. > > In case you download the OpenJFX SDK, running an app goes like > java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app > > If you use gradle or maven, the same should be achieved using e.g. > dependencies { > compile 'javafx:javafx.controls:11.0.0' > } > > (ignore the naming and versioning for now) > > This will download the javafx controls module and its dependencies from > e.g. maven central. The javafx controls module info declares a requires > entry for javafx.base and javafx.graphics so those will be downloaded. > > The question is how the native libs should be downloaded. It is possible to > bundle the native libs with the modules, but there are a number of options > for dealing with platform-specific libraries: > > 1. javafx.graphics contains all native libraries for all platforms. > 2. a generic javafx.graphics module containing java code only, plus N > platform-specific modules (or jar) containing the native code. An example > of how this is used is ND4J: > https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j- > native/1.0.0-SNAPSHOT/ > > To make it more complex, there are a number of options for e.g. prims > leading to a number of native libs. Do we want to include all relevant > options for all platforms? > > - Johan > > > ------------------------------ > > Message: 2 > Date: Sun, 29 Apr 2018 20:25:02 +0200 > From: Tom Eugelink > To: openjfx-dev at openjdk.java.net > Subject: WaitForPaintPulse > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > Is there a way in J9+ to wait for a paint pulse? I'm having problems > getting my unit tests stable. > > Tom > > > > > ------------------------------ > > Message: 3 > Date: Sun, 29 Apr 2018 16:19:10 -0700 > From: Philip Race > To: Johan Vos > Cc: "openjfx-dev at openjdk.java.net List" > Subject: Re: native libs in modules > Message-ID: <5AE652EE.8080606 at oracle.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > > On 4/29/18, 10:05 AM, Johan Vos wrote: > > Now that the OpenJFX SDK that works with Java 11 is about to be released > in > > EA, we should think about releasing the modules. > > > > In case you download the OpenJFX SDK, running an app goes like > > java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app > > > > If you use gradle or maven, the same should be achieved using e.g. > > dependencies { > > compile 'javafx:javafx.controls:11.0.0' > > } > > > > (ignore the naming and versioning for now) > > > > This will download the javafx controls module and its dependencies from > > e.g. maven central. The javafx controls module info declares a requires > > entry for javafx.base and javafx.graphics so those will be downloaded. > > > > The question is how the native libs should be downloaded. It is possible > to > > bundle the native libs with the modules, but there are a number of > options > > for dealing with platform-specific libraries: > > > > 1. javafx.graphics contains all native libraries for all platforms. > > 2. a generic javafx.graphics module containing java code only, plus N > > platform-specific modules (or jar) containing the native code. An example > > of how this is used is ND4J: > > https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j- > native/1.0.0-SNAPSHOT/ > > The java code is platform-specific too .. so I don't see how #1 would > work and > #2 would seem to require some large amount of work and I don't think will > work either because you can't split packages acrosss modules which is > what it > would probably mean. > > -phil. > > > > To make it more complex, there are a number of options for e.g. prims > > leading to a number of native libs. Do we want to include all relevant > > options for all platforms? > > > > - Johan > > > End of openjfx-dev Digest, Vol 77, Issue 28 > ******************************************* > From michael.dever at icloud.com Mon Apr 30 15:12:44 2018 From: michael.dever at icloud.com (Michael Dever) Date: Mon, 30 Apr 2018 11:12:44 -0400 Subject: native libs in modules In-Reply-To: References: Message-ID: <327AB91A-4D1F-4C5A-8F0B-06B770F08520@icloud.com> What IDE are you all using. Clearly, it can't be Netbeans. That's still stuck on Java 8. On Apr 29, 2018, at 1:05 PM, Johan Vos wrote: Now that the OpenJFX SDK that works with Java 11 is about to be released in EA, we should think about releasing the modules. In case you download the OpenJFX SDK, running an app goes like java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app If you use gradle or maven, the same should be achieved using e.g. dependencies { compile 'javafx:javafx.controls:11.0.0' } (ignore the naming and versioning for now) This will download the javafx controls module and its dependencies from e.g. maven central. The javafx controls module info declares a requires entry for javafx.base and javafx.graphics so those will be downloaded. The question is how the native libs should be downloaded. It is possible to bundle the native libs with the modules, but there are a number of options for dealing with platform-specific libraries: 1. javafx.graphics contains all native libraries for all platforms. 2. a generic javafx.graphics module containing java code only, plus N platform-specific modules (or jar) containing the native code. An example of how this is used is ND4J: https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j-native/1.0.0-SNAPSHOT/ To make it more complex, there are a number of options for e.g. prims leading to a number of native libs. Do we want to include all relevant options for all platforms? - Johan From kevin.rushforth at oracle.com Mon Apr 30 15:29:57 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 30 Apr 2018 08:29:57 -0700 Subject: native libs in modules In-Reply-To: References: Message-ID: <6ee8a8f8-0f15-8c05-ab9a-9f53625123c5@oracle.com> Either way I suspect the native libs will need to be packaged in a jar file. As Phil mentions, there are per-platform .class files as well as per-platform native libraries. One thing to note is that unlike the JDK build, all class files for Windows, Linux, and Mac are set up to be built (but not shipped) on all three platforms, so it might be possible to create a jar file that would be the same on all three platforms. I don't know how feasible it would be or whether that the right direction to take or not. This will need some more thought and discussion. How does SWT handle it? In our build.gradle file we refer to the actual platform-specific jar files (which is really just a zip file with another .jar that has the class files, plus the native libraries), so I don't know how an application using Maven would refer to SWT. -- Kevin On 4/30/2018 8:07 AM, Paul Ray Russell wrote: > >If you use gradle or maven, the same should be achieved using e.g. >> dependencies { >> compile 'javafx:javafx.controls:11.0.0' >> } > So does this mean there a plan to offer this as pure Maven build - or will > it require Gradle? If pure Maven, are the native libs going to be packaged > inside a JAR file? > > Best, > Paul > > > On 30 April 2018 at 13:00, wrote: > >> Send openjfx-dev mailing list submissions to >> openjfx-dev at openjdk.java.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev >> or, via email, send a message with subject or body 'help' to >> openjfx-dev-request at openjdk.java.net >> >> You can reach the person managing the list at >> openjfx-dev-owner at openjdk.java.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of openjfx-dev digest..." >> >> >> Today's Topics: >> >> 1. native libs in modules (Johan Vos) >> 2. WaitForPaintPulse (Tom Eugelink) >> 3. Re: native libs in modules (Philip Race) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sun, 29 Apr 2018 17:05:51 +0000 >> From: Johan Vos >> To: "openjfx-dev at openjdk.java.net List" >> Subject: native libs in modules >> Message-ID: >> > gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> Now that the OpenJFX SDK that works with Java 11 is about to be released in >> EA, we should think about releasing the modules. >> >> In case you download the OpenJFX SDK, running an app goes like >> java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app >> >> If you use gradle or maven, the same should be achieved using e.g. >> dependencies { >> compile 'javafx:javafx.controls:11.0.0' >> } >> >> (ignore the naming and versioning for now) >> >> This will download the javafx controls module and its dependencies from >> e.g. maven central. The javafx controls module info declares a requires >> entry for javafx.base and javafx.graphics so those will be downloaded. >> >> The question is how the native libs should be downloaded. It is possible to >> bundle the native libs with the modules, but there are a number of options >> for dealing with platform-specific libraries: >> >> 1. javafx.graphics contains all native libraries for all platforms. >> 2. a generic javafx.graphics module containing java code only, plus N >> platform-specific modules (or jar) containing the native code. An example >> of how this is used is ND4J: >> https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j- >> native/1.0.0-SNAPSHOT/ >> >> To make it more complex, there are a number of options for e.g. prims >> leading to a number of native libs. Do we want to include all relevant >> options for all platforms? >> >> - Johan >> >> >> ------------------------------ >> >> Message: 2 >> Date: Sun, 29 Apr 2018 20:25:02 +0200 >> From: Tom Eugelink >> To: openjfx-dev at openjdk.java.net >> Subject: WaitForPaintPulse >> Message-ID: >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> Is there a way in J9+ to wait for a paint pulse? I'm having problems >> getting my unit tests stable. >> >> Tom >> >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Sun, 29 Apr 2018 16:19:10 -0700 >> From: Philip Race >> To: Johan Vos >> Cc: "openjfx-dev at openjdk.java.net List" >> Subject: Re: native libs in modules >> Message-ID: <5AE652EE.8080606 at oracle.com> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> >> >> On 4/29/18, 10:05 AM, Johan Vos wrote: >>> Now that the OpenJFX SDK that works with Java 11 is about to be released >> in >>> EA, we should think about releasing the modules. >>> >>> In case you download the OpenJFX SDK, running an app goes like >>> java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app >>> >>> If you use gradle or maven, the same should be achieved using e.g. >>> dependencies { >>> compile 'javafx:javafx.controls:11.0.0' >>> } >>> >>> (ignore the naming and versioning for now) >>> >>> This will download the javafx controls module and its dependencies from >>> e.g. maven central. The javafx controls module info declares a requires >>> entry for javafx.base and javafx.graphics so those will be downloaded. >>> >>> The question is how the native libs should be downloaded. It is possible >> to >>> bundle the native libs with the modules, but there are a number of >> options >>> for dealing with platform-specific libraries: >>> >>> 1. javafx.graphics contains all native libraries for all platforms. >>> 2. a generic javafx.graphics module containing java code only, plus N >>> platform-specific modules (or jar) containing the native code. An example >>> of how this is used is ND4J: >>> https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j- >> native/1.0.0-SNAPSHOT/ >> >> The java code is platform-specific too .. so I don't see how #1 would >> work and >> #2 would seem to require some large amount of work and I don't think will >> work either because you can't split packages acrosss modules which is >> what it >> would probably mean. >> >> -phil. >>> To make it more complex, there are a number of options for e.g. prims >>> leading to a number of native libs. Do we want to include all relevant >>> options for all platforms? >>> >>> - Johan >> >> End of openjfx-dev Digest, Vol 77, Issue 28 >> ******************************************* >> From cenbe at kolabnow.com Mon Apr 30 15:54:43 2018 From: cenbe at kolabnow.com (Glenn Holmer) Date: Mon, 30 Apr 2018 10:54:43 -0500 Subject: native libs in modules In-Reply-To: <327AB91A-4D1F-4C5A-8F0B-06B770F08520@icloud.com> References: <327AB91A-4D1F-4C5A-8F0B-06B770F08520@icloud.com> Message-ID: <960d19aa-9915-5620-86aa-25a9b84756cd@kolabnow.com> On 04/30/2018 10:12 AM, Michael Dever wrote: > What IDE are you all using. > Clearly, it can't be Netbeans. > That's still stuck on Java 8. http://netbeans.apache.org/download/index.html -- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." From mp at jugs.org Mon Apr 30 15:58:50 2018 From: mp at jugs.org (Michael Paus) Date: Mon, 30 Apr 2018 17:58:50 +0200 Subject: native libs in modules In-Reply-To: <6ee8a8f8-0f15-8c05-ab9a-9f53625123c5@oracle.com> References: <6ee8a8f8-0f15-8c05-ab9a-9f53625123c5@oracle.com> Message-ID: <6b90031c-3738-cda5-5195-a6e85d1f479f@jugs.org> Am 30.04.18 um 17:29 schrieb Kevin Rushforth: > One thing to note is that unlike the JDK build, all class files for > Windows, Linux, and Mac are set up to be built (but not shipped) on > all three platforms, so it might be possible to create a jar file that > would be the same on all three platforms. I don't know how feasible it > would be or whether that the right direction to take or not. If possible, I would like to see a change in this policy to not ship certain fragments of the build. Especially I would like to have the possibility to use a JavaFX based on OpenGL on Windows too. This would make Java truly cross-platform and might offer a lot of possibilities for better integration of external graphics tools like for example tools based on JOGL. It might also offer the possibility to support WebGL in the WebView in the future so that this gap can be closed too. Am I just dreaming? What do others think? Michael From johan.vos at gluonhq.com Mon Apr 30 16:02:48 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 30 Apr 2018 16:02:48 +0000 Subject: native libs in modules In-Reply-To: <6ee8a8f8-0f15-8c05-ab9a-9f53625123c5@oracle.com> References: <6ee8a8f8-0f15-8c05-ab9a-9f53625123c5@oracle.com> Message-ID: We currently already have classes in distributions that are not relevant to that specific distribution. The com.sun.javafx.iio.ios.IosImageLoader is part of the Linux distribution, for example (it is directly referenced from the ImageLoader although it could be invoked via Reflection). But it is even more complicated than that. We have * java code for a specific platform (mac/linux/win/others) * native code for a specific platform (mac/linux/win/others) * java and native code for specific configurations (e.g. prism pipelines) The latter is sometimes related to platforms (e.g. D3D on windows only) and sometimes not. This allows for a very granular configuration, where only the relevant code is downloaded (e.g. prism-es2 for linux). In many cases though, an umbrella artefact is created that contains enough information for maven and gradle to download the correct dependencies then. I'm not sure I understand the question about platform-specific jar files, but typically this is done using classifiers, e.g. javafx javafx.graphics 11.0.0 linux-x86 or with gradle: compile 'javafx:javafx.graphics:11.0.0:linux-x86' The specified module can contain the native code + platform-specific java class files (in a platform-specific package in order not to have 2 modules with the same package) - Johan On Mon, Apr 30, 2018 at 5:40 PM Kevin Rushforth wrote: > Either way I suspect the native libs will need to be packaged in a jar > file. > > As Phil mentions, there are per-platform .class files as well as > per-platform native libraries. One thing to note is that unlike the JDK > build, all class files for Windows, Linux, and Mac are set up to be > built (but not shipped) on all three platforms, so it might be possible > to create a jar file that would be the same on all three platforms. I > don't know how feasible it would be or whether that the right direction > to take or not. > > This will need some more thought and discussion. How does SWT handle it? > In our build.gradle file we refer to the actual platform-specific jar > files (which is really just a zip file with another .jar that has the > class files, plus the native libraries), so I don't know how an > application using Maven would refer to SWT. > > -- Kevin > > > On 4/30/2018 8:07 AM, Paul Ray Russell wrote: > > >If you use gradle or maven, the same should be achieved using e.g. > >> dependencies { > >> compile 'javafx:javafx.controls:11.0.0' > >> } > > So does this mean there a plan to offer this as pure Maven build - or > will > > it require Gradle? If pure Maven, are the native libs going to be > packaged > > inside a JAR file? > > > > Best, > > Paul > > > > > > On 30 April 2018 at 13:00, wrote: > > > >> Send openjfx-dev mailing list submissions to > >> openjfx-dev at openjdk.java.net > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > >> or, via email, send a message with subject or body 'help' to > >> openjfx-dev-request at openjdk.java.net > >> > >> You can reach the person managing the list at > >> openjfx-dev-owner at openjdk.java.net > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of openjfx-dev digest..." > >> > >> > >> Today's Topics: > >> > >> 1. native libs in modules (Johan Vos) > >> 2. WaitForPaintPulse (Tom Eugelink) > >> 3. Re: native libs in modules (Philip Race) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Sun, 29 Apr 2018 17:05:51 +0000 > >> From: Johan Vos > >> To: "openjfx-dev at openjdk.java.net List" > >> Subject: native libs in modules > >> Message-ID: > >> >> gmail.com> > >> Content-Type: text/plain; charset="UTF-8" > >> > >> Now that the OpenJFX SDK that works with Java 11 is about to be > released in > >> EA, we should think about releasing the modules. > >> > >> In case you download the OpenJFX SDK, running an app goes like > >> java --module-path $OPENJFXSDK/lib --add-modules javafx.controls > your.app > >> > >> If you use gradle or maven, the same should be achieved using e.g. > >> dependencies { > >> compile 'javafx:javafx.controls:11.0.0' > >> } > >> > >> (ignore the naming and versioning for now) > >> > >> This will download the javafx controls module and its dependencies from > >> e.g. maven central. The javafx controls module info declares a requires > >> entry for javafx.base and javafx.graphics so those will be downloaded. > >> > >> The question is how the native libs should be downloaded. It is > possible to > >> bundle the native libs with the modules, but there are a number of > options > >> for dealing with platform-specific libraries: > >> > >> 1. javafx.graphics contains all native libraries for all platforms. > >> 2. a generic javafx.graphics module containing java code only, plus N > >> platform-specific modules (or jar) containing the native code. An > example > >> of how this is used is ND4J: > >> https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j- > >> native/1.0.0-SNAPSHOT/ > >> > >> To make it more complex, there are a number of options for e.g. prims > >> leading to a number of native libs. Do we want to include all relevant > >> options for all platforms? > >> > >> - Johan > >> > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Sun, 29 Apr 2018 20:25:02 +0200 > >> From: Tom Eugelink > >> To: openjfx-dev at openjdk.java.net > >> Subject: WaitForPaintPulse > >> Message-ID: > >> Content-Type: text/plain; charset=utf-8; format=flowed > >> > >> Is there a way in J9+ to wait for a paint pulse? I'm having problems > >> getting my unit tests stable. > >> > >> Tom > >> > >> > >> > >> > >> ------------------------------ > >> > >> Message: 3 > >> Date: Sun, 29 Apr 2018 16:19:10 -0700 > >> From: Philip Race > >> To: Johan Vos > >> Cc: "openjfx-dev at openjdk.java.net List" > >> Subject: Re: native libs in modules > >> Message-ID: <5AE652EE.8080606 at oracle.com> > >> Content-Type: text/plain; charset=UTF-8; format=flowed > >> > >> > >> > >> On 4/29/18, 10:05 AM, Johan Vos wrote: > >>> Now that the OpenJFX SDK that works with Java 11 is about to be > released > >> in > >>> EA, we should think about releasing the modules. > >>> > >>> In case you download the OpenJFX SDK, running an app goes like > >>> java --module-path $OPENJFXSDK/lib --add-modules javafx.controls > your.app > >>> > >>> If you use gradle or maven, the same should be achieved using e.g. > >>> dependencies { > >>> compile 'javafx:javafx.controls:11.0.0' > >>> } > >>> > >>> (ignore the naming and versioning for now) > >>> > >>> This will download the javafx controls module and its dependencies from > >>> e.g. maven central. The javafx controls module info declares a requires > >>> entry for javafx.base and javafx.graphics so those will be downloaded. > >>> > >>> The question is how the native libs should be downloaded. It is > possible > >> to > >>> bundle the native libs with the modules, but there are a number of > >> options > >>> for dealing with platform-specific libraries: > >>> > >>> 1. javafx.graphics contains all native libraries for all platforms. > >>> 2. a generic javafx.graphics module containing java code only, plus N > >>> platform-specific modules (or jar) containing the native code. An > example > >>> of how this is used is ND4J: > >>> https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j- > >> native/1.0.0-SNAPSHOT/ > >> > >> The java code is platform-specific too .. so I don't see how #1 would > >> work and > >> #2 would seem to require some large amount of work and I don't think > will > >> work either because you can't split packages acrosss modules which is > >> what it > >> would probably mean. > >> > >> -phil. > >>> To make it more complex, there are a number of options for e.g. prims > >>> leading to a number of native libs. Do we want to include all relevant > >>> options for all platforms? > >>> > >>> - Johan > >> > >> End of openjfx-dev Digest, Vol 77, Issue 28 > >> ******************************************* > >> > > From paulrussell70 at gmail.com Mon Apr 30 16:44:35 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Mon, 30 Apr 2018 17:44:35 +0100 Subject: native libs in modules Message-ID: >I'm not sure I understand the question about platform-specific jar files, Last time I worked on native specifics (which was to package up RXTX dlls for different OSs / in 64/32 bit) The easiest solution for pure Maven builds seemed to be, to package DLLs inside a jar. We then used a profile to control which DLL's were grabbed in different cases. And surely for this specific case, it would be better to split the native specifics into separate jars per OS to avoid a huge cross-OS download? From kevin.rushforth at oracle.com Mon Apr 30 22:26:38 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 30 Apr 2018 15:26:38 -0700 Subject: [8u] Review request: 8201619: [TESTBUG] Bad HG merge causes some web tests to be skipped by mistake Message-ID: Murali, Please review this simple test-only fix to correct a bad merge: https://bugs.openjdk.java.net/browse/JDK-8201619 http://cr.openjdk.java.net/~kcr/8201619/webrev/ This only affects 8u-dev, since the merge in questions was done when merging changes from 8u171 into 8u172. -- Kevin From kevin.rushforth at oracle.com Mon Apr 30 23:07:26 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 30 Apr 2018 16:07:26 -0700 Subject: native libs in modules In-Reply-To: References: Message-ID: <5fe89af2-5f06-b0e8-e50e-1533e54ac864@oracle.com> The native libraries are quite large -- especially jfxwebkit -- and it does seem better to have per-platform jar files, at least for the native libraries. The following modules could be platform-independent since they have no natives: javafx.base javafx.controls javafx.fxml javafx.swing We would just need to test that the set of modular jar files for each platform are the same, and then pick one (Linux?) to use for generating the platform-independent jar files. The following modules have native libraries: javafx.graphics (*) javafx.media (*) javafx.web (*) - also has some differences in the set of class files that are included depending on the platform So per-platform versions of the above would be needed to accommodate the different native libraries. If it would help, the .class files could be always included for all platforms, but there would be some additional effort to make this work. Also, it might be just as easy to have the class files and the natives in one downloaded jar file per platform, since at least the natives need to be platform-independent. I'm far from a maven expert, though, so I don't really know for sure which path is easier. -- Kevin On 4/30/2018 9:44 AM, Paul Ray Russell wrote: > >I'm not sure I understand the question about platform-specific jar files, > > Last time I worked on native specifics (which was to package up RXTX dlls > for different OSs / in 64/32 bit) The easiest solution for pure Maven > builds seemed to be, to package DLLs inside a jar. We then used a profile > to control which DLL's were grabbed in different cases. And surely for this > specific case, it would be better to split the native specifics into > separate jars per OS to avoid a huge cross-OS download?