From rajath.kamath at oracle.com Thu Mar 1 11:09:03 2018 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Thu, 1 Mar 2018 03:09:03 -0800 (PST) Subject: [11] Review Request - JDK-8193185: [Windows] System test failures in scene size tests with HiDPI Message-ID: <7b14c572-5b72-4774-9bb7-6e74d4d7b743@default> Hi Kevin, Ambarish, Please review this fix for ensuring scene size tests pass with fractional scale factor set as well. JBS : https://bugs.openjdk.java.net/browse/JDK-8193185 WebRev : http://cr.openjdk.java.net/~rkamath/8193185/webrev.00/ Thanks, Rajath From murali.billa at oracle.com Thu Mar 1 16:14:22 2018 From: murali.billa at oracle.com (Murali Billa) Date: Thu, 1 Mar 2018 08:14:22 -0800 (PST) Subject: [11] Review request for 8198609: [TestBug] Some of the system tests need a message about exceptions being expected Message-ID: ? Hi Kevin, Please review the below simple fix. JIRA:? https://bugs.openjdk.java.net/browse/JDK-8198609 ? webrev: http://cr.openjdk.java.net/~mbilla/8198609/webrev.00/ Thanks, Murali From kevin.rushforth at oracle.com Fri Mar 2 00:43:01 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 01 Mar 2018 16:43:01 -0800 Subject: [11] Review request: 8196297: Remove obsolete JFR logger code Message-ID: <5A989E15.5010201@oracle.com> Ambarish or Ajit, Please review the following fix to remove the obsolete JFR logger code: https://bugs.openjdk.java.net/browse/JDK-8196297 http://cr.openjdk.java.net/~kcr/8196297/webrev.00/ Thanks. -- Kevin From ambarish.rapte at oracle.com Fri Mar 2 01:19:09 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Thu, 1 Mar 2018 17:19:09 -0800 (PST) Subject: [11] RFR : JDK-8195802 : Eliminate use of jdk.internal.misc security utilities in javafx.graphics Message-ID: <31f2d347-59fb-4ec5-818b-8710502c0350@default> Hi Kevin & Ajit, Please review this fix, webrev: http://cr.openjdk.java.net/~arapte/fx/8195802/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8195802 Regards, Ambarish From kevin.rushforth at oracle.com Fri Mar 2 16:22:19 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 02 Mar 2018 08:22:19 -0800 Subject: [11] Review request: 8196198: Remove obsolete apps/experiments Message-ID: <5A997A3B.2070507@oracle.com> Ajit or Phil, Please review the following fix to remove the obsolete apps/experiments from the OpenJFX repo: https://bugs.openjdk.java.net/browse/JDK-8196198 http://cr.openjdk.java.net/~kcr/8196198/ There is no reason to keep them around in jfx mainline (they can still be found in openjfx/10 as well as being in the hg history). -- Kevin From kevin.rushforth at oracle.com Fri Mar 2 16:24:39 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 02 Mar 2018 08:24:39 -0800 Subject: [11] Review request: 8196198: Remove obsolete apps/experiments In-Reply-To: <5A997A3B.2070507@oracle.com> References: <5A997A3B.2070507@oracle.com> Message-ID: <5A997AC7.5030206@oracle.com> Note that the webrev just contains the one modified file. As explained in JBS I didn't see the point of posting a 30 Mbyte webrev consisting of 485 removed files. If you want to apply the actual patch, then you can download the .patch.gz file. -- Kevin Kevin Rushforth wrote: > Ajit or Phil, > > Please review the following fix to remove the obsolete > apps/experiments from the OpenJFX repo: > > https://bugs.openjdk.java.net/browse/JDK-8196198 > http://cr.openjdk.java.net/~kcr/8196198/ > > There is no reason to keep them around in jfx mainline (they can still > be found in openjfx/10 as well as being in the hg history). > > -- Kevin > From kevin.rushforth at oracle.com Fri Mar 2 17:12:15 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 02 Mar 2018 09:12:15 -0800 Subject: Removal of apps/scenebuilder from OpenJFX repo Message-ID: <5A9985EF.5000701@oracle.com> I filed the following JBS isuse to remova the SceneBuilder sources from the OpenJFX repo. https://bugs.openjdk.java.net/browse/JDK-8198961 As mentioned in the Description of that issue, the OpenJFX repo contains the source code for a no-longer-maintained version of the SceneBuilder tool. Active development on SceneBuilder in the OpenJFX repo was stopped over three years ago. Since that time, the only changes have been either jigsaw-related changes to keep it buildable and runnable, or global changes that happened to touch some of the files in apps/scenebuilder. A fork of SceneBuilder is maintained by Gluon, so anyone wanting to get the latest SceneBuilder should go there. Before I proceed, I wanted to poll the list to see whether anyone has a concern with this. I don't plan to take any action for at least a week. -- Kevin From mp at jugs.org Fri Mar 2 17:20:11 2018 From: mp at jugs.org (Michael Paus) Date: Fri, 2 Mar 2018 18:20:11 +0100 Subject: Removal of apps/scenebuilder from OpenJFX repo In-Reply-To: <5A9985EF.5000701@oracle.com> References: <5A9985EF.5000701@oracle.com> Message-ID: I? think it's a good idea to remove all unnecessary, outdated or dead code from the repo. That makes the build faster and also makes it easier to get an overview of what actually belongs to the JavaFX core. --Michael Am 02.03.18 um 18:12 schrieb Kevin Rushforth: > I filed the following JBS isuse to remova the SceneBuilder sources > from the OpenJFX repo. > > https://bugs.openjdk.java.net/browse/JDK-8198961 > > As mentioned in the Description of that issue, the OpenJFX repo > contains the source code for a no-longer-maintained version of the > SceneBuilder tool. Active development on SceneBuilder in the OpenJFX > repo was stopped over three years ago. Since that time, the only > changes have been either jigsaw-related changes to keep it buildable > and runnable, or global changes that happened to touch some of the > files in apps/scenebuilder. > > A fork of SceneBuilder is maintained by Gluon, so anyone wanting to > get the latest SceneBuilder should go there. > > Before I proceed, I wanted to poll the list to see whether anyone has > a concern with this. I don't plan to take any action for at least a week. > > -- Kevin > From javalists at cbfiddle.com Fri Mar 2 20:06:03 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 2 Mar 2018 12:06:03 -0800 Subject: JDK-8147501 [packager] Add arguments for splash screen Message-ID: <1880DAFE-FD36-4107-8D3D-525B1A485607@cbfiddle.com> I am writing to raise awareness of this bug. Splash screens are a supported feature of Java, but there is no way to use this feature when using the packager to create a bundled application (at least when using the ant tasks, which is how I use the packager). This problem also raises related issues: There are two ways supported by Java for specifying a splash screen, one using a command line argument (-splash) and one using a Manifest file attribute. Both of these ways are blocked by the packager. The command line argument approach is blocked apparently because the packager launcher ignores JVM options that it does not know about. I have to wonder why there is an extra gatekeeper here. Doesn?t the JVM already reject or ignore options it does not support? Why should some JDK developer have to maintain consistency between the launcher and the JVM? The Manifest file approach is blocked because the packager owns the Manifest file for a bundled application JAR. It apparently does not support adding attributes (even though the JAR making option does support adding attributes). Nor does it allow the Manifest to be replaced. Either or both of these options would seem reasonable. Regards, Alan [1] https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html From nlisker at gmail.com Sat Mar 3 18:35:00 2018 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 3 Mar 2018 20:35:00 +0200 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: <5A96D10B.2090301@oracle.com> References: <5A84F943.6030206@oracle.com> <5A861471.8030208@oracle.com> <5A95DAE9.9030809@oracle.com> <5A95EF0B.3030901@oracle.com> <5A96D10B.2090301@oracle.com> Message-ID: > > Accepting a PR in github does not require the *formal* process of creating > webrevs etc, but it requires discussion about the issue with reviewers of > OpenJFX. Doesn't that mean that accepting a fix into GitHub is equivalent to accepting it into OpenJFX? In that case there shouldn't be any edge cases. The only difference is that the patch delivery system is different. After a PR is accepted, the GitHub patch should be converted to an OpenJFX patch. Webrev or not webrev seems to me like a tooling issue. Having a small number of JBS bugs that are low hanging fruit will be good > to see how the flow works. I'm still not sure about all the steps. In order to submit a PR I need GitHub permissions? Can you know if I signed the OCA? - Nir On Wed, Feb 28, 2018 at 5:55 PM, Kevin Rushforth wrote: > > > Eugene created an easy one: https://bugs.openjdk.java.net/ > browse/JDK-8198795 > > I pointed out some prerequisites for doing this in JBS (and Nir expressed > concern as well), but yes, this might be a good one to start with. > > -- Kevin > > > Johan Vos wrote: > > I agree with this approach. > Having a small number of JBS bugs that are low hanging fruit will be good > to see how the flow works. > Eugene created an easy one: https://bugs.openjdk.java.net/ > browse/JDK-8198795 > > - Johan > > On Wed, Feb 28, 2018 at 9:52 AM Laurent Bourg?s > wrote: > >> Johan, >> I am following the long discussion and I mostly agree what was said. >> >> Maybe it is time to start working on github on few minor / trivial >> bugs... to test all the new process. >> >> I propose to extract few JBS bugs (small) with high ROI (agile /scrum >> approach) and create shadow copies into github issues (id, title, short >> description & JBS LINK) to be proposed to the jfx community. >> >> That would become our backlog that can be managed in a kanban board >> (github project). Moreover it would be awesome if such board would gather >> the activity of both oracle & community people on OpenJFX. >> >> Once somebody wants to work on one issue, just comment on the github >> issue and start working in your fork, make PR... >> >> Adopting this method, anybody will know publicly what's going on and it >> would reduce the risk of conflicts (code merge).... >> >> My 2 cents... >> >> Let's go on, >> "We are the champions..." >> >> Laurent >> >> >> Le 28 f?vr. 2018 9:15 AM, "Johan Vos" a ?crit : >> >> That is the difficult point indeed. >> But why would a PR to OpenJFX be rejected after it was approved in the >> github mirror? I would assume the main reason for this is because the PR >> did not what it was supposed to do. In that case, it makes sense to remove >> the commits from the github mirror as well. >> >> I think the main thing here is that we need to be very serious about >> reviewing and accepting PR's in the github mirror. Accepting a PR in >> github >> does not require the *formal* process of creating webrevs etc, but it >> requires discussion about the issue with reviewers of OpenJFX. >> We have to minimize the number of times an edge case occurs, in which the >> discussion was pro PR first, but after it got merged into "development" >> new >> arguments are brought up against the PR. >> I think it would be good to have sort of a post-mortem analysis in case >> this happens, in order to prevent it from happening again. But as I said, >> if it does happen, it probably has good reasons and in that case we have >> to >> remove it from the development branch as well. >> >> I think the more common case would be that an issue is fixed on the github >> mirror, but not yet accepted (nor rejected) in OpenJFX, so there will be >> some time lag between the PR acceptance and the integration in OpenJFX. >> But >> this should not be a problem, as long as the following scenario is the >> main >> flow: >> >> The github master branch is always synced with OpenJFX, and never gets >> modified by other commits. >> The github "development" branch is where we accept PR's, that can then be >> send upstream. Changes from "master" are regularly merged into >> "development". The moment an accepted PR makes it into OpenJFX, it will be >> synced into "master" and merged into "development" where the merge happens >> silently as there are no conflicts (since development already has this >> code). >> >> Does that make sense? >> >> - Johan >> >> On Wed, Feb 28, 2018 at 12:51 AM Kevin Rushforth < >> kevin.rushforth at oracle.com> >> wrote: >> >> > >> > >> > Nir Lisker wrote: >> > >> > Johan's thinking was to allow Committers to approve the PR on GitHub -- >> >> meaning they could be merged on GitHub before an actual Review has >> >> happened. Are you proposing to change that? >> > >> > >> > What if the PR is rejected at review? We'll end up with conflicts >> between >> > the repos. And supposed someone works on a different fix and uses the >> > rejected PR code, how will that be committed? >> > >> > >> > Good questions; maybe Johan has some thoughts as to how to mitigate >> this? >> > >> > >> > -- Kevin >> > >> > >> > >> > On Wed, Feb 28, 2018 at 12:25 AM, Kevin Rushforth < >> > kevin.rushforth at oracle.com> wrote: >> > >> >> This seems a good start in formalizing the process. It will need a >> little >> >> tweaking in a couple of areas. >> >> >> >> Regarding JBS access, even though I want to relax the requirement to >> >> become an Author (get a JBS account), it will likely end up somewhere >> >> between "an intention to contribute" and "two sponsored contributions, >> >> already reviewed and committed". Even without this, there will >> necessarily >> >> be a gap in time between "I want to work on a bug" and getting a JBS >> >> account. So there is value in encouraging people to clone the GitHub >> >> sandbox, "kick the tires", make a PR to get feedback, etc., before >> they can >> >> access JBS directly (or even while waiting for their OCA to be >> processed, >> >> but no PRs in that case). Something to take into account. >> >> >> >> Regarding review, we will need a bit more discussion on that. I like >> the >> >> idea of the PR being logged in JBS once it is ready to be reviewed. >> Johan's >> >> thinking was to allow Committers to approve the PR on GitHub -- meaning >> >> they could be merged on GitHub before an actual Review has happened. >> Are >> >> you proposing to change that? It might have some advantages, but it >> could >> >> also make it harder in other areas. I'd like to hear from Johan on >> this. >> >> This reminds me that we need to continue the discussion on the general >> >> "Review" policy, as it is relevant here. >> >> >> >> As for whether it is merged into GitHub, I don't have a strong opinion >> on >> >> that. As you say it will be pulled into the mirror anyway (along with >> >> changes from reviews happening in JBS that don't first go through the >> >> sandbox), so maybe it doesn't matter? On the other hand there might be >> >> advantages to getting it into the mainline of the sandbox early? Hard >> to >> >> say. >> >> >> >> -- Kevin >> >> >> >> >> >> Nir Lisker wrote: >> >> >> >> Iv'e given the pipeline some thought. I'm purposely ignoring current >> role >> >> names (Author, Contributor...). My suggestions: >> >> >> >> Potential contributor wants to contribute... >> >> >> >> 1. Formal process >> >> a. If the issue is not in the JBS, they submit it via bugreport. >> >> b. They send an email on the mailing list regarding the issue (a >> plan, >> >> question on how to approach etc.) >> >> c. If the above effort is "deemed worthy" (whatever that means), and >> >> they have signed the OCA, and they then they get access to JBS. If >> they've >> >> given a GitHub account, they get access to GitHub PRs. >> >> d. Discussion from the mailing list is copied/linked to the JBS >> issue. >> >> Maybe if it's their issue (step a) then the Reporter field can change >> to >> >> them. >> >> >> >> This ensures that: >> >> * There's 1 entry point. >> >> * GitHub and JBS identities are linked (GitHub identity is verified). >> >> * Being able to comment on JBS is easier - instead of requiring 2 >> commits >> >> it requires good intentions(?) >> >> * Not every person on the planet has access to JBS. >> >> >> >> 2. Work process >> >> a. They fork the GitHub repo. >> >> b. They create a PR with a 2-way link to/from JBS (similar to >> current >> >> webrevs - JBS links). >> >> c. Discussion specifically on the patch should happen in the PR >> thread. >> >> General info on the bug (affected versions etc.) still happens in JBS. >> >> d. After the patch had been reviewed, it is committed to the Oracle >> >> repo. Since GitHub mirrors Oracle I don't think it matters if the >> patch is >> >> merged into GitHub. >> >> >> >> This ensures that: >> >> * It's easier to start working because the GiutHub repo is more >> >> convenient than the Oracle repo currently. >> >> * PRs and JBS issues are mutually aware. >> >> * The submit -> review -> commit process is streamlined. >> >> >> >> We pay a synchronization price for having 2 repos and 2 bug trackers. >> >> This is what I could come up with. >> >> >> >> - Nir >> >> >> >> On Fri, Feb 16, 2018 at 1:14 AM, Kevin Rushforth < >> >> kevin.rushforth at oracle.com> wrote: >> >> >> >>> >> >>> >> >>> Johan Vos wrote: >> >>> >> >>> >> >>> >> >>> On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth < >> >>> kevin.rushforth at oracle.com> wrote: >> >>> >> >>> A global reference in JBS would indeed be very good to track back the >> >>> work in a PR to a real issue. It can also be very useful as there are >> many >> >>> existing issues in JBS that can be referred to in future work. >> >>> >> >>> The only issue I see is that in order to create an issue in JBS, you >> >>> need to have "author" status, so not everyone can do this? Given the >> idea >> >>> that developers who want to create a PR also need to sign an OCA, it >> might >> >>> make sense to somehow combine the administration? >> >>> >> >>> >> >>> I don't think we can combine this, but I hope to be able to relax the >> >>> requirements to become an Author a little. The current guidelines are >> 2 >> >>> sponsored contributions [1]. >> >>> >> >>> Pending appointment as an Author, it isn't hard to submit a bug via >> >>> http://bugreport.java.com/ . If there is a test case, it usually gets >> >>> moved to the JDK project within a day or so (and I can move them >> sooner, if >> >>> needed). The bigger bother is that you can't comment in JBS on a bug >> you >> >>> didn't create, but once the bug is there, you can work on it in GutHub >> >>> and/or send email to the list. I'll also add any comments from >> contributors >> >>> who are not yet Authors to any bug report. >> >>> >> >>> -- Kevin >> >>> >> >>> [1] http://openjdk.java.net/projects/#project-author >> >>> >> >>> >> >>> - Johan >> >>> >> >>> >> >> >> > >> >> >> From mp at jugs.org Sat Mar 3 18:49:01 2018 From: mp at jugs.org (Michael Paus) Date: Sat, 3 Mar 2018 19:49:01 +0100 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: <5A84F943.6030206@oracle.com> <5A861471.8030208@oracle.com> <5A95DAE9.9030809@oracle.com> <5A95EF0B.3030901@oracle.com> <5A96D10B.2090301@oracle.com> Message-ID: Am 03.03.18 um 19:35 schrieb Nir Lisker: > I'm still not sure about all the steps. In order to submit a PR I need > GitHub permissions? Can you know if I signed the OCA? There is a publicly available list of people which have signed the OCA here: http://www.oracle.com/technetwork/community/oca-486395.html --Michael From mike.ennen at gmail.com Sun Mar 4 09:28:53 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Sun, 4 Mar 2018 02:28:53 -0700 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: <5A84F943.6030206@oracle.com> <5A861471.8030208@oracle.com> <5A95DAE9.9030809@oracle.com> <5A95EF0B.3030901@oracle.com> <5A96D10B.2090301@oracle.com> Message-ID: In my opinion we need a bot that does a few things to automate the GitHub to OpenJFX contribution workflow. One of those things is we can, upon getting a new pull request from someone we haven't seen before, go over the OCA list and see if a username matches their Github username. If it does, the bot can comment on the PR with something containing: "This looks like your first contribution to the OpenJFX Github repository. Have you signed the OCA (Oracle Contributor Agreement) before with the username "brcolow" (name: Michael Ennen)? If so, reply with 'Yes, that is me." or if not reply with "Nope.". If we don't find their username in the OCA list we can ask basically the same question but leave out the bit with asking if they signed under their github repository. We will keep track of people that have signed it (and associate their github account info) so they only need to go through that once. I have seen this done in other github repositories (I think Microsoft uses something like this?) but can't think of them off-hand. Other things the bot will handle should be converting to a mercurial commit, generating a webrev, associating/asking for a JBS bug report, etc. I am willing to step up and write this bot. My idea would be to write it in Java and use something like AWS Lambda to have it run every X minutes or so. Alternatives are welcome...especially if there is some existing server infrastructure we could use. - Michael Ennen On Sat, Mar 3, 2018 at 11:49 AM, Michael Paus wrote: > Am 03.03.18 um 19:35 schrieb Nir Lisker: > >> I'm still not sure about all the steps. In order to submit a PR I need >> GitHub permissions? Can you know if I signed the OCA? >> > There is a publicly available list of people which have signed the OCA > here: > http://www.oracle.com/technetwork/community/oca-486395.html > --Michael > From johan.vos at gluonhq.com Sun Mar 4 20:23:35 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 04 Mar 2018 20:23:35 +0000 Subject: Repositories, AdoptOpenJDK and github In-Reply-To: References: <5A84F943.6030206@oracle.com> <5A861471.8030208@oracle.com> <5A95DAE9.9030809@oracle.com> <5A95EF0B.3030901@oracle.com> <5A96D10B.2090301@oracle.com> Message-ID: In my view, the difference between accepting a PR into GitHub versus into OpenJFX is probably mainly time-based. When there is an agreement about a PR, it can be merged in GitHub, but there are more steps required (webrev) before it can formally be pushed into OpenJFX, so the reviewer may choose to do that later (e.g. and combine a number of PR's). - Johan On Sat, Mar 3, 2018 at 7:35 PM Nir Lisker wrote: > Accepting a PR in github does not require the *formal* process of creating >> webrevs etc, but it requires discussion about the issue with reviewers of >> OpenJFX. > > > Doesn't that mean that accepting a fix into GitHub is equivalent to > accepting it into OpenJFX? In that case there shouldn't be any edge cases. > The only difference is that the patch delivery system is different. After > a PR is accepted, the GitHub patch should be converted to an OpenJFX patch. > Webrev or not webrev seems to me like a tooling issue. > > Having a small number of JBS bugs that are low hanging fruit will be good >> to see how the flow works. > > > I'm still not sure about all the steps. In order to submit a PR I need > GitHub permissions? Can you know if I signed the OCA? > > - Nir > > > On Wed, Feb 28, 2018 at 5:55 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> >> > Eugene created an easy one: >> https://bugs.openjdk.java.net/browse/JDK-8198795 >> >> I pointed out some prerequisites for doing this in JBS (and Nir expressed >> concern as well), but yes, this might be a good one to start with. >> >> -- Kevin >> >> >> Johan Vos wrote: >> >> I agree with this approach. >> Having a small number of JBS bugs that are low hanging fruit will be good >> to see how the flow works. >> Eugene created an easy one: >> https://bugs.openjdk.java.net/browse/JDK-8198795 >> >> - Johan >> >> On Wed, Feb 28, 2018 at 9:52 AM Laurent Bourg?s < >> bourges.laurent at gmail.com> wrote: >> >>> Johan, >>> I am following the long discussion and I mostly agree what was said. >>> >>> Maybe it is time to start working on github on few minor / trivial >>> bugs... to test all the new process. >>> >>> I propose to extract few JBS bugs (small) with high ROI (agile /scrum >>> approach) and create shadow copies into github issues (id, title, short >>> description & JBS LINK) to be proposed to the jfx community. >>> >>> That would become our backlog that can be managed in a kanban board >>> (github project). Moreover it would be awesome if such board would gather >>> the activity of both oracle & community people on OpenJFX. >>> >>> Once somebody wants to work on one issue, just comment on the github >>> issue and start working in your fork, make PR... >>> >>> Adopting this method, anybody will know publicly what's going on and it >>> would reduce the risk of conflicts (code merge).... >>> >>> My 2 cents... >>> >>> Let's go on, >>> "We are the champions..." >>> >>> Laurent >>> >>> >>> Le 28 f?vr. 2018 9:15 AM, "Johan Vos" a ?crit : >>> >>> That is the difficult point indeed. >>> But why would a PR to OpenJFX be rejected after it was approved in the >>> github mirror? I would assume the main reason for this is because the PR >>> did not what it was supposed to do. In that case, it makes sense to >>> remove >>> the commits from the github mirror as well. >>> >>> I think the main thing here is that we need to be very serious about >>> reviewing and accepting PR's in the github mirror. Accepting a PR in >>> github >>> does not require the *formal* process of creating webrevs etc, but it >>> requires discussion about the issue with reviewers of OpenJFX. >>> We have to minimize the number of times an edge case occurs, in which the >>> discussion was pro PR first, but after it got merged into "development" >>> new >>> arguments are brought up against the PR. >>> I think it would be good to have sort of a post-mortem analysis in case >>> this happens, in order to prevent it from happening again. But as I said, >>> if it does happen, it probably has good reasons and in that case we have >>> to >>> remove it from the development branch as well. >>> >>> I think the more common case would be that an issue is fixed on the >>> github >>> mirror, but not yet accepted (nor rejected) in OpenJFX, so there will be >>> some time lag between the PR acceptance and the integration in OpenJFX. >>> But >>> this should not be a problem, as long as the following scenario is the >>> main >>> flow: >>> >>> The github master branch is always synced with OpenJFX, and never gets >>> modified by other commits. >>> The github "development" branch is where we accept PR's, that can then be >>> send upstream. Changes from "master" are regularly merged into >>> "development". The moment an accepted PR makes it into OpenJFX, it will >>> be >>> synced into "master" and merged into "development" where the merge >>> happens >>> silently as there are no conflicts (since development already has this >>> code). >>> >>> Does that make sense? >>> >>> - Johan >>> >>> On Wed, Feb 28, 2018 at 12:51 AM Kevin Rushforth < >>> kevin.rushforth at oracle.com> >>> wrote: >>> >>> > >>> > >>> > Nir Lisker wrote: >>> > >>> > Johan's thinking was to allow Committers to approve the PR on GitHub -- >>> >> meaning they could be merged on GitHub before an actual Review has >>> >> happened. Are you proposing to change that? >>> > >>> > >>> > What if the PR is rejected at review? We'll end up with conflicts >>> between >>> > the repos. And supposed someone works on a different fix and uses the >>> > rejected PR code, how will that be committed? >>> > >>> > >>> > Good questions; maybe Johan has some thoughts as to how to mitigate >>> this? >>> > >>> > >>> > -- Kevin >>> > >>> > >>> > >>> > On Wed, Feb 28, 2018 at 12:25 AM, Kevin Rushforth < >>> > kevin.rushforth at oracle.com> wrote: >>> > >>> >> This seems a good start in formalizing the process. It will need a >>> little >>> >> tweaking in a couple of areas. >>> >> >>> >> Regarding JBS access, even though I want to relax the requirement to >>> >> become an Author (get a JBS account), it will likely end up somewhere >>> >> between "an intention to contribute" and "two sponsored contributions, >>> >> already reviewed and committed". Even without this, there will >>> necessarily >>> >> be a gap in time between "I want to work on a bug" and getting a JBS >>> >> account. So there is value in encouraging people to clone the GitHub >>> >> sandbox, "kick the tires", make a PR to get feedback, etc., before >>> they can >>> >> access JBS directly (or even while waiting for their OCA to be >>> processed, >>> >> but no PRs in that case). Something to take into account. >>> >> >>> >> Regarding review, we will need a bit more discussion on that. I like >>> the >>> >> idea of the PR being logged in JBS once it is ready to be reviewed. >>> Johan's >>> >> thinking was to allow Committers to approve the PR on GitHub -- >>> meaning >>> >> they could be merged on GitHub before an actual Review has happened. >>> Are >>> >> you proposing to change that? It might have some advantages, but it >>> could >>> >> also make it harder in other areas. I'd like to hear from Johan on >>> this. >>> >> This reminds me that we need to continue the discussion on the general >>> >> "Review" policy, as it is relevant here. >>> >> >>> >> As for whether it is merged into GitHub, I don't have a strong >>> opinion on >>> >> that. As you say it will be pulled into the mirror anyway (along with >>> >> changes from reviews happening in JBS that don't first go through the >>> >> sandbox), so maybe it doesn't matter? On the other hand there might be >>> >> advantages to getting it into the mainline of the sandbox early? Hard >>> to >>> >> say. >>> >> >>> >> -- Kevin >>> >> >>> >> >>> >> Nir Lisker wrote: >>> >> >>> >> Iv'e given the pipeline some thought. I'm purposely ignoring current >>> role >>> >> names (Author, Contributor...). My suggestions: >>> >> >>> >> Potential contributor wants to contribute... >>> >> >>> >> 1. Formal process >>> >> a. If the issue is not in the JBS, they submit it via bugreport. >>> >> b. They send an email on the mailing list regarding the issue (a >>> plan, >>> >> question on how to approach etc.) >>> >> c. If the above effort is "deemed worthy" (whatever that means), and >>> >> they have signed the OCA, and they then they get access to JBS. If >>> they've >>> >> given a GitHub account, they get access to GitHub PRs. >>> >> d. Discussion from the mailing list is copied/linked to the JBS >>> issue. >>> >> Maybe if it's their issue (step a) then the Reporter field can change >>> to >>> >> them. >>> >> >>> >> This ensures that: >>> >> * There's 1 entry point. >>> >> * GitHub and JBS identities are linked (GitHub identity is verified). >>> >> * Being able to comment on JBS is easier - instead of requiring 2 >>> commits >>> >> it requires good intentions(?) >>> >> * Not every person on the planet has access to JBS. >>> >> >>> >> 2. Work process >>> >> a. They fork the GitHub repo. >>> >> b. They create a PR with a 2-way link to/from JBS (similar to >>> current >>> >> webrevs - JBS links). >>> >> c. Discussion specifically on the patch should happen in the PR >>> thread. >>> >> General info on the bug (affected versions etc.) still happens in JBS. >>> >> d. After the patch had been reviewed, it is committed to the Oracle >>> >> repo. Since GitHub mirrors Oracle I don't think it matters if the >>> patch is >>> >> merged into GitHub. >>> >> >>> >> This ensures that: >>> >> * It's easier to start working because the GiutHub repo is more >>> >> convenient than the Oracle repo currently. >>> >> * PRs and JBS issues are mutually aware. >>> >> * The submit -> review -> commit process is streamlined. >>> >> >>> >> We pay a synchronization price for having 2 repos and 2 bug trackers. >>> >> This is what I could come up with. >>> >> >>> >> - Nir >>> >> >>> >> On Fri, Feb 16, 2018 at 1:14 AM, Kevin Rushforth < >>> >> kevin.rushforth at oracle.com> wrote: >>> >> >>> >>> >>> >>> >>> >>> Johan Vos wrote: >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth < >>> >>> kevin.rushforth at oracle.com> wrote: >>> >>> >>> >>> A global reference in JBS would indeed be very good to track back the >>> >>> work in a PR to a real issue. It can also be very useful as there >>> are many >>> >>> existing issues in JBS that can be referred to in future work. >>> >>> >>> >>> The only issue I see is that in order to create an issue in JBS, you >>> >>> need to have "author" status, so not everyone can do this? Given the >>> idea >>> >>> that developers who want to create a PR also need to sign an OCA, it >>> might >>> >>> make sense to somehow combine the administration? >>> >>> >>> >>> >>> >>> I don't think we can combine this, but I hope to be able to relax the >>> >>> requirements to become an Author a little. The current guidelines >>> are 2 >>> >>> sponsored contributions [1]. >>> >>> >>> >>> Pending appointment as an Author, it isn't hard to submit a bug via >>> >>> http://bugreport.java.com/ . If there is a test case, it usually >>> gets >>> >>> moved to the JDK project within a day or so (and I can move them >>> sooner, if >>> >>> needed). The bigger bother is that you can't comment in JBS on a bug >>> you >>> >>> didn't create, but once the bug is there, you can work on it in >>> GutHub >>> >>> and/or send email to the list. I'll also add any comments from >>> contributors >>> >>> who are not yet Authors to any bug report. >>> >>> >>> >>> -- Kevin >>> >>> >>> >>> [1] http://openjdk.java.net/projects/#project-author >>> >>> >>> >>> >>> >>> - Johan >>> >>> >>> >>> >>> >> >>> > >>> >>> >>> > From ank.cpp at gmail.com Mon Mar 5 19:44:29 2018 From: ank.cpp at gmail.com (ankit srivastav) Date: Tue, 6 Mar 2018 01:14:29 +0530 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: References: <5A820EF4.6020409@oracle.com> <5A95C556.7020503@oracle.com> Message-ID: I have no idea when/why test bugs started to get counted for committer status. The last time I checked, number of lines of patch matters the most irrespective of the significance of the patch [ that was a very strange and funny way of judging a patch, must be an idea from a non technical person]. If that would be the it;s way too easy to become committer in Javafx community. Looks like Javafx community does't have any proper way to judge patch significance or the rules can be tailored as per the circumstances. 1) Two of my DRT Media patches were counted as 0.5 and those were not cosmic changes.[ May be now you give me a reason for that ? I also did coding, testing and etc for those patches] I'm still sure that cosmic changes in Editor file should be awarded as 0.5 instead of 1. Saying a patch consist of coding, testing and etc, is just play of words. All those activities are part of code changes and every body does that, nothing special about it. I don't see them as separate activities. 2) For patch http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dc2963c3f7d1 , I can see 5 contributors. I don't know the exact contribution from Rajath, it could be as small as a comment change or could be the whole patch itself [ In that case why do we have 4 other contributors ]. Considering equal efforts by all contributors [ taking the best case ], Individual contribution = [1/5] --> 0.2. For Committer status round off --> 0. So that patch is 0 for me, unless actual code changes can be shown. Rest of the things look fine to me. --Ankit On Wed, Feb 28, 2018 at 10:34 AM, ankit srivastav wrote: > Dear Kevin, > > I will get back to you on this shortly with substantial claims. > > > --Ankit > > On 28 Feb 2018 2:23 a.m., "Kevin Rushforth" > wrote: > >> Hi Ankit, >> >> In response to your veto, I took the opportunity to look at the the list >> of changes, and believe that my earlier nomination of Rajath to OpenJFX >> Project Committer was justified, if perhaps barely so. >> >> While there is no objective criteria by which one can say a particular >> changeset is worth 0.5 of a fix, we do often look at 2 to 4 trivial fixes >> or test-only fixes to "make up the difference" in case only 6 or 7 are >> deemed "significant". This is why we usually want 10 or 12 fixes before we >> nominate someone for Committer -- to avoid quibbling over whether one or >> two are worthy of being counted. >> >> Rather than respond to each of your comments individually (although I do >> have one point below), I will instead list the fixes I consider significant. >> >> In looking at the list of fixes again, I would consider the following 7 >> non-test fixes to be significant, even though several of them were only a >> few lines of product code changed: >> >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/3d5c22069d1f >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/5a3cc1b5bb22 >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/674513271a88 >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dc2963c3f7d1 (see >> comment below) >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/9f43fb83e989 >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dedd5afd753e >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/cfa038af148b >> >> In all cases there needed to be an analysis, a fix, and testing to ensure >> that the bug was fixed without introducing a regression. As for your >> assertion about his part of the collaborative fix to upgrade WebKit to >> v605.1, JDK-8187483 (changeset dc2963c3f7d1), you make an unsubstantiated >> claim regarding his contribution. As he did contribute to that fix, I don't >> see any reason to question how significant it was. >> >> In addition to the above 7, and excluding JDK-8185314 (the removal of >> unused files, which I would agree does not count at all), the other three >> test fixes are in my opinion enough justify the nomination. >> >> I would finally point out that Rajath contributed three additional test >> fixes during the two week voting period, for a new total of 14 changesets >> (13 excluding the unused file removal). >> >> Please respond to the list as to whether you feel the additional three >> test fixes, along with my additional explanation, is enough to satisfy your >> concerns over this nomination, and if not, why not. I would like to put the >> nomination forward again for a vote once the objections are resolved. >> >> Thank you. >> >> -- Kevin >> >> >> ankit srivastav wrote: >> >> NO, >> >> Please go through the table, all the points accumulated are not even more >> then 7. >> I have given reasons for my points. >> >> >> *age* >> >> *author* >> >> *description* >> >> Points >> >> Reason >> >> 8 days ago >> >> rkamath >> >> 8196802: 3D unit tests listed as pass although they are actually skipped >> >> >> 0.5 >> >> Test file, not a direct impact-able code change in product. >> >> 10 days ago >> >> rkamath >> >> 8089454: [HTMLEditor] selection removes CENTER alignment >> >> >> 0.5 >> >> A very small change, why I?m saying so, as the file modified gets called >> directly from the APP written. No debugging/a little is required to make >> the change, which actually defies the purpose of getting knowledge of the >> product. >> >> 13 days ago >> >> rkamath >> >> 8196615: Skip 3D unit tests on system without 3D capability >> >> >> 0.5 >> >> Changes in Test file, not a direct impact-able code change in product. >> >> 4 weeks ago >> >> rkamath >> >> 8165459: HTMLEditor: clipboard toolbar buttons are disabled unexpectedly >> >> >> 0.5 >> >> A very small change, why I?m saying so, as the file modified gets called >> directly from the APP written. No debugging/a little is required to make >> the change, which actually defies the purpose of getting knowledge of the >> product. >> >> 7 weeks ago >> >> rkamath >> >> 8088925: Non opaque background cause NumberFormatException >> >> >> 0.5 >> >> A very small change, why I?m saying so, as the file modified gets called >> directly from the APP written. No debugging/a little is required to make >> the change, which actually defies the purpose of getting knowledge of the >> product. >> >> 2 months ago >> >> rkamath >> >> 8090011: 'tab' key makes control loose focus >> >> jdk-10+36 >> >> 0.5 >> >> A very small change, why I?m saying so, as the file modified gets called >> directly from the APP written. No debugging/a little is required to make >> the change, which actually defies the purpose of getting knowledge of the >> product. >> >> *age* >> >> *author* >> >> *description* >> >> Points >> >> Reason >> >> 2 months ago >> >> mbilla >> >> 8187483: Update to 605.1 version of WebKit >> >> >> 0 >> >> Unless you directly point what changes you have made in the patch I will >> count it has 0. Most probably you have made changes for DRT, which even a >> tester can do. Moving DRT is a non technical task, requires no technical >> skills. >> >> 3 months ago >> >> mbilla >> >> 8187928: [WebView] Images copied from clipboard not written in source >> file format >> >> >> 1 >> >> >> 4 months ago >> >> ghb >> >> 8178290: Intermittent test failure in test.com.sun.webkit.network.Co >> okieTest >> >> jdk-10+29 >> >> 0.5 >> >> Changes in Test file, not a direct impact-able code change in product. >> >> 4 months ago >> >> mbilla >> >> 8187726: [WebView] Copy and Paste of Image not resulting in expected >> behavior >> >> jdk-10+27 >> >> 1 >> >> >> 4 months ago >> >> mbilla >> >> 8187671: [WebView] Drag and Drop of text or html results in an image >> >> >> 1 >> >> >> 5 months ago >> >> ghb >> >> 8089124: HTML5: Number input allows non-numeric input >> >> >> 0.5 >> >> Only setting value changes. For me this kind of change was not even get >> considered for Author status. >> >> 5 months ago >> >> ghb >> >> 8185314: Remove unused third-party python scripts from WebKit sources >> >> >> 0 >> >> No actual code change, you have only removed it.It seems it was not even >> getting called otherwise you must have change some other files which calls >> function from these files. >> >> >> Adding all the points, total sum = 7. >> So it's a NO for me. >> I think you have to solve at least 3 more issues to get to the committer >> status. >> >> *The whole idea behind becoming a committer is to get good solid product >> knowledge not the issue count.* >> *Quality matters over quantity.* >> >> Which one can only get after solving variety of issues with various >> level of difficulty level. >> >> Here I can see you have 3 checkins for file HTMLEditorSkin.java. >> This file basically gets I/P from APP written. >> No/little debugging skill is require to solve the issue in this file. >> >> For all the test changes I have awarded 0.5 as no direct impact on >> product. >> For DRT, moving DRT from one revision to another is just a side job. >> Anybody can do that. >> If I tell a 12th grader then even he can also do that. >> Also I'm not sure what's the actual contribution so awarded as 0. >> >> Removing a file, that's too unused, no code change so 0. >> >> *I have awarded proper points to proper code changes.* >> >> @Rajath: >> I know you must be under pressure (No idea from whom) to become >> committer, but I can see lots of potential in you. >> You should not not succumb to such pressure. >> Whole idea [as I have stated above ] to become committer is get sound >> product understanding, don't stop yourself to get that. >> *Solve issue to get knowledge not just to show counts to other people.* >> >> I can one more checkin from you, but that's too I guess in Test file i.e. >> 0.5 >> So It seems, you are very close to your destination. >> >> Let me now if anyone in the community has any objection. >> >> --Ankit >> >> >> >> >> On Tue, Feb 13, 2018 at 3:32 AM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> I hereby nominate Rajath Kamath [1] to OpenJFX Committer. >>> >>> Rajath is a member of JavaFX team at Oracle, who has contributed 11 >>> changesets [2][3] to OpenJFX. >>> >>> Votes are due by February 26, 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]. >>> >>> Thanks. >>> >>> -- Kevin >>> >>> [1] http://openjdk.java.net/census#rkamath >>> >>> [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=2 >>> 0&rev=author%28rkamath%29 >>> [3] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=2 >>> 0&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 >>> >>> >> From jonathan at jonathangiles.net Mon Mar 5 20:20:14 2018 From: jonathan at jonathangiles.net (Jonathan Giles) Date: Tue, 6 Mar 2018 09:20:14 +1300 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: References: <5A820EF4.6020409@oracle.com> <5A95C556.7020503@oracle.com> Message-ID: Ankit, You should zoom out a little bit and look at the bigger picture. Does OpenJFX want more or less contributors? Does OpenJFX want to make the burden to becoming a committer easier or more difficult? Does OpenJFX want to be a community that welcomes or shuns people who are ready to contribute? Trying to objectively quantify contributions to a community is difficult, so the question I always ask myself is - do we want to welcome this person into the community even further, by enabling them to grow and offer more, or do we want to keep pushing back on the contributor until they either meet some goal or leave in frustration? Based on this criteria, and the contributions that Kevin has outlined, I would much rather we have Rajath be part of our community than not. Delaying his committer status has no real effect here other than to cause slow downs - he is a member of the JavaFX team at Oracle, this is what he will be doing regardless - just with more hurdles in place until he becomes committer :-) I would advocate for your acceptance of Rajath, in the spirit of community harmony and further progression of JavaFX. Being a committer does not imply that Rajath has unfettered access to OpenJFX with no risk of reprisal - he still has to go through the same review process as everyone else - it just means that at the very end, once the work is reviewed and accepted, he can push it to the repo on his own, without requiring the input of anyone else. Committer status, in other words, should not require a huge burden of excellence - it should require just enough to know that the person is committed to the cause, and to not desire to cause havoc in the repo :-) -- Jonathan On Tue, Mar 6, 2018 at 8:44 AM, ankit srivastav wrote: > I have no idea when/why test bugs started to get counted for committer > status. > The last time I checked, number of lines of patch matters the most > irrespective of the significance of the patch [ that was a very strange and > funny way of judging a patch, must be an idea from a non technical person]. > > If that would be the it;s way too easy to become committer in Javafx > community. > Looks like Javafx community does't have any proper way to judge patch > significance or the rules can be tailored as per the circumstances. > > > 1) > Two of my DRT Media patches were counted as 0.5 and those were not cosmic > changes.[ May be now you give me a reason for that ? I also did coding, > testing and etc for those patches] > > I'm still sure that cosmic changes in Editor file should be awarded as 0.5 > instead of 1. > Saying a patch consist of coding, testing and etc, is just play of words. > All those activities are part of code changes and every body does that, > nothing special about it. > I don't see them as separate activities. > > 2) > For patch http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dc2963c3f7d1 > , > I can see 5 contributors. > I don't know the exact contribution from Rajath, it could be as small as a > comment change or could be the whole patch itself [ In that case why do we > have 4 other contributors ]. > Considering equal efforts by all contributors [ taking the best case ], > Individual contribution = [1/5] --> 0.2. For Committer status round off > --> 0. > So that patch is 0 for me, unless actual code changes can be shown. > > > Rest of the things look fine to me. > > --Ankit > > > > > > > > > > > > > > On Wed, Feb 28, 2018 at 10:34 AM, ankit srivastav > wrote: > > > Dear Kevin, > > > > I will get back to you on this shortly with substantial claims. > > > > > > --Ankit > > > > On 28 Feb 2018 2:23 a.m., "Kevin Rushforth" > > wrote: > > > >> Hi Ankit, > >> > >> In response to your veto, I took the opportunity to look at the the list > >> of changes, and believe that my earlier nomination of Rajath to OpenJFX > >> Project Committer was justified, if perhaps barely so. > >> > >> While there is no objective criteria by which one can say a particular > >> changeset is worth 0.5 of a fix, we do often look at 2 to 4 trivial > fixes > >> or test-only fixes to "make up the difference" in case only 6 or 7 are > >> deemed "significant". This is why we usually want 10 or 12 fixes before > we > >> nominate someone for Committer -- to avoid quibbling over whether one or > >> two are worthy of being counted. > >> > >> Rather than respond to each of your comments individually (although I do > >> have one point below), I will instead list the fixes I consider > significant. > >> > >> In looking at the list of fixes again, I would consider the following 7 > >> non-test fixes to be significant, even though several of them were only > a > >> few lines of product code changed: > >> > >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/3d5c22069d1f > >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/5a3cc1b5bb22 > >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/674513271a88 > >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dc2963c3f7d1 (see > >> comment below) > >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/9f43fb83e989 > >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dedd5afd753e > >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/cfa038af148b > >> > >> In all cases there needed to be an analysis, a fix, and testing to > ensure > >> that the bug was fixed without introducing a regression. As for your > >> assertion about his part of the collaborative fix to upgrade WebKit to > >> v605.1, JDK-8187483 (changeset dc2963c3f7d1), you make an > unsubstantiated > >> claim regarding his contribution. As he did contribute to that fix, I > don't > >> see any reason to question how significant it was. > >> > >> In addition to the above 7, and excluding JDK-8185314 (the removal of > >> unused files, which I would agree does not count at all), the other > three > >> test fixes are in my opinion enough justify the nomination. > >> > >> I would finally point out that Rajath contributed three additional test > >> fixes during the two week voting period, for a new total of 14 > changesets > >> (13 excluding the unused file removal). > >> > >> Please respond to the list as to whether you feel the additional three > >> test fixes, along with my additional explanation, is enough to satisfy > your > >> concerns over this nomination, and if not, why not. I would like to put > the > >> nomination forward again for a vote once the objections are resolved. > >> > >> Thank you. > >> > >> -- Kevin > >> > >> > >> ankit srivastav wrote: > >> > >> NO, > >> > >> Please go through the table, all the points accumulated are not even > more > >> then 7. > >> I have given reasons for my points. > >> > >> > >> *age* > >> > >> *author* > >> > >> *description* > >> > >> Points > >> > >> Reason > >> > >> 8 days ago > >> > >> rkamath > >> > >> 8196802: 3D unit tests listed as pass although they are actually > skipped > >> 1438734a46e3?revcount=20> > >> > >> 0.5 > >> > >> Test file, not a direct impact-able code change in product. > >> > >> 10 days ago > >> > >> rkamath > >> > >> 8089454: [HTMLEditor] selection removes CENTER alignment > >> b86ce9469653?revcount=20> > >> > >> 0.5 > >> > >> A very small change, why I?m saying so, as the file modified gets called > >> directly from the APP written. No debugging/a little is required to make > >> the change, which actually defies the purpose of getting knowledge of > the > >> product. > >> > >> 13 days ago > >> > >> rkamath > >> > >> 8196615: Skip 3D unit tests on system without 3D capability > >> 4f433399edbd?revcount=20> > >> > >> 0.5 > >> > >> Changes in Test file, not a direct impact-able code change in product. > >> > >> 4 weeks ago > >> > >> rkamath > >> > >> 8165459: HTMLEditor: clipboard toolbar buttons are disabled unexpectedly > >> 3d5c22069d1f?revcount=20> > >> > >> 0.5 > >> > >> A very small change, why I?m saying so, as the file modified gets called > >> directly from the APP written. No debugging/a little is required to make > >> the change, which actually defies the purpose of getting knowledge of > the > >> product. > >> > >> 7 weeks ago > >> > >> rkamath > >> > >> 8088925: Non opaque background cause NumberFormatException > >> 5a3cc1b5bb22?revcount=20> > >> > >> 0.5 > >> > >> A very small change, why I?m saying so, as the file modified gets called > >> directly from the APP written. No debugging/a little is required to make > >> the change, which actually defies the purpose of getting knowledge of > the > >> product. > >> > >> 2 months ago > >> > >> rkamath > >> > >> 8090011: 'tab' key makes control loose focus > >> 674513271a88?revcount=20> > >> jdk-10+36 > >> > >> 0.5 > >> > >> A very small change, why I?m saying so, as the file modified gets called > >> directly from the APP written. No debugging/a little is required to make > >> the change, which actually defies the purpose of getting knowledge of > the > >> product. > >> > >> *age* > >> > >> *author* > >> > >> *description* > >> > >> Points > >> > >> Reason > >> > >> 2 months ago > >> > >> mbilla > >> > >> 8187483: Update to 605.1 version of WebKit > >> dc2963c3f7d1?revcount=20> > >> > >> 0 > >> > >> Unless you directly point what changes you have made in the patch I will > >> count it has 0. Most probably you have made changes for DRT, which even > a > >> tester can do. Moving DRT is a non technical task, requires no technical > >> skills. > >> > >> 3 months ago > >> > >> mbilla > >> > >> 8187928: [WebView] Images copied from clipboard not written in source > >> file format > >> 9f43fb83e989?revcount=20> > >> > >> 1 > >> > >> > >> 4 months ago > >> > >> ghb > >> > >> 8178290: Intermittent test failure in test.com.sun.webkit.network.Co > >> okieTest > >> 315c8aa5bc4c?revcount=20> > >> jdk-10+29 > >> > >> 0.5 > >> > >> Changes in Test file, not a direct impact-able code change in product. > >> > >> 4 months ago > >> > >> mbilla > >> > >> 8187726: [WebView] Copy and Paste of Image not resulting in expected > >> behavior > >> dedd5afd753e?revcount=20> > >> jdk-10+27 > >> > >> 1 > >> > >> > >> 4 months ago > >> > >> mbilla > >> > >> 8187671: [WebView] Drag and Drop of text or html results in an image > >> cfa038af148b?revcount=20> > >> > >> 1 > >> > >> > >> 5 months ago > >> > >> ghb > >> > >> 8089124: HTML5: Number input allows non-numeric input > >> 73ace584b9ba?revcount=20> > >> > >> 0.5 > >> > >> Only setting value changes. For me this kind of change was not even get > >> considered for Author status. > >> > >> 5 months ago > >> > >> ghb > >> > >> 8185314: Remove unused third-party python scripts from WebKit sources > >> 55ad191f5932?revcount=20> > >> > >> 0 > >> > >> No actual code change, you have only removed it.It seems it was not even > >> getting called otherwise you must have change some other files which > calls > >> function from these files. > >> > >> > >> Adding all the points, total sum = 7. > >> So it's a NO for me. > >> I think you have to solve at least 3 more issues to get to the committer > >> status. > >> > >> *The whole idea behind becoming a committer is to get good solid product > >> knowledge not the issue count.* > >> *Quality matters over quantity.* > >> > >> Which one can only get after solving variety of issues with various > >> level of difficulty level. > >> > >> Here I can see you have 3 checkins for file HTMLEditorSkin.java. > >> This file basically gets I/P from APP written. > >> No/little debugging skill is require to solve the issue in this file. > >> > >> For all the test changes I have awarded 0.5 as no direct impact on > >> product. > >> For DRT, moving DRT from one revision to another is just a side job. > >> Anybody can do that. > >> If I tell a 12th grader then even he can also do that. > >> Also I'm not sure what's the actual contribution so awarded as 0. > >> > >> Removing a file, that's too unused, no code change so 0. > >> > >> *I have awarded proper points to proper code changes.* > >> > >> @Rajath: > >> I know you must be under pressure (No idea from whom) to become > >> committer, but I can see lots of potential in you. > >> You should not not succumb to such pressure. > >> Whole idea [as I have stated above ] to become committer is get sound > >> product understanding, don't stop yourself to get that. > >> *Solve issue to get knowledge not just to show counts to other people.* > >> > >> I can one more checkin from you, but that's too I guess in Test file > i.e. > >> 0.5 > >> So It seems, you are very close to your destination. > >> > >> Let me now if anyone in the community has any objection. > >> > >> --Ankit > >> > >> > >> > >> > >> On Tue, Feb 13, 2018 at 3:32 AM, Kevin Rushforth < > >> kevin.rushforth at oracle.com> wrote: > >> > >>> I hereby nominate Rajath Kamath [1] to OpenJFX Committer. > >>> > >>> Rajath is a member of JavaFX team at Oracle, who has contributed 11 > >>> changesets [2][3] to OpenJFX. > >>> > >>> Votes are due by February 26, 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]. > >>> > >>> Thanks. > >>> > >>> -- Kevin > >>> > >>> [1] http://openjdk.java.net/census#rkamath > >>> > >>> [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=2 > >>> 0&rev=author%28rkamath%29 > >>> [3] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=2 > >>> 0&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 > >>> > >>> > >> > From kevin.rushforth at oracle.com Mon Mar 5 21:33:52 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 05 Mar 2018 13:33:52 -0800 Subject: [11] Review request: JDK-8195788: Remove obsolete javafx.jmx module Message-ID: <5A9DB7C0.7080702@oracle.com> Please review the following: https://bugs.openjdk.java.net/browse/JDK-8195788 http://cr.openjdk.java.net/~kcr/8195788/webrev.00/ As the title says, this will remove the obsolete javafx.jmx module. Details are in JBS. -- Kevin From dipak.kumar at oracle.com Tue Mar 6 09:08:04 2018 From: dipak.kumar at oracle.com (Dipak Kumar) Date: Tue, 6 Mar 2018 01:08:04 -0800 (PST) Subject: [11] Review request: 8198354: [macOS] Corrupt Thai characters displayed in word wrapped label Message-ID: Hi Phil/Kevin, Please review the below fix - Webrev : http://cr.openjdk.java.net/~mbilla/8198354/webrev.00/ JBS : https://bugs.openjdk.java.net/browse/JDK-8198354 Details about the fix has been updated in JBS. Thanks, Dipak From kevin.rushforth at oracle.com Tue Mar 6 16:54:24 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Mar 2018 08:54:24 -0800 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: References: <5A820EF4.6020409@oracle.com> <5A95C556.7020503@oracle.com> Message-ID: <5A9EC7C0.7050706@oracle.com> Hi Ankit, If you read my response to your first email, I thought I was clear that we don't count test bugs the same as product fixes, but neither are they worth 0. Meaning that a few test fixes can certainly count towards "making up the difference" as I said. As for your two other points: > I'm still sure that cosmic changes in Editor file should be awarded as > 0.5 instead of 1. > Saying a patch consist of coding, testing and etc, is just play of words. > All those activities are part of code changes and every body does > that, nothing special about it. > I don't see them as separate activities. I understand what you are saying here, and there is no objective criteria by which a patch is considered significant...it will always be a judgment call. The reason I pointed out analysis and testing is to distinguish it, for example, from a hypothetical patch to add a null check to avoid an NPE, but without any analysis or testing to make sure that it isn't just masking a symptom. I think that all 7 of the ones I listed can be considered significant (even though a couple might be on the bubble). Still, to satisfy your point, I will wait for one more product fix before putting forth Rajath's nomination again. > For > patch http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dc2963c3f7d1 > , I > can see 5 contributors. > I don't know the exact contribution from Rajath, it could be as small > as a comment change or could be the whole patch itself [ In that case > why do we have 4 other contributors ]. > Considering equal efforts by all contributors [ taking the best case > ], Individual contribution = [1/5] --> 0.2. For Committer status > round off --> 0. > So that patch is 0 for me, unless actual code changes can be shown. I'm sorry, but saying that this changeset doesn't count (for anyone according to your math) is quite simply a fallacious argument that isn't backed up by any precedent in the OpenJDK community. -- Kevin ankit srivastav wrote: > > > I have no idea when/why test bugs started to get counted for committer > status. > The last time I checked, number of lines of patch matters the most > irrespective of the significance of the patch [ that was a very > strange and funny way of judging a patch, must be an idea from a non > technical person]. > > If that would be the it;s way too easy to become committer in Javafx > community. > Looks like Javafx community does't have any proper way to judge patch > significance or the rules can be tailored as per the circumstances. > > > 1) > Two of my DRT Media patches were counted as 0.5 and those were not > cosmic changes.[ May be now you give me a reason for that ? I also did > coding, testing and etc for those patches] > > I'm still sure that cosmic changes in Editor file should be awarded as > 0.5 instead of 1. > Saying a patch consist of coding, testing and etc, is just play of words. > All those activities are part of code changes and every body does > that, nothing special about it. > I don't see them as separate activities. > > 2) > For > patch http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dc2963c3f7d1 > , I > can see 5 contributors. > I don't know the exact contribution from Rajath, it could be as small > as a comment change or could be the whole patch itself [ In that case > why do we have 4 other contributors ]. > Considering equal efforts by all contributors [ taking the best case > ], Individual contribution = [1/5] --> 0.2. For Committer status > round off --> 0. > So that patch is 0 for me, unless actual code changes can be shown. > > > Rest of the things look fine to me. > > --Ankit > > > > > > > > > > > > > > On Wed, Feb 28, 2018 at 10:34 AM, ankit srivastav > wrote: > > Dear Kevin, > > I will get back to you on this shortly with substantial claims. > > > --Ankit > > On 28 Feb 2018 2:23 a.m., "Kevin Rushforth" > > > wrote: > > Hi Ankit, > > In response to your veto, I took the opportunity to look at > the the list of changes, and believe that my earlier > nomination of Rajath to OpenJFX Project Committer was > justified, if perhaps barely so. > > While there is no objective criteria by which one can say a > particular changeset is worth 0.5 of a fix, we do often look > at 2 to 4 trivial fixes or test-only fixes to "make up the > difference" in case only 6 or 7 are deemed "significant". This > is why we usually want 10 or 12 fixes before we nominate > someone for Committer -- to avoid quibbling over whether one > or two are worthy of being counted. > > Rather than respond to each of your comments individually > (although I do have one point below), I will instead list the > fixes I consider significant. > > In looking at the list of fixes again, I would consider the > following 7 non-test fixes to be significant, even though > several of them were only a few lines of product code changed: > > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/3d5c22069d1f > > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/5a3cc1b5bb22 > > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/674513271a88 > > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dc2963c3f7d1 > > (see comment below) > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/9f43fb83e989 > > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/dedd5afd753e > > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/cfa038af148b > > > In all cases there needed to be an analysis, a fix, and > testing to ensure that the bug was fixed without introducing a > regression. As for your assertion about his part of the > collaborative fix to upgrade WebKit to v605.1, JDK-8187483 > (changeset dc2963c3f7d1), you make an unsubstantiated claim > regarding his contribution. As he did contribute to that fix, > I don't see any reason to question how significant it was. > > In addition to the above 7, and excluding JDK-8185314 (the > removal of unused files, which I would agree does not count at > all), the other three test fixes are in my opinion enough > justify the nomination. > > I would finally point out that Rajath contributed three > additional test fixes during the two week voting period, for a > new total of 14 changesets (13 excluding the unused file removal). > > Please respond to the list as to whether you feel the > additional three test fixes, along with my additional > explanation, is enough to satisfy your concerns over this > nomination, and if not, why not. I would like to put the > nomination forward again for a vote once the objections are > resolved. > > Thank you. > > -- Kevin > > > ankit srivastav wrote: >> NO, >> >> Please go through the table, all the points accumulated are >> not even more then 7. >> I have given reasons for my points. >> >> >> *age* >> >> >> >> *author* >> >> >> >> *description* >> >> >> >> Points >> >> >> >> Reason >> >> 8 days ago >> >> >> >> rkamath >> >> >> >> 8196802: 3D unit tests listed as pass although they are >> actually skipped >> >> >> >> >> 0.5 >> >> >> >> Test file, not a direct impact-able code change in product. >> >> 10 days ago >> >> >> >> rkamath >> >> >> >> 8089454: [HTMLEditor] selection removes CENTER alignment >> >> >> >> >> 0.5 >> >> >> >> A very small change, why I?m saying so, as the file modified >> gets called directly from the APP written. No debugging/a >> little is required to make the change, which actually defies >> the purpose of getting knowledge of the product. >> >> 13 days ago >> >> >> >> rkamath >> >> >> >> 8196615: Skip 3D unit tests on system without 3D capability >> >> >> >> >> 0.5 >> >> >> >> Changes in Test file, not a direct impact-able code change in >> product. >> >> 4 weeks ago >> >> >> >> rkamath >> >> >> >> 8165459: HTMLEditor: clipboard toolbar buttons are disabled >> unexpectedly >> >> >> >> >> 0.5 >> >> >> >> A very small change, why I?m saying so, as the file modified >> gets called directly from the APP written. No debugging/a >> little is required to make the change, which actually defies >> the purpose of getting knowledge of the product. >> >> 7 weeks ago >> >> >> >> rkamath >> >> >> >> 8088925: Non opaque background cause NumberFormatException >> >> >> >> >> 0.5 >> >> >> >> A very small change, why I?m saying so, as the file modified >> gets called directly from the APP written. No debugging/a >> little is required to make the change, which actually defies >> the purpose of getting knowledge of the product. >> >> 2 months ago >> >> >> >> rkamath >> >> >> >> 8090011: 'tab' key makes control loose focus >> jdk-10+36 >> >> >> >> 0.5 >> >> >> >> A very small change, why I?m saying so, as the file modified >> gets called directly from the APP written. No debugging/a >> little is required to make the change, which actually defies >> the purpose of getting knowledge of the product. >> >> *age* >> >> >> >> *author* >> >> >> >> *description* >> >> >> >> Points >> >> >> >> Reason >> >> 2 months ago >> >> >> >> mbilla >> >> >> >> 8187483: Update to 605.1 version of WebKit >> >> >> >> >> 0 >> >> >> >> Unless you directly point what changes you have made in the >> patch I will count it has 0. Most probably you have made >> changes for DRT, which even a tester can do. Moving DRT is a >> non technical task, requires no technical skills. >> >> 3 months ago >> >> >> >> mbilla >> >> >> >> 8187928: [WebView] Images copied from clipboard not written >> in source file format >> >> >> >> >> 1 >> >> >> >> >> 4 months ago >> >> >> >> ghb >> >> >> >> 8178290: Intermittent test failure in >> test.com.sun.webkit.network.CookieTest >> jdk-10+29 >> >> >> >> 0.5 >> >> >> >> Changes in Test file, not a direct impact-able code change in >> product. >> >> 4 months ago >> >> >> >> mbilla >> >> >> >> 8187726: [WebView] Copy and Paste of Image not resulting in >> expected behavior >> jdk-10+27 >> >> >> >> 1 >> >> >> >> >> 4 months ago >> >> >> >> mbilla >> >> >> >> 8187671: [WebView] Drag and Drop of text or html results in >> an image >> >> >> >> >> 1 >> >> >> >> >> 5 months ago >> >> >> >> ghb >> >> >> >> 8089124: HTML5: Number input allows non-numeric input >> >> >> >> >> 0.5 >> >> >> >> Only setting value changes. For me this kind of change was >> not even get considered for Author status. >> >> 5 months ago >> >> >> >> ghb >> >> >> >> 8185314: Remove unused third-party python scripts from WebKit >> sources >> >> >> >> >> 0 >> >> >> >> No actual code change, you have only removed it.It seems it >> was not even getting called otherwise you must have change >> some other files which calls function from these files. >> >> >> >> Adding all the points, total sum = 7. >> So it's a NO for me. >> I think you have to solve at least 3 more issues to get to >> the committer status. >> * >> * >> *The whole idea behind becoming a committer is to get good >> solid product knowledge not the issue count.* >> *Quality matters over quantity.* >> >> Which one can only get after solving variety of issues with >> various level of difficulty level. >> >> Here I can see you have 3 checkins for file HTMLEditorSkin.java. >> This file basically gets I/P from APP written. >> No/little debugging skill is require to solve the issue in >> this file. >> >> For all the test changes I have awarded 0.5 as no direct >> impact on product. >> For DRT, moving DRT from one revision to another is just a >> side job. Anybody can do that. >> If I tell a 12th grader then even he can also do that. >> Also I'm not sure what's the actual contribution so awarded as 0. >> >> Removing a file, that's too unused, no code change so 0. >> >> *I have awarded proper points to proper code changes.* >> >> @Rajath: >> I know you must be under pressure (No idea from whom) to >> become committer, but I can see lots of potential in you. >> You should not not succumb to such pressure. >> Whole idea [as I have stated above ] to become committer is >> get sound product understanding, don't stop yourself to get that. >> *Solve issue to get knowledge not just to show counts to >> other people.* >> >> I can one more checkin from you, but that's too I guess in >> Test file i.e. 0.5 >> So It seems, you are very close to your destination. >> >> Let me now if anyone in the community has any objection. >> >> --Ankit >> >> >> >> >> On Tue, Feb 13, 2018 at 3:32 AM, Kevin Rushforth >> > > wrote: >> >> I hereby nominate Rajath Kamath [1] to OpenJFX Committer. >> >> Rajath is a member of JavaFX team at Oracle, who has >> contributed 11 changesets [2][3] to OpenJFX. >> >> Votes are due by February 26, 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]. >> >> 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 >> >> >> > From openjfx at arne-augenstein.de Wed Mar 7 16:51:42 2018 From: openjfx at arne-augenstein.de (openjfx at arne-augenstein.de) Date: Wed, 07 Mar 2018 17:51:42 +0100 Subject: Bad character spacing (kerning?) in Linux Message-ID: <20180307175142.Horde.LxbBxp77ayTktbeunp-7PA2@webmail.df.eu> Hello all, I've recently started a project in JavaFX and had some trouble with inconsistent widths of spaces between characters in Linux. I haven't been able to find much useful information and therefore posted a stackoverflow question with a screenshot illustrating the problem and some simple example code to reproduce the issue. I think it's better explained with the picture, that's why I won't repeat myself here and point you instead to my question on that page: https://stackoverflow.com/questions/49136131/bad-character-spacing-kerning-in-javafxs-font-rendering-in-linux One of the members of stackoverflow advised me to ask this question on your mailing list. My question is if this behavior is inherent to the way JavaFX renders text on Linux. And if there is some workaround/setting which I could use to circumvent this issue. Thanks in advance and regards Arne Augenstein From philip.race at oracle.com Wed Mar 7 17:10:49 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 7 Mar 2018 09:10:49 -0800 Subject: Bad character spacing (kerning?) in Linux In-Reply-To: <20180307175142.Horde.LxbBxp77ayTktbeunp-7PA2@webmail.df.eu> References: <20180307175142.Horde.LxbBxp77ayTktbeunp-7PA2@webmail.df.eu> Message-ID: <337abc1a-675b-13b5-c22c-912fbd0a17f3@oracle.com> The Linux image shows greyscale text. The Mac image shows subpixel LCD text. The latter can be positioned with sub-pixel (1/3 pixel) resolution. Why does this make a difference ? JavaFX like CoreText + DirectWrite, and unlike GDI + Swing uses unhinted glyphs with floating point accumulation of the positions. But the raster problem is that you need to align the glyph to discrete pixels In the subpixel case you have 3x the resolution to play with and the rounding to the raster grid is not obvious. If your linux system were configured to support LCD subpixel text I'd expect it to be similar to Mac .. modulo the fact that retina is hi-res and that the fonts will be different. So it is probably not something FX has control over .. you need to look at your settings. If freetype from your vendor is configured without LCD text support you may be out of luck -phil. On 03/07/2018 08:51 AM, openjfx at arne-augenstein.de wrote: > > Hello all, > > I've recently started a project in JavaFX and had some trouble with > inconsistent widths of spaces between characters in Linux. I haven't > been able to find much useful information and therefore posted a > stackoverflow question with a screenshot illustrating the problem and > some simple example code to reproduce the issue. I think it's better > explained with the picture, that's why I won't repeat myself here and > point you instead to my question on that page: > > https://stackoverflow.com/questions/49136131/bad-character-spacing-kerning-in-javafxs-font-rendering-in-linux > > > One of the members of stackoverflow advised me to ask this question on > your mailing list. My question is if this behavior is inherent to the > way JavaFX renders text on Linux. And if there is some > workaround/setting which I could use to circumvent this issue. > > Thanks in advance and regards > Arne Augenstein > From openjfx at arne-augenstein.de Wed Mar 7 20:20:59 2018 From: openjfx at arne-augenstein.de (Arne Augenstein) Date: Wed, 07 Mar 2018 21:20:59 +0100 Subject: Bad character spacing (kerning?) in Linux In-Reply-To: <337abc1a-675b-13b5-c22c-912fbd0a17f3@oracle.com> References: <20180307175142.Horde.LxbBxp77ayTktbeunp-7PA2@webmail.df.eu> <337abc1a-675b-13b5-c22c-912fbd0a17f3@oracle.com> Message-ID: <1520454059.728.0@sslout.df.eu> Thanks Phil, I think you've put me on the right track. I'm using Manjaro, which is a very close derivative of Archlinux. Looking at https://wiki.archlinux.org/index.php/font_configuration#Subpixel_rendering it seems this really could be the underlying problem. Subpixel rendering is disabled by default on Archlinux systems. I probably will need a few days to verify that this is in fact the issue. I will report back as soon as I've found out more. Arne On Mi, M?r 7, 2018 at 6:10 PM, Phil Race wrote: > The Linux image shows greyscale text. > The Mac image shows subpixel LCD text. > The latter can be positioned with sub-pixel (1/3 pixel) resolution. > > Why does this make a difference ? > JavaFX like CoreText + DirectWrite, and unlike GDI + Swing uses > unhinted glyphs > with floating point accumulation of the positions. > But the raster problem is that you need to align the glyph to > discrete pixels > > In the subpixel case you have 3x the resolution to play with and the > rounding to > the raster grid is not obvious. > > If your linux system were configured to support LCD subpixel text I'd > expect > it to be similar to Mac .. modulo the fact that retina is hi-res and > that the fonts will be different. > > So it is probably not something FX has control over .. you need to > look at your settings. > > If freetype from your vendor is configured without LCD text support > you may be out of luck > > -phil. > > > > On 03/07/2018 08:51 AM, openjfx at arne-augenstein.de wrote: >> >> Hello all, >> >> I've recently started a project in JavaFX and had some trouble with >> inconsistent widths of spaces between characters in Linux. I >> haven't been able to find much useful information and therefore >> posted a stackoverflow question with a screenshot illustrating the >> problem and some simple example code to reproduce the issue. I >> think it's better explained with the picture, that's why I won't >> repeat myself here and point you instead to my question on that >> page: >> >> https://stackoverflow.com/questions/49136131/bad-character-spacing-kerning-in-javafxs-font-rendering-in-linux >>  >> >> One of the members of stackoverflow advised me to ask this question >> on your mailing list. My question is if this behavior is inherent >> to the way JavaFX renders text on Linux. And if there is some >> workaround/setting which I could use to circumvent this issue. >> >> Thanks in advance and regards >> Arne Augenstein >> > From openjfx at arne-augenstein.de Wed Mar 7 21:14:44 2018 From: openjfx at arne-augenstein.de (Arne Augenstein) Date: Wed, 07 Mar 2018 22:14:44 +0100 Subject: Bad character spacing (kerning?) in Linux In-Reply-To: <1520454059.728.0@sslout.df.eu> References: <20180307175142.Horde.LxbBxp77ayTktbeunp-7PA2@webmail.df.eu> <337abc1a-675b-13b5-c22c-912fbd0a17f3@oracle.com> <1520454059.728.0@sslout.df.eu> Message-ID: <1520457284.741.0@sslout.df.eu> Ok, it went faster than expected. I can confirm that missing subpixel rendering was the issue. Archlinux has some alternative freetype packages which provide Cleartype rendering. I found one that works on my machine and now the text is rendered correctly. Thanks a lot. I've searched for a solution to this behaviour for quite a couple of days and you provided me with the correct answer within an hour. For reference (if someone else has the same problem): I've installed the package freetype2-ultimate5 from the AUR repository. freetype2-cleartype would've probably been the better choice as it is advised to use this one in the wiki article from my previous mail. But that package currently doesn't compile on my PC. Arne On Mi, M?r 7, 2018 at 9:20 PM, Arne Augenstein wrote: > Thanks Phil, I think you've put me on the right track. I'm using > Manjaro, which is a very close derivative of Archlinux. Looking at > https://wiki.archlinux.org/index.php/font_configuration#Subpixel_rendering > it seems this really could be the underlying problem. Subpixel > rendering is disabled by default on Archlinux systems. > > I probably will need a few days to verify that this is in fact the > issue. I will report back as soon as I've found out more. > > Arne > > On Mi, M?r 7, 2018 at 6:10 PM, Phil Race > wrote: >> The Linux image shows greyscale text. >> The Mac image shows subpixel LCD text. >> The latter can be positioned with sub-pixel (1/3 pixel) resolution. >> >> Why does this make a difference ? >> JavaFX like CoreText + DirectWrite, and unlike GDI + Swing uses >> unhinted glyphs >> with floating point accumulation of the positions. >> But the raster problem is that you need to align the glyph to >> discrete pixels >> >> In the subpixel case you have 3x the resolution to play with and the >> rounding to >> the raster grid is not obvious. >> >> If your linux system were configured to support LCD subpixel text >> I'd expect >> it to be similar to Mac .. modulo the fact that retina is hi-res and >> that the fonts will be different. >> >> So it is probably not something FX has control over .. you need to >> look at your settings. >> >> If freetype from your vendor is configured without LCD text support >> you may be out of luck >> >> -phil. >> >> >> >> On 03/07/2018 08:51 AM, openjfx at arne-augenstein.de wrote: >>> >>> Hello all, >>> >>> I've recently started a project in JavaFX and had some trouble with >>> inconsistent widths of spaces between characters in Linux. I >>> haven't been able to find much useful information and therefore >>> posted a stackoverflow question with a screenshot illustrating >>> the problem and some simple example code to reproduce the issue. >>> I think it's better explained with the picture, that's why I >>> won't repeat myself here and point you instead to my question on >>> that page: >>> >>> https://stackoverflow.com/questions/49136131/bad-character-spacing-kerning-in-javafxs-font-rendering-in-linux >>>  >>> >>> One of the members of stackoverflow advised me to ask this question >>> on your mailing list. My question is if this behavior is >>> inherent to the way JavaFX renders text on Linux. And if there >>> is some workaround/setting which I could use to circumvent this >>> issue. >>> >>> Thanks in advance and regards >>> Arne Augenstein >>> >> From alexander.matveev at oracle.com Thu Mar 8 00:01:09 2018 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 7 Mar 2018 16:01:09 -0800 Subject: [11] Review request for 8199008: [macOS, Linux] Instantiating MediaPlayer causes CPU usage to be over 100% Message-ID: <654872c7-b570-dbed-09e6-4dd9cf64f6df@oracle.com> Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8199008 Fixed infinite loop on OS X and Linux in massaging loop which caused 100% CPU utilization. Thanks, Alexander From rajath.kamath at oracle.com Thu Mar 8 11:29:17 2018 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Thu, 8 Mar 2018 03:29:17 -0800 (PST) Subject: [11] Review Request - JDK-8197488: [testbug] java.lang.IllegalStateException getting logged on stdout/stderr while running javafx unit tests Message-ID: <3d46d3ec-884c-4354-ae3a-ebe272bc522d@default> Hi Kevin, Ajit, Please review this fix in TreeTableViewTest and TableViewTest for exceptions getting logged although unit test run is successful. Details in JBS. JBS : https://bugs.openjdk.java.net/browse/JDK-8197488 WebRev : HYPERLINK "http://cr.openjdk.java.net/%7Erkamath/8197488/webrev.00/" http://cr.openjdk.java.net/~rkamath/8197488/webrev.00/ Thanks, Rajath From kevin.rushforth at oracle.com Thu Mar 8 15:48:18 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 08 Mar 2018 07:48:18 -0800 Subject: [11] Review request: JDK-8199071: Fix gradle deprecation warnings Message-ID: <5AA15B42.3040302@oracle.com> Phil, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8199071 http://cr.openjdk.java.net/~kcr/8199071/webrev.00/ This is mostly simple cleanup. The only substantive change was to remove the override of the deprecated sourceSets.main.output.classesDir property (added by the fix for https://bugs.openjdk.java.net/browse/JDK-8185358 so we could transition from gradle 3 to gradle 4), along with associated changes to use gradle's per-language output directory. -- Kevin From kevin.rushforth at oracle.com Thu Mar 8 15:59:41 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 08 Mar 2018 07:59:41 -0800 Subject: [11] Review request: JDK-8199132: Remove reference to JApplet from JavaFX Ensemble demo Message-ID: <5AA15DED.7030407@oracle.com> Prasanta or Ajit, Please review the following fix to remove the reference to JApplet from the SwingInterop sample in Ensemble8: https://bugs.openjdk.java.net/browse/JDK-8199132 http://cr.openjdk.java.net/~kcr/8199132/webrev.00/ Thanks. -- Kevin From kevin.rushforth at oracle.com Thu Mar 8 19:37:03 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 08 Mar 2018 11:37:03 -0800 Subject: [11] Review request: 8198858: Remove use of internal packages of core modules from unit tests Message-ID: <5AA190DF.3050508@oracle.com> Ajit and Ambarish, Please review the following to cleanup references to internal core packages from our unit tests: https://bugs.openjdk.java.net/browse/JDK-8198858 http://cr.openjdk.java.net/~kcr/8198858/webrev.00/ Thanks. -- Kevin From chris.nahr at gmail.com Fri Mar 9 09:58:24 2018 From: chris.nahr at gmail.com (Chris Nahr) Date: Fri, 9 Mar 2018 10:58:24 +0100 Subject: Text mismeasured at certain Windows DPI levels Message-ID: <37a5df38-e8e8-bb44-9bf6-586503701284@gmail.com> I've found a pretty serious issue with CheckBox labels on Windows DPI levels other than 100% or 200%. Apparently the label mismeasures itself during layout, so its text is cut off with an ellipsis. I've attached a simple program to reproduce this. Running with -Dglass.win.uiScale=100%, 125%, 150%, 175%, 200% cuts off all CheckBox labels on any DPI scale between 100% and 200%. My environment is Java SE 9.0.4 on Windows 10 Creators Update. The only workaround I found was to set an explicit minimum width for the CheckBox. In that case the incorrect self-measurement of the label text is ignored and the full text displayed. Best regards, Christoph Nahr ----- Test Program ----- import javafx.application.*; import javafx.scene.*; import javafx.scene.control.*; import javafx.scene.layout.*; import javafx.stage.*; public class CheckBoxLabel extends Application { public static void main(String[] args) { Application.launch(args); } @Override public void start(Stage stage) { final HBox box = new HBox(); for (int i = 0; i < 4; i++) box.getChildren().add(new CheckBox("Check")); stage.setScene(new Scene(box)); stage.show(); } } From rajath.kamath at oracle.com Fri Mar 9 10:42:14 2018 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Fri, 9 Mar 2018 02:42:14 -0800 (PST) Subject: [11] Review Request - JDK-8088769: Alphachannel for transparent colors is not shown in HtmlEditor In-Reply-To: <7a1cb99f-6191-44d7-bae1-cfaa781982f2@default> References: <7a1cb99f-6191-44d7-bae1-cfaa781982f2@default> Message-ID: Hi Kevin, Murali, Please review this fix for HTMLEditor. Details of the fix mentioned in JBS. JBS : https://bugs.openjdk.java.net/browse/JDK-8088769 WebRev : HYPERLINK "http://cr.openjdk.java.net/%7Erkamath/8088769/webrev.00/" http://cr.openjdk.java.net/~rkamath/8088769/webrev.00/ Thanks, Rajath From bourges.laurent at gmail.com Fri Mar 9 21:14:50 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 9 Mar 2018 22:14:50 +0100 Subject: [11] Review request: JDK-8189689: JavaFX build fails with gcc 6 Message-ID: Kevin, Please review the following webrev that fixes compilation with gcc 6, that was initiated on github by Emmanuel Bourg (@ebourg) in PR #11 and #16 https://bugs.openjdk.java.net/browse/JDK-8189689 http://cr.openjdk.java.net/~lbourges/fx/fx-8189689.0/ Thanks, Laurent From kevin.rushforth at oracle.com Fri Mar 9 21:52:04 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 09 Mar 2018 13:52:04 -0800 Subject: [11] Review request: JDK-8189689: JavaFX build fails with gcc 6 In-Reply-To: References: Message-ID: <5AA30204.3000905@oracle.com> Looks good. +1 -- Kevin Laurent Bourg?s wrote: > Kevin, > > Please review the following webrev that fixes compilation with gcc 6, > that was initiated on github by Emmanuel Bourg (@ebourg) in PR #11 and #16 > > https://bugs.openjdk.java.net/browse/JDK-8189689 > http://cr.openjdk.java.net/~lbourges/fx/fx-8189689.0/ > > > Thanks, > Laurent From sven.reimers at gmail.com Sat Mar 10 22:07:14 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Sat, 10 Mar 2018 23:07:14 +0100 Subject: Test failures running on OS X Message-ID: Hi, getting back into the OpenJFX I started with a fresh clone and ran gradle test.. I got test.javafx.scene.control.SpinnerTest > dblSpinner_testToString_valueInRange FAILED junit.framework.ComparisonFailure: null expected:<0[.]3> but was:<0[,]3> at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at test.javafx.scene.control.SpinnerTest.dblSpinner_testToString_valueInRange(SpinnerTest.java:607) test.javafx.scene.control.SpinnerTest > dblSpinner_testFromString_valueInRange FAILED junit.framework.AssertionFailedError: expected:<0.3> but was:<0.0> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:283) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:71) at test.javafx.scene.control.SpinnerTest.dblSpinner_testFromString_valueInRange(SpinnerTest.java:615) test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCancel FAILED junit.framework.ComparisonFailure: null expected:<2[.]5> but was:<2[,]5> at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testCancel(SpinnerTest.java:1334) test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCommit_valid FAILED junit.framework.AssertionFailedError: expected:<2.5> but was:<2.0> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:283) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:71) at test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testCommit_valid(SpinnerTest.java:1308) This is with gradle 46, 9.0.4 on a german locale OS X... Any ideas what to look for? Thanks Sven From bourges.laurent at gmail.com Sun Mar 11 08:07:33 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sun, 11 Mar 2018 09:07:33 +0100 Subject: Test failures running on OS X In-Reply-To: References: Message-ID: Hi, I confirm I have the same problem on my FR Locale. I added -Duser.language=en to the gradle command line and it worked. Alternatively set LANG=US in your env. It should be fixed in build.gradle... Cheers, Laurent Le 10 mars 2018 11:07 PM, "Sven Reimers" a ?crit : > Hi, > > getting back into the OpenJFX I started with a fresh clone and ran gradle > test.. > > I got > > test.javafx.scene.control.SpinnerTest > > dblSpinner_testToString_valueInRange FAILED > junit.framework.ComparisonFailure: null expected:<0[.]3> but > was:<0[,]3> > at junit.framework.Assert.assertEquals(Assert.java:81) > at junit.framework.Assert.assertEquals(Assert.java:87) > at > test.javafx.scene.control.SpinnerTest.dblSpinner_ > testToString_valueInRange(SpinnerTest.java:607) > > test.javafx.scene.control.SpinnerTest > > dblSpinner_testFromString_valueInRange FAILED > junit.framework.AssertionFailedError: expected:<0.3> but was:<0.0> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:283) > at junit.framework.Assert.assertEquals(Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:71) > at > test.javafx.scene.control.SpinnerTest.dblSpinner_ > testFromString_valueInRange(SpinnerTest.java:615) > > test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCancel FAILED > junit.framework.ComparisonFailure: null expected:<2[.]5> but > was:<2[,]5> > at junit.framework.Assert.assertEquals(Assert.java:81) > at junit.framework.Assert.assertEquals(Assert.java:87) > at > test.javafx.scene.control.SpinnerTest.test_jdk_8150946_ > testCancel(SpinnerTest.java:1334) > > test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCommit_valid > FAILED > junit.framework.AssertionFailedError: expected:<2.5> but was:<2.0> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:283) > at junit.framework.Assert.assertEquals(Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:71) > at > test.javafx.scene.control.SpinnerTest.test_jdk_8150946_ > testCommit_valid(SpinnerTest.java:1308) > > This is with gradle 46, 9.0.4 on a german locale OS X... > > Any ideas what to look for? > > Thanks > > Sven > From chris.nahr at gmail.com Mon Mar 12 10:33:48 2018 From: chris.nahr at gmail.com (Chris Nahr) Date: Mon, 12 Mar 2018 11:33:48 +0100 Subject: Text mismeasured at certain Windows DPI levels In-Reply-To: <37a5df38-e8e8-bb44-9bf6-586503701284@gmail.com> References: <37a5df38-e8e8-bb44-9bf6-586503701284@gmail.com> Message-ID: After some more experimentation I added some details and a screenshot (from another test program) to this blog post: http://news.kynosarges.org/2018/03/11/windows-gui-dpi-scaling-in-2018/ That's about a small test suite for DPI scaling, and it's where I first saw this bug. Like the repro program below these test programs are quite simple. The bug does not seem to occur in more complex real-world programs, but it's reproducible when it does occur and also affects labeled controls other than checkboxes (saw it in buttons). As I wrote in the blog post: My present guess is that on DPI scales that are not multiples of 100%, there is a small discrepancy in the initial measurement between a label's required width and the width provided by its container. In complex windows this gets eventually fixed by subsequent layout passes, but in simple windows the error persists and manifests as an ellipsis. -- Christoph Nahr On 2018-03-09 10:58, Chris Nahr wrote: > I've found a pretty serious issue with CheckBox labels on Windows DPI > levels other than 100% or 200%. Apparently the label mismeasures itself > during layout, so its text is cut off with an ellipsis. > > I've attached a simple program to reproduce this. Running with > -Dglass.win.uiScale=100%, 125%, 150%, 175%, 200% cuts off all CheckBox > labels on any DPI scale between 100% and 200%. My environment is Java SE > 9.0.4 on Windows 10 Creators Update. > > The only workaround I found was to set an explicit minimum width for the > CheckBox. In that case the incorrect self-measurement of the label text > is ignored and the full text displayed. > > Best regards, > Christoph Nahr > > > ----- Test Program ----- > > import javafx.application.*; > import javafx.scene.*; > import javafx.scene.control.*; > import javafx.scene.layout.*; > import javafx.stage.*; > > public class CheckBoxLabel extends Application { > > ??? public static void main(String[] args) { > ??????? Application.launch(args); > ??? } > > ??? @Override > ??? public void start(Stage stage) { > ??????? final HBox box = new HBox(); > ??????? for (int i = 0; i < 4; i++) > ??????????? box.getChildren().add(new CheckBox("Check")); > > ??????? stage.setScene(new Scene(box)); > ??????? stage.show(); > ??? } > } > From kevin.rushforth at oracle.com Mon Mar 12 15:02:00 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Mar 2018 08:02:00 -0700 Subject: Text mismeasured at certain Windows DPI levels In-Reply-To: References: <37a5df38-e8e8-bb44-9bf6-586503701284@gmail.com> Message-ID: <5AA69668.3050902@oracle.com> Since you have a simple test program that reproduces this bug, can you please file a bug report? http://bugreport.java.com/ Thanks. -- Kevin Chris Nahr wrote: > After some more experimentation I added some details and a screenshot > (from another test program) to this blog post: > http://news.kynosarges.org/2018/03/11/windows-gui-dpi-scaling-in-2018/ > > That's about a small test suite for DPI scaling, and it's where I > first saw this bug. Like the repro program below these test programs > are quite simple. The bug does not seem to occur in more complex > real-world programs, but it's reproducible when it does occur and also > affects labeled controls other than checkboxes (saw it in buttons). > > As I wrote in the blog post: My present guess is that on DPI scales > that are not multiples of 100%, there is a small discrepancy in the > initial measurement between a label's required width and the width > provided by its container. In complex windows this gets eventually > fixed by subsequent layout passes, but in simple windows the error > persists and manifests as an ellipsis. > > -- Christoph Nahr > > > On 2018-03-09 10:58, Chris Nahr wrote: >> I've found a pretty serious issue with CheckBox labels on Windows DPI >> levels other than 100% or 200%. Apparently the label mismeasures >> itself during layout, so its text is cut off with an ellipsis. >> >> I've attached a simple program to reproduce this. Running with >> -Dglass.win.uiScale=100%, 125%, 150%, 175%, 200% cuts off all >> CheckBox labels on any DPI scale between 100% and 200%. My >> environment is Java SE 9.0.4 on Windows 10 Creators Update. >> >> The only workaround I found was to set an explicit minimum width for >> the CheckBox. In that case the incorrect self-measurement of the >> label text is ignored and the full text displayed. >> >> Best regards, >> Christoph Nahr >> >> >> ----- Test Program ----- >> >> import javafx.application.*; >> import javafx.scene.*; >> import javafx.scene.control.*; >> import javafx.scene.layout.*; >> import javafx.stage.*; >> >> public class CheckBoxLabel extends Application { >> >> public static void main(String[] args) { >> Application.launch(args); >> } >> >> @Override >> public void start(Stage stage) { >> final HBox box = new HBox(); >> for (int i = 0; i < 4; i++) >> box.getChildren().add(new CheckBox("Check")); >> >> stage.setScene(new Scene(box)); >> stage.show(); >> } >> } >> From kevin.rushforth at oracle.com Mon Mar 12 15:09:28 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Mar 2018 08:09:28 -0700 Subject: Test failures running on OS X In-Reply-To: References: Message-ID: <5AA69828.1030508@oracle.com> I haven't run these with a Locale other than en_US, but given the nature of the failure, it looks like you may have discovered another Locale-related test bug. We had another test that was fixed by setting the default Locale to Locale.US in a static @BeforeClass method in the test class [1]. Perhaps a similar solution is needed here. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8160039 Sven Reimers wrote: > Hi, > > getting back into the OpenJFX I started with a fresh clone and ran gradle > test.. > > I got > > test.javafx.scene.control.SpinnerTest > > dblSpinner_testToString_valueInRange FAILED > junit.framework.ComparisonFailure: null expected:<0[.]3> but was:<0[,]3> > at junit.framework.Assert.assertEquals(Assert.java:81) > at junit.framework.Assert.assertEquals(Assert.java:87) > at > test.javafx.scene.control.SpinnerTest.dblSpinner_testToString_valueInRange(SpinnerTest.java:607) > > test.javafx.scene.control.SpinnerTest > > dblSpinner_testFromString_valueInRange FAILED > junit.framework.AssertionFailedError: expected:<0.3> but was:<0.0> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:283) > at junit.framework.Assert.assertEquals(Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:71) > at > test.javafx.scene.control.SpinnerTest.dblSpinner_testFromString_valueInRange(SpinnerTest.java:615) > > test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCancel FAILED > junit.framework.ComparisonFailure: null expected:<2[.]5> but was:<2[,]5> > at junit.framework.Assert.assertEquals(Assert.java:81) > at junit.framework.Assert.assertEquals(Assert.java:87) > at > test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testCancel(SpinnerTest.java:1334) > > test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCommit_valid > FAILED > junit.framework.AssertionFailedError: expected:<2.5> but was:<2.0> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:283) > at junit.framework.Assert.assertEquals(Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:71) > at > test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testCommit_valid(SpinnerTest.java:1308) > > This is with gradle 46, 9.0.4 on a german locale OS X... > > Any ideas what to look for? > > Thanks > > Sven > From bourges.laurent at gmail.com Mon Mar 12 15:51:12 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 12 Mar 2018 16:51:12 +0100 Subject: Test failures running on OS X In-Reply-To: <5AA69828.1030508@oracle.com> References: <5AA69828.1030508@oracle.com> Message-ID: Kevin, It is possible to define the Locale (set user.language=...) in the gradle build file, that would avoid touching the java code at all. I have no opinion what is preferable to have less maintenance work or problems in future. Laurent 2018-03-12 16:09 GMT+01:00 Kevin Rushforth : > I haven't run these with a Locale other than en_US, but given the nature > of the failure, it looks like you may have discovered another > Locale-related test bug. > > We had another test that was fixed by setting the default Locale to > Locale.US in a static @BeforeClass method in the test class [1]. Perhaps a > similar solution is needed here. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8160039 > > > > Sven Reimers wrote: > >> Hi, >> >> getting back into the OpenJFX I started with a fresh clone and ran gradle >> test.. >> >> I got >> >> test.javafx.scene.control.SpinnerTest > >> dblSpinner_testToString_valueInRange FAILED >> junit.framework.ComparisonFailure: null expected:<0[.]3> but >> was:<0[,]3> >> at junit.framework.Assert.assertEquals(Assert.java:81) >> at junit.framework.Assert.assertEquals(Assert.java:87) >> at >> test.javafx.scene.control.SpinnerTest.dblSpinner_testToStrin >> g_valueInRange(SpinnerTest.java:607) >> >> test.javafx.scene.control.SpinnerTest > >> dblSpinner_testFromString_valueInRange FAILED >> junit.framework.AssertionFailedError: expected:<0.3> but was:<0.0> >> at junit.framework.Assert.fail(Assert.java:47) >> at junit.framework.Assert.failNotEquals(Assert.java:283) >> at junit.framework.Assert.assertEquals(Assert.java:64) >> at junit.framework.Assert.assertEquals(Assert.java:71) >> at >> test.javafx.scene.control.SpinnerTest.dblSpinner_testFromStr >> ing_valueInRange(SpinnerTest.java:615) >> >> test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCancel >> FAILED >> junit.framework.ComparisonFailure: null expected:<2[.]5> but >> was:<2[,]5> >> at junit.framework.Assert.assertEquals(Assert.java:81) >> at junit.framework.Assert.assertEquals(Assert.java:87) >> at >> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testC >> ancel(SpinnerTest.java:1334) >> >> test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCommit_valid >> FAILED >> junit.framework.AssertionFailedError: expected:<2.5> but was:<2.0> >> at junit.framework.Assert.fail(Assert.java:47) >> at junit.framework.Assert.failNotEquals(Assert.java:283) >> at junit.framework.Assert.assertEquals(Assert.java:64) >> at junit.framework.Assert.assertEquals(Assert.java:71) >> at >> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testC >> ommit_valid(SpinnerTest.java:1308) >> >> This is with gradle 46, 9.0.4 on a german locale OS X... >> >> Any ideas what to look for? >> >> Thanks >> >> Sven >> >> > -- -- Laurent Bourg?s From kevin.rushforth at oracle.com Mon Mar 12 15:55:35 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Mar 2018 08:55:35 -0700 Subject: Test failures running on OS X In-Reply-To: References: <5AA69828.1030508@oracle.com> Message-ID: <5AA6A2F7.1030707@oracle.com> Laurent Bourg?s wrote: > Kevin, > > It is possible to define the Locale (set user.language=...) in the > gradle build file, that would avoid touching the java code at all. I suppose this could be done, and if there are many such failing tests, it might be an OK short-term solution. It's probably not the best long-term solution, since I think it is better for any test that is sensitive to the Locale to set it in the test itself. Sven: if you run using the --continue option (so it won't stop after the first batch of failing tests), are there any more tests that fail in other modules? -- Kevin > > I have no opinion what is preferable to have less maintenance work or > problems in future. > > Laurent > > 2018-03-12 16:09 GMT+01:00 Kevin Rushforth >: > > I haven't run these with a Locale other than en_US, but given the > nature of the failure, it looks like you may have discovered > another Locale-related test bug. > > We had another test that was fixed by setting the default Locale > to Locale.US in a static @BeforeClass method in the test class > [1]. Perhaps a similar solution is needed here. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8160039 > > > > > Sven Reimers wrote: > > Hi, > > getting back into the OpenJFX I started with a fresh clone and > ran gradle > test.. > > I got > > test.javafx.scene.control.SpinnerTest > > dblSpinner_testToString_valueInRange FAILED > junit.framework.ComparisonFailure: null expected:<0[.]3> > but was:<0[,]3> > at junit.framework.Assert.assertEquals(Assert.java:81) > at junit.framework.Assert.assertEquals(Assert.java:87) > at > test.javafx.scene.control.SpinnerTest.dblSpinner_testToString_valueInRange(SpinnerTest.java:607) > > test.javafx.scene.control.SpinnerTest > > dblSpinner_testFromString_valueInRange FAILED > junit.framework.AssertionFailedError: expected:<0.3> but > was:<0.0> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:283) > at junit.framework.Assert.assertEquals(Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:71) > at > test.javafx.scene.control.SpinnerTest.dblSpinner_testFromString_valueInRange(SpinnerTest.java:615) > > test.javafx.scene.control.SpinnerTest > > test_jdk_8150946_testCancel FAILED > junit.framework.ComparisonFailure: null expected:<2[.]5> > but was:<2[,]5> > at junit.framework.Assert.assertEquals(Assert.java:81) > at junit.framework.Assert.assertEquals(Assert.java:87) > at > test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testCancel(SpinnerTest.java:1334) > > test.javafx.scene.control.SpinnerTest > > test_jdk_8150946_testCommit_valid > FAILED > junit.framework.AssertionFailedError: expected:<2.5> but > was:<2.0> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:283) > at junit.framework.Assert.assertEquals(Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:71) > at > test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testCommit_valid(SpinnerTest.java:1308) > > This is with gradle 46, 9.0.4 on a german locale OS X... > > Any ideas what to look for? > > Thanks > > Sven > > > > > > -- > -- > Laurent Bourg?s From nlisker at gmail.com Mon Mar 12 20:38:09 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 12 Mar 2018 22:38:09 +0200 Subject: JDK-8130379: Enhance the Bounds class with getCenter method Message-ID: Hello, I would like to work on https://bugs.openjdk.java.net/browse/JDK-8130379, which adds convenience API to the Bounds class. Any comments? - Nir From kevin.rushforth at oracle.com Mon Mar 12 21:07:11 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Mar 2018 14:07:11 -0700 Subject: JDK-8130379: Enhance the Bounds class with getCenter method In-Reply-To: References: Message-ID: <5AA6EBFF.1030509@oracle.com> Hi Nir, This seems like a simple enough RFE, and I am not aware of anyone else working on it, nor any barriers that would make it difficult. As with any RFE that adds API (or implements a new feature) the API additions will need to be approved first. Currently we use the CSR process [1][2], but we will want to change that at some point. Note that as indicated in the "More community participation in JavaFX" thread [3], new API / new features will still have a higher bar for acceptance than bug fixes. Also, any new feature needs to be accompanied by API docs and tests. Thanks! -- Kevin [1] https://wiki.openjdk.java.net/display/csr/Main [2] https://wiki.openjdk.java.net/display/csr/CSR+FAQs [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021335.html Nir Lisker wrote: > Hello, > > I would like to work on https://bugs.openjdk.java.net/browse/JDK-8130379, > which adds convenience API to the Bounds class. Any comments? > > - Nir > From fbrunnerlist at gmx.ch Mon Mar 12 22:16:05 2018 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Mon, 12 Mar 2018 23:16:05 +0100 Subject: Removal of apps/scenebuilder from OpenJFX repo In-Reply-To: <5A9985EF.5000701@oracle.com> References: <5A9985EF.5000701@oracle.com> Message-ID: <4846435.J8drcGo0IV@andor> OK, this still comes a bit as a surprise as the source code has been kept in the repo and was not just provided as a ZIP file. I'm currently working on a tool based on the SceneBuilder Kit. I needed to work on the code a bit and was planning to donate the code back to OpenJFX once released, as I was under the impression OpenJFX would serve as the master / upstream-repo for all SceneBuilder forks. I was also under the impression that OpenJFX at least would make sure the code works with any new JDK / JavaFX version and hoped it would get support for new controls, if any were added to JavaFX. -Florian Am Freitag, 2. M?rz 2018, 09:12:15 CET schrieb Kevin Rushforth: > I filed the following JBS isuse to remova the SceneBuilder sources from > the OpenJFX repo. > > https://bugs.openjdk.java.net/browse/JDK-8198961 > > As mentioned in the Description of that issue, the OpenJFX repo contains > the source code for a no-longer-maintained version of the SceneBuilder > tool. Active development on SceneBuilder in the OpenJFX repo was stopped > over three years ago. Since that time, the only changes have been either > jigsaw-related changes to keep it buildable and runnable, or global > changes that happened to touch some of the files in apps/scenebuilder. > > A fork of SceneBuilder is maintained by Gluon, so anyone wanting to get > the latest SceneBuilder should go there. > > Before I proceed, I wanted to poll the list to see whether anyone has a > concern with this. I don't plan to take any action for at least a week. > > -- Kevin > > From kevin.rushforth at oracle.com Mon Mar 12 22:25:08 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Mar 2018 15:25:08 -0700 Subject: Removal of apps/scenebuilder from OpenJFX repo In-Reply-To: <4846435.J8drcGo0IV@andor> References: <5A9985EF.5000701@oracle.com> <4846435.J8drcGo0IV@andor> Message-ID: <5AA6FE44.5000609@oracle.com> Hi Florian, By way of update, after thinking about this for a week (and getting some offline feedback), I no longer propose doing this -- at least not for the short-mid term. I've retargeted this RFE to tbd_major and lowered the priority to P4. Having said that, we don't have any plans to modify SceneBuilder, but will happily accept contributions. -- Kevin Florian Brunner wrote: > OK, this still comes a bit as a surprise as the source code has been kept in the repo and was not just provided as a ZIP file. > > I'm currently working on a tool based on the SceneBuilder Kit. I needed to work on the code a bit and was planning to donate the code back to OpenJFX once released, as I was under the impression OpenJFX would serve as the master / upstream-repo for all SceneBuilder forks. I was also under the impression that OpenJFX at least would make sure the code works with any new JDK / JavaFX version and hoped it would get support for new controls, if any were added to JavaFX. > > -Florian > > Am Freitag, 2. M?rz 2018, 09:12:15 CET schrieb Kevin Rushforth: > >> I filed the following JBS isuse to remova the SceneBuilder sources from >> the OpenJFX repo. >> >> https://bugs.openjdk.java.net/browse/JDK-8198961 >> >> As mentioned in the Description of that issue, the OpenJFX repo contains >> the source code for a no-longer-maintained version of the SceneBuilder >> tool. Active development on SceneBuilder in the OpenJFX repo was stopped >> over three years ago. Since that time, the only changes have been either >> jigsaw-related changes to keep it buildable and runnable, or global >> changes that happened to touch some of the files in apps/scenebuilder. >> >> A fork of SceneBuilder is maintained by Gluon, so anyone wanting to get >> the latest SceneBuilder should go there. >> >> Before I proceed, I wanted to poll the list to see whether anyone has a >> concern with this. I don't plan to take any action for at least a week. >> >> -- Kevin >> >> >> > > > From chris.nahr at gmail.com Tue Mar 13 08:23:20 2018 From: chris.nahr at gmail.com (Chris Nahr) Date: Tue, 13 Mar 2018 09:23:20 +0100 Subject: Text mismeasured at certain Windows DPI levels In-Reply-To: <5AA69668.3050902@oracle.com> References: <37a5df38-e8e8-bb44-9bf6-586503701284@gmail.com> <5AA69668.3050902@oracle.com> Message-ID: OK, I filed a bug report with internal review ID 9052971. Interestingly, merely calling sizeToScene explicitly (which shouldn't be necessary though) fixes the bug at 125% and 150% but not at 175%. I added that info to the report and the test program. Thanks, Chris On 2018-03-12 16:02, Kevin Rushforth wrote: > Since you have a simple test program that reproduces this bug, can you > please file a bug report? > > http://bugreport.java.com/ > > Thanks. > > -- Kevin > > Chris Nahr wrote: >> After some more experimentation I added some details and a screenshot >> (from another test program) to this blog post: >> http://news.kynosarges.org/2018/03/11/windows-gui-dpi-scaling-in-2018/ >> >> That's about a small test suite for DPI scaling, and it's where I >> first saw this bug. Like the repro program below these test programs >> are quite simple. The bug does not seem to occur in more complex >> real-world programs, but it's reproducible when it does occur and also >> affects labeled controls other than checkboxes (saw it in buttons). >> >> As I wrote in the blog post: My present guess is that on DPI scales >> that are not multiples of 100%, there is a small discrepancy in the >> initial measurement between a label's required width and the width >> provided by its container. In complex windows this gets eventually >> fixed by subsequent layout passes, but in simple windows the error >> persists and manifests as an ellipsis. >> >> -- Christoph Nahr >> >> >> On 2018-03-09 10:58, Chris Nahr wrote: >>> I've found a pretty serious issue with CheckBox labels on Windows DPI >>> levels other than 100% or 200%. Apparently the label mismeasures >>> itself during layout, so its text is cut off with an ellipsis. >>> >>> I've attached a simple program to reproduce this. Running with >>> -Dglass.win.uiScale=100%, 125%, 150%, 175%, 200% cuts off all >>> CheckBox labels on any DPI scale between 100% and 200%. My >>> environment is Java SE 9.0.4 on Windows 10 Creators Update. >>> >>> The only workaround I found was to set an explicit minimum width for >>> the CheckBox. In that case the incorrect self-measurement of the >>> label text is ignored and the full text displayed. >>> >>> Best regards, >>> Christoph Nahr >>> >>> >>> ----- Test Program ----- >>> >>> import javafx.application.*; >>> import javafx.scene.*; >>> import javafx.scene.control.*; >>> import javafx.scene.layout.*; >>> import javafx.stage.*; >>> >>> public class CheckBoxLabel extends Application { >>> >>> ???? public static void main(String[] args) { >>> ???????? Application.launch(args); >>> ???? } >>> >>> ???? @Override >>> ???? public void start(Stage stage) { >>> ???????? final HBox box = new HBox(); >>> ???????? for (int i = 0; i < 4; i++) >>> ???????????? box.getChildren().add(new CheckBox("Check")); >>> >>> ???????? stage.setScene(new Scene(box)); >>> ???????? stage.show(); >>> ???? } >>> } >>> > From kevin.rushforth at oracle.com Tue Mar 13 12:54:53 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 13 Mar 2018 05:54:53 -0700 Subject: Text mismeasured at certain Windows DPI levels In-Reply-To: References: <37a5df38-e8e8-bb44-9bf6-586503701284@gmail.com> <5AA69668.3050902@oracle.com> Message-ID: <5AA7CA1D.1000705@oracle.com> Thanks. We'll take a look. It's possible this is related to other bugs with initial sizing that were introduced with HiDPI spuport (although that wouldn't explain the continued failure at 175%). -- Kevin Chris Nahr wrote: > OK, I filed a bug report with internal review ID 9052971. > Interestingly, merely calling sizeToScene explicitly (which shouldn't > be necessary though) fixes the bug at 125% and 150% but not at 175%. I > added that info to the report and the test program. > > Thanks, Chris > > > On 2018-03-12 16:02, Kevin Rushforth wrote: >> Since you have a simple test program that reproduces this bug, can >> you please file a bug report? >> >> http://bugreport.java.com/ >> >> Thanks. >> >> -- Kevin >> >> Chris Nahr wrote: >>> After some more experimentation I added some details and a >>> screenshot (from another test program) to this blog post: >>> http://news.kynosarges.org/2018/03/11/windows-gui-dpi-scaling-in-2018/ >>> >>> That's about a small test suite for DPI scaling, and it's where I >>> first saw this bug. Like the repro program below these test programs >>> are quite simple. The bug does not seem to occur in more complex >>> real-world programs, but it's reproducible when it does occur and >>> also affects labeled controls other than checkboxes (saw it in >>> buttons). >>> >>> As I wrote in the blog post: My present guess is that on DPI scales >>> that are not multiples of 100%, there is a small discrepancy in the >>> initial measurement between a label's required width and the width >>> provided by its container. In complex windows this gets eventually >>> fixed by subsequent layout passes, but in simple windows the error >>> persists and manifests as an ellipsis. >>> >>> -- Christoph Nahr >>> >>> >>> On 2018-03-09 10:58, Chris Nahr wrote: >>>> I've found a pretty serious issue with CheckBox labels on Windows >>>> DPI levels other than 100% or 200%. Apparently the label >>>> mismeasures itself during layout, so its text is cut off with an >>>> ellipsis. >>>> >>>> I've attached a simple program to reproduce this. Running with >>>> -Dglass.win.uiScale=100%, 125%, 150%, 175%, 200% cuts off all >>>> CheckBox labels on any DPI scale between 100% and 200%. My >>>> environment is Java SE 9.0.4 on Windows 10 Creators Update. >>>> >>>> The only workaround I found was to set an explicit minimum width >>>> for the CheckBox. In that case the incorrect self-measurement of >>>> the label text is ignored and the full text displayed. >>>> >>>> Best regards, >>>> Christoph Nahr >>>> >>>> >>>> ----- Test Program ----- >>>> >>>> import javafx.application.*; >>>> import javafx.scene.*; >>>> import javafx.scene.control.*; >>>> import javafx.scene.layout.*; >>>> import javafx.stage.*; >>>> >>>> public class CheckBoxLabel extends Application { >>>> >>>> public static void main(String[] args) { >>>> Application.launch(args); >>>> } >>>> >>>> @Override >>>> public void start(Stage stage) { >>>> final HBox box = new HBox(); >>>> for (int i = 0; i < 4; i++) >>>> box.getChildren().add(new CheckBox("Check")); >>>> >>>> stage.setScene(new Scene(box)); >>>> stage.show(); >>>> } >>>> } >>>> >> From nlisker at gmail.com Tue Mar 13 14:02:43 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 13 Mar 2018 16:02:43 +0200 Subject: Updating class javafx.beans.binding.When In-Reply-To: References: <5A84F8B2.3040703@oracle.com> <5A875139.8000901@oracle.com> Message-ID: Solved the configuration issues, so I'm continuing with this. I submitted https://bugs.openjdk.java.net/browse/JDK-8199514 for the refactoring part. As for https://bugs.openjdk.java.net/browse/JDK-8089579, should it be closed as Not an Issue and a new issue created for the new API propasal, or should it be retrofitted? - Nir On Tue, Feb 20, 2018 at 12:45 PM, Nir Lisker wrote: > OK, let's wait with this until I figure out if there's a problem with the > test suit. > > On Fri, Feb 16, 2018 at 11:46 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> This will take me a bit more time to look at than I have right now (and >> Monday is a US holiday), so one quick comment for now: >> >> The refactoring must not alter any public API signatures for exported >> packagers, and must be behavior neutral. So if there are unit tests that >> pass without your fix and fail with your fix, then you will need to alter >> your fix, unless you can show that the tests are testing an implementation >> detail that would not affect an application that just uses public API. >> >> >> -- Kevin >> >> >> Nir Lisker wrote: >> >> Let's start with the refactoring then. Before I submit a bug let's check >> that this plan makes sense. Attached webrev for discussion. >> >> Changes: >> * Main change was to the XxxCondition classes. Instead of having 4 >> combinations of primitives and observables I used the unification approach >> that NumberConditionBuilder took with wrapping the value in a constant >> observable. I also replaced these classes with a generic wrappers >> XxxConditionHolders which hold the binding part of the XxxCondition class. >> >> * I attempted to generify XxxConditionBuilders as well. The attempt is >> ConditionBuilder and an example implementation was done for boolean only - >> BooleanConditionBuilder2. I think that it doesn't gain much. >> >> * Added BooleanConstant class in internal API (it was missing for some >> reason). >> >> * The handling of Numbers in the original class is a bit weird in my >> eyes. The compile time return types are DoubleBinding if one or both values >> are double and NumberBinding otherwise [1]. On the other hand, the runtime >> return types takes special care to return a binding class based on widening >> conventions and the docs don't mention anything about that. In my change, >> the runtime type is always DoubleBinding (though I kept a placeholder >> if-else chain) and that saves some code. The user can always call >> floatValue() etc. anyway. >> >> Between backwards compatibility and limitations of generics this is the >> best I could come up with. >> >> Additional notes: >> >> * Running the tests from gradle causes some of the When tests to fail and >> I don't know why, it's hard to debug. I wrote my own ad-hoc test for one of >> the failed tests and it passes. >> >> * I noticed that StringConstant extends StringExpression while all the >> other classes just implement their respective ObservableXxxValue. Don't >> know why, but I can align these classes to one of those choices. >> >> [1] https://docs.oracle.com/javase/9/docs/api/javafx/beans/ >> binding/When.NumberConditionBuilder.html >> >> On Thu, Feb 15, 2018 at 5:04 AM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> Sorry for the delay in responding. I was traveling when this was sent >>> and barely able to keep up with urgent email / tasks. >>> >>> Most of what you suggest below seems good. My only concern is whether >>> the "on demand" evaluation will have any side effects. Conceptually, it >>> seems like the right thing to do. >>> >>> The refactoring you propose is probably best done as a separate bug fix, >>> so that we don't mix behavioral changes with refactoring, unless you think >>> that the refactoring is intertwined with the fix. >>> >>> If you would like to work on a fix, that would be good. It will need to >>> include new unit tests, plus ensuring that the existing unit tests pass. >>> >>> Thanks. >>> >>> -- Kevin >>> >>> >>> >>> Nir Lisker wrote: >>> >>>> Hi, >>>> >>>> I was looking at https://bugs.openjdk.java.net/browse/JDK-8089579, >>>> which >>>> prompted me to have a look at When. There are a few points I would like >>>> to >>>> address: >>>> >>>> * StringConditionBuilder#otherwise(ObservableStringValue) does not >>>> check >>>> for null as other condition builders do. This results in a deeper NPE >>>> when StringCondition tries to register a listener to the >>>> ObservableStringValue. >>>> >>>> * I would like a (re)evaluation on the above bug ticket and thoughts on >>>> the >>>> proposal of "on demand evaluation" using a Supplier or a similar method. >>>> The behavior of the intended implementation would be to evaluate 'then' >>>> and >>>> 'otherwise' whenever their condition is met, and only then. >>>> >>>> * The class can benefit from some small refactoring, such as using >>>> Objects.requireNonNull for null checks and some code reuse to reduce the >>>> chance of bugs such as the missing null check of StringConditionBuilder. >>>> >>>> * There are a few Javadoc corrections and some clarifications of the >>>> current behavior could be beneficial as well. >>>> >>>> I can work on all of the above. How to proceed? >>>> >>>> - Nir >>>> >>>> >>> >> > From kevin.rushforth at oracle.com Tue Mar 13 14:26:18 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 13 Mar 2018 07:26:18 -0700 Subject: Updating class javafx.beans.binding.When In-Reply-To: References: <5A84F8B2.3040703@oracle.com> <5A875139.8000901@oracle.com> Message-ID: <5AA7DF8A.4070502@oracle.com> Nir Lisker wrote: > Solved the configuration issues, so I'm continuing with this. > > I submitted https://bugs.openjdk.java.net/browse/JDK-8199514 for the > refactoring part. As mentioned before, this seems OK long as the refactoring is behavior-neutral and limited in scope. > As for https://bugs.openjdk.java.net/browse/JDK-8089579, should it be > closed as Not an Issue and a new issue created for the new API > propasal, or should it be retrofitted? What new public API are you envisioning to propose? I would recommend to file a new Enhancement request, but leave the existing bug open (you can link it to the new RFE) until there is agreement on any new API, and until we know it solves the problem specified in the bug report. -- Kevin > - Nir > > On Tue, Feb 20, 2018 at 12:45 PM, Nir Lisker > wrote: > > OK, let's wait with this until I figure out if there's a problem > with the test suit. > > On Fri, Feb 16, 2018 at 11:46 PM, Kevin Rushforth > > > wrote: > > This will take me a bit more time to look at than I have right > now (and Monday is a US holiday), so one quick comment for now: > > The refactoring must not alter any public API signatures for > exported packagers, and must be behavior neutral. So if there > are unit tests that pass without your fix and fail with your > fix, then you will need to alter your fix, unless you can show > that the tests are testing an implementation detail that would > not affect an application that just uses public API. > > > -- Kevin > > > Nir Lisker wrote: >> Let's start with the refactoring then. Before I submit a bug >> let's check that this plan makes sense. Attached webrev for >> discussion. >> >> Changes: >> * Main change was to the XxxCondition classes. Instead of >> having 4 combinations of primitives and observables I used >> the unification approach that NumberConditionBuilder took >> with wrapping the value in a constant observable. I also >> replaced these classes with a generic wrappers >> XxxConditionHolders which hold the binding part of the >> XxxCondition class. >> >> * I attempted to generify XxxConditionBuilders as well. The >> attempt is ConditionBuilder and an example implementation was >> done for boolean only - BooleanConditionBuilder2. I think >> that it doesn't gain much. >> >> * Added BooleanConstant class in internal API (it was missing >> for some reason). >> >> * The handling of Numbers in the original class is a bit >> weird in my eyes. The compile time return types are >> DoubleBinding if one or both values are double and >> NumberBinding otherwise [1]. On the other hand, the runtime >> return types takes special care to return a binding class >> based on widening conventions and the docs don't mention >> anything about that. In my change, the runtime type is always >> DoubleBinding (though I kept a placeholder if-else chain) and >> that saves some code. The user can always call floatValue() >> etc. anyway. >> >> Between backwards compatibility and limitations of generics >> this is the best I could come up with. >> >> Additional notes: >> >> * Running the tests from gradle causes some of the When tests >> to fail and I don't know why, it's hard to debug. I wrote my >> own ad-hoc test for one of the failed tests and it passes. >> >> * I noticed that StringConstant extends StringExpression >> while all the other classes just implement their >> respective ObservableXxxValue. Don't know why, but I can >> align these classes to one of those choices. >> >> [1] https://docs.oracle.com/javase/9/docs/api/javafx/beans/binding/When.NumberConditionBuilder.html >> >> >> On Thu, Feb 15, 2018 at 5:04 AM, Kevin Rushforth >> > > wrote: >> >> Sorry for the delay in responding. I was traveling when >> this was sent and barely able to keep up with urgent >> email / tasks. >> >> Most of what you suggest below seems good. My only >> concern is whether the "on demand" evaluation will have >> any side effects. Conceptually, it seems like the right >> thing to do. >> >> The refactoring you propose is probably best done as a >> separate bug fix, so that we don't mix behavioral changes >> with refactoring, unless you think that the refactoring >> is intertwined with the fix. >> >> If you would like to work on a fix, that would be good. >> It will need to include new unit tests, plus ensuring >> that the existing unit tests pass. >> >> Thanks. >> >> -- Kevin >> >> >> >> Nir Lisker wrote: >> >> Hi, >> >> I was looking at >> https://bugs.openjdk.java.net/browse/JDK-8089579 >> , which >> prompted me to have a look at When. There are a few >> points I would like to >> address: >> >> * >> StringConditionBuilder#otherwise(ObservableStringValue) >> does not check >> for null as other condition builders do. This results >> in a deeper NPE >> when StringCondition tries to register a listener to the >> ObservableStringValue. >> >> * I would like a (re)evaluation on the above bug >> ticket and thoughts on the >> proposal of "on demand evaluation" using a Supplier >> or a similar method. >> The behavior of the intended implementation would be >> to evaluate 'then' and >> 'otherwise' whenever their condition is met, and only >> then. >> >> * The class can benefit from some small refactoring, >> such as using >> Objects.requireNonNull for null checks and some code >> reuse to reduce the >> chance of bugs such as the missing null check of >> StringConditionBuilder. >> >> * There are a few Javadoc corrections and some >> clarifications of the >> current behavior could be beneficial as well. >> >> I can work on all of the above. How to proceed? >> >> - Nir >> >> >> > > From nlisker at gmail.com Tue Mar 13 15:24:32 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 13 Mar 2018 17:24:32 +0200 Subject: Review Request: JDK-8199514: Refactor binding.When Message-ID: Hi, Please review preliminary fix for: https://bugs.openjdk.java.net/browse/JDK-8199514 http://cr.openjdk.java.net/~nlisker/8199514/webrev.00/ Thanks, Nir From kevin.rushforth at oracle.com Tue Mar 13 15:42:41 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 13 Mar 2018 08:42:41 -0700 Subject: Review Request: JDK-8199514: Refactor binding.When In-Reply-To: References: Message-ID: <5AA7F171.4090501@oracle.com> I took a quick look and had one comment: public class BooleanConditionBuilder2 extends ConditionBuilder { ... } As I understand it, you have added this as a possible refactoring for BooleanConditionBuilder (but left the original in for comparison), right? Since this would constitute a public API change, I don't think it should be done as part of this RFE. Otherwise, it becomes more than just a behavior-neutral implementation refactoring, and would need to be looked at as an API change, with all that entails. It will be a couple days before I can look at the rest. -- Kevin Nir Lisker wrote: > Hi, > > Please review preliminary fix for: > > https://bugs.openjdk.java.net/browse/JDK-8199514 > http://cr.openjdk.java.net/~nlisker/8199514/webrev.00/ > > Thanks, > Nir > From nlisker at gmail.com Tue Mar 13 15:55:36 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 13 Mar 2018 17:55:36 +0200 Subject: Review Request: JDK-8199514: Refactor binding.When In-Reply-To: <5AA7F171.4090501@oracle.com> References: <5AA7F171.4090501@oracle.com> Message-ID: > > As I understand it, you have added this as a possible refactoring for > BooleanConditionBuilder (but left the original in for comparison), right? Yes. I took Boolean as an example to demonstrate the approach. Since this would constitute a public API change, I don't think it should be > done as part of this RFE. I'm not sure what that change is. Is it extending the private ConditionBuilder class? It will be a couple days before I can look at the rest. No problem. -Nir On Tue, Mar 13, 2018 at 5:42 PM, Kevin Rushforth wrote: > I took a quick look and had one comment: > > public class BooleanConditionBuilder2 extends ConditionBuilder BooleanBinding> { ... } > > As I understand it, you have added this as a possible refactoring for > BooleanConditionBuilder (but left the original in for comparison), right? > Since this would constitute a public API change, I don't think it should be > done as part of this RFE. Otherwise, it becomes more than just a > behavior-neutral implementation refactoring, and would need to be looked at > as an API change, with all that entails. > > It will be a couple days before I can look at the rest. > > -- Kevin > > > > Nir Lisker wrote: > >> Hi, >> >> Please review preliminary fix for: >> >> https://bugs.openjdk.java.net/browse/JDK-8199514 >> http://cr.openjdk.java.net/~nlisker/8199514/webrev.00/ >> >> Thanks, >> Nir >> >> > From kevin.rushforth at oracle.com Tue Mar 13 16:53:45 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 13 Mar 2018 09:53:45 -0700 Subject: Review Request: JDK-8199514: Refactor binding.When In-Reply-To: References: <5AA7F171.4090501@oracle.com> Message-ID: <5AA80219.5030804@oracle.com> Nir Lisker wrote: > > As I understand it, you have added this as a possible refactoring > for BooleanConditionBuilder (but left the original in for > comparison), right? > > > Yes. I took Boolean as an example to demonstrate the approach. > > Since this would constitute a public API change, I don't think it > should be done as part of this RFE. > > > I'm not sure what that change is. Is it extending the > private ConditionBuilder class? Yes. This becomes part of the public API at that point. Also, it generally isn't a good practice for a public class to extend non-public classes, so that would need to be considered. -- Kevin > > It will be a couple days before I can look at the rest. > > > No problem. > > -Nir > > On Tue, Mar 13, 2018 at 5:42 PM, Kevin Rushforth > > wrote: > > I took a quick look and had one comment: > > public class BooleanConditionBuilder2 extends > ConditionBuilder { ... } > > As I understand it, you have added this as a possible refactoring > for BooleanConditionBuilder (but left the original in for > comparison), right? Since this would constitute a public API > change, I don't think it should be done as part of this RFE. > Otherwise, it becomes more than just a behavior-neutral > implementation refactoring, and would need to be looked at as an > API change, with all that entails. > > It will be a couple days before I can look at the rest. > > -- Kevin > > > > Nir Lisker wrote: > > Hi, > > Please review preliminary fix for: > > https://bugs.openjdk.java.net/browse/JDK-8199514 > > http://cr.openjdk.java.net/~nlisker/8199514/webrev.00/ > > > Thanks, > Nir > > > From mp at jugs.org Tue Mar 13 21:05:20 2018 From: mp at jugs.org (Michael Paus) Date: Tue, 13 Mar 2018 22:05:20 +0100 Subject: Removal of apps/scenebuilder from OpenJFX repo In-Reply-To: <5AA6FE44.5000609@oracle.com> References: <5A9985EF.5000701@oracle.com> <4846435.J8drcGo0IV@andor> <5AA6FE44.5000609@oracle.com> Message-ID: How will these changes then be synchronized with the work Gluon is doing for the version distributed by them? Do they work on the same repo? Am 12.03.18 um 23:25 schrieb Kevin Rushforth: > Hi Florian, > > By way of update, after thinking about this for a week (and getting > some offline feedback), I no longer propose doing this -- at least not > for the short-mid term. I've retargeted this RFE to tbd_major and > lowered the priority to P4. > > Having said that, we don't have any plans to modify SceneBuilder, but > will happily accept contributions. > > -- Kevin > > > Florian Brunner wrote: >> OK, this still comes a bit as a surprise as the source code has been >> kept in the repo and was not just provided as a ZIP file. >> >> I'm currently working on a tool based on the SceneBuilder Kit. I >> needed to work on the code a bit and was planning to donate the code >> back to OpenJFX once released, as I was under the impression OpenJFX >> would serve as the master / upstream-repo for all SceneBuilder forks. >> I was also under the impression that OpenJFX at least would make sure >> the code works with any new JDK / JavaFX version and hoped it would >> get support for new controls, if any were added to JavaFX. >> >> -Florian >> >> Am Freitag, 2. M?rz 2018, 09:12:15 CET schrieb Kevin Rushforth: >>> I filed the following JBS isuse to remova the SceneBuilder sources >>> from the OpenJFX repo. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8198961 >>> >>> As mentioned in the Description of that issue, the OpenJFX repo >>> contains the source code for a no-longer-maintained version of the >>> SceneBuilder tool. Active development on SceneBuilder in the OpenJFX >>> repo was stopped over three years ago. Since that time, the only >>> changes have been either jigsaw-related changes to keep it buildable >>> and runnable, or global changes that happened to touch some of the >>> files in apps/scenebuilder. >>> >>> A fork of SceneBuilder is maintained by Gluon, so anyone wanting to >>> get the latest SceneBuilder should go there. >>> >>> Before I proceed, I wanted to poll the list to see whether anyone >>> has a concern with this. I don't plan to take any action for at >>> least a week. >>> >>> -- Kevin >>> >>> >> >> From kevin.rushforth at oracle.com Tue Mar 13 21:11:37 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 13 Mar 2018 14:11:37 -0700 Subject: Removal of apps/scenebuilder from OpenJFX repo In-Reply-To: References: <5A9985EF.5000701@oracle.com> <4846435.J8drcGo0IV@andor> <5AA6FE44.5000609@oracle.com> Message-ID: <5AA83E89.5060908@oracle.com> That will be a question for Gluon. -- Kevin Michael Paus wrote: > How will these changes then be synchronized with the work Gluon is > doing for the version > distributed by them? Do they work on the same repo? > > Am 12.03.18 um 23:25 schrieb Kevin Rushforth: >> Hi Florian, >> >> By way of update, after thinking about this for a week (and getting >> some offline feedback), I no longer propose doing this -- at least >> not for the short-mid term. I've retargeted this RFE to tbd_major and >> lowered the priority to P4. >> >> Having said that, we don't have any plans to modify SceneBuilder, but >> will happily accept contributions. >> >> -- Kevin >> >> >> Florian Brunner wrote: >>> OK, this still comes a bit as a surprise as the source code has been >>> kept in the repo and was not just provided as a ZIP file. >>> >>> I'm currently working on a tool based on the SceneBuilder Kit. I >>> needed to work on the code a bit and was planning to donate the code >>> back to OpenJFX once released, as I was under the impression OpenJFX >>> would serve as the master / upstream-repo for all SceneBuilder >>> forks. I was also under the impression that OpenJFX at least would >>> make sure the code works with any new JDK / JavaFX version and hoped >>> it would get support for new controls, if any were added to JavaFX. >>> >>> -Florian >>> >>> Am Freitag, 2. M?rz 2018, 09:12:15 CET schrieb Kevin Rushforth: >>>> I filed the following JBS isuse to remova the SceneBuilder sources >>>> from the OpenJFX repo. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8198961 >>>> >>>> As mentioned in the Description of that issue, the OpenJFX repo >>>> contains the source code for a no-longer-maintained version of the >>>> SceneBuilder tool. Active development on SceneBuilder in the >>>> OpenJFX repo was stopped over three years ago. Since that time, the >>>> only changes have been either jigsaw-related changes to keep it >>>> buildable and runnable, or global changes that happened to touch >>>> some of the files in apps/scenebuilder. >>>> >>>> A fork of SceneBuilder is maintained by Gluon, so anyone wanting to >>>> get the latest SceneBuilder should go there. >>>> >>>> Before I proceed, I wanted to poll the list to see whether anyone >>>> has a concern with this. I don't plan to take any action for at >>>> least a week. >>>> >>>> -- Kevin >>>> >>>> >>> >>> > From nlisker at gmail.com Tue Mar 13 21:42:49 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 13 Mar 2018 23:42:49 +0200 Subject: JDK-8199560: Dynamic evaluation for binding.When Message-ID: 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 sven.reimers at gmail.com Wed Mar 14 20:52:12 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Wed, 14 Mar 2018 21:52:12 +0100 Subject: Test failures running on OS X In-Reply-To: <5AA6A2F7.1030707@oracle.com> References: <5AA69828.1030508@oracle.com> <5AA6A2F7.1030707@oracle.com> Message-ID: No further test failures due to locale, but I get this... > Task :web:test FAILED # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000107dddeaa, pid=73787, tid=38147 # # JRE version: Java(TM) SE Runtime Environment (9.0+11) (build 9.0.4+11) # Java VM: Java HotSpot(TM) 64-Bit Server VM (9.0.4+11, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64) # Problematic frame: # V [libjvm.dylib+0x3ddeaa] # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/sven/oss/openjfx/jfx-dev-rt/modules/javafx.web/hs_err_pid73787.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # ;-) Sven On Mon, Mar 12, 2018 at 4:55 PM, Kevin Rushforth wrote: > > > Laurent Bourg?s wrote: > > Kevin, > > It is possible to define the Locale (set user.language=...) in the gradle > build file, that would avoid touching the java code at all. > > > I suppose this could be done, and if there are many such failing tests, it > might be an OK short-term solution. It's probably not the best long-term > solution, since I think it is better for any test that is sensitive to the > Locale to set it in the test itself. > > Sven: if you run using the --continue option (so it won't stop after the > first batch of failing tests), are there any more tests that fail in other > modules? > > -- Kevin > > > > > > I have no opinion what is preferable to have less maintenance work or > problems in future. > > Laurent > > 2018-03-12 16:09 GMT+01:00 Kevin Rushforth : > >> I haven't run these with a Locale other than en_US, but given the nature >> of the failure, it looks like you may have discovered another >> Locale-related test bug. >> >> We had another test that was fixed by setting the default Locale to >> Locale.US in a static @BeforeClass method in the test class [1]. Perhaps a >> similar solution is needed here. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8160039 >> >> >> >> Sven Reimers wrote: >> >>> Hi, >>> >>> getting back into the OpenJFX I started with a fresh clone and ran gradle >>> test.. >>> >>> I got >>> >>> test.javafx.scene.control.SpinnerTest > >>> dblSpinner_testToString_valueInRange FAILED >>> junit.framework.ComparisonFailure: null expected:<0[.]3> but >>> was:<0[,]3> >>> at junit.framework.Assert.assertEquals(Assert.java:81) >>> at junit.framework.Assert.assertEquals(Assert.java:87) >>> at >>> test.javafx.scene.control.SpinnerTest.dblSpinner_testToStrin >>> g_valueInRange(SpinnerTest.java:607) >>> >>> test.javafx.scene.control.SpinnerTest > >>> dblSpinner_testFromString_valueInRange FAILED >>> junit.framework.AssertionFailedError: expected:<0.3> but was:<0.0> >>> at junit.framework.Assert.fail(Assert.java:47) >>> at junit.framework.Assert.failNotEquals(Assert.java:283) >>> at junit.framework.Assert.assertEquals(Assert.java:64) >>> at junit.framework.Assert.assertEquals(Assert.java:71) >>> at >>> test.javafx.scene.control.SpinnerTest.dblSpinner_testFromStr >>> ing_valueInRange(SpinnerTest.java:615) >>> >>> test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCancel >>> FAILED >>> junit.framework.ComparisonFailure: null expected:<2[.]5> but >>> was:<2[,]5> >>> at junit.framework.Assert.assertEquals(Assert.java:81) >>> at junit.framework.Assert.assertEquals(Assert.java:87) >>> at >>> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testC >>> ancel(SpinnerTest.java:1334) >>> >>> test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCommit_va >>> lid >>> FAILED >>> junit.framework.AssertionFailedError: expected:<2.5> but was:<2.0> >>> at junit.framework.Assert.fail(Assert.java:47) >>> at junit.framework.Assert.failNotEquals(Assert.java:283) >>> at junit.framework.Assert.assertEquals(Assert.java:64) >>> at junit.framework.Assert.assertEquals(Assert.java:71) >>> at >>> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testC >>> ommit_valid(SpinnerTest.java:1308) >>> >>> This is with gradle 46, 9.0.4 on a german locale OS X... >>> >>> Any ideas what to look for? >>> >>> Thanks >>> >>> Sven >>> >>> >> > > > -- > -- > Laurent Bourg?s > > -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers From kevin.rushforth at oracle.com Wed Mar 14 20:57:50 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Mar 2018 13:57:50 -0700 Subject: Test failures running on OS X In-Reply-To: References: <5AA69828.1030508@oracle.com> <5AA6A2F7.1030707@oracle.com> Message-ID: <5AA98CCE.5090403@oracle.com> This will happen if you: A) don't build WebKit; and B) are running with a libwebkit.dylib that is out of date w.r.t., the java source. In your case it looks like you are using the native webkit library from JDK 9.0.4 and the sources from jfx-dev (11-ea). -- Kevin Sven Reimers wrote: > No further test failures due to locale, but I get this... > > > Task :web:test FAILED > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000107dddeaa, pid=73787, tid=38147 > # > # JRE version: Java(TM) SE Runtime Environment (9.0+11) (build 9.0.4+11) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (9.0.4+11, mixed mode, > tiered, compressed oops, g1 gc, bsd-amd64) > # Problematic frame: > # V [libjvm.dylib+0x3ddeaa] > # > # No core dump will be written. Core dumps have been disabled. To > enable core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # > /Users/sven/oss/openjfx/jfx-dev-rt/modules/javafx.web/hs_err_pid73787.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > > ;-) > > Sven > > On Mon, Mar 12, 2018 at 4:55 PM, Kevin Rushforth > > wrote: > > > > Laurent Bourg?s wrote: >> Kevin, >> >> It is possible to define the Locale (set user.language=...) in >> the gradle build file, that would avoid touching the java code at >> all. > > I suppose this could be done, and if there are many such failing > tests, it might be an OK short-term solution. It's probably not > the best long-term solution, since I think it is better for any > test that is sensitive to the Locale to set it in the test itself. > > Sven: if you run using the --continue option (so it won't stop > after the first batch of failing tests), are there any more tests > that fail in other modules? > > -- Kevin > > > > >> >> I have no opinion what is preferable to have less maintenance >> work or problems in future. >> >> Laurent >> >> 2018-03-12 16:09 GMT+01:00 Kevin Rushforth >> >: >> >> I haven't run these with a Locale other than en_US, but given >> the nature of the failure, it looks like you may have >> discovered another Locale-related test bug. >> >> We had another test that was fixed by setting the default >> Locale to Locale.US in a static @BeforeClass method in the >> test class [1]. Perhaps a similar solution is needed here. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8160039 >> >> >> >> >> Sven Reimers wrote: >> >> Hi, >> >> getting back into the OpenJFX I started with a fresh >> clone and ran gradle >> test.. >> >> I got >> >> test.javafx.scene.control.SpinnerTest > >> dblSpinner_testToString_valueInRange FAILED >> junit.framework.ComparisonFailure: null >> expected:<0[.]3> but was:<0[,]3> >> at >> junit.framework.Assert.assertEquals(Assert.java:81) >> at >> junit.framework.Assert.assertEquals(Assert.java:87) >> at >> test.javafx.scene.control.SpinnerTest.dblSpinner_testToString_valueInRange(SpinnerTest.java:607) >> >> test.javafx.scene.control.SpinnerTest > >> dblSpinner_testFromString_valueInRange FAILED >> junit.framework.AssertionFailedError: expected:<0.3> >> but was:<0.0> >> at junit.framework.Assert.fail(Assert.java:47) >> at >> junit.framework.Assert.failNotEquals(Assert.java:283) >> at >> junit.framework.Assert.assertEquals(Assert.java:64) >> at >> junit.framework.Assert.assertEquals(Assert.java:71) >> at >> test.javafx.scene.control.SpinnerTest.dblSpinner_testFromString_valueInRange(SpinnerTest.java:615) >> >> test.javafx.scene.control.SpinnerTest > >> test_jdk_8150946_testCancel FAILED >> junit.framework.ComparisonFailure: null >> expected:<2[.]5> but was:<2[,]5> >> at >> junit.framework.Assert.assertEquals(Assert.java:81) >> at >> junit.framework.Assert.assertEquals(Assert.java:87) >> at >> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testCancel(SpinnerTest.java:1334) >> >> test.javafx.scene.control.SpinnerTest > >> test_jdk_8150946_testCommit_valid >> FAILED >> junit.framework.AssertionFailedError: expected:<2.5> >> but was:<2.0> >> at junit.framework.Assert.fail(Assert.java:47) >> at >> junit.framework.Assert.failNotEquals(Assert.java:283) >> at >> junit.framework.Assert.assertEquals(Assert.java:64) >> at >> junit.framework.Assert.assertEquals(Assert.java:71) >> at >> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testCommit_valid(SpinnerTest.java:1308) >> >> This is with gradle 46, 9.0.4 on a german locale OS X... >> >> Any ideas what to look for? >> >> Thanks >> >> Sven >> >> >> >> >> >> -- >> -- >> Laurent Bourg?s > > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * Java Champion > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > * Duke's Choice Award Winner 2009 > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers From sven.reimers at gmail.com Wed Mar 14 21:03:30 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Wed, 14 Mar 2018 22:03:30 +0100 Subject: Test failures running on OS X In-Reply-To: <5AA98CCE.5090403@oracle.com> References: <5AA69828.1030508@oracle.com> <5AA6A2F7.1030707@oracle.com> <5AA98CCE.5090403@oracle.com> Message-ID: Sure.. always building latest.. Will try to get a clean build done.. Sven On Wed, Mar 14, 2018 at 9:57 PM, Kevin Rushforth wrote: > This will happen if you: A) don't build WebKit; and B) are running with a > libwebkit.dylib that is out of date w.r.t., the java source. > > In your case it looks like you are using the native webkit library from > JDK 9.0.4 and the sources from jfx-dev (11-ea). > > -- Kevin > > > > Sven Reimers wrote: > > No further test failures due to locale, but I get this... > > > Task :web:test FAILED > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000107dddeaa, pid=73787, tid=38147 > # > # JRE version: Java(TM) SE Runtime Environment (9.0+11) (build 9.0.4+11) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (9.0.4+11, mixed mode, > tiered, compressed oops, g1 gc, bsd-amd64) > # Problematic frame: > # V [libjvm.dylib+0x3ddeaa] > # > # No core dump will be written. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /Users/sven/oss/openjfx/jfx-dev-rt/modules/javafx.web/hs_ > err_pid73787.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > > ;-) > > Sven > > On Mon, Mar 12, 2018 at 4:55 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> >> >> Laurent Bourg?s wrote: >> >> Kevin, >> >> It is possible to define the Locale (set user.language=...) in the gradle >> build file, that would avoid touching the java code at all. >> >> >> I suppose this could be done, and if there are many such failing tests, >> it might be an OK short-term solution. It's probably not the best long-term >> solution, since I think it is better for any test that is sensitive to the >> Locale to set it in the test itself. >> >> Sven: if you run using the --continue option (so it won't stop after the >> first batch of failing tests), are there any more tests that fail in other >> modules? >> >> -- Kevin >> >> >> >> >> >> I have no opinion what is preferable to have less maintenance work or >> problems in future. >> >> Laurent >> >> 2018-03-12 16:09 GMT+01:00 Kevin Rushforth : >> >>> I haven't run these with a Locale other than en_US, but given the nature >>> of the failure, it looks like you may have discovered another >>> Locale-related test bug. >>> >>> We had another test that was fixed by setting the default Locale to >>> Locale.US in a static @BeforeClass method in the test class [1]. Perhaps a >>> similar solution is needed here. >>> >>> -- Kevin >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8160039 >>> >>> >>> >>> Sven Reimers wrote: >>> >>>> Hi, >>>> >>>> getting back into the OpenJFX I started with a fresh clone and ran >>>> gradle >>>> test.. >>>> >>>> I got >>>> >>>> test.javafx.scene.control.SpinnerTest > >>>> dblSpinner_testToString_valueInRange FAILED >>>> junit.framework.ComparisonFailure: null expected:<0[.]3> but >>>> was:<0[,]3> >>>> at junit.framework.Assert.assertEquals(Assert.java:81) >>>> at junit.framework.Assert.assertEquals(Assert.java:87) >>>> at >>>> test.javafx.scene.control.SpinnerTest.dblSpinner_testToStrin >>>> g_valueInRange(SpinnerTest.java:607) >>>> >>>> test.javafx.scene.control.SpinnerTest > >>>> dblSpinner_testFromString_valueInRange FAILED >>>> junit.framework.AssertionFailedError: expected:<0.3> but was:<0.0> >>>> at junit.framework.Assert.fail(Assert.java:47) >>>> at junit.framework.Assert.failNotEquals(Assert.java:283) >>>> at junit.framework.Assert.assertEquals(Assert.java:64) >>>> at junit.framework.Assert.assertEquals(Assert.java:71) >>>> at >>>> test.javafx.scene.control.SpinnerTest.dblSpinner_testFromStr >>>> ing_valueInRange(SpinnerTest.java:615) >>>> >>>> test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCancel >>>> FAILED >>>> junit.framework.ComparisonFailure: null expected:<2[.]5> but >>>> was:<2[,]5> >>>> at junit.framework.Assert.assertEquals(Assert.java:81) >>>> at junit.framework.Assert.assertEquals(Assert.java:87) >>>> at >>>> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testC >>>> ancel(SpinnerTest.java:1334) >>>> >>>> test.javafx.scene.control.SpinnerTest > test_jdk_8150946_testCommit_va >>>> lid >>>> FAILED >>>> junit.framework.AssertionFailedError: expected:<2.5> but was:<2.0> >>>> at junit.framework.Assert.fail(Assert.java:47) >>>> at junit.framework.Assert.failNotEquals(Assert.java:283) >>>> at junit.framework.Assert.assertEquals(Assert.java:64) >>>> at junit.framework.Assert.assertEquals(Assert.java:71) >>>> at >>>> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testC >>>> ommit_valid(SpinnerTest.java:1308) >>>> >>>> This is with gradle 46, 9.0.4 on a german locale OS X... >>>> >>>> Any ideas what to look for? >>>> >>>> Thanks >>>> >>>> Sven >>>> >>>> >>> >> >> >> -- >> -- >> Laurent Bourg?s >> >> > > > -- > Sven Reimers > > * Senior Expert Software Architect > * Java Champion > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: http://community.java.net/ > javadesktop > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > * Duke's Choice Award Winner 2009 > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers From kevin.rushforth at oracle.com Wed Mar 14 21:08:25 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Mar 2018 14:08:25 -0700 Subject: Test failures running on OS X In-Reply-To: <5AA98CCE.5090403@oracle.com> References: <5AA69828.1030508@oracle.com> <5AA6A2F7.1030707@oracle.com> <5AA98CCE.5090403@oracle.com> Message-ID: <5AA98F49.9090603@oracle.com> As a solution, you can download the latest EA build of Oracle JDK 11 here: http://jdk.java.net/11/ and copy the libjfxwebkit.dylib from there into your FX build. You could also build webkit yourself, but that increases the build time significantly (although it pretty easy to set up on Mac...not so much on Windows). -- Kevin Kevin Rushforth wrote: > This will happen if you: A) don't build WebKit; and B) are running > with a libwebkit.dylib that is out of date w.r.t., the java source. > > In your case it looks like you are using the native webkit library > from JDK 9.0.4 and the sources from jfx-dev (11-ea). > > -- Kevin > > > Sven Reimers wrote: >> No further test failures due to locale, but I get this... >> >> > Task :web:test FAILED >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x0000000107dddeaa, pid=73787, tid=38147 >> # >> # JRE version: Java(TM) SE Runtime Environment (9.0+11) (build 9.0.4+11) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (9.0.4+11, mixed mode, >> tiered, compressed oops, g1 gc, bsd-amd64) >> # Problematic frame: >> # V [libjvm.dylib+0x3ddeaa] >> # >> # No core dump will be written. Core dumps have been disabled. To >> enable core dumping, try "ulimit -c unlimited" before starting Java >> again >> # >> # An error report file with more information is saved as: >> # >> /Users/sven/oss/openjfx/jfx-dev-rt/modules/javafx.web/hs_err_pid73787.log >> >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.java.com/bugreport/crash.jsp >> # >> >> ;-) >> >> Sven >> >> On Mon, Mar 12, 2018 at 4:55 PM, Kevin Rushforth >> > wrote: >> >> >> >> Laurent Bourg?s wrote: >>> Kevin, >>> >>> It is possible to define the Locale (set user.language=...) in >>> the gradle build file, that would avoid touching the java code at >>> all. >> >> I suppose this could be done, and if there are many such failing >> tests, it might be an OK short-term solution. It's probably not >> the best long-term solution, since I think it is better for any >> test that is sensitive to the Locale to set it in the test itself. >> >> Sven: if you run using the --continue option (so it won't stop >> after the first batch of failing tests), are there any more tests >> that fail in other modules? >> >> -- Kevin >> >> >> >> >>> >>> I have no opinion what is preferable to have less maintenance >>> work or problems in future. >>> >>> Laurent >>> >>> 2018-03-12 16:09 GMT+01:00 Kevin Rushforth >>> >: >>> >>> I haven't run these with a Locale other than en_US, but given >>> the nature of the failure, it looks like you may have >>> discovered another Locale-related test bug. >>> >>> We had another test that was fixed by setting the default >>> Locale to Locale.US in a static @BeforeClass method in the >>> test class [1]. Perhaps a similar solution is needed here. >>> >>> -- Kevin >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8160039 >>> >>> >>> >>> >>> Sven Reimers wrote: >>> >>> Hi, >>> >>> getting back into the OpenJFX I started with a fresh >>> clone and ran gradle >>> test.. >>> >>> I got >>> >>> test.javafx.scene.control.SpinnerTest > >>> dblSpinner_testToString_valueInRange FAILED >>> junit.framework.ComparisonFailure: null >>> expected:<0[.]3> but was:<0[,]3> >>> at >>> junit.framework.Assert.assertEquals(Assert.java:81) >>> at >>> junit.framework.Assert.assertEquals(Assert.java:87) >>> at >>> >>> test.javafx.scene.control.SpinnerTest.dblSpinner_testToString_valueInRange(SpinnerTest.java:607) >>> >>> >>> test.javafx.scene.control.SpinnerTest > >>> dblSpinner_testFromString_valueInRange FAILED >>> junit.framework.AssertionFailedError: expected:<0.3> >>> but was:<0.0> >>> at junit.framework.Assert.fail(Assert.java:47) >>> at >>> junit.framework.Assert.failNotEquals(Assert.java:283) >>> at >>> junit.framework.Assert.assertEquals(Assert.java:64) >>> at >>> junit.framework.Assert.assertEquals(Assert.java:71) >>> at >>> >>> test.javafx.scene.control.SpinnerTest.dblSpinner_testFromString_valueInRange(SpinnerTest.java:615) >>> >>> >>> test.javafx.scene.control.SpinnerTest > >>> test_jdk_8150946_testCancel FAILED >>> junit.framework.ComparisonFailure: null >>> expected:<2[.]5> but was:<2[,]5> >>> at >>> junit.framework.Assert.assertEquals(Assert.java:81) >>> at >>> junit.framework.Assert.assertEquals(Assert.java:87) >>> at >>> >>> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testCancel(SpinnerTest.java:1334) >>> >>> >>> test.javafx.scene.control.SpinnerTest > >>> test_jdk_8150946_testCommit_valid >>> FAILED >>> junit.framework.AssertionFailedError: expected:<2.5> >>> but was:<2.0> >>> at junit.framework.Assert.fail(Assert.java:47) >>> at >>> junit.framework.Assert.failNotEquals(Assert.java:283) >>> at >>> junit.framework.Assert.assertEquals(Assert.java:64) >>> at >>> junit.framework.Assert.assertEquals(Assert.java:71) >>> at >>> >>> test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testCommit_valid(SpinnerTest.java:1308) >>> >>> >>> This is with gradle 46, 9.0.4 on a german locale OS X... >>> >>> Any ideas what to look for? >>> >>> Thanks >>> >>> Sven >>> >>> >>> >>> >>> -- -- Laurent Bourg?s >> >> >> >> >> -- >> Sven Reimers >> >> * Senior Expert Software Architect >> * Java Champion >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> * Community Leader NetBeans: http://community.java.net/netbeans >> Desktop Java: >> http://community.java.net/javadesktop >> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >> * Duke's Choice Award Winner 2009 >> >> * XING: https://www.xing.com/profile/Sven_Reimers8 >> * LinkedIn: http://www.linkedin.com/in/svenreimers From sven.reimers at gmail.com Wed Mar 14 21:10:28 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Wed, 14 Mar 2018 22:10:28 +0100 Subject: Test failures running on OS X In-Reply-To: <5AA98F49.9090603@oracle.com> References: <5AA69828.1030508@oracle.com> <5AA6A2F7.1030707@oracle.com> <5AA98CCE.5090403@oracle.com> <5AA98F49.9090603@oracle.com> Message-ID: Already downloading.. Thanks Sven Am 14.03.2018 22:08 schrieb "Kevin Rushforth" : > As a solution, you can download the latest EA build of Oracle JDK 11 here: > > http://jdk.java.net/11/ > > and copy the libjfxwebkit.dylib from there into your FX build. > > You could also build webkit yourself, but that increases the build time > significantly (although it pretty easy to set up on Mac...not so much on > Windows). > > -- Kevin > > > Kevin Rushforth wrote: > >> This will happen if you: A) don't build WebKit; and B) are running with a >> libwebkit.dylib that is out of date w.r.t., the java source. >> >> In your case it looks like you are using the native webkit library from >> JDK 9.0.4 and the sources from jfx-dev (11-ea). >> >> -- Kevin >> >> >> Sven Reimers wrote: >> >>> No further test failures due to locale, but I get this... >>> >>> > Task :web:test FAILED >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # SIGSEGV (0xb) at pc=0x0000000107dddeaa, pid=73787, tid=38147 >>> # >>> # JRE version: Java(TM) SE Runtime Environment (9.0+11) (build 9.0.4+11) >>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (9.0.4+11, mixed mode, >>> tiered, compressed oops, g1 gc, bsd-amd64) >>> # Problematic frame: >>> # V [libjvm.dylib+0x3ddeaa] >>> # >>> # No core dump will be written. Core dumps have been disabled. To enable >>> core dumping, try "ulimit -c unlimited" before starting Java again >>> # >>> # An error report file with more information is saved as: >>> # /Users/sven/oss/openjfx/jfx-dev-rt/modules/javafx.web/hs_err_pid73787.log >>> >>> # >>> # If you would like to submit a bug report, please visit: >>> # http://bugreport.java.com/bugreport/crash.jsp >>> # >>> >>> ;-) >>> >>> Sven >>> >>> On Mon, Mar 12, 2018 at 4:55 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com > wrote: >>> >>> >>> >>> Laurent Bourg?s wrote: >>> >>>> Kevin, >>>> >>>> It is possible to define the Locale (set user.language=...) in >>>> the gradle build file, that would avoid touching the java code at >>>> all. >>>> >>> >>> I suppose this could be done, and if there are many such failing >>> tests, it might be an OK short-term solution. It's probably not >>> the best long-term solution, since I think it is better for any >>> test that is sensitive to the Locale to set it in the test itself. >>> >>> Sven: if you run using the --continue option (so it won't stop >>> after the first batch of failing tests), are there any more tests >>> that fail in other modules? >>> >>> -- Kevin >>> >>> >>> >>> >>> >>>> I have no opinion what is preferable to have less maintenance >>>> work or problems in future. >>>> >>>> Laurent >>>> >>>> 2018-03-12 16:09 GMT+01:00 Kevin Rushforth >>>> >: >>>> >>>> I haven't run these with a Locale other than en_US, but given >>>> the nature of the failure, it looks like you may have >>>> discovered another Locale-related test bug. >>>> >>>> We had another test that was fixed by setting the default >>>> Locale to Locale.US in a static @BeforeClass method in the >>>> test class [1]. Perhaps a similar solution is needed here. >>>> >>>> -- Kevin >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8160039 >>>> >>>> >>>> >>>> >>>> Sven Reimers wrote: >>>> >>>> Hi, >>>> >>>> getting back into the OpenJFX I started with a fresh >>>> clone and ran gradle >>>> test.. >>>> >>>> I got >>>> >>>> test.javafx.scene.control.SpinnerTest > >>>> dblSpinner_testToString_valueInRange FAILED >>>> junit.framework.ComparisonFailure: null >>>> expected:<0[.]3> but was:<0[,]3> >>>> at >>>> junit.framework.Assert.assertEquals(Assert.java:81) >>>> at >>>> junit.framework.Assert.assertEquals(Assert.java:87) >>>> at >>>> test.javafx.scene.control.Spin >>>> nerTest.dblSpinner_testToString_valueInRange(SpinnerTest.java:607) >>>> >>>> test.javafx.scene.control.SpinnerTest > >>>> dblSpinner_testFromString_valueInRange FAILED >>>> junit.framework.AssertionFailedError: expected:<0.3> >>>> but was:<0.0> >>>> at junit.framework.Assert.fail(Assert.java:47) >>>> at >>>> junit.framework.Assert.failNotEquals(Assert.java:283) >>>> at >>>> junit.framework.Assert.assertEquals(Assert.java:64) >>>> at >>>> junit.framework.Assert.assertEquals(Assert.java:71) >>>> at >>>> test.javafx.scene.control.Spin >>>> nerTest.dblSpinner_testFromString_valueInRange(SpinnerTest.java:615) >>>> >>>> test.javafx.scene.control.SpinnerTest > >>>> test_jdk_8150946_testCancel FAILED >>>> junit.framework.ComparisonFailure: null >>>> expected:<2[.]5> but was:<2[,]5> >>>> at >>>> junit.framework.Assert.assertEquals(Assert.java:81) >>>> at >>>> junit.framework.Assert.assertEquals(Assert.java:87) >>>> at >>>> test.javafx.scene.control.Spin >>>> nerTest.test_jdk_8150946_testCancel(SpinnerTest.java:1334) >>>> >>>> test.javafx.scene.control.SpinnerTest > >>>> test_jdk_8150946_testCommit_valid >>>> FAILED >>>> junit.framework.AssertionFailedError: expected:<2.5> >>>> but was:<2.0> >>>> at junit.framework.Assert.fail(Assert.java:47) >>>> at >>>> junit.framework.Assert.failNotEquals(Assert.java:283) >>>> at >>>> junit.framework.Assert.assertEquals(Assert.java:64) >>>> at >>>> junit.framework.Assert.assertEquals(Assert.java:71) >>>> at >>>> test.javafx.scene.control.Spin >>>> nerTest.test_jdk_8150946_testCommit_valid(SpinnerTest.java:1308) >>>> >>>> This is with gradle 46, 9.0.4 on a german locale OS X... >>>> >>>> Any ideas what to look for? >>>> >>>> Thanks >>>> >>>> Sven >>>> >>>> >>>> >>>> -- -- Laurent Bourg?s >>>> >>> >>> >>> >>> >>> -- >>> Sven Reimers >>> >>> * Senior Expert Software Architect >>> * Java Champion >>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>> * Community Leader NetBeans: http://community.java.net/netbeans >>> Desktop Java: >>> http://community.java.net/javadesktop >>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >>> * Duke's Choice Award Winner 2009 >>> >>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>> >> From kevin.rushforth at oracle.com Wed Mar 14 21:16:57 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Mar 2018 14:16:57 -0700 Subject: Test failures running on OS X In-Reply-To: References: <5AA69828.1030508@oracle.com> <5AA6A2F7.1030707@oracle.com> <5AA98CCE.5090403@oracle.com> <5AA98F49.9090603@oracle.com> Message-ID: <5AA99149.1030805@oracle.com> One more thing to note. You won't actually be able to use JDK 11 as your boot JDK, since gradle 4.x does not yet run with JDK 11. See: https://github.com/gradle/gradle/issues/4515 https://bugs.openjdk.java.net/browse/JDK-8199069 -- Kevin Sven Reimers wrote: > Already downloading.. > > Thanks > > Sven > > Am 14.03.2018 22:08 schrieb "Kevin Rushforth" > >: > > As a solution, you can download the latest EA build of Oracle JDK > 11 here: > > http://jdk.java.net/11/ > > and copy the libjfxwebkit.dylib from there into your FX build. > > You could also build webkit yourself, but that increases the build > time significantly (although it pretty easy to set up on Mac...not > so much on Windows). > > -- Kevin > > > Kevin Rushforth wrote: > > This will happen if you: A) don't build WebKit; and B) are > running with a libwebkit.dylib that is out of date w.r.t., the > java source. > > In your case it looks like you are using the native webkit > library from JDK 9.0.4 and the sources from jfx-dev (11-ea). > > -- Kevin > > > Sven Reimers wrote: > > No further test failures due to locale, but I get this... > > > Task :web:test FAILED > # > # A fatal error has been detected by the Java Runtime > Environment: > # > # SIGSEGV (0xb) at pc=0x0000000107dddeaa, pid=73787, > tid=38147 > # > # JRE version: Java(TM) SE Runtime Environment (9.0+11) > (build 9.0.4+11) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (9.0.4+11, > mixed mode, tiered, compressed oops, g1 gc, bsd-amd64) > # Problematic frame: > # V [libjvm.dylib+0x3ddeaa] > # > # No core dump will be written. Core dumps have been > disabled. To enable core dumping, try "ulimit -c > unlimited" before starting Java again > # > # An error report file with more information is saved as: > # > /Users/sven/oss/openjfx/jfx-dev-rt/modules/javafx.web/hs_err_pid73787.log > > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > > # > > ;-) > > Sven > > On Mon, Mar 12, 2018 at 4:55 PM, Kevin Rushforth > > >> wrote: > > > > Laurent Bourg?s wrote: > > Kevin, > > It is possible to define the Locale (set > user.language=...) in > the gradle build file, that would avoid touching > the java code at > all. > > > I suppose this could be done, and if there are many > such failing > tests, it might be an OK short-term solution. It's > probably not > the best long-term solution, since I think it is > better for any > test that is sensitive to the Locale to set it in the > test itself. > > Sven: if you run using the --continue option (so it > won't stop > after the first batch of failing tests), are there any > more tests > that fail in other modules? > > -- Kevin > > > > > > I have no opinion what is preferable to have less > maintenance > work or problems in future. > > Laurent > > 2018-03-12 16:09 GMT+01:00 Kevin Rushforth > > >>: > > I haven't run these with a Locale other than > en_US, but given > the nature of the failure, it looks like you > may have > discovered another Locale-related test bug. > > We had another test that was fixed by setting > the default > Locale to Locale.US in a static @BeforeClass > method in the > test class [1]. Perhaps a similar solution is > needed here. > > -- Kevin > > [1] > https://bugs.openjdk.java.net/browse/JDK-8160039 > > > > > > > > Sven Reimers wrote: > > Hi, > > getting back into the OpenJFX I started > with a fresh > clone and ran gradle > test.. > > I got > > test.javafx.scene.control.SpinnerTest > > dblSpinner_testToString_valueInRange FAILED > junit.framework.ComparisonFailure: null > expected:<0[.]3> but was:<0[,]3> > at > > junit.framework.Assert.assertEquals(Assert.java:81) > at > > junit.framework.Assert.assertEquals(Assert.java:87) > at > > test.javafx.scene.control.SpinnerTest.dblSpinner_testToString_valueInRange(SpinnerTest.java:607) > > > test.javafx.scene.control.SpinnerTest > > dblSpinner_testFromString_valueInRange FAILED > junit.framework.AssertionFailedError: > expected:<0.3> > but was:<0.0> > at > junit.framework.Assert.fail(Assert.java:47) > at > > junit.framework.Assert.failNotEquals(Assert.java:283) > at > > junit.framework.Assert.assertEquals(Assert.java:64) > at > > junit.framework.Assert.assertEquals(Assert.java:71) > at > > test.javafx.scene.control.SpinnerTest.dblSpinner_testFromString_valueInRange(SpinnerTest.java:615) > > > test.javafx.scene.control.SpinnerTest > > test_jdk_8150946_testCancel FAILED > junit.framework.ComparisonFailure: null > expected:<2[.]5> but was:<2[,]5> > at > > junit.framework.Assert.assertEquals(Assert.java:81) > at > > junit.framework.Assert.assertEquals(Assert.java:87) > at > > test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testCancel(SpinnerTest.java:1334) > > > test.javafx.scene.control.SpinnerTest > > test_jdk_8150946_testCommit_valid > FAILED > junit.framework.AssertionFailedError: > expected:<2.5> > but was:<2.0> > at > junit.framework.Assert.fail(Assert.java:47) > at > > junit.framework.Assert.failNotEquals(Assert.java:283) > at > > junit.framework.Assert.assertEquals(Assert.java:64) > at > > junit.framework.Assert.assertEquals(Assert.java:71) > at > > test.javafx.scene.control.SpinnerTest.test_jdk_8150946_testCommit_valid(SpinnerTest.java:1308) > > > This is with gradle 46, 9.0.4 on a german > locale OS X... > > Any ideas what to look for? > > Thanks > > Sven > > > > -- -- Laurent Bourg?s > > > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * Java Champion > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: > http://community.java.net/netbeans > > Desktop Java: > http://community.java.net/javadesktop > > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > * Duke's Choice Award Winner 2009 > > * XING: https://www.xing.com/profile/Sven_Reimers8 > > * LinkedIn: http://www.linkedin.com/in/svenreimers > > From sven.reimers at gmail.com Wed Mar 14 21:21:28 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Wed, 14 Mar 2018 22:21:28 +0100 Subject: Test failures running on OS X In-Reply-To: <5AA99149.1030805@oracle.com> References: <5AA69828.1030508@oracle.com> <5AA6A2F7.1030707@oracle.com> <5AA98CCE.5090403@oracle.com> <5AA98F49.9090603@oracle.com> <5AA99149.1030805@oracle.com> Message-ID: Ok, so back to building everything on my own - fine for me... Sven On Wed, Mar 14, 2018 at 10:16 PM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > One more thing to note. You won't actually be able to use JDK 11 as your > boot JDK, since gradle 4.x does not yet run with JDK 11. See: > > https://github.com/gradle/gradle/issues/4515 > https://bugs.openjdk.java.net/browse/JDK-8199069 > > > -- Kevin > > > Sven Reimers wrote: > > Already downloading.. > > Thanks > > Sven > > Am 14.03.2018 22:08 schrieb "Kevin Rushforth" >: > >> As a solution, you can download the latest EA build of Oracle JDK 11 here: >> >> http://jdk.java.net/11/ >> >> and copy the libjfxwebkit.dylib from there into your FX build. >> >> You could also build webkit yourself, but that increases the build time >> significantly (although it pretty easy to set up on Mac...not so much on >> Windows). >> >> -- Kevin >> >> >> Kevin Rushforth wrote: >> >>> This will happen if you: A) don't build WebKit; and B) are running with >>> a libwebkit.dylib that is out of date w.r.t., the java source. >>> >>> In your case it looks like you are using the native webkit library from >>> JDK 9.0.4 and the sources from jfx-dev (11-ea). >>> >>> -- Kevin >>> >>> >>> Sven Reimers wrote: >>> >>>> No further test failures due to locale, but I get this... >>>> >>>> > Task :web:test FAILED >>>> # >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # SIGSEGV (0xb) at pc=0x0000000107dddeaa, pid=73787, tid=38147 >>>> # >>>> # JRE version: Java(TM) SE Runtime Environment (9.0+11) (build 9.0.4+11) >>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (9.0.4+11, mixed mode, >>>> tiered, compressed oops, g1 gc, bsd-amd64) >>>> # Problematic frame: >>>> # V [libjvm.dylib+0x3ddeaa] >>>> # >>>> # No core dump will be written. Core dumps have been disabled. To >>>> enable core dumping, try "ulimit -c unlimited" before starting Java again >>>> # >>>> # An error report file with more information is saved as: >>>> # /Users/sven/oss/openjfx/jfx-dev-rt/modules/javafx.web/hs_err_pid73787.log >>>> >>>> # >>>> # If you would like to submit a bug report, please visit: >>>> # http://bugreport.java.com/bugreport/crash.jsp >>>> # >>>> >>>> ;-) >>>> >>>> Sven >>>> >>>> On Mon, Mar 12, 2018 at 4:55 PM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com > wrote: >>>> >>>> >>>> >>>> Laurent Bourg?s wrote: >>>> >>>>> Kevin, >>>>> >>>>> It is possible to define the Locale (set user.language=...) in >>>>> the gradle build file, that would avoid touching the java code at >>>>> all. >>>>> >>>> >>>> I suppose this could be done, and if there are many such failing >>>> tests, it might be an OK short-term solution. It's probably not >>>> the best long-term solution, since I think it is better for any >>>> test that is sensitive to the Locale to set it in the test itself. >>>> >>>> Sven: if you run using the --continue option (so it won't stop >>>> after the first batch of failing tests), are there any more tests >>>> that fail in other modules? >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> >>>> >>>>> I have no opinion what is preferable to have less maintenance >>>>> work or problems in future. >>>>> >>>>> Laurent >>>>> >>>>> 2018-03-12 16:09 GMT+01:00 Kevin Rushforth >>>>> >: >>>>> >>>>> I haven't run these with a Locale other than en_US, but given >>>>> the nature of the failure, it looks like you may have >>>>> discovered another Locale-related test bug. >>>>> >>>>> We had another test that was fixed by setting the default >>>>> Locale to Locale.US in a static @BeforeClass method in the >>>>> test class [1]. Perhaps a similar solution is needed here. >>>>> >>>>> -- Kevin >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8160039 >>>>> >>>>> >>>>> >>>>> >>>>> Sven Reimers wrote: >>>>> >>>>> Hi, >>>>> >>>>> getting back into the OpenJFX I started with a fresh >>>>> clone and ran gradle >>>>> test.. >>>>> >>>>> I got >>>>> >>>>> test.javafx.scene.control.SpinnerTest > >>>>> dblSpinner_testToString_valueInRange FAILED >>>>> junit.framework.ComparisonFailure: null >>>>> expected:<0[.]3> but was:<0[,]3> >>>>> at >>>>> junit.framework.Assert.assertEquals(Assert.java:81) >>>>> at >>>>> junit.framework.Assert.assertEquals(Assert.java:87) >>>>> at >>>>> test.javafx.scene.control.Spin >>>>> nerTest.dblSpinner_testToString_valueInRange(SpinnerTest.java:607) >>>>> >>>>> test.javafx.scene.control.SpinnerTest > >>>>> dblSpinner_testFromString_valueInRange FAILED >>>>> junit.framework.AssertionFailedError: expected:<0.3> >>>>> but was:<0.0> >>>>> at junit.framework.Assert.fail(Assert.java:47) >>>>> at >>>>> junit.framework.Assert.failNotEquals(Assert.java:283) >>>>> at >>>>> junit.framework.Assert.assertEquals(Assert.java:64) >>>>> at >>>>> junit.framework.Assert.assertEquals(Assert.java:71) >>>>> at >>>>> test.javafx.scene.control.Spin >>>>> nerTest.dblSpinner_testFromString_valueInRange(SpinnerTest.java:615) >>>>> >>>>> test.javafx.scene.control.SpinnerTest > >>>>> test_jdk_8150946_testCancel FAILED >>>>> junit.framework.ComparisonFailure: null >>>>> expected:<2[.]5> but was:<2[,]5> >>>>> at >>>>> junit.framework.Assert.assertEquals(Assert.java:81) >>>>> at >>>>> junit.framework.Assert.assertEquals(Assert.java:87) >>>>> at >>>>> test.javafx.scene.control.Spin >>>>> nerTest.test_jdk_8150946_testCancel(SpinnerTest.java:1334) >>>>> >>>>> test.javafx.scene.control.SpinnerTest > >>>>> test_jdk_8150946_testCommit_valid >>>>> FAILED >>>>> junit.framework.AssertionFailedError: expected:<2.5> >>>>> but was:<2.0> >>>>> at junit.framework.Assert.fail(Assert.java:47) >>>>> at >>>>> junit.framework.Assert.failNotEquals(Assert.java:283) >>>>> at >>>>> junit.framework.Assert.assertEquals(Assert.java:64) >>>>> at >>>>> junit.framework.Assert.assertEquals(Assert.java:71) >>>>> at >>>>> test.javafx.scene.control.Spin >>>>> nerTest.test_jdk_8150946_testCommit_valid(SpinnerTest.java:1308) >>>>> >>>>> This is with gradle 46, 9.0.4 on a german locale OS X... >>>>> >>>>> Any ideas what to look for? >>>>> >>>>> Thanks >>>>> >>>>> Sven >>>>> >>>>> >>>>> >>>>> -- -- Laurent Bourg?s >>>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Sven Reimers >>>> >>>> * Senior Expert Software Architect >>>> * Java Champion >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>>> * Community Leader NetBeans: http://community.java.net/netbeans >>>> Desktop Java: >>>> http://community.java.net/javadesktop >>>> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >>>> * Duke's Choice Award Winner 2009 >>>> >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>>> >>> -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers From kevin.rushforth at oracle.com Thu Mar 15 21:19:05 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 15 Mar 2018 14:19:05 -0700 Subject: [11] Review request: 8199684: Update minumum boot JDK to jdk-9+181 Message-ID: <5AAAE349.8090205@oracle.com> Phil, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8199684 http://cr.openjdk.java.net/~kcr/8199684/webrev.00/ This is long-overdue cleanup to bump the minimum boot JDK to JDK 9 GA, which I discovered while working on the gradle changes for separating FX bits (and which you recently reminded me of). Note that we could consider bumping the minimum to JDK 10 GA some time after it ships next week, but that would require more discussion and a heads-up that it was coming, whereas this just corrects an oversight and won't affect any developers at all. -- Kevin From johan.vos at gluonhq.com Fri Mar 16 08:32:56 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 16 Mar 2018 08:32:56 +0000 Subject: webrev for locale javadoc Message-ID: The very simple webrev for https://bugs.openjdk.java.net/browse/JDK-8199675 is here: http://cr.openjdk.java.net/~jvos/8199675/webrev.00/ I'll commit once approved (adding the contributed-by smanux (Emmanuel Bourg) ) From kevin.rushforth at oracle.com Fri Mar 16 11:33:41 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 16 Mar 2018 04:33:41 -0700 Subject: webrev for locale javadoc In-Reply-To: References: Message-ID: <5AABAB95.4030203@oracle.com> Approved. -- Kevin Johan Vos wrote: > The very simple webrev for https://bugs.openjdk.java.net/browse/JDK-8199675 is > here: > http://cr.openjdk.java.net/~jvos/8199675/webrev.00/ > > I'll commit once approved (adding the contributed-by smanux (Emmanuel > Bourg) ) > From kevin.rushforth at oracle.com Fri Mar 16 22:39:37 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 16 Mar 2018 15:39:37 -0700 Subject: JDK-8199560: Dynamic evaluation for binding.When In-Reply-To: References: Message-ID: <5AAC47A9.20004@oracle.com> 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 openjfx at arne-augenstein.de Sat Mar 17 12:27:46 2018 From: openjfx at arne-augenstein.de (Arne Augenstein) Date: Sat, 17 Mar 2018 13:27:46 +0100 Subject: HostServices.showDocument in Linux: Default browser Message-ID: <1521289666.708.0@sslout.df.eu> Hello all, I've been trying to figure out which mechanism JavaFX uses in Linux to determine the default browser with which to open the passed URI. I'm using Manjaro Linux and this method always opens links in Firefox. My default browser is Chrome, though. In all the applications I've tested it (which honestly aren't that many) this setting gets respected and links are opened in Chrome. The "default application"-situation in Linux is a bit complicated, see for example https://wiki.archlinux.org/index.php/default_applications. There many different places default applications can be set and obviously I haven't found the one which JavaFX uses, yet. Can you give me a hint where to look? Regards Arne Augenstein From tom.schindl at bestsolution.at Sat Mar 17 12:55:18 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 17 Mar 2018 13:55:18 +0100 Subject: HostServices.showDocument in Linux: Default browser In-Reply-To: <1521289666.708.0@sslout.df.eu> References: <1521289666.708.0@sslout.df.eu> Message-ID: <758054ae-b4d8-ea90-d6dd-06ad8ab7e0b6@bestsolution.at> Hi, See http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/dfe920ff7163/modules/javafx.graphics/src/main/java/com/sun/javafx/application/HostServicesDelegate.java Tom On 17.03.18 13:27, Arne Augenstein wrote: > Hello all, > > I've been trying to figure out which mechanism JavaFX uses in Linux to > determine the default browser with which to open the passed URI. > > I'm using Manjaro Linux and this method always opens links in Firefox. > My default browser is Chrome, though. In all the applications I've > tested it (which honestly aren't that many) this setting gets respected > and links are opened in Chrome. > > The "default application"-situation in Linux is a bit complicated, see > for example https://wiki.archlinux.org/index.php/default_applications. > There many different places default applications can be set and > obviously I haven't found the one which JavaFX uses, yet. Can you give > me a hint where to look? > > > Regards > Arne Augenstein From openjfx at arne-augenstein.de Sat Mar 17 15:16:56 2018 From: openjfx at arne-augenstein.de (Arne Augenstein) Date: Sat, 17 Mar 2018 16:16:56 +0100 Subject: HostServices.showDocument in Linux: Default browser In-Reply-To: <758054ae-b4d8-ea90-d6dd-06ad8ab7e0b6@bestsolution.at> References: <1521289666.708.0@sslout.df.eu> <758054ae-b4d8-ea90-d6dd-06ad8ab7e0b6@bestsolution.at> Message-ID: <1521299816.708.1@sslout.df.eu> Hi, thanks. That is the explanation. I have Firefox an Chromium installed and Chromium is missing in the browsers list in line 162. My immediate problem could be solved by adding "chromium" to this list. But it still wouldn't be a good solution as it doesn't take into account any kind of priority users with different browsers might have as it doesn't use any of Linux' ways to define default applications. It also doesn't work with less popular browsers. I will keep using Desktop.getDesktop().browse(Uri uri) for the time being as this seems to be working better at the moment. Regards Arne Augenstein On Sa, M?r 17, 2018 at 1:55 PM, Tom Schindl wrote: > Hi, > > See > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/dfe920ff7163/modules/javafx.graphics/src/main/java/com/sun/javafx/application/HostServicesDelegate.java > > Tom > > On 17.03.18 13:27, Arne Augenstein wrote: >> Hello all, >> >> I've been trying to figure out which mechanism JavaFX uses in Linux >> to >> determine the default browser with which to open the passed URI. >> >> I'm using Manjaro Linux and this method always opens links in >> Firefox. >> My default browser is Chrome, though. In all the applications I've >> tested it (which honestly aren't that many) this setting gets >> respected >> and links are opened in Chrome. >> >> The "default application"-situation in Linux is a bit complicated, >> see >> for example >> https://wiki.archlinux.org/index.php/default_applications. >> There many different places default applications can be set and >> obviously I haven't found the one which JavaFX uses, yet. Can you >> give >> me a hint where to look? >> >> >> Regards >> Arne Augenstein From nlisker at gmail.com Sat Mar 17 21:40:51 2018 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 17 Mar 2018 23:40:51 +0200 Subject: Review Request: JDK-8180151: JavaFX incorrectly renders scenegraph with two 3D boxes with certain dimensions Message-ID: Hi Kevin, Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8180151 http://cr.openjdk.java.net/~nlisker/8180151/webrev.00/ Thanks, Nir From itaisha at gmail.com Sun Mar 18 11:19:59 2018 From: itaisha at gmail.com (Itai) Date: Sun, 18 Mar 2018 13:19:59 +0200 Subject: Question/discussion about JDK-8129582 In-Reply-To: References: <586D3053.3020308@oracle.com> <827bf5c3-1e12-c4b4-5bad-aeb5c28e6864@oracle.com> Message-ID: Hello, In hopes of getting this bug fixed, I have made changes to `PangoGlyphLayout` so that is only allocates the FT2 FontMap once, and uses a `PlatformImpl.FinishListener` to unref it when the JavaFX platform exits. Attached is the modified version of the file. In my personal tests, depending on hardware used, there is a speedup of between x2 and x10 in layout times, and scrolling large Lists/Tables feels as snappy with CTL languages as with any other language. For anyone wanting to test it, remember this bug only affects Linux, and only CTL languages (such as Arabic, Farsi, Hebrew and Hindi). Regards, Itai. On Sun, Jan 8, 2017 at 11:39 PM, Itai wrote: > I think I have found two problems. The first, and probably most critical > one, is that a new PangoFontMap is created for every call of > PangoGlyphLayout#layout. It is not entirely clear from the Pango > documentation what the lifetime or intended usage of a PangoFontMap is, but > I have found this comment in [1]: > > "But note that a PangoFontMap is a big expensive object. So, you > *really* want to be using only one for your entire program. > Frequently calling pango_ft2_font_map_new() is going kill > the performance of your application." > > This seems to imply PangoFontMap is intended as a global (per display?) > font cache. Indeed, creating only one PangoFontMap seems to improve > performance drastically, although I'm not sure what is the best way to > handle this object (i.e. when and how it should be re-used and freed), as > it should probably (?) be held for the entire lifetime of the JavaFX > application. > > The second problem is probably less significant, but could still > theoretically hurt performance - it has to do with the usage of > g_list_nth_data, which as per [2] has O(N) complexity, and is called once > per item in the list, which yields O(N^2) complexity. Replacing it with > linked-list traversal with g_list_next should reduce this back to O(N). > > I hope this information is clear enough. As I said I lack the overall > understanding of the JavaFX platform to know where and how to manage a > global object, such as PangoFontMap should apparently be, so I refrain from > posting any patch that I know would be wrong. > > Regards, > Itai. > > [1]: https://mail.gnome.org/archives/gtk-list/2005-April/msg00105.html > [2]: https://developer.gnome.org/programming-guidelines/ > stable/glist.html.en > > On Sun, Jan 8, 2017 at 8:08 PM, Itai wrote: > >> Thank you for the link, it's an interesting read indeed! >> >> I wasn't really skipping layout, just using the much simpler layout used >> by Latin scripts, but you are correct that this will break for anything >> more complex - this has nothing to do with BiDi though, more to do with >> complex layout elements (like diacritic or cantillation marks for Hebrew, >> or general Arabic/Farsi text). >> Indeed, this can't be a general solution, but I guess I was driven by >> frustration. >> >> I have tried some more configurations though, and found that on Windows >> the loss of performance is much less noticeable, which seems to mean that >> the problem is either: >> 1. Pango is inherently slow / inherently slow when laying out BiDi text. >> 2. JavaFX uses Pango in a sub-optimal / redundant way. >> 3. The JNI / native calls to Pango are done in a sub-optimal way. >> >> Option 1 can be easily debunked, as general Gnome/GTK applications run as >> smoothly with BiDi text as with Latin / LTR text. >> For options 2 and 3 I guess some more digging into the code must be done. >> My understanding is that JNI calls are not likely to incur performance loss >> to such a degree, unless very large amounts of memory are copied back and >> forth between Java and native code, so I'll start by reading into the Pango >> documentation and understanding the logic of PangoGlyphLayout. >> >> If you have any input on this or believe my assumptions or conclusions >> are wrong I'd be glad to hear. I realize you are all busy with the upcoming >> 9 release, so I'll try to get as detailed a result as I can. >> >> Regards, >> Itai. >> >> On Wed, Jan 4, 2017 at 8:44 PM, Phil Race wrote: >> >>> You can't skip layout just because it is bidi .. >>> where here you are apparently implicitly meaning Hebrew. >>> This might be apparently working but may not always work even >>> for Hebrew and will be a disaster for Arabic. >>> >>> Here is a web page which talks about OTL (OpenType Layout) for Hebrew : >>> https://www.microsoft.com/typography/OpenTypeDev/hebrew/intro.htm >>> I can't say offhand why this might be exclusive to FX. >>> That test case would be handy. >>> So this needs more analysis even if you found a way to limit this to >>> specifically Latin+Hebrew. >>> >>> -phil. >>> >>> >>> On 01/04/2017 10:32 AM, Itai wrote: >>> >>> Some quick-and-dirty thing I hacked now and seems to improve the >>> performance drastically is something like: >>> >>> if (complex but not bidi) { >>> use GlyphLayout. >>> } else if (bidi) { >>> use java.text.Bidi.reorderVisually to get visual glyph order, then >>> use same implementation as non-bidi non-complex layout >>> } else { >>> ... >>> } >>> >>> Very minimal tests show it working correctly, and performance is 8-10 >>> times faster (on par with non-bidi text). >>> Do you think this solution makes sense? Can you see any obvious >>> pitfalls? >>> If it seems OK I'll try some more tests and then work it into something >>> clean enough to submit as a patch suggestion. >>> >>> >>> On Wed, Jan 4, 2017 at 7:48 PM, Itai wrote: >>> >>>> Thanks for replying. >>>> I think I understand what you're saying about the cache. As for >>>> complexity - I'm mostly working with text which is only in Hebrew, which >>>> isn't complex as far as I understand the definition (no glyph "fusing" as >>>> in Arabic or Farsi). I can work with minor performance drops, but when the >>>> same window takes more than 10 times to show if it has Hebrew labels is a >>>> lot more than minor - and this is exclusive to JavaFX, so it's not like >>>> this problem is unsolvable. >>>> >>>> Perhaps the caching is indeed not the correct solution, but maybe there >>>> can be a way to simplify the layout in non-complex BiDi cases? Or optimize >>>> PangoGlyphLayout.layout? >>>> >>>> Thank you again for replying, I really hope this issue can see some >>>> improvement. >>>> >>>> On Wed, Jan 4, 2017 at 7:26 PM, Philip Race < >>>> philip.race at oracle.com> wrote: >>>> >>>>> The cache is a heuristic optimisation and whether it helps depends on >>>>> how well that cache is used. >>>>> It is a time-space trade-off and I'd expect it to show up as helping >>>>> more in micro-benchmarks or >>>>> text-intensive benchmarks which use the same text broken in the same >>>>> way. >>>>> Complex text layout is inherently slower and if you are doing a lot of >>>>> it .. it will be slow .. and >>>>> unless it is repeated a cache won't help. >>>>> During start-up I'd *expect* that there isn't a lot of re-use going on. >>>>> >>>>> You would need to profile how often the same text (and attributes) >>>>> are passed through this code. >>>>> If you could provide us a test case we could examine it too. >>>>> >>>>> If it were a real use case, then we'd move on to examine the >>>>> feasibility of caching ... >>>>> >>>>> -phil. >>>>> >>>>> >>>>> >>>>> On 1/4/17, 9:19 AM, Itai wrote: >>>>> >>>>>> Recently JDK-8129582 [1] started really affecting me, with startup >>>>>> speed >>>>>> and overall responsiveness becoming really bad. >>>>>> >>>>>> Digging into it, I have found most time is wasted in >>>>>> com.sun.javafx.text.GlyphLayout.layout (as represented by >>>>>> PangoGlyphLayout >>>>>> on my Linux machine), which in turn is called >>>>>> by com.sun.javafx.text.PrismTextLayout.shape, which has: >>>>>> >>>>>> if (run.isComplex()) { >>>>>> /* Use GlyphLayout to shape complex text */ >>>>>> layout.layout(run, font, strike, chars); >>>>>> } else { >>>>>> ... >>>>>> if (layoutCache == null) { >>>>>> ... >>>>>> } else { >>>>>> ... >>>>>> } >>>>>> } >>>>>> >>>>>> which to my very naive reading seems as if while non-complex (with >>>>>> all BiDi >>>>>> text considered complex) glyph runs are cached, complex runs are never >>>>>> cached, which forces re-calculation every time. >>>>>> >>>>>> I'm trying to read and understand this part better, but could it be >>>>>> possible that this is the issue? How feasible would it be to have a >>>>>> layout >>>>>> cache for complex runs, or at least non-complex BiDi runs? >>>>>> >>>>>> Thanks, >>>>>> Itai. >>>>>> >>>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8129582 >>>>>> >>>>> >>>> >>> >>> >> > From philip.race at oracle.com Sun Mar 18 18:28:54 2018 From: philip.race at oracle.com (Philip Race) Date: Sun, 18 Mar 2018 11:28:54 -0700 Subject: Question/discussion about JDK-8129582 In-Reply-To: References: <586D3053.3020308@oracle.com> <827bf5c3-1e12-c4b4-5bad-aeb5c28e6864@oracle.com> Message-ID: <5AAEAFE6.8010408@oracle.com> It seems we should look at this. I apparently never saw or read (acc. to my mailer) previous email where you identified a problem with PangoGlyphLayout else we'd likely have looked at it when you sent it, as I agree this sounds like a major performance issue. -phil. On 3/18/18, 4:19 AM, Itai wrote: > Hello, > > In hopes of getting this bug fixed, I have made changes to > `PangoGlyphLayout` so that is only allocates the FT2 FontMap once, and > uses a `PlatformImpl.FinishListener` to unref it when the JavaFX > platform exits. Attached is the modified version of the file. > In my personal tests, depending on hardware used, there is a speedup > of between x2 and x10 in layout times, and scrolling large > Lists/Tables feels as snappy with CTL languages as with any other > language. > For anyone wanting to test it, remember this bug only affects Linux, > and only CTL languages (such as Arabic, Farsi, Hebrew and Hindi). > > Regards, > Itai. > > On Sun, Jan 8, 2017 at 11:39 PM, Itai > wrote: > > I think I have found two problems. The first, and probably most > critical one, is that a new PangoFontMap is created for every call > of PangoGlyphLayout#layout. It is not entirely clear from the > Pango documentation what the lifetime or intended usage of a > PangoFontMap is, but I have found this comment in [1]: > > "But note that a PangoFontMap is a big expensive object. So, you > *really* want to be using only one for your entire program. > Frequently calling pango_ft2_font_map_new() is going kill > the performance of your application." > > This seems to imply PangoFontMap is intended as a global (per > display?) font cache. Indeed, creating only one PangoFontMap seems > to improve performance drastically, although I'm not sure what is > the best way to handle this object (i.e. when and how it should be > re-used and freed), as it should probably (?) be held for the > entire lifetime of the JavaFX application. > > The second problem is probably less significant, but could still > theoretically hurt performance - it has to do with the usage of > g_list_nth_data, which as per [2] has O(N) complexity, and is > called once per item in the list, which yields O(N^2) complexity. > Replacing it with linked-list traversal with g_list_next should > reduce this back to O(N). > > I hope this information is clear enough. As I said I lack the > overall understanding of the JavaFX platform to know where and how > to manage a global object, such as PangoFontMap should apparently > be, so I refrain from posting any patch that I know would be wrong. > > Regards, > Itai. > > [1]: > https://mail.gnome.org/archives/gtk-list/2005-April/msg00105.html > > [2]: > https://developer.gnome.org/programming-guidelines/stable/glist.html.en > > > On Sun, Jan 8, 2017 at 8:08 PM, Itai > wrote: > > Thank you for the link, it's an interesting read indeed! > > I wasn't really skipping layout, just using the much simpler > layout used by Latin scripts, but you are correct that this > will break for anything more complex - this has nothing to do > with BiDi though, more to do with complex layout elements > (like diacritic or cantillation marks for Hebrew, or general > Arabic/Farsi text). > Indeed, this can't be a general solution, but I guess I was > driven by frustration. > > I have tried some more configurations though, and found that > on Windows the loss of performance is much less noticeable, > which seems to mean that the problem is either: > 1. Pango is inherently slow / inherently slow when laying out > BiDi text. > 2. JavaFX uses Pango in a sub-optimal / redundant way. > 3. The JNI / native calls to Pango are done in a sub-optimal way. > > Option 1 can be easily debunked, as general Gnome/GTK > applications run as smoothly with BiDi text as with Latin / > LTR text. > For options 2 and 3 I guess some more digging into the code > must be done. My understanding is that JNI calls are not > likely to incur performance loss to such a degree, unless very > large amounts of memory are copied back and forth between Java > and native code, so I'll start by reading into the Pango > documentation and understanding the logic of PangoGlyphLayout. > > If you have any input on this or believe my assumptions or > conclusions are wrong I'd be glad to hear. I realize you are > all busy with the upcoming 9 release, so I'll try to get as > detailed a result as I can. > > Regards, > Itai. > > On Wed, Jan 4, 2017 at 8:44 PM, Phil Race > > wrote: > > You can't skip layout just because it is bidi .. > where here you are apparently implicitly meaning Hebrew. > This might be apparently working but may not always work even > for Hebrew and will be a disaster for Arabic. > > Here is a web page which talks about OTL (OpenType Layout) > for Hebrew : > https://www.microsoft.com/typography/OpenTypeDev/hebrew/intro.htm > > I can't say offhand why this might be exclusive to FX. > That test case would be handy. > So this needs more analysis even if you found a way to > limit this to > specifically Latin+Hebrew. > > -phil. > > > On 01/04/2017 10:32 AM, Itai wrote: >> Some quick-and-dirty thing I hacked now and seems to >> improve the performance drastically is something like: >> >> if (complex but not bidi) { >> use GlyphLayout. >> } else if (bidi) { >> use java.text.Bidi.reorderVisually to get visual glyph >> order, then use same implementation as non-bidi >> non-complex layout >> } else { >> ... >> } >> >> Very minimal tests show it working correctly, and >> performance is 8-10 times faster (on par with non-bidi >> text). >> Do you think this solution makes sense? Can you see any >> obvious pitfalls? >> If it seems OK I'll try some more tests and then work it >> into something clean enough to submit as a patch suggestion. >> >> >> On Wed, Jan 4, 2017 at 7:48 PM, Itai > > wrote: >> >> Thanks for replying. >> I think I understand what you're saying about the >> cache. As for complexity - I'm mostly working with >> text which is only in Hebrew, which isn't complex as >> far as I understand the definition (no glyph "fusing" >> as in Arabic or Farsi). I can work with minor >> performance drops, but when the same window takes >> more than 10 times to show if it has Hebrew labels is >> a lot more than minor - and this is exclusive to >> JavaFX, so it's not like this problem is unsolvable. >> >> Perhaps the caching is indeed not the correct >> solution, but maybe there can be a way to simplify >> the layout in non-complex BiDi cases? Or optimize >> PangoGlyphLayout.layout? >> >> Thank you again for replying, I really hope this >> issue can see some improvement. >> >> On Wed, Jan 4, 2017 at 7:26 PM, Philip Race >> > > wrote: >> >> The cache is a heuristic optimisation and whether >> it helps depends on how well that cache is used. >> It is a time-space trade-off and I'd expect it to >> show up as helping more in micro-benchmarks or >> text-intensive benchmarks which use the same text >> broken in the same way. >> Complex text layout is inherently slower and if >> you are doing a lot of it .. it will be slow .. and >> unless it is repeated a cache won't help. >> During start-up I'd *expect* that there isn't a >> lot of re-use going on. >> >> You would need to profile how often the same >> text (and attributes) are passed through this code. >> If you could provide us a test case we could >> examine it too. >> >> If it were a real use case, then we'd move on to >> examine the feasibility of caching ... >> >> -phil. >> >> >> >> On 1/4/17, 9:19 AM, Itai wrote: >> >> Recently JDK-8129582 [1] started really >> affecting me, with startup speed >> and overall responsiveness becoming really bad. >> >> Digging into it, I have found most time is >> wasted in >> com.sun.javafx.text.GlyphLayout.layout (as >> represented by PangoGlyphLayout >> on my Linux machine), which in turn is called >> by com.sun.javafx.text.PrismTextLayout.shape, >> which has: >> >> if (run.isComplex()) { >> /* Use GlyphLayout to shape >> complex text */ >> layout.layout(run, font, strike, >> chars); >> } else { >> ... >> if (layoutCache == null) { >> ... >> } else { >> ... >> } >> } >> >> which to my very naive reading seems as if >> while non-complex (with all BiDi >> text considered complex) glyph runs are >> cached, complex runs are never >> cached, which forces re-calculation every time. >> >> I'm trying to read and understand this part >> better, but could it be >> possible that this is the issue? How feasible >> would it be to have a layout >> cache for complex runs, or at least >> non-complex BiDi runs? >> >> Thanks, >> Itai. >> >> [1]: >> https://bugs.openjdk.java.net/browse/JDK-8129582 >> >> >> >> > > > > From johan.vos at gluonhq.com Mon Mar 19 08:02:25 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 19 Mar 2018 08:02:25 +0000 Subject: Gradle wrappers Message-ID: Hi, Using Gradle wrappers has been discussed a number of times, but there was never a clear resolution afaik. Andres opened an issue for using gradle wrappers: https://github.com/javafxports/openjdk-jfx/issues/23 I personally like gradle wrappers myself, it makes it easier to automate builds etc. If developers really want to use a specific (other) gradle version, it is of course very well possible to do so. Opinions? - Johan From kevin.rushforth at oracle.com Mon Mar 19 12:40:13 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 19 Mar 2018 05:40:13 -0700 Subject: Gradle wrappers In-Reply-To: References: Message-ID: <5AAFAFAD.1020309@oracle.com> As long as it is optional, this seems like a fine idea. When we explored it before, there was some concern about checking in the gradlew.jar file to the repo -- we would need to get additional third-party legal approval -- so I would need to check on that before this can be merged to the mainline. -- Kevin Johan Vos wrote: > Hi, > > Using Gradle wrappers has been discussed a number of times, but there was > never a clear resolution afaik. > > Andres opened an issue for using gradle wrappers: > https://github.com/javafxports/openjdk-jfx/issues/23 > > I personally like gradle wrappers myself, it makes it easier to automate > builds etc. If developers really want to use a specific (other) gradle > version, it is of course very well possible to do so. > > Opinions? > > - Johan > From ambarish.rapte at oracle.com Mon Mar 19 14:10:53 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 19 Mar 2018 07:10:53 -0700 (PDT) Subject: [11] RFR : JDK-8195800 : Eliminate dependency on sun.reflect.misc in javafx modules Message-ID: Hi Kevin, Alan & Mandy, Request you to review this fix: Webrev: http://cr.openjdk.java.net/~arapte/fx/8195800/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8195800 Regards, Ambarish From mandy.chung at oracle.com Mon Mar 19 18:37:48 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 19 Mar 2018 11:37:48 -0700 Subject: [11] RFR : JDK-8195800 : Eliminate dependency on sun.reflect.misc in javafx modules In-Reply-To: References: Message-ID: <21ef3838-af00-4885-3f15-e89fa3f292a5@oracle.com> On 3/19/18 7:10 AM, Ambarish Rapte wrote: > > Hi Kevin, Alan & Mandy, > > ??????????????? Request you to review this fix: > > ??????????????? Webrev: > http://cr.openjdk.java.net/~arapte/fx/8195800/webrev.00/ > > > ??????????????? JBS: https://bugs.openjdk.java.net/browse/JDK-8195800 > This looks okay.? Nit FieldUtil isn't a trampoline class and you may just drop this comment: 30 /* 31 * Create a trampoline class. 32 */ Mandy From kevin.rushforth at oracle.com Mon Mar 19 21:19:47 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 19 Mar 2018 14:19:47 -0700 Subject: [11] RFR : JDK-8195800 : Eliminate dependency on sun.reflect.misc in javafx modules In-Reply-To: <21ef3838-af00-4885-3f15-e89fa3f292a5@oracle.com> References: <21ef3838-af00-4885-3f15-e89fa3f292a5@oracle.com> Message-ID: <5AB02973.6090904@oracle.com> This looks good to me, too, with one comment: The three new files have DOS line endings. Please convert to UNIX-style line endings, else it will fail jcheck (and fail the tools/scripts/checkWhiteSpace). -- Kevin mandy chung wrote: > > > On 3/19/18 7:10 AM, Ambarish Rapte wrote: >> >> Hi Kevin, Alan & Mandy, >> >> >> >> Request you to review this fix: >> >> Webrev: >> http://cr.openjdk.java.net/~arapte/fx/8195800/webrev.00/ >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8195800 >> >> >> > > This looks okay. Nit FieldUtil isn't a trampoline class and you may > just drop this comment: > > 30 /* > 31 * Create a trampoline class. > 32 */ > > > Mandy From nlisker at gmail.com Tue Mar 20 01:36:45 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 20 Mar 2018 03:36:45 +0200 Subject: JDK-8130379: Enhance the Bounds class with getCenter method In-Reply-To: <5AA6EBFF.1030509@oracle.com> References: <5AA6EBFF.1030509@oracle.com> Message-ID: Hi Kevin, I didn't see any opinions after a week. Please look at the webrev for: https://bugs.openjdk.java.net/browse/JDK-8130379 http://cr.openjdk.java.net/~nlisker/8130379/webrev.00/ I'm still slightly in favor of having the 2D and 3D center methods, but the webrev does not contain them. Thanks, Nir On Mon, Mar 12, 2018 at 11:07 PM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > Hi Nir, > > This seems like a simple enough RFE, and I am not aware of anyone else > working on it, nor any barriers that would make it difficult. > > As with any RFE that adds API (or implements a new feature) the API > additions will need to be approved first. Currently we use the CSR process > [1][2], but we will want to change that at some point. Note that as > indicated in the "More community participation in JavaFX" thread [3], new > API / new features will still have a higher bar for acceptance than bug > fixes. > > Also, any new feature needs to be accompanied by API docs and tests. > > Thanks! > > -- Kevin > > [1] https://wiki.openjdk.java.net/display/csr/Main > [2] https://wiki.openjdk.java.net/display/csr/CSR+FAQs > [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-Febr > uary/021335.html > > > > > Nir Lisker wrote: > >> Hello, >> >> I would like to work on https://bugs.openjdk.java.net/browse/JDK-8130379, >> which adds convenience API to the Bounds class. Any comments? >> >> - Nir >> >> > From mike.ennen at gmail.com Tue Mar 20 01:39:52 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 19 Mar 2018 18:39:52 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <5A53FE9F.6000304@oracle.com> References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> Message-ID: Ping :) On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth wrote: > I'll take a look some time after RDP2 of JDK 10. > > > -- Kevin > > > Michael Ennen wrote: > > Hey Kevin, > > Hope you had a good holiday. Hopefully you will get some time in the > coming weeks > to review my work. > > Thanks! > > On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Sure, no problem. One quick comment is that a common way to solve this is >> by delegating to an implementation class, which would then be sub-classes. >> >> >> -- Kevin >> >> >> Michael Ennen wrote: >> >> I am not trying to be a burden here. I understand that you may not have >> time to hand-hold >> to this degree. I will try and make progress, sorry for the follow up >> question. >> >> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen >> wrote: >> >>> How can Robot call into the implementation when it is a super class of >>> the implementations? >>> >>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> >>>> >>>> Michael Ennen wrote: >>>> >>>> I have a question about how to proceed with the Robot code. >>>> >>>> The base abstract Robot class is: https://github.com/brcolow >>>> /openjfx/blob/master/modules/javafx.graphics/src/main/java/j >>>> avafx/scene/robot/Robot.java >>>> >>>> As you can see for each method, such as "getMouseX()" there is a "_" >>>> prefixed method >>>> which is abstract and a non-prefixed method: >>>> >>>> protected abstract int _getMouseX(); >>>> >>>> public int getMouseX() { >>>> Application.checkEventThread(); >>>> return _getMouseX(); >>>> } >>>> >>>> I have copied this from the private Robot API. >>>> >>>> Is there a better way to do this? Would this pass review? >>>> >>>> >>>> Yes there are better ways to do this. No it would not pass review, >>>> since this would be leaking implementation into the public API. >>>> >>>> Rather than copying the public / protected methods from the internal >>>> package, it probably makes more sense to start with what a Robot API should >>>> look like and then have that call into the implementation (suitably >>>> modified so it better matches the public API). For one thing you will then >>>> leave the implementation, including the per-platform code, where it belongs >>>> -- in glass. The Robot API can be informed by the current implementation, >>>> but should not be defined by it. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Thanks very much. >>>> >>>> >>>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> Glad you got the build working. You can post back on this thread when >>>>> you are ready. >>>>> >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Michael Ennen wrote: >>>>> >>>>> Correction: >>>>> >>>>> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>> to buildSrc/addExports. >>>>> >>>>> For posterity :) >>>>> >>>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen >>>>> wrote: >>>>> >>>>>> Ah, indeed, missed adding "--add-opens javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>>> to buildSrc/addExports. >>>>>> Thanks for the guidance on that. >>>>>> >>>>>> I will continue to work on this in the GitHub repo and polish it up >>>>>> (add javadocs, better method signatures, etc.) and >>>>>> even plan on maybe improving the underlying native Robot >>>>>> implementations (for example fixing/improving the >>>>>> way color profiles are handled for MacRobot). >>>>>> >>>>>> I will also take a look at "fixing" JemmyFX to use the new public API >>>>>> (as well as any other place in the JavaFX code >>>>>> base that does). >>>>>> >>>>>> I was expecting that JDK 11 would be the appropriate time frame, >>>>>> especially because it will be the release where >>>>>> private APIs will be totally inaccessible, correct? >>>>>> >>>>>> After I get it in a reasonable state should I post back on this >>>>>> mailing list thread or what would be the appropriate >>>>>> way? >>>>>> >>>>>> Thanks Kevin. >>>>>> >>>>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth < >>>>>> kevin.rushforth at oracle.com> wrote: >>>>>> >>>>>>> This is a limitation of the the way --patch-modules works. You will >>>>>>> need to add an entry in: >>>>>>> >>>>>>> buildSrc/addExports >>>>>>> >>>>>>> Btw, as for the proposal itself, this might need to be a JEP >>>>>>> depending on the scope. In any case, it could be considered in the JDK 11 >>>>>>> time frame, but there are several things that need to be worked out before >>>>>>> making Robot a public API, including the fact that the JemmyFX framework in >>>>>>> the openjfx/jfx/tests directory uses Robot. Once you get a working >>>>>>> prototype, it would be interesting to discuss it in more detail. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> Michael Ennen wrote: >>>>>>> >>>>>>> Currently I am stuck with tests not being able to see the new >>>>>>> "javafx.scene.robot" module: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Task :systemTests:compileTestJava >>>>>>> >>>>>>> >>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34: >>>>>>> error: package javafx.scene.robot is not visible >>>>>>> import javafx.scene.robot.Robot; >>>>>>> ^ >>>>>>> (package javafx.scene.robot is declared in module javafx.graphics, which >>>>>>> does not export it) >>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33: >>>>>>> error: package javafx.scene.robot is not visible >>>>>>> import javafx.scene.robot.Robot; >>>>>>> >>>>>>> I have added: >>>>>>> >>>>>>> exports javafx.scene.robot; >>>>>>> >>>>>>> to: modules/javafx.graphics/src/main/java/module-info.java >>>>>>> >>>>>>> But this does not seem to be enough. >>>>>>> >>>>>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> I am still working on all the necessary changes to actually allow openjfx >>>>>>> to compile. >>>>>>> Tons to learn in that arena and I know the code as it is written won't >>>>>>> totally work. >>>>>>> For example one can no longer: >>>>>>> >>>>>>> #include "com_sun_glass_ui_Robot.h" >>>>>>> >>>>>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp >>>>>>> >>>>>>> But I am not sure how those headers are generated and if I can just simply >>>>>>> change >>>>>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt). >>>>>>> >>>>>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> I have created a (small) proposal (building on the work of Benjamin >>>>>>> Gudehaus) about moving some classes in to the public API so that TestFX (a >>>>>>> JavaFX UI testing framework) can continue to work with future JDK releases. >>>>>>> The somewhat nicely formatted proposal can be found as a Github gist: >>>>>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >>>>>>> >>>>>>> All suggested changes can be found by using Github Compare View: >>>>>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 >>>>>>> e1f4f1cb8f20430feaa53b6...master >>>>>>> >>>>>>> But I have copied it to this email for convenience: >>>>>>> >>>>>>> ----------------------- PROPOSAL ----------------------- >>>>>>> >>>>>>> TestFX, the JavaFX GUI testing framework currently requires 4 (four) >>>>>>> classes that are part of the JDK's private API. They are: >>>>>>> >>>>>>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op >>>>>>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/ >>>>>>> java/com/sun/glass/ui/Application.java) >>>>>>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx >>>>>>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/ >>>>>>> com/sun/glass/ui/Pixels.java) >>>>>>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/ >>>>>>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com >>>>>>> /sun/glass/ui/Robot.java) >>>>>>> [com.sun.javafx.application.ParametersImpl](http://hg.openjdk.java.net/openjfx/10-dev/rt/file/tip/modules/javafx. >>>>>>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java ) >>>>>>> >>>>>>> In order to compile the project with Java 9, we use the following flags: >>>>>>> >>>>>>> ```sh >>>>>>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx >>>>>>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx >>>>>>> ``` >>>>>>> >>>>>>> If the --add-exports flags are disabled in a future Java release TestFX >>>>>>> will require these four classes to be moved into the public API to >>>>>>> continue working. >>>>>>> >>>>>>> While these classes are probably not very useful for applications to use >>>>>>> directly, any JavaFX application wanting to write UI tests will most >>>>>>> likely >>>>>>> use TestFX and thus they will indirectly be using these classes. >>>>>>> >>>>>>> JavaFX internal tests also use these classes for essentially the same >>>>>>> purpose (UI tests). >>>>>>> >>>>>>> ### Details of Usage For Each Private API Class >>>>>>> >>>>>>> #### com.sun.javafx.application.ParametersImpl >>>>>>> >>>>>>> ##### TestFX Usage >>>>>>> >>>>>>> ```java >>>>>>> ParametersImpl parameters = new ParametersImpl(applicationArgs); >>>>>>> ParametersImpl.registerParameters(application, parameters); >>>>>>> ``` >>>>>>> >>>>>>> The parameters are set on a constructed Application. >>>>>>> >>>>>>> ##### Suggested Public API Replacement >>>>>>> >>>>>>> `javafx.application.Application`: >>>>>>> >>>>>>> ```java >>>>>>> /** >>>>>>> * Sets the parameters for this Application. >>>>>>> * >>>>>>> *

>>>>>>> * NOTE: this method should not be called from the Application >>>>>>> constructor, >>>>>>> * as it will return null. It may be called in the init() method or any >>>>>>> * time after that. >>>>>>> *

>>>>>>> * >>>>>>> * @param parameters the parameters to set for this Application >>>>>>> */ >>>>>>> public final Parameters setParameters(String... parameters) { >>>>>>> ParametersImpl parameters = new ParametersImpl(parameters); >>>>>>> ParametersImpl.registerParameters(this, parameters); >>>>>>> } >>>>>>> ``` >>>>>>> >>>>>>> #### com.sun.glass.ui.Application >>>>>>> >>>>>>> ##### TestFX Usage >>>>>>> >>>>>>> ```java >>>>>>> return Application.GetApplication().createRobot(); >>>>>>> ``` >>>>>>> >>>>>>> The Application class is used to instantiate a Robot. >>>>>>> >>>>>>> ##### Suggested Public API Replacement >>>>>>> >>>>>>> `javafx.application.Application`: >>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>> x.graphics/src/main/java/javafx/application/Application.java#L527 >>>>>>> >>>>>>> #### com.sun.glass.ui.Pixels >>>>>>> >>>>>>> ##### TestFX Usage >>>>>>> >>>>>>> ```java >>>>>>> @Override >>>>>>> public Image getCaptureRegion(Rectangle2D region) { >>>>>>> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> { >>>>>>> Pixels glassPixels = useRobot().getScreenCapture( >>>>>>> (int) region.getMinX(), (int) region.getMinY(), >>>>>>> (int) region.getWidth(), (int) region.getHeight() >>>>>>> ); >>>>>>> return convertFromGlassPixels(glassPixels); >>>>>>> }); >>>>>>> } >>>>>>> >>>>>>> private Image convertFromGlassPixels(Pixels glassPixels) { >>>>>>> int width = glassPixels.getWidth(); >>>>>>> int height = glassPixels.getHeight(); >>>>>>> WritableImage image = new WritableImage(width, height); >>>>>>> >>>>>>> int bytesPerComponent = glassPixels.getBytesPerComponent(); >>>>>>> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) { >>>>>>> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels(); >>>>>>> writeIntBufferToImage(intBuffer, image); >>>>>>> } >>>>>>> >>>>>>> return image; >>>>>>> } >>>>>>> >>>>>>> private void writeIntBufferToImage(IntBuffer intBuffer, >>>>>>> WritableImage image) { >>>>>>> PixelWriter pixelWriter = image.getPixelWriter(); >>>>>>> double width = image.getWidth(); >>>>>>> double height = image.getHeight(); >>>>>>> >>>>>>> for (int y = 0; y < height; y++) { >>>>>>> for (int x = 0; x < width; x++) { >>>>>>> int argb = intBuffer.get(); >>>>>>> pixelWriter.setArgb(x, y, argb); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> ``` >>>>>>> >>>>>>> Pixels is used to create a screen capture. >>>>>>> >>>>>>> ##### Suggested Public API Replacement >>>>>>> >>>>>>> Bypass needing to expose the Pixels class to the public API by >>>>>>> changing the getScreenCapture method of Robot - that is, changing: >>>>>>> >>>>>>> `public Pixels getScreenCapture(int x, int y, int width, int height)` >>>>>>> >>>>>>> to: >>>>>>> >>>>>>> `public Image getScreenCapture(int x, int y, int width, int height)` >>>>>>> >>>>>>> #### com.sun.glass.ui.Robot >>>>>>> >>>>>>> ##### TestFX Usage >>>>>>> >>>>>>> Essentially every method of Robot is used: >>>>>>> >>>>>>> ``` >>>>>>> public void keyPress(int code) >>>>>>> public void keyRelease(int code) >>>>>>> public int getMouseX() >>>>>>> public int getMouseY() >>>>>>> public void mouseMove(int x, int y) >>>>>>> public void mousePress(int buttons) >>>>>>> public void mouseRelease(int buttons) >>>>>>> public void mouseWheel(int wheelAmt) >>>>>>> public int getPixelColor(int x, int y) >>>>>>> public Pixels getScreenCapture(int x, int y, int width, int height) >>>>>>> ``` >>>>>>> >>>>>>> ##### Suggested Public API Replacement >>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Michael Ennen >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Michael Ennen >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>>> >>>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>>> >>>> >>> >>> >>> -- >>> Michael Ennen >>> >> >> >> >> -- >> Michael Ennen >> >> > > > -- > Michael Ennen > > -- Michael Ennen From kevin.rushforth at oracle.com Tue Mar 20 12:28:23 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 20 Mar 2018 05:28:23 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> Message-ID: <5AB0FE67.9090909@oracle.com> I will do an initial review of the API today and suggest next steps. -- Kevin Michael Ennen wrote: > Ping :) > > On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth > > wrote: > > I'll take a look some time after RDP2 of JDK 10. > > > -- Kevin > > > Michael Ennen wrote: >> Hey Kevin, >> >> Hope you had a good holiday. Hopefully you will get some time in >> the coming weeks >> to review my work. >> >> Thanks! >> >> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth >> > >> wrote: >> >> Sure, no problem. One quick comment is that a common way to >> solve this is by delegating to an implementation class, which >> would then be sub-classes. >> >> >> -- Kevin >> >> >> Michael Ennen wrote: >>> I am not trying to be a burden here. I understand that you >>> may not have time to hand-hold >>> to this degree. I will try and make progress, sorry for the >>> follow up question. >>> >>> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen >>> > wrote: >>> >>> How can Robot call into the implementation when it is a >>> super class of the implementations? >>> >>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth >>> >> > wrote: >>> >>> >>> >>> Michael Ennen wrote: >>>> I have a question about how to proceed with the >>>> Robot code. >>>> >>>> The base abstract Robot class >>>> is: https://github.com/brcolow/openjfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java >>>> >>>> >>>> As you can see for each method, such as >>>> "getMouseX()" there is a "_" prefixed method >>>> which is abstract and a non-prefixed method: >>>> >>>> protected abstract int _getMouseX(); >>>> >>>> public int getMouseX() { >>>> Application.checkEventThread(); >>>> return _getMouseX(); >>>> } >>>> >>>> I have copied this from the private Robot API. >>>> >>>> Is there a better way to do this? Would this pass >>>> review? >>> >>> Yes there are better ways to do this. No it would >>> not pass review, since this would be leaking >>> implementation into the public API. >>> >>> Rather than copying the public / protected methods >>> from the internal package, it probably makes more >>> sense to start with what a Robot API should look >>> like and then have that call into the implementation >>> (suitably modified so it better matches the public >>> API). For one thing you will then leave the >>> implementation, including the per-platform code, >>> where it belongs -- in glass. The Robot API can be >>> informed by the current implementation, but should >>> not be defined by it. >>> >>> -- Kevin >>> >>> >>>> >>>> Thanks very much. >>>> >>>> >>>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth >>>> >>> > wrote: >>>> >>>> Glad you got the build working. You can post >>>> back on this thread when you are ready. >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> Michael Ennen wrote: >>>>> Correction: >>>>> >>>>> Adding ""--add-exports >>>>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>> to buildSrc/addExports. >>>>> >>>>> For posterity :) >>>>> >>>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen >>>>> >>>> > wrote: >>>>> >>>>> Ah, indeed, missed adding "--add-opens >>>>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>> to buildSrc/addExports. >>>>> Thanks for the guidance on that. >>>>> >>>>> I will continue to work on this in the >>>>> GitHub repo and polish it up (add >>>>> javadocs, better method signatures, etc.) >>>>> and >>>>> even plan on maybe improving the >>>>> underlying native Robot implementations >>>>> (for example fixing/improving the >>>>> way color profiles are handled for MacRobot). >>>>> >>>>> I will also take a look at "fixing" >>>>> JemmyFX to use the new public API (as well >>>>> as any other place in the JavaFX code >>>>> base that does). >>>>> >>>>> I was expecting that JDK 11 would be the >>>>> appropriate time frame, especially because >>>>> it will be the release where >>>>> private APIs will be totally inaccessible, >>>>> correct? >>>>> >>>>> After I get it in a reasonable state >>>>> should I post back on this mailing list >>>>> thread or what would be the appropriate >>>>> way? >>>>> >>>>> Thanks Kevin. >>>>> >>>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin >>>>> Rushforth >>>> > wrote: >>>>> >>>>> This is a limitation of the the way >>>>> --patch-modules works. You will need >>>>> to add an entry in: >>>>> >>>>> buildSrc/addExports >>>>> >>>>> Btw, as for the proposal itself, this >>>>> might need to be a JEP depending on >>>>> the scope. In any case, it could be >>>>> considered in the JDK 11 time frame, >>>>> but there are several things that need >>>>> to be worked out before making Robot a >>>>> public API, including the fact that >>>>> the JemmyFX framework in the >>>>> openjfx/jfx/tests directory uses >>>>> Robot. Once you get a working >>>>> prototype, it would be interesting to >>>>> discuss it in more detail. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Michael Ennen wrote: >>>>>> Currently I am stuck with tests not being able to see the new >>>>>> "javafx.scene.robot" module: >>>>>> >>>>>> >>>>>>> Task :systemTests:compileTestJava >>>>>>> >>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34: >>>>>> error: package javafx.scene.robot is not visible >>>>>> import javafx.scene.robot.Robot; >>>>>> ^ >>>>>> (package javafx.scene.robot is declared in module javafx.graphics, which >>>>>> does not export it) >>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33: >>>>>> error: package javafx.scene.robot is not visible >>>>>> import javafx.scene.robot.Robot; >>>>>> >>>>>> I have added: >>>>>> >>>>>> exports javafx.scene.robot; >>>>>> >>>>>> to: modules/javafx.graphics/src/main/java/module-info.java >>>>>> >>>>>> But this does not seem to be enough. >>>>>> >>>>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen wrote: >>>>>> >>>>>> >>>>>>> I am still working on all the necessary changes to actually allow openjfx >>>>>>> to compile. >>>>>>> Tons to learn in that arena and I know the code as it is written won't >>>>>>> totally work. >>>>>>> For example one can no longer: >>>>>>> >>>>>>> #include "com_sun_glass_ui_Robot.h" >>>>>>> >>>>>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp >>>>>>> >>>>>>> But I am not sure how those headers are generated and if I can just simply >>>>>>> change >>>>>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt). >>>>>>> >>>>>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> I have created a (small) proposal (building on the work of Benjamin >>>>>>>> Gudehaus) about moving some classes in to the public API so that TestFX (a >>>>>>>> JavaFX UI testing framework) can continue to work with future JDK releases. >>>>>>>> The somewhat nicely formatted proposal can be found as a Github gist: >>>>>>>> >>>>>>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >>>>>>>> >>>>>>>> All suggested changes can be found by using Github Compare View: >>>>>>>> >>>>>>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 >>>>>>>> e1f4f1cb8f20430feaa53b6...master >>>>>>>> >>>>>>>> But I have copied it to this email for convenience: >>>>>>>> >>>>>>>> ----------------------- PROPOSAL ----------------------- >>>>>>>> >>>>>>>> TestFX, the JavaFX GUI testing framework currently requires 4 (four) >>>>>>>> classes that are part of the JDK's private API. They are: >>>>>>>> >>>>>>>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op >>>>>>>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/ >>>>>>>> java/com/sun/glass/ui/Application.java) >>>>>>>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx >>>>>>>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/ >>>>>>>> com/sun/glass/ui/Pixels.java) >>>>>>>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/ >>>>>>>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com >>>>>>>> /sun/glass/ui/Robot.java) >>>>>>>> [com.sun.javafx.application.Pa rametersImpl](http://hg.openjd >>>>>>>> k.java.net/openjfx/10-dev/rt/file/tip/modules/javafx. >>>>>>>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java ) >>>>>>>> >>>>>>>> In order to compile the project with Java 9, we use the following flags: >>>>>>>> >>>>>>>> ```sh >>>>>>>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx >>>>>>>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx >>>>>>>> ``` >>>>>>>> >>>>>>>> If the --add-exports flags are disabled in a future Java release TestFX >>>>>>>> will require these four classes to be moved into the public API to >>>>>>>> continue working. >>>>>>>> >>>>>>>> While these classes are probably not very useful for applications to use >>>>>>>> directly, any JavaFX application wanting to write UI tests will most >>>>>>>> likely >>>>>>>> use TestFX and thus they will indirectly be using these classes. >>>>>>>> >>>>>>>> JavaFX internal tests also use these classes for essentially the same >>>>>>>> purpose (UI tests). >>>>>>>> >>>>>>>> ### Details of Usage For Each Private API Class >>>>>>>> >>>>>>>> #### com.sun.javafx.application.ParametersImpl >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> ```java >>>>>>>> ParametersImpl parameters = new ParametersImpl(applicationArgs); >>>>>>>> ParametersImpl.registerParameters(application, parameters); >>>>>>>> ``` >>>>>>>> >>>>>>>> The parameters are set on a constructed Application. >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> `javafx.application.Application`: >>>>>>>> >>>>>>>> ```java >>>>>>>> /** >>>>>>>> * Sets the parameters for this Application. >>>>>>>> * >>>>>>>> *

>>>>>>>> * NOTE: this method should not be called from the Application >>>>>>>> constructor, >>>>>>>> * as it will return null. It may be called in the init() method or any >>>>>>>> * time after that. >>>>>>>> *

>>>>>>>> * >>>>>>>> * @param parameters the parameters to set for this Application >>>>>>>> */ >>>>>>>> public final Parameters setParameters(String... parameters) { >>>>>>>> ParametersImpl parameters = new ParametersImpl(parameters); >>>>>>>> ParametersImpl.registerParameters(this, parameters); >>>>>>>> } >>>>>>>> ``` >>>>>>>> >>>>>>>> #### com.sun.glass.ui.Application >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> ```java >>>>>>>> return Application.GetApplication().createRobot(); >>>>>>>> ``` >>>>>>>> >>>>>>>> The Application class is used to instantiate a Robot. >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> `javafx.application.Application`: >>>>>>>> >>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>> x.graphics/src/main/java/javafx/application/Application.java#L527 >>>>>>>> >>>>>>>> #### com.sun.glass.ui.Pixels >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> ```java >>>>>>>> @Override >>>>>>>> public Image getCaptureRegion(Rectangle2D region) { >>>>>>>> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> { >>>>>>>> Pixels glassPixels = useRobot().getScreenCapture( >>>>>>>> (int) region.getMinX(), (int) region.getMinY(), >>>>>>>> (int) region.getWidth(), (int) region.getHeight() >>>>>>>> ); >>>>>>>> return convertFromGlassPixels(glassPixels); >>>>>>>> }); >>>>>>>> } >>>>>>>> >>>>>>>> private Image convertFromGlassPixels(Pixels glassPixels) { >>>>>>>> int width = glassPixels.getWidth(); >>>>>>>> int height = glassPixels.getHeight(); >>>>>>>> WritableImage image = new WritableImage(width, height); >>>>>>>> >>>>>>>> int bytesPerComponent = glassPixels.getBytesPerComponent(); >>>>>>>> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) { >>>>>>>> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels(); >>>>>>>> writeIntBufferToImage(intBuffer, image); >>>>>>>> } >>>>>>>> >>>>>>>> return image; >>>>>>>> } >>>>>>>> >>>>>>>> private void writeIntBufferToImage(IntBuffer intBuffer, >>>>>>>> WritableImage image) { >>>>>>>> PixelWriter pixelWriter = image.getPixelWriter(); >>>>>>>> double width = image.getWidth(); >>>>>>>> double height = image.getHeight(); >>>>>>>> >>>>>>>> for (int y = 0; y < height; y++) { >>>>>>>> for (int x = 0; x < width; x++) { >>>>>>>> int argb = intBuffer.get(); >>>>>>>> pixelWriter.setArgb(x, y, argb); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> ``` >>>>>>>> >>>>>>>> Pixels is used to create a screen capture. >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> Bypass needing to expose the Pixels class to the public API by >>>>>>>> changing the getScreenCapture method of Robot - that is, changing: >>>>>>>> >>>>>>>> `public Pixels getScreenCapture(int x, int y, int width, int height)` >>>>>>>> >>>>>>>> to: >>>>>>>> >>>>>>>> `public Image getScreenCapture(int x, int y, int width, int height)` >>>>>>>> >>>>>>>> #### com.sun.glass.ui.Robot >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> Essentially every method of Robot is used: >>>>>>>> >>>>>>>> ``` >>>>>>>> public void keyPress(int code) >>>>>>>> public void keyRelease(int code) >>>>>>>> public int getMouseX() >>>>>>>> public int getMouseY() >>>>>>>> public void mouseMove(int x, int y) >>>>>>>> public void mousePress(int buttons) >>>>>>>> public void mouseRelease(int buttons) >>>>>>>> public void mouseWheel(int wheelAmt) >>>>>>>> public int getPixelColor(int x, int y) >>>>>>>> public Pixels getScreenCapture(int x, int y, int width, int height) >>>>>>>> ``` >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Michael Ennen >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Michael Ennen >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>> >>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>> >>> >>> >>> >>> -- >>> Michael Ennen >>> >>> >>> >>> >>> -- >>> Michael Ennen >> >> >> >> >> -- >> Michael Ennen > > > > > -- > Michael Ennen From kevin.rushforth at oracle.com Tue Mar 20 14:59:08 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 20 Mar 2018 07:59:08 -0700 Subject: [11] Review request: 8198654: Switch FX's default GTK version to 3 Message-ID: <5AB121BC.3070105@oracle.com> Phil, Please review the FX change to use GTK 3 by default, as you recently did for AWT: https://bugs.openjdk.java.net/browse/JDK-8198654 http://cr.openjdk.java.net/~kcr/8198654/webrev.00/ I have run a full test, including all robot tests, on Ubuntu 16.04 using two different JDKs -- one with your AWT fix and one without. No new issues were discovered. Thanks. -- Kevin From kevin.rushforth at oracle.com Tue Mar 20 23:28:33 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 20 Mar 2018 16:28:33 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> Message-ID: <5AB19921.3000906@oracle.com> Hi Michael, Here is some quick feedback. I think what you have is heading in the right direction as far as the public API goes. I'd like to get some feedback from other developers as well. I would want to make sure that the API meets the needs of multiple developers. I took a look at the public class and as I may have mentioned earlier, it will help to split the API and the implementation even further, by creating a peer object as we do for Scene, Stage, etc., rather than having the glass platform implementation directly subclass the public Robot class. Then you can easily delegate to the Glass Robot peer without having any implementation leak into the public API (e.g., the overridden create and dispose methods). So what you would have in that case is something more like this: public final class Robot { private final GlassRobot peer; public Robot() { // Ensure we have proper permission for creating a robot. final SecurityManager sm = System.getSecurityManager(); if (sm != null) { sm.checkPermission(CREATE_ROBOT_PERMISSION); } Application.checkEventThread(); peer = Toolkit.createRobot(); } // NOTE: for the rest, the peer can do the thread check public void keyPress(KeyCode keyCode) { peer.keyPress(keyCode); } public void keyRelease(KeyCode keyCode) { peer.keyRelease(keyCode); } public final void keyType(KeyCode keyCode) { keyPress(keyCode); keyRelease(keyCode); } ... And so on. The Toolkit class can return a glass robot "peer" which should then only need minor changes (e.g., to the signatures of methods that have slightly different types) from the current one. The QuantumToolkit implementation of createPeer can construct, initialize, and return the GlassRobot instance. The StubToolkit and DummyToolkit implementations can throw an UnsuppportedOperationException. As for the public API, the set of methods you have seem mostly what we would want. Here are a few quick thoughts: void keyPress(KeyCode keyCode); void keyRelease(KeyCode keyCode); void keyType(KeyCode keyCode); int getMouseX(); // maybe should return double? int getMouseY(); Point2D getMousePosition(); void mouseMove(int x, int y); // maybe params should be double? void mouseMove(Point2D location); void mousePress(MouseButton button); // This one seems redundant...covered by the next method void mousePress(MouseButton... buttons); void mouseRelease(MouseButton button); // This one seems redundant...covered by the next method void mouseRelease(MouseButton... buttons); // I don't see the need for this method void mouseWheel(int wheelAmt, VerticalDirection direction); void mouseWheel(int wheelAmt); Color getPixelColor(int x, int y); // maybe params should be double? Color getPixelColor(Point2D location); // Probably the following should return WritableImage to match Snapshot. maybe also have a variable that takes a WritableImage to allow caller to allocate and reuse (that might overkill in this case)? Image getScreenCapture(int x, int y, int width, int height); // maybe params should be double? Image getScreenCapture(int x, int y, int width, int height, boolean scaleToFit); // maybe params should be double? Image getScreenCapture(Rectangle2D region); Image getScreenCapture(Rectangle2D region, boolean scaleToFit); void getScreenCapture(int x, int y, int width, int height, int[] data); // Not sure we need / want this one The biggest question I have is whether we should follow the pattern of the other related public APIs in Screen and Stage and use doubles everywhere rather than ints. Also, we will need to see whether there are any implications for multiple screens (probably not, but the docs will need to specify what coordinates the x, and y values are in). Hopefully this will spark a discussion. -- Kevin Michael Ennen wrote: > Ping :) > > On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth > > wrote: > > I'll take a look some time after RDP2 of JDK 10. > > > -- Kevin > > > Michael Ennen wrote: >> Hey Kevin, >> >> Hope you had a good holiday. Hopefully you will get some time in >> the coming weeks >> to review my work. >> >> Thanks! >> >> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth >> > >> wrote: >> >> Sure, no problem. One quick comment is that a common way to >> solve this is by delegating to an implementation class, which >> would then be sub-classes. >> >> >> -- Kevin >> >> >> Michael Ennen wrote: >>> I am not trying to be a burden here. I understand that you >>> may not have time to hand-hold >>> to this degree. I will try and make progress, sorry for the >>> follow up question. >>> >>> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen >>> > wrote: >>> >>> How can Robot call into the implementation when it is a >>> super class of the implementations? >>> >>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth >>> >> > wrote: >>> >>> >>> >>> Michael Ennen wrote: >>>> I have a question about how to proceed with the >>>> Robot code. >>>> >>>> The base abstract Robot class >>>> is: https://github.com/brcolow/openjfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java >>>> >>>> >>>> As you can see for each method, such as >>>> "getMouseX()" there is a "_" prefixed method >>>> which is abstract and a non-prefixed method: >>>> >>>> protected abstract int _getMouseX(); >>>> >>>> public int getMouseX() { >>>> Application.checkEventThread(); >>>> return _getMouseX(); >>>> } >>>> >>>> I have copied this from the private Robot API. >>>> >>>> Is there a better way to do this? Would this pass >>>> review? >>> >>> Yes there are better ways to do this. No it would >>> not pass review, since this would be leaking >>> implementation into the public API. >>> >>> Rather than copying the public / protected methods >>> from the internal package, it probably makes more >>> sense to start with what a Robot API should look >>> like and then have that call into the implementation >>> (suitably modified so it better matches the public >>> API). For one thing you will then leave the >>> implementation, including the per-platform code, >>> where it belongs -- in glass. The Robot API can be >>> informed by the current implementation, but should >>> not be defined by it. >>> >>> -- Kevin >>> >>> >>>> >>>> Thanks very much. >>>> >>>> >>>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth >>>> >>> > wrote: >>>> >>>> Glad you got the build working. You can post >>>> back on this thread when you are ready. >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> Michael Ennen wrote: >>>>> Correction: >>>>> >>>>> Adding ""--add-exports >>>>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>> to buildSrc/addExports. >>>>> >>>>> For posterity :) >>>>> >>>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen >>>>> >>>> > wrote: >>>>> >>>>> Ah, indeed, missed adding "--add-opens >>>>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>> to buildSrc/addExports. >>>>> Thanks for the guidance on that. >>>>> >>>>> I will continue to work on this in the >>>>> GitHub repo and polish it up (add >>>>> javadocs, better method signatures, etc.) >>>>> and >>>>> even plan on maybe improving the >>>>> underlying native Robot implementations >>>>> (for example fixing/improving the >>>>> way color profiles are handled for MacRobot). >>>>> >>>>> I will also take a look at "fixing" >>>>> JemmyFX to use the new public API (as well >>>>> as any other place in the JavaFX code >>>>> base that does). >>>>> >>>>> I was expecting that JDK 11 would be the >>>>> appropriate time frame, especially because >>>>> it will be the release where >>>>> private APIs will be totally inaccessible, >>>>> correct? >>>>> >>>>> After I get it in a reasonable state >>>>> should I post back on this mailing list >>>>> thread or what would be the appropriate >>>>> way? >>>>> >>>>> Thanks Kevin. >>>>> >>>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin >>>>> Rushforth >>>> > wrote: >>>>> >>>>> This is a limitation of the the way >>>>> --patch-modules works. You will need >>>>> to add an entry in: >>>>> >>>>> buildSrc/addExports >>>>> >>>>> Btw, as for the proposal itself, this >>>>> might need to be a JEP depending on >>>>> the scope. In any case, it could be >>>>> considered in the JDK 11 time frame, >>>>> but there are several things that need >>>>> to be worked out before making Robot a >>>>> public API, including the fact that >>>>> the JemmyFX framework in the >>>>> openjfx/jfx/tests directory uses >>>>> Robot. Once you get a working >>>>> prototype, it would be interesting to >>>>> discuss it in more detail. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Michael Ennen wrote: >>>>>> Currently I am stuck with tests not being able to see the new >>>>>> "javafx.scene.robot" module: >>>>>> >>>>>> >>>>>>> Task :systemTests:compileTestJava >>>>>>> >>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34: >>>>>> error: package javafx.scene.robot is not visible >>>>>> import javafx.scene.robot.Robot; >>>>>> ^ >>>>>> (package javafx.scene.robot is declared in module javafx.graphics, which >>>>>> does not export it) >>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33: >>>>>> error: package javafx.scene.robot is not visible >>>>>> import javafx.scene.robot.Robot; >>>>>> >>>>>> I have added: >>>>>> >>>>>> exports javafx.scene.robot; >>>>>> >>>>>> to: modules/javafx.graphics/src/main/java/module-info.java >>>>>> >>>>>> But this does not seem to be enough. >>>>>> >>>>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen wrote: >>>>>> >>>>>> >>>>>>> I am still working on all the necessary changes to actually allow openjfx >>>>>>> to compile. >>>>>>> Tons to learn in that arena and I know the code as it is written won't >>>>>>> totally work. >>>>>>> For example one can no longer: >>>>>>> >>>>>>> #include "com_sun_glass_ui_Robot.h" >>>>>>> >>>>>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp >>>>>>> >>>>>>> But I am not sure how those headers are generated and if I can just simply >>>>>>> change >>>>>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt). >>>>>>> >>>>>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> I have created a (small) proposal (building on the work of Benjamin >>>>>>>> Gudehaus) about moving some classes in to the public API so that TestFX (a >>>>>>>> JavaFX UI testing framework) can continue to work with future JDK releases. >>>>>>>> The somewhat nicely formatted proposal can be found as a Github gist: >>>>>>>> >>>>>>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >>>>>>>> >>>>>>>> All suggested changes can be found by using Github Compare View: >>>>>>>> >>>>>>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 >>>>>>>> e1f4f1cb8f20430feaa53b6...master >>>>>>>> >>>>>>>> But I have copied it to this email for convenience: >>>>>>>> >>>>>>>> ----------------------- PROPOSAL ----------------------- >>>>>>>> >>>>>>>> TestFX, the JavaFX GUI testing framework currently requires 4 (four) >>>>>>>> classes that are part of the JDK's private API. They are: >>>>>>>> >>>>>>>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op >>>>>>>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/ >>>>>>>> java/com/sun/glass/ui/Application.java) >>>>>>>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx >>>>>>>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/ >>>>>>>> com/sun/glass/ui/Pixels.java) >>>>>>>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/ >>>>>>>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com >>>>>>>> /sun/glass/ui/Robot.java) >>>>>>>> [com.sun.javafx.application.Pa rametersImpl](http://hg.openjd >>>>>>>> k.java.net/openjfx/10-dev/rt/file/tip/modules/javafx. >>>>>>>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java ) >>>>>>>> >>>>>>>> In order to compile the project with Java 9, we use the following flags: >>>>>>>> >>>>>>>> ```sh >>>>>>>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx >>>>>>>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx >>>>>>>> ``` >>>>>>>> >>>>>>>> If the --add-exports flags are disabled in a future Java release TestFX >>>>>>>> will require these four classes to be moved into the public API to >>>>>>>> continue working. >>>>>>>> >>>>>>>> While these classes are probably not very useful for applications to use >>>>>>>> directly, any JavaFX application wanting to write UI tests will most >>>>>>>> likely >>>>>>>> use TestFX and thus they will indirectly be using these classes. >>>>>>>> >>>>>>>> JavaFX internal tests also use these classes for essentially the same >>>>>>>> purpose (UI tests). >>>>>>>> >>>>>>>> ### Details of Usage For Each Private API Class >>>>>>>> >>>>>>>> #### com.sun.javafx.application.ParametersImpl >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> ```java >>>>>>>> ParametersImpl parameters = new ParametersImpl(applicationArgs); >>>>>>>> ParametersImpl.registerParameters(application, parameters); >>>>>>>> ``` >>>>>>>> >>>>>>>> The parameters are set on a constructed Application. >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> `javafx.application.Application`: >>>>>>>> >>>>>>>> ```java >>>>>>>> /** >>>>>>>> * Sets the parameters for this Application. >>>>>>>> * >>>>>>>> *

>>>>>>>> * NOTE: this method should not be called from the Application >>>>>>>> constructor, >>>>>>>> * as it will return null. It may be called in the init() method or any >>>>>>>> * time after that. >>>>>>>> *

>>>>>>>> * >>>>>>>> * @param parameters the parameters to set for this Application >>>>>>>> */ >>>>>>>> public final Parameters setParameters(String... parameters) { >>>>>>>> ParametersImpl parameters = new ParametersImpl(parameters); >>>>>>>> ParametersImpl.registerParameters(this, parameters); >>>>>>>> } >>>>>>>> ``` >>>>>>>> >>>>>>>> #### com.sun.glass.ui.Application >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> ```java >>>>>>>> return Application.GetApplication().createRobot(); >>>>>>>> ``` >>>>>>>> >>>>>>>> The Application class is used to instantiate a Robot. >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> `javafx.application.Application`: >>>>>>>> >>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>> x.graphics/src/main/java/javafx/application/Application.java#L527 >>>>>>>> >>>>>>>> #### com.sun.glass.ui.Pixels >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> ```java >>>>>>>> @Override >>>>>>>> public Image getCaptureRegion(Rectangle2D region) { >>>>>>>> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> { >>>>>>>> Pixels glassPixels = useRobot().getScreenCapture( >>>>>>>> (int) region.getMinX(), (int) region.getMinY(), >>>>>>>> (int) region.getWidth(), (int) region.getHeight() >>>>>>>> ); >>>>>>>> return convertFromGlassPixels(glassPixels); >>>>>>>> }); >>>>>>>> } >>>>>>>> >>>>>>>> private Image convertFromGlassPixels(Pixels glassPixels) { >>>>>>>> int width = glassPixels.getWidth(); >>>>>>>> int height = glassPixels.getHeight(); >>>>>>>> WritableImage image = new WritableImage(width, height); >>>>>>>> >>>>>>>> int bytesPerComponent = glassPixels.getBytesPerComponent(); >>>>>>>> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) { >>>>>>>> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels(); >>>>>>>> writeIntBufferToImage(intBuffer, image); >>>>>>>> } >>>>>>>> >>>>>>>> return image; >>>>>>>> } >>>>>>>> >>>>>>>> private void writeIntBufferToImage(IntBuffer intBuffer, >>>>>>>> WritableImage image) { >>>>>>>> PixelWriter pixelWriter = image.getPixelWriter(); >>>>>>>> double width = image.getWidth(); >>>>>>>> double height = image.getHeight(); >>>>>>>> >>>>>>>> for (int y = 0; y < height; y++) { >>>>>>>> for (int x = 0; x < width; x++) { >>>>>>>> int argb = intBuffer.get(); >>>>>>>> pixelWriter.setArgb(x, y, argb); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> ``` >>>>>>>> >>>>>>>> Pixels is used to create a screen capture. >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> Bypass needing to expose the Pixels class to the public API by >>>>>>>> changing the getScreenCapture method of Robot - that is, changing: >>>>>>>> >>>>>>>> `public Pixels getScreenCapture(int x, int y, int width, int height)` >>>>>>>> >>>>>>>> to: >>>>>>>> >>>>>>>> `public Image getScreenCapture(int x, int y, int width, int height)` >>>>>>>> >>>>>>>> #### com.sun.glass.ui.Robot >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> Essentially every method of Robot is used: >>>>>>>> >>>>>>>> ``` >>>>>>>> public void keyPress(int code) >>>>>>>> public void keyRelease(int code) >>>>>>>> public int getMouseX() >>>>>>>> public int getMouseY() >>>>>>>> public void mouseMove(int x, int y) >>>>>>>> public void mousePress(int buttons) >>>>>>>> public void mouseRelease(int buttons) >>>>>>>> public void mouseWheel(int wheelAmt) >>>>>>>> public int getPixelColor(int x, int y) >>>>>>>> public Pixels getScreenCapture(int x, int y, int width, int height) >>>>>>>> ``` >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Michael Ennen >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Michael Ennen >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>> >>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>> >>> >>> >>> >>> -- >>> Michael Ennen >>> >>> >>> >>> >>> -- >>> Michael Ennen >> >> >> >> >> -- >> Michael Ennen > > > > > -- > Michael Ennen From bourges.laurent at gmail.com Wed Mar 21 16:43:53 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 21 Mar 2018 17:43:53 +0100 Subject: [11] Review request: JDK-8196617: FX print tests fail with NPE in some environments Message-ID: Kevin, Please review this webrev that fixes the NPE in getMediaName(): JBS: https://bugs.openjdk.java.net/browse/JDK-8196617 webrev: http://cr.openjdk.java.net/~lbourges/fx/fx-8196617.0/ It was tested OK on the appveyor CI that failed before the patch. Thanks, Laurent From kevin.rushforth at oracle.com Wed Mar 21 17:21:45 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 21 Mar 2018 10:21:45 -0700 Subject: [11] Review request: JDK-8196617: FX print tests fail with NPE in some environments In-Reply-To: References: Message-ID: <5AB294A9.5060807@oracle.com> I'll defer to Phil on this review. I have no concerns over the fix, and can confirm that the failing tests now pass on my system. -- Kevin Laurent Bourg?s wrote: > Kevin, > > Please review this webrev that fixes the NPE in getMediaName(): > JBS: https://bugs.openjdk.java.net/browse/JDK-8196617 > webrev: http://cr.openjdk.java.net/~lbourges/fx/fx-8196617.0/ > > > It was tested OK on the appveyor CI that failed before the patch. > > Thanks, > Laurent From johan.vos at gluonhq.com Wed Mar 21 17:55:25 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 21 Mar 2018 17:55:25 +0000 Subject: [11] Review request: JDK-8196617: FX print tests fail with NPE in some environments In-Reply-To: <5AB294A9.5060807@oracle.com> References: <5AB294A9.5060807@oracle.com> Message-ID: I checked this as well, and even without checking you can see why this fixes the tests (on Windows, with the PseudoPrinter). This is a very important commit, as it fixes the automated build on Windows, which makes it much easier to make progress without regression. - Johan On Wed, Mar 21, 2018 at 6:32 PM Kevin Rushforth wrote: > I'll defer to Phil on this review. > > I have no concerns over the fix, and can confirm that the failing tests > now pass on my system. > > -- Kevin > > > Laurent Bourg?s wrote: > > Kevin, > > > > Please review this webrev that fixes the NPE in getMediaName(): > > JBS: https://bugs.openjdk.java.net/browse/JDK-8196617 > > webrev: http://cr.openjdk.java.net/~lbourges/fx/fx-8196617.0/ > > > > > > It was tested OK on the appveyor CI that failed before the patch. > > > > Thanks, > > Laurent > From tom.schindl at bestsolution.at Wed Mar 21 22:23:57 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 21 Mar 2018 23:23:57 +0100 Subject: Dependencies on java.desktop Message-ID: <2fa51511-c20d-cc9c-10f7-5e1de2b2a48d@bestsolution.at> Hi, I always thought the JavaFX-Codebase should be able to run with just the java.base module but I was browsing the codebase a bit and was suprised (or rather shocked) that even the base-module requires java.desktop. If I get it correct this because of the java.beans (provided by the adapters) stuff is found in there. Why hasn't the requires there not defined as: requires static java.desktop; Tom From mike.ennen at gmail.com Thu Mar 22 05:20:52 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 21 Mar 2018 22:20:52 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <5AB19921.3000906@oracle.com> References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> <5AB19921.3000906@oracle.com> Message-ID: Okay, thanks for that review, Kevin. I will take into account all of the your suggestions (and if any others come in as well) and report back soon. Thanks, Michael On Tue, Mar 20, 2018 at 4:28 PM, Kevin Rushforth wrote: > Hi Michael, > > Here is some quick feedback. > > I think what you have is heading in the right direction as far as the > public API goes. I'd like to get some feedback from other developers as > well. I would want to make sure that the API meets the needs of multiple > developers. > > I took a look at the public class and as I may have mentioned earlier, it > will help to split the API and the implementation even further, by creating > a peer object as we do for Scene, Stage, etc., rather than having the glass > platform implementation directly subclass the public Robot class. > > Then you can easily delegate to the Glass Robot peer without having any > implementation leak into the public API (e.g., the overridden create and > dispose methods). > > So what you would have in that case is something more like this: > > public final class Robot { > > private final GlassRobot peer; > > public Robot() { > // Ensure we have proper permission for creating a robot. > final SecurityManager sm = System.getSecurityManager(); > if (sm != null) { > sm.checkPermission(CREATE_ROBOT_PERMISSION); > } > > Application.checkEventThread(); > > peer = Toolkit.createRobot(); > } > > // NOTE: for the rest, the peer can do the thread check > > public void keyPress(KeyCode keyCode) { > peer.keyPress(keyCode); > } > > public void keyRelease(KeyCode keyCode) { > peer.keyRelease(keyCode); > } > > public final void keyType(KeyCode keyCode) { > keyPress(keyCode); > keyRelease(keyCode); > } > > ... > > > And so on. The Toolkit class can return a glass robot "peer" which should > then only need minor changes (e.g., to the signatures of methods that have > slightly different types) from the current one. The QuantumToolkit > implementation of createPeer can construct, initialize, and return the > GlassRobot instance. The StubToolkit and DummyToolkit implementations can > throw an UnsuppportedOperationException. > > As for the public API, the set of methods you have seem mostly what we > would want. Here are a few quick thoughts: > > void keyPress(KeyCode keyCode); > void keyRelease(KeyCode keyCode); > void keyType(KeyCode keyCode); > > int getMouseX(); // maybe should return double? > int getMouseY(); > > Point2D getMousePosition(); > > void mouseMove(int x, int y); // maybe params should be double? > > void mouseMove(Point2D location); > > void mousePress(MouseButton button); // This one seems > redundant...covered by the next method > void mousePress(MouseButton... buttons); > > void mouseRelease(MouseButton button); // This one seems > redundant...covered by the next method > void mouseRelease(MouseButton... buttons); > > // I don't see the need for this method > void mouseWheel(int wheelAmt, VerticalDirection direction); > > void mouseWheel(int wheelAmt); > > Color getPixelColor(int x, int y); // maybe params should be double? > > Color getPixelColor(Point2D location); > > // Probably the following should return WritableImage to match Snapshot. > maybe also have a variable that takes a WritableImage to allow caller to > allocate and reuse (that might overkill in this case)? > > Image getScreenCapture(int x, int y, int width, int height); // maybe > params should be double? > Image getScreenCapture(int x, int y, int width, int height, boolean > scaleToFit); // maybe params should be double? > Image getScreenCapture(Rectangle2D region); > Image getScreenCapture(Rectangle2D region, boolean scaleToFit); > > void getScreenCapture(int x, int y, int width, int height, int[] data); // > Not sure we need / want this one > > The biggest question I have is whether we should follow the pattern of the > other related public APIs in Screen and Stage and use doubles everywhere > rather than ints. Also, we will need to see whether there are any > implications for multiple screens (probably not, but the docs will need to > specify what coordinates the x, and y values are in). > > Hopefully this will spark a discussion. > > > -- Kevin > > > Michael Ennen wrote: > > Ping :) > > On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I'll take a look some time after RDP2 of JDK 10. >> >> >> -- Kevin >> >> >> Michael Ennen wrote: >> >> Hey Kevin, >> >> Hope you had a good holiday. Hopefully you will get some time in the >> coming weeks >> to review my work. >> >> Thanks! >> >> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> Sure, no problem. One quick comment is that a common way to solve this >>> is by delegating to an implementation class, which would then be >>> sub-classes. >>> >>> >>> -- Kevin >>> >>> >>> Michael Ennen wrote: >>> >>> I am not trying to be a burden here. I understand that you may not have >>> time to hand-hold >>> to this degree. I will try and make progress, sorry for the follow up >>> question. >>> >>> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen >>> wrote: >>> >>>> How can Robot call into the implementation when it is a super class of >>>> the implementations? >>>> >>>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> >>>>> >>>>> Michael Ennen wrote: >>>>> >>>>> I have a question about how to proceed with the Robot code. >>>>> >>>>> The base abstract Robot class is: https://github.com/brcolow >>>>> /openjfx/blob/master/modules/javafx.graphics/src/main/java/j >>>>> avafx/scene/robot/Robot.java >>>>> >>>>> As you can see for each method, such as "getMouseX()" there is a "_" >>>>> prefixed method >>>>> which is abstract and a non-prefixed method: >>>>> >>>>> protected abstract int _getMouseX(); >>>>> >>>>> public int getMouseX() { >>>>> Application.checkEventThread(); >>>>> return _getMouseX(); >>>>> } >>>>> >>>>> I have copied this from the private Robot API. >>>>> >>>>> Is there a better way to do this? Would this pass review? >>>>> >>>>> >>>>> Yes there are better ways to do this. No it would not pass review, >>>>> since this would be leaking implementation into the public API. >>>>> >>>>> Rather than copying the public / protected methods from the internal >>>>> package, it probably makes more sense to start with what a Robot API should >>>>> look like and then have that call into the implementation (suitably >>>>> modified so it better matches the public API). For one thing you will then >>>>> leave the implementation, including the per-platform code, where it belongs >>>>> -- in glass. The Robot API can be informed by the current implementation, >>>>> but should not be defined by it. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Thanks very much. >>>>> >>>>> >>>>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> Glad you got the build working. You can post back on this thread when >>>>>> you are ready. >>>>>> >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Michael Ennen wrote: >>>>>> >>>>>> Correction: >>>>>> >>>>>> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>>> to buildSrc/addExports. >>>>>> >>>>>> For posterity :) >>>>>> >>>>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen >>>>>> wrote: >>>>>> >>>>>>> Ah, indeed, missed adding "--add-opens javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>>>> to buildSrc/addExports. >>>>>>> Thanks for the guidance on that. >>>>>>> >>>>>>> I will continue to work on this in the GitHub repo and polish it up >>>>>>> (add javadocs, better method signatures, etc.) and >>>>>>> even plan on maybe improving the underlying native Robot >>>>>>> implementations (for example fixing/improving the >>>>>>> way color profiles are handled for MacRobot). >>>>>>> >>>>>>> I will also take a look at "fixing" JemmyFX to use the new public >>>>>>> API (as well as any other place in the JavaFX code >>>>>>> base that does). >>>>>>> >>>>>>> I was expecting that JDK 11 would be the appropriate time frame, >>>>>>> especially because it will be the release where >>>>>>> private APIs will be totally inaccessible, correct? >>>>>>> >>>>>>> After I get it in a reasonable state should I post back on this >>>>>>> mailing list thread or what would be the appropriate >>>>>>> way? >>>>>>> >>>>>>> Thanks Kevin. >>>>>>> >>>>>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth < >>>>>>> kevin.rushforth at oracle.com> wrote: >>>>>>> >>>>>>>> This is a limitation of the the way --patch-modules works. You will >>>>>>>> need to add an entry in: >>>>>>>> >>>>>>>> buildSrc/addExports >>>>>>>> >>>>>>>> Btw, as for the proposal itself, this might need to be a JEP >>>>>>>> depending on the scope. In any case, it could be considered in the JDK 11 >>>>>>>> time frame, but there are several things that need to be worked out before >>>>>>>> making Robot a public API, including the fact that the JemmyFX framework in >>>>>>>> the openjfx/jfx/tests directory uses Robot. Once you get a working >>>>>>>> prototype, it would be interesting to discuss it in more detail. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Michael Ennen wrote: >>>>>>>> >>>>>>>> Currently I am stuck with tests not being able to see the new >>>>>>>> "javafx.scene.robot" module: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Task :systemTests:compileTestJava >>>>>>>> >>>>>>>> >>>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34: >>>>>>>> error: package javafx.scene.robot is not visible >>>>>>>> import javafx.scene.robot.Robot; >>>>>>>> ^ >>>>>>>> (package javafx.scene.robot is declared in module javafx.graphics, which >>>>>>>> does not export it) >>>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33: >>>>>>>> error: package javafx.scene.robot is not visible >>>>>>>> import javafx.scene.robot.Robot; >>>>>>>> >>>>>>>> I have added: >>>>>>>> >>>>>>>> exports javafx.scene.robot; >>>>>>>> >>>>>>>> to: modules/javafx.graphics/src/main/java/module-info.java >>>>>>>> >>>>>>>> But this does not seem to be enough. >>>>>>>> >>>>>>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I am still working on all the necessary changes to actually allow openjfx >>>>>>>> to compile. >>>>>>>> Tons to learn in that arena and I know the code as it is written won't >>>>>>>> totally work. >>>>>>>> For example one can no longer: >>>>>>>> >>>>>>>> #include "com_sun_glass_ui_Robot.h" >>>>>>>> >>>>>>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp >>>>>>>> >>>>>>>> But I am not sure how those headers are generated and if I can just simply >>>>>>>> change >>>>>>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt). >>>>>>>> >>>>>>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I have created a (small) proposal (building on the work of Benjamin >>>>>>>> Gudehaus) about moving some classes in to the public API so that TestFX (a >>>>>>>> JavaFX UI testing framework) can continue to work with future JDK releases. >>>>>>>> The somewhat nicely formatted proposal can be found as a Github gist: >>>>>>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >>>>>>>> >>>>>>>> All suggested changes can be found by using Github Compare View: >>>>>>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 >>>>>>>> e1f4f1cb8f20430feaa53b6...master >>>>>>>> >>>>>>>> But I have copied it to this email for convenience: >>>>>>>> >>>>>>>> ----------------------- PROPOSAL ----------------------- >>>>>>>> >>>>>>>> TestFX, the JavaFX GUI testing framework currently requires 4 (four) >>>>>>>> classes that are part of the JDK's private API. They are: >>>>>>>> >>>>>>>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op >>>>>>>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/ >>>>>>>> java/com/sun/glass/ui/Application.java) >>>>>>>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx >>>>>>>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/ >>>>>>>> com/sun/glass/ui/Pixels.java) >>>>>>>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/ >>>>>>>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com >>>>>>>> /sun/glass/ui/Robot.java) >>>>>>>> [com.sun.javafx.application.ParametersImpl](http://hg.openjdk.java.net/openjfx/10-dev/rt/file/tip/modules/javafx. >>>>>>>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java ) >>>>>>>> >>>>>>>> In order to compile the project with Java 9, we use the following flags: >>>>>>>> >>>>>>>> ```sh >>>>>>>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx >>>>>>>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx >>>>>>>> ``` >>>>>>>> >>>>>>>> If the --add-exports flags are disabled in a future Java release TestFX >>>>>>>> will require these four classes to be moved into the public API to >>>>>>>> continue working. >>>>>>>> >>>>>>>> While these classes are probably not very useful for applications to use >>>>>>>> directly, any JavaFX application wanting to write UI tests will most >>>>>>>> likely >>>>>>>> use TestFX and thus they will indirectly be using these classes. >>>>>>>> >>>>>>>> JavaFX internal tests also use these classes for essentially the same >>>>>>>> purpose (UI tests). >>>>>>>> >>>>>>>> ### Details of Usage For Each Private API Class >>>>>>>> >>>>>>>> #### com.sun.javafx.application.ParametersImpl >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> ```java >>>>>>>> ParametersImpl parameters = new ParametersImpl(applicationArgs); >>>>>>>> ParametersImpl.registerParameters(application, parameters); >>>>>>>> ``` >>>>>>>> >>>>>>>> The parameters are set on a constructed Application. >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> `javafx.application.Application`: >>>>>>>> >>>>>>>> ```java >>>>>>>> /** >>>>>>>> * Sets the parameters for this Application. >>>>>>>> * >>>>>>>> *

>>>>>>>> * NOTE: this method should not be called from the Application >>>>>>>> constructor, >>>>>>>> * as it will return null. It may be called in the init() method or any >>>>>>>> * time after that. >>>>>>>> *

>>>>>>>> * >>>>>>>> * @param parameters the parameters to set for this Application >>>>>>>> */ >>>>>>>> public final Parameters setParameters(String... parameters) { >>>>>>>> ParametersImpl parameters = new ParametersImpl(parameters); >>>>>>>> ParametersImpl.registerParameters(this, parameters); >>>>>>>> } >>>>>>>> ``` >>>>>>>> >>>>>>>> #### com.sun.glass.ui.Application >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> ```java >>>>>>>> return Application.GetApplication().createRobot(); >>>>>>>> ``` >>>>>>>> >>>>>>>> The Application class is used to instantiate a Robot. >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> `javafx.application.Application`: >>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>> x.graphics/src/main/java/javafx/application/Application.java#L527 >>>>>>>> >>>>>>>> #### com.sun.glass.ui.Pixels >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> ```java >>>>>>>> @Override >>>>>>>> public Image getCaptureRegion(Rectangle2D region) { >>>>>>>> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> { >>>>>>>> Pixels glassPixels = useRobot().getScreenCapture( >>>>>>>> (int) region.getMinX(), (int) region.getMinY(), >>>>>>>> (int) region.getWidth(), (int) region.getHeight() >>>>>>>> ); >>>>>>>> return convertFromGlassPixels(glassPixels); >>>>>>>> }); >>>>>>>> } >>>>>>>> >>>>>>>> private Image convertFromGlassPixels(Pixels glassPixels) { >>>>>>>> int width = glassPixels.getWidth(); >>>>>>>> int height = glassPixels.getHeight(); >>>>>>>> WritableImage image = new WritableImage(width, height); >>>>>>>> >>>>>>>> int bytesPerComponent = glassPixels.getBytesPerComponent(); >>>>>>>> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) { >>>>>>>> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels(); >>>>>>>> writeIntBufferToImage(intBuffer, image); >>>>>>>> } >>>>>>>> >>>>>>>> return image; >>>>>>>> } >>>>>>>> >>>>>>>> private void writeIntBufferToImage(IntBuffer intBuffer, >>>>>>>> WritableImage image) { >>>>>>>> PixelWriter pixelWriter = image.getPixelWriter(); >>>>>>>> double width = image.getWidth(); >>>>>>>> double height = image.getHeight(); >>>>>>>> >>>>>>>> for (int y = 0; y < height; y++) { >>>>>>>> for (int x = 0; x < width; x++) { >>>>>>>> int argb = intBuffer.get(); >>>>>>>> pixelWriter.setArgb(x, y, argb); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> ``` >>>>>>>> >>>>>>>> Pixels is used to create a screen capture. >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> Bypass needing to expose the Pixels class to the public API by >>>>>>>> changing the getScreenCapture method of Robot - that is, changing: >>>>>>>> >>>>>>>> `public Pixels getScreenCapture(int x, int y, int width, int height)` >>>>>>>> >>>>>>>> to: >>>>>>>> >>>>>>>> `public Image getScreenCapture(int x, int y, int width, int height)` >>>>>>>> >>>>>>>> #### com.sun.glass.ui.Robot >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> Essentially every method of Robot is used: >>>>>>>> >>>>>>>> ``` >>>>>>>> public void keyPress(int code) >>>>>>>> public void keyRelease(int code) >>>>>>>> public int getMouseX() >>>>>>>> public int getMouseY() >>>>>>>> public void mouseMove(int x, int y) >>>>>>>> public void mousePress(int buttons) >>>>>>>> public void mouseRelease(int buttons) >>>>>>>> public void mouseWheel(int wheelAmt) >>>>>>>> public int getPixelColor(int x, int y) >>>>>>>> public Pixels getScreenCapture(int x, int y, int width, int height) >>>>>>>> ``` >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Michael Ennen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Michael Ennen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Michael Ennen >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>>> >>>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>>> >>> >>> >>> >>> -- >>> Michael Ennen >>> >>> >> >> >> -- >> Michael Ennen >> >> > > > -- > Michael Ennen > > From mike.ennen at gmail.com Thu Mar 22 06:58:12 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 21 Mar 2018 23:58:12 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <5AB19921.3000906@oracle.com> References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> <5AB19921.3000906@oracle.com> Message-ID: Quick question: Currently a Robot is created by calling `Application.createRobot` which delegates to the underlying platform-specific application class (GtkApplication, WinApplication, etc.) via `com.sun.glass.ui.Application.GetApplication().createRobot();` You suggest moving this to the Toolkit class? If GtkRobot, WinRobot, etc. all extend the abstract base class GlassRobot (the peer), how will Toolkit be able to instantiate the correct, platform-specific class? Sorry, I got stuck trying to implement this part of your review. The rest is easy for me to follow and will be no problem. On Tue, Mar 20, 2018 at 4:28 PM, Kevin Rushforth wrote: > Hi Michael, > > Here is some quick feedback. > > I think what you have is heading in the right direction as far as the > public API goes. I'd like to get some feedback from other developers as > well. I would want to make sure that the API meets the needs of multiple > developers. > > I took a look at the public class and as I may have mentioned earlier, it > will help to split the API and the implementation even further, by creating > a peer object as we do for Scene, Stage, etc., rather than having the glass > platform implementation directly subclass the public Robot class. > > Then you can easily delegate to the Glass Robot peer without having any > implementation leak into the public API (e.g., the overridden create and > dispose methods). > > So what you would have in that case is something more like this: > > public final class Robot { > > private final GlassRobot peer; > > public Robot() { > // Ensure we have proper permission for creating a robot. > final SecurityManager sm = System.getSecurityManager(); > if (sm != null) { > sm.checkPermission(CREATE_ROBOT_PERMISSION); > } > > Application.checkEventThread(); > > peer = Toolkit.createRobot(); > } > > // NOTE: for the rest, the peer can do the thread check > > public void keyPress(KeyCode keyCode) { > peer.keyPress(keyCode); > } > > public void keyRelease(KeyCode keyCode) { > peer.keyRelease(keyCode); > } > > public final void keyType(KeyCode keyCode) { > keyPress(keyCode); > keyRelease(keyCode); > } > > ... > > > And so on. The Toolkit class can return a glass robot "peer" which should > then only need minor changes (e.g., to the signatures of methods that have > slightly different types) from the current one. The QuantumToolkit > implementation of createPeer can construct, initialize, and return the > GlassRobot instance. The StubToolkit and DummyToolkit implementations can > throw an UnsuppportedOperationException. > > As for the public API, the set of methods you have seem mostly what we > would want. Here are a few quick thoughts: > > void keyPress(KeyCode keyCode); > void keyRelease(KeyCode keyCode); > void keyType(KeyCode keyCode); > > int getMouseX(); // maybe should return double? > int getMouseY(); > > Point2D getMousePosition(); > > void mouseMove(int x, int y); // maybe params should be double? > > void mouseMove(Point2D location); > > void mousePress(MouseButton button); // This one seems > redundant...covered by the next method > void mousePress(MouseButton... buttons); > > void mouseRelease(MouseButton button); // This one seems > redundant...covered by the next method > void mouseRelease(MouseButton... buttons); > > // I don't see the need for this method > void mouseWheel(int wheelAmt, VerticalDirection direction); > > void mouseWheel(int wheelAmt); > > Color getPixelColor(int x, int y); // maybe params should be double? > > Color getPixelColor(Point2D location); > > // Probably the following should return WritableImage to match Snapshot. > maybe also have a variable that takes a WritableImage to allow caller to > allocate and reuse (that might overkill in this case)? > > Image getScreenCapture(int x, int y, int width, int height); // maybe > params should be double? > Image getScreenCapture(int x, int y, int width, int height, boolean > scaleToFit); // maybe params should be double? > Image getScreenCapture(Rectangle2D region); > Image getScreenCapture(Rectangle2D region, boolean scaleToFit); > > void getScreenCapture(int x, int y, int width, int height, int[] data); // > Not sure we need / want this one > > The biggest question I have is whether we should follow the pattern of the > other related public APIs in Screen and Stage and use doubles everywhere > rather than ints. Also, we will need to see whether there are any > implications for multiple screens (probably not, but the docs will need to > specify what coordinates the x, and y values are in). > > Hopefully this will spark a discussion. > > > -- Kevin > > > Michael Ennen wrote: > > Ping :) > > On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I'll take a look some time after RDP2 of JDK 10. >> >> >> -- Kevin >> >> >> Michael Ennen wrote: >> >> Hey Kevin, >> >> Hope you had a good holiday. Hopefully you will get some time in the >> coming weeks >> to review my work. >> >> Thanks! >> >> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> Sure, no problem. One quick comment is that a common way to solve this >>> is by delegating to an implementation class, which would then be >>> sub-classes. >>> >>> >>> -- Kevin >>> >>> >>> Michael Ennen wrote: >>> >>> I am not trying to be a burden here. I understand that you may not have >>> time to hand-hold >>> to this degree. I will try and make progress, sorry for the follow up >>> question. >>> >>> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen >>> wrote: >>> >>>> How can Robot call into the implementation when it is a super class of >>>> the implementations? >>>> >>>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> >>>>> >>>>> Michael Ennen wrote: >>>>> >>>>> I have a question about how to proceed with the Robot code. >>>>> >>>>> The base abstract Robot class is: https://github.com/brcolow >>>>> /openjfx/blob/master/modules/javafx.graphics/src/main/java/j >>>>> avafx/scene/robot/Robot.java >>>>> >>>>> As you can see for each method, such as "getMouseX()" there is a "_" >>>>> prefixed method >>>>> which is abstract and a non-prefixed method: >>>>> >>>>> protected abstract int _getMouseX(); >>>>> >>>>> public int getMouseX() { >>>>> Application.checkEventThread(); >>>>> return _getMouseX(); >>>>> } >>>>> >>>>> I have copied this from the private Robot API. >>>>> >>>>> Is there a better way to do this? Would this pass review? >>>>> >>>>> >>>>> Yes there are better ways to do this. No it would not pass review, >>>>> since this would be leaking implementation into the public API. >>>>> >>>>> Rather than copying the public / protected methods from the internal >>>>> package, it probably makes more sense to start with what a Robot API should >>>>> look like and then have that call into the implementation (suitably >>>>> modified so it better matches the public API). For one thing you will then >>>>> leave the implementation, including the per-platform code, where it belongs >>>>> -- in glass. The Robot API can be informed by the current implementation, >>>>> but should not be defined by it. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Thanks very much. >>>>> >>>>> >>>>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> Glad you got the build working. You can post back on this thread when >>>>>> you are ready. >>>>>> >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Michael Ennen wrote: >>>>>> >>>>>> Correction: >>>>>> >>>>>> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>>> to buildSrc/addExports. >>>>>> >>>>>> For posterity :) >>>>>> >>>>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen >>>>>> wrote: >>>>>> >>>>>>> Ah, indeed, missed adding "--add-opens javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>>>> to buildSrc/addExports. >>>>>>> Thanks for the guidance on that. >>>>>>> >>>>>>> I will continue to work on this in the GitHub repo and polish it up >>>>>>> (add javadocs, better method signatures, etc.) and >>>>>>> even plan on maybe improving the underlying native Robot >>>>>>> implementations (for example fixing/improving the >>>>>>> way color profiles are handled for MacRobot). >>>>>>> >>>>>>> I will also take a look at "fixing" JemmyFX to use the new public >>>>>>> API (as well as any other place in the JavaFX code >>>>>>> base that does). >>>>>>> >>>>>>> I was expecting that JDK 11 would be the appropriate time frame, >>>>>>> especially because it will be the release where >>>>>>> private APIs will be totally inaccessible, correct? >>>>>>> >>>>>>> After I get it in a reasonable state should I post back on this >>>>>>> mailing list thread or what would be the appropriate >>>>>>> way? >>>>>>> >>>>>>> Thanks Kevin. >>>>>>> >>>>>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth < >>>>>>> kevin.rushforth at oracle.com> wrote: >>>>>>> >>>>>>>> This is a limitation of the the way --patch-modules works. You will >>>>>>>> need to add an entry in: >>>>>>>> >>>>>>>> buildSrc/addExports >>>>>>>> >>>>>>>> Btw, as for the proposal itself, this might need to be a JEP >>>>>>>> depending on the scope. In any case, it could be considered in the JDK 11 >>>>>>>> time frame, but there are several things that need to be worked out before >>>>>>>> making Robot a public API, including the fact that the JemmyFX framework in >>>>>>>> the openjfx/jfx/tests directory uses Robot. Once you get a working >>>>>>>> prototype, it would be interesting to discuss it in more detail. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Michael Ennen wrote: >>>>>>>> >>>>>>>> Currently I am stuck with tests not being able to see the new >>>>>>>> "javafx.scene.robot" module: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Task :systemTests:compileTestJava >>>>>>>> >>>>>>>> >>>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34: >>>>>>>> error: package javafx.scene.robot is not visible >>>>>>>> import javafx.scene.robot.Robot; >>>>>>>> ^ >>>>>>>> (package javafx.scene.robot is declared in module javafx.graphics, which >>>>>>>> does not export it) >>>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33: >>>>>>>> error: package javafx.scene.robot is not visible >>>>>>>> import javafx.scene.robot.Robot; >>>>>>>> >>>>>>>> I have added: >>>>>>>> >>>>>>>> exports javafx.scene.robot; >>>>>>>> >>>>>>>> to: modules/javafx.graphics/src/main/java/module-info.java >>>>>>>> >>>>>>>> But this does not seem to be enough. >>>>>>>> >>>>>>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I am still working on all the necessary changes to actually allow openjfx >>>>>>>> to compile. >>>>>>>> Tons to learn in that arena and I know the code as it is written won't >>>>>>>> totally work. >>>>>>>> For example one can no longer: >>>>>>>> >>>>>>>> #include "com_sun_glass_ui_Robot.h" >>>>>>>> >>>>>>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp >>>>>>>> >>>>>>>> But I am not sure how those headers are generated and if I can just simply >>>>>>>> change >>>>>>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt). >>>>>>>> >>>>>>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I have created a (small) proposal (building on the work of Benjamin >>>>>>>> Gudehaus) about moving some classes in to the public API so that TestFX (a >>>>>>>> JavaFX UI testing framework) can continue to work with future JDK releases. >>>>>>>> The somewhat nicely formatted proposal can be found as a Github gist: >>>>>>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >>>>>>>> >>>>>>>> All suggested changes can be found by using Github Compare View: >>>>>>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 >>>>>>>> e1f4f1cb8f20430feaa53b6...master >>>>>>>> >>>>>>>> But I have copied it to this email for convenience: >>>>>>>> >>>>>>>> ----------------------- PROPOSAL ----------------------- >>>>>>>> >>>>>>>> TestFX, the JavaFX GUI testing framework currently requires 4 (four) >>>>>>>> classes that are part of the JDK's private API. They are: >>>>>>>> >>>>>>>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op >>>>>>>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/ >>>>>>>> java/com/sun/glass/ui/Application.java) >>>>>>>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx >>>>>>>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/ >>>>>>>> com/sun/glass/ui/Pixels.java) >>>>>>>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/ >>>>>>>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com >>>>>>>> /sun/glass/ui/Robot.java) >>>>>>>> [com.sun.javafx.application.ParametersImpl](http://hg.openjdk.java.net/openjfx/10-dev/rt/file/tip/modules/javafx. >>>>>>>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java ) >>>>>>>> >>>>>>>> In order to compile the project with Java 9, we use the following flags: >>>>>>>> >>>>>>>> ```sh >>>>>>>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx >>>>>>>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx >>>>>>>> ``` >>>>>>>> >>>>>>>> If the --add-exports flags are disabled in a future Java release TestFX >>>>>>>> will require these four classes to be moved into the public API to >>>>>>>> continue working. >>>>>>>> >>>>>>>> While these classes are probably not very useful for applications to use >>>>>>>> directly, any JavaFX application wanting to write UI tests will most >>>>>>>> likely >>>>>>>> use TestFX and thus they will indirectly be using these classes. >>>>>>>> >>>>>>>> JavaFX internal tests also use these classes for essentially the same >>>>>>>> purpose (UI tests). >>>>>>>> >>>>>>>> ### Details of Usage For Each Private API Class >>>>>>>> >>>>>>>> #### com.sun.javafx.application.ParametersImpl >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> ```java >>>>>>>> ParametersImpl parameters = new ParametersImpl(applicationArgs); >>>>>>>> ParametersImpl.registerParameters(application, parameters); >>>>>>>> ``` >>>>>>>> >>>>>>>> The parameters are set on a constructed Application. >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> `javafx.application.Application`: >>>>>>>> >>>>>>>> ```java >>>>>>>> /** >>>>>>>> * Sets the parameters for this Application. >>>>>>>> * >>>>>>>> *

>>>>>>>> * NOTE: this method should not be called from the Application >>>>>>>> constructor, >>>>>>>> * as it will return null. It may be called in the init() method or any >>>>>>>> * time after that. >>>>>>>> *

>>>>>>>> * >>>>>>>> * @param parameters the parameters to set for this Application >>>>>>>> */ >>>>>>>> public final Parameters setParameters(String... parameters) { >>>>>>>> ParametersImpl parameters = new ParametersImpl(parameters); >>>>>>>> ParametersImpl.registerParameters(this, parameters); >>>>>>>> } >>>>>>>> ``` >>>>>>>> >>>>>>>> #### com.sun.glass.ui.Application >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> ```java >>>>>>>> return Application.GetApplication().createRobot(); >>>>>>>> ``` >>>>>>>> >>>>>>>> The Application class is used to instantiate a Robot. >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> `javafx.application.Application`: >>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>> x.graphics/src/main/java/javafx/application/Application.java#L527 >>>>>>>> >>>>>>>> #### com.sun.glass.ui.Pixels >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> ```java >>>>>>>> @Override >>>>>>>> public Image getCaptureRegion(Rectangle2D region) { >>>>>>>> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> { >>>>>>>> Pixels glassPixels = useRobot().getScreenCapture( >>>>>>>> (int) region.getMinX(), (int) region.getMinY(), >>>>>>>> (int) region.getWidth(), (int) region.getHeight() >>>>>>>> ); >>>>>>>> return convertFromGlassPixels(glassPixels); >>>>>>>> }); >>>>>>>> } >>>>>>>> >>>>>>>> private Image convertFromGlassPixels(Pixels glassPixels) { >>>>>>>> int width = glassPixels.getWidth(); >>>>>>>> int height = glassPixels.getHeight(); >>>>>>>> WritableImage image = new WritableImage(width, height); >>>>>>>> >>>>>>>> int bytesPerComponent = glassPixels.getBytesPerComponent(); >>>>>>>> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) { >>>>>>>> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels(); >>>>>>>> writeIntBufferToImage(intBuffer, image); >>>>>>>> } >>>>>>>> >>>>>>>> return image; >>>>>>>> } >>>>>>>> >>>>>>>> private void writeIntBufferToImage(IntBuffer intBuffer, >>>>>>>> WritableImage image) { >>>>>>>> PixelWriter pixelWriter = image.getPixelWriter(); >>>>>>>> double width = image.getWidth(); >>>>>>>> double height = image.getHeight(); >>>>>>>> >>>>>>>> for (int y = 0; y < height; y++) { >>>>>>>> for (int x = 0; x < width; x++) { >>>>>>>> int argb = intBuffer.get(); >>>>>>>> pixelWriter.setArgb(x, y, argb); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> ``` >>>>>>>> >>>>>>>> Pixels is used to create a screen capture. >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> >>>>>>>> Bypass needing to expose the Pixels class to the public API by >>>>>>>> changing the getScreenCapture method of Robot - that is, changing: >>>>>>>> >>>>>>>> `public Pixels getScreenCapture(int x, int y, int width, int height)` >>>>>>>> >>>>>>>> to: >>>>>>>> >>>>>>>> `public Image getScreenCapture(int x, int y, int width, int height)` >>>>>>>> >>>>>>>> #### com.sun.glass.ui.Robot >>>>>>>> >>>>>>>> ##### TestFX Usage >>>>>>>> >>>>>>>> Essentially every method of Robot is used: >>>>>>>> >>>>>>>> ``` >>>>>>>> public void keyPress(int code) >>>>>>>> public void keyRelease(int code) >>>>>>>> public int getMouseX() >>>>>>>> public int getMouseY() >>>>>>>> public void mouseMove(int x, int y) >>>>>>>> public void mousePress(int buttons) >>>>>>>> public void mouseRelease(int buttons) >>>>>>>> public void mouseWheel(int wheelAmt) >>>>>>>> public int getPixelColor(int x, int y) >>>>>>>> public Pixels getScreenCapture(int x, int y, int width, int height) >>>>>>>> ``` >>>>>>>> >>>>>>>> ##### Suggested Public API Replacement >>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Michael Ennen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Michael Ennen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Michael Ennen >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>>> >>>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>>> >>> >>> >>> >>> -- >>> Michael Ennen >>> >>> >> >> >> -- >> Michael Ennen >> >> > > > -- > Michael Ennen > > -- Michael Ennen From nlisker at gmail.com Thu Mar 22 07:35:13 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 22 Mar 2018 09:35:13 +0200 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API Message-ID: Hi Michael, About the public API, I agree with Kevin that the following methods are redundant: - mousePress(MouseButton button) - mouseRelease(MouseButton button); - mouseWheel(int wheelAmt, VerticalDirection direction) About the implementation of getScreenCapture, isn't that conflicting with the glass.ui.Robot implementation? Do you intend to change that implementation? What's the link to the current changeset/webrev? - Nir From mike.ennen at gmail.com Thu Mar 22 09:19:40 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Thu, 22 Mar 2018 02:19:40 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> <5AB19921.3000906@oracle.com> Message-ID: I should have been more clear in my previous message. I am creating the Robot thusly: javafx.scene.robot.Robot constructor (public API so JavaFX users can simply instantiate one): public Robot() { // Ensure we have proper permission for creating a robot. final SecurityManager sm = System.getSecurityManager(); if (sm != null) { sm.checkPermission(CREATE_ROBOT_PERMISSION); } peer = GlassRobot.getRobot(); } static method com.sun.glass.ui.GlassRobot.getRobot(): public static GlassRobot getRobot() { return Application.GetApplication().createRobot(); } This seems straight-forward. I am not sure how to change this to Toolkit, because the individual application implementations (GtkApplication, WinApplication, etc.) all instantiate their correct, platform-specific Robot instance. On Wed, Mar 21, 2018 at 11:58 PM, Michael Ennen wrote: > Quick question: > > Currently a Robot is created by calling `Application.createRobot` which > delegates > to the underlying platform-specific application class (GtkApplication, > WinApplication, etc.) > via `com.sun.glass.ui.Application.GetApplication().createRobot();` > > > You suggest moving this to the Toolkit class? If GtkRobot, WinRobot, etc. > all extend > the abstract base class GlassRobot (the peer), how will Toolkit be able to > instantiate > the correct, platform-specific class? Sorry, I got stuck trying to > implement this part > of your review. The rest is easy for me to follow and will be no problem. > > > On Tue, Mar 20, 2018 at 4:28 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Hi Michael, >> >> Here is some quick feedback. >> >> I think what you have is heading in the right direction as far as the >> public API goes. I'd like to get some feedback from other developers as >> well. I would want to make sure that the API meets the needs of multiple >> developers. >> >> I took a look at the public class and as I may have mentioned earlier, it >> will help to split the API and the implementation even further, by creating >> a peer object as we do for Scene, Stage, etc., rather than having the glass >> platform implementation directly subclass the public Robot class. >> >> Then you can easily delegate to the Glass Robot peer without having any >> implementation leak into the public API (e.g., the overridden create and >> dispose methods). >> >> So what you would have in that case is something more like this: >> >> public final class Robot { >> >> private final GlassRobot peer; >> >> public Robot() { >> // Ensure we have proper permission for creating a robot. >> final SecurityManager sm = System.getSecurityManager(); >> if (sm != null) { >> sm.checkPermission(CREATE_ROBOT_PERMISSION); >> } >> >> Application.checkEventThread(); >> >> peer = Toolkit.createRobot(); >> } >> >> // NOTE: for the rest, the peer can do the thread check >> >> public void keyPress(KeyCode keyCode) { >> peer.keyPress(keyCode); >> } >> >> public void keyRelease(KeyCode keyCode) { >> peer.keyRelease(keyCode); >> } >> >> public final void keyType(KeyCode keyCode) { >> keyPress(keyCode); >> keyRelease(keyCode); >> } >> >> ... >> >> >> And so on. The Toolkit class can return a glass robot "peer" which should >> then only need minor changes (e.g., to the signatures of methods that have >> slightly different types) from the current one. The QuantumToolkit >> implementation of createPeer can construct, initialize, and return the >> GlassRobot instance. The StubToolkit and DummyToolkit implementations can >> throw an UnsuppportedOperationException. >> >> As for the public API, the set of methods you have seem mostly what we >> would want. Here are a few quick thoughts: >> >> void keyPress(KeyCode keyCode); >> void keyRelease(KeyCode keyCode); >> void keyType(KeyCode keyCode); >> >> int getMouseX(); // maybe should return double? >> int getMouseY(); >> >> Point2D getMousePosition(); >> >> void mouseMove(int x, int y); // maybe params should be double? >> >> void mouseMove(Point2D location); >> >> void mousePress(MouseButton button); // This one seems >> redundant...covered by the next method >> void mousePress(MouseButton... buttons); >> >> void mouseRelease(MouseButton button); // This one seems >> redundant...covered by the next method >> void mouseRelease(MouseButton... buttons); >> >> // I don't see the need for this method >> void mouseWheel(int wheelAmt, VerticalDirection direction); >> >> void mouseWheel(int wheelAmt); >> >> Color getPixelColor(int x, int y); // maybe params should be double? >> >> Color getPixelColor(Point2D location); >> >> // Probably the following should return WritableImage to match Snapshot. >> maybe also have a variable that takes a WritableImage to allow caller to >> allocate and reuse (that might overkill in this case)? >> >> Image getScreenCapture(int x, int y, int width, int height); // maybe >> params should be double? >> Image getScreenCapture(int x, int y, int width, int height, boolean >> scaleToFit); // maybe params should be double? >> Image getScreenCapture(Rectangle2D region); >> Image getScreenCapture(Rectangle2D region, boolean scaleToFit); >> >> void getScreenCapture(int x, int y, int width, int height, int[] data); >> // Not sure we need / want this one >> >> The biggest question I have is whether we should follow the pattern of >> the other related public APIs in Screen and Stage and use doubles >> everywhere rather than ints. Also, we will need to see whether there are >> any implications for multiple screens (probably not, but the docs will need >> to specify what coordinates the x, and y values are in). >> >> Hopefully this will spark a discussion. >> >> >> -- Kevin >> >> >> Michael Ennen wrote: >> >> Ping :) >> >> On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> I'll take a look some time after RDP2 of JDK 10. >>> >>> >>> -- Kevin >>> >>> >>> Michael Ennen wrote: >>> >>> Hey Kevin, >>> >>> Hope you had a good holiday. Hopefully you will get some time in the >>> coming weeks >>> to review my work. >>> >>> Thanks! >>> >>> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> Sure, no problem. One quick comment is that a common way to solve this >>>> is by delegating to an implementation class, which would then be >>>> sub-classes. >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> Michael Ennen wrote: >>>> >>>> I am not trying to be a burden here. I understand that you may not have >>>> time to hand-hold >>>> to this degree. I will try and make progress, sorry for the follow up >>>> question. >>>> >>>> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen >>>> wrote: >>>> >>>>> How can Robot call into the implementation when it is a super class of >>>>> the implementations? >>>>> >>>>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> Michael Ennen wrote: >>>>>> >>>>>> I have a question about how to proceed with the Robot code. >>>>>> >>>>>> The base abstract Robot class is: https://github.com/brcolow >>>>>> /openjfx/blob/master/modules/javafx.graphics/src/main/java/j >>>>>> avafx/scene/robot/Robot.java >>>>>> >>>>>> As you can see for each method, such as "getMouseX()" there is a "_" >>>>>> prefixed method >>>>>> which is abstract and a non-prefixed method: >>>>>> >>>>>> protected abstract int _getMouseX(); >>>>>> >>>>>> public int getMouseX() { >>>>>> Application.checkEventThread(); >>>>>> return _getMouseX(); >>>>>> } >>>>>> >>>>>> I have copied this from the private Robot API. >>>>>> >>>>>> Is there a better way to do this? Would this pass review? >>>>>> >>>>>> >>>>>> Yes there are better ways to do this. No it would not pass review, >>>>>> since this would be leaking implementation into the public API. >>>>>> >>>>>> Rather than copying the public / protected methods from the internal >>>>>> package, it probably makes more sense to start with what a Robot API should >>>>>> look like and then have that call into the implementation (suitably >>>>>> modified so it better matches the public API). For one thing you will then >>>>>> leave the implementation, including the per-platform code, where it belongs >>>>>> -- in glass. The Robot API can be informed by the current implementation, >>>>>> but should not be defined by it. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Thanks very much. >>>>>> >>>>>> >>>>>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth < >>>>>> kevin.rushforth at oracle.com> wrote: >>>>>> >>>>>>> Glad you got the build working. You can post back on this thread >>>>>>> when you are ready. >>>>>>> >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Michael Ennen wrote: >>>>>>> >>>>>>> Correction: >>>>>>> >>>>>>> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>>>> to buildSrc/addExports. >>>>>>> >>>>>>> For posterity :) >>>>>>> >>>>>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen >>>>>>> wrote: >>>>>>> >>>>>>>> Ah, indeed, missed adding "--add-opens >>>>>>>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED" to >>>>>>>> buildSrc/addExports. >>>>>>>> Thanks for the guidance on that. >>>>>>>> >>>>>>>> I will continue to work on this in the GitHub repo and polish it up >>>>>>>> (add javadocs, better method signatures, etc.) and >>>>>>>> even plan on maybe improving the underlying native Robot >>>>>>>> implementations (for example fixing/improving the >>>>>>>> way color profiles are handled for MacRobot). >>>>>>>> >>>>>>>> I will also take a look at "fixing" JemmyFX to use the new public >>>>>>>> API (as well as any other place in the JavaFX code >>>>>>>> base that does). >>>>>>>> >>>>>>>> I was expecting that JDK 11 would be the appropriate time frame, >>>>>>>> especially because it will be the release where >>>>>>>> private APIs will be totally inaccessible, correct? >>>>>>>> >>>>>>>> After I get it in a reasonable state should I post back on this >>>>>>>> mailing list thread or what would be the appropriate >>>>>>>> way? >>>>>>>> >>>>>>>> Thanks Kevin. >>>>>>>> >>>>>>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth < >>>>>>>> kevin.rushforth at oracle.com> wrote: >>>>>>>> >>>>>>>>> This is a limitation of the the way --patch-modules works. You >>>>>>>>> will need to add an entry in: >>>>>>>>> >>>>>>>>> buildSrc/addExports >>>>>>>>> >>>>>>>>> Btw, as for the proposal itself, this might need to be a JEP >>>>>>>>> depending on the scope. In any case, it could be considered in the JDK 11 >>>>>>>>> time frame, but there are several things that need to be worked out before >>>>>>>>> making Robot a public API, including the fact that the JemmyFX framework in >>>>>>>>> the openjfx/jfx/tests directory uses Robot. Once you get a working >>>>>>>>> prototype, it would be interesting to discuss it in more detail. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Michael Ennen wrote: >>>>>>>>> >>>>>>>>> Currently I am stuck with tests not being able to see the new >>>>>>>>> "javafx.scene.robot" module: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Task :systemTests:compileTestJava >>>>>>>>> >>>>>>>>> >>>>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34: >>>>>>>>> error: package javafx.scene.robot is not visible >>>>>>>>> import javafx.scene.robot.Robot; >>>>>>>>> ^ >>>>>>>>> (package javafx.scene.robot is declared in module javafx.graphics, which >>>>>>>>> does not export it) >>>>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33: >>>>>>>>> error: package javafx.scene.robot is not visible >>>>>>>>> import javafx.scene.robot.Robot; >>>>>>>>> >>>>>>>>> I have added: >>>>>>>>> >>>>>>>>> exports javafx.scene.robot; >>>>>>>>> >>>>>>>>> to: modules/javafx.graphics/src/main/java/module-info.java >>>>>>>>> >>>>>>>>> But this does not seem to be enough. >>>>>>>>> >>>>>>>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I am still working on all the necessary changes to actually allow openjfx >>>>>>>>> to compile. >>>>>>>>> Tons to learn in that arena and I know the code as it is written won't >>>>>>>>> totally work. >>>>>>>>> For example one can no longer: >>>>>>>>> >>>>>>>>> #include "com_sun_glass_ui_Robot.h" >>>>>>>>> >>>>>>>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp >>>>>>>>> >>>>>>>>> But I am not sure how those headers are generated and if I can just simply >>>>>>>>> change >>>>>>>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt). >>>>>>>>> >>>>>>>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I have created a (small) proposal (building on the work of Benjamin >>>>>>>>> Gudehaus) about moving some classes in to the public API so that TestFX (a >>>>>>>>> JavaFX UI testing framework) can continue to work with future JDK releases. >>>>>>>>> The somewhat nicely formatted proposal can be found as a Github gist: >>>>>>>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >>>>>>>>> >>>>>>>>> All suggested changes can be found by using Github Compare View: >>>>>>>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 >>>>>>>>> e1f4f1cb8f20430feaa53b6...master >>>>>>>>> >>>>>>>>> But I have copied it to this email for convenience: >>>>>>>>> >>>>>>>>> ----------------------- PROPOSAL ----------------------- >>>>>>>>> >>>>>>>>> TestFX, the JavaFX GUI testing framework currently requires 4 (four) >>>>>>>>> classes that are part of the JDK's private API. They are: >>>>>>>>> >>>>>>>>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op >>>>>>>>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/ >>>>>>>>> java/com/sun/glass/ui/Application.java) >>>>>>>>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx >>>>>>>>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/ >>>>>>>>> com/sun/glass/ui/Pixels.java) >>>>>>>>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/ >>>>>>>>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com >>>>>>>>> /sun/glass/ui/Robot.java) >>>>>>>>> [com.sun.javafx.application.ParametersImpl](http://hg.openjdk.java.net/openjfx/10-dev/rt/file/tip/modules/javafx. >>>>>>>>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java ) >>>>>>>>> >>>>>>>>> In order to compile the project with Java 9, we use the following flags: >>>>>>>>> >>>>>>>>> ```sh >>>>>>>>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx >>>>>>>>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> If the --add-exports flags are disabled in a future Java release TestFX >>>>>>>>> will require these four classes to be moved into the public API to >>>>>>>>> continue working. >>>>>>>>> >>>>>>>>> While these classes are probably not very useful for applications to use >>>>>>>>> directly, any JavaFX application wanting to write UI tests will most >>>>>>>>> likely >>>>>>>>> use TestFX and thus they will indirectly be using these classes. >>>>>>>>> >>>>>>>>> JavaFX internal tests also use these classes for essentially the same >>>>>>>>> purpose (UI tests). >>>>>>>>> >>>>>>>>> ### Details of Usage For Each Private API Class >>>>>>>>> >>>>>>>>> #### com.sun.javafx.application.ParametersImpl >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> ParametersImpl parameters = new ParametersImpl(applicationArgs); >>>>>>>>> ParametersImpl.registerParameters(application, parameters); >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> The parameters are set on a constructed Application. >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> >>>>>>>>> `javafx.application.Application`: >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> /** >>>>>>>>> * Sets the parameters for this Application. >>>>>>>>> * >>>>>>>>> *

>>>>>>>>> * NOTE: this method should not be called from the Application >>>>>>>>> constructor, >>>>>>>>> * as it will return null. It may be called in the init() method or any >>>>>>>>> * time after that. >>>>>>>>> *

>>>>>>>>> * >>>>>>>>> * @param parameters the parameters to set for this Application >>>>>>>>> */ >>>>>>>>> public final Parameters setParameters(String... parameters) { >>>>>>>>> ParametersImpl parameters = new ParametersImpl(parameters); >>>>>>>>> ParametersImpl.registerParameters(this, parameters); >>>>>>>>> } >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> #### com.sun.glass.ui.Application >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> return Application.GetApplication().createRobot(); >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> The Application class is used to instantiate a Robot. >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> >>>>>>>>> `javafx.application.Application`: >>>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>>> x.graphics/src/main/java/javafx/application/Application.java#L527 >>>>>>>>> >>>>>>>>> #### com.sun.glass.ui.Pixels >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> @Override >>>>>>>>> public Image getCaptureRegion(Rectangle2D region) { >>>>>>>>> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> { >>>>>>>>> Pixels glassPixels = useRobot().getScreenCapture( >>>>>>>>> (int) region.getMinX(), (int) region.getMinY(), >>>>>>>>> (int) region.getWidth(), (int) region.getHeight() >>>>>>>>> ); >>>>>>>>> return convertFromGlassPixels(glassPixels); >>>>>>>>> }); >>>>>>>>> } >>>>>>>>> >>>>>>>>> private Image convertFromGlassPixels(Pixels glassPixels) { >>>>>>>>> int width = glassPixels.getWidth(); >>>>>>>>> int height = glassPixels.getHeight(); >>>>>>>>> WritableImage image = new WritableImage(width, height); >>>>>>>>> >>>>>>>>> int bytesPerComponent = glassPixels.getBytesPerComponent(); >>>>>>>>> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) { >>>>>>>>> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels(); >>>>>>>>> writeIntBufferToImage(intBuffer, image); >>>>>>>>> } >>>>>>>>> >>>>>>>>> return image; >>>>>>>>> } >>>>>>>>> >>>>>>>>> private void writeIntBufferToImage(IntBuffer intBuffer, >>>>>>>>> WritableImage image) { >>>>>>>>> PixelWriter pixelWriter = image.getPixelWriter(); >>>>>>>>> double width = image.getWidth(); >>>>>>>>> double height = image.getHeight(); >>>>>>>>> >>>>>>>>> for (int y = 0; y < height; y++) { >>>>>>>>> for (int x = 0; x < width; x++) { >>>>>>>>> int argb = intBuffer.get(); >>>>>>>>> pixelWriter.setArgb(x, y, argb); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> Pixels is used to create a screen capture. >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> >>>>>>>>> Bypass needing to expose the Pixels class to the public API by >>>>>>>>> changing the getScreenCapture method of Robot - that is, changing: >>>>>>>>> >>>>>>>>> `public Pixels getScreenCapture(int x, int y, int width, int height)` >>>>>>>>> >>>>>>>>> to: >>>>>>>>> >>>>>>>>> `public Image getScreenCapture(int x, int y, int width, int height)` >>>>>>>>> >>>>>>>>> #### com.sun.glass.ui.Robot >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> Essentially every method of Robot is used: >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> public void keyPress(int code) >>>>>>>>> public void keyRelease(int code) >>>>>>>>> public int getMouseX() >>>>>>>>> public int getMouseY() >>>>>>>>> public void mouseMove(int x, int y) >>>>>>>>> public void mousePress(int buttons) >>>>>>>>> public void mouseRelease(int buttons) >>>>>>>>> public void mouseWheel(int wheelAmt) >>>>>>>>> public int getPixelColor(int x, int y) >>>>>>>>> public Pixels getScreenCapture(int x, int y, int width, int height) >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Michael Ennen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Michael Ennen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Michael Ennen >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Michael Ennen >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>>> >>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>>> >>>> >>> >>> >>> -- >>> Michael Ennen >>> >>> >> >> >> -- >> Michael Ennen >> >> > > > -- > Michael Ennen > -- Michael Ennen From kevin.rushforth at oracle.com Thu Mar 22 12:54:49 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 22 Mar 2018 05:54:49 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> <5AB19921.3000906@oracle.com> Message-ID: <5AB3A799.5060202@oracle.com> Michael Ennen wrote: > Quick question: > > Currently a Robot is created by calling `Application.createRobot` > which delegates > to the underlying platform-specific application class (GtkApplication, > WinApplication, etc.) > via `com.sun.glass.ui.Application.GetApplication().createRobot();` I just meant that the Toolkit class was a convenient place to call com.sun.glass.ui.Application.GetApplication().createRobot() -- something like this: Toolkit: public GlassRobot createRobot() { // or could be abstract throw new UnsupportedOperationException("not implemented"); } QuantumToolkit: public GlassRobot createRobot() { return com.sun.glass.ui.Application.GetApplication().createRobot(); } The reason for doing it there is because it already has the mechanism for handling QuantumToolkit versus StubToolkit. Otherwise you wouldn't need the extra level of indirection. -- Kevin > You suggest moving this to the Toolkit class? If GtkRobot, WinRobot, > etc. all extend > the abstract base class GlassRobot (the peer), how will Toolkit be > able to instantiate > the correct, platform-specific class? Sorry, I got stuck trying to > implement this part > of your review. The rest is easy for me to follow and will be no problem. > > > On Tue, Mar 20, 2018 at 4:28 PM, Kevin Rushforth > > wrote: > > Hi Michael, > > Here is some quick feedback. > > I think what you have is heading in the right direction as far as > the public API goes. I'd like to get some feedback from other > developers as well. I would want to make sure that the API meets > the needs of multiple developers. > > I took a look at the public class and as I may have mentioned > earlier, it will help to split the API and the implementation even > further, by creating a peer object as we do for Scene, Stage, > etc., rather than having the glass platform implementation > directly subclass the public Robot class. > > Then you can easily delegate to the Glass Robot peer without > having any implementation leak into the public API (e.g., the > overridden create and dispose methods). > > So what you would have in that case is something more like this: > > public final class Robot { > > private final GlassRobot peer; > > public Robot() { > // Ensure we have proper permission for creating a robot. > final SecurityManager sm = System.getSecurityManager(); > if (sm != null) { > sm.checkPermission(CREATE_ROBOT_PERMISSION); > } > > Application.checkEventThread(); > > peer = Toolkit.createRobot(); > } > > // NOTE: for the rest, the peer can do the thread check > > public void keyPress(KeyCode keyCode) { > peer.keyPress(keyCode); > } > > public void keyRelease(KeyCode keyCode) { > peer.keyRelease(keyCode); > } > > public final void keyType(KeyCode keyCode) { > keyPress(keyCode); > keyRelease(keyCode); > } > > ... > > > And so on. The Toolkit class can return a glass robot "peer" which > should then only need minor changes (e.g., to the signatures of > methods that have slightly different types) from the current one. > The QuantumToolkit implementation of createPeer can construct, > initialize, and return the GlassRobot instance. The StubToolkit > and DummyToolkit implementations can throw an > UnsuppportedOperationException. > > As for the public API, the set of methods you have seem mostly > what we would want. Here are a few quick thoughts: > > void keyPress(KeyCode keyCode); > void keyRelease(KeyCode keyCode); > void keyType(KeyCode keyCode); > > int getMouseX(); // maybe should return double? > int getMouseY(); > > Point2D getMousePosition(); > > void mouseMove(int x, int y); // maybe params should be double? > > void mouseMove(Point2D location); > > void mousePress(MouseButton button); // This one seems > redundant...covered by the next method > void mousePress(MouseButton... buttons); > > void mouseRelease(MouseButton button); // This one seems > redundant...covered by the next method > void mouseRelease(MouseButton... buttons); > > // I don't see the need for this method > void mouseWheel(int wheelAmt, VerticalDirection direction); > > void mouseWheel(int wheelAmt); > > Color getPixelColor(int x, int y); // maybe params should be double? > > Color getPixelColor(Point2D location); > > // Probably the following should return WritableImage to match > Snapshot. maybe also have a variable that takes a WritableImage to > allow caller to allocate and reuse (that might overkill in this case)? > > Image getScreenCapture(int x, int y, int width, int height); // > maybe params should be double? > Image getScreenCapture(int x, int y, int width, int height, > boolean scaleToFit); // maybe params should be double? > Image getScreenCapture(Rectangle2D region); > Image getScreenCapture(Rectangle2D region, boolean scaleToFit); > > void getScreenCapture(int x, int y, int width, int height, int[] > data); // Not sure we need / want this one > > The biggest question I have is whether we should follow the > pattern of the other related public APIs in Screen and Stage and > use doubles everywhere rather than ints. Also, we will need to see > whether there are any implications for multiple screens (probably > not, but the docs will need to specify what coordinates the x, and > y values are in). > > Hopefully this will spark a discussion. > > > -- Kevin > > > Michael Ennen wrote: >> Ping :) >> >> On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth >> > >> wrote: >> >> I'll take a look some time after RDP2 of JDK 10. >> >> >> -- Kevin >> >> >> Michael Ennen wrote: >>> Hey Kevin, >>> >>> Hope you had a good holiday. Hopefully you will get some >>> time in the coming weeks >>> to review my work. >>> >>> Thanks! >>> >>> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth >>> >> > wrote: >>> >>> Sure, no problem. One quick comment is that a common way >>> to solve this is by delegating to an implementation >>> class, which would then be sub-classes. >>> >>> >>> -- Kevin >>> >>> >>> Michael Ennen wrote: >>>> I am not trying to be a burden here. I understand that >>>> you may not have time to hand-hold >>>> to this degree. I will try and make progress, sorry for >>>> the follow up question. >>>> >>>> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen >>>> > wrote: >>>> >>>> How can Robot call into the implementation when it >>>> is a super class of the implementations? >>>> >>>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth >>>> >>> > wrote: >>>> >>>> >>>> >>>> Michael Ennen wrote: >>>>> I have a question about how to proceed with >>>>> the Robot code. >>>>> >>>>> The base abstract Robot class >>>>> is: https://github.com/brcolow/openjfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>> >>>>> >>>>> As you can see for each method, such as >>>>> "getMouseX()" there is a "_" prefixed method >>>>> which is abstract and a non-prefixed method: >>>>> >>>>> protected abstract int _getMouseX(); >>>>> >>>>> public int getMouseX() { >>>>> Application.checkEventThread(); >>>>> return _getMouseX(); >>>>> } >>>>> >>>>> I have copied this from the private Robot API. >>>>> >>>>> Is there a better way to do this? Would this >>>>> pass review? >>>> >>>> Yes there are better ways to do this. No it >>>> would not pass review, since this would be >>>> leaking implementation into the public API. >>>> >>>> Rather than copying the public / protected >>>> methods from the internal package, it probably >>>> makes more sense to start with what a Robot API >>>> should look like and then have that call into >>>> the implementation (suitably modified so it >>>> better matches the public API). For one thing >>>> you will then leave the implementation, >>>> including the per-platform code, where it >>>> belongs -- in glass. The Robot API can be >>>> informed by the current implementation, but >>>> should not be defined by it. >>>> >>>> -- Kevin >>>> >>>> >>>>> >>>>> Thanks very much. >>>>> >>>>> >>>>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin >>>>> Rushforth >>>> > wrote: >>>>> >>>>> Glad you got the build working. You can >>>>> post back on this thread when you are ready. >>>>> >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Michael Ennen wrote: >>>>>> Correction: >>>>>> >>>>>> Adding ""--add-exports >>>>>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>>> to buildSrc/addExports. >>>>>> >>>>>> For posterity :) >>>>>> >>>>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael >>>>>> Ennen >>>>> > wrote: >>>>>> >>>>>> Ah, indeed, missed adding >>>>>> "--add-opens >>>>>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>>> to buildSrc/addExports. >>>>>> Thanks for the guidance on that. >>>>>> >>>>>> I will continue to work on this in >>>>>> the GitHub repo and polish it up (add >>>>>> javadocs, better method signatures, >>>>>> etc.) and >>>>>> even plan on maybe improving the >>>>>> underlying native Robot >>>>>> implementations (for example >>>>>> fixing/improving the >>>>>> way color profiles are handled for >>>>>> MacRobot). >>>>>> >>>>>> I will also take a look at "fixing" >>>>>> JemmyFX to use the new public API (as >>>>>> well as any other place in the JavaFX >>>>>> code >>>>>> base that does). >>>>>> >>>>>> I was expecting that JDK 11 would be >>>>>> the appropriate time frame, >>>>>> especially because it will be the >>>>>> release where >>>>>> private APIs will be totally >>>>>> inaccessible, correct? >>>>>> >>>>>> After I get it in a reasonable state >>>>>> should I post back on this mailing >>>>>> list thread or what would be the >>>>>> appropriate >>>>>> way? >>>>>> >>>>>> Thanks Kevin. >>>>>> >>>>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin >>>>>> Rushforth >>>>> > >>>>>> wrote: >>>>>> >>>>>> This is a limitation of the the >>>>>> way --patch-modules works. You >>>>>> will need to add an entry in: >>>>>> >>>>>> buildSrc/addExports >>>>>> >>>>>> Btw, as for the proposal itself, >>>>>> this might need to be a JEP >>>>>> depending on the scope. In any >>>>>> case, it could be considered in >>>>>> the JDK 11 time frame, but there >>>>>> are several things that need to >>>>>> be worked out before making Robot >>>>>> a public API, including the fact >>>>>> that the JemmyFX framework in the >>>>>> openjfx/jfx/tests directory uses >>>>>> Robot. Once you get a working >>>>>> prototype, it would be >>>>>> interesting to discuss it in more >>>>>> detail. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Michael Ennen wrote: >>>>>>> Currently I am stuck with tests not being able to see the new >>>>>>> "javafx.scene.robot" module: >>>>>>> >>>>>>> >>>>>>>> Task :systemTests:compileTestJava >>>>>>>> >>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34: >>>>>>> error: package javafx.scene.robot is not visible >>>>>>> import javafx.scene.robot.Robot; >>>>>>> ^ >>>>>>> (package javafx.scene.robot is declared in module javafx.graphics, which >>>>>>> does not export it) >>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33: >>>>>>> error: package javafx.scene.robot is not visible >>>>>>> import javafx.scene.robot.Robot; >>>>>>> >>>>>>> I have added: >>>>>>> >>>>>>> exports javafx.scene.robot; >>>>>>> >>>>>>> to: modules/javafx.graphics/src/main/java/module-info.java >>>>>>> >>>>>>> But this does not seem to be enough. >>>>>>> >>>>>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen wrote: >>>>>>> >>>>>>> >>>>>>>> I am still working on all the necessary changes to actually allow openjfx >>>>>>>> to compile. >>>>>>>> Tons to learn in that arena and I know the code as it is written won't >>>>>>>> totally work. >>>>>>>> For example one can no longer: >>>>>>>> >>>>>>>> #include "com_sun_glass_ui_Robot.h" >>>>>>>> >>>>>>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp >>>>>>>> >>>>>>>> But I am not sure how those headers are generated and if I can just simply >>>>>>>> change >>>>>>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt). >>>>>>>> >>>>>>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I have created a (small) proposal (building on the work of Benjamin >>>>>>>>> Gudehaus) about moving some classes in to the public API so that TestFX (a >>>>>>>>> JavaFX UI testing framework) can continue to work with future JDK releases. >>>>>>>>> The somewhat nicely formatted proposal can be found as a Github gist: >>>>>>>>> >>>>>>>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >>>>>>>>> >>>>>>>>> All suggested changes can be found by using Github Compare View: >>>>>>>>> >>>>>>>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 >>>>>>>>> e1f4f1cb8f20430feaa53b6...master >>>>>>>>> >>>>>>>>> But I have copied it to this email for convenience: >>>>>>>>> >>>>>>>>> ----------------------- PROPOSAL ----------------------- >>>>>>>>> >>>>>>>>> TestFX, the JavaFX GUI testing framework currently requires 4 (four) >>>>>>>>> classes that are part of the JDK's private API. They are: >>>>>>>>> >>>>>>>>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op >>>>>>>>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/ >>>>>>>>> java/com/sun/glass/ui/Application.java) >>>>>>>>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx >>>>>>>>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/ >>>>>>>>> com/sun/glass/ui/Pixels.java) >>>>>>>>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/ >>>>>>>>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com >>>>>>>>> /sun/glass/ui/Robot.java) >>>>>>>>> [com.sun.javafx.application.Pa rametersImpl](http://hg.openjd >>>>>>>>> k.java.net/openjfx/10-dev/rt/file/tip/modules/javafx. >>>>>>>>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java ) >>>>>>>>> >>>>>>>>> In order to compile the project with Java 9, we use the following flags: >>>>>>>>> >>>>>>>>> ```sh >>>>>>>>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx >>>>>>>>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> If the --add-exports flags are disabled in a future Java release TestFX >>>>>>>>> will require these four classes to be moved into the public API to >>>>>>>>> continue working. >>>>>>>>> >>>>>>>>> While these classes are probably not very useful for applications to use >>>>>>>>> directly, any JavaFX application wanting to write UI tests will most >>>>>>>>> likely >>>>>>>>> use TestFX and thus they will indirectly be using these classes. >>>>>>>>> >>>>>>>>> JavaFX internal tests also use these classes for essentially the same >>>>>>>>> purpose (UI tests). >>>>>>>>> >>>>>>>>> ### Details of Usage For Each Private API Class >>>>>>>>> >>>>>>>>> #### com.sun.javafx.application.ParametersImpl >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> ParametersImpl parameters = new ParametersImpl(applicationArgs); >>>>>>>>> ParametersImpl.registerParameters(application, parameters); >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> The parameters are set on a constructed Application. >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> >>>>>>>>> `javafx.application.Application`: >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> /** >>>>>>>>> * Sets the parameters for this Application. >>>>>>>>> * >>>>>>>>> *

>>>>>>>>> * NOTE: this method should not be called from the Application >>>>>>>>> constructor, >>>>>>>>> * as it will return null. It may be called in the init() method or any >>>>>>>>> * time after that. >>>>>>>>> *

>>>>>>>>> * >>>>>>>>> * @param parameters the parameters to set for this Application >>>>>>>>> */ >>>>>>>>> public final Parameters setParameters(String... parameters) { >>>>>>>>> ParametersImpl parameters = new ParametersImpl(parameters); >>>>>>>>> ParametersImpl.registerParameters(this, parameters); >>>>>>>>> } >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> #### com.sun.glass.ui.Application >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> return Application.GetApplication().createRobot(); >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> The Application class is used to instantiate a Robot. >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> >>>>>>>>> `javafx.application.Application`: >>>>>>>>> >>>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>>> x.graphics/src/main/java/javafx/application/Application.java#L527 >>>>>>>>> >>>>>>>>> #### com.sun.glass.ui.Pixels >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> @Override >>>>>>>>> public Image getCaptureRegion(Rectangle2D region) { >>>>>>>>> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> { >>>>>>>>> Pixels glassPixels = useRobot().getScreenCapture( >>>>>>>>> (int) region.getMinX(), (int) region.getMinY(), >>>>>>>>> (int) region.getWidth(), (int) region.getHeight() >>>>>>>>> ); >>>>>>>>> return convertFromGlassPixels(glassPixels); >>>>>>>>> }); >>>>>>>>> } >>>>>>>>> >>>>>>>>> private Image convertFromGlassPixels(Pixels glassPixels) { >>>>>>>>> int width = glassPixels.getWidth(); >>>>>>>>> int height = glassPixels.getHeight(); >>>>>>>>> WritableImage image = new WritableImage(width, height); >>>>>>>>> >>>>>>>>> int bytesPerComponent = glassPixels.getBytesPerComponent(); >>>>>>>>> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) { >>>>>>>>> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels(); >>>>>>>>> writeIntBufferToImage(intBuffer, image); >>>>>>>>> } >>>>>>>>> >>>>>>>>> return image; >>>>>>>>> } >>>>>>>>> >>>>>>>>> private void writeIntBufferToImage(IntBuffer intBuffer, >>>>>>>>> WritableImage image) { >>>>>>>>> PixelWriter pixelWriter = image.getPixelWriter(); >>>>>>>>> double width = image.getWidth(); >>>>>>>>> double height = image.getHeight(); >>>>>>>>> >>>>>>>>> for (int y = 0; y < height; y++) { >>>>>>>>> for (int x = 0; x < width; x++) { >>>>>>>>> int argb = intBuffer.get(); >>>>>>>>> pixelWriter.setArgb(x, y, argb); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> Pixels is used to create a screen capture. >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> >>>>>>>>> Bypass needing to expose the Pixels class to the public API by >>>>>>>>> changing the getScreenCapture method of Robot - that is, changing: >>>>>>>>> >>>>>>>>> `public Pixels getScreenCapture(int x, int y, int width, int height)` >>>>>>>>> >>>>>>>>> to: >>>>>>>>> >>>>>>>>> `public Image getScreenCapture(int x, int y, int width, int height)` >>>>>>>>> >>>>>>>>> #### com.sun.glass.ui.Robot >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> Essentially every method of Robot is used: >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> public void keyPress(int code) >>>>>>>>> public void keyRelease(int code) >>>>>>>>> public int getMouseX() >>>>>>>>> public int getMouseY() >>>>>>>>> public void mouseMove(int x, int y) >>>>>>>>> public void mousePress(int buttons) >>>>>>>>> public void mouseRelease(int buttons) >>>>>>>>> public void mouseWheel(int wheelAmt) >>>>>>>>> public int getPixelColor(int x, int y) >>>>>>>>> public Pixels getScreenCapture(int x, int y, int width, int height) >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> >>>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Michael Ennen >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> Michael Ennen >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>> >>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>>> >>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>> >>> >>> >>> >>> -- >>> Michael Ennen >> >> >> >> >> -- >> Michael Ennen > > > > > -- > Michael Ennen From mike.ennen at gmail.com Thu Mar 22 21:27:57 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Thu, 22 Mar 2018 14:27:57 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <5AB3A799.5060202@oracle.com> References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> <5AB19921.3000906@oracle.com> <5AB3A799.5060202@oracle.com> Message-ID: Got it. Not sure why I made it so complicated in my head, lol. Will be working on this in the next few days. On Thu, Mar 22, 2018 at 5:54 AM, Kevin Rushforth wrote: > > > Michael Ennen wrote: > > Quick question: > > Currently a Robot is created by calling `Application.createRobot` which > delegates > to the underlying platform-specific application class (GtkApplication, > WinApplication, etc.) > via `com.sun.glass.ui.Application.GetApplication().createRobot();` > > > I just meant that the Toolkit class was a convenient place to call > com.sun.glass.ui.Application.GetApplication().createRobot() -- something > like this: > > Toolkit: > > public GlassRobot createRobot() { // or could be abstract > throw new UnsupportedOperationException("not implemented"); > } > > QuantumToolkit: > > public GlassRobot createRobot() { > return com.sun.glass.ui.Application.GetApplication().createRobot(); > } > > The reason for doing it there is because it already has the mechanism for > handling QuantumToolkit versus StubToolkit. Otherwise you wouldn't need the > extra level of indirection. > > -- Kevin > > > You suggest moving this to the Toolkit class? If GtkRobot, WinRobot, etc. > all extend > the abstract base class GlassRobot (the peer), how will Toolkit be able to > instantiate > the correct, platform-specific class? Sorry, I got stuck trying to > implement this part > of your review. The rest is easy for me to follow and will be no problem. > > > On Tue, Mar 20, 2018 at 4:28 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Hi Michael, >> >> Here is some quick feedback. >> >> I think what you have is heading in the right direction as far as the >> public API goes. I'd like to get some feedback from other developers as >> well. I would want to make sure that the API meets the needs of multiple >> developers. >> >> I took a look at the public class and as I may have mentioned earlier, it >> will help to split the API and the implementation even further, by creating >> a peer object as we do for Scene, Stage, etc., rather than having the glass >> platform implementation directly subclass the public Robot class. >> >> Then you can easily delegate to the Glass Robot peer without having any >> implementation leak into the public API (e.g., the overridden create and >> dispose methods). >> >> So what you would have in that case is something more like this: >> >> public final class Robot { >> >> private final GlassRobot peer; >> >> public Robot() { >> // Ensure we have proper permission for creating a robot. >> final SecurityManager sm = System.getSecurityManager(); >> if (sm != null) { >> sm.checkPermission(CREATE_ROBOT_PERMISSION); >> } >> >> Application.checkEventThread(); >> >> peer = Toolkit.createRobot(); >> } >> >> // NOTE: for the rest, the peer can do the thread check >> >> public void keyPress(KeyCode keyCode) { >> peer.keyPress(keyCode); >> } >> >> public void keyRelease(KeyCode keyCode) { >> peer.keyRelease(keyCode); >> } >> >> public final void keyType(KeyCode keyCode) { >> keyPress(keyCode); >> keyRelease(keyCode); >> } >> >> ... >> >> >> And so on. The Toolkit class can return a glass robot "peer" which should >> then only need minor changes (e.g., to the signatures of methods that have >> slightly different types) from the current one. The QuantumToolkit >> implementation of createPeer can construct, initialize, and return the >> GlassRobot instance. The StubToolkit and DummyToolkit implementations can >> throw an UnsuppportedOperationException. >> >> As for the public API, the set of methods you have seem mostly what we >> would want. Here are a few quick thoughts: >> >> void keyPress(KeyCode keyCode); >> void keyRelease(KeyCode keyCode); >> void keyType(KeyCode keyCode); >> >> int getMouseX(); // maybe should return double? >> int getMouseY(); >> >> Point2D getMousePosition(); >> >> void mouseMove(int x, int y); // maybe params should be double? >> >> void mouseMove(Point2D location); >> >> void mousePress(MouseButton button); // This one seems >> redundant...covered by the next method >> void mousePress(MouseButton... buttons); >> >> void mouseRelease(MouseButton button); // This one seems >> redundant...covered by the next method >> void mouseRelease(MouseButton... buttons); >> >> // I don't see the need for this method >> void mouseWheel(int wheelAmt, VerticalDirection direction); >> >> void mouseWheel(int wheelAmt); >> >> Color getPixelColor(int x, int y); // maybe params should be double? >> >> Color getPixelColor(Point2D location); >> >> // Probably the following should return WritableImage to match Snapshot. >> maybe also have a variable that takes a WritableImage to allow caller to >> allocate and reuse (that might overkill in this case)? >> >> Image getScreenCapture(int x, int y, int width, int height); // maybe >> params should be double? >> Image getScreenCapture(int x, int y, int width, int height, boolean >> scaleToFit); // maybe params should be double? >> Image getScreenCapture(Rectangle2D region); >> Image getScreenCapture(Rectangle2D region, boolean scaleToFit); >> >> void getScreenCapture(int x, int y, int width, int height, int[] data); >> // Not sure we need / want this one >> >> The biggest question I have is whether we should follow the pattern of >> the other related public APIs in Screen and Stage and use doubles >> everywhere rather than ints. Also, we will need to see whether there are >> any implications for multiple screens (probably not, but the docs will need >> to specify what coordinates the x, and y values are in). >> >> Hopefully this will spark a discussion. >> >> >> -- Kevin >> >> >> Michael Ennen wrote: >> >> Ping :) >> >> On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> I'll take a look some time after RDP2 of JDK 10. >>> >>> >>> -- Kevin >>> >>> >>> Michael Ennen wrote: >>> >>> Hey Kevin, >>> >>> Hope you had a good holiday. Hopefully you will get some time in the >>> coming weeks >>> to review my work. >>> >>> Thanks! >>> >>> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> Sure, no problem. One quick comment is that a common way to solve this >>>> is by delegating to an implementation class, which would then be >>>> sub-classes. >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> Michael Ennen wrote: >>>> >>>> I am not trying to be a burden here. I understand that you may not have >>>> time to hand-hold >>>> to this degree. I will try and make progress, sorry for the follow up >>>> question. >>>> >>>> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen >>>> wrote: >>>> >>>>> How can Robot call into the implementation when it is a super class of >>>>> the implementations? >>>>> >>>>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> Michael Ennen wrote: >>>>>> >>>>>> I have a question about how to proceed with the Robot code. >>>>>> >>>>>> The base abstract Robot class is: https://github.com/brcolow >>>>>> /openjfx/blob/master/modules/javafx.graphics/src/main/java/j >>>>>> avafx/scene/robot/Robot.java >>>>>> >>>>>> As you can see for each method, such as "getMouseX()" there is a "_" >>>>>> prefixed method >>>>>> which is abstract and a non-prefixed method: >>>>>> >>>>>> protected abstract int _getMouseX(); >>>>>> >>>>>> public int getMouseX() { >>>>>> Application.checkEventThread(); >>>>>> return _getMouseX(); >>>>>> } >>>>>> >>>>>> I have copied this from the private Robot API. >>>>>> >>>>>> Is there a better way to do this? Would this pass review? >>>>>> >>>>>> >>>>>> Yes there are better ways to do this. No it would not pass review, >>>>>> since this would be leaking implementation into the public API. >>>>>> >>>>>> Rather than copying the public / protected methods from the internal >>>>>> package, it probably makes more sense to start with what a Robot API should >>>>>> look like and then have that call into the implementation (suitably >>>>>> modified so it better matches the public API). For one thing you will then >>>>>> leave the implementation, including the per-platform code, where it belongs >>>>>> -- in glass. The Robot API can be informed by the current implementation, >>>>>> but should not be defined by it. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Thanks very much. >>>>>> >>>>>> >>>>>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth < >>>>>> kevin.rushforth at oracle.com> wrote: >>>>>> >>>>>>> Glad you got the build working. You can post back on this thread >>>>>>> when you are ready. >>>>>>> >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Michael Ennen wrote: >>>>>>> >>>>>>> Correction: >>>>>>> >>>>>>> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>>>> to buildSrc/addExports. >>>>>>> >>>>>>> For posterity :) >>>>>>> >>>>>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen >>>>>>> wrote: >>>>>>> >>>>>>>> Ah, indeed, missed adding "--add-opens >>>>>>>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED" to >>>>>>>> buildSrc/addExports. >>>>>>>> Thanks for the guidance on that. >>>>>>>> >>>>>>>> I will continue to work on this in the GitHub repo and polish it up >>>>>>>> (add javadocs, better method signatures, etc.) and >>>>>>>> even plan on maybe improving the underlying native Robot >>>>>>>> implementations (for example fixing/improving the >>>>>>>> way color profiles are handled for MacRobot). >>>>>>>> >>>>>>>> I will also take a look at "fixing" JemmyFX to use the new public >>>>>>>> API (as well as any other place in the JavaFX code >>>>>>>> base that does). >>>>>>>> >>>>>>>> I was expecting that JDK 11 would be the appropriate time frame, >>>>>>>> especially because it will be the release where >>>>>>>> private APIs will be totally inaccessible, correct? >>>>>>>> >>>>>>>> After I get it in a reasonable state should I post back on this >>>>>>>> mailing list thread or what would be the appropriate >>>>>>>> way? >>>>>>>> >>>>>>>> Thanks Kevin. >>>>>>>> >>>>>>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth < >>>>>>>> kevin.rushforth at oracle.com> wrote: >>>>>>>> >>>>>>>>> This is a limitation of the the way --patch-modules works. You >>>>>>>>> will need to add an entry in: >>>>>>>>> >>>>>>>>> buildSrc/addExports >>>>>>>>> >>>>>>>>> Btw, as for the proposal itself, this might need to be a JEP >>>>>>>>> depending on the scope. In any case, it could be considered in the JDK 11 >>>>>>>>> time frame, but there are several things that need to be worked out before >>>>>>>>> making Robot a public API, including the fact that the JemmyFX framework in >>>>>>>>> the openjfx/jfx/tests directory uses Robot. Once you get a working >>>>>>>>> prototype, it would be interesting to discuss it in more detail. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Michael Ennen wrote: >>>>>>>>> >>>>>>>>> Currently I am stuck with tests not being able to see the new >>>>>>>>> "javafx.scene.robot" module: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Task :systemTests:compileTestJava >>>>>>>>> >>>>>>>>> >>>>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34: >>>>>>>>> error: package javafx.scene.robot is not visible >>>>>>>>> import javafx.scene.robot.Robot; >>>>>>>>> ^ >>>>>>>>> (package javafx.scene.robot is declared in module javafx.graphics, which >>>>>>>>> does not export it) >>>>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33: >>>>>>>>> error: package javafx.scene.robot is not visible >>>>>>>>> import javafx.scene.robot.Robot; >>>>>>>>> >>>>>>>>> I have added: >>>>>>>>> >>>>>>>>> exports javafx.scene.robot; >>>>>>>>> >>>>>>>>> to: modules/javafx.graphics/src/main/java/module-info.java >>>>>>>>> >>>>>>>>> But this does not seem to be enough. >>>>>>>>> >>>>>>>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I am still working on all the necessary changes to actually allow openjfx >>>>>>>>> to compile. >>>>>>>>> Tons to learn in that arena and I know the code as it is written won't >>>>>>>>> totally work. >>>>>>>>> For example one can no longer: >>>>>>>>> >>>>>>>>> #include "com_sun_glass_ui_Robot.h" >>>>>>>>> >>>>>>>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp >>>>>>>>> >>>>>>>>> But I am not sure how those headers are generated and if I can just simply >>>>>>>>> change >>>>>>>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt). >>>>>>>>> >>>>>>>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I have created a (small) proposal (building on the work of Benjamin >>>>>>>>> Gudehaus) about moving some classes in to the public API so that TestFX (a >>>>>>>>> JavaFX UI testing framework) can continue to work with future JDK releases. >>>>>>>>> The somewhat nicely formatted proposal can be found as a Github gist: >>>>>>>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >>>>>>>>> >>>>>>>>> All suggested changes can be found by using Github Compare View: >>>>>>>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 >>>>>>>>> e1f4f1cb8f20430feaa53b6...master >>>>>>>>> >>>>>>>>> But I have copied it to this email for convenience: >>>>>>>>> >>>>>>>>> ----------------------- PROPOSAL ----------------------- >>>>>>>>> >>>>>>>>> TestFX, the JavaFX GUI testing framework currently requires 4 (four) >>>>>>>>> classes that are part of the JDK's private API. They are: >>>>>>>>> >>>>>>>>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op >>>>>>>>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/ >>>>>>>>> java/com/sun/glass/ui/Application.java) >>>>>>>>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx >>>>>>>>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/ >>>>>>>>> com/sun/glass/ui/Pixels.java) >>>>>>>>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/ >>>>>>>>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com >>>>>>>>> /sun/glass/ui/Robot.java) >>>>>>>>> [com.sun.javafx.application.ParametersImpl](http://hg.openjdk.java.net/openjfx/10-dev/rt/file/tip/modules/javafx. >>>>>>>>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java ) >>>>>>>>> >>>>>>>>> In order to compile the project with Java 9, we use the following flags: >>>>>>>>> >>>>>>>>> ```sh >>>>>>>>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx >>>>>>>>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> If the --add-exports flags are disabled in a future Java release TestFX >>>>>>>>> will require these four classes to be moved into the public API to >>>>>>>>> continue working. >>>>>>>>> >>>>>>>>> While these classes are probably not very useful for applications to use >>>>>>>>> directly, any JavaFX application wanting to write UI tests will most >>>>>>>>> likely >>>>>>>>> use TestFX and thus they will indirectly be using these classes. >>>>>>>>> >>>>>>>>> JavaFX internal tests also use these classes for essentially the same >>>>>>>>> purpose (UI tests). >>>>>>>>> >>>>>>>>> ### Details of Usage For Each Private API Class >>>>>>>>> >>>>>>>>> #### com.sun.javafx.application.ParametersImpl >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> ParametersImpl parameters = new ParametersImpl(applicationArgs); >>>>>>>>> ParametersImpl.registerParameters(application, parameters); >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> The parameters are set on a constructed Application. >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> >>>>>>>>> `javafx.application.Application`: >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> /** >>>>>>>>> * Sets the parameters for this Application. >>>>>>>>> * >>>>>>>>> *

>>>>>>>>> * NOTE: this method should not be called from the Application >>>>>>>>> constructor, >>>>>>>>> * as it will return null. It may be called in the init() method or any >>>>>>>>> * time after that. >>>>>>>>> *

>>>>>>>>> * >>>>>>>>> * @param parameters the parameters to set for this Application >>>>>>>>> */ >>>>>>>>> public final Parameters setParameters(String... parameters) { >>>>>>>>> ParametersImpl parameters = new ParametersImpl(parameters); >>>>>>>>> ParametersImpl.registerParameters(this, parameters); >>>>>>>>> } >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> #### com.sun.glass.ui.Application >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> return Application.GetApplication().createRobot(); >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> The Application class is used to instantiate a Robot. >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> >>>>>>>>> `javafx.application.Application`: >>>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>>> x.graphics/src/main/java/javafx/application/Application.java#L527 >>>>>>>>> >>>>>>>>> #### com.sun.glass.ui.Pixels >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> @Override >>>>>>>>> public Image getCaptureRegion(Rectangle2D region) { >>>>>>>>> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> { >>>>>>>>> Pixels glassPixels = useRobot().getScreenCapture( >>>>>>>>> (int) region.getMinX(), (int) region.getMinY(), >>>>>>>>> (int) region.getWidth(), (int) region.getHeight() >>>>>>>>> ); >>>>>>>>> return convertFromGlassPixels(glassPixels); >>>>>>>>> }); >>>>>>>>> } >>>>>>>>> >>>>>>>>> private Image convertFromGlassPixels(Pixels glassPixels) { >>>>>>>>> int width = glassPixels.getWidth(); >>>>>>>>> int height = glassPixels.getHeight(); >>>>>>>>> WritableImage image = new WritableImage(width, height); >>>>>>>>> >>>>>>>>> int bytesPerComponent = glassPixels.getBytesPerComponent(); >>>>>>>>> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) { >>>>>>>>> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels(); >>>>>>>>> writeIntBufferToImage(intBuffer, image); >>>>>>>>> } >>>>>>>>> >>>>>>>>> return image; >>>>>>>>> } >>>>>>>>> >>>>>>>>> private void writeIntBufferToImage(IntBuffer intBuffer, >>>>>>>>> WritableImage image) { >>>>>>>>> PixelWriter pixelWriter = image.getPixelWriter(); >>>>>>>>> double width = image.getWidth(); >>>>>>>>> double height = image.getHeight(); >>>>>>>>> >>>>>>>>> for (int y = 0; y < height; y++) { >>>>>>>>> for (int x = 0; x < width; x++) { >>>>>>>>> int argb = intBuffer.get(); >>>>>>>>> pixelWriter.setArgb(x, y, argb); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> Pixels is used to create a screen capture. >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> >>>>>>>>> Bypass needing to expose the Pixels class to the public API by >>>>>>>>> changing the getScreenCapture method of Robot - that is, changing: >>>>>>>>> >>>>>>>>> `public Pixels getScreenCapture(int x, int y, int width, int height)` >>>>>>>>> >>>>>>>>> to: >>>>>>>>> >>>>>>>>> `public Image getScreenCapture(int x, int y, int width, int height)` >>>>>>>>> >>>>>>>>> #### com.sun.glass.ui.Robot >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> Essentially every method of Robot is used: >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> public void keyPress(int code) >>>>>>>>> public void keyRelease(int code) >>>>>>>>> public int getMouseX() >>>>>>>>> public int getMouseY() >>>>>>>>> public void mouseMove(int x, int y) >>>>>>>>> public void mousePress(int buttons) >>>>>>>>> public void mouseRelease(int buttons) >>>>>>>>> public void mouseWheel(int wheelAmt) >>>>>>>>> public int getPixelColor(int x, int y) >>>>>>>>> public Pixels getScreenCapture(int x, int y, int width, int height) >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Michael Ennen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Michael Ennen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Michael Ennen >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Michael Ennen >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>>> >>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>>> >>>> >>> >>> >>> -- >>> Michael Ennen >>> >>> >> >> >> -- >> Michael Ennen >> >> > > > -- > Michael Ennen > > -- Michael Ennen From ajit.ghaisas at oracle.com Fri Mar 23 16:34:43 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Fri, 23 Mar 2018 09:34:43 -0700 (PDT) Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules Message-ID: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> Hi Kevin, Mandy and Daniel, Please review the changeset that removes dependency on sun.util.logging package from JavaFX code. Bug : https://bugs.openjdk.java.net/browse/JDK-8195799 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ Request you to review. Regards, Ajit From mandy.chung at oracle.com Fri Mar 23 17:00:28 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 23 Mar 2018 10:00:28 -0700 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> Message-ID: <13cf6742-1d37-0b40-3214-11a2372cc8a3@oracle.com> On 3/23/18 9:34 AM, Ajit Ghaisas wrote: > Hi Kevin, Mandy and Daniel, > > Please review the changeset that removes dependency on sun.util.logging package from JavaFX code. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8195799 > Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ > buildSrc/addExports ?? FX modules are compiled together and I don't expect these --add-exports are needed.? I suspect it's because of the boot JDK and this is a temporary dance? PlatformLogger.java ?150???? public static synchronized PlatformLogger getLogger(String name) { This keeps the weak reference to all PlatformLogger created.? A simplification is to return new PlatformLogger(System.getLogger(name)); System::getLogger should return the same instance if it has been created.? I also suspect the caller of PlatformLogger::getLogger keeps a strong reference and calls it once. I recalled there were some native methods calling the Java API to set level.? It has been a while back since I looked at it and things miight have changed.? Is there such reference any more? Other than the above comments, this change looks good. Mandy From daniel.fuchs at oracle.com Fri Mar 23 17:21:01 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 23 Mar 2018 17:21:01 +0000 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> Message-ID: <676e17c7-8ffe-be71-553e-b4fcff58c1a5@oracle.com> Hi Ajit, I have two remarks, 1. I wonder if it's wise to keep the old unused levels like e.g. Level.CONFIG in your new PlatformLogger. The sun.util.logging.PlatformLogger had a bridge that allowed it to transfer these levels unchanged to java.logging when java.logging was the backend. Your new PlatformLogger does not have these bridges. Which means that code that might log with Level.CONFIG will in reality log with Level.DEBUG, which will be translated to Level.FINE when java.logging is the backend. So with the old sun.u.l.PlatformLogger, logging with Level.CONFIG would have ended up logging with Level.CONFIG in java.logging, but with your new implementation, this will end up as Level.FINE (as DEBUG maps to FINE when java.logging is the backend). AFAICS - there's no code in JavaFX (at least in the files present in your webrev) that logs with Level.CONFIG. So why not just remove these unused levels from your implementation of PlatformLogger? You certainly don't want new code to start using PlatformLogger::config (as that's actually an alias to DEBUG). The best way of avoiding future usage when there's none today is just to remove these problematic API point. 2. I understand the desire of minimizing the code changes, and introducing a PlatformLogger class that mimics the old sun.util.logging.PlatformLogger certainly achieve this goal. Now the interesting thing is: how many log statements are there throughout the JavaFX code base? If there are not too many - then you might want consider changing them to use directly the levels provided by System.Logger - and then you might want to use the "Refactor -> Rename" option of your IDE to simply rename the methods PlatformLogger::severe to PlatformLogger::error PlatformLogger::fine to PlatformLogger::debug PlatformLogger::finer to PlatformLogger::trace PlatformLogger::finest to PlatformLogger::trace Otherwise looks mostly good - I guess. best regards, -- daniel On 23/03/2018 16:34, Ajit Ghaisas wrote: > Hi Kevin, Mandy and Daniel, > > Please review the changeset that removes dependency on sun.util.logging package from JavaFX code. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8195799 > Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ > > Request you to review. > > Regards, > Ajit > From daniel.fuchs at oracle.com Fri Mar 23 17:29:14 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 23 Mar 2018 17:29:14 +0000 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <13cf6742-1d37-0b40-3214-11a2372cc8a3@oracle.com> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <13cf6742-1d37-0b40-3214-11a2372cc8a3@oracle.com> Message-ID: <900f5e2d-8aa8-ac1b-ebc2-2ae9e72e134d@oracle.com> Hi Mandy, On 23/03/2018 17:00, mandy chung wrote: > System::getLogger should return the same instance if it has been > created. Not necessarily. j.u.l does that, but System::getLogger may return a new cheap wrapper. As you noted, if JavaFX sources only creates a handful of loggers, the cost of maintaining a Map and dealing with the complexity of weak reference may not be justified. Best regards, -- daniel From kevin.rushforth at oracle.com Fri Mar 23 17:51:15 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 23 Mar 2018 10:51:15 -0700 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <676e17c7-8ffe-be71-553e-b4fcff58c1a5@oracle.com> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <676e17c7-8ffe-be71-553e-b4fcff58c1a5@oracle.com> Message-ID: <5AB53E93.8050407@oracle.com> Hi Daniel, Thanks for the review. I like the idea of removing the unused levels and methods. As for directly using System.Logger.Level, we have enough usages of the Level and convenience logging methods (e.g., "warn", "fine", etc.), that I think it's better to file a follow-up issue (to minimize the changes and so it would be more feasible to review the existing changes). The idea of doing a refactor / rename of the convenience methods and level names to match seems like a good one for that follow-up JBS issue. -- Kevin Daniel Fuchs wrote: > Hi Ajit, > > I have two remarks, > > 1. I wonder if it's wise to keep the old unused levels like e.g. > Level.CONFIG in your new PlatformLogger. > > The sun.util.logging.PlatformLogger had a bridge that allowed > it to transfer these levels unchanged to java.logging when > java.logging was the backend. > > Your new PlatformLogger does not have these bridges. > Which means that code that might log with Level.CONFIG > will in reality log with Level.DEBUG, which will be translated > to Level.FINE when java.logging is the backend. > > So with the old sun.u.l.PlatformLogger, logging with Level.CONFIG > would have ended up logging with Level.CONFIG in java.logging, > but with your new implementation, this will end up as Level.FINE > (as DEBUG maps to FINE when java.logging is the backend). > > AFAICS - there's no code in JavaFX (at least in the files present > in your webrev) that logs with Level.CONFIG. > So why not just remove these unused levels from your implementation > of PlatformLogger? You certainly don't want new code > to start using PlatformLogger::config (as that's actually > an alias to DEBUG). > The best way of avoiding future usage when there's none > today is just to remove these problematic API point. > > 2. I understand the desire of minimizing the code changes, and > introducing a PlatformLogger class that mimics the old > sun.util.logging.PlatformLogger certainly achieve this goal. > Now the interesting thing is: how many log statements are there > throughout the JavaFX code base? > > If there are not too many - then you might want consider > changing them to use directly the levels provided by > System.Logger - and then you might want to use the > "Refactor -> Rename" option of your IDE to simply > rename the methods > > PlatformLogger::severe to PlatformLogger::error > PlatformLogger::fine to PlatformLogger::debug > PlatformLogger::finer to PlatformLogger::trace > PlatformLogger::finest to PlatformLogger::trace > > > Otherwise looks mostly good - I guess. > > best regards, > > -- daniel > > On 23/03/2018 16:34, Ajit Ghaisas wrote: >> Hi Kevin, Mandy and Daniel, >> >> Please review the changeset that removes dependency on >> sun.util.logging package from JavaFX code. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8195799 >> Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ >> >> Request you to review. >> >> Regards, >> Ajit >> > From daniel.fuchs at oracle.com Fri Mar 23 19:19:29 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 23 Mar 2018 19:19:29 +0000 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <5AB53E93.8050407@oracle.com> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <676e17c7-8ffe-be71-553e-b4fcff58c1a5@oracle.com> <5AB53E93.8050407@oracle.com> Message-ID: Hi Kevin, This sounds reasonable to me. best regards, -- daniel On 23/03/2018 17:51, Kevin Rushforth wrote: > Hi Daniel, > > Thanks for the review. > > I like the idea of removing the unused levels and methods. > > As for directly using System.Logger.Level, we have enough usages of the > Level and convenience logging methods (e.g., "warn", "fine", etc.), that > I think it's better to file a follow-up issue (to minimize the changes > and so it would be more feasible to review the existing changes). The > idea of doing a refactor / rename of the convenience methods and level > names to match seems like a good one for that follow-up JBS issue. > > -- Kevin From mandy.chung at oracle.com Fri Mar 23 19:31:22 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 23 Mar 2018 12:31:22 -0700 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <5AB53E93.8050407@oracle.com> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <676e17c7-8ffe-be71-553e-b4fcff58c1a5@oracle.com> <5AB53E93.8050407@oracle.com> Message-ID: <08f39c95-67e5-7016-32f0-6cf1c0665ac1@oracle.com> On 3/23/18 10:51 AM, Kevin Rushforth wrote: > Hi Daniel, > > Thanks for the review. > > I like the idea of removing the unused levels and methods. > > As for directly using System.Logger.Level, we have enough usages of > the Level and convenience logging methods (e.g., "warn", "fine", > etc.), that I think it's better to file a follow-up issue (to minimize > the changes and so it would be more feasible to review the existing > changes). The idea of doing a refactor / rename of the convenience > methods and level names to match seems like a good one for that > follow-up JBS issue. > When you do the clean up, I suggest to drop PlatformLogger completely and directly use System.Logger (in addition to System.Logger.Level) Mandy > -- Kevin > > > Daniel Fuchs wrote: >> Hi Ajit, >> >> I have two remarks, >> >> 1. I wonder if it's wise to keep the old unused levels like e.g. >> ?? Level.CONFIG in your new PlatformLogger. >> >> ?? The sun.util.logging.PlatformLogger had a bridge that allowed >> ?? it to transfer these levels unchanged to java.logging when >> ?? java.logging was the backend. >> >> ?? Your new PlatformLogger does not have these bridges. >> ?? Which means that code that might log with Level.CONFIG >> ?? will in reality log with Level.DEBUG, which will be translated >> ?? to Level.FINE when java.logging is the backend. >> >> ?? So with the old sun.u.l.PlatformLogger, logging with Level.CONFIG >> ?? would have ended up logging with Level.CONFIG in java.logging, >> ?? but with your new implementation, this will end up as Level.FINE >> ?? (as DEBUG maps to FINE when java.logging is the backend). >> >> ?? AFAICS - there's no code in JavaFX (at least in the files present >> ?? in your webrev) that logs with Level.CONFIG. >> ?? So why not just remove these unused levels from your implementation >> ?? of PlatformLogger? You certainly don't want new code >> ?? to start using PlatformLogger::config (as that's actually >> ?? an alias to DEBUG). >> ?? The best way of avoiding future usage when there's none >> ?? today is just to remove these problematic API point. >> >> 2. I understand the desire of minimizing the code changes, and >> ?? introducing a PlatformLogger class that mimics the old >> ?? sun.util.logging.PlatformLogger certainly achieve this goal. >> ?? Now the interesting thing is: how many log statements are there >> ?? throughout the JavaFX code base? >> >> ?? If there are not too many - then you might want consider >> ?? changing them to use directly the levels provided by >> ?? System.Logger - and then you might want to use the >> ?? "Refactor -> Rename" option of your IDE to simply >> ?? rename the methods >> >> ?? PlatformLogger::severe to PlatformLogger::error >> ?? PlatformLogger::fine to PlatformLogger::debug >> ?? PlatformLogger::finer to PlatformLogger::trace >> ?? PlatformLogger::finest to PlatformLogger::trace >> >> >> Otherwise looks mostly good - I guess. >> >> best regards, >> >> -- daniel >> >> On 23/03/2018 16:34, Ajit Ghaisas wrote: >>> Hi Kevin, Mandy and Daniel, >>> >>> ???? Please review the changeset that removes dependency on >>> sun.util.logging package from JavaFX code. >>> >>> ???? Bug :? https://bugs.openjdk.java.net/browse/JDK-8195799 >>> ???? Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ >>> >>> ???? Request you to review. >>> >>> Regards, >>> Ajit >>> >> From kevin.rushforth at oracle.com Fri Mar 23 19:42:47 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 23 Mar 2018 12:42:47 -0700 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <08f39c95-67e5-7016-32f0-6cf1c0665ac1@oracle.com> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <676e17c7-8ffe-be71-553e-b4fcff58c1a5@oracle.com> <5AB53E93.8050407@oracle.com> <08f39c95-67e5-7016-32f0-6cf1c0665ac1@oracle.com> Message-ID: <5AB558B7.1090202@oracle.com> mandy chung wrote: > > > On 3/23/18 10:51 AM, Kevin Rushforth wrote: >> Hi Daniel, >> >> Thanks for the review. >> >> I like the idea of removing the unused levels and methods. >> >> As for directly using System.Logger.Level, we have enough usages of >> the Level and convenience logging methods (e.g., "warn", "fine", >> etc.), that I think it's better to file a follow-up issue (to >> minimize the changes and so it would be more feasible to review the >> existing changes). The idea of doing a refactor / rename of the >> convenience methods and level names to match seems like a good one >> for that follow-up JBS issue. >> > > When you do the clean up, I suggest to drop PlatformLogger completely > and directly use System.Logger (in addition to System.Logger.Level) If not too hard, that might be a good way to go. -- Kevin > > Mandy > >> -- Kevin >> >> >> Daniel Fuchs wrote: >>> Hi Ajit, >>> >>> I have two remarks, >>> >>> 1. I wonder if it's wise to keep the old unused levels like e.g. >>> Level.CONFIG in your new PlatformLogger. >>> >>> The sun.util.logging.PlatformLogger had a bridge that allowed >>> it to transfer these levels unchanged to java.logging when >>> java.logging was the backend. >>> >>> Your new PlatformLogger does not have these bridges. >>> Which means that code that might log with Level.CONFIG >>> will in reality log with Level.DEBUG, which will be translated >>> to Level.FINE when java.logging is the backend. >>> >>> So with the old sun.u.l.PlatformLogger, logging with Level.CONFIG >>> would have ended up logging with Level.CONFIG in java.logging, >>> but with your new implementation, this will end up as Level.FINE >>> (as DEBUG maps to FINE when java.logging is the backend). >>> >>> AFAICS - there's no code in JavaFX (at least in the files present >>> in your webrev) that logs with Level.CONFIG. >>> So why not just remove these unused levels from your implementation >>> of PlatformLogger? You certainly don't want new code >>> to start using PlatformLogger::config (as that's actually >>> an alias to DEBUG). >>> The best way of avoiding future usage when there's none >>> today is just to remove these problematic API point. >>> >>> 2. I understand the desire of minimizing the code changes, and >>> introducing a PlatformLogger class that mimics the old >>> sun.util.logging.PlatformLogger certainly achieve this goal. >>> Now the interesting thing is: how many log statements are there >>> throughout the JavaFX code base? >>> >>> If there are not too many - then you might want consider >>> changing them to use directly the levels provided by >>> System.Logger - and then you might want to use the >>> "Refactor -> Rename" option of your IDE to simply >>> rename the methods >>> >>> PlatformLogger::severe to PlatformLogger::error >>> PlatformLogger::fine to PlatformLogger::debug >>> PlatformLogger::finer to PlatformLogger::trace >>> PlatformLogger::finest to PlatformLogger::trace >>> >>> >>> Otherwise looks mostly good - I guess. >>> >>> best regards, >>> >>> -- daniel >>> >>> On 23/03/2018 16:34, Ajit Ghaisas wrote: >>>> Hi Kevin, Mandy and Daniel, >>>> >>>> Please review the changeset that removes dependency on >>>> sun.util.logging package from JavaFX code. >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8195799 >>>> Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ >>>> >>>> Request you to review. >>>> >>>> Regards, >>>> Ajit >>>> >>> > From kevin.rushforth at oracle.com Fri Mar 23 19:47:15 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 23 Mar 2018 12:47:15 -0700 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <13cf6742-1d37-0b40-3214-11a2372cc8a3@oracle.com> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <13cf6742-1d37-0b40-3214-11a2372cc8a3@oracle.com> Message-ID: <5AB559C3.70608@oracle.com> inline mandy chung wrote: > > > On 3/23/18 9:34 AM, Ajit Ghaisas wrote: >> Hi Kevin, Mandy and Daniel, >> >> Please review the changeset that removes dependency on sun.util.logging package from JavaFX code. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8195799 >> Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ >> >> > > buildSrc/addExports > FX modules are compiled together and I don't expect these > --add-exports are needed. I suspect it's because of the boot JDK and > this is a temporary dance? Exactly. It is needed for changes that have been added to module-info.java and are not in the minimum required boot JDK, so that we can build/run apps and tests. > PlatformLogger.java > 150 public static synchronized PlatformLogger getLogger(String > name) { > > This keeps the weak reference to all PlatformLogger created. A > simplification is to return > new PlatformLogger(System.getLogger(name)); > > > System::getLogger should return the same instance if it has been > created. I also suspect the caller of PlatformLogger::getLogger keeps > a strong reference and calls it once. > > I recalled there were some native methods calling the Java API to set > level. It has been a while back since I looked at it and things > miight have changed. Is there such reference any more? The ones that you were thinking of are in javafx.media are not calls to PlatformLogger at all, but calls to a similarly named convenience class in the javafx.media module. > Other than the above comments, this change looks good. Thanks. -- Kevin > > Mandy > > From mike.ennen at gmail.com Fri Mar 23 21:50:07 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 23 Mar 2018 14:50:07 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <5AB3A799.5060202@oracle.com> References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> <5AB19921.3000906@oracle.com> <5AB3A799.5060202@oracle.com> Message-ID: Kevin, I believe I followed all of your suggestions, except the one with a re-usable WritableImage. If you want me to implement that as well, I can, but you seemed unsure about the necessity of it. Hopefully it is easy for you to review using the GitHub PR: https://github.com/javafxports/openjdk-jfx/pull/36 as it takes less effort for me as the manual process of converting to a hg patch and importing it to generate a webrev is somewhat laborious. Once you approve the changes I can of course generate a hg patch, commit, and webrev. Since you suggested the params to be doubles I took the initiative and changed the params "down the line" to the native API calls, where appropriate. What I mean is, take the Mac GlassRobot.m implementation, the native `_mouseMove` implementation uses `CGEventCreateMouseEvent` which expects a CGPoint for the (x,y) location, which uses floats. So in this case the doubles are "down-casted" to floats to interact the native API, and then "up-casted" to doubles when returned by the public Robot class. For other native API implementations the double params are "down-casted" all the way to ints if that's what the native API expects in the following sense: (starts as double) ------> Downcasted to what the native API wants (sometimes int, sometimes float) | <------ Always upcasted to double as that's what public Robot API uses public Robot class <-> private GlassRobot <-> platform-specific Java class (e.g. MacRobot.java) <-> native implementation (e.g. MacRobot.m) This way the values returned by, for example, getMouseX and getMouseY, more closely match the actual values of the system, and the double params given to, for example, mouseMove, are used to provide better accuracy when the native API supports it, but if not, the double is simply casted to an int the extra precision does nothing. In other words, calling robot.mouseMove(75.5, 75.5) will try and pass the extra accuracy along to the native API if it expects it, but if not, won't. Hopefully that makes sense. Thanks! On Thu, Mar 22, 2018 at 5:54 AM, Kevin Rushforth wrote: > > > Michael Ennen wrote: > > Quick question: > > Currently a Robot is created by calling `Application.createRobot` which > delegates > to the underlying platform-specific application class (GtkApplication, > WinApplication, etc.) > via `com.sun.glass.ui.Application.GetApplication().createRobot();` > > > I just meant that the Toolkit class was a convenient place to call > com.sun.glass.ui.Application.GetApplication().createRobot() -- something > like this: > > Toolkit: > > public GlassRobot createRobot() { // or could be abstract > throw new UnsupportedOperationException("not implemented"); > } > > QuantumToolkit: > > public GlassRobot createRobot() { > return com.sun.glass.ui.Application.GetApplication().createRobot(); > } > > The reason for doing it there is because it already has the mechanism for > handling QuantumToolkit versus StubToolkit. Otherwise you wouldn't need the > extra level of indirection. > > -- Kevin > > > You suggest moving this to the Toolkit class? If GtkRobot, WinRobot, etc. > all extend > the abstract base class GlassRobot (the peer), how will Toolkit be able to > instantiate > the correct, platform-specific class? Sorry, I got stuck trying to > implement this part > of your review. The rest is easy for me to follow and will be no problem. > > > On Tue, Mar 20, 2018 at 4:28 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Hi Michael, >> >> Here is some quick feedback. >> >> I think what you have is heading in the right direction as far as the >> public API goes. I'd like to get some feedback from other developers as >> well. I would want to make sure that the API meets the needs of multiple >> developers. >> >> I took a look at the public class and as I may have mentioned earlier, it >> will help to split the API and the implementation even further, by creating >> a peer object as we do for Scene, Stage, etc., rather than having the glass >> platform implementation directly subclass the public Robot class. >> >> Then you can easily delegate to the Glass Robot peer without having any >> implementation leak into the public API (e.g., the overridden create and >> dispose methods). >> >> So what you would have in that case is something more like this: >> >> public final class Robot { >> >> private final GlassRobot peer; >> >> public Robot() { >> // Ensure we have proper permission for creating a robot. >> final SecurityManager sm = System.getSecurityManager(); >> if (sm != null) { >> sm.checkPermission(CREATE_ROBOT_PERMISSION); >> } >> >> Application.checkEventThread(); >> >> peer = Toolkit.createRobot(); >> } >> >> // NOTE: for the rest, the peer can do the thread check >> >> public void keyPress(KeyCode keyCode) { >> peer.keyPress(keyCode); >> } >> >> public void keyRelease(KeyCode keyCode) { >> peer.keyRelease(keyCode); >> } >> >> public final void keyType(KeyCode keyCode) { >> keyPress(keyCode); >> keyRelease(keyCode); >> } >> >> ... >> >> >> And so on. The Toolkit class can return a glass robot "peer" which should >> then only need minor changes (e.g., to the signatures of methods that have >> slightly different types) from the current one. The QuantumToolkit >> implementation of createPeer can construct, initialize, and return the >> GlassRobot instance. The StubToolkit and DummyToolkit implementations can >> throw an UnsuppportedOperationException. >> >> As for the public API, the set of methods you have seem mostly what we >> would want. Here are a few quick thoughts: >> >> void keyPress(KeyCode keyCode); >> void keyRelease(KeyCode keyCode); >> void keyType(KeyCode keyCode); >> >> int getMouseX(); // maybe should return double? >> int getMouseY(); >> >> Point2D getMousePosition(); >> >> void mouseMove(int x, int y); // maybe params should be double? >> >> void mouseMove(Point2D location); >> >> void mousePress(MouseButton button); // This one seems >> redundant...covered by the next method >> void mousePress(MouseButton... buttons); >> >> void mouseRelease(MouseButton button); // This one seems >> redundant...covered by the next method >> void mouseRelease(MouseButton... buttons); >> >> // I don't see the need for this method >> void mouseWheel(int wheelAmt, VerticalDirection direction); >> >> void mouseWheel(int wheelAmt); >> >> Color getPixelColor(int x, int y); // maybe params should be double? >> >> Color getPixelColor(Point2D location); >> >> // Probably the following should return WritableImage to match Snapshot. >> maybe also have a variable that takes a WritableImage to allow caller to >> allocate and reuse (that might overkill in this case)? >> >> Image getScreenCapture(int x, int y, int width, int height); // maybe >> params should be double? >> Image getScreenCapture(int x, int y, int width, int height, boolean >> scaleToFit); // maybe params should be double? >> Image getScreenCapture(Rectangle2D region); >> Image getScreenCapture(Rectangle2D region, boolean scaleToFit); >> >> void getScreenCapture(int x, int y, int width, int height, int[] data); >> // Not sure we need / want this one >> >> The biggest question I have is whether we should follow the pattern of >> the other related public APIs in Screen and Stage and use doubles >> everywhere rather than ints. Also, we will need to see whether there are >> any implications for multiple screens (probably not, but the docs will need >> to specify what coordinates the x, and y values are in). >> >> Hopefully this will spark a discussion. >> >> >> -- Kevin >> >> >> Michael Ennen wrote: >> >> Ping :) >> >> On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> I'll take a look some time after RDP2 of JDK 10. >>> >>> >>> -- Kevin >>> >>> >>> Michael Ennen wrote: >>> >>> Hey Kevin, >>> >>> Hope you had a good holiday. Hopefully you will get some time in the >>> coming weeks >>> to review my work. >>> >>> Thanks! >>> >>> On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> Sure, no problem. One quick comment is that a common way to solve this >>>> is by delegating to an implementation class, which would then be >>>> sub-classes. >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> Michael Ennen wrote: >>>> >>>> I am not trying to be a burden here. I understand that you may not have >>>> time to hand-hold >>>> to this degree. I will try and make progress, sorry for the follow up >>>> question. >>>> >>>> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen >>>> wrote: >>>> >>>>> How can Robot call into the implementation when it is a super class of >>>>> the implementations? >>>>> >>>>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> Michael Ennen wrote: >>>>>> >>>>>> I have a question about how to proceed with the Robot code. >>>>>> >>>>>> The base abstract Robot class is: https://github.com/brcolow >>>>>> /openjfx/blob/master/modules/javafx.graphics/src/main/java/j >>>>>> avafx/scene/robot/Robot.java >>>>>> >>>>>> As you can see for each method, such as "getMouseX()" there is a "_" >>>>>> prefixed method >>>>>> which is abstract and a non-prefixed method: >>>>>> >>>>>> protected abstract int _getMouseX(); >>>>>> >>>>>> public int getMouseX() { >>>>>> Application.checkEventThread(); >>>>>> return _getMouseX(); >>>>>> } >>>>>> >>>>>> I have copied this from the private Robot API. >>>>>> >>>>>> Is there a better way to do this? Would this pass review? >>>>>> >>>>>> >>>>>> Yes there are better ways to do this. No it would not pass review, >>>>>> since this would be leaking implementation into the public API. >>>>>> >>>>>> Rather than copying the public / protected methods from the internal >>>>>> package, it probably makes more sense to start with what a Robot API should >>>>>> look like and then have that call into the implementation (suitably >>>>>> modified so it better matches the public API). For one thing you will then >>>>>> leave the implementation, including the per-platform code, where it belongs >>>>>> -- in glass. The Robot API can be informed by the current implementation, >>>>>> but should not be defined by it. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Thanks very much. >>>>>> >>>>>> >>>>>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth < >>>>>> kevin.rushforth at oracle.com> wrote: >>>>>> >>>>>>> Glad you got the build working. You can post back on this thread >>>>>>> when you are ready. >>>>>>> >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Michael Ennen wrote: >>>>>>> >>>>>>> Correction: >>>>>>> >>>>>>> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>>>> to buildSrc/addExports. >>>>>>> >>>>>>> For posterity :) >>>>>>> >>>>>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen >>>>>>> wrote: >>>>>>> >>>>>>>> Ah, indeed, missed adding "--add-opens >>>>>>>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED" to >>>>>>>> buildSrc/addExports. >>>>>>>> Thanks for the guidance on that. >>>>>>>> >>>>>>>> I will continue to work on this in the GitHub repo and polish it up >>>>>>>> (add javadocs, better method signatures, etc.) and >>>>>>>> even plan on maybe improving the underlying native Robot >>>>>>>> implementations (for example fixing/improving the >>>>>>>> way color profiles are handled for MacRobot). >>>>>>>> >>>>>>>> I will also take a look at "fixing" JemmyFX to use the new public >>>>>>>> API (as well as any other place in the JavaFX code >>>>>>>> base that does). >>>>>>>> >>>>>>>> I was expecting that JDK 11 would be the appropriate time frame, >>>>>>>> especially because it will be the release where >>>>>>>> private APIs will be totally inaccessible, correct? >>>>>>>> >>>>>>>> After I get it in a reasonable state should I post back on this >>>>>>>> mailing list thread or what would be the appropriate >>>>>>>> way? >>>>>>>> >>>>>>>> Thanks Kevin. >>>>>>>> >>>>>>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth < >>>>>>>> kevin.rushforth at oracle.com> wrote: >>>>>>>> >>>>>>>>> This is a limitation of the the way --patch-modules works. You >>>>>>>>> will need to add an entry in: >>>>>>>>> >>>>>>>>> buildSrc/addExports >>>>>>>>> >>>>>>>>> Btw, as for the proposal itself, this might need to be a JEP >>>>>>>>> depending on the scope. In any case, it could be considered in the JDK 11 >>>>>>>>> time frame, but there are several things that need to be worked out before >>>>>>>>> making Robot a public API, including the fact that the JemmyFX framework in >>>>>>>>> the openjfx/jfx/tests directory uses Robot. Once you get a working >>>>>>>>> prototype, it would be interesting to discuss it in more detail. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Michael Ennen wrote: >>>>>>>>> >>>>>>>>> Currently I am stuck with tests not being able to see the new >>>>>>>>> "javafx.scene.robot" module: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Task :systemTests:compileTestJava >>>>>>>>> >>>>>>>>> >>>>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34: >>>>>>>>> error: package javafx.scene.robot is not visible >>>>>>>>> import javafx.scene.robot.Robot; >>>>>>>>> ^ >>>>>>>>> (package javafx.scene.robot is declared in module javafx.graphics, which >>>>>>>>> does not export it) >>>>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33: >>>>>>>>> error: package javafx.scene.robot is not visible >>>>>>>>> import javafx.scene.robot.Robot; >>>>>>>>> >>>>>>>>> I have added: >>>>>>>>> >>>>>>>>> exports javafx.scene.robot; >>>>>>>>> >>>>>>>>> to: modules/javafx.graphics/src/main/java/module-info.java >>>>>>>>> >>>>>>>>> But this does not seem to be enough. >>>>>>>>> >>>>>>>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I am still working on all the necessary changes to actually allow openjfx >>>>>>>>> to compile. >>>>>>>>> Tons to learn in that arena and I know the code as it is written won't >>>>>>>>> totally work. >>>>>>>>> For example one can no longer: >>>>>>>>> >>>>>>>>> #include "com_sun_glass_ui_Robot.h" >>>>>>>>> >>>>>>>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp >>>>>>>>> >>>>>>>>> But I am not sure how those headers are generated and if I can just simply >>>>>>>>> change >>>>>>>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt). >>>>>>>>> >>>>>>>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I have created a (small) proposal (building on the work of Benjamin >>>>>>>>> Gudehaus) about moving some classes in to the public API so that TestFX (a >>>>>>>>> JavaFX UI testing framework) can continue to work with future JDK releases. >>>>>>>>> The somewhat nicely formatted proposal can be found as a Github gist: >>>>>>>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >>>>>>>>> >>>>>>>>> All suggested changes can be found by using Github Compare View: >>>>>>>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 >>>>>>>>> e1f4f1cb8f20430feaa53b6...master >>>>>>>>> >>>>>>>>> But I have copied it to this email for convenience: >>>>>>>>> >>>>>>>>> ----------------------- PROPOSAL ----------------------- >>>>>>>>> >>>>>>>>> TestFX, the JavaFX GUI testing framework currently requires 4 (four) >>>>>>>>> classes that are part of the JDK's private API. They are: >>>>>>>>> >>>>>>>>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op >>>>>>>>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/ >>>>>>>>> java/com/sun/glass/ui/Application.java) >>>>>>>>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx >>>>>>>>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/ >>>>>>>>> com/sun/glass/ui/Pixels.java) >>>>>>>>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/ >>>>>>>>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com >>>>>>>>> /sun/glass/ui/Robot.java) >>>>>>>>> [com.sun.javafx.application.ParametersImpl](http://hg.openjdk.java.net/openjfx/10-dev/rt/file/tip/modules/javafx. >>>>>>>>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java ) >>>>>>>>> >>>>>>>>> In order to compile the project with Java 9, we use the following flags: >>>>>>>>> >>>>>>>>> ```sh >>>>>>>>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx >>>>>>>>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> If the --add-exports flags are disabled in a future Java release TestFX >>>>>>>>> will require these four classes to be moved into the public API to >>>>>>>>> continue working. >>>>>>>>> >>>>>>>>> While these classes are probably not very useful for applications to use >>>>>>>>> directly, any JavaFX application wanting to write UI tests will most >>>>>>>>> likely >>>>>>>>> use TestFX and thus they will indirectly be using these classes. >>>>>>>>> >>>>>>>>> JavaFX internal tests also use these classes for essentially the same >>>>>>>>> purpose (UI tests). >>>>>>>>> >>>>>>>>> ### Details of Usage For Each Private API Class >>>>>>>>> >>>>>>>>> #### com.sun.javafx.application.ParametersImpl >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> ParametersImpl parameters = new ParametersImpl(applicationArgs); >>>>>>>>> ParametersImpl.registerParameters(application, parameters); >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> The parameters are set on a constructed Application. >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> >>>>>>>>> `javafx.application.Application`: >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> /** >>>>>>>>> * Sets the parameters for this Application. >>>>>>>>> * >>>>>>>>> *

>>>>>>>>> * NOTE: this method should not be called from the Application >>>>>>>>> constructor, >>>>>>>>> * as it will return null. It may be called in the init() method or any >>>>>>>>> * time after that. >>>>>>>>> *

>>>>>>>>> * >>>>>>>>> * @param parameters the parameters to set for this Application >>>>>>>>> */ >>>>>>>>> public final Parameters setParameters(String... parameters) { >>>>>>>>> ParametersImpl parameters = new ParametersImpl(parameters); >>>>>>>>> ParametersImpl.registerParameters(this, parameters); >>>>>>>>> } >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> #### com.sun.glass.ui.Application >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> return Application.GetApplication().createRobot(); >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> The Application class is used to instantiate a Robot. >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> >>>>>>>>> `javafx.application.Application`: >>>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>>> x.graphics/src/main/java/javafx/application/Application.java#L527 >>>>>>>>> >>>>>>>>> #### com.sun.glass.ui.Pixels >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> ```java >>>>>>>>> @Override >>>>>>>>> public Image getCaptureRegion(Rectangle2D region) { >>>>>>>>> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> { >>>>>>>>> Pixels glassPixels = useRobot().getScreenCapture( >>>>>>>>> (int) region.getMinX(), (int) region.getMinY(), >>>>>>>>> (int) region.getWidth(), (int) region.getHeight() >>>>>>>>> ); >>>>>>>>> return convertFromGlassPixels(glassPixels); >>>>>>>>> }); >>>>>>>>> } >>>>>>>>> >>>>>>>>> private Image convertFromGlassPixels(Pixels glassPixels) { >>>>>>>>> int width = glassPixels.getWidth(); >>>>>>>>> int height = glassPixels.getHeight(); >>>>>>>>> WritableImage image = new WritableImage(width, height); >>>>>>>>> >>>>>>>>> int bytesPerComponent = glassPixels.getBytesPerComponent(); >>>>>>>>> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) { >>>>>>>>> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels(); >>>>>>>>> writeIntBufferToImage(intBuffer, image); >>>>>>>>> } >>>>>>>>> >>>>>>>>> return image; >>>>>>>>> } >>>>>>>>> >>>>>>>>> private void writeIntBufferToImage(IntBuffer intBuffer, >>>>>>>>> WritableImage image) { >>>>>>>>> PixelWriter pixelWriter = image.getPixelWriter(); >>>>>>>>> double width = image.getWidth(); >>>>>>>>> double height = image.getHeight(); >>>>>>>>> >>>>>>>>> for (int y = 0; y < height; y++) { >>>>>>>>> for (int x = 0; x < width; x++) { >>>>>>>>> int argb = intBuffer.get(); >>>>>>>>> pixelWriter.setArgb(x, y, argb); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> Pixels is used to create a screen capture. >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> >>>>>>>>> Bypass needing to expose the Pixels class to the public API by >>>>>>>>> changing the getScreenCapture method of Robot - that is, changing: >>>>>>>>> >>>>>>>>> `public Pixels getScreenCapture(int x, int y, int width, int height)` >>>>>>>>> >>>>>>>>> to: >>>>>>>>> >>>>>>>>> `public Image getScreenCapture(int x, int y, int width, int height)` >>>>>>>>> >>>>>>>>> #### com.sun.glass.ui.Robot >>>>>>>>> >>>>>>>>> ##### TestFX Usage >>>>>>>>> >>>>>>>>> Essentially every method of Robot is used: >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> public void keyPress(int code) >>>>>>>>> public void keyRelease(int code) >>>>>>>>> public int getMouseX() >>>>>>>>> public int getMouseY() >>>>>>>>> public void mouseMove(int x, int y) >>>>>>>>> public void mousePress(int buttons) >>>>>>>>> public void mouseRelease(int buttons) >>>>>>>>> public void mouseWheel(int wheelAmt) >>>>>>>>> public int getPixelColor(int x, int y) >>>>>>>>> public Pixels getScreenCapture(int x, int y, int width, int height) >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> ##### Suggested Public API Replacement >>>>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Michael Ennen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Michael Ennen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Michael Ennen >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Michael Ennen >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>>> >>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>>> >>>> >>> >>> >>> -- >>> Michael Ennen >>> >>> >> >> >> -- >> Michael Ennen >> >> > > > -- > Michael Ennen > > -- Michael Ennen From kevin.rushforth at oracle.com Fri Mar 23 21:56:46 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 23 Mar 2018 14:56:46 -0700 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> Message-ID: <5AB5781E.3020705@oracle.com> The only additional comments I have are couple typos and a white-space issue: 1. There is a typo in the Copyright year (201 rather than 2018) in the following two files: modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java modules/javafx.graphics/src/main/java/javafx/scene/Scene.java 2. There are tab characters in the following file that need to be changed to spaces: modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java public static void setUpClass() { >>> System.err.println("SelectBindingTest : log messages are expected from these tests."); All my testing looks good. With this patch I am now able to run applications with OpenJDK 10 + a standalone FX SDK with no qualified exports on the command line (as long as it doesn't use Swing interop). -- Kevin Ajit Ghaisas wrote: > Hi Kevin, Mandy and Daniel, > > Please review the changeset that removes dependency on sun.util.logging package from JavaFX code. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8195799 > Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ > > Request you to review. > > Regards, > Ajit > From swpalmer at gmail.com Sun Mar 25 01:11:47 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 24 Mar 2018 21:11:47 -0400 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> <5AB19921.3000906@oracle.com> <5AB3A799.5060202@oracle.com> Message-ID: <6F1667A4-E617-4C62-A6CD-8CE0AB463E24@gmail.com> > On Mar 23, 2018, at 5:50 PM, Michael Ennen wrote: > > Kevin, > > I believe I followed all of your suggestions, except the one with a > re-usable WritableImage. > If you want me to implement that as well, I can, but you seemed unsure > about the necessity > of it. I think it should be included to reduce garbage generated in a case where repeated captures is used. Such as a desktop sharing application, a screen recorder, etc. It would also be consistent with the node.snapshot API. In fact, I would just have the version that takes a WriteableImage and match the behaviour of node.snapshot. Scott From mike.ennen at gmail.com Sun Mar 25 03:27:22 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Sat, 24 Mar 2018 20:27:22 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <6F1667A4-E617-4C62-A6CD-8CE0AB463E24@gmail.com> References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> <5AB19921.3000906@oracle.com> <5AB3A799.5060202@oracle.com> <6F1667A4-E617-4C62-A6CD-8CE0AB463E24@gmail.com> Message-ID: Sounds like a good idea to me to only have `getScreenCapture` methods that have a WritableImage parameter which can be `null` which means a new WritableImage will be created otherwise the given one is re-used, as in Scene.snapshot and Node.snapshot. What are your thoughts on this, Kevin? On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer wrote: > > > On Mar 23, 2018, at 5:50 PM, Michael Ennen wrote: > > Kevin, > > I believe I followed all of your suggestions, except the one with a > re-usable WritableImage. > If you want me to implement that as well, I can, but you seemed unsure > about the necessity > of it. > > > I think it should be included to reduce garbage generated in a case where > repeated captures is used. Such as a desktop sharing application, a screen > recorder, etc. > It would also be consistent with the node.snapshot API. > > In fact, I would just have the version that takes a WriteableImage and > match the behaviour of node.snapshot. > > Scott > > -- Michael Ennen From nlisker at gmail.com Sun Mar 25 16:22:53 2018 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 25 Mar 2018 19:22:53 +0300 Subject: JDK-8199560: Dynamic evaluation for binding.When In-Reply-To: <5AAC47A9.20004@oracle.com> References: <5AAC47A9.20004@oracle.com> Message-ID: 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 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 johan.vos at gluonhq.com Mon Mar 26 08:50:03 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 26 Mar 2018 08:50:03 +0000 Subject: modules versus SDK's Message-ID: Hi, I want to start a discussion on distributing JavaFX as an SDK versus distributing its modules via the traditional build and distribution mechanisms. Personally, I think relying on an SDK is too much a barrier. It requires users to manually download software from the exact right place, and "install" it on the exact right target. If a version changes, you have to manage that manually. That is how JavaFX was distributed before it was bundled with the JDK, so it makes sense to provide that option (although me and others will probably never use that). Today however, when a developer has a dependency on a library or framework (including property files and native code), he uses his build tools (e.g. maven/gradle) to manage the download/install//update of those libaries/frameworks. If you rely on Spring, Apache Commons, slf4j,... you don't download those SDK's but you point to the group-name-version triplet in your pom.xml or build.gradle file. I don't see why JavaFX would be different here. When someone is new to JavaFX, or is considering JavaFX, I think chances on success will be much bigger if that person simply needs to add e.g. dependencies { compile: 'javafx:javax.graphics:11.0.0' } to his build.gradle and then rely on gradle (or maven) and jcenter/sonatype to make sure the correct version with all its dependencies are installed (in a maven/gradle local cache) - Johan From tbee at tbee.org Mon Mar 26 08:58:57 2018 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 26 Mar 2018 10:58:57 +0200 Subject: modules versus SDK's In-Reply-To: References: Message-ID: <03370bd5-6c29-3e07-d03c-83837059e478@tbee.org> I totally assumed that, when JavaFX is separated out, it will distributed as an artifact on Maven central (or similar) so it can be included like a dependency. Feels like a no brainer? On 26-3-2018 10:50, Johan Vos wrote: > Hi, > > I want to start a discussion on distributing JavaFX as an SDK versus > distributing its modules via the traditional build and distribution > mechanisms. > > Personally, I think relying on an SDK is too much a barrier. It requires > users to manually download software from the exact right place, and > "install" it on the exact right target. If a version changes, you have to > manage that manually. > > That is how JavaFX was distributed before it was bundled with the JDK, so > it makes sense to provide that option (although me and others will probably > never use that). > > Today however, when a developer has a dependency on a library or framework > (including property files and native code), he uses his build tools (e.g. > maven/gradle) to manage the download/install//update of those > libaries/frameworks. > If you rely on Spring, Apache Commons, slf4j,... you don't download those > SDK's but you point to the group-name-version triplet in your pom.xml or > build.gradle file. I don't see why JavaFX would be different here. > > When someone is new to JavaFX, or is considering JavaFX, I think chances on > success will be much bigger if that person simply needs to add e.g. > dependencies { > compile: 'javafx:javax.graphics:11.0.0' > } > to his build.gradle and then rely on gradle (or maven) and jcenter/sonatype > to make sure the correct version with all its dependencies are installed > (in a maven/gradle local cache) > > - Johan From sven.reimers at gmail.com Mon Mar 26 09:37:55 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 26 Mar 2018 09:37:55 +0000 Subject: modules versus SDK's In-Reply-To: <03370bd5-6c29-3e07-d03c-83837059e478@tbee.org> References: <03370bd5-6c29-3e07-d03c-83837059e478@tbee.org> Message-ID: +1 for getting it the "normal" way.. Sven Tom Eugelink schrieb am Mo., 26. M?rz 2018, 10:59: > I totally assumed that, when JavaFX is separated out, it will distributed > as an artifact on Maven central (or similar) so it can be included like a > dependency. Feels like a no brainer? > > > On 26-3-2018 10:50, Johan Vos wrote: > > Hi, > > > > I want to start a discussion on distributing JavaFX as an SDK versus > > distributing its modules via the traditional build and distribution > > mechanisms. > > > > Personally, I think relying on an SDK is too much a barrier. It requires > > users to manually download software from the exact right place, and > > "install" it on the exact right target. If a version changes, you have to > > manage that manually. > > > > That is how JavaFX was distributed before it was bundled with the JDK, so > > it makes sense to provide that option (although me and others will > probably > > never use that). > > > > Today however, when a developer has a dependency on a library or > framework > > (including property files and native code), he uses his build tools (e.g. > > maven/gradle) to manage the download/install//update of those > > libaries/frameworks. > > If you rely on Spring, Apache Commons, slf4j,... you don't download those > > SDK's but you point to the group-name-version triplet in your pom.xml or > > build.gradle file. I don't see why JavaFX would be different here. > > > > When someone is new to JavaFX, or is considering JavaFX, I think chances > on > > success will be much bigger if that person simply needs to add e.g. > > dependencies { > > compile: 'javafx:javax.graphics:11.0.0' > > } > > to his build.gradle and then rely on gradle (or maven) and > jcenter/sonatype > > to make sure the correct version with all its dependencies are installed > > (in a maven/gradle local cache) > > > > - Johan > > > From nlisker at gmail.com Mon Mar 26 09:52:45 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 26 Mar 2018 12:52:45 +0300 Subject: OpenJFX GitHub mirror Message-ID: 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 info at michaelhoffer.de Mon Mar 26 11:00:33 2018 From: info at michaelhoffer.de (Michael Hoffer) Date: Mon, 26 Mar 2018 13:00:33 +0200 Subject: modules versus SDK's In-Reply-To: <03370bd5-6c29-3e07-d03c-83837059e478@tbee.org> References: <03370bd5-6c29-3e07-d03c-83837059e478@tbee.org> Message-ID: Hi Johan, hi all, in my opinion SDKs are tolerable for providing the fundamental layers of infrastructure. But other dependencies should be lightweight and use the default channels for providing dependencies. There should be no difference between consuming JavaFX and let's say CommonsIO as dependencies. I think Qt is a good example why SDKs are not the ideal solution. While on Linux Qt is provided as a set of packages (e.g. rpm and deb) it is common to download the SDK on Windows and macOS. From my experience with students this sets an unnecessarily high barrier. If you don't know the technology so well most people download all sub-components just to get rid of any dependency problems. This leads to huge junks of unnecessary dependencies in the GB range. SDKs are easy to install if the come as a monolithic package but usually don't integrate well with well-established ways of providing and consuming dependencies. I think a Wiki page reads much nicer if it recommends to add simply add a dependency like compile: 'javafx:javax.graphics:11.0.0' instead of explaining where to download the SDK, setting JAVAFX_HOME etc. Regards, Michael -- Dr. Michael Hoffer Twitter: @mihosoft Webpage: www.mihosoft.eu Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) Goethe-Universit?t Kettenhofweg 139 60325 Frankfurt am Main phone: +49 69 798 25254 info at michaelhoffer.de 2018-03-26 10:58 GMT+02:00 Tom Eugelink : > I totally assumed that, when JavaFX is separated out, it will distributed > as an artifact on Maven central (or similar) so it can be included like a > dependency. Feels like a no brainer? > > > > On 26-3-2018 10:50, Johan Vos wrote: > >> Hi, >> >> I want to start a discussion on distributing JavaFX as an SDK versus >> distributing its modules via the traditional build and distribution >> mechanisms. >> >> Personally, I think relying on an SDK is too much a barrier. It requires >> users to manually download software from the exact right place, and >> "install" it on the exact right target. If a version changes, you have to >> manage that manually. >> >> That is how JavaFX was distributed before it was bundled with the JDK, so >> it makes sense to provide that option (although me and others will >> probably >> never use that). >> >> Today however, when a developer has a dependency on a library or framework >> (including property files and native code), he uses his build tools (e.g. >> maven/gradle) to manage the download/install//update of those >> libaries/frameworks. >> If you rely on Spring, Apache Commons, slf4j,... you don't download those >> SDK's but you point to the group-name-version triplet in your pom.xml or >> build.gradle file. I don't see why JavaFX would be different here. >> >> When someone is new to JavaFX, or is considering JavaFX, I think chances >> on >> success will be much bigger if that person simply needs to add e.g. >> dependencies { >> compile: 'javafx:javax.graphics:11.0.0' >> } >> to his build.gradle and then rely on gradle (or maven) and >> jcenter/sonatype >> to make sure the correct version with all its dependencies are installed >> (in a maven/gradle local cache) >> >> - Johan >> > > > From mario at datenwort.at Mon Mar 26 11:28:44 2018 From: mario at datenwort.at (Mario Ivankovits) Date: Mon, 26 Mar 2018 11:28:44 +0000 Subject: modules versus SDK's In-Reply-To: References: Message-ID: <194249A2-9ACE-4F5A-BFFE-915EC0C0AF20@datenwort.at> +1 on providing JavaFX as ?simple? dependency. Question is how to deal with the native libraries. Provide an artifact per platform? compile: 'javafx:javax.graphics-osx:11.0.0' compile: 'javafx:javax.graphics-win:11.0.0' compile: 'javafx:javax.graphics-pi:11.0.0? These bundles might just contain the native libraries and each of them depend on e.g. compile: 'javafx:javax.graphics:11.0.0? which contains just the JavaFX Java sources. That way one can build a cross-platfrom bundle with all native libraries or a slim bundle for a specific target. Best regards, Mario > Am 26.03.2018 um 10:50 schrieb Johan Vos : > > Hi, > > I want to start a discussion on distributing JavaFX as an SDK versus > distributing its modules via the traditional build and distribution > mechanisms. > > Personally, I think relying on an SDK is too much a barrier. It requires > users to manually download software from the exact right place, and > "install" it on the exact right target. If a version changes, you have to > manage that manually. > > That is how JavaFX was distributed before it was bundled with the JDK, so > it makes sense to provide that option (although me and others will probably > never use that). > > Today however, when a developer has a dependency on a library or framework > (including property files and native code), he uses his build tools (e.g. > maven/gradle) to manage the download/install//update of those > libaries/frameworks. > If you rely on Spring, Apache Commons, slf4j,... you don't download those > SDK's but you point to the group-name-version triplet in your pom.xml or > build.gradle file. I don't see why JavaFX would be different here. > > When someone is new to JavaFX, or is considering JavaFX, I think chances on > success will be much bigger if that person simply needs to add e.g. > dependencies { > compile: 'javafx:javax.graphics:11.0.0' > } > to his build.gradle and then rely on gradle (or maven) and jcenter/sonatype > to make sure the correct version with all its dependencies are installed > (in a maven/gradle local cache) > > - Johan From ajit.ghaisas at oracle.com Mon Mar 26 11:36:15 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Mon, 26 Mar 2018 04:36:15 -0700 (PDT) Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <5AB5781E.3020705@oracle.com> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <5AB5781E.3020705@oracle.com> Message-ID: Thanks all for the review. I have addressed the review comments in - http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/ The changes are - 1. Addressed the (c) year inaccuracies in files - modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java modules/javafx.graphics/src/main/java/javafx/scene/Scene.java 2. Removed tabs from modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java 3. Removed unused methods from com.sun.javafx.logging.PlatformLogger class. Also, I have created a new bug JDK-8200236 to address some of the valid suggestions from Mandy and Daniel. Request you to review the new webrev. Regards, Ajit -----Original Message----- From: Kevin Rushforth Sent: Saturday, March 24, 2018 3:27 AM To: Ajit Ghaisas Cc: Mandy Chung; Daniel Fuchs; openjfx-dev at openjdk.java.net Subject: Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules The only additional comments I have are couple typos and a white-space issue: 1. There is a typo in the Copyright year (201 rather than 2018) in the following two files: modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java modules/javafx.graphics/src/main/java/javafx/scene/Scene.java 2. There are tab characters in the following file that need to be changed to spaces: modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java public static void setUpClass() { >>> System.err.println("SelectBindingTest : log messages are expected from these tests."); All my testing looks good. With this patch I am now able to run applications with OpenJDK 10 + a standalone FX SDK with no qualified exports on the command line (as long as it doesn't use Swing interop). -- Kevin Ajit Ghaisas wrote: > Hi Kevin, Mandy and Daniel, > > Please review the changeset that removes dependency on sun.util.logging package from JavaFX code. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8195799 > Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ > > Request you to review. > > Regards, > Ajit > From org.openjdk at io7m.com Mon Mar 26 11:41:50 2018 From: org.openjdk at io7m.com (Mark Raynsford) Date: Mon, 26 Mar 2018 11:41:50 +0000 Subject: modules versus SDK's In-Reply-To: <194249A2-9ACE-4F5A-BFFE-915EC0C0AF20@datenwort.at> References: <194249A2-9ACE-4F5A-BFFE-915EC0C0AF20@datenwort.at> Message-ID: <20180326114150.4026b26c@copperhead.int.arc7.info> On 2018-03-26T11:28:44 +0000 Mario Ivankovits wrote: > +1 on providing JavaFX as ?simple? dependency. > > Question is how to deal with the native libraries. Provide an artifact per platform? Take a look at how LWJGL handles it: http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.lwjgl%22 We repack those artifacts into OSGi bundles in an automated fashion too: https://github.com/LWJGL/lwjgl3-osgi -- Mark Raynsford | http://www.io7m.com From daniel.fuchs at oracle.com Mon Mar 26 13:10:29 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 26 Mar 2018 14:10:29 +0100 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <5AB5781E.3020705@oracle.com> Message-ID: Hi Ajit, Looks good to me. I obviously didn't review the build changes. best regards, -- daniel On 26/03/2018 12:36, Ajit Ghaisas wrote: > Thanks all for the review. > > I have addressed the review comments in -http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/ > > The changes are - > 1. Addressed the (c) year inaccuracies in files - > modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java > > 2. Removed tabs from modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java > 3. Removed unused methods from com.sun.javafx.logging.PlatformLogger class. > > Also, I have created a new bug JDK-8200236 to address some of the valid suggestions from Mandy and Daniel. > > Request you to review the new webrev. > > Regards, > Ajit From johan.vos at gluonhq.com Mon Mar 26 13:37:11 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 26 Mar 2018 13:37:11 +0000 Subject: OpenJFX GitHub mirror In-Reply-To: References: Message-ID: 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 Mon Mar 26 14:54:39 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 26 Mar 2018 07:54:39 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> <5AB19921.3000906@oracle.com> <5AB3A799.5060202@oracle.com> <6F1667A4-E617-4C62-A6CD-8CE0AB463E24@gmail.com> Message-ID: <5AB909AF.9040201@oracle.com> Seems good to me, too. -- Kevin Michael Ennen wrote: > Sounds like a good idea to me to only have `getScreenCapture` methods > that have a WritableImage parameter which can be `null` which means a > new WritableImage will be created otherwise the given one is re-used, as > in Scene.snapshot and Node.snapshot. What are your thoughts on this, > Kevin? > > On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer > wrote: > > > >> On Mar 23, 2018, at 5:50 PM, Michael Ennen > > wrote: >> >> Kevin, >> >> I believe I followed all of your suggestions, except the one with a >> re-usable WritableImage. >> If you want me to implement that as well, I can, but you seemed >> unsure >> about the necessity >> of it. > > I think it should be included to reduce garbage generated in a > case where repeated captures is used. Such as a desktop sharing > application, a screen recorder, etc. > It would also be consistent with the node.snapshot API. > > In fact, I would just have the version that takes a WriteableImage > and match the behaviour of node.snapshot. > > Scott > > > > > -- > Michael Ennen From paulrussell70 at gmail.com Mon Mar 26 17:21:37 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Mon, 26 Mar 2018 18:21:37 +0100 Subject: modules versus SDK's Message-ID: > > > (including property files and native code), he uses his build tools (e.g. > > maven/gradle) to manage the download/install//update of those > > libaries/frameworks. > > If you rely on Spring, Apache Commons, slf4j,... you don't download those > > SDK's but you point to the group-name-version triplet in your pom.xml or > > build.gradle file. I don't see why JavaFX would be different here. > +1. It would be nice - if it's at all possible. From mandy.chung at oracle.com Mon Mar 26 17:30:43 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 26 Mar 2018 10:30:43 -0700 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <5AB5781E.3020705@oracle.com> Message-ID: You don't need the loggers map and getLogger method can simply return ???? return new PlatformLogger(System.getLogger(name)); Other than this, looks fine. Mandy On 3/26/18 4:36 AM, Ajit Ghaisas wrote: > Thanks all for the review. > > I have addressed the review comments in - http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/ > > The changes are - > 1. Addressed the (c) year inaccuracies in files - > modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java > > 2. Removed tabs from modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java > 3. Removed unused methods from com.sun.javafx.logging.PlatformLogger class. > > Also, I have created a new bug JDK-8200236 to address some of the valid suggestions from Mandy and Daniel. > > Request you to review the new webrev. > > Regards, > Ajit > > -----Original Message----- > From: Kevin Rushforth > Sent: Saturday, March 24, 2018 3:27 AM > To: Ajit Ghaisas > Cc: Mandy Chung; Daniel Fuchs; openjfx-dev at openjdk.java.net > Subject: Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules > > The only additional comments I have are couple typos and a white-space > issue: > > 1. There is a typo in the Copyright year (201 rather than 2018) in the following two files: > > modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java > > > 2. There are tab characters in the following file that need to be changed to spaces: > > modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java > public static void setUpClass() { > >>> System.err.println("SelectBindingTest : log messages are > expected from these tests."); > > > All my testing looks good. With this patch I am now able to run applications with OpenJDK 10 + a standalone FX SDK with no qualified exports on the command line (as long as it doesn't use Swing interop). > > -- Kevin > > > Ajit Ghaisas wrote: >> Hi Kevin, Mandy and Daniel, >> >> Please review the changeset that removes dependency on sun.util.logging package from JavaFX code. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8195799 >> Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ >> >> Request you to review. >> >> Regards, >> Ajit >> From nlisker at gmail.com Mon Mar 26 20:00:11 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 26 Mar 2018 23:00:11 +0300 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <5AB909AF.9040201@oracle.com> References: <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> <5AB19921.3000906@oracle.com> <5AB3A799.5060202@oracle.com> <6F1667A4-E617-4C62-A6CD-8CE0AB463E24@gmail.com> <5AB909AF.9040201@oracle.com> Message-ID: I'm thinking about the addition of a public method for mouse click, which is mouse press and then mouse release - the parallel for key typed. Is it worth? - Nir On Mon, Mar 26, 2018 at 5:54 PM, Kevin Rushforth wrote: > Seems good to me, too. > > -- Kevin > > > Michael Ennen wrote: > >> Sounds like a good idea to me to only have `getScreenCapture` methods >> that have a WritableImage parameter which can be `null` which means a >> new WritableImage will be created otherwise the given one is re-used, as >> in Scene.snapshot and Node.snapshot. What are your thoughts on this, >> Kevin? >> >> On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer > > wrote: >> >> >> >> On Mar 23, 2018, at 5:50 PM, Michael Ennen >> > wrote: >>> >>> Kevin, >>> >>> I believe I followed all of your suggestions, except the one with a >>> re-usable WritableImage. >>> If you want me to implement that as well, I can, but you seemed >>> unsure >>> about the necessity >>> of it. >>> >> >> I think it should be included to reduce garbage generated in a >> case where repeated captures is used. Such as a desktop sharing >> application, a screen recorder, etc. >> It would also be consistent with the node.snapshot API. >> >> In fact, I would just have the version that takes a WriteableImage >> and match the behaviour of node.snapshot. >> >> Scott >> >> >> >> >> -- >> Michael Ennen >> > From kevin.rushforth at oracle.com Mon Mar 26 20:46:07 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 26 Mar 2018 13:46:07 -0700 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <5AB5781E.3020705@oracle.com> Message-ID: <5AB95C0F.9040004@oracle.com> It doesn't seem harmful to keep the current implementation. This seems better to leave for the follow-on JBS issue (JDK-8200236) unless there something I am missing. -- Kevin mandy chung wrote: > You don't need the loggers map and getLogger method can simply return > return new PlatformLogger(System.getLogger(name)); > > Other than this, looks fine. > > Mandy > > > On 3/26/18 4:36 AM, Ajit Ghaisas wrote: >> Thanks all for the review. >> >> I have addressed the review comments in - http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/ >> >> The changes are - >> 1. Addressed the (c) year inaccuracies in files - >> modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java >> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java >> >> 2. Removed tabs from modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java >> 3. Removed unused methods from com.sun.javafx.logging.PlatformLogger class. >> >> Also, I have created a new bug JDK-8200236 to address some of the valid suggestions from Mandy and Daniel. >> >> Request you to review the new webrev. >> >> Regards, >> Ajit >> >> -----Original Message----- >> From: Kevin Rushforth >> Sent: Saturday, March 24, 2018 3:27 AM >> To: Ajit Ghaisas >> Cc: Mandy Chung; Daniel Fuchs; openjfx-dev at openjdk.java.net >> Subject: Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules >> >> The only additional comments I have are couple typos and a white-space >> issue: >> >> 1. There is a typo in the Copyright year (201 rather than 2018) in the following two files: >> >> modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java >> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java >> >> >> 2. There are tab characters in the following file that need to be changed to spaces: >> >> modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java >> public static void setUpClass() { >> >>> System.err.println("SelectBindingTest : log messages are >> expected from these tests."); >> >> >> All my testing looks good. With this patch I am now able to run applications with OpenJDK 10 + a standalone FX SDK with no qualified exports on the command line (as long as it doesn't use Swing interop). >> >> -- Kevin >> >> >> Ajit Ghaisas wrote: >> >>> Hi Kevin, Mandy and Daniel, >>> >>> Please review the changeset that removes dependency on sun.util.logging package from JavaFX code. >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8195799 >>> Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ >>> >>> Request you to review. >>> >>> Regards, >>> Ajit >>> >>> > From kevin.rushforth at oracle.com Mon Mar 26 20:46:50 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 26 Mar 2018 13:46:50 -0700 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <5AB5781E.3020705@oracle.com> Message-ID: <5AB95C3A.70400@oracle.com> This looks fine to me now. -- Kevin Ajit Ghaisas wrote: > Thanks all for the review. > > I have addressed the review comments in - http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/ > > The changes are - > 1. Addressed the (c) year inaccuracies in files - > modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java > > 2. Removed tabs from modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java > 3. Removed unused methods from com.sun.javafx.logging.PlatformLogger class. > > Also, I have created a new bug JDK-8200236 to address some of the valid suggestions from Mandy and Daniel. > > Request you to review the new webrev. > > Regards, > Ajit > > -----Original Message----- > From: Kevin Rushforth > Sent: Saturday, March 24, 2018 3:27 AM > To: Ajit Ghaisas > Cc: Mandy Chung; Daniel Fuchs; openjfx-dev at openjdk.java.net > Subject: Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules > > The only additional comments I have are couple typos and a white-space > issue: > > 1. There is a typo in the Copyright year (201 rather than 2018) in the following two files: > > modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java > > > 2. There are tab characters in the following file that need to be changed to spaces: > > modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java > public static void setUpClass() { > >>> System.err.println("SelectBindingTest : log messages are > expected from these tests."); > > > All my testing looks good. With this patch I am now able to run applications with OpenJDK 10 + a standalone FX SDK with no qualified exports on the command line (as long as it doesn't use Swing interop). > > -- Kevin > > > Ajit Ghaisas wrote: > >> Hi Kevin, Mandy and Daniel, >> >> Please review the changeset that removes dependency on sun.util.logging package from JavaFX code. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8195799 >> Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ >> >> Request you to review. >> >> Regards, >> Ajit >> >> From kevin.rushforth at oracle.com Mon Mar 26 20:58:54 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 26 Mar 2018 13:58:54 -0700 Subject: modules versus SDK's In-Reply-To: References: Message-ID: <5AB95F0E.9050206@oracle.com> Ultimately, I think you are right that a standalone JavaFX needs to be discoverable and usable via a dependency manager like gradle or maven. From the discussion, it seems most others agree. I note that this doesn't preclude also making a zip bundle available for developers who want to download and unzip JavaFX to compile or run against (i.e., I don't think it is an "either-or" choice). It probably means that it isn't worth spending much time on installers, etc -- just a zip bundle with the bits is probably good enough for the SDK. -- Kevin Johan Vos wrote: > Hi, > > I want to start a discussion on distributing JavaFX as an SDK versus > distributing its modules via the traditional build and distribution > mechanisms. > > Personally, I think relying on an SDK is too much a barrier. It requires > users to manually download software from the exact right place, and > "install" it on the exact right target. If a version changes, you have to > manage that manually. > > That is how JavaFX was distributed before it was bundled with the JDK, so > it makes sense to provide that option (although me and others will probably > never use that). > > Today however, when a developer has a dependency on a library or framework > (including property files and native code), he uses his build tools (e.g. > maven/gradle) to manage the download/install//update of those > libaries/frameworks. > If you rely on Spring, Apache Commons, slf4j,... you don't download those > SDK's but you point to the group-name-version triplet in your pom.xml or > build.gradle file. I don't see why JavaFX would be different here. > > When someone is new to JavaFX, or is considering JavaFX, I think chances on > success will be much bigger if that person simply needs to add e.g. > dependencies { > compile: 'javafx:javax.graphics:11.0.0' > } > to his build.gradle and then rely on gradle (or maven) and jcenter/sonatype > to make sure the correct version with all its dependencies are installed > (in a maven/gradle local cache) > > - Johan > From mike.ennen at gmail.com Mon Mar 26 21:16:41 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 26 Mar 2018 14:16:41 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> <5AB19921.3000906@oracle.com> <5AB3A799.5060202@oracle.com> <6F1667A4-E617-4C62-A6CD-8CE0AB463E24@gmail.com> <5AB909AF.9040201@oracle.com> Message-ID: Sounds like a reasonable idea to me. On Mon, Mar 26, 2018 at 1:00 PM, Nir Lisker wrote: > I'm thinking about the addition of a public method for mouse click, which > is mouse press and then mouse release - the parallel for key typed. Is it > worth? > > - Nir > > On Mon, Mar 26, 2018 at 5:54 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Seems good to me, too. >> >> -- Kevin >> >> >> Michael Ennen wrote: >> >>> Sounds like a good idea to me to only have `getScreenCapture` methods >>> that have a WritableImage parameter which can be `null` which means a >>> new WritableImage will be created otherwise the given one is re-used, as >>> in Scene.snapshot and Node.snapshot. What are your thoughts on this, >>> Kevin? >>> >>> On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer >> > wrote: >>> >>> >>> >>> On Mar 23, 2018, at 5:50 PM, Michael Ennen >>> > wrote: >>>> >>>> Kevin, >>>> >>>> I believe I followed all of your suggestions, except the one with a >>>> re-usable WritableImage. >>>> If you want me to implement that as well, I can, but you seemed >>>> unsure >>>> about the necessity >>>> of it. >>>> >>> >>> I think it should be included to reduce garbage generated in a >>> case where repeated captures is used. Such as a desktop sharing >>> application, a screen recorder, etc. >>> It would also be consistent with the node.snapshot API. >>> >>> In fact, I would just have the version that takes a WriteableImage >>> and match the behaviour of node.snapshot. >>> >>> Scott >>> >>> >>> >>> >>> -- >>> Michael Ennen >>> >> > -- Michael Ennen From kevin.rushforth at oracle.com Mon Mar 26 21:25:27 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 26 Mar 2018 14:25:27 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> <5AB19921.3000906@oracle.com> <5AB3A799.5060202@oracle.com> <6F1667A4-E617-4C62-A6CD-8CE0AB463E24@gmail.com> <5AB909AF.9040201@oracle.com> Message-ID: <5AB96547.8080204@oracle.com> Seems a reasonable addition to me, too. -- Kevin Michael Ennen wrote: > Sounds like a reasonable idea to me. > > On Mon, Mar 26, 2018 at 1:00 PM, Nir Lisker wrote: > > >> I'm thinking about the addition of a public method for mouse click, which >> is mouse press and then mouse release - the parallel for key typed. Is it >> worth? >> >> - Nir >> >> On Mon, Mar 26, 2018 at 5:54 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >> >>> Seems good to me, too. >>> >>> -- Kevin >>> >>> >>> Michael Ennen wrote: >>> >>> >>>> Sounds like a good idea to me to only have `getScreenCapture` methods >>>> that have a WritableImage parameter which can be `null` which means a >>>> new WritableImage will be created otherwise the given one is re-used, as >>>> in Scene.snapshot and Node.snapshot. What are your thoughts on this, >>>> Kevin? >>>> >>>> On Sat, Mar 24, 2018 at 6:11 PM, Scott Palmer >>> > wrote: >>>> >>>> >>>> >>>> On Mar 23, 2018, at 5:50 PM, Michael Ennen >>> >>>>> > wrote: >>>>> >>>>> Kevin, >>>>> >>>>> I believe I followed all of your suggestions, except the one with a >>>>> re-usable WritableImage. >>>>> If you want me to implement that as well, I can, but you seemed >>>>> unsure >>>>> about the necessity >>>>> of it. >>>>> >>>>> >>>> I think it should be included to reduce garbage generated in a >>>> case where repeated captures is used. Such as a desktop sharing >>>> application, a screen recorder, etc. >>>> It would also be consistent with the node.snapshot API. >>>> >>>> In fact, I would just have the version that takes a WriteableImage >>>> and match the behaviour of node.snapshot. >>>> >>>> Scott >>>> >>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>>> >>>> > > > From ajit.ghaisas at oracle.com Tue Mar 27 09:14:32 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 27 Mar 2018 02:14:32 -0700 (PDT) Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <5AB95C0F.9040004@oracle.com> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <5AB5781E.3020705@oracle.com> <5AB95C0F.9040004@oracle.com> Message-ID: <0b3eb054-3e01-451b-9fc8-ac2c63234c2c@default> Thanks for the review. As suggested, I have added Mandy?s point about loggers map to be addressed as part of JDK-8200236. ? Regards, Ajit ? From: Kevin Rushforth Sent: Tuesday, March 27, 2018 2:16 AM To: mandy chung Cc: Ajit Ghaisas; Daniel Fuchs; openjfx-dev at openjdk.java.net Subject: Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules ? It doesn't seem harmful to keep the current implementation. This seems better to leave for the follow-on JBS issue (JDK-8200236) unless there something I am missing. -- Kevin mandy chung wrote: You don't need the loggers map and getLogger method can simply return ???? return new PlatformLogger(System.getLogger(name)); Other than this, looks fine. Mandy On 3/26/18 4:36 AM, Ajit Ghaisas wrote: Thanks all for the review. ? I have addressed the review comments in - HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/fx/8195799/webrev.1/"http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/ ? The changes are - 1. Addressed the (c) year inaccuracies in files - modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java modules/javafx.graphics/src/main/java/javafx/scene/Scene.java ? 2. Removed tabs from modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java 3. Removed unused methods from com.sun.javafx.logging.PlatformLogger class. ? Also, I have created a new bug JDK-8200236 to address some of the valid suggestions from Mandy and Daniel. ? Request you to review the new webrev. ? Regards, Ajit ? -----Original Message----- From: Kevin Rushforth Sent: Saturday, March 24, 2018 3:27 AM To: Ajit Ghaisas Cc: Mandy Chung; Daniel Fuchs; HYPERLINK "mailto:openjfx-dev at openjdk.java.net"openjfx-dev at openjdk.java.net Subject: Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules ? The only additional comments I have are couple typos and a white-space issue: ? 1. There is a typo in the Copyright year (201 rather than 2018) in the following two files: ? modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java modules/javafx.graphics/src/main/java/javafx/scene/Scene.java ? ? 2. There are tab characters in the following file that need to be changed to spaces: ? modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java ???? public static void setUpClass() { >>>??????? System.err.println("SelectBindingTest : log messages are expected from these tests."); ? ? All my testing looks good. With this patch I am now able to run applications with OpenJDK 10 + a standalone FX SDK with no qualified exports on the command line (as long as it doesn't use Swing interop). ? -- Kevin ? ? Ajit Ghaisas wrote: ??? Hi Kevin, Mandy and Daniel, ? ??? Please review the changeset that removes dependency on sun.util.logging package from JavaFX code. ? ??? Bug : ?https://bugs.openjdk.java.net/browse/JDK-8195799 ??? Fix : ?HYPERLINK "http://cr.openjdk.java.net/%7Eaghaisas/fx/8195799/webrev.0/"http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ ? ??? Request you to review. ? Regards, Ajit ? ?????? ? From tom.schindl at bestsolution.at Tue Mar 27 09:20:43 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 27 Mar 2018 11:20:43 +0200 Subject: Dependencies on java.desktop In-Reply-To: <2fa51511-c20d-cc9c-10f7-5e1de2b2a48d@bestsolution.at> References: <2fa51511-c20d-cc9c-10f7-5e1de2b2a48d@bestsolution.at> Message-ID: <03ff46ce-4f07-7108-2cdd-bc258e0db488@bestsolution.at> Hi, Anyone else has an opinion on that? Is require static the way to go? Tom On 21.03.18 23:23, Tom Schindl wrote: > Hi, > > I always thought the JavaFX-Codebase should be able to run with just the > java.base module but I was browsing the codebase a bit and was suprised > (or rather shocked) that even the base-module requires java.desktop. > > If I get it correct this because of the java.beans (provided by the > adapters) stuff is found in there. Why hasn't the requires there not > defined as: > > requires static java.desktop; > > Tom > From kevin.rushforth at oracle.com Tue Mar 27 12:26:28 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 27 Mar 2018 05:26:28 -0700 Subject: Dependencies on java.desktop In-Reply-To: <03ff46ce-4f07-7108-2cdd-bc258e0db488@bestsolution.at> References: <2fa51511-c20d-cc9c-10f7-5e1de2b2a48d@bestsolution.at> <03ff46ce-4f07-7108-2cdd-bc258e0db488@bestsolution.at> Message-ID: <5ABA3874.10405@oracle.com> Hi Tom, Yes, this is an unfortunate dependency. It is "only" an implementation dependency, meaning that nothing in the public API depends on java.desktop (which is why we don't "requires transient java.desktop"), so it should be possible to remove this dependency in the future. As noted, it is only there because Java Beans is part of the java.desktop module. In the interim, your suggestion of "requires static java.base" could be the way to go. It would need a spec change to the JavaFX beans adapter classes documenting that they would throw an UnsupportedOperationException if java.desktop was not present at runtime, along with a recommendation that applications needing that functionality should add "requires java.desktop" to their own module-info.java. Note that this would only help non-graphical JavaFX applications that use javafx.base for its collections, properties, and bindings, since javafx.graphics requires java.desktop in a way that currently cannot easily be made optional (not without reimplementing printing support anyway). -- Kevin Tom Schindl wrote: > Hi, > > Anyone else has an opinion on that? Is require static the way to go? > > Tom > > On 21.03.18 23:23, Tom Schindl wrote: > >> Hi, >> >> I always thought the JavaFX-Codebase should be able to run with just the >> java.base module but I was browsing the codebase a bit and was suprised >> (or rather shocked) that even the base-module requires java.desktop. >> >> If I get it correct this because of the java.beans (provided by the >> adapters) stuff is found in there. Why hasn't the requires there not >> defined as: >> >> requires static java.desktop; >> >> Tom >> >> From nlisker at gmail.com Tue Mar 27 16:17:10 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 27 Mar 2018 19:17:10 +0300 Subject: OpenJFX GitHub mirror In-Reply-To: References: Message-ID: 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 tom.schindl at bestsolution.at Tue Mar 27 16:38:35 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 27 Mar 2018 18:38:35 +0200 Subject: Dependencies on java.desktop In-Reply-To: <5ABA3874.10405@oracle.com> References: <2fa51511-c20d-cc9c-10f7-5e1de2b2a48d@bestsolution.at> <03ff46ce-4f07-7108-2cdd-bc258e0db488@bestsolution.at> <5ABA3874.10405@oracle.com> Message-ID: <95b46e34-ebb3-9915-81d5-b94f3df4e53b@bestsolution.at> On 27.03.18 14:26, Kevin Rushforth wrote: > Hi Tom, > > Yes, this is an unfortunate dependency. It is "only" an implementation > dependency, meaning that nothing in the public API depends on > java.desktop (which is why we don't "requires transient java.desktop"), > so it should be possible to remove this dependency in the future. As > noted, it is only there because Java Beans is part of the java.desktop > module. > > In the interim, your suggestion of "requires static java.base" could be > the way to go. It would need a spec change to the JavaFX beans adapter > classes documenting that they would throw an > UnsupportedOperationException if java.desktop was not present at How can that happen. To write a JavaBean the consumer of the API by definition has to have java.desktop as a dependency how else would he've been able to construct the bean? > runtime, along with a recommendation that applications needing that > functionality should add "requires java.desktop" to their own > module-info.java. > > Note that this would only help non-graphical JavaFX applications that > use javafx.base for its collections, properties, and bindings, since > javafx.graphics requires java.desktop in a way that currently cannot > easily be made optional (not without reimplementing printing support > anyway). > I understand but I guess here one could do a spec change to define that printing is only available if one add java.desktop yourself as a dependency. Looking at printing I might be better moved to its own module, the problem with JPMS is that you can't move stuff after having released the API module, I wished instead of "require module" JPMS would have used "import package". Tom From tom.schindl at bestsolution.at Tue Mar 27 17:24:01 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 27 Mar 2018 19:24:01 +0200 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <5AB95C3A.70400@oracle.com> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <5AB5781E.3020705@oracle.com> <5AB95C3A.70400@oracle.com> Message-ID: <555b3da6-9ab0-9c09-aa7f-40914ff685ac@bestsolution.at> Minor question on this: I see the test stuff is using java.util.Logging could this not be ported to PlatformLogger? Tom On 26.03.18 22:46, Kevin Rushforth wrote: > This looks fine to me now. > > -- Kevin > > > Ajit Ghaisas wrote: >> Thanks all for the review. >> >> I have addressed the review comments in - >> http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/ >> >> The changes are - >> 1. Addressed the (c) year inaccuracies in files - >> modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java >> >> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java >> >> 2. Removed tabs from >> modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java >> >> 3. Removed unused methods from com.sun.javafx.logging.PlatformLogger >> class. >> >> Also, I have created a new bug JDK-8200236 to address some of the >> valid suggestions from Mandy and Daniel. >> >> Request you to review the new webrev. >> >> Regards, >> Ajit >> >> -----Original Message----- >> From: Kevin Rushforth Sent: Saturday, March 24, 2018 3:27 AM >> To: Ajit Ghaisas >> Cc: Mandy Chung; Daniel Fuchs; openjfx-dev at openjdk.java.net >> Subject: Re: [11] Review request : JDK-8195799 : Use System logger >> instead of platform logger in javafx modules >> >> The only additional comments I have are couple typos and a white-space >> issue: >> >> 1. There is a typo in the Copyright year (201 rather than 2018) in the >> following two files: >> >> modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java >> >> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java >> >> >> 2. There are tab characters in the following file that need to be >> changed to spaces: >> >> modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java >> >> ???? public static void setUpClass() { >> ?>>>??????? System.err.println("SelectBindingTest : log messages are >> expected from these tests."); >> >> >> All my testing looks good. With this patch I am now able to run >> applications with OpenJDK 10 + a standalone FX SDK with no qualified >> exports on the command line (as long as it doesn't use Swing interop). >> >> -- Kevin >> >> >> Ajit Ghaisas wrote: >> ? >>> Hi Kevin, Mandy and Daniel, >>> >>> ??? Please review the changeset that removes dependency on >>> sun.util.logging package from JavaFX code. >>> >>> ??? Bug :? https://bugs.openjdk.java.net/browse/JDK-8195799 >>> ??? Fix :? http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ >>> >>> ??? Request you to review. >>> >>> Regards, >>> Ajit >>> ? ??? From kevin.rushforth at oracle.com Tue Mar 27 17:55:40 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 27 Mar 2018 10:55:40 -0700 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <555b3da6-9ab0-9c09-aa7f-40914ff685ac@bestsolution.at> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <5AB5781E.3020705@oracle.com> <5AB95C3A.70400@oracle.com> <555b3da6-9ab0-9c09-aa7f-40914ff685ac@bestsolution.at> Message-ID: <5ABA859C.6020501@oracle.com> Yes it could be converted, but wasn't necessary to remove the depenency, so I filed a separate JBS issue to track this replacing the calls to j.u.l: JDK-8195974 . -- Kevin Tom Schindl wrote: > Minor question on this: I see the test stuff is using java.util.Logging > could this not be ported to PlatformLogger? > > Tom > > On 26.03.18 22:46, Kevin Rushforth wrote: > >> This looks fine to me now. >> >> -- Kevin >> >> >> Ajit Ghaisas wrote: >> >>> Thanks all for the review. >>> >>> I have addressed the review comments in - >>> http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/ >>> >>> The changes are - >>> 1. Addressed the (c) year inaccuracies in files - >>> modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java >>> >>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java >>> >>> 2. Removed tabs from >>> modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java >>> >>> 3. Removed unused methods from com.sun.javafx.logging.PlatformLogger >>> class. >>> >>> Also, I have created a new bug JDK-8200236 to address some of the >>> valid suggestions from Mandy and Daniel. >>> >>> Request you to review the new webrev. >>> >>> Regards, >>> Ajit >>> >>> -----Original Message----- >>> From: Kevin Rushforth Sent: Saturday, March 24, 2018 3:27 AM >>> To: Ajit Ghaisas >>> Cc: Mandy Chung; Daniel Fuchs; openjfx-dev at openjdk.java.net >>> Subject: Re: [11] Review request : JDK-8195799 : Use System logger >>> instead of platform logger in javafx modules >>> >>> The only additional comments I have are couple typos and a white-space >>> issue: >>> >>> 1. There is a typo in the Copyright year (201 rather than 2018) in the >>> following two files: >>> >>> modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java >>> >>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java >>> >>> >>> 2. There are tab characters in the following file that need to be >>> changed to spaces: >>> >>> modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java >>> >>> public static void setUpClass() { >>> >>> System.err.println("SelectBindingTest : log messages are >>> expected from these tests."); >>> >>> >>> All my testing looks good. With this patch I am now able to run >>> applications with OpenJDK 10 + a standalone FX SDK with no qualified >>> exports on the command line (as long as it doesn't use Swing interop). >>> >>> -- Kevin >>> >>> >>> Ajit Ghaisas wrote: >>> >>> >>>> Hi Kevin, Mandy and Daniel, >>>> >>>> Please review the changeset that removes dependency on >>>> sun.util.logging package from JavaFX code. >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8195799 >>>> Fix : http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ >>>> >>>> Request you to review. >>>> >>>> Regards, >>>> Ajit >>>> >>>> From pedro.duquevieira at gmail.com Wed Mar 28 00:16:17 2018 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 28 Mar 2018 01:16:17 +0100 Subject: modules versus SDK's Message-ID: Like Kevin says I don't think this is a one or the other choice. I think we need to think about people who are just evaluating the platform or learning, and whether making them also have to learn about build tools is good. I'd say part of the web's success is it shallow learning curve, and why languages that are technically inferior like javascript are some times preferred over technically superior languages. I'd argue we should also have an installer to make the process of evaluating/learning as easy as possible. We do need more javafx programmers/adopters. My 2 cents, -- Pedro Duque Vieira From mandy.chung at oracle.com Wed Mar 28 03:32:21 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 28 Mar 2018 11:32:21 +0800 Subject: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules In-Reply-To: <5AB95C0F.9040004@oracle.com> References: <4ca57c7a-627a-46d2-984c-d4a84d598e71@default> <5AB5781E.3020705@oracle.com> <5AB95C0F.9040004@oracle.com> Message-ID: <02d0cfe4-d860-ed2d-cb35-e998862afa31@oracle.com> It can be addressed later while I think this is a simple change to the getInstance method.? I guess you prefer to keep PlatformLogger as close to the original version and that's fine. Mandy On 3/27/18 4:46 AM, Kevin Rushforth wrote: > It doesn't seem harmful to keep the current implementation. This seems > better to leave for the follow-on JBS issue (JDK-8200236) unless there > something I am missing. > > -- Kevin > > > mandy chung wrote: >> You don't need the loggers map and getLogger method can simply return >> ???? return new PlatformLogger(System.getLogger(name)); >> >> Other than this, looks fine. >> >> Mandy >> >> >> On 3/26/18 4:36 AM, Ajit Ghaisas wrote: >>> Thanks all for the review. >>> >>> I have addressed the review comments in -http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/ >>> >>> The changes are - >>> 1. Addressed the (c) year inaccuracies in files - >>> modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java >>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java >>> >>> 2. Removed tabs from modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java >>> 3. Removed unused methods from com.sun.javafx.logging.PlatformLogger class. >>> >>> Also, I have created a new bug JDK-8200236 to address some of the valid suggestions from Mandy and Daniel. >>> >>> Request you to review the new webrev. >>> >>> Regards, >>> Ajit >>> >>> -----Original Message----- >>> From: Kevin Rushforth >>> Sent: Saturday, March 24, 2018 3:27 AM >>> To: Ajit Ghaisas >>> Cc: Mandy Chung; Daniel Fuchs;openjfx-dev at openjdk.java.net >>> Subject: Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules >>> >>> The only additional comments I have are couple typos and a white-space >>> issue: >>> >>> 1. There is a typo in the Copyright year (201 rather than 2018) in the following two files: >>> >>> modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java >>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java >>> >>> >>> 2. There are tab characters in the following file that need to be changed to spaces: >>> >>> modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java >>> public static void setUpClass() { >>> >>> System.err.println("SelectBindingTest : log messages are >>> expected from these tests."); >>> >>> >>> All my testing looks good. With this patch I am now able to run applications with OpenJDK 10 + a standalone FX SDK with no qualified exports on the command line (as long as it doesn't use Swing interop). >>> >>> -- Kevin >>> >>> >>> Ajit Ghaisas wrote: >>> >>>> Hi Kevin, Mandy and Daniel, >>>> >>>> Please review the changeset that removes dependency on sun.util.logging package from JavaFX code. >>>> >>>> Bug :https://bugs.openjdk.java.net/browse/JDK-8195799 >>>> Fix :http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.0/ >>>> >>>> Request you to review. >>>> >>>> Regards, >>>> Ajit >>>> >>>> >> From michael.dever at icloud.com Wed Mar 28 03:47:25 2018 From: michael.dever at icloud.com (Michael Dever) Date: Tue, 27 Mar 2018 23:47:25 -0400 Subject: modules versus SDK's In-Reply-To: References: Message-ID: <9AB119A1-1034-4806-92CC-D27F58C4B074@icloud.com> Agreed. On Mar 27, 2018, at 8:16 PM, Pedro Duque Vieira wrote: Like Kevin says I don't think this is a one or the other choice. I think we need to think about people who are just evaluating the platform or learning, and whether making them also have to learn about build tools is good. I'd say part of the web's success is it shallow learning curve, and why languages that are technically inferior like javascript are some times preferred over technically superior languages. I'd argue we should also have an installer to make the process of evaluating/learning as easy as possible. We do need more javafx programmers/adopters. My 2 cents, -- Pedro Duque Vieira From kevin.rushforth at oracle.com Wed Mar 28 16:51:36 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 28 Mar 2018 09:51:36 -0700 Subject: [11] Review request: 8200277: Compiling native media code fails when using OpenJDK build as boot JDK Message-ID: <5ABBC818.2000300@oracle.com> Please review the following: https://bugs.openjdk.java.net/browse/JDK-8200277 https://github.com/javafxports/openjdk-jfx/commit/ccd5aa2ca090f0844778def02c1c1243c87fb7d4 This was merged into the GitHub sandbox 'develop' branch here: https://github.com/javafxports/openjdk-jfx/pull/47 -- Kevin From kevin.rushforth at oracle.com Wed Mar 28 17:17:08 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 28 Mar 2018 10:17:08 -0700 Subject: [11] Review request: 8200277: Compiling native media code fails when using OpenJDK build as boot JDK In-Reply-To: <5ABBC818.2000300@oracle.com> References: <5ABBC818.2000300@oracle.com> Message-ID: <5ABBCE14.8050008@oracle.com> Actually, that was a pointer to the merge changeset on GitHub. Here is the actual changeset in question (the contents are identical) https://github.com/javafxports/openjdk-jfx/commit/b7279fa9572472be803139898e3407fd860e2e75 -- Kevin Kevin Rushforth wrote: > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8200277 > https://github.com/javafxports/openjdk-jfx/commit/ccd5aa2ca090f0844778def02c1c1243c87fb7d4 > > > This was merged into the GitHub sandbox 'develop' branch here: > > https://github.com/javafxports/openjdk-jfx/pull/47 > > -- Kevin > From kevin.rushforth at oracle.com Thu Mar 29 01:36:51 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 28 Mar 2018 18:36:51 -0700 Subject: JDK-8199560: Dynamic evaluation for binding.When In-Reply-To: References: <5AAC47A9.20004@oracle.com> Message-ID: <5ABC4333.3010700@oracle.com> 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 > > 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 kevin.rushforth at oracle.com Thu Mar 29 01:39:50 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 28 Mar 2018 18:39:50 -0700 Subject: OpenJFX GitHub mirror In-Reply-To: References: Message-ID: <5ABC43E6.10504@oracle.com> 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 bourges.laurent at gmail.com Thu Mar 29 06:42:59 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 29 Mar 2018 06:42:59 +0000 Subject: OpenJFX GitHub mirror In-Reply-To: <5ABC43E6.10504@oracle.com> References: <5ABC43E6.10504@oracle.com> Message-ID: 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 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 tom.schindl at bestsolution.at Thu Mar 29 07:08:26 2018 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 29 Mar 2018 09:08:26 +0200 Subject: OpenJFX GitHub mirror In-Reply-To: References: <5ABC43E6.10504@oracle.com> Message-ID: <055d45e1-1c38-6f82-2d9e-8f62a10d77d4@bestsolution.at> 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 > 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 nlisker at gmail.com Thu Mar 29 12:13:03 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 29 Mar 2018 15:13:03 +0300 Subject: OpenJFX GitHub mirror In-Reply-To: <055d45e1-1c38-6f82-2d9e-8f62a10d77d4@bestsolution.at> References: <5ABC43E6.10504@oracle.com> <055d45e1-1c38-6f82-2d9e-8f62a10d77d4@bestsolution.at> Message-ID: 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 nlisker at gmail.com Thu Mar 29 16:32:12 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 29 Mar 2018 19:32:12 +0300 Subject: JEP 286: Local-Variable Type Inference: Usage Message-ID: Hello, A style guide for usage of 'var' has been published at http://openjdk.java.net/projects/amber/LVTIstyle.html. Can we start using this feature in contributions to OpenJFX? - Nir From kevin.rushforth at oracle.com Thu Mar 29 16:36:27 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 29 Mar 2018 09:36:27 -0700 Subject: JEP 286: Local-Variable Type Inference: Usage In-Reply-To: References: Message-ID: <5ABD160B.3020100@oracle.com> As a prerequisite, we would need to update the minimum boot JDK to JDK 10, which I was going to propose doing anyway -- it seems the right time now that JDK 10 is out. I have no objections to then allowing the use of 'var' in new code. Do any others have any concerns? -- Kevin Nir Lisker wrote: > Hello, > > A style guide for usage of 'var' has been published at > http://openjdk.java.net/projects/amber/LVTIstyle.html. Can we start using > this feature in contributions to OpenJFX? > > - Nir > From kevin.rushforth at oracle.com Thu Mar 29 16:40:10 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 29 Mar 2018 09:40:10 -0700 Subject: [11] Review request: 8199841: Add gradle wrapper files to build Message-ID: <5ABD16EA.4030509@oracle.com> Hi Johan, Please review the following to add gradle wrapper: https://bugs.openjdk.java.net/browse/JDK-8199841 http://cr.openjdk.java.net/~kcr/8199841/webrev.00/ This is the aggregation of two changesets pushed to the github mirror: https://github.com/javafxports/openjdk-jfx/commit/7ff32048e62e7338ed6e2142ca0887b1ebc8aaa7 https://github.com/javafxports/openjdk-jfx/commit/5bb8f3f25d31af37dedb040da7e4cd3c91a31919 so there should be no merge conflict. It includes the associated third-party legal file. -- Kevin From kevin.rushforth at oracle.com Thu Mar 29 16:42:14 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 29 Mar 2018 09:42:14 -0700 Subject: CFV: New OpenJFX Committer: Rajath Kamath Message-ID: <5ABD1766.8020204@oracle.com> 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 kevin.rushforth at oracle.com Thu Mar 29 16:43:06 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 29 Mar 2018 09:43:06 -0700 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5ABD1766.8020204@oracle.com> References: <5ABD1766.8020204@oracle.com> Message-ID: <5ABD179A.8010507@oracle.com> Vote: YES 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 arunprasad.rajkumar at oracle.com Thu Mar 29 17:23:14 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Thu, 29 Mar 2018 22:53:14 +0530 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5ABD1766.8020204@oracle.com> References: <5ABD1766.8020204@oracle.com> Message-ID: <403F3AB3-15B4-413A-87E4-DAB59149DF9F@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 gshiv.sk at gmail.com Thu Mar 29 17:32:50 2018 From: gshiv.sk at gmail.com (Shiv Kumar Ganesh) Date: Thu, 29 Mar 2018 17:32:50 +0000 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <403F3AB3-15B4-413A-87E4-DAB59149DF9F@oracle.com> References: <5ABD1766.8020204@oracle.com> <403F3AB3-15B4-413A-87E4-DAB59149DF9F@oracle.com> Message-ID: VOTE: yes On Thu, Mar 29, 2018, 10:23 AM Arunprasad Rajkumar < arunprasad.rajkumar at oracle.com> wrote: > 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 Thu Mar 29 17:34:56 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 29 Mar 2018 17:34:56 +0000 Subject: [11] Review request: 8199841: Add gradle wrapper files to build In-Reply-To: <5ABD16EA.4030509@oracle.com> References: <5ABD16EA.4030509@oracle.com> Message-ID: Looks good. - Johan On Thu, Mar 29, 2018 at 6:40 PM Kevin Rushforth wrote: > Hi Johan, > > Please review the following to add gradle wrapper: > > https://bugs.openjdk.java.net/browse/JDK-8199841 > http://cr.openjdk.java.net/~kcr/8199841/webrev.00/ > > This is the aggregation of two changesets pushed to the github mirror: > > > https://github.com/javafxports/openjdk-jfx/commit/7ff32048e62e7338ed6e2142ca0887b1ebc8aaa7 > > https://github.com/javafxports/openjdk-jfx/commit/5bb8f3f25d31af37dedb040da7e4cd3c91a31919 > > so there should be no merge conflict. It includes the associated > third-party legal file. > > -- Kevin > > From murali.billa at oracle.com Thu Mar 29 17:35:21 2018 From: murali.billa at oracle.com (Murali Billa) Date: Thu, 29 Mar 2018 10:35:21 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <403F3AB3-15B4-413A-87E4-DAB59149DF9F@oracle.com> References: <5ABD1766.8020204@oracle.com> <403F3AB3-15B4-413A-87E4-DAB59149DF9F@oracle.com> Message-ID: <76fcafda-c506-45c3-85b2-cf60123acf86@default> 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 kevin.rushforth at oracle.com Thu Mar 29 17:41:11 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 29 Mar 2018 10:41:11 -0700 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: References: <5ABD1766.8020204@oracle.com> <403F3AB3-15B4-413A-87E4-DAB59149DF9F@oracle.com> Message-ID: <5ABD2537.1010109@oracle.com> I note that this vote is not valid. Only existing OpenJFX Project Committers are eligible to vote. Thanks. -- Kevin Shiv Kumar Ganesh wrote: > VOTE: yes > > On Thu, Mar 29, 2018, 10:23 AM Arunprasad Rajkumar > > wrote: > > 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 nlisker at gmail.com Thu Mar 29 17:42:35 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 29 Mar 2018 20:42:35 +0300 Subject: JDK-8200206: Adding an animation to more than one parent results in inconsistent state Message-ID: Hello, Iv'e created bug https://bugs.openjdk.java.net/browse/JDK-8200206. The behavior was noticed back when writing missing documentation for Transition [1]. Please evaluate. Thanks, Nir [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-January/021249.html From kevin.rushforth at oracle.com Thu Mar 29 18:31:25 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 29 Mar 2018 11:31:25 -0700 Subject: JEP 286: Local-Variable Type Inference: Usage In-Reply-To: <5ABD160B.3020100@oracle.com> References: <5ABD160B.3020100@oracle.com> Message-ID: <5ABD30FD.7080206@oracle.com> I filed: https://bugs.openjdk.java.net/browse/JDK-8200446 I'll send out a separate heads-up today (as we always do when requiring an update to our tool chain) and we can target this for next week if no objections. -- Kevin Kevin Rushforth wrote: > As a prerequisite, we would need to update the minimum boot JDK to JDK > 10, which I was going to propose doing anyway -- it seems the right > time now that JDK 10 is out. > > I have no objections to then allowing the use of 'var' in new code. > > Do any others have any concerns? > > -- Kevin > > > Nir Lisker wrote: >> Hello, >> >> A style guide for usage of 'var' has been published at >> http://openjdk.java.net/projects/amber/LVTIstyle.html. Can we start >> using >> this feature in contributions to OpenJFX? >> >> - Nir >> From artem.ananiev at oracle.com Thu Mar 29 18:36:18 2018 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 29 Mar 2018 11:36:18 -0700 Subject: JEP 286: Local-Variable Type Inference: Usage In-Reply-To: <5ABD160B.3020100@oracle.com> References: <5ABD160B.3020100@oracle.com> Message-ID: <5ABD3222.7080206@oracle.com> On 2018/03/29 9:36, Kevin Rushforth wrote: > As a prerequisite, we would need to update the minimum boot JDK to JDK > 10, which I was going to propose doing anyway -- it seems the right time > now that JDK 10 is out. > > I have no objections to then allowing the use of 'var' in new code. > > Do any others have any concerns? My personal experience with "var"s - they are used a lot in Scala, for example - is they make code very unreadable, especially when working with collections and streams. The only case when a "var" is suitable is new object creation: var object = new SomeType() In all other cases they are more painful than valuable. I can say it differently. It's very easy to use "var"s wrong. No matter what style guides are available, people will often use them in a way that makes code less readable. Just my $0.02 Thanks, Artem > -- Kevin > > > Nir Lisker wrote: >> Hello, >> >> A style guide for usage of 'var' has been published at >> http://openjdk.java.net/projects/amber/LVTIstyle.html. Can we start using >> this feature in contributions to OpenJFX? >> >> - Nir From kevin.rushforth at oracle.com Thu Mar 29 18:41:37 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 29 Mar 2018 11:41:37 -0700 Subject: JEP 286: Local-Variable Type Inference: Usage In-Reply-To: <5ABD3222.7080206@oracle.com> References: <5ABD160B.3020100@oracle.com> <5ABD3222.7080206@oracle.com> Message-ID: <5ABD3361.6070006@oracle.com> I tend to agree, so I would prefer to see them used judiciously. The write-up by Stuart (referenced below) raised some good points about when to use them vs when you might not want to. -- Kevin Artem Ananiev wrote: > > On 2018/03/29 9:36, Kevin Rushforth wrote: >> As a prerequisite, we would need to update the minimum boot JDK to JDK >> 10, which I was going to propose doing anyway -- it seems the right time >> now that JDK 10 is out. >> >> I have no objections to then allowing the use of 'var' in new code. >> >> Do any others have any concerns? > > My personal experience with "var"s - they are used a lot in Scala, for > example - is they make code very unreadable, especially when working > with collections and streams. The only case when a "var" is suitable > is new object creation: > > var object = new SomeType() > > In all other cases they are more painful than valuable. > > I can say it differently. It's very easy to use "var"s wrong. No > matter what style guides are available, people will often use them in > a way that makes code less readable. > > Just my $0.02 > > Thanks, > > Artem > >> -- Kevin >> >> >> Nir Lisker wrote: >>> Hello, >>> >>> A style guide for usage of 'var' has been published at >>> http://openjdk.java.net/projects/amber/LVTIstyle.html. Can we start >>> using >>> this feature in contributions to OpenJFX? >>> >>> - Nir From kevin.rushforth at oracle.com Thu Mar 29 18:43:12 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 29 Mar 2018 11:43:12 -0700 Subject: HEADS-UP: Proposal to bump the minimum boot JDK for FX to JDK 10 Message-ID: <5ABD33C0.9@oracle.com> 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 philip.race at oracle.com Thu Mar 29 18:57:18 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 29 Mar 2018 11:57:18 -0700 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5ABD1766.8020204@oracle.com> References: <5ABD1766.8020204@oracle.com> Message-ID: Vote: yes -phil. From tbee at tbee.org Fri Mar 30 05:36:31 2018 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 30 Mar 2018 07:36:31 +0200 Subject: JEP 286: Local-Variable Type Inference: Usage In-Reply-To: <5ABD3361.6070006@oracle.com> References: <5ABD160B.3020100@oracle.com> <5ABD3222.7080206@oracle.com> <5ABD3361.6070006@oracle.com> Message-ID: <27e0f28d-3ab7-040f-5005-3347d223f753@tbee.org> It is very comforting to see restraint when new features become available. IMHO a lot of the var-readability comes down to moving the type information into the variable name (which I personally do already anyhow) and regionality. Kudos On 29-3-2018 20:41, Kevin Rushforth wrote: > I tend to agree, so I would prefer to see them used judiciously. The write-up by Stuart (referenced below) raised some good points about when to use them vs when you might not want to. > > -- Kevin > > > Artem Ananiev wrote: >> >> On 2018/03/29 9:36, Kevin Rushforth wrote: >>> As a prerequisite, we would need to update the minimum boot JDK to JDK >>> 10, which I was going to propose doing anyway -- it seems the right time >>> now that JDK 10 is out. >>> >>> I have no objections to then allowing the use of 'var' in new code. >>> >>> Do any others have any concerns? >> >> My personal experience with "var"s - they are used a lot in Scala, for example - is they make code very unreadable, especially when working with collections and streams. The only case when a "var" is suitable is new object creation: >> >> var object = new SomeType() >> >> In all other cases they are more painful than valuable. >> >> I can say it differently. It's very easy to use "var"s wrong. No matter what style guides are available, people will often use them in a way that makes code less readable. >> >> Just my $0.02 >> >> Thanks, >> >> Artem >> >>> -- Kevin >>> >>> >>> Nir Lisker wrote: >>>> Hello, >>>> >>>> A style guide for usage of 'var' has been published at >>>> http://openjdk.java.net/projects/amber/LVTIstyle.html. Can we start using >>>> this feature in contributions to OpenJFX? >>>> >>>> - Nir From johan.vos at gluonhq.com Fri Mar 30 09:36:58 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 30 Mar 2018 09:36:58 +0000 Subject: Review request: 8200300: better gradle error message Message-ID: Please review the webrev http://cr.openjdk.java.net/~jvos/8200300/webrev.00/ which fixes https://bugs.openjdk.java.net/browse/JDK-8200300 From kevin.rushforth at oracle.com Fri Mar 30 12:28:22 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 30 Mar 2018 05:28:22 -0700 Subject: Review request: 8200300: better gradle error message In-Reply-To: References: Message-ID: <5ABE2D66.70106@oracle.com> +1 Johan Vos wrote: > Please review the webrev http://cr.openjdk.java.net/~jvos/8200300/webrev.00/ > which fixes https://bugs.openjdk.java.net/browse/JDK-8200300 > From ank.cpp at gmail.com Fri Mar 30 12:46:31 2018 From: ank.cpp at gmail.com (ankit srivastav) Date: Fri, 30 Mar 2018 18:16:31 +0530 Subject: CFV: New OpenJFX Committer: Rajath Kamath In-Reply-To: <5ABD2537.1010109@oracle.com> References: <5ABD1766.8020204@oracle.com> <403F3AB3-15B4-413A-87E4-DAB59149DF9F@oracle.com> <5ABD2537.1010109@oracle.com> Message-ID: Vote: Yes --Ankit On Thu, Mar 29, 2018 at 11:11 PM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > I note that this vote is not valid. Only existing OpenJFX Project > Committers are eligible to vote. > > Thanks. > > -- Kevin > > > Shiv Kumar Ganesh wrote: > >> VOTE: yes >> >> On Thu, Mar 29, 2018, 10:23 AM Arunprasad Rajkumar < >> arunprasad.rajkumar at oracle.com > >> wrote: >> >> 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 >> > 20&rev=author%28rkamath%29> >> > [3] >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount= >> 20&rev=rajath.kamath >> > 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-Febr >> uary/021499.html >> > >> >>