From kevin.rushforth at oracle.com Fri Dec 1 00:16:19 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 30 Nov 2017 16:16:19 -0800 Subject: javapackager feedback and questions In-Reply-To: References: <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com> Message-ID: <5A209F53.6080707@oracle.com> Hi Michael, We realized that the javapackger CLI JEP wasn't quite ready, and was out of scope for JDK 10 anyway, so we withdrew it in order to file a new JEP later. Related to this, we are soliciting input as to how people are using the javapackager (see Victor's question below). So we'd love to hear how you and others are using it, and for what kind of applications. -- Kevin Michael Hall wrote: >> On Nov 29, 2017, at 5:18 PM, victor.drozdov at oracle.com wrote: >> >> Hi, Mani. >> >> Thanks for providing the feedback! >> We will consider adding more examples and more details in the docs as you proposed(there is an arg named jvmOptions but that's not mentioned in the table). >> Looks like there is a bug when you specify systemWide=true on the MacOSX in non-gui mode. Can you provide more details about that (like full cmd line)? >> Actually, if you want you can clone the repo: >> http://hg.openjdk.java.net/openjfx/10-dev/rt/ >> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/) >> and help to improve javapackager. Or you can just create Enhancements for deploy/packager, as it's not always clear what users expect. >> >> > > Why was JEP 311 [1] Closed/Withdrawn? > > [1] http://openjdk.java.net/jeps/311 > > From mik3hall at gmail.com Fri Dec 1 00:20:59 2017 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 30 Nov 2017 18:20:59 -0600 Subject: javapackager feedback and questions In-Reply-To: <5A209F53.6080707@oracle.com> References: <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com> <5A209F53.6080707@oracle.com> Message-ID: > On Nov 30, 2017, at 6:16 PM, Kevin Rushforth wrote: > > Hi Michael, > > We realized that the javapackger CLI JEP wasn't quite ready, and was out of scope for JDK 10 anyway, so we withdrew it in order to file a new JEP later. > > Related to this, we are soliciting input as to how people are using the javapackager (see Victor's question below). > > So we'd love to hear how you and others are using it, and for what kind of applications. > > ? Kevin I was sort of waiting to see what came out of the JEP. It had some issues on OS X the last time I tried it. I might have used it for a starter application that I?ve been manually updating since. Now I use jlink, copy in the results? That sort of thing. I may look at it some more as-is if it doesn?t have a significant update currently in the works. Thanks. From sadhak001 at gmail.com Fri Dec 1 00:33:33 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 01 Dec 2017 00:33:33 +0000 Subject: javapackager feedback and questions In-Reply-To: References: <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com> Message-ID: Hi Victor, To answer your query about how javapackager can be made better, packr ( https://github.com/libgdx/packr) and FPM ( https://github.com/jordansissel/fpm) are two great examples in this space. If we can pool together some of the features from both, it would certainly draw attention of developers building installers and distributable packages. javapackager does already have many of them already. Packr does allow compressing jre packed into the app although jlink already helps in this area. Another example would be to be able to --dry-run your executions, bundle respective apps as a service (systemd, etc...), see usage of FPM at https://github.com/jordansissel/fpm/wiki#usage. Your queries about how people use it or like to use it, one thing FPM and packr do very well, is to allow creation of packages/installer on a single platform, their cross-platform functionality is a boon, although building on native environments have their own merits. Just now one would need to run javapackager in the specific environments to get a working installer/package created for that environment. Many would like to run Jenkins (Linux env) and build all three types of packages/installers on one box rather than spin off the individual slave variants of different platforms (Linux, MacOSX and Windows. I can help draw some enhancement points off this list and share it with you to avoid noise here, and you can choose to bring them to this list - the ones you would make part of the packager. Others might differ in the above and want something else. I hope this helps. Cheers, Mani On Thu, 30 Nov 2017 at 18:57 Martijn Verburg wrote: > Hi Victor, > > I can answer the last Q. It's for two products, one is Censum our GC Log > analyser (Java swing desktop app, yes they still exist! ;p) and the second > is a stand alone Java 'daemon' for our APM SaaS tool (illuminate). > > jlink and javapackager is a powerful combination for us, so thanks for > these tools! > > Cheers, > Martijn > > On 29 November 2017 at 23:18, wrote: > >> Hi, Mani. >> >> Thanks for providing the feedback! >> We will consider adding more examples and more details in the docs as you >> proposed(there is an arg named jvmOptions but that's not mentioned in the >> table). >> Looks like there is a bug when you specify systemWide=true on the MacOSX >> in non-gui mode. Can you provide more details about that (like full cmd >> line)? >> Actually, if you want you can clone the repo: >> http://hg.openjdk.java.net/openjfx/10-dev/rt/ >> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/) >> and help to improve javapackager. Or you can just create Enhancements for >> deploy/packager, as it's not always clear what users expect. >> >> By the way, what kind of apps you distribute using javapackager? Is that >> a UI app or services? >> >> --Victor >> >> >> >> On 11/29/17 3:48 AM, Mani Sarkar wrote: >> >>> Hi all, >>> >>> First I hope I'm writing to the correct mailing list, if not please >>> suggest >>> where to write instead. Also if it is worth writing back as separate >>> messages per issue or item, please do let me know. >>> >>> Some of my observations and feedback when using *javapackager*: >>> >>> *Positives* >>> - .dmg and .msi packaging work very well out of the box, easy to put >>> together configuration settings >>> - .rpm packages build very quickly >>> - a number of features from FPM (docs >>> | GitHub >>> ) available but some more for the >>> individual types of packages would certainly help (for e.g. exposing some >>> more of the CLI flags for DEB and RPM packaging) >>> >>> *Improvements* >>> - [doc and example required]: Additional documentation and examples >>> around >>> how to add a license when building a package would be helpful. After a >>> bit >>> of searching on google and experimenting with couple of combinations of >>> CLI >>> options I was able to figure it out. >>> - [doc correction]: jvmUserArg is referred to in the documentation with >>> examples, while in the usage documentation jvmOptions is used >>> (discrepancy >>> between the names of flags), see >>> >>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javapackager.html >>> and >>> >>> https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm#JSDPG585 >>> - [doc correction]: same goes for mac.signing-key-user-name while there >>> is >>> no mention of it in the javapackager usage documentation, it takes the >>> full >>> name of the user i.e. *Jane Doe* >>> *- *[doc and example required]: just adding >>> mac.signing-key-developer-id-app=xxxxx isn't enough, needs the other >>> code-sign related flags as well, possibly key should be in the Mac >>> KeyStore >>> when building it (check if id provided is the correct one, additional >>> examples would definitely help to reduce or eliminate experimentation and >>> assumptions) >>> - [potential bug]: Using *-B*systemWide=true flag causes error -10810 >>> when >>> building on the MacOSX in non-gui mode, can be overridden by using the >>> -Bmac.dmg.simple=true but we loose the backdrop and automatic shortcut >>> creation, etc... Swappin gthe order to: -Bmac.dmg.simple=true and *-B* >>> systemWide=true does not help, still ends up building a .dmg package with >>> just the app in it (no icon, no background) >>> - code signing examples for Windows and MacOSX will certainly help quite >>> a >>> bit >>> - [doc and example required] .deb packages take a long time to build, >>> some >>> additional flags that can help. Some findings along the lines on how to >>> speed up dpkg-build: >>> >>> export CCACHE_DIR=/home/$USER/.ccache >>> >>> export CCACHE_HASHDIR=$CCACHE_DIR >>> >>> export DEB_BUILD_OPTIONS="${DEB_BUILD_OPTIONS} >>> --preserve-envvar=CCACHE_DIR >>> --prepend-path=/usr/lib/ccache parallel=jobs" >>> >>> echo "Debian build options: ${DEB_BUILD_OPTIONS}" >>> >>> ------------------------------- >>> >>> A response with answers for the above will be highly appreciated. >>> >>> Thanks. >>> >>> Cheers, >>> Mani >>> >> >> > -- @theNeomatrix369 | Blog | @adoptopenjdk | Dev communities Meet-a-Project - MutabilityDetector | Github | Slideshare | LinkedIn Come to Devoxx UK 2018: http://www.devoxx.co.uk/ Don't chase success, rather aim for "Excellence", and success will come chasing after you! From kevin.rushforth at oracle.com Fri Dec 1 01:10:36 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 30 Nov 2017 17:10:36 -0800 Subject: [10] Review request: 8192867: Update version of Lucene in license file to 7.1.0 Message-ID: <5A20AC0C.7050502@oracle.com> Phil, Please review the following follow-up fix to the Lucene 7.1.0 upgrade. I forgot to change the version in the license file: https://bugs.openjdk.java.net/browse/JDK-8192867 The one line diff is in JBS, and repeated here: diff --git a/apps/samples/Ensemble8/legal/lucene.md b/apps/samples/Ensemble8/legal/lucene.md --- a/apps/samples/Ensemble8/legal/lucene.md +++ b/apps/samples/Ensemble8/legal/lucene.md @@ -1,4 +1,4 @@ -## Apache Lucene v3.2.0 +## Apache Lucene v7.1.0 ### Apache 2.0 License


-- Kevin


From swpalmer at gmail.com  Fri Dec  1 03:23:21 2017
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 30 Nov 2017 22:23:21 -0500
Subject: javapackager feedback and questions
In-Reply-To: <5A209F53.6080707@oracle.com>
References: 
 <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com>
 
 <5A209F53.6080707@oracle.com>
Message-ID: <2054E56A-27E2-40FD-91D7-A3FEE73F0B08@gmail.com>

I?m using javapackager to generate native installers for several services and GUI applications. I would be using it for some command line tools as well, but it doesn?t yet support ?console? applications on Windows. I.e. you can?t make javapackager with javapackager. I?ve filed an issue for that already (it was closed as won?t fix, but thankfully it was reopened)

Javapackager is one of the most useful tools in the JDK, but it is mostly undocumented and has many usability issues.
IMO, it tried to do way too much. The only thing it ever needed to do was the -deploy option.

I run javapackager two ways, always from Gradle scripts, either via the javaFX Gradle plugin, or as an Exec task.

The ability to have secondary launchers is great.

The customization options for installers needs some work. I?ve filed several issues (and I could file more). E.g. background images for macOS .dmg must be different from background images used in macOS .pkg as they are serving entirely different purposes. Including custom resources in subdirectories is difficult and/or broken depending on the version of javapackager used (v9 is broken).
On Windows .msi component rules are not followed making upgrades problematic. Install folders should be customizable by supplying custom wix files, etc.

On Linux services should be handled with systemd or sysctl. (I can?t remember which is preferred at the moment, but I know it didn?t use what I needed.)

I really like that we have javapackager and feel it is a very important addition to the JDK.  

I too would love if it could build for multiple platforms from a single platform, but I honestly don?t see that happening. It isn?t worth the trouble or effort - things like making a HFS+ .dmg for macOS from Windows isn?t realistic. We do NOT want some custom non-native installer (Though a .zip of an app bundle might work.)  You would also need the native bits of the JRE for each platform anyway. It would be possible to have those files available on any platform, but the tools to build .deb, .rpm, .dmg, .msi, etc. are just never going to be available everywhere.

Scott

> On Nov 30, 2017, at 7:16 PM, Kevin Rushforth  wrote:
> 
> Hi Michael,
> 
> We realized that the javapackger CLI JEP wasn't quite ready, and was out of scope for JDK 10 anyway, so we withdrew it in order to file a new JEP later.
> 
> Related to this, we are soliciting input as to how people are using the javapackager (see Victor's question below).
> 
> So we'd love to hear how you and others are using it, and for what kind of applications.
> 
> -- Kevin
> 
> 
> Michael Hall wrote:
>>> On Nov 29, 2017, at 5:18 PM, victor.drozdov at oracle.com wrote:
>>> 
>>> Hi, Mani.
>>> 
>>> Thanks for providing the feedback!
>>> We will consider adding more examples and more details in the docs as you proposed(there is an arg named jvmOptions but that's not mentioned in the table).
>>> Looks like there is a bug when you specify systemWide=true on the MacOSX in non-gui mode. Can you provide more details about that (like full cmd line)?
>>> Actually, if you want you can clone the repo:
>>> http://hg.openjdk.java.net/openjfx/10-dev/rt/
>>> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
>>> and help to improve javapackager. Or you can just create Enhancements for deploy/packager, as it's not always clear what users expect.
>>> 
>>>    
>> 
>> Why was JEP 311 [1] Closed/Withdrawn?
>> 
>> [1] http://openjdk.java.net/jeps/311
>> 
>>  

From kevin.rushforth at oracle.com  Fri Dec  1 13:02:57 2017
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 01 Dec 2017 05:02:57 -0800
Subject: PLEASE READ: OpenJFX developer repos + JDK 10 RDP1 deadlines
In-Reply-To: <5A1DD8BE.5090009@oracle.com>
References: <5A1DD8BE.5090009@oracle.com>
Message-ID: <5A215301.9010609@oracle.com>

As a reminder, the repo renaming is happening starting this Sunday 
evening, Dec 3, at 8pm Pacific. I will send email on Monday when the new 
jfx-dev repo is open for business.

-- Kevin

Kevin Rushforth wrote:
> To: All OpenJFX developers
>
> There are two related items that you need to be aware of, so please 
> read this if you are a developer of OpenJFX.
>
> Executive summary:
>
> 1. To match the JDK project, which has a persistent, 
> non-release-specific mainline repo [1], the FX 10 and 10-dev repos 
> will be "renamed" to jfx and jfx-dev. Starting Monday, Dec 4 all fixes 
> for FX should be pushed to jfx-dev/rt rather than 10-dev/rt.
>
> 2. As a reminder, the JDK 10 RDP1 milestone is coming up on Dec 14 
> [2]. All bug fixes and RFEs planned for 10 should be pushed by that 
> date. We will fork the repo at that time and only approved fixes will 
> go into JDK 10 after that point.
>
>
> Details:
>
> 1. Historically, the JDK has had separate development mainline repos 
> for each code line, and the OpenJFX project has followed this pattern. 
> Starting with JDK 10, development has switched to a model where the 
> development branch is persistent (that is, it doesn't change when a 
> new release is started) and is no longer release-specific. So there is 
> a jdk project with a jdk mainline repo [1], and no longer a jdk10 
> mainline repo. We will start following this for the OpenJFX project, too.
>
> We will "effectively rename" the FX 10-dev (and 10 [master]) repos to 
> jfx-dev (and jfx [master]). I use the term "effectively rename", 
> because what we will actually do is clone a new jfx-dev repo from 
> 10-dev and make 10-dev read-only. This is because we will shortly need 
> a new forked repo for 10 stabilization, so it is easier to do this 
> than delete and recreate it.
>
> The end result will be that for developers, the place you push fixes 
> going forward will always be "jfx-dev/rt" rather than "10-dev/rt" and 
> then "11-dev/rt" and then ...
>
> The planned timeline for the switchover is:
>
> Sunday, Dec 3
>
> * The openjfx 10-dev forest will be made read only at 8:00 pm Pacific 
> time on Sunday. If you have a fix that you want in before Monday, then 
> you need to push it no later than 7:59 pm (Pacific) Sunday night.
>
> * The jfx-dev forest will be cloned from 10-dev (and the jfx [master] 
> forest will be cloned from 10 [master])
>
> Monday, Dec 4
>
> * Once this is done and tested, I will send out email announcing that 
> it is open for pushing. I expect that this will happen early Monday 
> morning (Pacific time). Once the repo is open, developers will need to 
> edit their .hgrc files to point to the new jfx-dev forest instead of 
> 10-dev.
>
>
> 2. As a reminder, the JDK 10 RDP1 milestone is coming up on Dec 14 
> [2]. All bug fixes and RFEs planned for 10 should be pushed by that 
> date. We will fork the repo at that time; only approved fixes will go 
> into JDK 10 after that point. The guidelines are that only P1-P3 bugs 
> will be considered for inclusion into JDK 10 during RDP1, and not all 
> P3 bugs will be taken.  Generally developers focus on getting a fix 
> into the mainline, and it will make the next available train. Once the 
> 10 stabilization repo has forked, the next train will be 11.
>
> I expect that more guidance will be given on the jdk-dev mailing list 
> as for the processes and policies surrounding this.
>
> -- Kevin
>
> [1] http://hg.openjdk.java.net/jdk/jdk/
>
> [2] http://openjdk.java.net/projects/jdk/10/
>

From bourges.laurent at gmail.com  Fri Dec  1 14:14:44 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 1 Dec 2017 15:14:44 +0100
Subject: PLEASE READ: OpenJFX developer repos + JDK 10 RDP1 deadlines
In-Reply-To: <5A1DD8BE.5090009@oracle.com>
References: <5A1DD8BE.5090009@oracle.com>
Message-ID: 

Kevin,

To be sure, does it mean OpenJFX 10 changes are due to dec 14th ie for
JDK10 RDP1 ?

I would like to provide MarlinFX 0.8.2 for jfx10 but the remaining time is
short for the web review to happen... and the RFR Marlin 0.8.2 patch for
Java2d is submitted but no comment yet.

Should I submit an openjfx 10 patch for monday ?

Cheers,
Laurent

Le 28 nov. 2017 22:44, "Kevin Rushforth"  a
?crit :

> To: All OpenJFX developers
>
> There are two related items that you need to be aware of, so please read
> this if you are a developer of OpenJFX.
>
> Executive summary:
>
> 1. To match the JDK project, which has a persistent, non-release-specific
> mainline repo [1], the FX 10 and 10-dev repos will be "renamed" to jfx and
> jfx-dev. Starting Monday, Dec 4 all fixes for FX should be pushed to
> jfx-dev/rt rather than 10-dev/rt.
>
> 2. As a reminder, the JDK 10 RDP1 milestone is coming up on Dec 14 [2].
> All bug fixes and RFEs planned for 10 should be pushed by that date. We
> will fork the repo at that time and only approved fixes will go into JDK 10
> after that point.
>
>
> Details:
>
> 1. Historically, the JDK has had separate development mainline repos for
> each code line, and the OpenJFX project has followed this pattern. Starting
> with JDK 10, development has switched to a model where the development
> branch is persistent (that is, it doesn't change when a new release is
> started) and is no longer release-specific. So there is a jdk project with
> a jdk mainline repo [1], and no longer a jdk10 mainline repo. We will start
> following this for the OpenJFX project, too.
>
> We will "effectively rename" the FX 10-dev (and 10 [master]) repos to
> jfx-dev (and jfx [master]). I use the term "effectively rename", because
> what we will actually do is clone a new jfx-dev repo from 10-dev and make
> 10-dev read-only. This is because we will shortly need a new forked repo
> for 10 stabilization, so it is easier to do this than delete and recreate
> it.
>
> The end result will be that for developers, the place you push fixes going
> forward will always be "jfx-dev/rt" rather than "10-dev/rt" and then
> "11-dev/rt" and then ...
>
> The planned timeline for the switchover is:
>
> Sunday, Dec 3
>
> * The openjfx 10-dev forest will be made read only at 8:00 pm Pacific time
> on Sunday. If you have a fix that you want in before Monday, then you need
> to push it no later than 7:59 pm (Pacific) Sunday night.
>
> * The jfx-dev forest will be cloned from 10-dev (and the jfx [master]
> forest will be cloned from 10 [master])
>
> Monday, Dec 4
>
> * Once this is done and tested, I will send out email announcing that it
> is open for pushing. I expect that this will happen early Monday morning
> (Pacific time). Once the repo is open, developers will need to edit their
> .hgrc files to point to the new jfx-dev forest instead of 10-dev.
>
>
> 2. As a reminder, the JDK 10 RDP1 milestone is coming up on Dec 14 [2].
> All bug fixes and RFEs planned for 10 should be pushed by that date. We
> will fork the repo at that time; only approved fixes will go into JDK 10
> after that point. The guidelines are that only P1-P3 bugs will be
> considered for inclusion into JDK 10 during RDP1, and not all P3 bugs will
> be taken.  Generally developers focus on getting a fix into the mainline,
> and it will make the next available train. Once the 10 stabilization repo
> has forked, the next train will be 11.
>
> I expect that more guidance will be given on the jdk-dev mailing list as
> for the processes and policies surrounding this.
>
> -- Kevin
>
> [1] http://hg.openjdk.java.net/jdk/jdk/
>
> [2] http://openjdk.java.net/projects/jdk/10/
>
>

From kevin.rushforth at oracle.com  Fri Dec  1 14:16:43 2017
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 01 Dec 2017 06:16:43 -0800
Subject: PLEASE READ: OpenJFX developer repos + JDK 10 RDP1 deadlines
In-Reply-To: 
References: <5A1DD8BE.5090009@oracle.com>
 
Message-ID: <5A21644B.4080708@oracle.com>

Yes, this is the deadline for JDK 10 changes, both to core JDK (e.g., 
2D) and FX.

You can submit the openjfx 10 patch if you like, but I will wait until 
the 2D webrev is done being reviewed before acting on it. I note that it 
is a very large patch...

-- Kevin


Laurent Bourg?s wrote:
> Kevin,
>
> To be sure, does it mean OpenJFX 10 changes are due to dec 14th ie for 
> JDK10 RDP1 ?
>
> I would like to provide MarlinFX 0.8.2 for jfx10 but the remaining 
> time is short for the web review to happen... and the RFR Marlin 0.8.2 
> patch for Java2d is submitted but no comment yet. 
>
> Should I submit an openjfx 10 patch for monday ? 
>
> Cheers,
> Laurent
>
> Le 28 nov. 2017 22:44, "Kevin Rushforth"  > a ?crit :
>
>     To: All OpenJFX developers
>
>     There are two related items that you need to be aware of, so
>     please read this if you are a developer of OpenJFX.
>
>     Executive summary:
>
>     1. To match the JDK project, which has a persistent,
>     non-release-specific mainline repo [1], the FX 10 and 10-dev repos
>     will be "renamed" to jfx and jfx-dev. Starting Monday, Dec 4 all
>     fixes for FX should be pushed to jfx-dev/rt rather than 10-dev/rt.
>
>     2. As a reminder, the JDK 10 RDP1 milestone is coming up on Dec 14
>     [2]. All bug fixes and RFEs planned for 10 should be pushed by
>     that date. We will fork the repo at that time and only approved
>     fixes will go into JDK 10 after that point.
>
>
>     Details:
>
>     1. Historically, the JDK has had separate development mainline
>     repos for each code line, and the OpenJFX project has followed
>     this pattern. Starting with JDK 10, development has switched to a
>     model where the development branch is persistent (that is, it
>     doesn't change when a new release is started) and is no longer
>     release-specific. So there is a jdk project with a jdk mainline
>     repo [1], and no longer a jdk10 mainline repo. We will start
>     following this for the OpenJFX project, too.
>
>     We will "effectively rename" the FX 10-dev (and 10 [master]) repos
>     to jfx-dev (and jfx [master]). I use the term "effectively
>     rename", because what we will actually do is clone a new jfx-dev
>     repo from 10-dev and make 10-dev read-only. This is because we
>     will shortly need a new forked repo for 10 stabilization, so it is
>     easier to do this than delete and recreate it.
>
>     The end result will be that for developers, the place you push
>     fixes going forward will always be "jfx-dev/rt" rather than
>     "10-dev/rt" and then "11-dev/rt" and then ...
>
>     The planned timeline for the switchover is:
>
>     Sunday, Dec 3
>
>     * The openjfx 10-dev forest will be made read only at 8:00 pm
>     Pacific time on Sunday. If you have a fix that you want in before
>     Monday, then you need to push it no later than 7:59 pm (Pacific)
>     Sunday night.
>
>     * The jfx-dev forest will be cloned from 10-dev (and the jfx
>     [master] forest will be cloned from 10 [master])
>
>     Monday, Dec 4
>
>     * Once this is done and tested, I will send out email announcing
>     that it is open for pushing. I expect that this will happen early
>     Monday morning (Pacific time). Once the repo is open, developers
>     will need to edit their .hgrc files to point to the new jfx-dev
>     forest instead of 10-dev.
>
>
>     2. As a reminder, the JDK 10 RDP1 milestone is coming up on Dec 14
>     [2]. All bug fixes and RFEs planned for 10 should be pushed by
>     that date. We will fork the repo at that time; only approved fixes
>     will go into JDK 10 after that point. The guidelines are that only
>     P1-P3 bugs will be considered for inclusion into JDK 10 during
>     RDP1, and not all P3 bugs will be taken.  Generally developers
>     focus on getting a fix into the mainline, and it will make the
>     next available train. Once the 10 stabilization repo has forked,
>     the next train will be 11.
>
>     I expect that more guidance will be given on the jdk-dev mailing
>     list as for the processes and policies surrounding this.
>
>     -- Kevin
>
>     [1] http://hg.openjdk.java.net/jdk/jdk/
>     
>
>     [2] http://openjdk.java.net/projects/jdk/10/
>     
>

From sverre.moe at gmail.com  Fri Dec  1 17:37:34 2017
From: sverre.moe at gmail.com (Sverre Moe)
Date: Fri, 1 Dec 2017 18:37:34 +0100
Subject: javapackager feedback and questions
Message-ID: 

We are using the javapackager through the gradle/maven javafx plugin, to create:
* Executable JAR: When we went from Swing to JavaFX the maven jar
plugin could not create an executable JAR capable to start the JavaFX
Application.
* Native executable bundle: RPM (Linux), EXE (Windows), PKG (Mac)
* Java Web Start bundle

/Sverre

> Date: Thu, 30 Nov 2017 16:16:19 -0800
> From: Kevin Rushforth 
> To: Michael Hall 
> Cc: "jdk9-dev at openjdk.java.net" ,
>         "openjfx-dev at openjdk.java.net" , Mani
>         Sarkar 
> Subject: Re: javapackager feedback and questions
> Message-ID: <5A209F53.6080707 at oracle.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Michael,
>
> We realized that the javapackger CLI JEP wasn't quite ready, and was out
> of scope for JDK 10 anyway, so we withdrew it in order to file a new JEP
> later.
>
> Related to this, we are soliciting input as to how people are using the
> javapackager (see Victor's question below).
>
> So we'd love to hear how you and others are using it, and for what kind
> of applications.
>
> -- Kevin
>
>
> Michael Hall wrote:
> >> On Nov 29, 2017, at 5:18 PM, victor.drozdov at oracle.com wrote:
> >>
> >> Hi, Mani.
> >>
> >> Thanks for providing the feedback!
> >> We will consider adding more examples and more details in the docs as you proposed(there is an arg named jvmOptions but that's not mentioned in the table).
> >> Looks like there is a bug when you specify systemWide=true on the MacOSX in non-gui mode. Can you provide more details about that (like full cmd line)?
> >> Actually, if you want you can clone the repo:
> >> http://hg.openjdk.java.net/openjfx/10-dev/rt/
> >> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
> >> and help to improve javapackager. Or you can just create Enhancements for deploy/packager, as it's not always clear what users expect.
> >>
> >>
> >
> > Why was JEP 311 [1] Closed/Withdrawn?
> >
> > [1] http://openjdk.java.net/jeps/311
> >
> >

From victor.drozdov at oracle.com  Sat Dec  2 01:43:34 2017
From: victor.drozdov at oracle.com (victor.drozdov at oracle.com)
Date: Fri, 1 Dec 2017 17:43:34 -0800
Subject: [10] Review request: 8179033: javapackager fails to create Mac
 Application Bundle
Message-ID: 

Kevin,

Please review the changes about copying classpath entries on Mac and 
Windows.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033
Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8179033/webrev.00/

--Victor





From mik3hall at gmail.com  Sat Dec  2 14:16:33 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 2 Dec 2017 08:16:33 -0600
Subject: [10] Review request: 8179033: javapackager fails to create Mac
 Application Bundle
In-Reply-To: 
References: 
Message-ID: 


> On Dec 1, 2017, at 7:43 PM, victor.drozdov at oracle.com wrote:
> 
> Kevin,
> 
> Please review the changes about copying classpath entries on Mac and Windows.
> 
> JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033
> Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8179033/webrev.00/ 

Sorry, to comment on this when it is not my place. 
But I had looked at this sometime ago and it made no sense.
For the Mac you have?

-                Files.copy(new File(srcdir, fname).toPath(), new File(javaDirectory.toFile(), fname).toPath());
+                writeEntry(new FileInputStream(new File(srcdir, fname)),
+                           new File(javaDirectory.toFile(), fname).toPath());

What is the difference here? You are just changing the method of writing the file. Otherwise locations are identical.
Assuming the first way isn?t working, why would the second way do better?


From kevin.rushforth at oracle.com  Sat Dec  2 14:31:14 2017
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 02 Dec 2017 06:31:14 -0800
Subject: [10] Review request: 8179033: javapackager fails to create Mac
 Application Bundle
In-Reply-To: 
References: 
 
Message-ID: <5A22B932.3050403@oracle.com>



Michael Hall wrote:
>
>> On Dec 1, 2017, at 7:43 PM, victor.drozdov at oracle.com 
>>  wrote:
>>
>> Kevin,
>>
>> Please review the changes about copying classpath entries on Mac and 
>> Windows.
>>
>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033
>> Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8179033/webrev.00/ 
>> 
>
> Sorry, to comment on this when it is not my place. 
> But I had looked at this sometime ago and it made no sense.
> For the Mac you have?
>
> -                Files.copy(new File(srcdir, fname).toPath(), new 
> File(javaDirectory.toFile(), fname).toPath());
> +                writeEntry(new FileInputStream(new File(srcdir, fname)),
> +                           new File(javaDirectory.toFile(), 
> fname).toPath());
>
> What is the difference here? You are just changing the method of 
> writing the file. Otherwise locations are identical.
> Assuming the first way isn?t working, why would the second way do better?
>

writeEntry creates the directory before copying (and also opens the file 
using an InputStream, but its the former that is the main part of the fix).

-- Kevin


From mik3hall at gmail.com  Sat Dec  2 15:09:43 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 2 Dec 2017 09:09:43 -0600
Subject: [10] Review request: 8179033: javapackager fails to create Mac
 Application Bundle
In-Reply-To: <5A22B932.3050403@oracle.com>
References: 
 
 <5A22B932.3050403@oracle.com>
Message-ID: <46CD6E2E-7E52-4878-BDDA-E0FCABDCBB09@gmail.com>


> On Dec 2, 2017, at 8:31 AM, Kevin Rushforth  wrote:
> 
> 
> 
> Michael Hall wrote:
>> 
>> 
>>> On Dec 1, 2017, at 7:43 PM, victor.drozdov at oracle.com  wrote:
>>> 
>>> Kevin,
>>> 
>>> Please review the changes about copying classpath entries on Mac and Windows.
>>> 
>>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033 
>>> Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8179033/webrev.00/ 
>> 
>> Sorry, to comment on this when it is not my place. 
>> But I had looked at this sometime ago and it made no sense.
>> For the Mac you have?
>> 
>> -                Files.copy(new File(srcdir, fname).toPath(), new File(javaDirectory.toFile(), fname).toPath());
>> +                writeEntry(new FileInputStream(new File(srcdir, fname)),
>> +                           new File(javaDirectory.toFile(), fname).toPath());
>> 
>> What is the difference here? You are just changing the method of writing the file. Otherwise locations are identical.
>> Assuming the first way isn?t working, why would the second way do better?
>> 
> 
> writeEntry creates the directory before copying (and also opens the file using an InputStream, but its the former that is the main part of the fix).
> 
I had just noticed that was different and wondered if it was the fix. 
Which is fine.
Although maybe creating the directory and then do the Files.copy might be clearer rather than someone later trying to figure out what makes the writeEntry call necessary.


From kevin.rushforth at oracle.com  Sat Dec  2 15:11:51 2017
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 02 Dec 2017 07:11:51 -0800
Subject: [10] Review request: 8179033: javapackager fails to create Mac
 Application Bundle
In-Reply-To: <46CD6E2E-7E52-4878-BDDA-E0FCABDCBB09@gmail.com>
References: 
 
 <5A22B932.3050403@oracle.com>
 <46CD6E2E-7E52-4878-BDDA-E0FCABDCBB09@gmail.com>
Message-ID: <5A22C2B7.90103@oracle.com>



Michael Hall wrote:
>
>> On Dec 2, 2017, at 8:31 AM, Kevin Rushforth 
>> > wrote:
>>
>>
>>
>> Michael Hall wrote:
>>>
>>>> On Dec 1, 2017, at 7:43 PM, victor.drozdov at oracle.com 
>>>>  wrote:
>>>>
>>>> Kevin,
>>>>
>>>> Please review the changes about copying classpath entries on Mac 
>>>> and Windows.
>>>>
>>>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033
>>>> Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8179033/webrev.00/ 
>>>> 
>>>
>>> Sorry, to comment on this when it is not my place. 
>>> But I had looked at this sometime ago and it made no sense.
>>> For the Mac you have?
>>>
>>> -                Files.copy(new File(srcdir, fname).toPath(), new 
>>> File(javaDirectory.toFile(), fname).toPath());
>>> +                writeEntry(new FileInputStream(new File(srcdir, 
>>> fname)),
>>> +                           new File(javaDirectory.toFile(), 
>>> fname).toPath());
>>>
>>> What is the difference here? You are just changing the method of 
>>> writing the file. Otherwise locations are identical.
>>> Assuming the first way isn?t working, why would the second way do 
>>> better?
>>>
>>
>> writeEntry creates the directory before copying (and also opens the 
>> file using an InputStream, but its the former that is the main part 
>> of the fix).
>>
> I had just noticed that was different and wondered if it was the fix. 
> Which is fine.
> Although maybe creating the directory and then do the Files.copy might 
> be clearer rather than someone later trying to figure out what makes 
> the writeEntry call necessary.
>

Perhaps Victor can comment about this. Since many of the other copy 
operations also use writeEntry, it seems fine to me.

-- Kevin


From mik3hall at gmail.com  Sat Dec  2 15:18:45 2017
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 2 Dec 2017 09:18:45 -0600
Subject: [10] Review request: 8179033: javapackager fails to create Mac
 Application Bundle
In-Reply-To: <5A22C2B7.90103@oracle.com>
References: 
 
 <5A22B932.3050403@oracle.com>
 <46CD6E2E-7E52-4878-BDDA-E0FCABDCBB09@gmail.com> <5A22C2B7.90103@oracle.com>
Message-ID: 


> On Dec 2, 2017, at 9:11 AM, Kevin Rushforth  wrote:
> 
> 
> 
> Michael Hall wrote:
>> 
>> 
>>> On Dec 2, 2017, at 8:31 AM, Kevin Rushforth > wrote:
>>> 
>>> 
>>> 
>>> Michael Hall wrote:
>>>> 
>>>> 
>>>>> On Dec 1, 2017, at 7:43 PM, victor.drozdov at oracle.com  wrote:
>>>>> 
>>>>> Kevin,
>>>>> 
>>>>> Please review the changes about copying classpath entries on Mac and Windows.
>>>>> 
>>>>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033 
>>>>> Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8179033/webrev.00/ 
>>>> 
>>>> Sorry, to comment on this when it is not my place. 
>>>> But I had looked at this sometime ago and it made no sense.
>>>> For the Mac you have?
>>>> 
>>>> -                Files.copy(new File(srcdir, fname).toPath(), new File(javaDirectory.toFile(), fname).toPath());
>>>> +                writeEntry(new FileInputStream(new File(srcdir, fname)),
>>>> +                           new File(javaDirectory.toFile(), fname).toPath());
>>>> 
>>>> What is the difference here? You are just changing the method of writing the file. Otherwise locations are identical.
>>>> Assuming the first way isn?t working, why would the second way do better?
>>>> 
>>> 
>>> writeEntry creates the directory before copying (and also opens the file using an InputStream, but its the former that is the main part of the fix).
>>> 
>> I had just noticed that was different and wondered if it was the fix. 
>> Which is fine.
>> Although maybe creating the directory and then do the Files.copy might be clearer rather than someone later trying to figure out what makes the writeEntry call necessary.
>> 
> 
> Perhaps Victor can comment about this. Since many of the other copy operations also use writeEntry, it seems fine to me.

If it is normally used to ensure the directory is there this would probably be something people more familiar with the code would know.

Thanks.


From mike.ennen at gmail.com  Sun Dec  3 21:29:49 2017
From: mike.ennen at gmail.com (Michael Ennen)
Date: Sun, 3 Dec 2017 14:29:49 -0700
Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API
Message-ID: 

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/4ccdbbbce5234e2c5e1f4f1cb8f20430feaa53b6...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/openjfx/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/javafx.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/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java -- Michael Ennen From mike.ennen at gmail.com Sun Dec 3 23:25:33 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Sun, 3 Dec 2017 16:25:33 -0700 Subject: Error on build In-Reply-To: <2899cf9de5a9caeabe9c3628bd687e1e.startmail@www.startmail.com> References: <2899cf9de5a9caeabe9c3628bd687e1e.startmail@www.startmail.com> Message-ID: Try changing line 275 of the root build.gradle from: ext.IS_64 = OS_ARCH.toLowerCase().contains("64") to: ext.IS_64 = true On Sun, Oct 8, 2017 at 6:24 PM, wrote: > Hi, > > I possess an AMD 64 bit machine. > > My JDK_HOME points to a 64 bit JDK. > > MS C++ redistributables reported as installed on my machine (determined by > control panel -> uninstall a program -> reviewing resulting list of > installed sw) report both 32 and 64 installations. > > MS VS was installed as I reported below. > > AFAIK Cygwin is not versioned x86 or 64-bit or if it is (can't actually > recall) it cannot effect the result of the build. > > Are they any other factors at play I am unaware of? > > Cheers. > > > On Sunday, October 8, 2017 6:45 AM, David Bimamisa < > ketchxup at googlemail.com> wrote: > > >> Which version of JDK are you using? 64-bit or 32-bit? >> I remember getting these types of errors only if there was a mismatch >> between the JDK and c++ compiler machine type >> As noted in wiki: "the version of the JDK you have set as JDK_HOME will >> determine whether you build 32 or 64 bit binaries" >> >> >> Regards >> David >> >> 2017-10-07 1:09 GMT+02:00 : >> >>> This is the result of using *VS 2017 CE- every option selected, >>> downloaded and installed* >>> >>> I would say there is an external symbol _fltused (float used?) and a >>> few other such errors and also the assumption that the builder is on a 32 >>> bit machine ?? (see final error). >>> >>> >>> _fltused >>> __GSHandlerCheck >>> __security_check_cookie >>> powf >>> __imp_IsProcessorFeaturePresent >>> _DllMainCRTStartup >>> >>> and >>> >>> C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/LIB\MSVCRT.lib : >>> warning LNK4272: library machine type 'X86' conflicts with target machine >>> type 'x64' >>> C:\cygwin64\home\mdbg\rt\modules\javafx.graphics\build\libs\jsl-decora\win\decora_sse.dll >>> : fatal error LNK1120: 7 unresolved externals >>> :graphics:linkDecoraNativeShadersWin FAILED >>> >>> >>> MS Studio 2017 CE doesn't ask you if you want a 32 bit or 64 bit >>> installation, only WHERE you want it installed. >>> >>> The user choice of Program Files vs Program FIles x(86 ) might >>> constitute a choice of sorts so after failing with the default x86 place, I >>> uninstalled everything and tried the other only to have it fail much >>> sooner. The first fail (x86) actually got through building part or most of >>> .graphics, which gave me false hope. >>> >>> That non-question usually means the install itself knows what to do or >>> has a preference and in this context especially - VS 2017,install- should >>> not lead to x86 vs 64 bit type problems . >>> >>> Also, the instructions on the wiki , outdated I am told, also say the >>> default project is sdk. I do not think this is the case. It seems mandatory >>> to type "sdk" after gradle to hit the sdk build task. >>> >>> Any help or experiences from anyone is much appreciated. >>> >>> >>> >>> Full output: >>> >>> SSEPhongLighting_POINTPeer.obj : error LNK2001: unresolved external >>> symbol _fltused >>> SSEPhongLighting_SPOTPeer.obj : error LNK2001: unresolved external >>> symbol _fltused >>> SSESepiaTonePeer.obj : error LNK2001: unresolved external symbol _fltused >>> SSEUtils.obj : error LNK2001: unresolved external symbol _fltused >>> SSELinearConvolvePeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSELinearConvolveShadowPeer.obj : error LNK2001: unresolved external >>> symbol _fltused >>> SSEPerspectiveTransformPeer.obj : error LNK2001: unresolved external >>> symbol _fltused >>> SSEPhongLighting_DISTANTPeer.obj : error LNK2001: unresolved external >>> symbol _fltused >>> SSEBrightpassPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEColorAdjustPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEDisplacementMapPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEInvertMaskPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_SRC_INPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_SRC_OUTPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_SRC_OVERPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBoxShadowPeer.obj : error LNK2001: unresolved external symbol _fltused >>> SSEBlend_REDPeer.obj : error LNK2001: unresolved external symbol _fltused >>> SSEBlend_SCREENPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_SOFT_LIGHTPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_SRC_ATOPPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_HARD_LIGHTPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_LIGHTENPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_MULTIPLYPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_OVERLAYPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_DARKENPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_DIFFERENCEPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_EXCLUSIONPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_GREENPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_ADDPeer.obj : error LNK2001: unresolved external symbol _fltused >>> SSEBlend_BLUEPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_COLOR_BURNPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> SSEBlend_COLOR_DODGEPeer.obj : error LNK2001: unresolved external symbol >>> _fltused >>> >>> SSEPerspectiveTransformPeer.obj : error LNK2001: unresolved external >>> symbol __GSHandlerCheck >>> SSEBoxShadowPeer.obj : error LNK2001: unresolved external symbol >>> __GSHandlerCheck >>> SSEDisplacementMapPeer.obj : error LNK2001: unresolved external symbol >>> __GSHandlerCheck >>> SSELinearConvolvePeer.obj : error LNK2001: unresolved external symbol >>> __GSHandlerCheck >>> SSELinearConvolveShadowPeer.obj : error LNK2001: unresolved external >>> symbol __GSHandlerCheck >>> >>> SSEPerspectiveTransformPeer.obj : error LNK2001: unresolved external >>> symbol __security_check_cookie >>> SSEBoxShadowPeer.obj : error LNK2001: unresolved external symbol >>> __security_check_cookie >>> SSEDisplacementMapPeer.obj : error LNK2001: unresolved external symbol >>> __security_check_cookie >>> SSELinearConvolvePeer.obj : error LNK2001: unresolved external symbol >>> __security_check_cookie >>> SSELinearConvolveShadowPeer.obj : error LNK2001: unresolved external >>> symbol __security_check_cookie >>> SSEPerspectiveTransformPeer.obj : error LNK2001: unresolved external >>> symbol __security_cookie >>> SSEBoxShadowPeer.obj : error LNK2001: unresolved external symbol >>> __security_cookie >>> SSEDisplacementMapPeer.obj : error LNK2001: unresolved external symbol >>> __security_cookie >>> SSELinearConvolvePeer.obj : error LNK2001: unresolved external symbol >>> __security_cookie >>> SSELinearConvolveShadowPeer.obj : error LNK2001: unresolved external >>> symbol __security_cookie >>> >>> SSEPhongLighting_DISTANTPeer.obj : error LNK2019: unresolved external >>> symbol powf referenced in function Java_com_sun_scenario_effect_i >>> mpl_sw_sse_SSEPhongLighting_1DISTANTPeer_filter >>> SSEPhongLighting_POINTPeer.obj : error LNK2001: unresolved external >>> symbol powf >>> SSEPhongLighting_SPOTPeer.obj : error LNK2001: unresolved external >>> symbol powf >>> >>> SSEUtils.obj : error LNK2019: unresolved external symbol >>> __imp_IsProcessorFeaturePresent referenced in function >>> Java_com_sun_scenario_effect_impl_sw_sse_SSERendererDelegate_isSupported >>> >>> LINK : error LNK2001: unresolved external symbol _DllMainCRTStartup >>> >>> C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/LIB\MSVCRT.lib : >>> warning LNK4272: library machine type 'X86' conflicts with target machine >>> type 'x64' >>> C:\cygwin64\home\mdbg\rt\modules\javafx.graphics\build\libs\jsl-decora\win\decora_sse.dll >>> : fatal error LNK1120: 7 unresolved externals >>> :graphics:linkDecoraNativeShadersWin FAILED >>> >>> >>> On Thursday, October 5, 2017 10:09 AM, David Bimamisa < >>> ketchxup at googlemail.com> wrote: >>> >>> >>>> Hi, >>>> >>>> I'm not sure whether DirectX is needed or not. So I stick with DirectX >>>> SDK >>>> (June 2010). >>>> But I think WINSDK is still needed since I got my build running only >>>> after >>>> installing Windows 10 SDK (shipped with visual studio 2017). >>>> However, I had to run the *vs_installer.ex*e again and go to "change" in >>>> order to customize my VS2017 installation. >>>> To get Windows 10 SDK installed, I added the workload "Desktop >>>> development with C++" (see Figure in https://docs.microsoft.com/ >>>> en-us/visualstudio/install/install-visual-studio) and selected the >>>> option >>>> "Toolset for visual C++" below in the right sided list (don't know if >>>> this >>>> is needed though) >>>> >>>> This is how my *build*/*windows_tools.properties *looks now: >>>> WINDOWS_VS_DEVENVDIR=C:/Program Files (x86)/Microsoft Visual >>>> Studio/2017/Community/Common7/IDE >>>> WINDOWS_VS_DEVENVCMD=C:/Program Files (x86)/Microsoft Visual >>>> Studio/2017/Community/Common7/IDE/devenv.com >>>> >>>> WINDOWS_VS_VCINSTALLDIR=C:/Program Files (x86)/Microsoft Visual >>>> Studio/2017/Community/VC >>>> WINDOWS_VS_VSINSTALLDIR=C:/Program Files (x86)/Microsoft Visual >>>> Studio/2017/Community >>>> WINDOWS_VS_MSVCDIR=C:/Program Files (x86)/Microsoft Visual >>>> Studio/2017/Community/VC >>>> WINDOWS_VS_INCLUDE=... >>>> WINDOWS_VS_LIB=... >>>> WINDOWS_VS_LIBPATH=... >>>> WINDOWS_VS_PATH=... >>>> WINDOWS_VS_VER=150 >>>> WINDOWS_SDK_DIR=C:/Program Files (x86)/Windows Kits/10 >>>> WINDOWS_SDK_VERSION=10.0.14393.0 >>>> >>>> Regards, >>>> David >>>> >>>> 2017-10-04 23:51 GMT+02:00 Chris Newland : >>>> >>>> >>>>> Thanks David. >>>>> >>>>> Do you know if the WINSDK and DirectX requirements are still as per the >>>>> wiki/docs or can later versions be used? >>>>> >>>>> Cheers, >>>>> >>>>> Chris >>>>> @chriswhocodes | JITWatch | DemoFX >>>>> >>>>> On Wed, October 4, 2017 13:15, David Bimamisa wrote: >>>>> > It should also work with the community version of VS2017 >>>>> > >>>>> > >>>>> > Regards >>>>> > David >>>>> > >>>>> > >>>>> > >>>>> > Am 03.10.2017 5:56 nachm. schrieb : >>>>> > >>>>> > >>>>> > VS 2017 Professional is now required to build OpenJFX. >>>>> > >>>>> >> >>>>> > Ahh I see. I am sure it needs every bit of power offered by the >>>>> > professional version of Microsoft's excellent dev environment but >>>>> > unfortunately it cuts me out of building or testing since I don't >>>>> have >>>>> > that subscription and it's really rather pricey. >>>>> > >>>>> > Cheers! >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >> >>>>> >> >>>>> > On Tuesday, October 3, 2017 9:43 AM, Kevin Rushforth < >>>>> > kevin.rushforth at oracle.com> wrote: >>>>> > >>>>> > >>>>> >> The Wiki is out of date. VS 2017 Professional is now required to >>>>> build >>>>> >> OpenJFX. A fix was just pushed [1] to allow a different build of VS >>>>> 2017 >>>>> >> than the hard-coded one. >>>>> >> >>>>> >> Also, I am still able to build with VS 2010 and VS 2013, which >>>>> should >>>>> >> work as long as you don't build media or webkit (they aren't built >>>>> by >>>>> >> default). >>>>> >> >>>>> >> -- Kevin >>>>> >> >>>>> >> >>>>> >> [1] https://bugs.openjdk.java.net/browse/JDK-8187366 >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> Chris Newland wrote: >>>>> >> >>>>> >> >>>>> >>> >>>>> >>> Hi, >>>>> >>> >>>>> >>> >>>>> >>> I'm also trying to build OpenJFX on Windows 10 so I can add a >>>>> >>> Windows >>>>> >>> build to my community OpenJFX build server at >>>>> >>> https://chriswhocodes.com >>>>> >>> and am hitting the same problems as you. >>>>> >>> >>>>> >>> Setting WINSDK_DIR on the command line using 'set' or 'export' >>>>> >>> doesn't work and neither does setting via the Windows environment >>>>> >>> manager UI. >>>>> >>> >>>>> >>> >>>>> >>> Hardcoding got me past this one: >>>>> >>> >>>>> >>> >>>>> >>> def WINDOWS_SDK_DIR="..." above the check. >>>>> >>> >>>>> >>> Next error I'm hitting is NativeCompileTask.compile() >>>>> >>> >>>>> >>> >>>>> >>> This is with Windows 10, VS10 Express, WinSDK 7.1, and DirectX June >>>>> >>> 2010. >>>>> >>> >>>>> >>> >>>>> >>> buildSrc/win.gradle has hardcoded paths to VS2017 Professional so >>>>> I'm >>>>> >>> guessing the devs who wrote this build script have got it working >>>>> on a >>>>> >>> more modern build environment than the one described in the docs. >>>>> >>> >>>>> >>> Will post here if I can get it to build. >>>>> >>> >>>>> >>> >>>>> >>> Cheers, >>>>> >>> >>>>> >>> >>>>> >>> Chris >>>>> >>> >>>>> >>> >>>>> >>> On Tue, October 3, 2017 02:14, javafx at use.startmail.com wrote: >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>>> >>>>> >>>> Hi again ! >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> Well I was able to track down the source of the error I am >>>>> >>>> receiving from the gradle build. Unfortunately, the error >>>>> persists, >>>>> >>>> which is a bit of a mystery. Maybe a gradle maven can enlighten me >>>>> >>>> here. >>>>> >>>> >>>>> >>>> For some reason, this line on line 90-91 of win.gradle is throwing >>>>> >>>> the exception, although I can prove it ought not to: if >>>>> >>>> (WINDOWS_SDK_DIR == >>>>> >>>> null || WINDOWS_SDK_DIR == "") { throw new GradleException("FAIL: >>>>> >>>> WINSDK_DIR not defined"); >>>>> >>>> I cannot get past this, the exception is triggered, and yet the >>>>> >>>> assignment of a value to property WINDOWS_SDK_DIR is quite clear >>>>> here >>>>> >>>> (line >>>>> >>>> of 69 win.gradle): defineProperty("WINDOWS_SDK_DIR", properties, >>>>> >>>> System.getenv().get("WINSDK_DIR")) >>>>> >>>> and that system variable is, in fact, set as proved by (my) >>>>> running >>>>> >>>> this simple program I wrote (which exists in the same directory as >>>>> >>>> win.gradle to exclude any conceivable path issues) and getting the >>>>> >>>> proper outputpublic class WinSDK { public WinSDK() { } public >>>>> static >>>>> >>>> void main(String[] args) { String sdk = >>>>> >>>> (String)System.getenv().get("WINSDK_DIR"); >>>>> >>>> System.out.println("sdk = " + sdk); >>>>> >>>> } >>>>> >>>> } >>>>> >>>> Output as expected- the proper path to Microsoft SDK and anyways >>>>> >>>> certainly not the empty string or null. >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> Sorry to ask such a basic question but is anyone on this list >>>>> >>>> actually able to clone then compile OpenFX from source using the >>>>> >>>> procedure outlined on the below mentioned page using any of the >>>>> >>>> gradle scripts, (in my instance gradle.win) ? >>>>> >>>> >>>>> >>>> Seems like first -step level stuff that is done regularly by >>>>> >>>> everyone on the list interested in improving or exploring OpenFX >>>>> but >>>>> >>>> maybe I am wrong about this? Many thanks in advance. >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> On Thursday, September 28, 2017 6:59 PM, >>>>> >>>> javafx at use.startmail.comwrote: >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>>> Hi All, >>>>> >>>>> New member to this group. I am encountering a little trouble >>>>> when >>>>> >>>>> I >>>>> >>>>> try to build OpenJFX. I am following the instructions here: >>>>> (using >>>>> >>>>> Cygwin >>>>> >>>>> on Win 7): >>>>> >>>>> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> When I run gradle after cloning the OpenJFX repository, I get a >>>>> >>>>> "build >>>>> >>>>> failed with exception" . I include the output from the entire run >>>>> >>>>> just in case it's significant: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> $ gradle >>>>> >>>>> WARNING: An illegal reflective access operation has occurred >>>>> >>>>> WARNING: Illegal reflective access by >>>>> >>>>> org.gradle.internal.reflect.JavaMethod >>>>> >>>>> (file:/C:/gradle/lib/gradle-base-services-3.1.jar) to method >>>>> >>>>> java.lang.ClassLoader.getPackages() WARNING: Please consider >>>>> >>>>> reporting this to the maintainers of >>>>> >>>>> org.gradle.internal.reflect.JavaMethod WARNING: Use >>>>> >>>>> --illegal-access=warn to enable warnings of further >>>>> >>>>> illegal reflective access operations WARNING: All illegal access >>>>> >>>>> operations will be denied in a future release >>>>> >>>>> :buildSrc:generateGrammarSource UP-TO-DATE >>>>> >>>>> :buildSrc:compileJava UP-TO-DATE >>>>> >>>>> :buildSrc:compileGroovy UP-TO-DATE >>>>> >>>>> :buildSrc:processResources UP-TO-DATE >>>>> >>>>> :buildSrc:classes UP-TO-DATE >>>>> >>>>> :buildSrc:jar UP-TO-DATE >>>>> >>>>> :buildSrc:assemble UP-TO-DATE >>>>> >>>>> :buildSrc:compileTestJava UP-TO-DATE >>>>> >>>>> :buildSrc:compileTestGroovy UP-TO-DATE >>>>> >>>>> :buildSrc:processTestResources UP-TO-DATE >>>>> >>>>> :buildSrc:testClasses UP-TO-DATE >>>>> >>>>> :buildSrc:test UP-TO-DATE >>>>> >>>>> :buildSrc:check UP-TO-DATE >>>>> >>>>> :buildSrc:build UP-TO-DATE >>>>> >>>>> FAILURE: Build failed with an exception. >>>>> >>>>> * Where: >>>>> >>>>> Script 'C:\cygwin64\home\mdbg\rt\buildSrc\win.gradle' line: 91 >>>>> >>>>> * What went wrong: >>>>> >>>>> A problem occurred evaluating script. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> FAIL: WINSDK_DIR not defined >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>> * Try: >>>>> >>>>> Run with --stacktrace option to get the stack trace. Run with >>>>> >>>>> --info >>>>> >>>>> or --debug option to get more log output. BUILD FAILED >>>>> >>>>> Total time: 1.376 secs >>>>> >>>>> I should add that even though the tutorial doesn't mention to do >>>>> >>>>> it, I >>>>> >>>>> cd-ed into the folder named rt, which was created by Mercurial >>>>> when >>>>> >>>>> I >>>>> >>>>> cloned OpenJFX, I called gradle from there. Calling it from the >>>>> >>>>> directory containing rt resulted in nothing happening , which >>>>> >>>>> makes sense afaik. the variable WINSDK is not one I am familiar >>>>> >>>>> with- it's not any environment or system variable on my machine >>>>> >>>>> and the tutorial doesn't say anything about it. I hesitate to >>>>> start >>>>> >>>>> arbitrarily hacking build files based on error messages. It seems >>>>> >>>>> as though it ought to just work and perhaps this is a bug I >>>>> should >>>>> >>>>> report or is it something else ? >>>>> >>>>> Thank you! >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>>> >>> >>>>> >> >>>>> > >>>>> >>>>> >>>>> >>>> -- Michael Ennen From mike.ennen at gmail.com Sun Dec 3 23:48:08 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Sun, 3 Dec 2017 16:48:08 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: Message-ID: 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/4ccdbbbce5234e2c5e1f4f1cb8f204 > 30feaa53b6...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/ > openjfx/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/ > javafx.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/ > javafx.graphics/src/main/java/javafx/scene/robot/Robot.java > > > -- > Michael Ennen > -- Michael Ennen From victor.drozdov at oracle.com Mon Dec 4 05:12:07 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Sun, 3 Dec 2017 21:12:07 -0800 Subject: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle In-Reply-To: <5A22C2B7.90103@oracle.com> References: <5A22B932.3050403@oracle.com> <46CD6E2E-7E52-4878-BDDA-E0FCABDCBB09@gmail.com> <5A22C2B7.90103@oracle.com> Message-ID: <6e01b3f3-2e48-fdae-4a3e-80fcbef36bf5@oracle.com> On 12/2/17 7:11 AM, Kevin Rushforth wrote: > > > Michael Hall wrote: >> >>> On Dec 2, 2017, at 8:31 AM, Kevin Rushforth >>> > wrote: >>> >>> >>> >>> Michael Hall wrote: >>>> >>>>> On Dec 1, 2017, at 7:43 PM, victor.drozdov at oracle.com >>>>> wrote: >>>>> >>>>> Kevin, >>>>> >>>>> Please review the changes about copying classpath entries on Mac >>>>> and Windows. >>>>> >>>>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~vdrozdov/JDK-8179033/webrev.00/ >>>>> >>>> >>>> Sorry, to comment on this when it is not my place. >>>> But I had looked at this sometime ago and it made no sense. >>>> For the Mac you have? >>>> >>>> - Files.copy(new File(srcdir, fname).toPath(), new >>>> File(javaDirectory.toFile(), fname).toPath()); >>>> + writeEntry(new FileInputStream(new File(srcdir, >>>> fname)), >>>> + new File(javaDirectory.toFile(), >>>> fname).toPath()); >>>> >>>> What is the difference here? You are just changing the method of >>>> writing the file. Otherwise locations are identical. >>>> Assuming the first way isn?t working, why would the second way do >>>> better? >>>> >>> >>> writeEntry creates the directory before copying (and also opens the >>> file using an InputStream, but its the former that is the main part >>> of the fix). >>> >> I had just noticed that was different and wondered if it was the fix. >> Which is fine. >> Although maybe creating the directory and then do the Files.copy >> might be clearer rather than someone later trying to figure out what >> makes the writeEntry call necessary. >> > > Perhaps Victor can comment about this. Since many of the other copy > operations also use writeEntry, it seems fine to me. > > -- Kevin > writeEntry() is supposed to be used for the operations where we need to create a directory and then do Files.copy(). I see no reason to avoid using it here. Linux bundler is also implemented this way. / private void writeEntry(InputStream in, Path dstFile) throws IOException {// // Files.createDirectories(dstFile.getParent());// // Files.copy(in, dstFile);// // }/ --Victor From mik3hall at gmail.com Mon Dec 4 08:40:14 2017 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 4 Dec 2017 02:40:14 -0600 Subject: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle In-Reply-To: <6e01b3f3-2e48-fdae-4a3e-80fcbef36bf5@oracle.com> References: <5A22B932.3050403@oracle.com> <46CD6E2E-7E52-4878-BDDA-E0FCABDCBB09@gmail.com> <5A22C2B7.90103@oracle.com> <6e01b3f3-2e48-fdae-4a3e-80fcbef36bf5@oracle.com> Message-ID: <4DBBA20D-06B1-4C12-B465-A38F3B277212@gmail.com> > On Dec 3, 2017, at 11:12 PM, victor.drozdov at oracle.com wrote: > >> >> >> > writeEntry() is supposed to be used for the operations where we need to create a directory and then do Files.copy(). I see no reason to avoid using it here. Linux bundler is also implemented this way. > This wasn?t clear just from the patch. But if it is consistent with how other code works it makes sense. Thanks. From sadhak001 at gmail.com Mon Dec 4 11:39:39 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Mon, 04 Dec 2017 11:39:39 +0000 Subject: javapackager feedback and questions In-Reply-To: <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com> References: <4729a893-3faa-c3ee-9669-ff932a0912de@oracle.com> Message-ID: Hi Victor, I have raised an issue on JBS via http://bugreport.java.com/ for this (ID given to me *9051766*): > Looks like there is a bug when you specify systemWide=true on the MacOSX in non-gui mode. I don't have an account on it, so I might not be able to amend or add new details to it. If I had to add a word or two to the subject or title of the issue, how do I do it? The other doc issues I'll raise as a combined documentation issue, id *9051768*. Let me know if you have any other questions or need anything else from me. Thanks. Cheers, Mani On Wed, 29 Nov 2017 at 23:18 wrote: > Hi, Mani. > > Thanks for providing the feedback! > We will consider adding more examples and more details in the docs as > you proposed(there is an arg named jvmOptions but that's not mentioned > in the table). > Looks like there is a bug when you specify systemWide=true on the MacOSX > in non-gui mode. Can you provide more details about that (like full cmd > line)? > Actually, if you want you can clone the repo: > http://hg.openjdk.java.net/openjfx/10-dev/rt/ > (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/) > and help to improve javapackager. Or you can just create Enhancements > for deploy/packager, as it's not always clear what users expect. > > By the way, what kind of apps you distribute using javapackager? Is that > a UI app or services? > > --Victor > > > -- @theNeomatrix369 | Blog | @adoptopenjdk | Dev communities Meet-a-Project - MutabilityDetector | Github | Slideshare | LinkedIn Come to Devoxx UK 2018: http://www.devoxx.co.uk/ Don't chase success, rather aim for "Excellence", and success will come chasing after you! From kevin.rushforth at oracle.com Mon Dec 4 14:35:16 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 04 Dec 2017 06:35:16 -0800 Subject: PLEASE READ: New OpenJFX dev repo is open for business In-Reply-To: <5A215301.9010609@oracle.com> References: <5A1DD8BE.5090009@oracle.com> <5A215301.9010609@oracle.com> Message-ID: <5A255D24.90601@oracle.com> All, The new OpenJFX developer repo, jfx-dev/rt, is now open. Effective immediately, changesets for FX 10 (and beyond) should be pushed to: http://hg.openjdk.java.net/openjfx/jfx-dev/rt You can edit your .hg/hgrc files to point to this new repo (no need to reclone your repo, although you can do that instead if you prefer). Let me know if you have any problems or questions about this. Thanks. -- Kevin Kevin Rushforth wrote: > As a reminder, the repo renaming is happening starting this Sunday > evening, Dec 3, at 8pm Pacific. I will send email on Monday when the > new jfx-dev repo is open for business. > > -- Kevin > > Kevin Rushforth wrote: >> To: All OpenJFX developers >> >> There are two related items that you need to be aware of, so please >> read this if you are a developer of OpenJFX. >> >> Executive summary: >> >> 1. To match the JDK project, which has a persistent, >> non-release-specific mainline repo [1], the FX 10 and 10-dev repos >> will be "renamed" to jfx and jfx-dev. Starting Monday, Dec 4 all >> fixes for FX should be pushed to jfx-dev/rt rather than 10-dev/rt. >> >> 2. As a reminder, the JDK 10 RDP1 milestone is coming up on Dec 14 >> [2]. All bug fixes and RFEs planned for 10 should be pushed by that >> date. We will fork the repo at that time and only approved fixes will >> go into JDK 10 after that point. >> >> >> Details: >> >> 1. Historically, the JDK has had separate development mainline repos >> for each code line, and the OpenJFX project has followed this >> pattern. Starting with JDK 10, development has switched to a model >> where the development branch is persistent (that is, it doesn't >> change when a new release is started) and is no longer >> release-specific. So there is a jdk project with a jdk mainline repo >> [1], and no longer a jdk10 mainline repo. We will start following >> this for the OpenJFX project, too. >> >> We will "effectively rename" the FX 10-dev (and 10 [master]) repos to >> jfx-dev (and jfx [master]). I use the term "effectively rename", >> because what we will actually do is clone a new jfx-dev repo from >> 10-dev and make 10-dev read-only. This is because we will shortly >> need a new forked repo for 10 stabilization, so it is easier to do >> this than delete and recreate it. >> >> The end result will be that for developers, the place you push fixes >> going forward will always be "jfx-dev/rt" rather than "10-dev/rt" and >> then "11-dev/rt" and then ... >> >> The planned timeline for the switchover is: >> >> Sunday, Dec 3 >> >> * The openjfx 10-dev forest will be made read only at 8:00 pm Pacific >> time on Sunday. If you have a fix that you want in before Monday, >> then you need to push it no later than 7:59 pm (Pacific) Sunday night. >> >> * The jfx-dev forest will be cloned from 10-dev (and the jfx [master] >> forest will be cloned from 10 [master]) >> >> Monday, Dec 4 >> >> * Once this is done and tested, I will send out email announcing that >> it is open for pushing. I expect that this will happen early Monday >> morning (Pacific time). Once the repo is open, developers will need >> to edit their .hgrc files to point to the new jfx-dev forest instead >> of 10-dev. >> >> >> 2. As a reminder, the JDK 10 RDP1 milestone is coming up on Dec 14 >> [2]. All bug fixes and RFEs planned for 10 should be pushed by that >> date. We will fork the repo at that time; only approved fixes will go >> into JDK 10 after that point. The guidelines are that only P1-P3 bugs >> will be considered for inclusion into JDK 10 during RDP1, and not all >> P3 bugs will be taken. Generally developers focus on getting a fix >> into the mainline, and it will make the next available train. Once >> the 10 stabilization repo has forked, the next train will be 11. >> >> I expect that more guidance will be given on the jdk-dev mailing list >> as for the processes and policies surrounding this. >> >> -- Kevin >> >> [1] http://hg.openjdk.java.net/jdk/jdk/ >> >> [2] http://openjdk.java.net/projects/jdk/10/ >> From kevin.rushforth at oracle.com Mon Dec 4 16:40:59 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 04 Dec 2017 08:40:59 -0800 Subject: [10] Review request: 8192874: Update location of Oracle modifications to third-party LGPL source code Message-ID: <5A257A9B.9020102@oracle.com> Hi Phil, Can you please review the following: https://bugs.openjdk.java.net/browse/JDK-8192874 http://cr.openjdk.java.net/~kcr/8192874/webrev.00/ Thanks. -- Kevin From mike.ennen at gmail.com Mon Dec 4 23:28:49 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 4 Dec 2017 16:28:49 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: Message-ID: 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.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 From kevin.rushforth at oracle.com Tue Dec 5 00:12:19 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 04 Dec 2017 16:12:19 -0800 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: Message-ID: <5A25E463.1020309@oracle.com> 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.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 >> >> > > > > From mike.ennen at gmail.com Tue Dec 5 01:08:06 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 4 Dec 2017 18:08:06 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <5A25E463.1020309@oracle.com> References: <5A25E463.1020309@oracle.com> Message-ID: 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.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 From mike.ennen at gmail.com Tue Dec 5 01:11:42 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 4 Dec 2017 18:11:42 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: <5A25E463.1020309@oracle.com> Message-ID: 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 From alexander.matveev at oracle.com Tue Dec 5 02:04:17 2017 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 4 Dec 2017 18:04:17 -0800 Subject: [10] Review request for 8191515: Add ToolProvider support for Java Packager Message-ID: <2078ea8d-bbdc-f1a6-aec9-d0bf11c63c6e@oracle.com> Hi Victor, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8191515 Added ToolProvider for Java Packager. Thanks, Alexander From victor.drozdov at oracle.com Tue Dec 5 02:42:08 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Mon, 4 Dec 2017 18:42:08 -0800 Subject: [10] Review request: 8186642: Assertion error if output application already exists Message-ID: <6234d049-7fed-2375-f6ec-a89c0dfc2a48@oracle.com> Kevin, Please review the changes about fixing "AssertionError: Duplicate entry". JIRA: https://bugs.openjdk.java.net/browse/JDK-8186642 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8186642/webrev.00/ --Victor From dave at jfree.org Tue Dec 5 12:54:09 2017 From: dave at jfree.org (David Gilbert) Date: Tue, 5 Dec 2017 13:54:09 +0100 Subject: Font metrics in JavaFX Canvas In-Reply-To: References: Message-ID: <952DC02E-FEA9-441F-82A9-827923ADA5E2@jfree.org> Any feedback on this item? Best regards, David Gilbert > On 30 Nov 2017, at 08:26, David Gilbert wrote: > > Hello, > > I have an open source project FXGraphics2D [1] that provides a Graphics2D API for the JavaFX canvas. It is open source and used to provide JavaFX support for JFreeChart [2] and Orson Charts [3]. It can also be used more generally for any code that targets the Java2D API. > > One limitation that I?ve encountered is that there is no API to get font metrics for fonts rendered on the JavaFX canvas, so it is difficult to implement the method Graphics2D.getFontMetrics(Font f) accurately. As a result, text alignment is difficult, for example see the tick labels on the vertical axis in this chart: > > http://www.jfree.org/jfreechart/fxgraphics2d-font-issue.png > > There is a feature request in the bug tracker, open for some time, that targets this particular feature. I?d like to highlight it for (hopefully) some attention in a future JDK release: > > https://bugs.openjdk.java.net/browse/JDK-8090775 > > Best regards, > > David Gilbert > > [1] https://github.com/jfree/fxgraphics2d > [2] https://github.com/jfree/jfreechart-fx > [3] https://github.com/jfree/orson-charts-fx From arunprasad.rajkumar at oracle.com Tue Dec 5 14:38:30 2017 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 5 Dec 2017 20:08:30 +0530 Subject: [10] Review request: 8148939: Font rendering artifacts on Adobe.com Message-ID: <9BD747C5-B926-4013-A9F2-4C4BAE2D7774@oracle.com> Hi Kevin, Phil, Please review the following fix related to LCD text rendering issue in Windows, Bug: https://bugs.openjdk.java.net/browse/JDK-8148939 Patch: http://cr.openjdk.java.net/~arajkumar/8148939/webrev Root cause: Padding is added for "left, bottom and right" parts to avoid LCD text rendering artifacts, but ?top? part is ignored. Adding a single pixel padding fixes the issue. Issue is seen only on Windows when enabling LCD font smoothing(which is enabled by default for WebView). I tried to reproduce the problem using ?Text/Label? node, but I couldn't. Probably because ?Text/Label? node calculates NGText bounding box differently, WebView uses "NGText.getShape().getBounds()?. Thanks, Arun From javafx at use.startmail.com Tue Dec 5 15:02:18 2017 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Tue, 5 Dec 2017 10:02:18 -0500 Subject: feedback on item Message-ID: >>Any feedback on this item? I had the same issue. I haven't gotten any response. They must already be aware of it but they're not tipping their hand about what if anything they plan to do about it or what release improvements might appear in.? For an easy 1000 yd. overview of what's missing, compare the class Font found in javafx to the class Font found in java.awt . java.awt's Font class, it's methods and the classes it references will lead you straight into what the difference between the two libraries are and what capabilities are absent in javafx.? ? From philip.race at oracle.com Tue Dec 5 20:41:08 2017 From: philip.race at oracle.com (Phil Race) Date: Tue, 5 Dec 2017 12:41:08 -0800 Subject: Text classes In-Reply-To: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> Message-ID: This is a gap it would be nice to fill. Since it is not a small effort to do right there'd be a design side as well as implementation so it can't be just 'slid in'. And I don't think just moving internal APIs to public is the way to approach it. There are no current plans to allocate Oracle resources to do that work. But this is an open source project, so if someone on this list is willing to design & contribute it - and of course fix the issues and long term maintain it - then that would be great. -phil. On 11/25/2017 03:40 PM, javafx at use.startmail.com wrote: > Hi, This is a question about the future of Text under Javafx. > > Very briefly, Swing provided access to everything a dev could need in > order to write a rich text editor from scratch. LineBreakMeasurers and > HitTesting and everything. > > In JavaFX these things are not directly available to the dev and > anyway, to the extent that they are, they cannot be used to write a > rich text editor.. > > There are many classes needed involving the measuring of glyphs and > text lines etc etc etc which would be needed for anyone who wanted to > write their own rich text editor. They exist, but are under sun.com > and given the modularization of Java 9 are truly inaccessible to > developers. > > I am aware of the existing Javafx controls. I am also aware of the > efforts available at GitHub and elsewhere to create a rich text editor > and all of them without exception are handicapped by this same lack of > API. > > I am also aware of HTMLEditor in JavaFX but that 1) commits the dev to > WebRenderer and 2) still doesn't provide access to the needed classes > and methods. It's not sufficient to suppose that HTML 5 or whatever > follows is the answer to all text layout challenges. > > Formerly, Swing had all these missing features available as API and > many good text editors were created using those APIs. > > For the sake of future planning, we really need to know- is there any > recognition within Oracle that this is something which has to be > addressed? Is it on any hypothetical roadmap? Or is HTMLEditor as > much as JavaFX is going to provide ? > > Thank you. From javafx at use.startmail.com Tue Dec 5 23:55:10 2017 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Tue, 5 Dec 2017 18:55:10 -0500 Subject: Text classes In-Reply-To: References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> Message-ID: <26eeb05da1c132ee6d278199c666171c.startmail@www.startmail.com> No Oracle plans !!!? My one sentence rant: Interactive infographics are a cool way to represent complex information and actgually represent a genuinely new way to communicate information which in some cases is also the best way or all possible ways, but there are at least two other ways that are also the best way under some circumstances- mathematics and the printed word. You can't possibly think you're going to release a GUI toolkit that doesn't fully support the written word. The vast bulk of civilization goes forward on the written word.? I would gladly do it or join an effort but I can't get JavFX to build and after a real, full week or trying, gave up for-ev-vah and moved on to other stuff. I am going to leverage Swing for my Fontly needs and am brushing of my C++ in case it JavaFX never does it and Oracle (foolishly!!!) deprecates Swing ....at which point it's abandon Java for me.? (Really, it's not seen as practical to use the existing implementation under the hood in FX ? Not even as a jumping off point? ) At the end of my WeekFromHellTryingToBuildJavaFX I had a couple of what I considered to be insights, based on my limited knowledge of JavaFX , which I'm going to pretend I don't realize are likely of sub-zero interest to readers of this forum and consequently share with you.? One was- Yeah.... large, possibly huge,? text documents are not the best fit for the particular scene graph implementation that is JavaFX. In short, JavaFX is *almost* a physics engine in the sense that a change in the size of THAT Node a way over yonder could crerdibly cause a repositioning of any or all Nodes in the scene graph as a result of resizing and the reactions of layout managers to that resizing. What that means for Big Text documents with LOts Of Text Nodes is a change in any of the CSS property values (or mutation of the words themselves) could kick off quite a process or recalculating where the CPU sucking methods that show up in my profiler, mostly reclaculating Rectangular bounds, are going to bring your program down.? I can get about 20k nodes to step lively in a program but 200k Nodes makes the scene never render at all, much less be usable. That's the scene graph. But documents have more than 200k words in them, If a change in font or style delineates the boundaries of? a (causes the creation of a new) Text Node (it is) then it's just waaaay too easy to generate waaay too many Nodes? and, looking intothe future of Text where whole chunks of it will be created by computers (AI) but consumed by humans? (analysis, digestion) TooManyNodes is only going to get worse.? So there's that.? Another was: We devs have made? quite a little problem for ourselves with respect to being able to communicate to others of our kind the necessary and siffcient conditions a machine must be in in order to build a pierce of software.? We really have no way to put an alien computer into a build-ready state or even communicate the conditions it needs to be in in real actionable detail. Talk about versions of this and defining system variables to be that are at best partial, ad-hoc efforts doomed to fail for a large number of people and ultimately backed by ignorance about the ACTUAL state of our own machines and chock-o-block woth unwarranted assumptions about the state of the would-be builder's machine. Variable are defined randomly in build scripts and those variables are often literally stitched together over widely separated statements from variables' values? assumed to be present on the machine and assumed to hold certain values. Build scripts are necessarily dependent on assumptions about the specific internal state of third party software they have no control over and that state is often temporary, en passant, shortly to become literally unavailable to future devs.? Organizations can mothball the required versions of software, create identical machines and have build vetrans available to troubleshoot the build but even those savants have no way of communicating to others what the magic is in their witches brew and they themselves are not aware of everything that goes into a successful build.? It's as I said, a wicked problem.? ? On Tuesday, December 5, 2017 3:41 PM, Phil Race wrote: ? > This is a gap it would be nice to fill. > Since it is not a small effort to do right there'd be a design side > as > well as implementation so it can't be just 'slid in'. > And I don't think just moving internal APIs to public is the way to > approach it. > There are no current plans to allocate Oracle resources to do that > work. > But this is an open source project, so if someone on this list is > willing to design & contribute it - and of course > fix the issues and long term maintain it - then that would be great. > > > -phil. > > On 11/25/2017 03:40 PM, javafx at use.startmail.com wrote: >> Hi, This is a question about the future of Text under Javafx. >> >> Very briefly, Swing provided access to everything a dev could need >> in >> order to write a rich text editor from scratch. LineBreakMeasurers >> and >> HitTesting and everything. >> >> In JavaFX these things are not directly available to the dev and >> anyway, to the extent that they are, they cannot be used to write a >> rich text editor.. >> >> There are many classes needed involving the measuring of glyphs and >> text lines etc etc etc which would be needed for anyone who wanted >> to >> write their own rich text editor. They exist, but are under sun.com >> and given the modularization of Java 9 are truly inaccessible to >> developers. >> >> I am aware of the existing Javafx controls. I am also aware of the >> efforts available at GitHub and elsewhere to create a rich text >> editor >> and all of them without exception are handicapped by this same lack >> of >> API. >> >> I am also aware of HTMLEditor in JavaFX but that 1) commits the dev >> to >> WebRenderer and 2) still doesn't provide access to the needed >> classes >> and methods. It's not sufficient to suppose that HTML 5 or whatever >> follows is the answer to all text layout challenges. >> >> Formerly, Swing had all these missing features available as API and >> many good text editors were created using those APIs. >> >> For the sake of future planning, we really need to know- is there >> any >> recognition within Oracle that this is something which has to be >> addressed? Is it on any hypothetical roadmap? ?Or is HTMLEditor as >> much as JavaFX is going to provide ? >> >> Thank you. From kevin.rushforth at oracle.com Wed Dec 6 00:29:55 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 05 Dec 2017 16:29:55 -0800 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: <5A25E463.1020309@oracle.com> Message-ID: <5A273A03.40902@oracle.com> 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 From javafx at use.startmail.com Wed Dec 6 00:36:01 2017 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Tue, 5 Dec 2017 19:36:01 -0500 Subject: Text classes In-Reply-To: References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> Message-ID: <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> Sorry about all the typos previously.? Question- why not use the code in awt ? I am not totally up on what's going on with the platforms' native rendering engines ( meaning, I have no idea whatsoever) or how they have changed, but golly it sure does still work pretty well. ?At least it seems to me looking at awt that a smallish number of things are 1) well defined by the native platofrm and 2) would more or less translate directly to an Java API and 3) from those small number of building blocks, (Font and Glyph metrics and this kind of thing)? ?text line layout algorithms can be written by ordinary civilians along with all the other stuff that goes into a text editor.? And yes, everything does look easy when someone else is going to do it.? ? From johnvalrose at gmail.com Wed Dec 6 04:21:46 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Wed, 6 Dec 2017 15:21:46 +1100 Subject: Innovation again (was Re: Text classes) In-Reply-To: <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> Message-ID: <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> Phil et. al., Whilst I?m not going to be quite as ?passionate? as some on this issue (although I do understand the frustration), I would like to point out again that this is indeed a huge gap and it is critical that it is filled ASAP. Obviously a solution where every word in a text document is a Node would be unworkable so it would need to be architected from the ground up. I would be happy to work on such as feature, just as I was happy to work on implementing WebGL, but my hesitation is concern over the assistance and involvement from Oracle. If I am going to have to spend months working on something without any or only minimal involvement from Oracle, only to find at the end that Oracle either doesn?t like the design, implementation or something else then it is wasted time I?ll never get back. There are lots of other innovations too that I would like to see in JavaFX but I just don?t ?feel the enthusiasm? from Oracle. If there is someone on the JavaFX team who would be willing to work with me (at least in some capacity), please have them contact me privately via email. The innovations I could work on and contribute include: 1. WebGL support in WebView 2. Better text support including text documents & rich text editors etc. 3. Significant improvements in scene graph rendering speed using modern game-engine style structures and algorithms JavaFX cannot survive without innovation and I am keen to see it happen and contribute as much as possible. Graciously, John-Val Rose Rosethorn Technology > On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: > > Sorry about all the typos previously. > > Question- why not use the code in awt ? I am not totally up on what's going on with the platforms' native rendering engines ( meaning, I have no idea whatsoever) or how they have changed, but golly it sure does still work pretty well. > > At least it seems to me looking at awt that a smallish number of things are 1) well defined by the native platofrm and 2) would more or less translate directly to an Java API and 3) from those small number of building blocks, (Font and Glyph metrics and this kind of thing) text line layout algorithms can be written by ordinary civilians along with all the other stuff that goes into a text editor. > > And yes, everything does look easy when someone else is going to do it. > > From philip.race at oracle.com Wed Dec 6 04:53:54 2017 From: philip.race at oracle.com (Philip Race) Date: Tue, 05 Dec 2017 20:53:54 -0800 Subject: Innovation again (was Re: Text classes) In-Reply-To: <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> Message-ID: <5A2777E2.7050106@oracle.com> I think looking at it as an Oracle-owned and controlled project maybe the first mistake here. Yes it was closed source and then Oracle controlled, but not any more, OCA requirements aside. It is not even a "java specification". It can be evolved at an API level without a JSR. The JEP process is the main thing to be followed, although we also use CSRs too to track API. Consider it that anyone who is a contributor owns (not the right word ?) a piece of it too. So standing on the project is what matters. Not the company who pays you to work on it. -phil. On 12/5/17, 8:21 PM, John-Val Rose wrote: > Phil et. al., > > Whilst I?m not going to be quite as ?passionate? as some on this issue (although I do understand the frustration), I would like to point out again that this is indeed a huge gap and it is critical that it is filled ASAP. > > Obviously a solution where every word in a text document is a Node would be unworkable so it would need to be architected from the ground up. > > I would be happy to work on such as feature, just as I was happy to work on implementing WebGL, but my hesitation is concern over the assistance and involvement from Oracle. > > If I am going to have to spend months working on something without any or only minimal involvement from Oracle, only to find at the end that Oracle either doesn?t like the design, implementation or something else then it is wasted time I?ll never get back. > > There are lots of other innovations too that I would like to see in JavaFX but I just don?t ?feel the enthusiasm? from Oracle. > > If there is someone on the JavaFX team who would be willing to work with me (at least in some capacity), please have them contact me privately via email. > > The innovations I could work on and contribute include: > > 1. WebGL support in WebView > 2. Better text support including text documents& rich text editors etc. > 3. Significant improvements in scene graph rendering speed using modern game-engine style structures and algorithms > > JavaFX cannot survive without innovation and I am keen to see it happen and contribute as much as possible. > > Graciously, > > John-Val Rose > Rosethorn Technology > >> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: >> >> Sorry about all the typos previously. >> >> Question- why not use the code in awt ? I am not totally up on what's going on with the platforms' native rendering engines ( meaning, I have no idea whatsoever) or how they have changed, but golly it sure does still work pretty well. >> >> At least it seems to me looking at awt that a smallish number of things are 1) well defined by the native platofrm and 2) would more or less translate directly to an Java API and 3) from those small number of building blocks, (Font and Glyph metrics and this kind of thing) text line layout algorithms can be written by ordinary civilians along with all the other stuff that goes into a text editor. >> >> And yes, everything does look easy when someone else is going to do it. >> >> From johnvalrose at gmail.com Wed Dec 6 05:27:40 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Wed, 6 Dec 2017 16:27:40 +1100 Subject: Innovation again (was Re: Text classes) In-Reply-To: <5A2777E2.7050106@oracle.com> References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> <5A2777E2.7050106@oracle.com> Message-ID: Well, that?s all fine but you didn?t address the issue of working with someone within Oracle to get these innovations done. Sure, I could just toil away by myself but clearly it would be better all around if there was someone with much more extensive knowledge of JavaFX and its internals who was accessible when required. I would assume that a member of the Oracle JavaFX team would be such a person. If not, then who? > On 6 Dec 2017, at 15:53, Philip Race wrote: > > I think looking at it as an Oracle-owned and controlled project maybe the first mistake here. > Yes it was closed source and then Oracle controlled, but not any more, OCA requirements aside. > It is not even a "java specification". It can be evolved at an API level without a JSR. > The JEP process is the main thing to be followed, although we also use CSRs too to track API. > Consider it that anyone who is a contributor owns (not the right word ?) a piece of it too. > So standing on the project is what matters. Not the company who pays you to work on it. > > -phil. > >> On 12/5/17, 8:21 PM, John-Val Rose wrote: >> Phil et. al., >> >> Whilst I?m not going to be quite as ?passionate? as some on this issue (although I do understand the frustration), I would like to point out again that this is indeed a huge gap and it is critical that it is filled ASAP. >> >> Obviously a solution where every word in a text document is a Node would be unworkable so it would need to be architected from the ground up. >> >> I would be happy to work on such as feature, just as I was happy to work on implementing WebGL, but my hesitation is concern over the assistance and involvement from Oracle. >> >> If I am going to have to spend months working on something without any or only minimal involvement from Oracle, only to find at the end that Oracle either doesn?t like the design, implementation or something else then it is wasted time I?ll never get back. >> >> There are lots of other innovations too that I would like to see in JavaFX but I just don?t ?feel the enthusiasm? from Oracle. >> >> If there is someone on the JavaFX team who would be willing to work with me (at least in some capacity), please have them contact me privately via email. >> >> The innovations I could work on and contribute include: >> >> 1. WebGL support in WebView >> 2. Better text support including text documents& rich text editors etc. >> 3. Significant improvements in scene graph rendering speed using modern game-engine style structures and algorithms >> >> JavaFX cannot survive without innovation and I am keen to see it happen and contribute as much as possible. >> >> Graciously, >> >> John-Val Rose >> Rosethorn Technology >> >>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: >>> >>> Sorry about all the typos previously. >>> >>> Question- why not use the code in awt ? I am not totally up on what's going on with the platforms' native rendering engines ( meaning, I have no idea whatsoever) or how they have changed, but golly it sure does still work pretty well. >>> >>> At least it seems to me looking at awt that a smallish number of things are 1) well defined by the native platofrm and 2) would more or less translate directly to an Java API and 3) from those small number of building blocks, (Font and Glyph metrics and this kind of thing) text line layout algorithms can be written by ordinary civilians along with all the other stuff that goes into a text editor. >>> >>> And yes, everything does look easy when someone else is going to do it. >>> >>> From philip.race at oracle.com Wed Dec 6 05:50:25 2017 From: philip.race at oracle.com (Philip Race) Date: Tue, 05 Dec 2017 21:50:25 -0800 Subject: Innovation again (was Re: Text classes) In-Reply-To: References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> <5A2777E2.7050106@oracle.com> Message-ID: <5A278521.8050202@oracle.com> There needs to be a viable community that is not just Oracle to support you here .. I think everyone has come to be dependent on Oracle to "be there". But if there is a specific community need that Oracle doesn't see as essential, then the community should help out. -phil. On 12/5/17, 9:27 PM, John-Val Rose wrote: > Well, that?s all fine but you didn?t address the issue of working with someone within Oracle to get these innovations done. > > Sure, I could just toil away by myself but clearly it would be better all around if there was someone with much more extensive knowledge of JavaFX and its internals who was accessible when required. > > I would assume that a member of the Oracle JavaFX team would be such a person. If not, then who? > >> On 6 Dec 2017, at 15:53, Philip Race wrote: >> >> I think looking at it as an Oracle-owned and controlled project maybe the first mistake here. >> Yes it was closed source and then Oracle controlled, but not any more, OCA requirements aside. >> It is not even a "java specification". It can be evolved at an API level without a JSR. >> The JEP process is the main thing to be followed, although we also use CSRs too to track API. >> Consider it that anyone who is a contributor owns (not the right word ?) a piece of it too. >> So standing on the project is what matters. Not the company who pays you to work on it. >> >> -phil. >> >>> On 12/5/17, 8:21 PM, John-Val Rose wrote: >>> Phil et. al., >>> >>> Whilst I?m not going to be quite as ?passionate? as some on this issue (although I do understand the frustration), I would like to point out again that this is indeed a huge gap and it is critical that it is filled ASAP. >>> >>> Obviously a solution where every word in a text document is a Node would be unworkable so it would need to be architected from the ground up. >>> >>> I would be happy to work on such as feature, just as I was happy to work on implementing WebGL, but my hesitation is concern over the assistance and involvement from Oracle. >>> >>> If I am going to have to spend months working on something without any or only minimal involvement from Oracle, only to find at the end that Oracle either doesn?t like the design, implementation or something else then it is wasted time I?ll never get back. >>> >>> There are lots of other innovations too that I would like to see in JavaFX but I just don?t ?feel the enthusiasm? from Oracle. >>> >>> If there is someone on the JavaFX team who would be willing to work with me (at least in some capacity), please have them contact me privately via email. >>> >>> The innovations I could work on and contribute include: >>> >>> 1. WebGL support in WebView >>> 2. Better text support including text documents& rich text editors etc. >>> 3. Significant improvements in scene graph rendering speed using modern game-engine style structures and algorithms >>> >>> JavaFX cannot survive without innovation and I am keen to see it happen and contribute as much as possible. >>> >>> Graciously, >>> >>> John-Val Rose >>> Rosethorn Technology >>> >>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: >>>> >>>> Sorry about all the typos previously. >>>> >>>> Question- why not use the code in awt ? I am not totally up on what's going on with the platforms' native rendering engines ( meaning, I have no idea whatsoever) or how they have changed, but golly it sure does still work pretty well. >>>> >>>> At least it seems to me looking at awt that a smallish number of things are 1) well defined by the native platofrm and 2) would more or less translate directly to an Java API and 3) from those small number of building blocks, (Font and Glyph metrics and this kind of thing) text line layout algorithms can be written by ordinary civilians along with all the other stuff that goes into a text editor. >>>> >>>> And yes, everything does look easy when someone else is going to do it. >>>> >>>> From johnvalrose at gmail.com Wed Dec 6 06:16:07 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Wed, 6 Dec 2017 17:16:07 +1100 Subject: Innovation again (was Re: Text classes) In-Reply-To: <5A278521.8050202@oracle.com> References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> <5A2777E2.7050106@oracle.com> <5A278521.8050202@oracle.com> Message-ID: <2FA8027D-79B1-4339-8BCA-6B5CB58D37E5@gmail.com> Absolutely - there needs to be a viable community that is not just Oracle. So, is there one? If not, how do we build one? OK, so let me rephrase my earlier email: I am willing to work with *anyone* (within Oracle or not) on the features that the community craves, such as those I listed (and any others). Not just because ?many hands make light work? but because I don?t know everything (or even close) and I need the knowledge and skills of others to assist me. Not to mention that I have only 24 hours in a day like everyone else and, also like everyone else, some of that time has to be devoted to earning an income. So, if there?s anyone reading this who has the time, the skills, the commitment and the passion to work hard (in your own time) to get these tasks done then please contact me privately. > On 6 Dec 2017, at 16:50, Philip Race wrote: > > There needs to be a viable community that is not just Oracle to support you here .. > I think everyone has come to be dependent on Oracle to "be there". > But if there is a specific community need that Oracle doesn't see as essential, then the community should help out. > > -phil. > >> On 12/5/17, 9:27 PM, John-Val Rose wrote: >> Well, that?s all fine but you didn?t address the issue of working with someone within Oracle to get these innovations done. >> >> Sure, I could just toil away by myself but clearly it would be better all around if there was someone with much more extensive knowledge of JavaFX and its internals who was accessible when required. >> >> I would assume that a member of the Oracle JavaFX team would be such a person. If not, then who? >> >>> On 6 Dec 2017, at 15:53, Philip Race wrote: >>> >>> I think looking at it as an Oracle-owned and controlled project maybe the first mistake here. >>> Yes it was closed source and then Oracle controlled, but not any more, OCA requirements aside. >>> It is not even a "java specification". It can be evolved at an API level without a JSR. >>> The JEP process is the main thing to be followed, although we also use CSRs too to track API. >>> Consider it that anyone who is a contributor owns (not the right word ?) a piece of it too. >>> So standing on the project is what matters. Not the company who pays you to work on it. >>> >>> -phil. >>> >>>> On 12/5/17, 8:21 PM, John-Val Rose wrote: >>>> Phil et. al., >>>> >>>> Whilst I?m not going to be quite as ?passionate? as some on this issue (although I do understand the frustration), I would like to point out again that this is indeed a huge gap and it is critical that it is filled ASAP. >>>> >>>> Obviously a solution where every word in a text document is a Node would be unworkable so it would need to be architected from the ground up. >>>> >>>> I would be happy to work on such as feature, just as I was happy to work on implementing WebGL, but my hesitation is concern over the assistance and involvement from Oracle. >>>> >>>> If I am going to have to spend months working on something without any or only minimal involvement from Oracle, only to find at the end that Oracle either doesn?t like the design, implementation or something else then it is wasted time I?ll never get back. >>>> >>>> There are lots of other innovations too that I would like to see in JavaFX but I just don?t ?feel the enthusiasm? from Oracle. >>>> >>>> If there is someone on the JavaFX team who would be willing to work with me (at least in some capacity), please have them contact me privately via email. >>>> >>>> The innovations I could work on and contribute include: >>>> >>>> 1. WebGL support in WebView >>>> 2. Better text support including text documents& rich text editors etc. >>>> 3. Significant improvements in scene graph rendering speed using modern game-engine style structures and algorithms >>>> >>>> JavaFX cannot survive without innovation and I am keen to see it happen and contribute as much as possible. >>>> >>>> Graciously, >>>> >>>> John-Val Rose >>>> Rosethorn Technology >>>> >>>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: >>>>> >>>>> Sorry about all the typos previously. >>>>> >>>>> Question- why not use the code in awt ? I am not totally up on what's going on with the platforms' native rendering engines ( meaning, I have no idea whatsoever) or how they have changed, but golly it sure does still work pretty well. >>>>> >>>>> At least it seems to me looking at awt that a smallish number of things are 1) well defined by the native platofrm and 2) would more or less translate directly to an Java API and 3) from those small number of building blocks, (Font and Glyph metrics and this kind of thing) text line layout algorithms can be written by ordinary civilians along with all the other stuff that goes into a text editor. >>>>> >>>>> And yes, everything does look easy when someone else is going to do it. >>>>> >>>>> From markus at headcrashing.eu Wed Dec 6 08:07:03 2017 From: markus at headcrashing.eu (Markus KARG) Date: Wed, 6 Dec 2017 09:07:03 +0100 Subject: Innovation again (was Re: Text classes) In-Reply-To: <5A278521.8050202@oracle.com> References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> <5A2777E2.7050106@oracle.com> <5A278521.8050202@oracle.com> Message-ID: <01a001d36e69$33afff70$9b0ffe50$@eu> I think what John actually asked for is whom to send his design upfront at the JFX team to get an initial judgement whether it is worth programming it, or whether it bears such flaws that it makes not much sense to invest any more time. Whether or not that decision is done by an Oracle employee or not, he simply needs to know whom to sent his proposal for early review. -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Philip Race Sent: Mittwoch, 6. Dezember 2017 06:50 To: John-Val Rose Cc: openjfx-dev at openjdk.java.net Subject: Re: Innovation again (was Re: Text classes) There needs to be a viable community that is not just Oracle to support you here .. I think everyone has come to be dependent on Oracle to "be there". But if there is a specific community need that Oracle doesn't see as essential, then the community should help out. -phil. On 12/5/17, 9:27 PM, John-Val Rose wrote: > Well, that?s all fine but you didn?t address the issue of working with someone within Oracle to get these innovations done. > > Sure, I could just toil away by myself but clearly it would be better all around if there was someone with much more extensive knowledge of JavaFX and its internals who was accessible when required. > > I would assume that a member of the Oracle JavaFX team would be such a person. If not, then who? > >> On 6 Dec 2017, at 15:53, Philip Race wrote: >> >> I think looking at it as an Oracle-owned and controlled project maybe the first mistake here. >> Yes it was closed source and then Oracle controlled, but not any more, OCA requirements aside. >> It is not even a "java specification". It can be evolved at an API level without a JSR. >> The JEP process is the main thing to be followed, although we also use CSRs too to track API. >> Consider it that anyone who is a contributor owns (not the right word ?) a piece of it too. >> So standing on the project is what matters. Not the company who pays you to work on it. >> >> -phil. >> >>> On 12/5/17, 8:21 PM, John-Val Rose wrote: >>> Phil et. al., >>> >>> Whilst I?m not going to be quite as ?passionate? as some on this issue (although I do understand the frustration), I would like to point out again that this is indeed a huge gap and it is critical that it is filled ASAP. >>> >>> Obviously a solution where every word in a text document is a Node would be unworkable so it would need to be architected from the ground up. >>> >>> I would be happy to work on such as feature, just as I was happy to work on implementing WebGL, but my hesitation is concern over the assistance and involvement from Oracle. >>> >>> If I am going to have to spend months working on something without any or only minimal involvement from Oracle, only to find at the end that Oracle either doesn?t like the design, implementation or something else then it is wasted time I?ll never get back. >>> >>> There are lots of other innovations too that I would like to see in JavaFX but I just don?t ?feel the enthusiasm? from Oracle. >>> >>> If there is someone on the JavaFX team who would be willing to work with me (at least in some capacity), please have them contact me privately via email. >>> >>> The innovations I could work on and contribute include: >>> >>> 1. WebGL support in WebView >>> 2. Better text support including text documents& rich text editors etc. >>> 3. Significant improvements in scene graph rendering speed using >>> modern game-engine style structures and algorithms >>> >>> JavaFX cannot survive without innovation and I am keen to see it happen and contribute as much as possible. >>> >>> Graciously, >>> >>> John-Val Rose >>> Rosethorn Technology >>> >>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: >>>> >>>> Sorry about all the typos previously. >>>> >>>> Question- why not use the code in awt ? I am not totally up on what's going on with the platforms' native rendering engines ( meaning, I have no idea whatsoever) or how they have changed, but golly it sure does still work pretty well. >>>> >>>> At least it seems to me looking at awt that a smallish number of things are 1) well defined by the native platofrm and 2) would more or less translate directly to an Java API and 3) from those small number of building blocks, (Font and Glyph metrics and this kind of thing) text line layout algorithms can be written by ordinary civilians along with all the other stuff that goes into a text editor. >>>> >>>> And yes, everything does look easy when someone else is going to do it. >>>> >>>> From neugens.limasoftware at gmail.com Wed Dec 6 08:11:14 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 06 Dec 2017 08:11:14 +0000 Subject: Innovation again (was Re: Text classes) In-Reply-To: <01a001d36e69$33afff70$9b0ffe50$@eu> References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> <5A2777E2.7050106@oracle.com> <5A278521.8050202@oracle.com> <01a001d36e69$33afff70$9b0ffe50$@eu> Message-ID: I think Phil said that, the way to propose such changes is to file a Jep and discuss it here. Cheers, Mario On Wed 6. Dec 2017 at 09:07, Markus KARG wrote: > I think what John actually asked for is whom to send his design upfront at > the JFX team to get an initial judgement whether it is worth programming > it, or whether it bears such flaws that it makes not much sense to invest > any more time. Whether or not that decision is done by an Oracle employee > or not, he simply needs to know whom to sent his proposal for early review. > > -Markus > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf > Of Philip Race > Sent: Mittwoch, 6. Dezember 2017 06:50 > To: John-Val Rose > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Innovation again (was Re: Text classes) > > There needs to be a viable community that is not just Oracle to support > you here .. > I think everyone has come to be dependent on Oracle to "be there". > But if there is a specific community need that Oracle doesn't see as > essential, then the community should help out. > > -phil. > > On 12/5/17, 9:27 PM, John-Val Rose wrote: > > Well, that?s all fine but you didn?t address the issue of working with > someone within Oracle to get these innovations done. > > > > Sure, I could just toil away by myself but clearly it would be better > all around if there was someone with much more extensive knowledge of > JavaFX and its internals who was accessible when required. > > > > I would assume that a member of the Oracle JavaFX team would be such a > person. If not, then who? > > > >> On 6 Dec 2017, at 15:53, Philip Race wrote: > >> > >> I think looking at it as an Oracle-owned and controlled project maybe > the first mistake here. > >> Yes it was closed source and then Oracle controlled, but not any more, > OCA requirements aside. > >> It is not even a "java specification". It can be evolved at an API > level without a JSR. > >> The JEP process is the main thing to be followed, although we also use > CSRs too to track API. > >> Consider it that anyone who is a contributor owns (not the right word > ?) a piece of it too. > >> So standing on the project is what matters. Not the company who pays > you to work on it. > >> > >> -phil. > >> > >>> On 12/5/17, 8:21 PM, John-Val Rose wrote: > >>> Phil et. al., > >>> > >>> Whilst I?m not going to be quite as ?passionate? as some on this issue > (although I do understand the frustration), I would like to point out again > that this is indeed a huge gap and it is critical that it is filled ASAP. > >>> > >>> Obviously a solution where every word in a text document is a Node > would be unworkable so it would need to be architected from the ground up. > >>> > >>> I would be happy to work on such as feature, just as I was happy to > work on implementing WebGL, but my hesitation is concern over the > assistance and involvement from Oracle. > >>> > >>> If I am going to have to spend months working on something without any > or only minimal involvement from Oracle, only to find at the end that > Oracle either doesn?t like the design, implementation or something else > then it is wasted time I?ll never get back. > >>> > >>> There are lots of other innovations too that I would like to see in > JavaFX but I just don?t ?feel the enthusiasm? from Oracle. > >>> > >>> If there is someone on the JavaFX team who would be willing to work > with me (at least in some capacity), please have them contact me privately > via email. > >>> > >>> The innovations I could work on and contribute include: > >>> > >>> 1. WebGL support in WebView > >>> 2. Better text support including text documents& rich text editors > etc. > >>> 3. Significant improvements in scene graph rendering speed using > >>> modern game-engine style structures and algorithms > >>> > >>> JavaFX cannot survive without innovation and I am keen to see it > happen and contribute as much as possible. > >>> > >>> Graciously, > >>> > >>> John-Val Rose > >>> Rosethorn Technology > >>> > >>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: > >>>> > >>>> Sorry about all the typos previously. > >>>> > >>>> Question- why not use the code in awt ? I am not totally up on what's > going on with the platforms' native rendering engines ( meaning, I have no > idea whatsoever) or how they have changed, but golly it sure does still > work pretty well. > >>>> > >>>> At least it seems to me looking at awt that a smallish number of > things are 1) well defined by the native platofrm and 2) would more or less > translate directly to an Java API and 3) from those small number of > building blocks, (Font and Glyph metrics and this kind of thing) text > line layout algorithms can be written by ordinary civilians along with all > the other stuff that goes into a text editor. > >>>> > >>>> And yes, everything does look easy when someone else is going to do > it. > >>>> > >>>> > > From markus at headcrashing.eu Wed Dec 6 08:33:03 2017 From: markus at headcrashing.eu (Markus KARG) Date: Wed, 6 Dec 2017 09:33:03 +0100 Subject: Innovation again (was Re: Text classes) In-Reply-To: References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> <5A2777E2.7050106@oracle.com> <5A278521.8050202@oracle.com> <01a001d36e69$33afff70$9b0ffe50$@eu> Message-ID: <001c01d36e6c$d5391e50$7fab5af0$@eu> Yes, but not everything needs a JEP always. Maybe what Phil has in mind is small enough to be accepted without. Somebody has to decide before filing the JEP. -Markus From: Mario Torre [mailto:neugens.limasoftware at gmail.com] Sent: Mittwoch, 6. Dezember 2017 09:11 To: Markus KARG Cc: openjfx-dev at openjdk.java.net Subject: Re: Innovation again (was Re: Text classes) I think Phil said that, the way to propose such changes is to file a Jep and discuss it here. Cheers, Mario On Wed 6. Dec 2017 at 09:07, Markus KARG wrote: I think what John actually asked for is whom to send his design upfront at the JFX team to get an initial judgement whether it is worth programming it, or whether it bears such flaws that it makes not much sense to invest any more time. Whether or not that decision is done by an Oracle employee or not, he simply needs to know whom to sent his proposal for early review. -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Philip Race Sent: Mittwoch, 6. Dezember 2017 06:50 To: John-Val Rose Cc: openjfx-dev at openjdk.java.net Subject: Re: Innovation again (was Re: Text classes) There needs to be a viable community that is not just Oracle to support you here .. I think everyone has come to be dependent on Oracle to "be there". But if there is a specific community need that Oracle doesn't see as essential, then the community should help out. -phil. On 12/5/17, 9:27 PM, John-Val Rose wrote: > Well, that?s all fine but you didn?t address the issue of working with someone within Oracle to get these innovations done. > > Sure, I could just toil away by myself but clearly it would be better all around if there was someone with much more extensive knowledge of JavaFX and its internals who was accessible when required. > > I would assume that a member of the Oracle JavaFX team would be such a person. If not, then who? > >> On 6 Dec 2017, at 15:53, Philip Race wrote: >> >> I think looking at it as an Oracle-owned and controlled project maybe the first mistake here. >> Yes it was closed source and then Oracle controlled, but not any more, OCA requirements aside. >> It is not even a "java specification". It can be evolved at an API level without a JSR. >> The JEP process is the main thing to be followed, although we also use CSRs too to track API. >> Consider it that anyone who is a contributor owns (not the right word ?) a piece of it too. >> So standing on the project is what matters. Not the company who pays you to work on it. >> >> -phil. >> >>> On 12/5/17, 8:21 PM, John-Val Rose wrote: >>> Phil et. al., >>> >>> Whilst I?m not going to be quite as ?passionate? as some on this issue (although I do understand the frustration), I would like to point out again that this is indeed a huge gap and it is critical that it is filled ASAP. >>> >>> Obviously a solution where every word in a text document is a Node would be unworkable so it would need to be architected from the ground up. >>> >>> I would be happy to work on such as feature, just as I was happy to work on implementing WebGL, but my hesitation is concern over the assistance and involvement from Oracle. >>> >>> If I am going to have to spend months working on something without any or only minimal involvement from Oracle, only to find at the end that Oracle either doesn?t like the design, implementation or something else then it is wasted time I?ll never get back. >>> >>> There are lots of other innovations too that I would like to see in JavaFX but I just don?t ?feel the enthusiasm? from Oracle. >>> >>> If there is someone on the JavaFX team who would be willing to work with me (at least in some capacity), please have them contact me privately via email. >>> >>> The innovations I could work on and contribute include: >>> >>> 1. WebGL support in WebView >>> 2. Better text support including text documents& rich text editors etc. >>> 3. Significant improvements in scene graph rendering speed using >>> modern game-engine style structures and algorithms >>> >>> JavaFX cannot survive without innovation and I am keen to see it happen and contribute as much as possible. >>> >>> Graciously, >>> >>> John-Val Rose >>> Rosethorn Technology >>> >>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: >>>> >>>> Sorry about all the typos previously. >>>> >>>> Question- why not use the code in awt ? I am not totally up on what's going on with the platforms' native rendering engines ( meaning, I have no idea whatsoever) or how they have changed, but golly it sure does still work pretty well. >>>> >>>> At least it seems to me looking at awt that a smallish number of things are 1) well defined by the native platofrm and 2) would more or less translate directly to an Java API and 3) from those small number of building blocks, (Font and Glyph metrics and this kind of thing) text line layout algorithms can be written by ordinary civilians along with all the other stuff that goes into a text editor. >>>> >>>> And yes, everything does look easy when someone else is going to do it. >>>> >>>> From bourges.laurent at gmail.com Wed Dec 6 08:34:59 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 6 Dec 2017 09:34:59 +0100 Subject: Font metrics in JavaFX Canvas In-Reply-To: <952DC02E-FEA9-441F-82A9-827923ADA5E2@jfree.org> References: <952DC02E-FEA9-441F-82A9-827923ADA5E2@jfree.org> Message-ID: Hi David, If I can help (dev / test / build / patch), I would love doing it on this RFE... on my spare time as usual (best effort). However I have no idea how text metrics are implemented in JavaFX. Could anyone give us directions or draft ideas to do the job ourselves ? Should we start a github repository to fix that issue with all interested people ? Cheers, Laurent Le 5 d?c. 2017 13:54, "David Gilbert" a ?crit : > Any feedback on this item? > > Best regards, > David Gilbert > > > > On 30 Nov 2017, at 08:26, David Gilbert wrote: > > > > Hello, > > > > I have an open source project FXGraphics2D [1] that provides a > Graphics2D API for the JavaFX canvas. It is open source and used to > provide JavaFX support for JFreeChart [2] and Orson Charts [3]. It can > also be used more generally for any code that targets the Java2D API. > > > > One limitation that I?ve encountered is that there is no API to get font > metrics for fonts rendered on the JavaFX canvas, so it is difficult to > implement the method Graphics2D.getFontMetrics(Font f) accurately. As a > result, text alignment is difficult, for example see the tick labels on the > vertical axis in this chart: > > > > http://www.jfree.org/jfreechart/fxgraphics2d-font-issue.png > > > > There is a feature request in the bug tracker, open for some time, that > targets this particular feature. I?d like to highlight it for (hopefully) > some attention in a future JDK release: > > > > https://bugs.openjdk.java.net/browse/JDK-8090775 < > https://bugs.openjdk.java.net/browse/JDK-8090775> > > > > Best regards, > > > > David Gilbert > > > > [1] https://github.com/jfree/fxgraphics2d fxgraphics2d> > > [2] https://github.com/jfree/jfreechart-fx jfreechart-fx> > > [3] https://github.com/jfree/orson-charts-fx orson-charts-fx> > > From johnvalrose at gmail.com Wed Dec 6 08:40:49 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Wed, 6 Dec 2017 19:40:49 +1100 Subject: Innovation again (was Re: Text classes) In-Reply-To: <001c01d36e6c$d5391e50$7fab5af0$@eu> References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> <5A2777E2.7050106@oracle.com> <5A278521.8050202@oracle.com> <01a001d36e69$33afff70$9b0ffe50$@eu> <001c01d36e6c$d5391e50$7fab5af0$@eu> Message-ID: Yes, I obviously need to know if anything I work on or design is going to be accepted or is even wanted by the community as a whole, and as early on in the process as possible. Heck, if I had my way, JavaFX would be used to build everything from forms to FPS games and highly complex and performant 3D visualizations. And don't say it can't be done in Java - it can. JavaMonkeyEngine can be used to create awesome games (for example). Plus, I have never "done" a JEP but I believe it's quite a long and involved process (?) So, I would appreciate some clarification on the best process and steps to take to go from ideas to released features. ?? Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology On 6 December 2017 at 19:33, Markus KARG wrote: > Yes, but not everything needs a JEP always. Maybe what Phil has in mind is > small enough to be accepted without. Somebody has to decide before filing > the JEP. > > -Markus > > > > From: Mario Torre [mailto:neugens.limasoftware at gmail.com] > Sent: Mittwoch, 6. Dezember 2017 09:11 > To: Markus KARG > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Innovation again (was Re: Text classes) > > > > I think Phil said that, the way to propose such changes is to file a Jep > and discuss it here. > > > > Cheers, > > Mario > > > > On Wed 6. Dec 2017 at 09:07, Markus KARG wrote: > > I think what John actually asked for is whom to send his design upfront at > the JFX team to get an initial judgement whether it is worth programming > it, or whether it bears such flaws that it makes not much sense to invest > any more time. Whether or not that decision is done by an Oracle employee > or not, he simply needs to know whom to sent his proposal for early review. > > -Markus > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf > Of Philip Race > Sent: Mittwoch, 6. Dezember 2017 06:50 > To: John-Val Rose > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Innovation again (was Re: Text classes) > > There needs to be a viable community that is not just Oracle to support > you here .. > I think everyone has come to be dependent on Oracle to "be there". > But if there is a specific community need that Oracle doesn't see as > essential, then the community should help out. > > -phil. > > On 12/5/17, 9:27 PM, John-Val Rose wrote: > > Well, that?s all fine but you didn?t address the issue of working with > someone within Oracle to get these innovations done. > > > > Sure, I could just toil away by myself but clearly it would be better > all around if there was someone with much more extensive knowledge of > JavaFX and its internals who was accessible when required. > > > > I would assume that a member of the Oracle JavaFX team would be such a > person. If not, then who? > > > >> On 6 Dec 2017, at 15:53, Philip Race wrote: > >> > >> I think looking at it as an Oracle-owned and controlled project maybe > the first mistake here. > >> Yes it was closed source and then Oracle controlled, but not any more, > OCA requirements aside. > >> It is not even a "java specification". It can be evolved at an API > level without a JSR. > >> The JEP process is the main thing to be followed, although we also use > CSRs too to track API. > >> Consider it that anyone who is a contributor owns (not the right word > ?) a piece of it too. > >> So standing on the project is what matters. Not the company who pays > you to work on it. > >> > >> -phil. > >> > >>> On 12/5/17, 8:21 PM, John-Val Rose wrote: > >>> Phil et. al., > >>> > >>> Whilst I?m not going to be quite as ?passionate? as some on this issue > (although I do understand the frustration), I would like to point out again > that this is indeed a huge gap and it is critical that it is filled ASAP. > >>> > >>> Obviously a solution where every word in a text document is a Node > would be unworkable so it would need to be architected from the ground up. > >>> > >>> I would be happy to work on such as feature, just as I was happy to > work on implementing WebGL, but my hesitation is concern over the > assistance and involvement from Oracle. > >>> > >>> If I am going to have to spend months working on something without any > or only minimal involvement from Oracle, only to find at the end that > Oracle either doesn?t like the design, implementation or something else > then it is wasted time I?ll never get back. > >>> > >>> There are lots of other innovations too that I would like to see in > JavaFX but I just don?t ?feel the enthusiasm? from Oracle. > >>> > >>> If there is someone on the JavaFX team who would be willing to work > with me (at least in some capacity), please have them contact me privately > via email. > >>> > >>> The innovations I could work on and contribute include: > >>> > >>> 1. WebGL support in WebView > >>> 2. Better text support including text documents& rich text editors > etc. > >>> 3. Significant improvements in scene graph rendering speed using > >>> modern game-engine style structures and algorithms > >>> > >>> JavaFX cannot survive without innovation and I am keen to see it > happen and contribute as much as possible. > >>> > >>> Graciously, > >>> > >>> John-Val Rose > >>> Rosethorn Technology > >>> > >>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: > >>>> > >>>> Sorry about all the typos previously. > >>>> > >>>> Question- why not use the code in awt ? I am not totally up on what's > going on with the platforms' native rendering engines ( meaning, I have no > idea whatsoever) or how they have changed, but golly it sure does still > work pretty well. > >>>> > >>>> At least it seems to me looking at awt that a smallish number of > things are 1) well defined by the native platofrm and 2) would more or less > translate directly to an Java API and 3) from those small number of > building blocks, (Font and Glyph metrics and this kind of thing) text > line layout algorithms can be written by ordinary civilians along with all > the other stuff that goes into a text editor. > >>>> > >>>> And yes, everything does look easy when someone else is going to do > it. > >>>> > >>>> > > From paulrussell70 at gmail.com Wed Dec 6 09:34:35 2017 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Wed, 6 Dec 2017 09:34:35 +0000 Subject: Innovation again (was Re: Text classes) Message-ID: Hi John, >>>Re: Significant improvements in scene graph rendering speed using modern game-engine style structures and algorithms. Agree, Also, I haven't been feeling the enthusiasm either. It's a mood that's permeating the user base. You just have to scout YouTube for JavaFX games, to read the mood. It's all feeling a bit like the last throws of Swing did. To my mind, JavaFX is the perfect 2D gaming platform, it just misses better lighting. I'd like to see the scene graph speed improved, and more work on the lighting for games. I'm busy working on our game : kattrunonthetide.com ( https://www.facebook.com/KattGame/) : Javafx is proving to be a great platform. If one "applies" azimuth lights to a flat canvas scene, (one with no scene graph) the bump mapping seems automatic. https://drive.google.com/file/d/1y0WHd5LiIWu1qSvRiHyPrPKBP2fp4gXL/view?usp=sharing But, the effect is ill documented, and I think it would be great to have more work in the this area. Some way to access pixels at high speed would be brilliant too. I know nothing of the Java shading language, JSL, and still think this would be a great addition if exposed. Currently something like LibGDX is a much better choice for games writing than JavaFX. Eyes to OpenGL, but I still think JavaFX with all it's great UI support (and FXGL library) should still be a good choice. Best, Paul On 6 December 2017 at 08:36, wrote: > Send openjfx-dev mailing list submissions to > openjfx-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > or, via email, send a message with subject or body 'help' to > openjfx-dev-request at openjdk.java.net > > You can reach the person managing the list at > openjfx-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openjfx-dev digest..." > > > Today's Topics: > > 1. Re: Innovation again (was Re: Text classes) (John-Val Rose) > 2. RE: Innovation again (was Re: Text classes) (Markus KARG) > 3. Re: Innovation again (was Re: Text classes) (Mario Torre) > 4. RE: Innovation again (was Re: Text classes) (Markus KARG) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 6 Dec 2017 17:16:07 +1100 > From: John-Val Rose > To: Philip Race > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Innovation again (was Re: Text classes) > Message-ID: <2FA8027D-79B1-4339-8BCA-6B5CB58D37E5 at gmail.com> > Content-Type: text/plain; charset=utf-8 > > Absolutely - there needs to be a viable community that is not just Oracle. > > So, is there one? If not, how do we build one? > > OK, so let me rephrase my earlier email: > > I am willing to work with *anyone* (within Oracle or not) on the features > that the community craves, such as those I listed (and any others). Not > just because ?many hands make light work? but because I don?t know > everything (or even close) and I need the knowledge and skills of others to > assist me. Not to mention that I have only 24 hours in a day like everyone > else and, also like everyone else, some of that time has to be devoted to > earning an income. > > So, if there?s anyone reading this who has the time, the skills, the > commitment and the passion to work hard (in your own time) to get these > tasks done then please contact me privately. > > > On 6 Dec 2017, at 16:50, Philip Race wrote: > > > > There needs to be a viable community that is not just Oracle to support > you here .. > > I think everyone has come to be dependent on Oracle to "be there". > > But if there is a specific community need that Oracle doesn't see as > essential, then the community should help out. > > > > -phil. > > > >> On 12/5/17, 9:27 PM, John-Val Rose wrote: > >> Well, that?s all fine but you didn?t address the issue of working with > someone within Oracle to get these innovations done. > >> > >> Sure, I could just toil away by myself but clearly it would be better > all around if there was someone with much more extensive knowledge of > JavaFX and its internals who was accessible when required. > >> > >> I would assume that a member of the Oracle JavaFX team would be such a > person. If not, then who? > >> > >>> On 6 Dec 2017, at 15:53, Philip Race wrote: > >>> > >>> I think looking at it as an Oracle-owned and controlled project maybe > the first mistake here. > >>> Yes it was closed source and then Oracle controlled, but not any more, > OCA requirements aside. > >>> It is not even a "java specification". It can be evolved at an API > level without a JSR. > >>> The JEP process is the main thing to be followed, although we also use > CSRs too to track API. > >>> Consider it that anyone who is a contributor owns (not the right word > ?) a piece of it too. > >>> So standing on the project is what matters. Not the company who pays > you to work on it. > >>> > >>> -phil. > >>> > >>>> On 12/5/17, 8:21 PM, John-Val Rose wrote: > >>>> Phil et. al., > >>>> > >>>> Whilst I?m not going to be quite as ?passionate? as some on this > issue (although I do understand the frustration), I would like to point out > again that this is indeed a huge gap and it is critical that it is filled > ASAP. > >>>> > >>>> Obviously a solution where every word in a text document is a Node > would be unworkable so it would need to be architected from the ground up. > >>>> > >>>> I would be happy to work on such as feature, just as I was happy to > work on implementing WebGL, but my hesitation is concern over the > assistance and involvement from Oracle. > >>>> > >>>> If I am going to have to spend months working on something without > any or only minimal involvement from Oracle, only to find at the end that > Oracle either doesn?t like the design, implementation or something else > then it is wasted time I?ll never get back. > >>>> > >>>> There are lots of other innovations too that I would like to see in > JavaFX but I just don?t ?feel the enthusiasm? from Oracle. > >>>> > >>>> If there is someone on the JavaFX team who would be willing to work > with me (at least in some capacity), please have them contact me privately > via email. > >>>> > >>>> The innovations I could work on and contribute include: > >>>> > >>>> 1. WebGL support in WebView > >>>> 2. Better text support including text documents& rich text editors > etc. > >>>> 3. Significant improvements in scene graph rendering speed using > modern game-engine style structures and algorithms > >>>> > >>>> JavaFX cannot survive without innovation and I am keen to see it > happen and contribute as much as possible. > >>>> > >>>> Graciously, > >>>> > >>>> John-Val Rose > >>>> Rosethorn Technology > >>>> > >>>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: > >>>>> > >>>>> Sorry about all the typos previously. > >>>>> > >>>>> Question- why not use the code in awt ? I am not totally up on > what's going on with the platforms' native rendering engines ( meaning, I > have no idea whatsoever) or how they have changed, but golly it sure does > still work pretty well. > >>>>> > >>>>> At least it seems to me looking at awt that a smallish number of > things are 1) well defined by the native platofrm and 2) would more or less > translate directly to an Java API and 3) from those small number of > building blocks, (Font and Glyph metrics and this kind of thing) text > line layout algorithms can be written by ordinary civilians along with all > the other stuff that goes into a text editor. > >>>>> > >>>>> And yes, everything does look easy when someone else is going to do > it. > >>>>> > >>>>> > > > ------------------------------ > > Message: 2 > Date: Wed, 6 Dec 2017 09:07:03 +0100 > From: "Markus KARG" > To: > Subject: RE: Innovation again (was Re: Text classes) > Message-ID: <01a001d36e69$33afff70$9b0ffe50$@eu> > Content-Type: text/plain; charset="UTF-8" > > I think what John actually asked for is whom to send his design upfront at > the JFX team to get an initial judgement whether it is worth programming > it, or whether it bears such flaws that it makes not much sense to invest > any more time. Whether or not that decision is done by an Oracle employee > or not, he simply needs to know whom to sent his proposal for early review. > > -Markus > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf > Of Philip Race > Sent: Mittwoch, 6. Dezember 2017 06:50 > To: John-Val Rose > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Innovation again (was Re: Text classes) > > There needs to be a viable community that is not just Oracle to support > you here .. > I think everyone has come to be dependent on Oracle to "be there". > But if there is a specific community need that Oracle doesn't see as > essential, then the community should help out. > > -phil. > > On 12/5/17, 9:27 PM, John-Val Rose wrote: > > Well, that?s all fine but you didn?t address the issue of working with > someone within Oracle to get these innovations done. > > > > Sure, I could just toil away by myself but clearly it would be better > all around if there was someone with much more extensive knowledge of > JavaFX and its internals who was accessible when required. > > > > I would assume that a member of the Oracle JavaFX team would be such a > person. If not, then who? > > > >> On 6 Dec 2017, at 15:53, Philip Race wrote: > >> > >> I think looking at it as an Oracle-owned and controlled project maybe > the first mistake here. > >> Yes it was closed source and then Oracle controlled, but not any more, > OCA requirements aside. > >> It is not even a "java specification". It can be evolved at an API > level without a JSR. > >> The JEP process is the main thing to be followed, although we also use > CSRs too to track API. > >> Consider it that anyone who is a contributor owns (not the right word > ?) a piece of it too. > >> So standing on the project is what matters. Not the company who pays > you to work on it. > >> > >> -phil. > >> > >>> On 12/5/17, 8:21 PM, John-Val Rose wrote: > >>> Phil et. al., > >>> > >>> Whilst I?m not going to be quite as ?passionate? as some on this issue > (although I do understand the frustration), I would like to point out again > that this is indeed a huge gap and it is critical that it is filled ASAP. > >>> > >>> Obviously a solution where every word in a text document is a Node > would be unworkable so it would need to be architected from the ground up. > >>> > >>> I would be happy to work on such as feature, just as I was happy to > work on implementing WebGL, but my hesitation is concern over the > assistance and involvement from Oracle. > >>> > >>> If I am going to have to spend months working on something without any > or only minimal involvement from Oracle, only to find at the end that > Oracle either doesn?t like the design, implementation or something else > then it is wasted time I?ll never get back. > >>> > >>> There are lots of other innovations too that I would like to see in > JavaFX but I just don?t ?feel the enthusiasm? from Oracle. > >>> > >>> If there is someone on the JavaFX team who would be willing to work > with me (at least in some capacity), please have them contact me privately > via email. > >>> > >>> The innovations I could work on and contribute include: > >>> > >>> 1. WebGL support in WebView > >>> 2. Better text support including text documents& rich text editors > etc. > >>> 3. Significant improvements in scene graph rendering speed using > >>> modern game-engine style structures and algorithms > >>> > >>> JavaFX cannot survive without innovation and I am keen to see it > happen and contribute as much as possible. > >>> > >>> Graciously, > >>> > >>> John-Val Rose > >>> Rosethorn Technology > >>> > >>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: > >>>> > >>>> Sorry about all the typos previously. > >>>> > >>>> Question- why not use the code in awt ? I am not totally up on what's > going on with the platforms' native rendering engines ( meaning, I have no > idea whatsoever) or how they have changed, but golly it sure does still > work pretty well. > >>>> > >>>> At least it seems to me looking at awt that a smallish number of > things are 1) well defined by the native platofrm and 2) would more or less > translate directly to an Java API and 3) from those small number of > building blocks, (Font and Glyph metrics and this kind of thing) text > line layout algorithms can be written by ordinary civilians along with all > the other stuff that goes into a text editor. > >>>> > >>>> And yes, everything does look easy when someone else is going to do > it. > >>>> > >>>> > > > > ------------------------------ > > Message: 3 > Date: Wed, 06 Dec 2017 08:11:14 +0000 > From: Mario Torre > To: Markus KARG > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Innovation again (was Re: Text classes) > Message-ID: > wheR1tA at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > I think Phil said that, the way to propose such changes is to file a Jep > and discuss it here. > > Cheers, > Mario > > On Wed 6. Dec 2017 at 09:07, Markus KARG wrote: > > > I think what John actually asked for is whom to send his design upfront > at > > the JFX team to get an initial judgement whether it is worth programming > > it, or whether it bears such flaws that it makes not much sense to invest > > any more time. Whether or not that decision is done by an Oracle employee > > or not, he simply needs to know whom to sent his proposal for early > review. > > > > -Markus > > > > -----Original Message----- > > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On > Behalf > > Of Philip Race > > Sent: Mittwoch, 6. Dezember 2017 06:50 > > To: John-Val Rose > > Cc: openjfx-dev at openjdk.java.net > > Subject: Re: Innovation again (was Re: Text classes) > > > > There needs to be a viable community that is not just Oracle to support > > you here .. > > I think everyone has come to be dependent on Oracle to "be there". > > But if there is a specific community need that Oracle doesn't see as > > essential, then the community should help out. > > > > -phil. > > > > On 12/5/17, 9:27 PM, John-Val Rose wrote: > > > Well, that?s all fine but you didn?t address the issue of working with > > someone within Oracle to get these innovations done. > > > > > > Sure, I could just toil away by myself but clearly it would be better > > all around if there was someone with much more extensive knowledge of > > JavaFX and its internals who was accessible when required. > > > > > > I would assume that a member of the Oracle JavaFX team would be such a > > person. If not, then who? > > > > > >> On 6 Dec 2017, at 15:53, Philip Race wrote: > > >> > > >> I think looking at it as an Oracle-owned and controlled project maybe > > the first mistake here. > > >> Yes it was closed source and then Oracle controlled, but not any more, > > OCA requirements aside. > > >> It is not even a "java specification". It can be evolved at an API > > level without a JSR. > > >> The JEP process is the main thing to be followed, although we also use > > CSRs too to track API. > > >> Consider it that anyone who is a contributor owns (not the right word > > ?) a piece of it too. > > >> So standing on the project is what matters. Not the company who pays > > you to work on it. > > >> > > >> -phil. > > >> > > >>> On 12/5/17, 8:21 PM, John-Val Rose wrote: > > >>> Phil et. al., > > >>> > > >>> Whilst I?m not going to be quite as ?passionate? as some on this > issue > > (although I do understand the frustration), I would like to point out > again > > that this is indeed a huge gap and it is critical that it is filled ASAP. > > >>> > > >>> Obviously a solution where every word in a text document is a Node > > would be unworkable so it would need to be architected from the ground > up. > > >>> > > >>> I would be happy to work on such as feature, just as I was happy to > > work on implementing WebGL, but my hesitation is concern over the > > assistance and involvement from Oracle. > > >>> > > >>> If I am going to have to spend months working on something without > any > > or only minimal involvement from Oracle, only to find at the end that > > Oracle either doesn?t like the design, implementation or something else > > then it is wasted time I?ll never get back. > > >>> > > >>> There are lots of other innovations too that I would like to see in > > JavaFX but I just don?t ?feel the enthusiasm? from Oracle. > > >>> > > >>> If there is someone on the JavaFX team who would be willing to work > > with me (at least in some capacity), please have them contact me > privately > > via email. > > >>> > > >>> The innovations I could work on and contribute include: > > >>> > > >>> 1. WebGL support in WebView > > >>> 2. Better text support including text documents& rich text editors > > etc. > > >>> 3. Significant improvements in scene graph rendering speed using > > >>> modern game-engine style structures and algorithms > > >>> > > >>> JavaFX cannot survive without innovation and I am keen to see it > > happen and contribute as much as possible. > > >>> > > >>> Graciously, > > >>> > > >>> John-Val Rose > > >>> Rosethorn Technology > > >>> > > >>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: > > >>>> > > >>>> Sorry about all the typos previously. > > >>>> > > >>>> Question- why not use the code in awt ? I am not totally up on > what's > > going on with the platforms' native rendering engines ( meaning, I have > no > > idea whatsoever) or how they have changed, but golly it sure does still > > work pretty well. > > >>>> > > >>>> At least it seems to me looking at awt that a smallish number of > > things are 1) well defined by the native platofrm and 2) would more or > less > > translate directly to an Java API and 3) from those small number of > > building blocks, (Font and Glyph metrics and this kind of thing) text > > line layout algorithms can be written by ordinary civilians along with > all > > the other stuff that goes into a text editor. > > >>>> > > >>>> And yes, everything does look easy when someone else is going to do > > it. > > >>>> > > >>>> > > > > > > > ------------------------------ > > Message: 4 > Date: Wed, 6 Dec 2017 09:33:03 +0100 > From: "Markus KARG" > To: > Subject: RE: Innovation again (was Re: Text classes) > Message-ID: <001c01d36e6c$d5391e50$7fab5af0$@eu> > Content-Type: text/plain; charset="UTF-8" > > Yes, but not everything needs a JEP always. Maybe what Phil has in mind is > small enough to be accepted without. Somebody has to decide before filing > the JEP. > > -Markus > > > > From: Mario Torre [mailto:neugens.limasoftware at gmail.com] > Sent: Mittwoch, 6. Dezember 2017 09:11 > To: Markus KARG > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Innovation again (was Re: Text classes) > > > > I think Phil said that, the way to propose such changes is to file a Jep > and discuss it here. > > > > Cheers, > > Mario > > > > On Wed 6. Dec 2017 at 09:07, Markus KARG wrote: > > I think what John actually asked for is whom to send his design upfront at > the JFX team to get an initial judgement whether it is worth programming > it, or whether it bears such flaws that it makes not much sense to invest > any more time. Whether or not that decision is done by an Oracle employee > or not, he simply needs to know whom to sent his proposal for early review. > > -Markus > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf > Of Philip Race > Sent: Mittwoch, 6. Dezember 2017 06:50 > To: John-Val Rose > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Innovation again (was Re: Text classes) > > There needs to be a viable community that is not just Oracle to support > you here .. > I think everyone has come to be dependent on Oracle to "be there". > But if there is a specific community need that Oracle doesn't see as > essential, then the community should help out. > > -phil. > > On 12/5/17, 9:27 PM, John-Val Rose wrote: > > Well, that?s all fine but you didn?t address the issue of working with > someone within Oracle to get these innovations done. > > > > Sure, I could just toil away by myself but clearly it would be better > all around if there was someone with much more extensive knowledge of > JavaFX and its internals who was accessible when required. > > > > I would assume that a member of the Oracle JavaFX team would be such a > person. If not, then who? > > > >> On 6 Dec 2017, at 15:53, Philip Race wrote: > >> > >> I think looking at it as an Oracle-owned and controlled project maybe > the first mistake here. > >> Yes it was closed source and then Oracle controlled, but not any more, > OCA requirements aside. > >> It is not even a "java specification". It can be evolved at an API > level without a JSR. > >> The JEP process is the main thing to be followed, although we also use > CSRs too to track API. > >> Consider it that anyone who is a contributor owns (not the right word > ?) a piece of it too. > >> So standing on the project is what matters. Not the company who pays > you to work on it. > >> > >> -phil. > >> > >>> On 12/5/17, 8:21 PM, John-Val Rose wrote: > >>> Phil et. al., > >>> > >>> Whilst I?m not going to be quite as ?passionate? as some on this issue > (although I do understand the frustration), I would like to point out again > that this is indeed a huge gap and it is critical that it is filled ASAP. > >>> > >>> Obviously a solution where every word in a text document is a Node > would be unworkable so it would need to be architected from the ground up. > >>> > >>> I would be happy to work on such as feature, just as I was happy to > work on implementing WebGL, but my hesitation is concern over the > assistance and involvement from Oracle. > >>> > >>> If I am going to have to spend months working on something without any > or only minimal involvement from Oracle, only to find at the end that > Oracle either doesn?t like the design, implementation or something else > then it is wasted time I?ll never get back. > >>> > >>> There are lots of other innovations too that I would like to see in > JavaFX but I just don?t ?feel the enthusiasm? from Oracle. > >>> > >>> If there is someone on the JavaFX team who would be willing to work > with me (at least in some capacity), please have them contact me privately > via email. > >>> > >>> The innovations I could work on and contribute include: > >>> > >>> 1. WebGL support in WebView > >>> 2. Better text support including text documents& rich text editors > etc. > >>> 3. Significant improvements in scene graph rendering speed using > >>> modern game-engine style structures and algorithms > >>> > >>> JavaFX cannot survive without innovation and I am keen to see it > happen and contribute as much as possible. > >>> > >>> Graciously, > >>> > >>> John-Val Rose > >>> Rosethorn Technology > >>> > >>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: > >>>> > >>>> Sorry about all the typos previously. > >>>> > >>>> Question- why not use the code in awt ? I am not totally up on what's > going on with the platforms' native rendering engines ( meaning, I have no > idea whatsoever) or how they have changed, but golly it sure does still > work pretty well. > >>>> > >>>> At least it seems to me looking at awt that a smallish number of > things are 1) well defined by the native platofrm and 2) would more or less > translate directly to an Java API and 3) from those small number of > building blocks, (Font and Glyph metrics and this kind of thing) text > line layout algorithms can be written by ordinary civilians along with all > the other stuff that goes into a text editor. > >>>> > >>>> And yes, everything does look easy when someone else is going to do > it. > >>>> > >>>> > > > > End of openjfx-dev Digest, Vol 73, Issue 11 > ******************************************* > From markus at headcrashing.eu Wed Dec 6 09:39:21 2017 From: markus at headcrashing.eu (Markus KARG) Date: Wed, 6 Dec 2017 10:39:21 +0100 Subject: Innovation again (was Re: Text classes) In-Reply-To: References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> <5A2777E2.7050106@oracle.com> <5A278521.8050202@oracle.com> <01a001d36e69$33afff70$9b0ffe50$@eu> <001c01d36e6c$d5391e50$7fab5af0$@eu> Message-ID: <003001d36e76$1b57ede0$5207c9a0$@eu> I understand your situation very well, as it is the same for me. What would be great would be some mentor at the OpenJFX team who helps to get external contributors at speed. Not only he could decide what needs a JEP or review it before filing, he also could help with coding standards, tooling and building, and so on. I think every open source project the size of OpenJDK should have such mentors. Unfortunately, least do. -Markus From: John-Val Rose [mailto:johnvalrose at gmail.com] Sent: Mittwoch, 6. Dezember 2017 09:41 To: Markus KARG Cc: openjfx-dev at openjdk.java.net Mailing Subject: Re: Innovation again (was Re: Text classes) Yes, I obviously need to know if anything I work on or design is going to be accepted or is even wanted by the community as a whole, and as early on in the process as possible. Heck, if I had my way, JavaFX would be used to build everything from forms to FPS games and highly complex and performant 3D visualizations. And don't say it can't be done in Java - it can. JavaMonkeyEngine can be used to create awesome games (for example). Plus, I have never "done" a JEP but I believe it's quite a long and involved process (?) So, I would appreciate some clarification on the best process and steps to take to go from ideas to released features. ?? Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology On 6 December 2017 at 19:33, Markus KARG wrote: Yes, but not everything needs a JEP always. Maybe what Phil has in mind is small enough to be accepted without. Somebody has to decide before filing the JEP. -Markus From: Mario Torre [mailto:neugens.limasoftware at gmail.com] Sent: Mittwoch, 6. Dezember 2017 09:11 To: Markus KARG Cc: openjfx-dev at openjdk.java.net Subject: Re: Innovation again (was Re: Text classes) I think Phil said that, the way to propose such changes is to file a Jep and discuss it here. Cheers, Mario On Wed 6. Dec 2017 at 09:07, Markus KARG wrote: I think what John actually asked for is whom to send his design upfront at the JFX team to get an initial judgement whether it is worth programming it, or whether it bears such flaws that it makes not much sense to invest any more time. Whether or not that decision is done by an Oracle employee or not, he simply needs to know whom to sent his proposal for early review. -Markus -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Philip Race Sent: Mittwoch, 6. Dezember 2017 06:50 To: John-Val Rose Cc: openjfx-dev at openjdk.java.net Subject: Re: Innovation again (was Re: Text classes) There needs to be a viable community that is not just Oracle to support you here .. I think everyone has come to be dependent on Oracle to "be there". But if there is a specific community need that Oracle doesn't see as essential, then the community should help out. -phil. On 12/5/17, 9:27 PM, John-Val Rose wrote: > Well, that?s all fine but you didn?t address the issue of working with someone within Oracle to get these innovations done. > > Sure, I could just toil away by myself but clearly it would be better all around if there was someone with much more extensive knowledge of JavaFX and its internals who was accessible when required. > > I would assume that a member of the Oracle JavaFX team would be such a person. If not, then who? > >> On 6 Dec 2017, at 15:53, Philip Race wrote: >> >> I think looking at it as an Oracle-owned and controlled project maybe the first mistake here. >> Yes it was closed source and then Oracle controlled, but not any more, OCA requirements aside. >> It is not even a "java specification". It can be evolved at an API level without a JSR. >> The JEP process is the main thing to be followed, although we also use CSRs too to track API. >> Consider it that anyone who is a contributor owns (not the right word ?) a piece of it too. >> So standing on the project is what matters. Not the company who pays you to work on it. >> >> -phil. >> >>> On 12/5/17, 8:21 PM, John-Val Rose wrote: >>> Phil et. al., >>> >>> Whilst I?m not going to be quite as ?passionate? as some on this issue (although I do understand the frustration), I would like to point out again that this is indeed a huge gap and it is critical that it is filled ASAP. >>> >>> Obviously a solution where every word in a text document is a Node would be unworkable so it would need to be architected from the ground up. >>> >>> I would be happy to work on such as feature, just as I was happy to work on implementing WebGL, but my hesitation is concern over the assistance and involvement from Oracle. >>> >>> If I am going to have to spend months working on something without any or only minimal involvement from Oracle, only to find at the end that Oracle either doesn?t like the design, implementation or something else then it is wasted time I?ll never get back. >>> >>> There are lots of other innovations too that I would like to see in JavaFX but I just don?t ?feel the enthusiasm? from Oracle. >>> >>> If there is someone on the JavaFX team who would be willing to work with me (at least in some capacity), please have them contact me privately via email. >>> >>> The innovations I could work on and contribute include: >>> >>> 1. WebGL support in WebView >>> 2. Better text support including text documents& rich text editors etc. >>> 3. Significant improvements in scene graph rendering speed using >>> modern game-engine style structures and algorithms >>> >>> JavaFX cannot survive without innovation and I am keen to see it happen and contribute as much as possible. >>> >>> Graciously, >>> >>> John-Val Rose >>> Rosethorn Technology >>> >>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: >>>> >>>> Sorry about all the typos previously. >>>> >>>> Question- why not use the code in awt ? I am not totally up on what's going on with the platforms' native rendering engines ( meaning, I have no idea whatsoever) or how they have changed, but golly it sure does still work pretty well. >>>> >>>> At least it seems to me looking at awt that a smallish number of things are 1) well defined by the native platofrm and 2) would more or less translate directly to an Java API and 3) from those small number of building blocks, (Font and Glyph metrics and this kind of thing) text line layout algorithms can be written by ordinary civilians along with all the other stuff that goes into a text editor. >>>> >>>> And yes, everything does look easy when someone else is going to do it. >>>> >>>> From krichter at posteo.de Wed Dec 6 09:43:56 2017 From: krichter at posteo.de (Karl-Philipp Richter) Date: Wed, 6 Dec 2017 10:43:56 +0100 Subject: Build issues on Ubuntu 16.04, 17.10 and 18.04-daily inside Docker Message-ID: Hi, I'm experiencing the following issues when building OpenJFX following https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX inside Ubuntu Docker images `ubuntu:[version]` which are official and as empty as possible. Afaik the build instructions or the supported list of OS is quite old (only Ubuntu LTS version 14.04 and 16.04 are still supported and up-to-date 17.10 and 18.04-daily are left out of the picture). My motivation here is to improve the build process of OpenJFX, but not only me alone. You might have you own CI, but in case you agree that the following are real issues, I can only recommend GitLab CI (your own instance or the one at gitlab.com) which allows to test whether build instructions are working on any docker image you can image and can be used parallel to existing infrastructure. I used it now to allow you to reproduce the issues as easily as possible: For `ubuntu:14.04` and `ubuntu:16.04` I get: [ant:taskdef] Could not load definitions from resource com/sun/javafx/tools/ant/antlib.xml. It could not be found. :apps:appsJarLinux FAILED FAILURE: Build failed with an exception. * Where: Build file '/builds/krichter/openjfx-8u-dev-rt/build.gradle' line: 3241 * What went wrong: Execution failed for task ':apps:appsJarLinux'. > The following error occurred while executing this line: /builds/krichter/openjfx-8u-dev-rt/apps/samples/build.xml:14: The following error occurred while executing this line: /builds/krichter/openjfx-8u-dev-rt/apps/samples/Ensemble8/build.xml:158: Problem: failed to create task or type javafx:com.sun.javafx.tools.ant:application Cause: The name is undefined. Action: Check the spelling. Action: Check that any custom tasks/types have been declared. Action: Check that any / declarations have taken place. No types or tasks have been defined in this namespace yet For `ubuntu:17.10` and `ubuntu:18.04` I get: :fxpackager:compileLinuxLibrary/builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:130:9: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] "jre/lib/"JAVAARCH"/client/libjvm.so"; ^ /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:134:13: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] "jre/lib/"JAVAARCH"/server/libjvm.so"; ^ /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:139:13: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] "lib/"JAVAARCH"/server/libjvm.so"; ^ /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:144:13: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] "lib/"JAVAARCH"/server/libjvm.so"; ^ /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:189:16: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] _T("/lib/"JAVAARCH"/client/libjvm.so"); ^ /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:193:20: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] _T("/lib/"JAVAARCH"/server/libjvm.so"); ^ /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp: In member function 'virtual bool PosixProcess::Wait()': /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp:235:5: error: 'wait' was not declared in this scope wait(); ^~~~ /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp:235:5: note: suggested alternative: 'Wait' wait(); ^~~~ Wait /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/Java.cpp: In destructor 'JavaClass::~JavaClass()': /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/Java.cpp:237:46: warning: throw will always call terminate() [-Wterminate] throw JavaException(FEnv, _T("Error")); ^ /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/Java.cpp:237:46: note: in C++11 destructors default to noexcept FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':fxpackager:compileLinuxLibrary'. > Could not call NativeCompileTask.compile() on task ':fxpackager:compileLinuxLibrary' Details and complete build logs can be found at https://gitlab.com/krichter/openjfx-8u-dev-rt/pipelines/14781176. The build script `.gitlab-ci.yml` contains the commands used to build. -Kalle From neugens.limasoftware at gmail.com Wed Dec 6 10:10:17 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 6 Dec 2017 11:10:17 +0100 Subject: Innovation again (was Re: Text classes) In-Reply-To: References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> <5A2777E2.7050106@oracle.com> <5A278521.8050202@oracle.com> <01a001d36e69$33afff70$9b0ffe50$@eu> <001c01d36e6c$d5391e50$7fab5af0$@eu> Message-ID: 2017-12-06 9:40 GMT+01:00 John-Val Rose : > Yes, I obviously need to know if anything I work on or design is going to > be accepted or is even wanted by the community as a whole, and as early on > in the process as possible. Heck, if I had my way, JavaFX would be used to > build everything from forms to FPS games and highly complex and performant > 3D visualizations. And don't say it can't be done in Java - it can. > JavaMonkeyEngine can be used to create awesome games (for example). If I understood correctly the change is big enough to need a JEP. Generally, you need a JEP for new features, new API and big changes. You don't need for bug fixes and internal refactoring. So, for instance, adding a new port to the graphics need a JEP. It's up to the project maintainer to say whether that should be a JEP or not, though. > Plus, I have never "done" a JEP but I believe it's quite a long and > involved process (?) Well, that doesn't mean you can avoid it ;) I did work only with the two previous drafts of the JEP, but the latest draft is a lot quicker (simply file a bug report basically). The JEP is detailed here: http://openjdk.java.net/jeps/1 http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html The second link is the current version, the first link is for reference since this is where the process should be detailed, but hasn't been merged yet. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From bourges.laurent at gmail.com Wed Dec 6 10:18:37 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 6 Dec 2017 11:18:37 +0100 Subject: Build issues on Ubuntu 16.04, 17.10 and 18.04-daily inside Docker In-Reply-To: References: Message-ID: Hi, My 2 cents: I reported a JavaFX build problem with GCC 6: https://bugs.openjdk.java.net/browse/JDK-8189689 It gives a workaround for the wait() bug: wait(&status); Laurent 2017-12-06 10:43 UTC+01:00, Karl-Philipp Richter : > Hi, > I'm experiencing the following issues when building OpenJFX following > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX inside > Ubuntu Docker images `ubuntu:[version]` which are official and as empty > as possible. Afaik the build instructions or the supported list of OS is > quite old (only Ubuntu LTS version 14.04 and 16.04 are still supported > and up-to-date 17.10 and 18.04-daily are left out of the picture). My > motivation here is to improve the build process of OpenJFX, but not only > me alone. You might have you own CI, but in case you agree that the > following are real issues, I can only recommend GitLab CI (your own > instance or the one at gitlab.com) which allows to test whether build > instructions are working on any docker image you can image and can be > used parallel to existing infrastructure. I used it now to allow you to > reproduce the issues as easily as possible: > > For `ubuntu:14.04` and `ubuntu:16.04` I get: > > [ant:taskdef] Could not load definitions from resource > com/sun/javafx/tools/ant/antlib.xml. It could not be found. > :apps:appsJarLinux FAILED > > FAILURE: Build failed with an exception. > > * Where: > Build file '/builds/krichter/openjfx-8u-dev-rt/build.gradle' line: 3241 > > * What went wrong: > Execution failed for task ':apps:appsJarLinux'. > > The following error occurred while executing this line: > /builds/krichter/openjfx-8u-dev-rt/apps/samples/build.xml:14: The > following error occurred while executing this line: > > /builds/krichter/openjfx-8u-dev-rt/apps/samples/Ensemble8/build.xml:158: > Problem: failed to create task or type > javafx:com.sun.javafx.tools.ant:application > Cause: The name is undefined. > Action: Check the spelling. > Action: Check that any custom tasks/types have been declared. > Action: Check that any / declarations have > taken place. > No types or tasks have been defined in this namespace yet > > For `ubuntu:17.10` and `ubuntu:18.04` I get: > > > :fxpackager:compileLinuxLibrary/builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:130:9: > warning: invalid suffix on literal; C++11 requires a space between > literal and string macro [-Wliteral-suffix] > "jre/lib/"JAVAARCH"/client/libjvm.so"; > ^ > > /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:134:13: > warning: invalid suffix on literal; C++11 requires a space between > literal and string macro [-Wliteral-suffix] > "jre/lib/"JAVAARCH"/server/libjvm.so"; > ^ > > /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:139:13: > warning: invalid suffix on literal; C++11 requires a space between > literal and string macro [-Wliteral-suffix] > "lib/"JAVAARCH"/server/libjvm.so"; > ^ > > /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:144:13: > warning: invalid suffix on literal; C++11 requires a space between > literal and string macro [-Wliteral-suffix] > "lib/"JAVAARCH"/server/libjvm.so"; > ^ > > /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:189:16: > warning: invalid suffix on literal; C++11 requires a space between > literal and string macro [-Wliteral-suffix] > _T("/lib/"JAVAARCH"/client/libjvm.so"); > ^ > > /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:193:20: > warning: invalid suffix on literal; C++11 requires a space between > literal and string macro [-Wliteral-suffix] > _T("/lib/"JAVAARCH"/server/libjvm.so"); > ^ > > /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp: > In member function 'virtual bool PosixProcess::Wait()': > > /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp:235:5: > error: 'wait' was not declared in this scope > wait(); > ^~~~ > > /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp:235:5: > note: suggested alternative: 'Wait' > wait(); > ^~~~ > Wait > > /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/Java.cpp: > In destructor 'JavaClass::~JavaClass()': > > /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/Java.cpp:237:46: > warning: throw will always call terminate() [-Wterminate] > throw JavaException(FEnv, _T("Error")); > ^ > > /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/Java.cpp:237:46: > note: in C++11 destructors default to noexcept > FAILED > > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':fxpackager:compileLinuxLibrary'. > > Could not call NativeCompileTask.compile() on task > ':fxpackager:compileLinuxLibrary' > > Details and complete build logs can be found at > https://gitlab.com/krichter/openjfx-8u-dev-rt/pipelines/14781176. The > build script `.gitlab-ci.yml` contains the commands used to build. > > -Kalle > > -- -- Laurent Bourg?s From sadhak001 at gmail.com Wed Dec 6 15:58:28 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Wed, 06 Dec 2017 15:58:28 +0000 Subject: javapackager: MacOSX: question about adding a file to the DMG outside of the app bundler Message-ID: Hi, Has anyone worked out how to add a file like a README.txt into the DMG volume such that its not bundled into the app bundler (.app file) but placed outside it so that it is visible when the DMG volume is mounted for installation? It sounds like a simple action but the usage or docs don't point to it directly - from the options so far, it seems it might not be possible. How else can we present this to the end-user? Any thoughts on this? Thanks. Cheers, Mani -- @theNeomatrix369 | Blog | @adoptopenjdk | Dev communities Meet-a-Project - MutabilityDetector | Github | Slideshare | LinkedIn Come to Devoxx UK 2018: http://www.devoxx.co.uk/ Don't chase success, rather aim for "Excellence", and success will come chasing after you! From mp at jugs.org Wed Dec 6 16:51:40 2017 From: mp at jugs.org (Michael Paus) Date: Wed, 6 Dec 2017 17:51:40 +0100 Subject: javapackager: MacOSX: question about adding a file to the DMG outside of the app bundler In-Reply-To: References: Message-ID: <7710970c-dd3b-0f9d-6c8d-e64b62fa26f4@jugs.org> I have not tried it myself but this post http://crazyedy.com/tech/?p=535 claims that it is possible to add something like a readme after the DMG file has been created by making it writable. Am 06.12.17 um 16:58 schrieb Mani Sarkar: > Hi, > > Has anyone worked out how to add a file like a README.txt into the DMG > volume such that its not bundled into the app bundler (.app file) but > placed outside it so that it is visible when the DMG volume is mounted for > installation? > > It sounds like a simple action but the usage or docs don't point to it > directly - from the options so far, it seems it might not be possible. How > else can we present this to the end-user? > > Any thoughts on this? > > Thanks. > > Cheers, > Mani From kevin.rushforth at oracle.com Wed Dec 6 18:10:54 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 06 Dec 2017 10:10:54 -0800 Subject: Build issues on Ubuntu 16.04, 17.10 and 18.04-daily inside Docker In-Reply-To: References: Message-ID: <5A2832AE.4010305@oracle.com> We ought to get a fix for JDK-8189689 in sooner rather than later to allow builds to continue to work on newer versions of gcc. Maybe right after the JDK 10 RDP1 fork would be a good time. As for the other error (the one from ant), you need 'ant' in your path in order to build the apps. ant 1.8.2 is what we use (we had some problems with 1.9 based versions, but I don't recall specifically if that was something in the apps build that was failing). It's clear from the various build problems that folks are having, that the build instructions on the Wiki needs updating. I can take a stab at that after the JDK 10 RDP1 deadline has passed. If anyone wants to share their build problems, I can see about incorporating that into the Wiki. -- Kevin Laurent Bourg?s wrote: > Hi, > > My 2 cents: I reported a JavaFX build problem with GCC 6: > https://bugs.openjdk.java.net/browse/JDK-8189689 > > It gives a workaround for the wait() bug: > wait(&status); > > Laurent > > 2017-12-06 10:43 UTC+01:00, Karl-Philipp Richter : > >> Hi, >> I'm experiencing the following issues when building OpenJFX following >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX inside >> Ubuntu Docker images `ubuntu:[version]` which are official and as empty >> as possible. Afaik the build instructions or the supported list of OS is >> quite old (only Ubuntu LTS version 14.04 and 16.04 are still supported >> and up-to-date 17.10 and 18.04-daily are left out of the picture). My >> motivation here is to improve the build process of OpenJFX, but not only >> me alone. You might have you own CI, but in case you agree that the >> following are real issues, I can only recommend GitLab CI (your own >> instance or the one at gitlab.com) which allows to test whether build >> instructions are working on any docker image you can image and can be >> used parallel to existing infrastructure. I used it now to allow you to >> reproduce the issues as easily as possible: >> >> For `ubuntu:14.04` and `ubuntu:16.04` I get: >> >> [ant:taskdef] Could not load definitions from resource >> com/sun/javafx/tools/ant/antlib.xml. It could not be found. >> :apps:appsJarLinux FAILED >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Build file '/builds/krichter/openjfx-8u-dev-rt/build.gradle' line: 3241 >> >> * What went wrong: >> Execution failed for task ':apps:appsJarLinux'. >> > The following error occurred while executing this line: >> /builds/krichter/openjfx-8u-dev-rt/apps/samples/build.xml:14: The >> following error occurred while executing this line: >> >> /builds/krichter/openjfx-8u-dev-rt/apps/samples/Ensemble8/build.xml:158: >> Problem: failed to create task or type >> javafx:com.sun.javafx.tools.ant:application >> Cause: The name is undefined. >> Action: Check the spelling. >> Action: Check that any custom tasks/types have been declared. >> Action: Check that any / declarations have >> taken place. >> No types or tasks have been defined in this namespace yet >> >> For `ubuntu:17.10` and `ubuntu:18.04` I get: >> >> >> :fxpackager:compileLinuxLibrary/builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:130:9: >> warning: invalid suffix on literal; C++11 requires a space between >> literal and string macro [-Wliteral-suffix] >> "jre/lib/"JAVAARCH"/client/libjvm.so"; >> ^ >> >> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:134:13: >> warning: invalid suffix on literal; C++11 requires a space between >> literal and string macro [-Wliteral-suffix] >> "jre/lib/"JAVAARCH"/server/libjvm.so"; >> ^ >> >> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:139:13: >> warning: invalid suffix on literal; C++11 requires a space between >> literal and string macro [-Wliteral-suffix] >> "lib/"JAVAARCH"/server/libjvm.so"; >> ^ >> >> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:144:13: >> warning: invalid suffix on literal; C++11 requires a space between >> literal and string macro [-Wliteral-suffix] >> "lib/"JAVAARCH"/server/libjvm.so"; >> ^ >> >> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:189:16: >> warning: invalid suffix on literal; C++11 requires a space between >> literal and string macro [-Wliteral-suffix] >> _T("/lib/"JAVAARCH"/client/libjvm.so"); >> ^ >> >> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/LinuxPlatform.cpp:193:20: >> warning: invalid suffix on literal; C++11 requires a space between >> literal and string macro [-Wliteral-suffix] >> _T("/lib/"JAVAARCH"/server/libjvm.so"); >> ^ >> >> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp: >> In member function 'virtual bool PosixProcess::Wait()': >> >> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp:235:5: >> error: 'wait' was not declared in this scope >> wait(); >> ^~~~ >> >> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp:235:5: >> note: suggested alternative: 'Wait' >> wait(); >> ^~~~ >> Wait >> >> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/Java.cpp: >> In destructor 'JavaClass::~JavaClass()': >> >> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/Java.cpp:237:46: >> warning: throw will always call terminate() [-Wterminate] >> throw JavaException(FEnv, _T("Error")); >> ^ >> >> /builds/krichter/openjfx-8u-dev-rt/modules/fxpackager/src/main/native/library/common/Java.cpp:237:46: >> note: in C++11 destructors default to noexcept >> FAILED >> >> FAILURE: Build failed with an exception. >> >> * What went wrong: >> Execution failed for task ':fxpackager:compileLinuxLibrary'. >> > Could not call NativeCompileTask.compile() on task >> ':fxpackager:compileLinuxLibrary' >> >> Details and complete build logs can be found at >> https://gitlab.com/krichter/openjfx-8u-dev-rt/pipelines/14781176. The >> build script `.gitlab-ci.yml` contains the commands used to build. >> >> -Kalle >> >> >> > > > From victor.drozdov at oracle.com Thu Dec 7 02:36:32 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Wed, 6 Dec 2017 18:36:32 -0800 Subject: [10] Review request: 8193161: NullPointerException when generating image/installer on Linux Message-ID: Alexander, Please review the changes about fixing NPE when generating an image or installer on Linux. JIRA: https://bugs.openjdk.java.net/browse/JDK-8193161 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8193161/webrev.00/ --Victor From philip.race at oracle.com Thu Dec 7 03:15:06 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 06 Dec 2017 19:15:06 -0800 Subject: RFR: 8089900: [Mac, Font] NPE in MacFontFinder.populateFontFileNameMap Message-ID: <5A28B23A.2090304@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8089900 Webrev : http://cr.openjdk.java.net/~prr/8089900/ Reported numerous times over many years and releases. Root cause in core text not known but we can avoid the NPE Read the bug report and it's duplicates for more details. -phil. From murali.billa at oracle.com Thu Dec 7 13:40:48 2017 From: murali.billa at oracle.com (Murali Billa) Date: Thu, 7 Dec 2017 05:40:48 -0800 (PST) Subject: [10] Review request: 8187483: Update to 605.1 version of WebKit In-Reply-To: <7c6cf31e-0f42-4120-8bd1-db40411358b0@default> References: <7c6cf31e-0f42-4120-8bd1-db40411358b0@default> Message-ID: Hi All, Following webrev contains changes to upgrade to newer WebKit which is based on GTK WebKit 2.18 [1]. http://cr.openjdk.java.net/~mbilla/8187483/webrev.01/ Above link has one webrev and one patchset file. 1. rt-non-webkit ? Contains changes other than "modules/javafx.web/src/main/native", it will be useful only for review. 2. rt.changeset.gz ? Actual changeset file in compressed format which contains all the changes from ?rt? directory, uncompress before using it(gunzip rt.changeset.gz) and do the following steps. $ cd rt $ hg import --no-commit rt.changeset #(from rt.changset.gz) Please review and let me know the feedback. [1] https://trac.webkit.org/wiki/WebKitGTK/2.18.x Thanks, Murali From kevin.rushforth at oracle.com Thu Dec 7 17:51:51 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 07 Dec 2017 09:51:51 -0800 Subject: [Fwd: JDK 10 enters Rampdown Phase One in one week] Message-ID: <5A297FB7.2090902@oracle.com> We will follow the same deadline for JavaFX: Changes for JDK 10 are due into jfx-dev/rt by 16:00 UTC (which is 8:00 am Pacific) on Thursday, Dec 14. -- Kevin -------------- next part -------------- An embedded message was scrubbed... From: mark.reinhold at oracle.com Subject: JDK 10 enters Rampdown Phase One in one week Date: Thu, 7 Dec 2017 07:58:44 -0800 (PST) Size: 6064 URL: From victor.drozdov at oracle.com Fri Dec 8 01:07:20 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Thu, 7 Dec 2017 17:07:20 -0800 Subject: [10] Review request: 8191514: Deprecate com.sun.* and com.oracle.* packages in jdk.packager for removal Message-ID: Kevin, Please review the changes about deprecating com.sun.* and com.oracle.* packages for removal. JIRA: https://bugs.openjdk.java.net/browse/JDK-8191514 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8191951/webrev.00/ --Victor From kevin.rushforth at oracle.com Fri Dec 8 01:12:39 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 07 Dec 2017 17:12:39 -0800 Subject: [8u] Review request: 8145604 & 8145602 : Remove QTKit based media player Message-ID: <5A29E707.6060707@oracle.com> Hi Alexander, Please review the following backports to JDK 8u of two related fixes that went into JDK 9: https://bugs.openjdk.java.net/browse/JDK-8145604 http://cr.openjdk.java.net/~kcr/8145604/8u/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8145602 http://cr.openjdk.java.net/~kcr/8145602/8u/webrev.00/ These are needed to allow FX 8u-dev to build on macOS 10.12 and Xcode 9.1, which in turn are needed to build the latest WebKit (which is in the process of being backported). Details are in JBS. -- Kevin From johan.vos at gluonhq.com Fri Dec 8 13:46:38 2017 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 08 Dec 2017 13:46:38 +0000 Subject: CSS reference URL? Message-ID: Hi, Our Pro JavaFX 9 book is about to be published, and it will contain links to online resources. One very useful resource is the CSS reference. For JavaFX 8, this was at https://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html but I can't find it for JavaFX 9 so far? - Johan From kevin.rushforth at oracle.com Fri Dec 8 13:50:01 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 08 Dec 2017 05:50:01 -0800 Subject: CSS reference URL? In-Reply-To: References: Message-ID: <5A2A9889.1040805@oracle.com> https://docs.oracle.com/javase/9/docs/api/javafx/scene/doc-files/cssref.html -- Kevin Johan Vos wrote: > Hi, > > Our Pro JavaFX 9 book is about to be published, and it will contain links > to online resources. One very useful resource is the CSS reference. For > JavaFX 8, this was at > https://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html > but > I can't find it for JavaFX 9 so far? > > - Johan > From david.grieve at oracle.com Fri Dec 8 14:13:25 2017 From: david.grieve at oracle.com (David Grieve) Date: Fri, 8 Dec 2017 09:13:25 -0500 Subject: CSS reference URL? In-Reply-To: References: Message-ID: https://docs.oracle.com/javase/9/docs/api/javafx/scene/doc-files/cssref.html On 12/8/17 8:46 AM, Johan Vos wrote: > Hi, > > Our Pro JavaFX 9 book is about to be published, and it will contain links > to online resources. One very useful resource is the CSS reference. For > JavaFX 8, this was at > https://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html > but > I can't find it for JavaFX 9 so far? > > - Johan From ambarish.rapte at oracle.com Fri Dec 8 17:59:03 2017 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Fri, 8 Dec 2017 09:59:03 -0800 (PST) Subject: [10] Review request : JDK-8183520 : [linux] NPE when switching Scene Message-ID: <3305d5d9-c6b6-44e1-afa5-55bbc75474af@default> Hi Kevin & Ajit, Request you to review this fix, Issue: https://bugs.openjdk.java.net/browse/JDK-8183520 Webrev: http://cr.openjdk.java.net/~arapte/fx/8183520/webrev.00/ Regards, Ambarish From johan.vos at gluonhq.com Fri Dec 8 21:12:49 2017 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 08 Dec 2017 21:12:49 +0000 Subject: CSS reference URL? In-Reply-To: References: Message-ID: Thanks David and Kevin, your work is very much appreciated. - Johan On Fri, Dec 8, 2017 at 3:24 PM David Grieve wrote: > > https://docs.oracle.com/javase/9/docs/api/javafx/scene/doc-files/cssref.html > > > On 12/8/17 8:46 AM, Johan Vos wrote: > > Hi, > > > > Our Pro JavaFX 9 book is about to be published, and it will contain links > > to online resources. One very useful resource is the CSS reference. For > > JavaFX 8, this was at > > > https://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html > > but > > I can't find it for JavaFX 9 so far? > > > > - Johan > > From bourges.laurent at gmail.com Fri Dec 8 22:01:52 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 8 Dec 2017 23:01:52 +0100 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: <5A038C1E.50607@oracle.com> References: <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> <59B004BF.2000105@oracle.com> <018f1daa-d154-9d97-88f7-93bc0a376293@oracle.com> <5A038C1E.50607@oracle.com> Message-ID: Hi Kevin, Here is the updated patch providing MarlinFX-0.8.2 to OpenJFX-10 that provides an efficient path clipper fixing the bug JDK-8184429: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-082-8184429.0/ It is up-to-date with jfx-dev / jdk forrest (10) and recent changes from the Marlin 0.8.2 patch under review (2d). Changes: - (D)MarlinPrismUtils share lots of code from (D)MarlinRenderingEngine to initialize clipping & Marlin Stroker / Filler pipelines - It does not include the ClipShapeTest (2d) as it needs rewritting to use JavaFX API. PS: Use the Test class (from jbs bug) to see large performance gains Cheers, Laurent 2017-11-08 23:58 UTC+01:00, Kevin Rushforth : > And once we are happy with the 2D webrev, it should be pretty > straight-forward to review it for FX. > > -- Kevin > > > Phil Race wrote: >> I think they should be separate webrevs sent to the separate lists and >> you should start with 2D >> as I can then run the JDK regression tests on it. I know you can >> theoretically run the open regression >> tests too (are you ?) but there are some random scattered closed >> regression tests that so far >> as I can see can be open sourced .. that I can run but you can't .. >> I'll at least run the >> automated ones. I wouldn't call them anything very focused on testing >> rasterization but >> I can at least check off that concern .. >> >> And yes, I'll make time to review it. >> >> -phil. From victor.drozdov at oracle.com Fri Dec 8 23:40:31 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Fri, 8 Dec 2017 15:40:31 -0800 Subject: [10] Review request: 8137114: native launcher not finding cfg-file Message-ID: <779558fd-b986-69c7-9731-1ac74703cdc0@oracle.com> Kevin, Please review the changes about fixing GenericPlatform::GetAppName(). JIRA: https://bugs.openjdk.java.net/browse/JDK-8137114 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8137114/webrev.00/ --Victor From nlisker at gmail.com Sat Dec 9 06:29:52 2017 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 9 Dec 2017 08:29:52 +0200 Subject: TabPane bug: removing and adding a tab Message-ID: Looks like there's a bug with TabPane which happens when a tab is removed and quickly added back, before the layout is updated. This causes incorrect positioning of the headers. It was posted on SO: https://stackoverflow.com/ questions/47616221/javafx-tabpane-tabs-dont-update-position/ and apparently happens on 8, but not on 9. Nir From guy.abossolo.foh at scientificware.com Sat Dec 9 13:47:19 2017 From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy) Date: Sat, 09 Dec 2017 14:47:19 +0100 Subject: JDK-8147476 Rendering issues with MathML token elements (Message for Murali Billa) Message-ID: <9f1f2e02d0d0b75c78fde45f644903bc@scientificware.com> Hello, Could you inform me about the resolution of the (JDK-8147476) rendering issues with MathML token elements. I don't understand what means the marker value "for a to-be-determined major release". In oder words, what is the process to determine this major release with the new release plan ? Do I need to post another bug report or are you still working on it ? Best regards. From kevin.rushforth at oracle.com Sat Dec 9 14:10:09 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 09 Dec 2017 06:10:09 -0800 Subject: JDK-8147476 Rendering issues with MathML token elements (Message for Murali Billa) In-Reply-To: <9f1f2e02d0d0b75c78fde45f644903bc@scientificware.com> References: <9f1f2e02d0d0b75c78fde45f644903bc@scientificware.com> Message-ID: <5A2BEEC1.30803@oracle.com> Hi, A fix version of 'tbd_major' means the bug is in our backlog and is not yet targeted for a specific release. There is no need to file another bug report, and doing so will not get it looked at any sooner. Murali can comment as to whether he plans to look at this in the near term or not. If you are interested in seeing that this bug get fixed sooner, then I might suggest that you consider contributing a fix for this bug youself [1]. -- Kevin [1] http://openjdk.java.net/contribute/ Abossolo Foh Guy wrote: > Hello, > > Could you inform me about the resolution of the (JDK-8147476) > rendering issues with MathML token elements. > I don't understand what means the marker value "for a to-be-determined > major release". > In oder words, what is the process to determine this major release > with the new release plan ? > Do I need to post another bug report or are you still working on it ? > > Best regards. > From kevin.rushforth at oracle.com Mon Dec 11 22:02:17 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 11 Dec 2017 14:02:17 -0800 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: References: <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> <59B004BF.2000105@oracle.com> <018f1daa-d154-9d97-88f7-93bc0a376293@oracle.com> <5A038C1E.50607@oracle.com> Message-ID: <5A2F0069.4050908@oracle.com> This looks good to me. Phil will also take a look since he reviewed the Java2D version of the fix. I ran regression tests on all three platforms with no problems. I also ran three different perf tests on Linux, all of which showed the expected improvement. -- Kevin Laurent Bourg?s wrote: > Hi Kevin, > > Here is the updated patch providing MarlinFX-0.8.2 to OpenJFX-10 that > provides an efficient path clipper fixing the bug JDK-8184429: > http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-082-8184429.0/ > > It is up-to-date with jfx-dev / jdk forrest (10) and recent changes > from the Marlin 0.8.2 patch under review (2d). > > Changes: > - (D)MarlinPrismUtils share lots of code from (D)MarlinRenderingEngine > to initialize clipping & Marlin Stroker / Filler pipelines > - It does not include the ClipShapeTest (2d) as it needs rewritting to > use JavaFX API. > > PS: Use the Test class (from jbs bug) to see large performance gains > > Cheers, > Laurent > > 2017-11-08 23:58 UTC+01:00, Kevin Rushforth : > >> And once we are happy with the 2D webrev, it should be pretty >> straight-forward to review it for FX. >> >> -- Kevin >> >> >> Phil Race wrote: >> >>> I think they should be separate webrevs sent to the separate lists and >>> you should start with 2D >>> as I can then run the JDK regression tests on it. I know you can >>> theoretically run the open regression >>> tests too (are you ?) but there are some random scattered closed >>> regression tests that so far >>> as I can see can be open sourced .. that I can run but you can't .. >>> I'll at least run the >>> automated ones. I wouldn't call them anything very focused on testing >>> rasterization but >>> I can at least check off that concern .. >>> >>> And yes, I'll make time to review it. >>> >>> -phil. >>> From philip.race at oracle.com Mon Dec 11 22:41:58 2017 From: philip.race at oracle.com (Phil Race) Date: Mon, 11 Dec 2017 14:41:58 -0800 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: <5A2F0069.4050908@oracle.com> References: <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> <59B004BF.2000105@oracle.com> <018f1daa-d154-9d97-88f7-93bc0a376293@oracle.com> <5A038C1E.50607@oracle.com> <5A2F0069.4050908@oracle.com> Message-ID: The changes are fine with me. -phil. On 12/11/2017 02:02 PM, Kevin Rushforth wrote: > This looks good to me. Phil will also take a look since he reviewed > the Java2D version of the fix. > > I ran regression tests on all three platforms with no problems. I also > ran three different perf tests on Linux, all of which showed the > expected improvement. > > -- Kevin > > > Laurent Bourg?s wrote: >> Hi Kevin, >> >> Here is the updated patch providing MarlinFX-0.8.2 to OpenJFX-10 that >> provides an efficient path clipper fixing the bug JDK-8184429: >> http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-082-8184429.0/ >> >> It is up-to-date with jfx-dev / jdk forrest (10) and recent changes >> from the Marlin 0.8.2 patch under review (2d). >> >> Changes: >> - (D)MarlinPrismUtils share lots of code from (D)MarlinRenderingEngine >> to initialize clipping & Marlin Stroker / Filler pipelines >> - It does not include the ClipShapeTest (2d) as it needs rewritting to >> use JavaFX API. >> >> PS: Use the Test class (from jbs bug) to see large performance gains >> >> Cheers, >> Laurent >> >> 2017-11-08 23:58 UTC+01:00, Kevin Rushforth >> : >>> And once we are happy with the 2D webrev, it should be pretty >>> straight-forward to review it for FX. >>> >>> -- Kevin >>> >>> >>> Phil Race wrote: >>>> I think they should be separate webrevs sent to the separate lists and >>>> you should start with 2D >>>> as I can then run the JDK regression tests on it. I know you can >>>> theoretically run the open regression >>>> tests too (are you ?) but there are some random scattered closed >>>> regression tests that so far >>>> as I can see can be open sourced .. that I can run but you can't .. >>>> I'll at least run the >>>> automated ones. I wouldn't call them anything very focused on testing >>>> rasterization but >>>> I can at least check off that concern .. >>>> >>>> And yes, I'll make time to review it. >>>> >>>> -phil. From kevin.rushforth at oracle.com Tue Dec 12 00:20:08 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 11 Dec 2017 16:20:08 -0800 Subject: CFV: New OpenJFX Committer: Laurent =?ISO-8859-1?Q?Bourg=E8s?= Message-ID: <5A2F20B8.9060007@oracle.com> I hereby nominate Laurent Bourg?s [1] to OpenJFX Committer. Laurent is the author of the Marlin rasterizer, which is used as the default rasterizer for both Java2D and JavaFX. He has contributed 10 changesets [2] to OpenJFX. Votes are due by December 25, 2017. (Given the Christmas holiday in the US, it will be at least one week after that before I publish the results). Only current OpenJFX Committers [3] 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 [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] http://openjdk.java.net/census#lbourges [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?rev=author%28lbourges%29 [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer From kevin.rushforth at oracle.com Tue Dec 12 00:38:22 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 11 Dec 2017 16:38:22 -0800 Subject: CFV: New OpenJFX Committer: Laurent =?ISO-8859-1?Q?Bourg=E8s?= In-Reply-To: <5A2F20B8.9060007@oracle.com> References: <5A2F20B8.9060007@oracle.com> Message-ID: <5A2F24FE.3090206@oracle.com> Vote: YES Kevin Rushforth wrote: > I hereby nominate Laurent Bourg?s [1] to OpenJFX Committer. > > Laurent is the author of the Marlin rasterizer, which is used as the > default rasterizer for both Java2D and JavaFX. He has contributed 10 > changesets [2] to OpenJFX. > > Votes are due by December 25, 2017. > (Given the Christmas holiday in the US, it will be at least one week > after that before I publish the results). > > Only current OpenJFX Committers [3] 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 [4]. Nomination to a > project Committer is described in [5]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#lbourges > > [2] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?rev=author%28lbourges%29 > > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From philip.race at oracle.com Tue Dec 12 02:02:06 2017 From: philip.race at oracle.com (Philip Race) Date: Mon, 11 Dec 2017 18:02:06 -0800 Subject: CFV: New OpenJFX Committer: Laurent =?ISO-8859-1?Q?Bourg=E8s?= In-Reply-To: <5A2F20B8.9060007@oracle.com> References: <5A2F20B8.9060007@oracle.com> Message-ID: <5A2F389E.4060700@oracle.com> Vote: yes -phil. From guru.hb at oracle.com Tue Dec 12 03:31:05 2017 From: guru.hb at oracle.com (Guru) Date: Tue, 12 Dec 2017 09:01:05 +0530 Subject: =?utf-8?Q?Re=3A_CFV=3A_New_OpenJFX_Committer=3A_Laurent_Bourg?= =?utf-8?Q?=C3=A8s?= In-Reply-To: <5A2F20B8.9060007@oracle.com> References: <5A2F20B8.9060007@oracle.com> Message-ID: <66A54800-5D34-4FA9-9F9F-2F8B1CE9B01C@oracle.com> Vote: Yes > On 12-Dec-2017, at 5:50 AM, Kevin Rushforth wrote: > > I hereby nominate Laurent Bourg?s [1] to OpenJFX Committer. > > Laurent is the author of the Marlin rasterizer, which is used as the default rasterizer for both Java2D and JavaFX. He has contributed 10 changesets [2] to OpenJFX. > > Votes are due by December 25, 2017. > (Given the Christmas holiday in the US, it will be at least one week after that before I publish the results). > > Only current OpenJFX Committers [3] 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 [4]. Nomination to a project Committer is described in [5]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#lbourges > > [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?rev=author%28lbourges%29 > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From ajit.ghaisas at oracle.com Tue Dec 12 04:23:02 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Mon, 11 Dec 2017 20:23:02 -0800 (PST) Subject: =?iso-8859-1?B?UkU6IENGVjogTmV3IE9wZW5KRlggQ28=?= =?iso-8859-1?B?bW1pdHRlcjogTGF1cmVudCBCb3VyZ+hz?= In-Reply-To: <5A2F20B8.9060007@oracle.com> References: <5A2F20B8.9060007@oracle.com> Message-ID: <0a38fe7b-727e-4184-a6ad-1a3639a17c09@default> Vote : YES Regards, Ajit -----Original Message----- From: Kevin Rushforth Sent: Tuesday, December 12, 2017 5:50 AM To: Laurent Bourg?s; openjfx-dev at openjdk.java.net Subject: CFV: New OpenJFX Committer: Laurent Bourg?s I hereby nominate Laurent Bourg?s [1] to OpenJFX Committer. Laurent is the author of the Marlin rasterizer, which is used as the default rasterizer for both Java2D and JavaFX. He has contributed 10 changesets [2] to OpenJFX. Votes are due by December 25, 2017. (Given the Christmas holiday in the US, it will be at least one week after that before I publish the results). Only current OpenJFX Committers [3] 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 [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] http://openjdk.java.net/census#lbourges [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?rev=author%28lbourges%29 [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer From arunprasad.rajkumar at oracle.com Tue Dec 12 05:51:24 2017 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Tue, 12 Dec 2017 11:21:24 +0530 Subject: =?UTF-8?Q?Re:_CFV:_New_OpenJFX_Committer:_Laurent_Bourg=c3=a8s?= In-Reply-To: <5A2F20B8.9060007@oracle.com> References: <5A2F20B8.9060007@oracle.com> Message-ID: <3e7411bf-58e7-3e6d-00ac-092663c6bf5e@oracle.com> Vote: Yes On 12/12/2017 5:50 AM, Kevin Rushforth wrote: > I hereby nominate Laurent Bourg?s [1] to OpenJFX Committer. > > Laurent is the author of the Marlin rasterizer, which is used as the > default rasterizer for both Java2D and JavaFX. He has contributed 10 > changesets [2] to OpenJFX. > > Votes are due by December 25, 2017. > (Given the Christmas holiday in the US, it will be at least one week > after that before I publish the results). > > Only current OpenJFX Committers [3] 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 [4]. Nomination to a > project Committer is described in [5]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#lbourges > > [2] > http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?rev=author%28lbourges%29 > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From murali.billa at oracle.com Tue Dec 12 06:10:40 2017 From: murali.billa at oracle.com (Murali Billa) Date: Mon, 11 Dec 2017 22:10:40 -0800 (PST) Subject: [8u-Backport] Review request: 8187483: Update to 605.1 version of WebKit Message-ID: <62eb753d-bfd9-4a45-94d4-d1778dcdcec0@default> Hi All, Please review the following patch to merge the GTK WebKit 2.18 into FX 8u : http://cr.openjdk.java.net/~mbilla/8187483/8u-dev-bp/webrev.01/ Above link has one webrev and one changeset file: 1. rt-non-webkit ? Contains changes other than "modules/web/src/main/native", it will be useful only for review. 2. rt.changeset.gz ? Actual changeset file in compressed format which contains all the changes from ?rt? directory, uncompress before using it(gunzip rt.changeset.gz) and do the following steps. $ cd rt $ hg import --no-commit rt.changeset #(from rt.changset.gz) Thanks, Murali From ank.cpp at gmail.com Tue Dec 12 12:47:08 2017 From: ank.cpp at gmail.com (ankit srivastav) Date: Tue, 12 Dec 2017 18:17:08 +0530 Subject: =?UTF-8?Q?RE=3A_CFV=3A_New_OpenJFX_Committer=3A_Laurent_Bourg=C3=A8s?= In-Reply-To: References: <5A2F20B8.9060007@oracle.com> <0a38fe7b-727e-4184-a6ad-1a3639a17c09@default> Message-ID: Vote: Yes --Ankit On 12 Dec 2017 11:28 a.m., "Ajit Ghaisas" wrote: Vote : YES Regards, Ajit -----Original Message----- From: Kevin Rushforth Sent: Tuesday, December 12, 2017 5:50 AM To: Laurent Bourg?s; openjfx-dev at openjdk.java.net Subject: CFV: New OpenJFX Committer: Laurent Bourg?s I hereby nominate Laurent Bourg?s [1] to OpenJFX Committer. Laurent is the author of the Marlin rasterizer, which is used as the default rasterizer for both Java2D and JavaFX. He has contributed 10 changesets [2] to OpenJFX. Votes are due by December 25, 2017. (Given the Christmas holiday in the US, it will be at least one week after that before I publish the results). Only current OpenJFX Committers [3] 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 [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] http://openjdk.java.net/census#lbourges [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?rev=author%28lbourges%29 [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer From johnvalrose at gmail.com Wed Dec 13 02:28:43 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Wed, 13 Dec 2017 13:28:43 +1100 Subject: Innovation again (was Re: Text classes) In-Reply-To: <2FA8027D-79B1-4339-8BCA-6B5CB58D37E5@gmail.com> References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> <5A2777E2.7050106@oracle.com> <5A278521.8050202@oracle.com> <2FA8027D-79B1-4339-8BCA-6B5CB58D37E5@gmail.com> Message-ID: I posted this over a week ago: > I am willing to work with *anyone* (within Oracle or not) on the features that the community craves, > such as those I listed (and any others). Not just because ?many hands make light work? but because > I don?t know everything (or even close) and I need the knowledge and skills of others to assist me. Not > to mention that I have only 24 hours in a day like everyone else and, also like everyone else, some of > that time has to be devoted to earning an income. > > So, if there?s anyone reading this who has the time, the skills, the commitment and the passion to work hard (in your own time) to get these tasks done then please contact me privately. To my significant disappointment, only one person has contacted me since then in relation to this proposal. I'm beginning to think that I am completely out of touch with the JavaFX community, what they actually want and also with exactly *what* JavaFX is or is meant to be. I have reached out on this list and via Twitter in the hope that an inspired and passionate group of developers could come together, pool their resources and collaborate on taking JavaFX as far is it can possibly go as a fully-fledged hardware-accelerated graphics toolkit for the JVM. But... it seem that my "vision" for JavaFX is unique to me and I have to say that I really don't understand why that is. Is it that the JavaFX community see it as merely a Swing replacement or "upgrade" and that there just aren't people out there who want to do more sophisticated things with a Java-based toolkit or at least see performance increase dramatically? Or, do people feel that the kind of features you can find in say Qt cannot be added to JavaFX because it's a "Java thing": well all know how slow Java is and that if you want to do real animations, visualisations etc. then you have to use C++? Well, it's not the 1990s anymore. Java is NOT the problem. So, what IS the problem? I have to say that as chief architect for my company, if the JavaFX community (and I include Oracle as a big part of that) simply don't want to see innovation in JavaFX, won't support or contribute to making it happen or feel they don't need it, causing JavaFX to lag further and further behind other graphic toolkits and never be capable of supporting such features as advanced animations, visualisations, games, 3D, VR, AR and have proper HTML5 support etc. then, despite being a huge Java fan and advocate, JavaFX simply can't even be on the table of technologies to choose from when I'm developing a technological strategy. So, I'd like to ask this multi-part question in the hope that as many people reply as possible: *** For *your* siutation, what is JavaFX, how do you want it to evolve and what does it mean to you? *** Maybe I really am "Robinson Crusoe"... ?? Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology On 6 December 2017 at 17:16, John-Val Rose wrote: > Absolutely - there needs to be a viable community that is not just Oracle. > > So, is there one? If not, how do we build one? > > OK, so let me rephrase my earlier email: > > I am willing to work with *anyone* (within Oracle or not) on the features > that the community craves, such as those I listed (and any others). Not > just because ?many hands make light work? but because I don?t know > everything (or even close) and I need the knowledge and skills of others to > assist me. Not to mention that I have only 24 hours in a day like everyone > else and, also like everyone else, some of that time has to be devoted to > earning an income. > > So, if there?s anyone reading this who has the time, the skills, the > commitment and the passion to work hard (in your own time) to get these > tasks done then please contact me privately. > > > On 6 Dec 2017, at 16:50, Philip Race wrote: > > > > There needs to be a viable community that is not just Oracle to support > you here .. > > I think everyone has come to be dependent on Oracle to "be there". > > But if there is a specific community need that Oracle doesn't see as > essential, then the community should help out. > > > > -phil. > > > >> On 12/5/17, 9:27 PM, John-Val Rose wrote: > >> Well, that?s all fine but you didn?t address the issue of working with > someone within Oracle to get these innovations done. > >> > >> Sure, I could just toil away by myself but clearly it would be better > all around if there was someone with much more extensive knowledge of > JavaFX and its internals who was accessible when required. > >> > >> I would assume that a member of the Oracle JavaFX team would be such a > person. If not, then who? > >> > >>> On 6 Dec 2017, at 15:53, Philip Race wrote: > >>> > >>> I think looking at it as an Oracle-owned and controlled project maybe > the first mistake here. > >>> Yes it was closed source and then Oracle controlled, but not any more, > OCA requirements aside. > >>> It is not even a "java specification". It can be evolved at an API > level without a JSR. > >>> The JEP process is the main thing to be followed, although we also use > CSRs too to track API. > >>> Consider it that anyone who is a contributor owns (not the right word > ?) a piece of it too. > >>> So standing on the project is what matters. Not the company who pays > you to work on it. > >>> > >>> -phil. > >>> > >>>> On 12/5/17, 8:21 PM, John-Val Rose wrote: > >>>> Phil et. al., > >>>> > >>>> Whilst I?m not going to be quite as ?passionate? as some on this > issue (although I do understand the frustration), I would like to point out > again that this is indeed a huge gap and it is critical that it is filled > ASAP. > >>>> > >>>> Obviously a solution where every word in a text document is a Node > would be unworkable so it would need to be architected from the ground up. > >>>> > >>>> I would be happy to work on such as feature, just as I was happy to > work on implementing WebGL, but my hesitation is concern over the > assistance and involvement from Oracle. > >>>> > >>>> If I am going to have to spend months working on something without > any or only minimal involvement from Oracle, only to find at the end that > Oracle either doesn?t like the design, implementation or something else > then it is wasted time I?ll never get back. > >>>> > >>>> There are lots of other innovations too that I would like to see in > JavaFX but I just don?t ?feel the enthusiasm? from Oracle. > >>>> > >>>> If there is someone on the JavaFX team who would be willing to work > with me (at least in some capacity), please have them contact me privately > via email. > >>>> > >>>> The innovations I could work on and contribute include: > >>>> > >>>> 1. WebGL support in WebView > >>>> 2. Better text support including text documents& rich text editors > etc. > >>>> 3. Significant improvements in scene graph rendering speed using > modern game-engine style structures and algorithms > >>>> > >>>> JavaFX cannot survive without innovation and I am keen to see it > happen and contribute as much as possible. > >>>> > >>>> Graciously, > >>>> > >>>> John-Val Rose > >>>> Rosethorn Technology > >>>> > >>>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: > >>>>> > >>>>> Sorry about all the typos previously. > >>>>> > >>>>> Question- why not use the code in awt ? I am not totally up on > what's going on with the platforms' native rendering engines ( meaning, I > have no idea whatsoever) or how they have changed, but golly it sure does > still work pretty well. > >>>>> > >>>>> At least it seems to me looking at awt that a smallish number of > things are 1) well defined by the native platofrm and 2) would more or less > translate directly to an Java API and 3) from those small number of > building blocks, (Font and Glyph metrics and this kind of thing) text > line layout algorithms can be written by ordinary civilians along with all > the other stuff that goes into a text editor. > >>>>> > >>>>> And yes, everything does look easy when someone else is going to do > it. > >>>>> > >>>>> > From victor.drozdov at oracle.com Wed Dec 13 02:24:44 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Tue, 12 Dec 2017 18:24:44 -0800 Subject: [10] Review request: 8191176: JavaFX Self-Contained Application fails with error "Failed to find library: jvm.dll" Message-ID: <97dd7673-09d7-7a31-7ca2-6263ba835778@oracle.com> Kevin, Please review the changes about fixing the error "Failed to find library: jvm.dll" JIRA: https://bugs.openjdk.java.net/browse/JDK-8191176 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8191176/webrev.00/ --Victor From jonathan at jonathangiles.net Wed Dec 13 02:50:39 2017 From: jonathan at jonathangiles.net (Jonathan Giles) Date: Wed, 13 Dec 2017 15:50:39 +1300 Subject: New OpenJFX Committer: Laurent =?UTF-8?B?Qm91cmfDqHM=?= In-Reply-To: <5A2F20B8.9060007@oracle.com> References: <5A2F20B8.9060007@oracle.com> Message-ID: <0325E237-F8A9-4FAE-B366-DE4D17A5B74C@jonathangiles.net> Vote: yes -- Jonathan ?On 12/12/17, 1:25 PM, "openjfx-dev on behalf of Kevin Rushforth" wrote: I hereby nominate Laurent Bourg?s [1] to OpenJFX Committer. Laurent is the author of the Marlin rasterizer, which is used as the default rasterizer for both Java2D and JavaFX. He has contributed 10 changesets [2] to OpenJFX. Votes are due by December 25, 2017. (Given the Christmas holiday in the US, it will be at least one week after that before I publish the results). Only current OpenJFX Committers [3] 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 [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] http://openjdk.java.net/census#lbourges [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?rev=author%28lbourges%29 [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer From murali.billa at oracle.com Wed Dec 13 08:49:16 2017 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 13 Dec 2017 00:49:16 -0800 (PST) Subject: =?utf-8?B?UkU6IE5ldyBPcGVuSkZYIENvbW1pdHRlcjogTGF1cmVudCBCb3VyZ8Oocw==?= In-Reply-To: <0325E237-F8A9-4FAE-B366-DE4D17A5B74C@jonathangiles.net> References: <5A2F20B8.9060007@oracle.com> <0325E237-F8A9-4FAE-B366-DE4D17A5B74C@jonathangiles.net> Message-ID: <0bd3e813-c2c8-4b9f-99ca-8380a0d4bbb0@default> Vote: yes Thanks, Murali ?On 12/12/17, 1:25 PM, "openjfx-dev on behalf of Kevin Rushforth" wrote: I hereby nominate Laurent Bourg?s [1] to OpenJFX Committer. Laurent is the author of the Marlin rasterizer, which is used as the default rasterizer for both Java2D and JavaFX. He has contributed 10 changesets [2] to OpenJFX. Votes are due by December 25, 2017. (Given the Christmas holiday in the US, it will be at least one week after that before I publish the results). Only current OpenJFX Committers [3] 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 [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] http://openjdk.java.net/census#lbourges [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?rev=author%28lbourges%29 [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer From nlisker at gmail.com Wed Dec 13 09:27:02 2017 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 13 Dec 2017 11:27:02 +0200 Subject: openjfx-dev Digest, Vol 73, Issue 20 In-Reply-To: References: Message-ID: John, As as I said in the past I'm all for it. Just didn't see anything going on. My personal preference is in the area of the 3D API. Iv'e already built on top of it for my own use and I (personally) think that some of what Iv'e done could be useful for the API. I also looked into the Prism HLSL code (I'm not a HLSL dev) with the plan of adding more shaders. Not simple. It still looks to me like JEPs are the best option. Currently I'm waiting for the updated instructions for building OpenJFX as I rather spend 1 day later than 4 now. You can contact me privately if you want. Nir On Wed, Dec 13, 2017 at 10:53 AM, wrote: > > Message: 2 > Date: Wed, 13 Dec 2017 13:28:43 +1100 > From: John-Val Rose > To: Philip Race > Cc: "openjfx-dev at openjdk.java.net Mailing" > > Subject: Re: Innovation again (was Re: Text classes) > Message-ID: > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > I posted this over a week ago: > > > I am willing to work with *anyone* (within Oracle or not) on the features > that the community craves, > > such as those I listed (and any others). Not just because ?many hands > make light work? but because > > I don?t know everything (or even close) and I need the knowledge and > skills of others to assist me. Not > > to mention that I have only 24 hours in a day like everyone else and, > also like everyone else, some of > > that time has to be devoted to earning an income. > > > > So, if there?s anyone reading this who has the time, the skills, the > commitment and the passion to work hard (in your own time) to get these > tasks done then please contact me privately. > > To my significant disappointment, only one person has contacted me since > then in relation to this proposal. > > I'm beginning to think that I am completely out of touch with the JavaFX > community, what they actually want and also with exactly *what* JavaFX is > or is meant to be. > > I have reached out on this list and via Twitter in the hope that an > inspired and passionate group of developers could come together, pool their > resources and collaborate on taking JavaFX as far is it can possibly go as > a fully-fledged hardware-accelerated graphics toolkit for the JVM. > > But... it seem that my "vision" for JavaFX is unique to me and I have to > say that I really don't understand why that is. > > Is it that the JavaFX community see it as merely a Swing replacement or > "upgrade" and that there just aren't people out there who want to do more > sophisticated things with a Java-based toolkit or at least see performance > increase dramatically? > > Or, do people feel that the kind of features you can find in say Qt cannot > be added to JavaFX because it's a "Java thing": well all know how slow Java > is and that if you want to do real animations, visualisations etc. then you > have to use C++? > > Well, it's not the 1990s anymore. Java is NOT the problem. > > So, what IS the problem? > > I have to say that as chief architect for my company, if the JavaFX > community (and I include Oracle as a big part of that) simply don't want to > see innovation in JavaFX, won't support or contribute to making it happen > or feel they don't need it, causing JavaFX to lag further and further > behind other graphic toolkits and never be capable of supporting such > features as advanced animations, visualisations, games, 3D, VR, AR and have > proper HTML5 support etc. then, despite being a huge Java fan and advocate, > JavaFX simply can't even be on the table of technologies to choose from > when I'm developing a technological strategy. > > So, I'd like to ask this multi-part question in the hope that as many > people reply as possible: > > *** For *your* siutation, what is JavaFX, how do you want it to evolve and > what does it mean to you? *** > > Maybe I really am "Robinson Crusoe"... > > ?? > Graciously, > > John-Val Rose > Chief Scientist/Architect > Rosethorn Technology > > > On 6 December 2017 at 17:16, John-Val Rose wrote: > > > Absolutely - there needs to be a viable community that is not just > Oracle. > > > > So, is there one? If not, how do we build one? > > > > OK, so let me rephrase my earlier email: > > > > I am willing to work with *anyone* (within Oracle or not) on the features > > that the community craves, such as those I listed (and any others). Not > > just because ?many hands make light work? but because I don?t know > > everything (or even close) and I need the knowledge and skills of others > to > > assist me. Not to mention that I have only 24 hours in a day like > everyone > > else and, also like everyone else, some of that time has to be devoted to > > earning an income. > > > > So, if there?s anyone reading this who has the time, the skills, the > > commitment and the passion to work hard (in your own time) to get these > > tasks done then please contact me privately. > > > > > On 6 Dec 2017, at 16:50, Philip Race wrote: > > > > > > There needs to be a viable community that is not just Oracle to support > > you here .. > > > I think everyone has come to be dependent on Oracle to "be there". > > > But if there is a specific community need that Oracle doesn't see as > > essential, then the community should help out. > > > > > > -phil. > > > > > >> On 12/5/17, 9:27 PM, John-Val Rose wrote: > > >> Well, that?s all fine but you didn?t address the issue of working with > > someone within Oracle to get these innovations done. > > >> > > >> Sure, I could just toil away by myself but clearly it would be better > > all around if there was someone with much more extensive knowledge of > > JavaFX and its internals who was accessible when required. > > >> > > >> I would assume that a member of the Oracle JavaFX team would be such a > > person. If not, then who? > > >> > > >>> On 6 Dec 2017, at 15:53, Philip Race wrote: > > >>> > > >>> I think looking at it as an Oracle-owned and controlled project maybe > > the first mistake here. > > >>> Yes it was closed source and then Oracle controlled, but not any > more, > > OCA requirements aside. > > >>> It is not even a "java specification". It can be evolved at an API > > level without a JSR. > > >>> The JEP process is the main thing to be followed, although we also > use > > CSRs too to track API. > > >>> Consider it that anyone who is a contributor owns (not the right word > > ?) a piece of it too. > > >>> So standing on the project is what matters. Not the company who pays > > you to work on it. > > >>> > > >>> -phil. > > >>> > > >>>> On 12/5/17, 8:21 PM, John-Val Rose wrote: > > >>>> Phil et. al., > > >>>> > > >>>> Whilst I?m not going to be quite as ?passionate? as some on this > > issue (although I do understand the frustration), I would like to point > out > > again that this is indeed a huge gap and it is critical that it is filled > > ASAP. > > >>>> > > >>>> Obviously a solution where every word in a text document is a Node > > would be unworkable so it would need to be architected from the ground > up. > > >>>> > > >>>> I would be happy to work on such as feature, just as I was happy to > > work on implementing WebGL, but my hesitation is concern over the > > assistance and involvement from Oracle. > > >>>> > > >>>> If I am going to have to spend months working on something without > > any or only minimal involvement from Oracle, only to find at the end that > > Oracle either doesn?t like the design, implementation or something else > > then it is wasted time I?ll never get back. > > >>>> > > >>>> There are lots of other innovations too that I would like to see in > > JavaFX but I just don?t ?feel the enthusiasm? from Oracle. > > >>>> > > >>>> If there is someone on the JavaFX team who would be willing to work > > with me (at least in some capacity), please have them contact me > privately > > via email. > > >>>> > > >>>> The innovations I could work on and contribute include: > > >>>> > > >>>> 1. WebGL support in WebView > > >>>> 2. Better text support including text documents& rich text editors > > etc. > > >>>> 3. Significant improvements in scene graph rendering speed using > > modern game-engine style structures and algorithms > > >>>> > > >>>> JavaFX cannot survive without innovation and I am keen to see it > > happen and contribute as much as possible. > > >>>> > > >>>> Graciously, > > >>>> > > >>>> John-Val Rose > > >>>> Rosethorn Technology > > >>>> > > >>>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: > > >>>>> > > >>>>> Sorry about all the typos previously. > > >>>>> > > >>>>> Question- why not use the code in awt ? I am not totally up on > > what's going on with the platforms' native rendering engines ( meaning, I > > have no idea whatsoever) or how they have changed, but golly it sure does > > still work pretty well. > > >>>>> > > >>>>> At least it seems to me looking at awt that a smallish number of > > things are 1) well defined by the native platofrm and 2) would more or > less > > translate directly to an Java API and 3) from those small number of > > building blocks, (Font and Glyph metrics and this kind of thing) text > > line layout algorithms can be written by ordinary civilians along with > all > > the other stuff that goes into a text editor. > > >>>>> > > >>>>> And yes, everything does look easy when someone else is going to do > > it. > > >>>>> > > >>>>> > > > > From ambarish.rapte at oracle.com Wed Dec 13 09:27:31 2017 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Wed, 13 Dec 2017 01:27:31 -0800 (PST) Subject: [10] RFR : 8193426 : [TEST BUG] Exceptions, warnings when running TabPaneDragPolicyTest Message-ID: <50659ce1-0af7-4ad6-be8f-384ce948a9cd@default> Hi Kevin & Ajit, Please review this test bug fix, Issue: https://bugs.openjdk.java.net/browse/JDK-8193426 Webrev: http://cr.openjdk.java.net/~arapte/fx/8193426/webrev.00/ Regards, Ambarish From ajit.ghaisas at oracle.com Wed Dec 13 12:41:43 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 13 Dec 2017 04:41:43 -0800 (PST) Subject: [10] Review request : JDK-8183100 : Styles not applied reliably after Java 8u92 Message-ID: <2a06052b-65c6-4af2-b345-0f558248cdbb@default> Hi Kevin, Request you to review following fix : Issues : https://bugs.openjdk.java.net/browse/JDK-8183100 Fix for JDK 10 : http://cr.openjdk.java.net/~aghaisas/fx/8183100/webrev.1/ This patch reverts the patch of JDK-8151756. This fixes 3 regressions (JDK-8185709, JDK-8183100 and JDK-8168951) caused due to JDK-8151756. Please refer to JBS of JDK-8183100 for more details. Regards, Ajit From murali.billa at oracle.com Wed Dec 13 17:30:42 2017 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 13 Dec 2017 09:30:42 -0800 (PST) Subject: [10] Review request for 8193458: Incorrect cmake platform string for 32-bit Linux Message-ID: <7a63555c-6c82-49fe-96cf-a126c5e15a17@default> ? ? Hi Kevin, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8193458 ? Webrev: http://cr.openjdk.java.net/~mbilla/8193458/webrev.00/ Thanks, Murali From murali.billa at oracle.com Wed Dec 13 19:27:18 2017 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 13 Dec 2017 11:27:18 -0800 (PST) Subject: [8u] Review request for 8193450: Port changes to java and native files from JDK-8192806 to FX 8u Message-ID: <973d90a9-2ea5-4cae-8380-8e3801ca1f96@default> Hi Kevin, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8193450 Webrev: http://cr.openjdk.java.net/~mbilla/8193450/webrev.00/ Thanks, Murali From kevin.rushforth at oracle.com Wed Dec 13 22:27:16 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 13 Dec 2017 14:27:16 -0800 Subject: Reminder: JDK 10 enters Rampdown Phase One in < 18 hours In-Reply-To: <5A297FB7.2090902@oracle.com> References: <5A297FB7.2090902@oracle.com> Message-ID: <5A31A944.1090203@oracle.com> By way of reminder, if there are still any fixes that anyone wants to get in to FX for JDK 10, you have until tomorrow at 16:00 UTC (8am Pacific). Please allow sufficient time for it to be reviewed. Anything pushed after that time will be for JDK 11 by default. Any exceptions will need to follow the Rampdown Phase One process. Details are still pending, but basically it will be similar to JDK 9 rampdown. We might approve P1-P3 bugs (and not all such bugs will be approved) , as well as some (not all) P4 test bugs and doc bugs. Other P4-P5 bugs and all RFEs can wait for JDK 11. -- Kevin On 12/7/2017 9:51 AM, Kevin Rushforth wrote: > We will follow the same deadline for JavaFX: Changes for JDK 10 are > due into jfx-dev/rt by 16:00 UTC (which is 8:00 am Pacific) on > Thursday, Dec 14. > > -- Kevin > > > ------------------------------------------------------------------------ > > Subject: > JDK 10 enters Rampdown Phase One in one week > From: > mark.reinhold at oracle.com > Date: > Thu, 7 Dec 2017 07:58:44 -0800 (PST) > To: > jdk-dev at openjdk.java.net > > To: > jdk-dev at openjdk.java.net > > > JDK 10 will enter Rampdown Phase One in one week, on Thursday, 14 > December. Changes intended for JDK 10 should be in the main-line > repository (http://hg.openjdk.java.net/jdk/jdk), or one of the two > repositories that feed it (jdk/hs or jdk/client), by 16:00 UTC on > that day [1]. > > After next week's build (jdk-10+36) is promoted we'll open a jdk/jdk10 > repository, initialized from that tag in the main line, to host the > remaining stabilization work for JDK 10. This will include any last > changes that trickle in from jdk/hs and jdk/client, most likely early > the following week. Further JDK 10 EA builds will be done from this > repository. > > We'll semi-automatically merge changes pushed to JDK 10 into the > main-line jdk/jdk repository, as we did for the transition from JDK 9 > to JDK 10. This means that: > > - If you make a change in JDK 10 then you needn't do any extra > work to get it into the main line, though if a merge conflict > arises then you might be asked to help resolve it. > > - If you need to make a change in both JDK 10 and the main line > then just push it to JDK 10, and wait for the automatic merge > to complete. > > Changes pushed into the main-line repositories (jdk/{jdk,client,hs}) > after the above deadline will be destined for JDK 11 unless they're > back-ported. When back-ports turn out to be necessary then they'll be > easier to do than in the past: Duplicate bugids are permitted in the > new repository layout, so a change can be pushed to both code lines > using the same bugid if needed. > > The Rampdown Phase One process will be similar to that of JDK 9 [2]. > I'll post a detailed proposal for that shortly. > > - Mark > > > [1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+10+Rampdown+Phase+One&iso=20171214T16 > [2] http://openjdk.java.net/projects/jdk9/rdp-1 > From victor.drozdov at oracle.com Thu Dec 14 03:06:28 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Wed, 13 Dec 2017 19:06:28 -0800 Subject: [10] Review request: 8193353: javapackager is totally broken in "-createbss" mode Message-ID: <55ee2dd9-9c7c-aa11-5ccf-249b662fa931@oracle.com> Kevin, Please review the changes about removing old code related with jfxrt.jar JIRA: https://bugs.openjdk.java.net/browse/JDK-8193353 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8193353/webrev.00/ --Victor From kevin.rushforth at oracle.com Thu Dec 14 16:07:51 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Dec 2017 08:07:51 -0800 Subject: [Fwd: jdk/jdk open for JDK *11* changes] Message-ID: <5A32A1D7.8040304@oracle.com> This applies to JavaFX as well. Starting now, jfx-dev is open for JDK 11 changes. Changes can be requested for backport to JDK 10 according to the guidelines set forth by Mark Reinhold, but otherwise will be in JDK 11. -- Kevin -------------- next part -------------- An embedded message was scrubbed... From: mark.reinhold at oracle.com Subject: jdk/jdk open for JDK *11* changes Date: Thu, 14 Dec 2017 08:00:45 -0800 (PST) Size: 4512 URL: From kevin.rushforth at oracle.com Thu Dec 14 16:12:18 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 14 Dec 2017 08:12:18 -0800 Subject: [10] Review request: 8191448: Update copyright header for files modified in 2017 Message-ID: <5A32A2E2.9020500@oracle.com> Now that we have hit RDP1 and expect relative few changes for 10, I have one more change to update the Copyright year to 2017 for files modified this year. Here is the JBS bug and webrev for this: https://bugs.openjdk.java.net/browse/JDK-8191448 http://cr.openjdk.java.net/~kcr/8191448/webrev/ -- Kevin From cnewland at chrisnewland.com Fri Dec 15 07:26:28 2017 From: cnewland at chrisnewland.com (Chris Newland) Date: Fri, 15 Dec 2017 07:26:28 -0000 Subject: Innovation again (was Re: Text classes) Message-ID: <5895e0d9a099e85fcb1bffa7a9e94059.squirrel@excalibur.xssl.net> Hi John, Here's my $0.02 on JavaFX as someone who's used it for over 4 years in the JITWatch project (https://github.com/AdoptOpenJDK/jitwatch) and also for fun with my DemoFX benchmarks (https://github.com/chriswhocodes/DemoFX). On the whole I think the API is very good. Event handling, layout, choice of components give me 99% of what I need. The CSS approach to styling feels a bit clunky when I want to change fine-grained appearance programatically without defining new CSS classes. Proper font metrics would be nice too (already discussed recently). The Canvas/GraphicsContext API provides a decent entry point into "old school" 2D programming and a way to avoid the scenegraph which does suffer with scale when you push it too hard. You can do fun things with PixelReader/Writer. Personally I'd like an even lower level API to framebuffers as the current implementation looks a bit copy-heavy (my opinion from just the source code, I've not had time to see how much the JIT saves us here). I'd really like the video frame grabber API for MediaPlayer (deprecated after 8) added back but I'm probably alone here. I can always go off-heap here or just implement a video decoder in pure Java. For 3D I think a component that provides a surface usable by an existing OpenGL library is probably better than trying to replicate in pure OpenJFX but this isn't really my area. I was disappointed when Oracle decided to drop support for ARM / IoT but that's no reflection on the JavaFX team, just a commercial decision by a cloud-focused company. I've tried to keep IoT support going via community builds of JavaFX 8 at https://www.chriswhocodes.com but I never really cracked getting Windows builds working. I'm hoping to find some time next year to work with the AdoptOpenJDK group (CC'd) and Laurent Borges (Marlin/MarlinFX) to improve early access testing and cross-platform support of OpenJFX builds. This got a lot harder since the modular JDK9 where you can no longer simply modify OpenJFX, rebuild, and drop an overlay onto your JRE. There are a few companies doing great work (Canoo, Gluon etc.) and a long list of community individuals (Gerrit, Carl, Sean, Almas, Johan, Alessio, Sven, Andres, Dirk, Dierk, Michael, Jens, Jose, ... actually the more I think about it the longer this list gets) who showcase what is possible. The Gluon mobile stuff looks really interesting and I've just started trying to rewrite an iOS native app into a cross-platform app using their Eclipse plugin. In summary I'm very happy with JavaFX and I think the community, while small, contains a lot of talent and energy. The "official" OpenJFX devs are responsive to the community while being realistic about what can be achieved outside their sanctioned roadmap. If there's 1 single thing I'd like to ask for it's an updated set of build instructions for each platform. That's the biggest barrier to getting more community patches submitted in my opinion. Just the $0.02 of one JavaFX user ;) Cheers, Chris -- @chriswhocodes On Wed, December 13, 2017 02:28, John-Val Rose wrote: > I posted this over a week ago: > > >> I am willing to work with *anyone* (within Oracle or not) on the >> features > that the community craves, >> such as those I listed (and any others). Not just because ?many hands > make light work? but because >> I don?t know everything (or even close) and I need the knowledge and >> > skills of others to assist me. Not >> to mention that I have only 24 hours in a day like everyone else and, > also like everyone else, some of >> that time has to be devoted to earning an income. >> >> So, if there?s anyone reading this who has the time, the skills, the >> > commitment and the passion to work hard (in your own time) to get these > tasks done then please contact me privately. > > To my significant disappointment, only one person has contacted me since > then in relation to this proposal. > > I'm beginning to think that I am completely out of touch with the JavaFX > community, what they actually want and also with exactly *what* JavaFX is > or is meant to be. > > I have reached out on this list and via Twitter in the hope that an > inspired and passionate group of developers could come together, pool > their resources and collaborate on taking JavaFX as far is it can possibly > go as a fully-fledged hardware-accelerated graphics toolkit for the JVM. > > But... it seem that my "vision" for JavaFX is unique to me and I have to > say that I really don't understand why that is. > > Is it that the JavaFX community see it as merely a Swing replacement or > "upgrade" and that there just aren't people out there who want to do more > sophisticated things with a Java-based toolkit or at least see performance > increase dramatically? > > Or, do people feel that the kind of features you can find in say Qt > cannot be added to JavaFX because it's a "Java thing": well all know how > slow Java is and that if you want to do real animations, visualisations > etc. then you have to use C++? > > Well, it's not the 1990s anymore. Java is NOT the problem. > > > So, what IS the problem? > > > I have to say that as chief architect for my company, if the JavaFX > community (and I include Oracle as a big part of that) simply don't want > to see innovation in JavaFX, won't support or contribute to making it > happen or feel they don't need it, causing JavaFX to lag further and > further behind other graphic toolkits and never be capable of supporting > such features as advanced animations, visualisations, games, 3D, VR, AR > and have proper HTML5 support etc. then, despite being a huge Java fan and > advocate, JavaFX simply can't even be on the table of technologies to > choose from when I'm developing a technological strategy. > > So, I'd like to ask this multi-part question in the hope that as many > people reply as possible: > > *** For *your* siutation, what is JavaFX, how do you want it to evolve > and what does it mean to you? *** > > Maybe I really am "Robinson Crusoe"... > > > ?? > Graciously, > > > John-Val Rose > Chief Scientist/Architect > Rosethorn Technology > > > > On 6 December 2017 at 17:16, John-Val Rose wrote: > > >> Absolutely - there needs to be a viable community that is not just >> Oracle. >> >> >> So, is there one? If not, how do we build one? >> >> >> OK, so let me rephrase my earlier email: >> >> >> I am willing to work with *anyone* (within Oracle or not) on the >> features that the community craves, such as those I listed (and any >> others). Not just because ?many hands make light work? but because I >> don?t know everything (or even close) and I need the knowledge and >> skills of others to assist me. Not to mention that I have only 24 hours >> in a day like everyone else and, also like everyone else, some of that >> time has to be devoted to earning an income. >> >> So, if there?s anyone reading this who has the time, the skills, the >> commitment and the passion to work hard (in your own time) to get these >> tasks done then please contact me privately. >> >>> On 6 Dec 2017, at 16:50, Philip Race wrote: >>> >>> >>> There needs to be a viable community that is not just Oracle to >>> support >> you here .. >>> I think everyone has come to be dependent on Oracle to "be there". >>> But if there is a specific community need that Oracle doesn't see as >>> >> essential, then the community should help out. >>> >>> -phil. >>> >>> >>>> On 12/5/17, 9:27 PM, John-Val Rose wrote: >>>> Well, that?s all fine but you didn?t address the issue of working >>>> with >> someone within Oracle to get these innovations done. >>>> >>>> Sure, I could just toil away by myself but clearly it would be >>>> better >> all around if there was someone with much more extensive knowledge of >> JavaFX and its internals who was accessible when required. >> >>>> >>>> I would assume that a member of the Oracle JavaFX team would be >>>> such a >> person. If not, then who? >>>> >>>>> On 6 Dec 2017, at 15:53, Philip Race >>>>> wrote: >>>>> >>>>> >>>>> I think looking at it as an Oracle-owned and controlled project >>>>> maybe >> the first mistake here. >>>>> Yes it was closed source and then Oracle controlled, but not any >>>>> more, >> OCA requirements aside. >> >>>>> It is not even a "java specification". It can be evolved at an >>>>> API >>>>> >> level without a JSR. >>>>> The JEP process is the main thing to be followed, although we >>>>> also use >> CSRs too to track API. >> >>>>> Consider it that anyone who is a contributor owns (not the right >>>>> word >> ?) a piece of it too. >> >>>>> So standing on the project is what matters. Not the company who >>>>> pays >> you to work on it. >>>>> >>>>> -phil. >>>>> >>>>> >>>>>> On 12/5/17, 8:21 PM, John-Val Rose wrote: >>>>>> Phil et. al., >>>>>> >>>>>> >>>>>> Whilst I?m not going to be quite as ?passionate? as some on >>>>>> this >> issue (although I do understand the frustration), I would like to point >> out again that this is indeed a huge gap and it is critical that it is >> filled ASAP. >> >>>>>> >>>>>> Obviously a solution where every word in a text document is a >>>>>> Node >>>>>> >> would be unworkable so it would need to be architected from the ground >> up. >>>>>> >>>>>> I would be happy to work on such as feature, just as I was >>>>>> happy to >> work on implementing WebGL, but my hesitation is concern over the >> assistance and involvement from Oracle. >>>>>> >>>>>> If I am going to have to spend months working on something >>>>>> without >> any or only minimal involvement from Oracle, only to find at the end >> that Oracle either doesn?t like the design, implementation or something >> else then it is wasted time I?ll never get back. >>>>>> >>>>>> There are lots of other innovations too that I would like to >>>>>> see in >> JavaFX but I just don?t ?feel the enthusiasm? from Oracle. >> >>>>>> >>>>>> If there is someone on the JavaFX team who would be willing to >>>>>> work >> with me (at least in some capacity), please have them contact me >> privately via email. >>>>>> >>>>>> The innovations I could work on and contribute include: >>>>>> >>>>>> >>>>>> 1. WebGL support in WebView >>>>>> 2. Better text support including text documents& rich text >>>>>> editors >> etc. >>>>>> 3. Significant improvements in scene graph rendering speed >>>>>> using >> modern game-engine style structures and algorithms >>>>>> >>>>>> JavaFX cannot survive without innovation and I am keen to see >>>>>> it >> happen and contribute as much as possible. >>>>>> >>>>>> Graciously, >>>>>> >>>>>> >>>>>> John-Val Rose >>>>>> Rosethorn Technology >>>>>> >>>>>> >>>>>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: >>>>>>> >>>>>>> >>>>>>> Sorry about all the typos previously. >>>>>>> >>>>>>> >>>>>>> Question- why not use the code in awt ? I am not totally up >>>>>>> on >> what's going on with the platforms' native rendering engines ( meaning, >> I >> have no idea whatsoever) or how they have changed, but golly it sure >> does still work pretty well. >>>>>>> >>>>>>> At least it seems to me looking at awt that a smallish number >>>>>>> of >> things are 1) well defined by the native platofrm and 2) would more or >> less translate directly to an Java API and 3) from those small number of >> building blocks, (Font and Glyph metrics and this kind of thing) >> text line layout algorithms can be written by ordinary civilians along >> with all the other stuff that goes into a text editor. >>>>>>> >>>>>>> And yes, everything does look easy when someone else is going >>>>>>> to do >> it. >>>>>>> >>>>>>> >> > From johnvalrose at gmail.com Fri Dec 15 09:09:29 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Fri, 15 Dec 2017 20:09:29 +1100 Subject: Innovation again (was Re: Text classes) In-Reply-To: <5895e0d9a099e85fcb1bffa7a9e94059.squirrel@excalibur.xssl.net> References: <5895e0d9a099e85fcb1bffa7a9e94059.squirrel@excalibur.xssl.net> Message-ID: Thanks for that extensive and very insightful response Chris. Let me make something very clear, just in case people have the wrong idea: I am not here to complain, stir-up trouble or to criticise anyone. In fact, I greatly admire the JavaFX team at Oracle and what they are managing to achieve within what seem like some fairly tight constraints. The entire Java team at Oracle includes some absolute legends and true rock stars and the JavaFX team is no exception. I just wish they had a bigger budget and a bigger team... but fortunately, as Chris says, there is a vibrant and surprisingly large community and OpenJFX is open-source. My "frustration" is that I have a lofty vision of what JavaFX *could* be and what I really want it to be but can also see that it's not there and seemingly not heading there with any great momentum. I keep getting back to "innovation" and the apparent lack of innovation happening with OpenJFX. Since JavaFX 2, other than the inclusion of some basic 3D features, I just don't see any major new enhancements and don't see any discussions or proposals for major new features. Then there's the absence of a product roadmap which suggests to me that the Oracle team is basically keeping the ship afloat in a very light breeze with a broken rudder. But again, I am *not* blaming the team themselves. I am sure they are just as frustrated as I am (and probably even more). So, the question I ask myself is how do we enable this innovation to happen within the prevailing parameters. Clearly, it will require a lot of effort from a lot of people and the cooperation of Oracle. This effort would have a much better chance of being successful if it was to be coordinated in at least a semi-formal manner. This leads to me the idea of offering to be the coordinator (not the "boss", "leader" or "head honcho") of such a team and act as both a facilitator and contributor. I am happy now that several people have contacted me privately in relation to this and I respect their desire to remain out of the spotlight. The available talent pool in the community is absolutely amazing so I am hoping as many of these true superstars can join this initiative and, together with Oracle, we can steer JavaFX forwards and add a powerful motor to power the ship. (I'm not sure why I'm using so many nautical metaphors!). This initiative/team/group should not be "hidden" either - it should be completely transparent and open to enable anyone to follow the thought processes, the progress and the results and also to comment, constructively criticise, make suggestions and even make small contributions. This team is not operating in competition with Oracle - quite the opposite in fact. It's there to complement the already great efforts of the Oracle JavaFX team. I am familiar with "The Java EE Guardians" and while I am not proposing that we do something with exactly the same model, their results speak for themselves. I am open to suggestions and ideas about how such a group/team should be structured and the governance and actually hope that as many people as possible chime-in with their own "2 cents". I'm just offering to be the central contact point for now and then the consensus can determine how we proceed. Another thing which is becoming clear to me is that almost everyone has some quite different ideas of what JavaFX should be or what they would like to see included in the toolkit. This is actually a good thing as it highlights the potential for JavaFX but clearly not every idea can be implemented. But at least there are some key common issues and wishes that we can probably tackle first. Yes, Chris is absolutely spot-on about the build issues. For the broader community to be able to contribute or be motivated to contribute, the process must be as simple as possible and first-things-first, we have to be able to reliably build OpenJFX on all supported platforms. No developer wants to waste time with build issues; they just want to code. I would suggest that this is something Oracle prioritise ahead of perhaps everything else with OpenJFX 9/10 (and that anyone who has advanced knowledge of the tools or the DevOps pipeline try to help as well). As you can see, Chris has basically given us his feature/fix "wish list" and I have received the wish lists of many others and, of course, I have my own. One thing that I have often referred to is the *competitors* of JavaFX (like Qt and Xamarin) and how we are lagging behind them and that the "gap" is growing. But one could argue that from another perspective, JavaFX is actually itself its only real competitor being the official Java GUI toolkit (having supplanted Swing). I like this idea because we all know there are about 11 million Java developers in the world and I am sure most agree that Java (or the JVM) should have a first-class graphics toolkit so all of us who love Java and who eat, breathe & live Java don't have to "turn to the dark side" and learn or relearn languages like C++ or (dare I say it) C# (aka "Microsoft Java"). We can observe what is happening with other toolkits and also keep our fingers on the pulse of graphics toolkit technology directions/advancements in general and use these as inspirations for how we decide to enhance JavaFX. I think I was probably wrong or at least misguided to think that we need to try to make JavaFX "a Java version of Qt" for example. Perhaps we just need JavaFX to meet the major requirements of Java GUI developers and be able to use it to produce *modern* commercial applications that look great, work well and hold their own against other products, all the while we are not having to drift away from Java or the JVM. So to summarise (while you are hopefully still awake), I am not suggesting that I try to tell others what to do or what JavaFX should or shouldn't be but rather that I am simply offering to be the central contact who coordinates the ideas, the efforts and the team in general and also to act as a liaison with Oracle or any other company that can be involved. I can also try to set-up any infrastructure required such as a website, a mailing list, Google group, GitHub project etc. If the community feels I am not the best person for this role then that's perfectly OK! I am more than happy to just to burn the midnight oil and contribute in any way I can. After all, this is not about "me" at all - it's all about JavaFX. I strongly suspect that such luminaries as mentioned by Chris (and Chris himself) are light years ahead of me in knowledge and skills with both Java and JavaFX (and they are all my heroes!). Maybe if I can find an eye patch I can be Nick Fury and the others can be The Avengers? (Sorry if you're more of a DC fan). Please feel free to reach out to me at any time to (privately and confidentially) discuss any of these issues, or even better, post on this list. P.S. I'd like to especially praise the efforts and outstanding achievements of Johan Vos and Gluon. All JavaFX developers owe them enormous gratitude. And, they are already doing much of what I am proposing (though mainly in the mobile space). ?? Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology On 15 December 2017 at 18:26, Chris Newland wrote: > Hi John, > > Here's my $0.02 on JavaFX as someone who's used it for over 4 years in the > JITWatch project (https://github.com/AdoptOpenJDK/jitwatch) and also for > fun with my DemoFX benchmarks (https://github.com/chriswhocodes/DemoFX). > > On the whole I think the API is very good. Event handling, layout, choice > of components give me 99% of what I need. > > The CSS approach to styling feels a bit clunky when I want to change > fine-grained appearance programatically without defining new CSS classes. > Proper font metrics would be nice too (already discussed recently). > > The Canvas/GraphicsContext API provides a decent entry point into "old > school" 2D programming and a way to avoid the scenegraph which does suffer > with scale when you push it too hard. You can do fun things with > PixelReader/Writer. > > Personally I'd like an even lower level API to framebuffers as the current > implementation looks a bit copy-heavy (my opinion from just the source > code, I've not had time to see how much the JIT saves us here). I'd really > like the video frame grabber API for MediaPlayer (deprecated after 8) > added back but I'm probably alone here. I can always go off-heap here or > just implement a video decoder in pure Java. > > For 3D I think a component that provides a surface usable by an existing > OpenGL library is probably better than trying to replicate in pure OpenJFX > but this isn't really my area. > > I was disappointed when Oracle decided to drop support for ARM / IoT but > that's no reflection on the JavaFX team, just a commercial decision by a > cloud-focused company. I've tried to keep IoT support going via community > builds of JavaFX 8 at https://www.chriswhocodes.com but I never really > cracked getting Windows builds working. I'm hoping to find some time next > year to work with the AdoptOpenJDK group (CC'd) and Laurent Borges > (Marlin/MarlinFX) to improve early access testing and cross-platform > support of OpenJFX builds. This got a lot harder since the modular JDK9 > where you can no longer simply modify OpenJFX, rebuild, and drop an > overlay onto your JRE. > > There are a few companies doing great work (Canoo, Gluon etc.) and a long > list of community individuals (Gerrit, Carl, Sean, Almas, Johan, Alessio, > Sven, Andres, Dirk, Dierk, Michael, Jens, Jose, ... actually the more I > think about it the longer this list gets) who showcase what is possible. > > The Gluon mobile stuff looks really interesting and I've just started > trying to rewrite an iOS native app into a cross-platform app using their > Eclipse plugin. > > In summary I'm very happy with JavaFX and I think the community, while > small, contains a lot of talent and energy. > > The "official" OpenJFX devs are responsive to the community while being > realistic about what can be achieved outside their sanctioned roadmap. > > If there's 1 single thing I'd like to ask for it's an updated set of build > instructions for each platform. That's the biggest barrier to getting more > community patches submitted in my opinion. > > Just the $0.02 of one JavaFX user ;) > > Cheers, > > Chris > -- > @chriswhocodes > > > > On Wed, December 13, 2017 02:28, John-Val Rose wrote: > > I posted this over a week ago: > > > > > >> I am willing to work with *anyone* (within Oracle or not) on the > >> features > > that the community craves, > >> such as those I listed (and any others). Not just because ?many hands > > make light work? but because > >> I don?t know everything (or even close) and I need the knowledge and > >> > > skills of others to assist me. Not > >> to mention that I have only 24 hours in a day like everyone else and, > > also like everyone else, some of > >> that time has to be devoted to earning an income. > >> > >> So, if there?s anyone reading this who has the time, the skills, the > >> > > commitment and the passion to work hard (in your own time) to get these > > tasks done then please contact me privately. > > > > To my significant disappointment, only one person has contacted me since > > then in relation to this proposal. > > > > I'm beginning to think that I am completely out of touch with the JavaFX > > community, what they actually want and also with exactly *what* JavaFX is > > or is meant to be. > > > > I have reached out on this list and via Twitter in the hope that an > > inspired and passionate group of developers could come together, pool > > their resources and collaborate on taking JavaFX as far is it can > possibly > > go as a fully-fledged hardware-accelerated graphics toolkit for the JVM. > > > > But... it seem that my "vision" for JavaFX is unique to me and I have to > > say that I really don't understand why that is. > > > > Is it that the JavaFX community see it as merely a Swing replacement or > > "upgrade" and that there just aren't people out there who want to do more > > sophisticated things with a Java-based toolkit or at least see > performance > > increase dramatically? > > > > Or, do people feel that the kind of features you can find in say Qt > > cannot be added to JavaFX because it's a "Java thing": well all know how > > slow Java is and that if you want to do real animations, visualisations > > etc. then you have to use C++? > > > > Well, it's not the 1990s anymore. Java is NOT the problem. > > > > > > So, what IS the problem? > > > > > > I have to say that as chief architect for my company, if the JavaFX > > community (and I include Oracle as a big part of that) simply don't want > > to see innovation in JavaFX, won't support or contribute to making it > > happen or feel they don't need it, causing JavaFX to lag further and > > further behind other graphic toolkits and never be capable of supporting > > such features as advanced animations, visualisations, games, 3D, VR, AR > > and have proper HTML5 support etc. then, despite being a huge Java fan > and > > advocate, JavaFX simply can't even be on the table of technologies to > > choose from when I'm developing a technological strategy. > > > > So, I'd like to ask this multi-part question in the hope that as many > > people reply as possible: > > > > *** For *your* siutation, what is JavaFX, how do you want it to evolve > > and what does it mean to you? *** > > > > Maybe I really am "Robinson Crusoe"... > > > > > > ?? > > Graciously, > > > > > > John-Val Rose > > Chief Scientist/Architect > > Rosethorn Technology > > > > > > > > On 6 December 2017 at 17:16, John-Val Rose > wrote: > > > > > >> Absolutely - there needs to be a viable community that is not just > >> Oracle. > >> > >> > >> So, is there one? If not, how do we build one? > >> > >> > >> OK, so let me rephrase my earlier email: > >> > >> > >> I am willing to work with *anyone* (within Oracle or not) on the > >> features that the community craves, such as those I listed (and any > >> others). Not just because ?many hands make light work? but because I > >> don?t know everything (or even close) and I need the knowledge and > >> skills of others to assist me. Not to mention that I have only 24 hours > >> in a day like everyone else and, also like everyone else, some of that > >> time has to be devoted to earning an income. > >> > >> So, if there?s anyone reading this who has the time, the skills, the > >> commitment and the passion to work hard (in your own time) to get these > >> tasks done then please contact me privately. > >> > >>> On 6 Dec 2017, at 16:50, Philip Race wrote: > >>> > >>> > >>> There needs to be a viable community that is not just Oracle to > >>> support > >> you here .. > >>> I think everyone has come to be dependent on Oracle to "be there". > >>> But if there is a specific community need that Oracle doesn't see as > >>> > >> essential, then the community should help out. > >>> > >>> -phil. > >>> > >>> > >>>> On 12/5/17, 9:27 PM, John-Val Rose wrote: > >>>> Well, that?s all fine but you didn?t address the issue of working > >>>> with > >> someone within Oracle to get these innovations done. > >>>> > >>>> Sure, I could just toil away by myself but clearly it would be > >>>> better > >> all around if there was someone with much more extensive knowledge of > >> JavaFX and its internals who was accessible when required. > >> > >>>> > >>>> I would assume that a member of the Oracle JavaFX team would be > >>>> such a > >> person. If not, then who? > >>>> > >>>>> On 6 Dec 2017, at 15:53, Philip Race > >>>>> wrote: > >>>>> > >>>>> > >>>>> I think looking at it as an Oracle-owned and controlled project > >>>>> maybe > >> the first mistake here. > >>>>> Yes it was closed source and then Oracle controlled, but not any > >>>>> more, > >> OCA requirements aside. > >> > >>>>> It is not even a "java specification". It can be evolved at an > >>>>> API > >>>>> > >> level without a JSR. > >>>>> The JEP process is the main thing to be followed, although we > >>>>> also use > >> CSRs too to track API. > >> > >>>>> Consider it that anyone who is a contributor owns (not the right > >>>>> word > >> ?) a piece of it too. > >> > >>>>> So standing on the project is what matters. Not the company who > >>>>> pays > >> you to work on it. > >>>>> > >>>>> -phil. > >>>>> > >>>>> > >>>>>> On 12/5/17, 8:21 PM, John-Val Rose wrote: > >>>>>> Phil et. al., > >>>>>> > >>>>>> > >>>>>> Whilst I?m not going to be quite as ?passionate? as some on > >>>>>> this > >> issue (although I do understand the frustration), I would like to point > >> out again that this is indeed a huge gap and it is critical that it is > >> filled ASAP. > >> > >>>>>> > >>>>>> Obviously a solution where every word in a text document is a > >>>>>> Node > >>>>>> > >> would be unworkable so it would need to be architected from the ground > >> up. > >>>>>> > >>>>>> I would be happy to work on such as feature, just as I was > >>>>>> happy to > >> work on implementing WebGL, but my hesitation is concern over the > >> assistance and involvement from Oracle. > >>>>>> > >>>>>> If I am going to have to spend months working on something > >>>>>> without > >> any or only minimal involvement from Oracle, only to find at the end > >> that Oracle either doesn?t like the design, implementation or something > >> else then it is wasted time I?ll never get back. > >>>>>> > >>>>>> There are lots of other innovations too that I would like to > >>>>>> see in > >> JavaFX but I just don?t ?feel the enthusiasm? from Oracle. > >> > >>>>>> > >>>>>> If there is someone on the JavaFX team who would be willing to > >>>>>> work > >> with me (at least in some capacity), please have them contact me > >> privately via email. > >>>>>> > >>>>>> The innovations I could work on and contribute include: > >>>>>> > >>>>>> > >>>>>> 1. WebGL support in WebView > >>>>>> 2. Better text support including text documents& rich text > >>>>>> editors > >> etc. > >>>>>> 3. Significant improvements in scene graph rendering speed > >>>>>> using > >> modern game-engine style structures and algorithms > >>>>>> > >>>>>> JavaFX cannot survive without innovation and I am keen to see > >>>>>> it > >> happen and contribute as much as possible. > >>>>>> > >>>>>> Graciously, > >>>>>> > >>>>>> > >>>>>> John-Val Rose > >>>>>> Rosethorn Technology > >>>>>> > >>>>>> > >>>>>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: > >>>>>>> > >>>>>>> > >>>>>>> Sorry about all the typos previously. > >>>>>>> > >>>>>>> > >>>>>>> Question- why not use the code in awt ? I am not totally up > >>>>>>> on > >> what's going on with the platforms' native rendering engines ( meaning, > >> I > >> have no idea whatsoever) or how they have changed, but golly it sure > >> does still work pretty well. > >>>>>>> > >>>>>>> At least it seems to me looking at awt that a smallish number > >>>>>>> of > >> things are 1) well defined by the native platofrm and 2) would more or > >> less translate directly to an Java API and 3) from those small number of > >> building blocks, (Font and Glyph metrics and this kind of thing) > >> text line layout algorithms can be written by ordinary civilians along > >> with all the other stuff that goes into a text editor. > >>>>>>> > >>>>>>> And yes, everything does look easy when someone else is going > >>>>>>> to do > >> it. > >>>>>>> > >>>>>>> > >> > > > > > From bourges.laurent at gmail.com Fri Dec 15 10:38:03 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 15 Dec 2017 11:38:03 +0100 Subject: Innovation again (was Re: Text classes) In-Reply-To: References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> <5A2777E2.7050106@oracle.com> <5A278521.8050202@oracle.com> <2FA8027D-79B1-4339-8BCA-6B5CB58D37E5@gmail.com> Message-ID: Dear all, Chris mail motivated me to answer too. *** For *your* situation, what is JavaFX, how do you want it to evolve and what does it mean to you? *** I am developping for 10 years scientific desktop apps with Java Swing (+ Java Web Start). As our users are mostly using linux & macOS, we only require JDK 6 ! (old linux distributions had only openjdk6 by default) Of course we could switch our code base to jdk8 soon as user stats reports that 90% have it. Using JDK8 would let us adopt JavaFX lately ... for its nicer widgets & 3d plots (star models) but we could also use third-party libs for 3d plots (orson charts). My main concern is about the future of Java Client (2d / JFX)... For science, python is the main language so we are outsiders and users complain about Java updates... if JavaFX is no more in the mood, we will not adopt it in future ?? as our service is offered for 10 years min ... Finally I invested a lot of my own time improving the OpenJDK/JFX AA renderers (Marlin) and had the chance to work with Oracle gentle persons on its integration in jdk9/10. My own experience proves that good FOSS & external contributions have their place in the OpenJDK projects. Let's the community get more involved to contribute patches to these projects. The main issue is sustainability: - who will maintain / review patches (only few people) ? - what funding for the community (meeting, conference, travel costs) ? Cheers, Laurent Maybe I really am "Robinson Crusoe"... PS: I feel like the last jedi (coding legacy AA software renderers while others use Gpu) From Jago.Westmacott at fulcrumasset.com Fri Dec 15 11:41:11 2017 From: Jago.Westmacott at fulcrumasset.com (Jago Westmacott) Date: Fri, 15 Dec 2017 11:41:11 +0000 Subject: Innovation again (was Re: Text classes) In-Reply-To: References: <661862520bbcb12145e3f62a982cdea3.startmail@www.startmail.com> <81179fc3a7c9426d76ec56ec63c82885.startmail@www.startmail.com> <0B77B4B6-4765-4B98-B745-E748159AE92E@gmail.com> <5A2777E2.7050106@oracle.com> <5A278521.8050202@oracle.com> <2FA8027D-79B1-4339-8BCA-6B5CB58D37E5@gmail.com> Message-ID: Dear all, Chris' email has similarly motivated me to post for the first time. I work with a small a 6 person team developing a proprietary distributed software platform. The GUI is another 'node' or 'engine' on the graph of interconnected processes. It provides a large number of different views on different sets of data via a docking framework. The majority of our data views consist of custom tables and tree-tables, that allow fast filtering, slicing and dicing, aggregating, etc. of large data sets. Our Gui was originally written in Swing and the performance / responsiveness was excellent. The code was optimised using various well known Swing optimisations - and the end result was supper snappy and a delight to use. About three years ago we migrated to JavaFx. The motivation behind the migration was simply to build a more attractive Gui (particularly improved text rendering and animations), because people do judge a book by its cover. Our original Swing Gui was lightweight (same basic components being reused and minimal business logic) so in theory this would be a relatively painless exercise. The end result was (and still is) a more attractive Gui - but building it was an extremely painful process. We find the basic 2D performance of JavaFx poor. To the extent that we ended up writing our own custom table components using a Canvas as a viewport on the underlying data. While we get adequate performance using our custom components - the general experience in terms of responsiveness, is still a little disappointing when compared to the Swing original. My biggest frustration, I think, has been that the response I have often read when performance concerns have been mentioned, is that performance is fine and JavaFx is built for modern hardware. Apart from not agreeing that the performance is fine - an area where Java still maintains its popularity is in the 'enterprise' - and don't feel that JavaFx caters well for the types of Gui's that are typically found in this space. To get the point after a rambling email, top of my wish-list would be better performance. Or better access to the underlying API, to enable building of lighter weight, optimised 2D components. - Jago -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Laurent Bourg?s Sent: 15 December 2017 10:38 To: John-Val Rose Cc: openjfx-dev at openjdk.java.net Mailing Subject: Re: Innovation again (was Re: Text classes) Dear all, Chris mail motivated me to answer too. *** For *your* situation, what is JavaFX, how do you want it to evolve and what does it mean to you? *** I am developping for 10 years scientific desktop apps with Java Swing (+ Java Web Start). As our users are mostly using linux & macOS, we only require JDK 6 ! (old linux distributions had only openjdk6 by default) Of course we could switch our code base to jdk8 soon as user stats reports that 90% have it. Using JDK8 would let us adopt JavaFX lately ... for its nicer widgets & 3d plots (star models) but we could also use third-party libs for 3d plots (orson charts). My main concern is about the future of Java Client (2d / JFX)... For science, python is the main language so we are outsiders and users complain about Java updates... if JavaFX is no more in the mood, we will not adopt it in future ?? as our service is offered for 10 years min ... Finally I invested a lot of my own time improving the OpenJDK/JFX AA renderers (Marlin) and had the chance to work with Oracle gentle persons on its integration in jdk9/10. My own experience proves that good FOSS & external contributions have their place in the OpenJDK projects. Let's the community get more involved to contribute patches to these projects. The main issue is sustainability: - who will maintain / review patches (only few people) ? - what funding for the community (meeting, conference, travel costs) ? Cheers, Laurent Maybe I really am "Robinson Crusoe"... PS: I feel like the last jedi (coding legacy AA software renderers while others use Gpu) This e-mail and any attachment hereto is confidential and is solely for the intended recipient. If you are neither the intended recipient nor a designated representative of the intended recipient please contact the sender, delete this message from your system immediately, destroy any print-out of it and do not use, copy or disseminate the information in or attached to it in any way. Unless expressly stated, opinions in this email are those of the individual sender and not those of Fulcrum Asset Management LLP. This e-mail and the information contained herein should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial products, including an interest in a fund, or an official confirmation of any transaction. Any such offer or solicitation will be made to qualified investors only by means of an offering memorandum and related subscription agreement. Securities shall not be offered or sold in any jurisdiction in which such offer, solicitation or sale would be unlawful until the requirements of the laws of such jurisdiction have been satisfied. Any performance information contained herein may be unaudited and estimated. Past performance is not indicative of future results. Fulcrum Asset Management LLP does not represent that the contents of this e-mail or any attachment hereto are complete or accurate and they should not be relied upon as such. All information in or attached to this e-mail is subject to change without notice. Fulcrum Asset Management LLP is authorised and regulated by the Financial Conduct Authority of the United Kingdom (No: 230683) and incorporated as a Limited Liability Partnership in England and Wales (No: OC306401) with its registered office at Marble Arch House, 66 Seymour Street, London, W1H 5BT. Fulcrum Asset Management LP is a wholly owned subsidiary of Fulcrum Asset Management LLP incorporated in the State of Delaware, operating from 350 Park Avenue, 13th Floor, New York, NY 10022 USA. From mp at jugs.org Fri Dec 15 13:42:33 2017 From: mp at jugs.org (Michael Paus) Date: Fri, 15 Dec 2017 14:42:33 +0100 Subject: Innovation again (was Re: Text classes) In-Reply-To: References: <5895e0d9a099e85fcb1bffa7a9e94059.squirrel@excalibur.xssl.net> Message-ID: Hi, first of all I would like to say that I fully agree with everything that has been said so far in this thread and I am glad that someone is pushing this long overdue discussion. Please find my comments inline. Am 15.12.17 um 10:09 schrieb John-Val Rose: > [...] > > This initiative/team/group should not be "hidden" either - it should be > completely transparent and open to enable anyone to follow the thought > processes, the progress and the results and also to comment, constructively > criticise, make suggestions and even make small contributions. This team is > not operating in competition with Oracle - quite the opposite in fact. > It's there to complement the already great efforts of the Oracle JavaFX > team. > > I am familiar with "The Java EE Guardians" and while I am not proposing > that we do something with exactly the same model, their results speak for > themselves. I am open to suggestions and ideas about how such a group/team > should be structured and the governance and actually hope that as many > people as possible chime-in with their own "2 cents". > > I'm just offering to be the central contact point for now and then the > consensus can determine how we proceed. A lot has already been discussed on this list and elsewhere but my impression is that all these ideas are forgotten faster than they are written up because there is no place to collect them and no person to organize and administer such a place. If such a place existed I would be more than happy to share my ideas with others. > Yes, Chris is absolutely spot-on about the build issues. For the broader > community to be able to contribute or be motivated to contribute, the > process must be as simple as possible and first-things-first, we have to be > able to reliably build OpenJFX on all supported platforms. No developer > wants to waste time with build issues; they just want to code. I would > suggest that this is something Oracle prioritise ahead of perhaps > everything else with OpenJFX 9/10 (and that anyone who has advanced > knowledge of the tools or the DevOps pipeline try to help as well). Yes, I see this as a big stumbling stone as well. I would like to add that it would also be necessary to advertise the use of such builds and to harmonize the handling of version numbers of such builds. I currently have a lot of problems using my own builds as well as the EA builds from Oracle with the existing build tools and IDEs. Many of them get a hick-up if they encounter build versions beyond the current/official versions. > > As you can see, Chris has basically given us his feature/fix "wish list" > and I have received the wish lists of many others and, of course, I have my > own. > > One thing that I have often referred to is the *competitors* of JavaFX > (like Qt and Xamarin) and how we are lagging behind them and that the "gap" > is growing. But one could argue that from another perspective, JavaFX is > actually itself its only real competitor being the official Java GUI > toolkit (having supplanted Swing). I like this idea because we all know > there are about 11 million Java developers in the world and I am sure most > agree that Java (or the JVM) should have a first-class graphics toolkit so > all of us who love Java and who eat, breathe & live Java don't have to > "turn to the dark side" and learn or relearn languages like C++ or (dare I > say it) C# (aka "Microsoft Java"). > > We can observe what is happening with other toolkits and also keep our > fingers on the pulse of graphics toolkit technology directions/advancements > in general and use these as inspirations for how we decide to enhance > JavaFX. I think I was probably wrong or at least misguided to think that > we need to try to make JavaFX "a Java version of Qt" for example. Perhaps > we just need JavaFX to meet the major requirements of Java GUI developers > and be able to use it to produce *modern* commercial applications that look > great, work well and hold their own against other products, all the while > we are not having to drift away from Java or the JVM. In order for this to become true JavaFX first needs to get some basics right. My keyword here would be: - Platform integration (e.g. Mac menu bar.) - Working packager on all platforms - An automatic update mechanism for applications (not WebStart) > > So to summarise (while you are hopefully still awake), I am not suggesting > that I try to tell others what to do or what JavaFX should or shouldn't be > but rather that I am simply offering to be the central contact who > coordinates the ideas, the efforts and the team in general and also to act > as a liaison with Oracle or any other company that can be involved. I can > also try to set-up any infrastructure required such as a website, a mailing > list, Google group, GitHub project etc. For collecting and structuring of ideas something like GitHub and its Wiki seem to be a better suited than a mailing list (which we already have.). > > If the community feels I am not the best person for this role then that's > perfectly OK! I am more than happy to just to burn the midnight oil and > contribute in any way I can. Go for it. Someone has to make the first step. > > After all, this is not about "me" at all - it's all about JavaFX. I > strongly suspect that such luminaries as mentioned by Chris (and Chris > himself) are light years ahead of me in knowledge and skills with both Java > and JavaFX (and they are all my heroes!). Maybe if I can find an eye patch > I can be Nick Fury and the others can be The Avengers? (Sorry if you're > more of a DC fan). > > Please feel free to reach out to me at any time to (privately and > confidentially) discuss any of these issues, or even better, post on this > list. > > P.S. I'd like to especially praise the efforts and outstanding achievements > of Johan Vos and Gluon. All JavaFX developers owe them enormous gratitude. > And, they are already doing much of what I am proposing (though mainly in > the mobile space). > > ?? > Graciously, > > John-Val Rose > Chief Scientist/Architect > Rosethorn Technology > > > On 15 December 2017 at 18:26, Chris Newland > wrote: > >> Hi John, >> >> Here's my $0.02 on JavaFX as someone who's used it for over 4 years in the >> JITWatch project (https://github.com/AdoptOpenJDK/jitwatch) and also for >> fun with my DemoFX benchmarks (https://github.com/chriswhocodes/DemoFX). >> >> On the whole I think the API is very good. Event handling, layout, choice >> of components give me 99% of what I need. >> >> The CSS approach to styling feels a bit clunky when I want to change >> fine-grained appearance programatically without defining new CSS classes. >> Proper font metrics would be nice too (already discussed recently). >> >> The Canvas/GraphicsContext API provides a decent entry point into "old >> school" 2D programming and a way to avoid the scenegraph which does suffer >> with scale when you push it too hard. You can do fun things with >> PixelReader/Writer. >> >> Personally I'd like an even lower level API to framebuffers as the current >> implementation looks a bit copy-heavy (my opinion from just the source >> code, I've not had time to see how much the JIT saves us here). I'd really >> like the video frame grabber API for MediaPlayer (deprecated after 8) >> added back but I'm probably alone here. I can always go off-heap here or >> just implement a video decoder in pure Java. >> >> For 3D I think a component that provides a surface usable by an existing >> OpenGL library is probably better than trying to replicate in pure OpenJFX >> but this isn't really my area. >> >> I was disappointed when Oracle decided to drop support for ARM / IoT but >> that's no reflection on the JavaFX team, just a commercial decision by a >> cloud-focused company. I've tried to keep IoT support going via community >> builds of JavaFX 8 at https://www.chriswhocodes.com but I never really >> cracked getting Windows builds working. I'm hoping to find some time next >> year to work with the AdoptOpenJDK group (CC'd) and Laurent Borges >> (Marlin/MarlinFX) to improve early access testing and cross-platform >> support of OpenJFX builds. This got a lot harder since the modular JDK9 >> where you can no longer simply modify OpenJFX, rebuild, and drop an >> overlay onto your JRE. >> >> There are a few companies doing great work (Canoo, Gluon etc.) and a long >> list of community individuals (Gerrit, Carl, Sean, Almas, Johan, Alessio, >> Sven, Andres, Dirk, Dierk, Michael, Jens, Jose, ... actually the more I >> think about it the longer this list gets) who showcase what is possible. >> >> The Gluon mobile stuff looks really interesting and I've just started >> trying to rewrite an iOS native app into a cross-platform app using their >> Eclipse plugin. >> >> In summary I'm very happy with JavaFX and I think the community, while >> small, contains a lot of talent and energy. >> >> The "official" OpenJFX devs are responsive to the community while being >> realistic about what can be achieved outside their sanctioned roadmap. >> >> If there's 1 single thing I'd like to ask for it's an updated set of build >> instructions for each platform. That's the biggest barrier to getting more >> community patches submitted in my opinion. >> >> Just the $0.02 of one JavaFX user ;) >> >> Cheers, >> >> Chris >> -- >> @chriswhocodes >> >> >> >> On Wed, December 13, 2017 02:28, John-Val Rose wrote: >>> I posted this over a week ago: >>> >>> >>>> I am willing to work with *anyone* (within Oracle or not) on the >>>> features >>> that the community craves, >>>> such as those I listed (and any others). Not just because ?many hands >>> make light work? but because >>>> I don?t know everything (or even close) and I need the knowledge and >>>> >>> skills of others to assist me. Not >>>> to mention that I have only 24 hours in a day like everyone else and, >>> also like everyone else, some of >>>> that time has to be devoted to earning an income. >>>> >>>> So, if there?s anyone reading this who has the time, the skills, the >>>> >>> commitment and the passion to work hard (in your own time) to get these >>> tasks done then please contact me privately. >>> >>> To my significant disappointment, only one person has contacted me since >>> then in relation to this proposal. >>> >>> I'm beginning to think that I am completely out of touch with the JavaFX >>> community, what they actually want and also with exactly *what* JavaFX is >>> or is meant to be. >>> >>> I have reached out on this list and via Twitter in the hope that an >>> inspired and passionate group of developers could come together, pool >>> their resources and collaborate on taking JavaFX as far is it can >> possibly >>> go as a fully-fledged hardware-accelerated graphics toolkit for the JVM. >>> >>> But... it seem that my "vision" for JavaFX is unique to me and I have to >>> say that I really don't understand why that is. >>> >>> Is it that the JavaFX community see it as merely a Swing replacement or >>> "upgrade" and that there just aren't people out there who want to do more >>> sophisticated things with a Java-based toolkit or at least see >> performance >>> increase dramatically? >>> >>> Or, do people feel that the kind of features you can find in say Qt >>> cannot be added to JavaFX because it's a "Java thing": well all know how >>> slow Java is and that if you want to do real animations, visualisations >>> etc. then you have to use C++? >>> >>> Well, it's not the 1990s anymore. Java is NOT the problem. >>> >>> >>> So, what IS the problem? >>> >>> >>> I have to say that as chief architect for my company, if the JavaFX >>> community (and I include Oracle as a big part of that) simply don't want >>> to see innovation in JavaFX, won't support or contribute to making it >>> happen or feel they don't need it, causing JavaFX to lag further and >>> further behind other graphic toolkits and never be capable of supporting >>> such features as advanced animations, visualisations, games, 3D, VR, AR >>> and have proper HTML5 support etc. then, despite being a huge Java fan >> and >>> advocate, JavaFX simply can't even be on the table of technologies to >>> choose from when I'm developing a technological strategy. >>> >>> So, I'd like to ask this multi-part question in the hope that as many >>> people reply as possible: >>> >>> *** For *your* siutation, what is JavaFX, how do you want it to evolve >>> and what does it mean to you? *** >>> >>> Maybe I really am "Robinson Crusoe"... >>> >>> >>> ?? >>> Graciously, >>> >>> >>> John-Val Rose >>> Chief Scientist/Architect >>> Rosethorn Technology >>> >>> >>> >>> On 6 December 2017 at 17:16, John-Val Rose >> wrote: >>> >>>> Absolutely - there needs to be a viable community that is not just >>>> Oracle. >>>> >>>> >>>> So, is there one? If not, how do we build one? >>>> >>>> >>>> OK, so let me rephrase my earlier email: >>>> >>>> >>>> I am willing to work with *anyone* (within Oracle or not) on the >>>> features that the community craves, such as those I listed (and any >>>> others). Not just because ?many hands make light work? but because I >>>> don?t know everything (or even close) and I need the knowledge and >>>> skills of others to assist me. Not to mention that I have only 24 hours >>>> in a day like everyone else and, also like everyone else, some of that >>>> time has to be devoted to earning an income. >>>> >>>> So, if there?s anyone reading this who has the time, the skills, the >>>> commitment and the passion to work hard (in your own time) to get these >>>> tasks done then please contact me privately. >>>> >>>>> On 6 Dec 2017, at 16:50, Philip Race wrote: >>>>> >>>>> >>>>> There needs to be a viable community that is not just Oracle to >>>>> support >>>> you here .. >>>>> I think everyone has come to be dependent on Oracle to "be there". >>>>> But if there is a specific community need that Oracle doesn't see as >>>>> >>>> essential, then the community should help out. >>>>> -phil. >>>>> >>>>> >>>>>> On 12/5/17, 9:27 PM, John-Val Rose wrote: >>>>>> Well, that?s all fine but you didn?t address the issue of working >>>>>> with >>>> someone within Oracle to get these innovations done. >>>>>> Sure, I could just toil away by myself but clearly it would be >>>>>> better >>>> all around if there was someone with much more extensive knowledge of >>>> JavaFX and its internals who was accessible when required. >>>> >>>>>> I would assume that a member of the Oracle JavaFX team would be >>>>>> such a >>>> person. If not, then who? >>>>>>> On 6 Dec 2017, at 15:53, Philip Race >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> I think looking at it as an Oracle-owned and controlled project >>>>>>> maybe >>>> the first mistake here. >>>>>>> Yes it was closed source and then Oracle controlled, but not any >>>>>>> more, >>>> OCA requirements aside. >>>> >>>>>>> It is not even a "java specification". It can be evolved at an >>>>>>> API >>>>>>> >>>> level without a JSR. >>>>>>> The JEP process is the main thing to be followed, although we >>>>>>> also use >>>> CSRs too to track API. >>>> >>>>>>> Consider it that anyone who is a contributor owns (not the right >>>>>>> word >>>> ?) a piece of it too. >>>> >>>>>>> So standing on the project is what matters. Not the company who >>>>>>> pays >>>> you to work on it. >>>>>>> -phil. >>>>>>> >>>>>>> >>>>>>>> On 12/5/17, 8:21 PM, John-Val Rose wrote: >>>>>>>> Phil et. al., >>>>>>>> >>>>>>>> >>>>>>>> Whilst I?m not going to be quite as ?passionate? as some on >>>>>>>> this >>>> issue (although I do understand the frustration), I would like to point >>>> out again that this is indeed a huge gap and it is critical that it is >>>> filled ASAP. >>>> >>>>>>>> Obviously a solution where every word in a text document is a >>>>>>>> Node >>>>>>>> >>>> would be unworkable so it would need to be architected from the ground >>>> up. >>>>>>>> I would be happy to work on such as feature, just as I was >>>>>>>> happy to >>>> work on implementing WebGL, but my hesitation is concern over the >>>> assistance and involvement from Oracle. >>>>>>>> If I am going to have to spend months working on something >>>>>>>> without >>>> any or only minimal involvement from Oracle, only to find at the end >>>> that Oracle either doesn?t like the design, implementation or something >>>> else then it is wasted time I?ll never get back. >>>>>>>> There are lots of other innovations too that I would like to >>>>>>>> see in >>>> JavaFX but I just don?t ?feel the enthusiasm? from Oracle. >>>> >>>>>>>> If there is someone on the JavaFX team who would be willing to >>>>>>>> work >>>> with me (at least in some capacity), please have them contact me >>>> privately via email. >>>>>>>> The innovations I could work on and contribute include: >>>>>>>> >>>>>>>> >>>>>>>> 1. WebGL support in WebView >>>>>>>> 2. Better text support including text documents& rich text >>>>>>>> editors >>>> etc. >>>>>>>> 3. Significant improvements in scene graph rendering speed >>>>>>>> using >>>> modern game-engine style structures and algorithms >>>>>>>> JavaFX cannot survive without innovation and I am keen to see >>>>>>>> it >>>> happen and contribute as much as possible. >>>>>>>> Graciously, >>>>>>>> >>>>>>>> >>>>>>>> John-Val Rose >>>>>>>> Rosethorn Technology >>>>>>>> >>>>>>>> >>>>>>>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Sorry about all the typos previously. >>>>>>>>> >>>>>>>>> >>>>>>>>> Question- why not use the code in awt ? I am not totally up >>>>>>>>> on >>>> what's going on with the platforms' native rendering engines ( meaning, >>>> I >>>> have no idea whatsoever) or how they have changed, but golly it sure >>>> does still work pretty well. >>>>>>>>> At least it seems to me looking at awt that a smallish number >>>>>>>>> of >>>> things are 1) well defined by the native platofrm and 2) would more or >>>> less translate directly to an Java API and 3) from those small number of >>>> building blocks, (Font and Glyph metrics and this kind of thing) >>>> text line layout algorithms can be written by ordinary civilians along >>>> with all the other stuff that goes into a text editor. >>>>>>>>> And yes, everything does look easy when someone else is going >>>>>>>>> to do >>>> it. >>>>>>>>> >> >> From tamerkarakan at yahoo.com Fri Dec 15 15:22:46 2017 From: tamerkarakan at yahoo.com (Tamer KARAKAN) Date: Fri, 15 Dec 2017 15:22:46 +0000 (UTC) Subject: No subject References: <36404373.276859.1513351366623.ref@mail.yahoo.com> Message-ID: <36404373.276859.1513351366623@mail.yahoo.com> Android?de Yahoo Postadan g?nderildi From johnvalrose at gmail.com Fri Dec 15 15:58:50 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Sat, 16 Dec 2017 02:58:50 +1100 Subject: =?utf-8?Q?Re:_Innovation_=E2=80=9Cessay=E2=80=9D?= Message-ID: <1D17C354-FCB8-4AF6-B491-9F6D97A3914D@gmail.com> It?s been noted that my previous email was very much in the ?TL;DR? category. I?m sorry about that. I guess I just had a lot to say and feel very passionate about JavaFX. Graciously, John-Val Rose From kevin.rushforth at oracle.com Fri Dec 15 18:55:56 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 15 Dec 2017 10:55:56 -0800 Subject: PLEASE READ: JDK10 RDP1 process for JavaFX Message-ID: <5A341ABC.70703@oracle.com> To: OpenJFX Committers As you should have seen from the message I forwarded from Mark Reinhold, the JDK 10 RDP1 (proposed) rules have been posted. During RDP1 there is no additional approval needed, beyond the usual code review, to push the following types of fixes: * P1-P3 bugs [1] * P1-P5 test and javadoc bugs (must have noreg-self or noreg-doc label) Note that RFEs are no longer allowed in JDK 10 [2] Most fixes will go into jfx-dev/rt for 11, but for those fixes that meet the above criteria, they can go directly in 10-dev/rt. As such, openjfx/10-dev/rt has been reopened for FX fixes for JDK 10. Please ask if you have any questions. If you want to get a bug fix into JDK 10, it is your responsibility to push it there. I will sync from 10-dev --> jfx-dev periodically (roughly once a week, but possibly more often). Alternatively, you can push it to both places if you want the fix into jfx-dev sooner (or you can push to jfx-dev first and then later backport it to 10-dev). -- Kevin [1] Especially for P3 bugs, make sure it is a safe fix and that the priority is correct, and not "I want to get this in so I'll call it a P3" [2] Without prior approval from the JDK project lead, and such approval is not expected to be given From kevin.rushforth at oracle.com Fri Dec 15 18:53:15 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 15 Dec 2017 10:53:15 -0800 Subject: [Fwd: JDK 10 Rampdown Phase One: Process proposal] Message-ID: <5A341A1B.2080505@oracle.com> FYI... -------------- next part -------------- An embedded message was scrubbed... From: mark.reinhold at oracle.com Subject: JDK 10 Rampdown Phase One: Process proposal Date: Fri, 15 Dec 2017 08:35:29 -0800 (PST) Size: 5952 URL: From kevin.rushforth at oracle.com Fri Dec 15 18:59:26 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 15 Dec 2017 10:59:26 -0800 Subject: [10] Review request: JDK-8193636: FX build fails with jdk-10+36 due to missing javah Message-ID: <5A341B8E.2000100@oracle.com> Phil, Please review the following to remove the check for the existence of 'javah': https://bugs.openjdk.java.net/browse/JDK-8193636 http://cr.openjdk.java.net/~kcr/8193636/webrev.00/ Thanks. -- Kevin From nlisker at gmail.com Fri Dec 15 19:08:37 2017 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 15 Dec 2017 21:08:37 +0200 Subject: openjfx-dev Digest, Vol 73, Issue 25 In-Reply-To: References: Message-ID: Kevin, I wouldn't mind pushing javadoc changes into 10, but don't have OpenJFX built yet as I'm waiting for updated instructions on that. Can you tell when is RDP1 ending and when is it planned to update the build instructions so I'll know what my time window is? Thanks, Nir On Fri, Dec 15, 2017 at 8:59 PM, wrote: > Send openjfx-dev mailing list submissions to > openjfx-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > or, via email, send a message with subject or body 'help' to > openjfx-dev-request at openjdk.java.net > > You can reach the person managing the list at > openjfx-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openjfx-dev digest..." > > > Today's Topics: > > 1. Re: Innovation again (was Re: Text classes) (Michael Paus) > 2. (Tamer KARAKAN) > 3. Re: Innovation ?essay? (John-Val Rose) > 4. PLEASE READ: JDK10 RDP1 process for JavaFX (Kevin Rushforth) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 15 Dec 2017 14:42:33 +0100 > From: Michael Paus > To: openjfx-dev at openjdk.java.net > Subject: Re: Innovation again (was Re: Text classes) > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi, > first of all I would like to say that I fully agree with everything that > has been > said so far in this thread and I am glad that someone is pushing this long > overdue discussion. Please find my comments inline. > > Am 15.12.17 um 10:09 schrieb John-Val Rose: > > [...] > > > > This initiative/team/group should not be "hidden" either - it should be > > completely transparent and open to enable anyone to follow the thought > > processes, the progress and the results and also to comment, > constructively > > criticise, make suggestions and even make small contributions. This team > is > > not operating in competition with Oracle - quite the opposite in fact. > > It's there to complement the already great efforts of the Oracle JavaFX > > team. > > > > I am familiar with "The Java EE Guardians" and while I am not proposing > > that we do something with exactly the same model, their results speak for > > themselves. I am open to suggestions and ideas about how such a > group/team > > should be structured and the governance and actually hope that as many > > people as possible chime-in with their own "2 cents". > > > > I'm just offering to be the central contact point for now and then the > > consensus can determine how we proceed. > A lot has already been discussed on this list and elsewhere but my > impression > is that all these ideas are forgotten faster than they are written up > because > there is no place to collect them and no person to organize and > administer such > a place. If such a place existed I would be more than happy to share my > ideas > with others. > > Yes, Chris is absolutely spot-on about the build issues. For the broader > > community to be able to contribute or be motivated to contribute, the > > process must be as simple as possible and first-things-first, we have to > be > > able to reliably build OpenJFX on all supported platforms. No developer > > wants to waste time with build issues; they just want to code. I would > > suggest that this is something Oracle prioritise ahead of perhaps > > everything else with OpenJFX 9/10 (and that anyone who has advanced > > knowledge of the tools or the DevOps pipeline try to help as well). > Yes, I see this as a big stumbling stone as well. I would like to add > that it would > also be necessary to advertise the use of such builds and to harmonize the > handling of version numbers of such builds. I currently have a lot of > problems > using my own builds as well as the EA builds from Oracle with the existing > build tools and IDEs. Many of them get a hick-up if they encounter build > versions > beyond the current/official versions. > > > > As you can see, Chris has basically given us his feature/fix "wish list" > > and I have received the wish lists of many others and, of course, I have > my > > own. > > > > One thing that I have often referred to is the *competitors* of JavaFX > > (like Qt and Xamarin) and how we are lagging behind them and that the > "gap" > > is growing. But one could argue that from another perspective, JavaFX is > > actually itself its only real competitor being the official Java GUI > > toolkit (having supplanted Swing). I like this idea because we all know > > there are about 11 million Java developers in the world and I am sure > most > > agree that Java (or the JVM) should have a first-class graphics toolkit > so > > all of us who love Java and who eat, breathe & live Java don't have to > > "turn to the dark side" and learn or relearn languages like C++ or (dare > I > > say it) C# (aka "Microsoft Java"). > > > > We can observe what is happening with other toolkits and also keep our > > fingers on the pulse of graphics toolkit technology > directions/advancements > > in general and use these as inspirations for how we decide to enhance > > JavaFX. I think I was probably wrong or at least misguided to think that > > we need to try to make JavaFX "a Java version of Qt" for example. > Perhaps > > we just need JavaFX to meet the major requirements of Java GUI developers > > and be able to use it to produce *modern* commercial applications that > look > > great, work well and hold their own against other products, all the while > > we are not having to drift away from Java or the JVM. > In order for this to become true JavaFX first needs to get some basics > right. > My keyword here would be: > - Platform integration (e.g. Mac menu bar.) > - Working packager on all platforms > - An automatic update mechanism for applications (not WebStart) > > > > So to summarise (while you are hopefully still awake), I am not > suggesting > > that I try to tell others what to do or what JavaFX should or shouldn't > be > > but rather that I am simply offering to be the central contact who > > coordinates the ideas, the efforts and the team in general and also to > act > > as a liaison with Oracle or any other company that can be involved. I > can > > also try to set-up any infrastructure required such as a website, a > mailing > > list, Google group, GitHub project etc. > For collecting and structuring of ideas something like GitHub and its Wiki > seem to be a better suited than a mailing list (which we already have.). > > > > If the community feels I am not the best person for this role then that's > > perfectly OK! I am more than happy to just to burn the midnight oil and > > contribute in any way I can. > Go for it. Someone has to make the first step. > > > > After all, this is not about "me" at all - it's all about JavaFX. I > > strongly suspect that such luminaries as mentioned by Chris (and Chris > > himself) are light years ahead of me in knowledge and skills with both > Java > > and JavaFX (and they are all my heroes!). Maybe if I can find an eye > patch > > I can be Nick Fury and the others can be The Avengers? (Sorry if you're > > more of a DC fan). > > > > Please feel free to reach out to me at any time to (privately and > > confidentially) discuss any of these issues, or even better, post on this > > list. > > > > P.S. I'd like to especially praise the efforts and outstanding > achievements > > of Johan Vos and Gluon. All JavaFX developers owe them enormous > gratitude. > > And, they are already doing much of what I am proposing (though mainly in > > the mobile space). > > > > ?? > > Graciously, > > > > John-Val Rose > > Chief Scientist/Architect > > Rosethorn Technology > > > > > > On 15 December 2017 at 18:26, Chris Newland > > wrote: > > > >> Hi John, > >> > >> Here's my $0.02 on JavaFX as someone who's used it for over 4 years in > the > >> JITWatch project (https://github.com/AdoptOpenJDK/jitwatch) and also > for > >> fun with my DemoFX benchmarks (https://github.com/chriswhocodes/DemoFX > ). > >> > >> On the whole I think the API is very good. Event handling, layout, > choice > >> of components give me 99% of what I need. > >> > >> The CSS approach to styling feels a bit clunky when I want to change > >> fine-grained appearance programatically without defining new CSS > classes. > >> Proper font metrics would be nice too (already discussed recently). > >> > >> The Canvas/GraphicsContext API provides a decent entry point into "old > >> school" 2D programming and a way to avoid the scenegraph which does > suffer > >> with scale when you push it too hard. You can do fun things with > >> PixelReader/Writer. > >> > >> Personally I'd like an even lower level API to framebuffers as the > current > >> implementation looks a bit copy-heavy (my opinion from just the source > >> code, I've not had time to see how much the JIT saves us here). I'd > really > >> like the video frame grabber API for MediaPlayer (deprecated after 8) > >> added back but I'm probably alone here. I can always go off-heap here or > >> just implement a video decoder in pure Java. > >> > >> For 3D I think a component that provides a surface usable by an existing > >> OpenGL library is probably better than trying to replicate in pure > OpenJFX > >> but this isn't really my area. > >> > >> I was disappointed when Oracle decided to drop support for ARM / IoT but > >> that's no reflection on the JavaFX team, just a commercial decision by a > >> cloud-focused company. I've tried to keep IoT support going via > community > >> builds of JavaFX 8 at https://www.chriswhocodes.com but I never really > >> cracked getting Windows builds working. I'm hoping to find some time > next > >> year to work with the AdoptOpenJDK group (CC'd) and Laurent Borges > >> (Marlin/MarlinFX) to improve early access testing and cross-platform > >> support of OpenJFX builds. This got a lot harder since the modular JDK9 > >> where you can no longer simply modify OpenJFX, rebuild, and drop an > >> overlay onto your JRE. > >> > >> There are a few companies doing great work (Canoo, Gluon etc.) and a > long > >> list of community individuals (Gerrit, Carl, Sean, Almas, Johan, > Alessio, > >> Sven, Andres, Dirk, Dierk, Michael, Jens, Jose, ... actually the more I > >> think about it the longer this list gets) who showcase what is possible. > >> > >> The Gluon mobile stuff looks really interesting and I've just started > >> trying to rewrite an iOS native app into a cross-platform app using > their > >> Eclipse plugin. > >> > >> In summary I'm very happy with JavaFX and I think the community, while > >> small, contains a lot of talent and energy. > >> > >> The "official" OpenJFX devs are responsive to the community while being > >> realistic about what can be achieved outside their sanctioned roadmap. > >> > >> If there's 1 single thing I'd like to ask for it's an updated set of > build > >> instructions for each platform. That's the biggest barrier to getting > more > >> community patches submitted in my opinion. > >> > >> Just the $0.02 of one JavaFX user ;) > >> > >> Cheers, > >> > >> Chris > >> -- > >> @chriswhocodes > >> > >> > >> > >> On Wed, December 13, 2017 02:28, John-Val Rose wrote: > >>> I posted this over a week ago: > >>> > >>> > >>>> I am willing to work with *anyone* (within Oracle or not) on the > >>>> features > >>> that the community craves, > >>>> such as those I listed (and any others). Not just because ?many hands > >>> make light work? but because > >>>> I don?t know everything (or even close) and I need the knowledge and > >>>> > >>> skills of others to assist me. Not > >>>> to mention that I have only 24 hours in a day like everyone else and, > >>> also like everyone else, some of > >>>> that time has to be devoted to earning an income. > >>>> > >>>> So, if there?s anyone reading this who has the time, the skills, the > >>>> > >>> commitment and the passion to work hard (in your own time) to get these > >>> tasks done then please contact me privately. > >>> > >>> To my significant disappointment, only one person has contacted me > since > >>> then in relation to this proposal. > >>> > >>> I'm beginning to think that I am completely out of touch with the > JavaFX > >>> community, what they actually want and also with exactly *what* JavaFX > is > >>> or is meant to be. > >>> > >>> I have reached out on this list and via Twitter in the hope that an > >>> inspired and passionate group of developers could come together, pool > >>> their resources and collaborate on taking JavaFX as far is it can > >> possibly > >>> go as a fully-fledged hardware-accelerated graphics toolkit for the > JVM. > >>> > >>> But... it seem that my "vision" for JavaFX is unique to me and I have > to > >>> say that I really don't understand why that is. > >>> > >>> Is it that the JavaFX community see it as merely a Swing replacement or > >>> "upgrade" and that there just aren't people out there who want to do > more > >>> sophisticated things with a Java-based toolkit or at least see > >> performance > >>> increase dramatically? > >>> > >>> Or, do people feel that the kind of features you can find in say Qt > >>> cannot be added to JavaFX because it's a "Java thing": well all know > how > >>> slow Java is and that if you want to do real animations, visualisations > >>> etc. then you have to use C++? > >>> > >>> Well, it's not the 1990s anymore. Java is NOT the problem. > >>> > >>> > >>> So, what IS the problem? > >>> > >>> > >>> I have to say that as chief architect for my company, if the JavaFX > >>> community (and I include Oracle as a big part of that) simply don't > want > >>> to see innovation in JavaFX, won't support or contribute to making it > >>> happen or feel they don't need it, causing JavaFX to lag further and > >>> further behind other graphic toolkits and never be capable of > supporting > >>> such features as advanced animations, visualisations, games, 3D, VR, AR > >>> and have proper HTML5 support etc. then, despite being a huge Java fan > >> and > >>> advocate, JavaFX simply can't even be on the table of technologies to > >>> choose from when I'm developing a technological strategy. > >>> > >>> So, I'd like to ask this multi-part question in the hope that as many > >>> people reply as possible: > >>> > >>> *** For *your* siutation, what is JavaFX, how do you want it to evolve > >>> and what does it mean to you? *** > >>> > >>> Maybe I really am "Robinson Crusoe"... > >>> > >>> > >>> ?? > >>> Graciously, > >>> > >>> > >>> John-Val Rose > >>> Chief Scientist/Architect > >>> Rosethorn Technology > >>> > >>> > >>> > >>> On 6 December 2017 at 17:16, John-Val Rose > >> wrote: > >>> > >>>> Absolutely - there needs to be a viable community that is not just > >>>> Oracle. > >>>> > >>>> > >>>> So, is there one? If not, how do we build one? > >>>> > >>>> > >>>> OK, so let me rephrase my earlier email: > >>>> > >>>> > >>>> I am willing to work with *anyone* (within Oracle or not) on the > >>>> features that the community craves, such as those I listed (and any > >>>> others). Not just because ?many hands make light work? but because I > >>>> don?t know everything (or even close) and I need the knowledge and > >>>> skills of others to assist me. Not to mention that I have only 24 > hours > >>>> in a day like everyone else and, also like everyone else, some of that > >>>> time has to be devoted to earning an income. > >>>> > >>>> So, if there?s anyone reading this who has the time, the skills, the > >>>> commitment and the passion to work hard (in your own time) to get > these > >>>> tasks done then please contact me privately. > >>>> > >>>>> On 6 Dec 2017, at 16:50, Philip Race wrote: > >>>>> > >>>>> > >>>>> There needs to be a viable community that is not just Oracle to > >>>>> support > >>>> you here .. > >>>>> I think everyone has come to be dependent on Oracle to "be there". > >>>>> But if there is a specific community need that Oracle doesn't see as > >>>>> > >>>> essential, then the community should help out. > >>>>> -phil. > >>>>> > >>>>> > >>>>>> On 12/5/17, 9:27 PM, John-Val Rose wrote: > >>>>>> Well, that?s all fine but you didn?t address the issue of working > >>>>>> with > >>>> someone within Oracle to get these innovations done. > >>>>>> Sure, I could just toil away by myself but clearly it would be > >>>>>> better > >>>> all around if there was someone with much more extensive knowledge of > >>>> JavaFX and its internals who was accessible when required. > >>>> > >>>>>> I would assume that a member of the Oracle JavaFX team would be > >>>>>> such a > >>>> person. If not, then who? > >>>>>>> On 6 Dec 2017, at 15:53, Philip Race > >>>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>>> I think looking at it as an Oracle-owned and controlled project > >>>>>>> maybe > >>>> the first mistake here. > >>>>>>> Yes it was closed source and then Oracle controlled, but not any > >>>>>>> more, > >>>> OCA requirements aside. > >>>> > >>>>>>> It is not even a "java specification". It can be evolved at an > >>>>>>> API > >>>>>>> > >>>> level without a JSR. > >>>>>>> The JEP process is the main thing to be followed, although we > >>>>>>> also use > >>>> CSRs too to track API. > >>>> > >>>>>>> Consider it that anyone who is a contributor owns (not the right > >>>>>>> word > >>>> ?) a piece of it too. > >>>> > >>>>>>> So standing on the project is what matters. Not the company who > >>>>>>> pays > >>>> you to work on it. > >>>>>>> -phil. > >>>>>>> > >>>>>>> > >>>>>>>> On 12/5/17, 8:21 PM, John-Val Rose wrote: > >>>>>>>> Phil et. al., > >>>>>>>> > >>>>>>>> > >>>>>>>> Whilst I?m not going to be quite as ?passionate? as some on > >>>>>>>> this > >>>> issue (although I do understand the frustration), I would like to > point > >>>> out again that this is indeed a huge gap and it is critical that it is > >>>> filled ASAP. > >>>> > >>>>>>>> Obviously a solution where every word in a text document is a > >>>>>>>> Node > >>>>>>>> > >>>> would be unworkable so it would need to be architected from the ground > >>>> up. > >>>>>>>> I would be happy to work on such as feature, just as I was > >>>>>>>> happy to > >>>> work on implementing WebGL, but my hesitation is concern over the > >>>> assistance and involvement from Oracle. > >>>>>>>> If I am going to have to spend months working on something > >>>>>>>> without > >>>> any or only minimal involvement from Oracle, only to find at the end > >>>> that Oracle either doesn?t like the design, implementation or > something > >>>> else then it is wasted time I?ll never get back. > >>>>>>>> There are lots of other innovations too that I would like to > >>>>>>>> see in > >>>> JavaFX but I just don?t ?feel the enthusiasm? from Oracle. > >>>> > >>>>>>>> If there is someone on the JavaFX team who would be willing to > >>>>>>>> work > >>>> with me (at least in some capacity), please have them contact me > >>>> privately via email. > >>>>>>>> The innovations I could work on and contribute include: > >>>>>>>> > >>>>>>>> > >>>>>>>> 1. WebGL support in WebView > >>>>>>>> 2. Better text support including text documents& rich text > >>>>>>>> editors > >>>> etc. > >>>>>>>> 3. Significant improvements in scene graph rendering speed > >>>>>>>> using > >>>> modern game-engine style structures and algorithms > >>>>>>>> JavaFX cannot survive without innovation and I am keen to see > >>>>>>>> it > >>>> happen and contribute as much as possible. > >>>>>>>> Graciously, > >>>>>>>> > >>>>>>>> > >>>>>>>> John-Val Rose > >>>>>>>> Rosethorn Technology > >>>>>>>> > >>>>>>>> > >>>>>>>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Sorry about all the typos previously. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Question- why not use the code in awt ? I am not totally up > >>>>>>>>> on > >>>> what's going on with the platforms' native rendering engines ( > meaning, > >>>> I > >>>> have no idea whatsoever) or how they have changed, but golly it sure > >>>> does still work pretty well. > >>>>>>>>> At least it seems to me looking at awt that a smallish number > >>>>>>>>> of > >>>> things are 1) well defined by the native platofrm and 2) would more or > >>>> less translate directly to an Java API and 3) from those small number > of > >>>> building blocks, (Font and Glyph metrics and this kind of thing) > >>>> text line layout algorithms can be written by ordinary civilians along > >>>> with all the other stuff that goes into a text editor. > >>>>>>>>> And yes, everything does look easy when someone else is going > >>>>>>>>> to do > >>>> it. > >>>>>>>>> > >> > >> > > > > ------------------------------ > > Message: 2 > Date: Fri, 15 Dec 2017 15:22:46 +0000 (UTC) > From: Tamer KARAKAN > To: "openjfx-dev at openjdk.java.net" > Message-ID: <36404373.276859.1513351366623 at mail.yahoo.com> > Content-Type: text/plain; charset=UTF-8 > > > > Android?de Yahoo Postadan g?nderildi > > ------------------------------ > > Message: 3 > Date: Sat, 16 Dec 2017 02:58:50 +1100 > From: John-Val Rose > To: "openjfx-dev at openjdk.java.net" > Subject: Re: Innovation ?essay? > Message-ID: <1D17C354-FCB8-4AF6-B491-9F6D97A3914D at gmail.com> > Content-Type: text/plain; charset=utf-8 > > It?s been noted that my previous email was very much in the ?TL;DR? > category. > > I?m sorry about that. > > I guess I just had a lot to say and feel very passionate about JavaFX. > > Graciously, > > John-Val Rose > > ------------------------------ > > Message: 4 > Date: Fri, 15 Dec 2017 10:55:56 -0800 > From: Kevin Rushforth > To: "openjfx-dev at openjdk.java.net" > Subject: PLEASE READ: JDK10 RDP1 process for JavaFX > Message-ID: <5A341ABC.70703 at oracle.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > To: OpenJFX Committers > > As you should have seen from the message I forwarded from Mark Reinhold, > the JDK 10 RDP1 (proposed) rules have been posted. > > During RDP1 there is no additional approval needed, beyond the usual > code review, to push the following types of fixes: > > * P1-P3 bugs [1] > > * P1-P5 test and javadoc bugs (must have noreg-self or noreg-doc label) > > Note that RFEs are no longer allowed in JDK 10 [2] > > Most fixes will go into jfx-dev/rt for 11, but for those fixes that meet > the above criteria, they can go directly in 10-dev/rt. As such, > openjfx/10-dev/rt has been reopened for FX fixes for JDK 10. Please ask > if you have any questions. > > If you want to get a bug fix into JDK 10, it is your responsibility to > push it there. I will sync from 10-dev --> jfx-dev periodically (roughly > once a week, but possibly more often). Alternatively, you can push it to > both places if you want the fix into jfx-dev sooner (or you can push to > jfx-dev first and then later backport it to 10-dev). > > -- Kevin > > [1] Especially for P3 bugs, make sure it is a safe fix and that the > priority is correct, and not "I want to get this in so I'll call it a P3" > > [2] Without prior approval from the JDK project lead, and such approval > is not expected to be given > > > > End of openjfx-dev Digest, Vol 73, Issue 25 > ******************************************* > From mike.ennen at gmail.com Fri Dec 15 20:47:15 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 15 Dec 2017 13:47:15 -0700 Subject: Innovation again (was Re: Text classes) In-Reply-To: <5895e0d9a099e85fcb1bffa7a9e94059.squirrel@excalibur.xssl.net> References: <5895e0d9a099e85fcb1bffa7a9e94059.squirrel@excalibur.xssl.net> Message-ID: I am not trying to create an OpenJFX repository that is maintained to any degree But, in my work on the Robot API I also went ahead and created the necessary infrastructure to get OpenJFX building on Appveyor (Windows continuous integration) and Travis CI (both Linux and macOS continuious integration). You can see the commits to the repository here: https://github.com/brcolow/openjfx/commits/master Currently some of it is silly (like using the github releases deployment to host screen captures of failed tests) but that can all be very easily adapted. Adding in the deployment of the actual build artifacts and creating a mercurial to git mirror would allow us to get live builds for all three major platforms. My work in this area may be useful for anyone who wants to maintain an OpenJFX community repository for fielding contributions from a wider field which can then be submitted to Oracle. On Fri, Dec 15, 2017 at 12:26 AM, Chris Newland wrote: > Hi John, > > Here's my $0.02 on JavaFX as someone who's used it for over 4 years in the > JITWatch project (https://github.com/AdoptOpenJDK/jitwatch) and also for > fun with my DemoFX benchmarks (https://github.com/chriswhocodes/DemoFX). > > On the whole I think the API is very good. Event handling, layout, choice > of components give me 99% of what I need. > > The CSS approach to styling feels a bit clunky when I want to change > fine-grained appearance programatically without defining new CSS classes. > Proper font metrics would be nice too (already discussed recently). > > The Canvas/GraphicsContext API provides a decent entry point into "old > school" 2D programming and a way to avoid the scenegraph which does suffer > with scale when you push it too hard. You can do fun things with > PixelReader/Writer. > > Personally I'd like an even lower level API to framebuffers as the current > implementation looks a bit copy-heavy (my opinion from just the source > code, I've not had time to see how much the JIT saves us here). I'd really > like the video frame grabber API for MediaPlayer (deprecated after 8) > added back but I'm probably alone here. I can always go off-heap here or > just implement a video decoder in pure Java. > > For 3D I think a component that provides a surface usable by an existing > OpenGL library is probably better than trying to replicate in pure OpenJFX > but this isn't really my area. > > I was disappointed when Oracle decided to drop support for ARM / IoT but > that's no reflection on the JavaFX team, just a commercial decision by a > cloud-focused company. I've tried to keep IoT support going via community > builds of JavaFX 8 at https://www.chriswhocodes.com but I never really > cracked getting Windows builds working. I'm hoping to find some time next > year to work with the AdoptOpenJDK group (CC'd) and Laurent Borges > (Marlin/MarlinFX) to improve early access testing and cross-platform > support of OpenJFX builds. This got a lot harder since the modular JDK9 > where you can no longer simply modify OpenJFX, rebuild, and drop an > overlay onto your JRE. > > There are a few companies doing great work (Canoo, Gluon etc.) and a long > list of community individuals (Gerrit, Carl, Sean, Almas, Johan, Alessio, > Sven, Andres, Dirk, Dierk, Michael, Jens, Jose, ... actually the more I > think about it the longer this list gets) who showcase what is possible. > > The Gluon mobile stuff looks really interesting and I've just started > trying to rewrite an iOS native app into a cross-platform app using their > Eclipse plugin. > > In summary I'm very happy with JavaFX and I think the community, while > small, contains a lot of talent and energy. > > The "official" OpenJFX devs are responsive to the community while being > realistic about what can be achieved outside their sanctioned roadmap. > > If there's 1 single thing I'd like to ask for it's an updated set of build > instructions for each platform. That's the biggest barrier to getting more > community patches submitted in my opinion. > > Just the $0.02 of one JavaFX user ;) > > Cheers, > > Chris > -- > @chriswhocodes > > > > On Wed, December 13, 2017 02:28, John-Val Rose wrote: > > I posted this over a week ago: > > > > > >> I am willing to work with *anyone* (within Oracle or not) on the > >> features > > that the community craves, > >> such as those I listed (and any others). Not just because ?many hands > > make light work? but because > >> I don?t know everything (or even close) and I need the knowledge and > >> > > skills of others to assist me. Not > >> to mention that I have only 24 hours in a day like everyone else and, > > also like everyone else, some of > >> that time has to be devoted to earning an income. > >> > >> So, if there?s anyone reading this who has the time, the skills, the > >> > > commitment and the passion to work hard (in your own time) to get these > > tasks done then please contact me privately. > > > > To my significant disappointment, only one person has contacted me since > > then in relation to this proposal. > > > > I'm beginning to think that I am completely out of touch with the JavaFX > > community, what they actually want and also with exactly *what* JavaFX is > > or is meant to be. > > > > I have reached out on this list and via Twitter in the hope that an > > inspired and passionate group of developers could come together, pool > > their resources and collaborate on taking JavaFX as far is it can > possibly > > go as a fully-fledged hardware-accelerated graphics toolkit for the JVM. > > > > But... it seem that my "vision" for JavaFX is unique to me and I have to > > say that I really don't understand why that is. > > > > Is it that the JavaFX community see it as merely a Swing replacement or > > "upgrade" and that there just aren't people out there who want to do more > > sophisticated things with a Java-based toolkit or at least see > performance > > increase dramatically? > > > > Or, do people feel that the kind of features you can find in say Qt > > cannot be added to JavaFX because it's a "Java thing": well all know how > > slow Java is and that if you want to do real animations, visualisations > > etc. then you have to use C++? > > > > Well, it's not the 1990s anymore. Java is NOT the problem. > > > > > > So, what IS the problem? > > > > > > I have to say that as chief architect for my company, if the JavaFX > > community (and I include Oracle as a big part of that) simply don't want > > to see innovation in JavaFX, won't support or contribute to making it > > happen or feel they don't need it, causing JavaFX to lag further and > > further behind other graphic toolkits and never be capable of supporting > > such features as advanced animations, visualisations, games, 3D, VR, AR > > and have proper HTML5 support etc. then, despite being a huge Java fan > and > > advocate, JavaFX simply can't even be on the table of technologies to > > choose from when I'm developing a technological strategy. > > > > So, I'd like to ask this multi-part question in the hope that as many > > people reply as possible: > > > > *** For *your* siutation, what is JavaFX, how do you want it to evolve > > and what does it mean to you? *** > > > > Maybe I really am "Robinson Crusoe"... > > > > > > ?? > > Graciously, > > > > > > John-Val Rose > > Chief Scientist/Architect > > Rosethorn Technology > > > > > > > > On 6 December 2017 at 17:16, John-Val Rose > wrote: > > > > > >> Absolutely - there needs to be a viable community that is not just > >> Oracle. > >> > >> > >> So, is there one? If not, how do we build one? > >> > >> > >> OK, so let me rephrase my earlier email: > >> > >> > >> I am willing to work with *anyone* (within Oracle or not) on the > >> features that the community craves, such as those I listed (and any > >> others). Not just because ?many hands make light work? but because I > >> don?t know everything (or even close) and I need the knowledge and > >> skills of others to assist me. Not to mention that I have only 24 hours > >> in a day like everyone else and, also like everyone else, some of that > >> time has to be devoted to earning an income. > >> > >> So, if there?s anyone reading this who has the time, the skills, the > >> commitment and the passion to work hard (in your own time) to get these > >> tasks done then please contact me privately. > >> > >>> On 6 Dec 2017, at 16:50, Philip Race wrote: > >>> > >>> > >>> There needs to be a viable community that is not just Oracle to > >>> support > >> you here .. > >>> I think everyone has come to be dependent on Oracle to "be there". > >>> But if there is a specific community need that Oracle doesn't see as > >>> > >> essential, then the community should help out. > >>> > >>> -phil. > >>> > >>> > >>>> On 12/5/17, 9:27 PM, John-Val Rose wrote: > >>>> Well, that?s all fine but you didn?t address the issue of working > >>>> with > >> someone within Oracle to get these innovations done. > >>>> > >>>> Sure, I could just toil away by myself but clearly it would be > >>>> better > >> all around if there was someone with much more extensive knowledge of > >> JavaFX and its internals who was accessible when required. > >> > >>>> > >>>> I would assume that a member of the Oracle JavaFX team would be > >>>> such a > >> person. If not, then who? > >>>> > >>>>> On 6 Dec 2017, at 15:53, Philip Race > >>>>> wrote: > >>>>> > >>>>> > >>>>> I think looking at it as an Oracle-owned and controlled project > >>>>> maybe > >> the first mistake here. > >>>>> Yes it was closed source and then Oracle controlled, but not any > >>>>> more, > >> OCA requirements aside. > >> > >>>>> It is not even a "java specification". It can be evolved at an > >>>>> API > >>>>> > >> level without a JSR. > >>>>> The JEP process is the main thing to be followed, although we > >>>>> also use > >> CSRs too to track API. > >> > >>>>> Consider it that anyone who is a contributor owns (not the right > >>>>> word > >> ?) a piece of it too. > >> > >>>>> So standing on the project is what matters. Not the company who > >>>>> pays > >> you to work on it. > >>>>> > >>>>> -phil. > >>>>> > >>>>> > >>>>>> On 12/5/17, 8:21 PM, John-Val Rose wrote: > >>>>>> Phil et. al., > >>>>>> > >>>>>> > >>>>>> Whilst I?m not going to be quite as ?passionate? as some on > >>>>>> this > >> issue (although I do understand the frustration), I would like to point > >> out again that this is indeed a huge gap and it is critical that it is > >> filled ASAP. > >> > >>>>>> > >>>>>> Obviously a solution where every word in a text document is a > >>>>>> Node > >>>>>> > >> would be unworkable so it would need to be architected from the ground > >> up. > >>>>>> > >>>>>> I would be happy to work on such as feature, just as I was > >>>>>> happy to > >> work on implementing WebGL, but my hesitation is concern over the > >> assistance and involvement from Oracle. > >>>>>> > >>>>>> If I am going to have to spend months working on something > >>>>>> without > >> any or only minimal involvement from Oracle, only to find at the end > >> that Oracle either doesn?t like the design, implementation or something > >> else then it is wasted time I?ll never get back. > >>>>>> > >>>>>> There are lots of other innovations too that I would like to > >>>>>> see in > >> JavaFX but I just don?t ?feel the enthusiasm? from Oracle. > >> > >>>>>> > >>>>>> If there is someone on the JavaFX team who would be willing to > >>>>>> work > >> with me (at least in some capacity), please have them contact me > >> privately via email. > >>>>>> > >>>>>> The innovations I could work on and contribute include: > >>>>>> > >>>>>> > >>>>>> 1. WebGL support in WebView > >>>>>> 2. Better text support including text documents& rich text > >>>>>> editors > >> etc. > >>>>>> 3. Significant improvements in scene graph rendering speed > >>>>>> using > >> modern game-engine style structures and algorithms > >>>>>> > >>>>>> JavaFX cannot survive without innovation and I am keen to see > >>>>>> it > >> happen and contribute as much as possible. > >>>>>> > >>>>>> Graciously, > >>>>>> > >>>>>> > >>>>>> John-Val Rose > >>>>>> Rosethorn Technology > >>>>>> > >>>>>> > >>>>>>> On 6 Dec 2017, at 11:36, javafx at use.startmail.com wrote: > >>>>>>> > >>>>>>> > >>>>>>> Sorry about all the typos previously. > >>>>>>> > >>>>>>> > >>>>>>> Question- why not use the code in awt ? I am not totally up > >>>>>>> on > >> what's going on with the platforms' native rendering engines ( meaning, > >> I > >> have no idea whatsoever) or how they have changed, but golly it sure > >> does still work pretty well. > >>>>>>> > >>>>>>> At least it seems to me looking at awt that a smallish number > >>>>>>> of > >> things are 1) well defined by the native platofrm and 2) would more or > >> less translate directly to an Java API and 3) from those small number of > >> building blocks, (Font and Glyph metrics and this kind of thing) > >> text line layout algorithms can be written by ordinary civilians along > >> with all the other stuff that goes into a text editor. > >>>>>>> > >>>>>>> And yes, everything does look easy when someone else is going > >>>>>>> to do > >> it. > >>>>>>> > >>>>>>> > >> > > > > > -- Michael Ennen From kevin.rushforth at oracle.com Fri Dec 15 21:39:25 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 15 Dec 2017 13:39:25 -0800 Subject: javadoc changes [was: openjfx-dev Digest, Vol 73, Issue 25] In-Reply-To: References: Message-ID: <5A34410D.3020401@oracle.com> [fixed subject line] The freeze for the last planned integration prior to RDP2 will be on 1/15/2018 (end of the day Pacific time), so this is the deadline. RDP2 starts on 1/18/2018. See the jdk10 project page [1] for all JDK 10 dates. I hope to fix at least a first pass of the build instructions to get rid of obsolete or incorrect instructions, and get something usable for each platform next week (before the Christmas holiday in the US). As for javadoc changes, are these simple changes to the text that you will propose? If so, it might be something we could add to JDK-8188314 (Fix typos in FX API docs) or maybe a follow-on, in which case you could just send diffs or email comments to attach to the JBS issue. Or is it something else you had in mind? Anything much beyond simple javadoc fixes should probably wait for the next release, but that still leaves a fair bit of room for improvements to the docs that can still go into 10 if you are of a mind to to do it. -- Kevin [1] http://openjdk.java.net/projects/jdk/10/ [2] https://bugs.openjdk.java.net/browse/JDK-8188314 Nir Lisker wrote: > Kevin, > > I wouldn't mind pushing javadoc changes into 10, but don't have > OpenJFX built yet as I'm waiting for updated instructions on that. Can > you tell when is RDP1 ending and when is it planned to update the > build instructions so I'll know what my time window is? > > Thanks, > Nir > From adam at adamish.com Sat Dec 16 04:50:05 2017 From: adam at adamish.com (Adam Granger) Date: Fri, 15 Dec 2017 20:50:05 -0800 Subject: Build failure on missing ant-javafx.jar Message-ID: <73d719570225cd54084c679f82970cb4c5e46212@webmail.adamish.com> Greetings, When performing an OpenJFX build from hg tag 8u131b11 the build fails on ??? > Execution failed for task ':apps:appsJarLinux'. ??? > The following error occurred while executing this line: ??? > ? /tmp/build/rt/apps/samples/build.xml:14: The following error occurred while executing this line: ??? > ? /tmp/build/rt/apps/samples/Ensemble8/build.xml:158: Problem: failed to create task or type javafx:com.sun.javafx.tools.ant:application I?ve traced this to the build expecting to find? the JAR "${platform.home}/lib/ant-javafx.jar" however platform.home is set to /usr/lib/jvm/java-openjdk. I'm using a vanilla openjdk on Centos 6.8 as my boot JDK which does not contain any JavaFX parts - this matches the build instructions from https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX which state ??? "The OpenJFX build requires a Java JDK 8 that does not have the JFX jar present. The build scripts check for this condition, and will refuse to continue if it is found"... Surely this is a chicken-and-egg situation?. The OpenJFX build shouldn?t expect that the boot-JDK already contains JavaFX parts? Instead the build should use the ant-javafx.jar file that it built earlier? Apologies if I've misunderstood this. Other than that I've found the OpenJFX pretty good and well documented, thanks to all involved. Thanks, Adam From nlisker at gmail.com Sat Dec 16 09:24:52 2017 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 16 Dec 2017 11:24:52 +0200 Subject: javadoc changes [was: openjfx-dev Digest, Vol 73, Issue 25] In-Reply-To: <5A34410D.3020401@oracle.com> References: <5A34410D.3020401@oracle.com> Message-ID: Sorry about the subject line, I believe the gmail web client is not very suitable for mailing lists. If anyone has suggestions about it please let me know (privately or publicly). The schedule is fine for me, 2-3 weeks should be more than enough. I have 2 sets of changes in mind. One is corrections like the various "Fix typos in FX API docs" issues which I want to get into 10. Honestly, I want to use these as practice for submitting patches as not much can go wrong and they can be evaluated quickly (without tests, backwards comp. issues etc.). I have the list in a "non-human readable format" so I would need to re-write it if you want me to send it somewhere. The second set is expansion on current docs which I find lacking (comparing to Swing/AWT) and that is more extensive, so I would think to get it into 11 (or if a timely interim version suddenly appears then maybe that). Should I formulate a full proposal on the second set? Nir On Fri, Dec 15, 2017 at 11:39 PM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > [fixed subject line] > > The freeze for the last planned integration prior to RDP2 will be on > 1/15/2018 (end of the day Pacific time), so this is the deadline. RDP2 > starts on 1/18/2018. See the jdk10 project page [1] for all JDK 10 dates. > > I hope to fix at least a first pass of the build instructions to get rid > of obsolete or incorrect instructions, and get something usable for each > platform next week (before the Christmas holiday in the US). > > As for javadoc changes, are these simple changes to the text that you will > propose? If so, it might be something we could add to JDK-8188314 (Fix > typos in FX API docs) or maybe a follow-on, in which case you could just > send diffs or email comments to attach to the JBS issue. Or is it something > else you had in mind? Anything much beyond simple javadoc fixes should > probably wait for the next release, but that still leaves a fair bit of > room for improvements to the docs that can still go into 10 if you are of a > mind to to do it. > > -- Kevin > > [1] http://openjdk.java.net/projects/jdk/10/ > > [2] https://bugs.openjdk.java.net/browse/JDK-8188314 > > > Nir Lisker wrote: > >> Kevin, >> >> I wouldn't mind pushing javadoc changes into 10, but don't have OpenJFX >> built yet as I'm waiting for updated instructions on that. Can you tell >> when is RDP1 ending and when is it planned to update the build instructions >> so I'll know what my time window is? >> >> Thanks, >> Nir >> >> > From guy.abossolo.foh at scientificware.com Sat Dec 16 10:47:46 2017 From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy) Date: Sat, 16 Dec 2017 11:47:46 +0100 Subject: Text classes Message-ID: <3fd229f0504be9bffabaeb5134eba692@scientificware.com> Hello, * Does it means you're interested to port swing/text package to JavaFX ? If the case, I will integrate your community to participate. * This debate is a true problematic, ** First, "Do it yourself" ! I recently posted a message about MathML support in JavaFX. MathML display is broken since 2015. This is the same response : if that's a priority for you, you can do it by yourself : > "If you are interested in seeing that this bug get fixed > sooner, then I might suggest that you consider contributing a fix > for > this bug youself." ** Secondly, how to participate in this project ? Ok, but my experience was not the best in hacking OpenJDK by myself. Without several supplications and an active sponsoring of an Oracle Engineer my patch would have never be pushed in the OpenJDK. My reponse to Kevin message : "I already contributed to openjdk specific bugs for the same reasons you give me. An issue in the swing/text package. My patch was posted in 2012 and accepted in 2017 for JDK9. It hasn't been a great experience for me. I'm working on Math notation support in swing/text package. And the day that I also try to work with JavaFx ... the MathML support is broken ! I'm really interested in seeing this bug fixed. That's why, I first contacted F. Wang from Igalia who worked on MathML integration in WebKit because I thought that it was a WebKit issue. But he answered me that it's probably a bug in OpenJFX because in others WebKit based applications, all works fine. He suggested me to post a bug report. Thus I made a look to the bug database and discovered that it's an old issue. This issue doesn't disappear with the new WebKit version in JavaFX. And now, I'm trying to contact Murali to know what I can expect in the future releases. I would be happy and proud to fix this issue but there is no documentation about WebKit integration in OpenJFX. I hope Murali will add a comment about he plans to look at this." ** Finaly, I don't know ... Murali added his comment in the bug report last week : MathML support is not a priority. What I 'll have to do now ? No response ! I hope not offense anybody with my bad english. I'm a pretty constructive person. Best regards. From javafx at use.startmail.com Sat Dec 16 13:53:11 2017 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Sat, 16 Dec 2017 08:53:11 -0500 Subject: Text classes In-Reply-To: <3fd229f0504be9bffabaeb5134eba692@scientificware.com> References: <3fd229f0504be9bffabaeb5134eba692@scientificware.com> Message-ID: Created a github page with a? wiki anyone interested is invited to join: https://github.com/javafx-iness/master/wiki I am interested to be able to do hit testing on Text for the purpose of writing a rich text editor, among other things.? ? On Saturday, December 16, 2017 5:47 AM, Abossolo Foh Guy wrote: ? > Hello, > > * Does it means you're interested to port swing/text package to > JavaFX ? > If the case, I will integrate your community to participate. > > * This debate is a true problematic, > > ** First, "Do it yourself" ! > I recently posted a message about MathML support in JavaFX. MathML > display is broken since 2015. This is the same response : if that's a > priority for you, you can do it by yourself : >> ? ?"If you are interested in seeing that this bug get fixed >> ? ?sooner, then I might suggest that you consider contributing a fix >> for >> ? ?this bug youself." > ** Secondly, how to participate in this project ? > Ok, but my experience was not the best in hacking OpenJDK by myself. > Without several supplications and an active sponsoring of an Oracle > Engineer my patch would have never be pushed in the OpenJDK. My > reponse > to Kevin message : > > "I already contributed to openjdk specific bugs for the same reasons > you > give me. An issue in the swing/text package. My patch was posted in > 2012 > and accepted in 2017 for JDK9. It hasn't been a great experience for > me. > I'm working on Math notation support in swing/text package. > > And the day that I also try to work with JavaFx ... the MathML > support > is broken ! > > I'm really interested in seeing this bug fixed. > That's why, I first contacted F. Wang from Igalia who worked on > MathML > integration in WebKit because I thought that it was a WebKit issue. > But > he answered me that it's probably a bug in OpenJFX because in others > WebKit based applications, all works fine. He suggested me to post a > bug > report. Thus I made a look to the bug database and discovered that > it's > an old issue. This issue doesn't disappear with the new WebKit > version > in JavaFX. > And now, I'm trying to contact Murali to know what I can expect in > the > future releases. > I would be happy and proud to fix this issue but there is no > documentation about WebKit integration in OpenJFX. > I hope Murali will add a comment about he plans to look at this." > > ** Finaly, I don't know ... > Murali added his comment in the bug report last week : MathML support > is > not a priority. What I 'll have to do now ? No response ! > > I hope not offense anybody with my bad english. I'm a pretty > constructive person. > > Best regards. > ? From guy.abossolo.foh at scientificware.com Sun Dec 17 07:54:11 2017 From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy) Date: Sun, 17 Dec 2017 08:54:11 +0100 Subject: Text classes Message-ID: <0f9e4fa2078731a0fe58dbd9eb7bad41@scientificware.com> Hi, "You cannot do hit testing on current Text. That is, given an x-y coordinate on a screen of text, which presumably represents a mouse click location, you cannot get the offset into the characters at that x,y. This is a necessary part of writing a rich text editor ..." I understand the response of Oracle lead. All you need to implement that is already public. It's the reason why I asked you, if you want to implement a swing/text like module/package in JavaFX. Best regards. From guy.abossolo.foh at scientificware.com Sun Dec 17 08:01:03 2017 From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy) Date: Sun, 17 Dec 2017 09:01:03 +0100 Subject: JDK-8147476 Rendering issues with MathML token elements (Message for Murali Billa) Message-ID: Hello, About the comment in JDK-8147476 : * First, I tested webkit with Safari on OSX and IOS last versions in an Apple Store and with my Ipod. The screen captures confirm F. Wang (igalia) conclusion about the status of WebKit (Removed for the list). The display is pretty good. I tested these applications with Mozilla MathML Torture Test (https://developer.mozilla.org/fr/docs/Mozilla/MathML_Project/MathML_Torture_Test) and the link posted in the bug report . * Secondly : About Chrome, MathML support in Chrome is in progress : May 2017 : https://twitter.com/regocas/status/869871891628126209 Novembre 2017 : https://mathml.igalia.com/ It seems that Google and Igalia had reached an agreement. * Thirdly : Who knows that JavaFX support MathML since 2015. No reference in your documentation and in the MathML w3c website (Software section). Best regards. From pedro.duquevieira at gmail.com Mon Dec 18 22:12:07 2017 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 18 Dec 2017 22:12:07 +0000 Subject: Innovation again Message-ID: Hi, I've been with JavaFX since version 1, also have experience with Swing. Been on a number of JavaFX commercial projects, contributed to community projects like JFxtras, ControlsFX, worked on Scene Builder and also have some open source JavaFX projects of my own. Like others said I think building openJFX should be as easy as possible, having to climb a mountain to be able to contribute or worse yet trying to climb and having to give up half way will block many people from contributing. Having JavaFX team members help out contributors would also be very helpful, I think, or at least having the OpenJFX various areas thoroughly documented. For every hour a JavaFX team member spends on helping out with some guidance community members on a specific issue it would be multiplied for several working man hours. I remember when I was a kid reading about how it was important for the guys who made Counter-Strike to be able to talk to Valve developers directly, Counter-Strike is one of the most successful online games of all time, it started as a modification (mod) to the Half-Life game owned by Valve, it was a free modification and was developed by a bunch of passionate developers who earned nothing for it in return. The game was created 18 years ago, later Valve adquierd the rights and now, 18 years later Valve still sells and profits from newer versions of the Game. A bunch of other successful mods were also created for Half-Life. Lastly someone has mentioned performance as the major issue with JavaFX. I agree. I've never felt this with desktop apps, but maybe the apps I've built were not performance heavy. Having worked on JavaFX for mobile the major issue I've found with it was performance, specially animations were not smooth which hindered the user experience. If JavaFX is to grow and get more and more adoption it has to run great on mobile. My 0.02? :) Cheers, -- Pedro Duque Vieira From johnvalrose at gmail.com Tue Dec 19 01:08:22 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Tue, 19 Dec 2017 12:08:22 +1100 Subject: Innovation again In-Reply-To: References: Message-ID: Thank you Pedro. I?ve admired your work for some time. Well, it seems we?re all singing the same song. The question is, who (if anyone) is listening? > On 19 Dec 2017, at 09:12, Pedro Duque Vieira wrote: > > Hi, > > I've been with JavaFX since version 1, also have experience with Swing. > Been on a number of JavaFX commercial projects, contributed to community > projects like JFxtras, ControlsFX, worked on Scene Builder and also have > some open source JavaFX projects of my own. > > Like others said I think building openJFX should be as easy as possible, > having to climb a mountain to be able to contribute or worse yet trying to > climb and having to give up half way will block many people from > contributing. > > Having JavaFX team members help out contributors would also be very > helpful, I think, or at least having the OpenJFX various areas thoroughly > documented. For every hour a JavaFX team member spends on helping out with > some guidance community members on a specific issue it would be multiplied > for several working man hours. > I remember when I was a kid reading about how it was important for the guys > who made Counter-Strike to be able to talk to Valve developers directly, > Counter-Strike is one of the most successful online games of all time, it > started as a modification (mod) to the Half-Life game owned by Valve, it > was a free modification and was developed by a bunch of passionate > developers who earned nothing for it in return. > The game was created 18 years ago, later Valve adquierd the rights and > now, 18 years later Valve still sells and profits from newer versions of > the Game. A bunch of other successful mods were also created for Half-Life. > > Lastly someone has mentioned performance as the major issue with JavaFX. I > agree. I've never felt this with desktop apps, but maybe the apps I've > built were not performance heavy. > Having worked on JavaFX for mobile the major issue I've found with it was > performance, specially animations were not smooth which hindered the user > experience. If JavaFX is to grow and get more and more adoption it has to > run great on mobile. > > My 0.02? :) > > Cheers, > > > > -- > Pedro Duque Vieira From kevin.rushforth at oracle.com Tue Dec 19 19:14:30 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Dec 2017 11:14:30 -0800 Subject: [10] Review request: 8193823: gradle test fails to run when using jdk-10+36 as boot JDK Message-ID: <5A396516.9060209@oracle.com> Phil, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8193823 http://cr.openjdk.java.net/~kcr/8193823/webrev.00/ This will allow us to continue to build with the latest JDK and works around a gradle bug that was exposed with the time-based version string changes for JEP-322 that went into jdk-10+36. -- Kevin From philip.race at oracle.com Tue Dec 19 20:11:27 2017 From: philip.race at oracle.com (Phil Race) Date: Tue, 19 Dec 2017 12:11:27 -0800 Subject: Building OpenJFX. Message-ID: In the "innovation" email thread it was suggested that one obstacle to getting involved and contributing to OpenJFX is just building it. So what are the top one or two pain points with building OpenJFX today ? - Insufficient or out-dated build docs ? - Tool-chain configuration problems - platform-specific or otherwise ? - Needing to do a JDK build as well (JDK 9 and later) ? - Something else ? And having identified your pain point(s), what do you think would be a solution ? -phil. From bourges.laurent at gmail.com Tue Dec 19 20:42:02 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 19 Dec 2017 21:42:02 +0100 Subject: Building OpenJFX. In-Reply-To: References: Message-ID: Phil, I am using ubuntu 17.4 (soon will upgrade to 17.10) and gcc 6 is the default compiler. I submitted a jfx bug as I had to fix some c code (wait call) and ignore warnings (as error) to build OpenJFX / JDK 10 on gcc6. I may help fixing some warnings but I am not an expert of javafx native code so I can give you at least the complete list of gcc warnings. My 2 cents... Cheers, Laurent Le 19 d?c. 2017 21:12, "Phil Race" a ?crit : > In the "innovation" email thread it was suggested that one obstacle to > getting involved and contributing to OpenJFX is just building it. > > So what are the top one or two pain points with building OpenJFX today ? > > - Insufficient or out-dated build docs ? > - Tool-chain configuration problems - platform-specific or otherwise ? > - Needing to do a JDK build as well (JDK 9 and later) ? > - Something else ? > > And having identified your pain point(s), what do you think would be a > solution ? > > -phil. > From neugens.limasoftware at gmail.com Tue Dec 19 21:04:39 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 19 Dec 2017 22:04:39 +0100 Subject: Building OpenJFX. In-Reply-To: References: Message-ID: For me the most intricate part is about building the webkit based code, especially on RHEL/CentOS. I admit I didn't try with the very latest code drop though. The moving version of Gradle is also an issue, since we try to use a stable toolchain on those OSes. Cheers, Mario 2017-12-19 21:11 GMT+01:00 Phil Race : > In the "innovation" email thread it was suggested that one obstacle to > getting involved and contributing to OpenJFX is just building it. > > So what are the top one or two pain points with building OpenJFX today ? > > - Insufficient or out-dated build docs ? > - Tool-chain configuration problems - platform-specific or otherwise ? > - Needing to do a JDK build as well (JDK 9 and later) ? > - Something else ? > > And having identified your pain point(s), what do you think would be a > solution ? > > -phil. -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From kevin.rushforth at oracle.com Tue Dec 19 21:17:11 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Dec 2017 13:17:11 -0800 Subject: Building OpenJFX. In-Reply-To: References: Message-ID: <5A3981D7.3050201@oracle.com> Building WebKit is challenging, to be sure. I hope to enlist the help of some of our WebKit team members to review (and contribute to) update build instructions to help make it a little less painful, but it is still a challenge. As for the moving version of gradle, we so far have settled on a specific version for each release family: gradle 1.8 for JDK 8u, 3.1 for JDK 9, and 4.3 for JDK 10. We don't tend to bump it. Thanks for the feedback. -- Kevin Mario Torre wrote: > For me the most intricate part is about building the webkit based > code, especially on RHEL/CentOS. I admit I didn't try with the very > latest code drop though. The moving version of Gradle is also an > issue, since we try to use a stable toolchain on those OSes. > > Cheers, > Mario > > 2017-12-19 21:11 GMT+01:00 Phil Race : > >> In the "innovation" email thread it was suggested that one obstacle to >> getting involved and contributing to OpenJFX is just building it. >> >> So what are the top one or two pain points with building OpenJFX today ? >> >> - Insufficient or out-dated build docs ? >> - Tool-chain configuration problems - platform-specific or otherwise ? >> - Needing to do a JDK build as well (JDK 9 and later) ? >> - Something else ? >> >> And having identified your pain point(s), what do you think would be a >> solution ? >> >> -phil. >> > > > > From johan.vos at gluonhq.com Tue Dec 19 21:39:23 2017 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 19 Dec 2017 21:39:23 +0000 Subject: Building OpenJFX. In-Reply-To: References: Message-ID: To be honest, building OpenJFX is the least of my worries. Compared with other frameworks, building OpenJFX is extremely easy and well-documented. The wiki pages are still mostly accurate. I agree with Mario about the webkit: that is the biggest pain imho. The fact that a bunch of code is dropped every now and then doesn't make it easy. Also, it takes a very long time to build those sources. On Android and iOS, we don't have that problem as we leverage the webkit libraries that are available on those platforms. It would be great if we could do something similar on desktop (link instead of compile). About the gradle moving target: OpenJFX has for a VERY long time been on gradle 1.8. The recent changes were, as I see it, required to keep up with the gradle/Java9 catchup. For Android and iOS, I took the build.gradle from OpenJFX 10 and build with a released Java 9, and that works perfect. I think the gradle bumps will be less now. - Johan On Tue, Dec 19, 2017 at 9:22 PM Phil Race wrote: > In the "innovation" email thread it was suggested that one obstacle to > getting involved and contributing to OpenJFX is just building it. > > So what are the top one or two pain points with building OpenJFX today ? > > - Insufficient or out-dated build docs ? > - Tool-chain configuration problems - platform-specific or otherwise ? > - Needing to do a JDK build as well (JDK 9 and later) ? > - Something else ? > > And having identified your pain point(s), what do you think would be a > solution ? > > -phil. > From swpalmer at gmail.com Tue Dec 19 22:04:50 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 19 Dec 2017 17:04:50 -0500 Subject: Building OpenJFX. In-Reply-To: <5A3981D7.3050201@oracle.com> References: <5A3981D7.3050201@oracle.com> Message-ID: <8A96BFCC-74D7-40D6-9CFF-3E3EEDDF37C6@gmail.com> The project should be configured to use the Gradle Wrapper, so the correct version of Gradle is used automatically. https://docs.gradle.org/current/userguide/gradle_wrapper.html There was some concern about checking in the gradle-wrapper.jar file, and potential licensing issues. While I doubt such issues are ?real? I understand that you have to deal with Oracle lawyers. Perhaps a solution then is to configure the wrapper via a setup step to run the wrapper task with any version of gradle that can handle it, then run the gradlew script that it generates. e.g. build.gradle contains: task wrapper(type: Wrapper) { gradleVersion = '4.3' } one-time setup: gradle wrapper run the build: gradlew Gradle bumps should be able to happen any time without causing issues. Gradle becomes just another dependency that is automatically fetched. A simple check to make sure the Gradle version is okay can be coded into the build script, e.g. something like: def blessed_gradle_version = '4.3' task wrapper(type: Wrapper) { gradleVersion = blessed_gradle_version } if (project.gradle.gradleVersion != blessed_gradle_version) { println "Build expects ${blessed_gradle_version} but found ${project.gradle.gradleVersion}\n Run 'gradle wrapper', then use 'gradlew'" } else { apply from: 'real_build.gradle' } Gradle incompatibilities should be rare anyway. What I would really like to see, and I know I?m asking for a lot, is the elimination of the Cygwin requirement and the use of the Gradle native plugin for the native code (maybe we can exclude WebKit from that for now) You shouldn?t need Ant either. It should be easy to build without WebKit and have pre-built WebKit binaries pulled in like any other dependency instead, based on a build property. E.g. gradlew -PusePrebuiltWebKit=true Regards, Scott > On Dec 19, 2017, at 4:17 PM, Kevin Rushforth wrote: > > Building WebKit is challenging, to be sure. I hope to enlist the help of some of our WebKit team members to review (and contribute to) update build instructions to help make it a little less painful, but it is still a challenge. > > As for the moving version of gradle, we so far have settled on a specific version for each release family: gradle 1.8 for JDK 8u, 3.1 for JDK 9, and 4.3 for JDK 10. We don't tend to bump it. > > Thanks for the feedback. > > -- Kevin > > > Mario Torre wrote: >> For me the most intricate part is about building the webkit based >> code, especially on RHEL/CentOS. I admit I didn't try with the very >> latest code drop though. The moving version of Gradle is also an >> issue, since we try to use a stable toolchain on those OSes. >> >> Cheers, >> Mario >> >> 2017-12-19 21:11 GMT+01:00 Phil Race : >> >>> In the "innovation" email thread it was suggested that one obstacle to >>> getting involved and contributing to OpenJFX is just building it. >>> >>> So what are the top one or two pain points with building OpenJFX today ? >>> >>> - Insufficient or out-dated build docs ? >>> - Tool-chain configuration problems - platform-specific or otherwise ? >>> - Needing to do a JDK build as well (JDK 9 and later) ? >>> - Something else ? >>> >>> And having identified your pain point(s), what do you think would be a >>> solution ? >>> >>> -phil. From neugens.limasoftware at gmail.com Tue Dec 19 22:13:20 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 19 Dec 2017 23:13:20 +0100 Subject: Building OpenJFX. In-Reply-To: <8A96BFCC-74D7-40D6-9CFF-3E3EEDDF37C6@gmail.com> References: <5A3981D7.3050201@oracle.com> <8A96BFCC-74D7-40D6-9CFF-3E3EEDDF37C6@gmail.com> Message-ID: 2017-12-19 23:04 GMT+01:00 Scott Palmer : > The project should be configured to use the Gradle Wrapper, so the correct version of Gradle is used automatically. This is not an option for Linux distributions and is not an option for many people using them. We need to be able to produce a build with an all local toolchain. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From cnewland at chrisnewland.com Tue Dec 19 22:49:26 2017 From: cnewland at chrisnewland.com (Chris Newland) Date: Tue, 19 Dec 2017 22:49:26 -0000 Subject: Building OpenJFX. In-Reply-To: References: Message-ID: Hi Phil, Would it be possible to update the Windows build instructions? Getting VS10 and SDKs from 2010 to work on a Windows 10 build machine isn't much fun. Thanks, Chris On Tue, December 19, 2017 20:11, Phil Race wrote: > In the "innovation" email thread it was suggested that one obstacle to > getting involved and contributing to OpenJFX is just building it. > > So what are the top one or two pain points with building OpenJFX today ? > > > - Insufficient or out-dated build docs ? > - Tool-chain configuration problems - platform-specific or otherwise ? > - Needing to do a JDK build as well (JDK 9 and later) ? > - Something else ? > > > And having identified your pain point(s), what do you think would be a > solution ? > > -phil. > > From kevin.rushforth at oracle.com Tue Dec 19 22:51:04 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Dec 2017 14:51:04 -0800 Subject: Building OpenJFX. In-Reply-To: <8A96BFCC-74D7-40D6-9CFF-3E3EEDDF37C6@gmail.com> References: <5A3981D7.3050201@oracle.com> <8A96BFCC-74D7-40D6-9CFF-3E3EEDDF37C6@gmail.com> Message-ID: <5A3997D8.7000806@oracle.com> > While I doubt such issues are ?real? I understand that you have to deal with Oracle lawyers. It might be worth asking again to see whether there are any concerns. If we can address them, then maybe this is the way to go. > Perhaps a solution then is to configure the wrapper via a setup step to run the wrapper task with any version of gradle that can handle it, then run the gradlew script that it generates. And if not, then this is good alternative. > What I would really like to see, and I know I?m asking for a lot, is the elimination of the Cygwin requirement and the use of the Gradle native plugin for the native code (maybe we can exclude WebKit from that for now) > You shouldn?t need Ant either. > Yeah, that would be a big task, but possibly worth someone looking into (as for myself, I consider Windows to be unusable without Cygwin as a developer, so it wouldn't occur to me to want to build on a system without it). Eliminating the need for ant would require some work to refactor the apps, but is conceptually easy. > It should be easy to build without WebKit and have pre-built WebKit binaries pulled in like any other dependency instead, based on a build property. E.g. gradlew -PusePrebuiltWebKit=true > We already have a mechanism to point to a (possibly early access) JDK to grab the binary from there (see the STUB_RUNTIME variable). It wouldn't be too hard to extend that. Thanks for the suggestions. -- Kevin Scott Palmer wrote: > The project should be configured to use the Gradle Wrapper, so the correct version of Gradle is used automatically. > https://docs.gradle.org/current/userguide/gradle_wrapper.html > > There was some concern about checking in the gradle-wrapper.jar file, and potential licensing issues. While I doubt such issues are ?real? I understand that you have to deal with Oracle lawyers. Perhaps a solution then is to configure the wrapper via a setup step to run the wrapper task with any version of gradle that can handle it, then run the gradlew script that it generates. > > e.g. > build.gradle contains: > task wrapper(type: Wrapper) { > gradleVersion = '4.3' > } > > one-time setup: > gradle wrapper > > run the build: > gradlew > > Gradle bumps should be able to happen any time without causing issues. Gradle becomes just another dependency that is automatically fetched. A simple check to make sure the Gradle version is okay can be coded into the build script, e.g. something like: > > def blessed_gradle_version = '4.3' > task wrapper(type: Wrapper) { > gradleVersion = blessed_gradle_version > } > if (project.gradle.gradleVersion != blessed_gradle_version) { > println "Build expects ${blessed_gradle_version} but found ${project.gradle.gradleVersion}\n Run 'gradle wrapper', then use 'gradlew'" > } else { > apply from: 'real_build.gradle' > } > > Gradle incompatibilities should be rare anyway. > > What I would really like to see, and I know I?m asking for a lot, is the elimination of the Cygwin requirement and the use of the Gradle native plugin for the native code (maybe we can exclude WebKit from that for now) > You shouldn?t need Ant either. > > It should be easy to build without WebKit and have pre-built WebKit binaries pulled in like any other dependency instead, based on a build property. E.g. gradlew -PusePrebuiltWebKit=true > > Regards, > > Scott > > >> On Dec 19, 2017, at 4:17 PM, Kevin Rushforth wrote: >> >> Building WebKit is challenging, to be sure. I hope to enlist the help of some of our WebKit team members to review (and contribute to) update build instructions to help make it a little less painful, but it is still a challenge. >> >> As for the moving version of gradle, we so far have settled on a specific version for each release family: gradle 1.8 for JDK 8u, 3.1 for JDK 9, and 4.3 for JDK 10. We don't tend to bump it. >> >> Thanks for the feedback. >> >> -- Kevin >> >> >> Mario Torre wrote: >> >>> For me the most intricate part is about building the webkit based >>> code, especially on RHEL/CentOS. I admit I didn't try with the very >>> latest code drop though. The moving version of Gradle is also an >>> issue, since we try to use a stable toolchain on those OSes. >>> >>> Cheers, >>> Mario >>> >>> 2017-12-19 21:11 GMT+01:00 Phil Race : >>> >>> >>>> In the "innovation" email thread it was suggested that one obstacle to >>>> getting involved and contributing to OpenJFX is just building it. >>>> >>>> So what are the top one or two pain points with building OpenJFX today ? >>>> >>>> - Insufficient or out-dated build docs ? >>>> - Tool-chain configuration problems - platform-specific or otherwise ? >>>> - Needing to do a JDK build as well (JDK 9 and later) ? >>>> - Something else ? >>>> >>>> And having identified your pain point(s), what do you think would be a >>>> solution ? >>>> >>>> -phil. >>>> From swpalmer at gmail.com Tue Dec 19 22:53:18 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 19 Dec 2017 17:53:18 -0500 Subject: Building OpenJFX. In-Reply-To: References: <5A3981D7.3050201@oracle.com> <8A96BFCC-74D7-40D6-9CFF-3E3EEDDF37C6@gmail.com> Message-ID: > On Dec 19, 2017, at 5:13 PM, Mario Torre wrote: > > 2017-12-19 23:04 GMT+01:00 Scott Palmer : >> The project should be configured to use the Gradle Wrapper, so the correct version of Gradle is used automatically. > > This is not an option for Linux distributions and is not an option for > many people using them. We need to be able to produce a build with an > all local toolchain. The availability of the Gradle Wrapper does not mean you have to use it though. It would be helpful for those that can use it, at least if they suspected a Gradle incompatibility to be contributing to their builds problems. I have found that most Gradle versions since 3.x have worked fine on my projects without requiring any tweaks. Regards, Scott From kevin.rushforth at oracle.com Tue Dec 19 22:53:47 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Dec 2017 14:53:47 -0800 Subject: Building OpenJFX. In-Reply-To: References: Message-ID: <5A39987B.9070103@oracle.com> Yes, if I do nothing else before Christmas I will update the per-platform instructions for the three platforms (especially Windows) to be current. For Windows, the current compiler is VS 2017. -- Kevin Chris Newland wrote: > Hi Phil, > > Would it be possible to update the Windows build instructions? Getting > VS10 and SDKs from 2010 to work on a Windows 10 build machine isn't much > fun. > > Thanks, > > Chris > > > > On Tue, December 19, 2017 20:11, Phil Race wrote: > >> In the "innovation" email thread it was suggested that one obstacle to >> getting involved and contributing to OpenJFX is just building it. >> >> So what are the top one or two pain points with building OpenJFX today ? >> >> >> - Insufficient or out-dated build docs ? >> - Tool-chain configuration problems - platform-specific or otherwise ? >> - Needing to do a JDK build as well (JDK 9 and later) ? >> - Something else ? >> >> >> And having identified your pain point(s), what do you think would be a >> solution ? >> >> -phil. >> >> >> > > > From tom.schindl at bestsolution.at Tue Dec 19 22:56:40 2017 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 19 Dec 2017 23:56:40 +0100 Subject: Building OpenJFX. In-Reply-To: References: Message-ID: <2032ffb689945f89fe9e4c4a0b4c0185@bestsolution.at> Hi Phil, As I've went through the (painful) process of getting OpenJFX build on Windows (without the Webkit part) for a Build-Dummy like myself I've documented those steps 1 by 1 - https://github.com/BestSolution-at/openjfx-build/blob/master/README.md Tom Am 2017-12-19 21:11, schrieb Phil Race: > In the "innovation" email thread it was suggested that one obstacle to > getting involved and contributing to OpenJFX is just building it. > > So what are the top one or two pain points with building OpenJFX today > ? > > - Insufficient or out-dated build docs ? > - Tool-chain configuration problems - platform-specific or otherwise ? > - Needing to do a JDK build as well (JDK 9 and later) ? > - Something else ? > > And having identified your pain point(s), what do you think would be a > solution ? > > -phil. From kevin.rushforth at oracle.com Tue Dec 19 22:52:27 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Dec 2017 14:52:27 -0800 Subject: Building OpenJFX. In-Reply-To: References: <5A3981D7.3050201@oracle.com> <8A96BFCC-74D7-40D6-9CFF-3E3EEDDF37C6@gmail.com> Message-ID: <5A39982B.5080703@oracle.com> So making gradlew optional seems best then, if added. -- Kevin Mario Torre wrote: > 2017-12-19 23:04 GMT+01:00 Scott Palmer : > >> The project should be configured to use the Gradle Wrapper, so the correct version of Gradle is used automatically. >> > > This is not an option for Linux distributions and is not an option for > many people using them. We need to be able to produce a build with an > all local toolchain. > > Cheers, > Mario > From ajit.ghaisas at oracle.com Wed Dec 20 11:49:26 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 20 Dec 2017 03:49:26 -0800 (PST) Subject: [10] Review request : JDK-8193494 : Add a regression test case for JDK-8183100 changeset Message-ID: <67c19900-522e-4537-b19e-acef074008d4@default> Hi Kevin, Ambarish, Request you to review following test addition : Issue : https://bugs.openjdk.java.net/browse/JDK-8193494 Fix for JDK 10 : http://cr.openjdk.java.net/~aghaisas/fx/8193494/webrev.0/ Regards, Ajit From kevin.rushforth at oracle.com Wed Dec 20 18:13:23 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 20 Dec 2017 10:13:23 -0800 Subject: [11] Review request: 8193895: Change JavaFX release version to 11 Message-ID: <5A3AA843.7090603@oracle.com> Hi Phil, Can you review the following to bump the release version in jfx-dev to 11: https://bugs.openjdk.java.net/browse/JDK-8193895 http://cr.openjdk.java.net/~kcr/8193895/webrev.00/ Thanks. -- Kevin From kevin.rushforth at oracle.com Wed Dec 20 18:32:22 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 20 Dec 2017 10:32:22 -0800 Subject: [8u] Review request: 8193554: Disable failing fxpackager tests on macOS until JDK-8193232 is fixed Message-ID: <5A3AACB6.5020709@oracle.com> Hi Victor, Please review the following to disable the FX packager tests that temporarily fail on macOS 10.12: https://bugs.openjdk.java.net/browse/JDK-8193554 http://cr.openjdk.java.net/~kcr/8193554/webrev.00/ Thanks. -- Kevin From mike.ennen at gmail.com Wed Dec 20 20:49:04 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 20 Dec 2017 13:49:04 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <5A273A03.40902@oracle.com> References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> Message-ID: 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? 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 < >> 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 From kevin.rushforth at oracle.com Wed Dec 20 21:04:01 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 20 Dec 2017 13:04:01 -0800 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> Message-ID: <5A3AD041.8020301@oracle.com> 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 From mike.ennen at gmail.com Wed Dec 20 21:08:37 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 20 Dec 2017 14:08:37 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <5A3AD041.8020301@oracle.com> References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> Message-ID: 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 < > 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 From mike.ennen at gmail.com Wed Dec 20 21:37:11 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 20 Dec 2017 14:37:11 -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> Message-ID: 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/ >> 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 < >> 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 From kevin.rushforth at oracle.com Wed Dec 20 22:05:35 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 20 Dec 2017 14:05:35 -0800 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> Message-ID: <5A3ADEAF.6000903@oracle.com> 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 From victor.drozdov at oracle.com Thu Dec 21 01:17:33 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Wed, 20 Dec 2017 17:17:33 -0800 Subject: [10] Review request: 8189661: Regression of JDK-8095828 (though workaround does not work) Message-ID: <20bf41e9-2c01-8da8-6282-20b9982537f2@oracle.com> Alexander, Please review my changes for fixing the issue: "JDK-8189661: Regression of JDK-8095828 (though workaround does not work)" JIRA: https://bugs.openjdk.java.net/browse/JDK-8189661 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8189661/webrev.00/ --Victor From victor.drozdov at oracle.com Thu Dec 21 05:26:37 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Wed, 20 Dec 2017 21:26:37 -0800 Subject: [10] Review request: 8178951: "Module ... does not exist" is printed on console Message-ID: <8b987c5a-67cd-9595-bb92-f5fba99612b1@oracle.com> Alexander, Please review my changes for fixing the issue: " 8178951: "Module ... does not exist" is printed on console" JIRA: https://bugs.openjdk.java.net/browse/JDK-8178951 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8178951/webrev.00/ --Victor From mike.ennen at gmail.com Thu Dec 21 05:40:45 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 20 Dec 2017 22:40:45 -0700 Subject: Windows Build setupTools Message-ID: Some people were reporting that Windows builds are difficult to setup. I think this is due to the fact that the call to setupTools in buildSrc/win.gradle is in fact not working correctly. Invoking buildSrc/genVSproperties.bat directly prints the correct properties. However adding some debugging to setupTools it is clear that something is very wrong with it. This is the result: WINDOWS_VS_DEVENVDIR= WINDOWS_VS_DEVENVCMD=/VCExpress.exe WINDOWS_VS_VCINSTALLDIR= WINDOWS_VS_VSINSTALLDIR= WINDOWS_VS_MSVCDIR= WINDOWS_VS_INCLUDE= WINDOWS_VS_LIB= WINDOWS_VS_LIBPATH= WINDOWS_VS_PATH=; WINDOWS_VS_VER=120 WINDOWS_SDK_DIR= WINDOWS_SDK_VERSION= This is the reason people are needing to hard-code values for the properties below the call to setupTools. I am trying to debug what is actually wrong with setupTools but so far not making much progress. I tried this on my local Windows 10 machine and Appveyor VMs and the result is the same. I also read at least two mails in this list about needing to hard-code the properties, I am assuming it is for the same reason. I will try and figure out the reason but wanted to at least make this issue more concrete. -- Michael Ennen From tom.schindl at bestsolution.at Thu Dec 21 08:04:40 2017 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 21 Dec 2017 09:04:40 +0100 Subject: Windows Build setupTools In-Reply-To: References: Message-ID: <40007848-23dd-c5ef-8137-0c7965f67cff@bestsolution.at> Hi Michael, I did not had to setup any special variables and documented my steps at https://github.com/BestSolution-at/openjfx-build. I had trouble myself initially but the reason was that I ran the "gradle sdk" command from within a MSDOS-Shell but you really need to run it within cygwin. Tom On 21.12.17 06:40, Michael Ennen wrote: > Some people were reporting that Windows builds are difficult to setup. > I think this is due to the fact that the call to setupTools in > buildSrc/win.gradle > is in fact not working correctly. > > Invoking buildSrc/genVSproperties.bat directly prints the correct > properties. > > However adding some debugging to setupTools it is clear that something is > very wrong > with it. This is the result: > > WINDOWS_VS_DEVENVDIR= > WINDOWS_VS_DEVENVCMD=/VCExpress.exe > WINDOWS_VS_VCINSTALLDIR= > WINDOWS_VS_VSINSTALLDIR= > WINDOWS_VS_MSVCDIR= > WINDOWS_VS_INCLUDE= > WINDOWS_VS_LIB= > WINDOWS_VS_LIBPATH= > WINDOWS_VS_PATH=; > WINDOWS_VS_VER=120 > WINDOWS_SDK_DIR= > WINDOWS_SDK_VERSION= > > This is the reason people are needing to hard-code values for the properties > below the call to setupTools. > > I am trying to debug what is actually wrong with setupTools but so far not > making much > progress. I tried this on my local Windows 10 machine and Appveyor VMs and > the result > is the same. I also read at least two mails in this list about needing to > hard-code the > properties, I am assuming it is for the same reason. > > I will try and figure out the reason but wanted to at least make this issue > more concrete. > From mike.ennen at gmail.com Thu Dec 21 08:08:59 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Thu, 21 Dec 2017 01:08:59 -0700 Subject: Windows Build setupTools In-Reply-To: <40007848-23dd-c5ef-8137-0c7965f67cff@bestsolution.at> References: <40007848-23dd-c5ef-8137-0c7965f67cff@bestsolution.at> Message-ID: Thanks for the tip, Tom. I understand that Cygwin is a dependency of building on Windows but didn't know that the properties are only configured on a cygwin shell. I have a pseudo-goal of removing the Cygwin dependency from building OpenJFX on Windows and I wonder why Cygwin is necessary for setupTools to work? I see other obvious places in the build files that would only work on Cygwin, but am unclear as to why the properties would not be set in cmd.exe or Powershell. Thanks again for the clarification. On Thu, Dec 21, 2017 at 1:04 AM, Tom Schindl wrote: > Hi Michael, > > I did not had to setup any special variables and documented my steps at > https://github.com/BestSolution-at/openjfx-build. > > I had trouble myself initially but the reason was that I ran the "gradle > sdk" command from within a MSDOS-Shell but you really need to run it within > cygwin. > > Tom > > > On 21.12.17 06:40, Michael Ennen wrote: > >> Some people were reporting that Windows builds are difficult to setup. >> I think this is due to the fact that the call to setupTools in >> buildSrc/win.gradle >> is in fact not working correctly. >> >> Invoking buildSrc/genVSproperties.bat directly prints the correct >> properties. >> >> However adding some debugging to setupTools it is clear that something is >> very wrong >> with it. This is the result: >> >> WINDOWS_VS_DEVENVDIR= >> WINDOWS_VS_DEVENVCMD=/VCExpress.exe >> WINDOWS_VS_VCINSTALLDIR= >> WINDOWS_VS_VSINSTALLDIR= >> WINDOWS_VS_MSVCDIR= >> WINDOWS_VS_INCLUDE= >> WINDOWS_VS_LIB= >> WINDOWS_VS_LIBPATH= >> WINDOWS_VS_PATH=; >> WINDOWS_VS_VER=120 >> WINDOWS_SDK_DIR= >> WINDOWS_SDK_VERSION= >> >> This is the reason people are needing to hard-code values for the >> properties >> below the call to setupTools. >> >> I am trying to debug what is actually wrong with setupTools but so far not >> making much >> progress. I tried this on my local Windows 10 machine and Appveyor VMs and >> the result >> is the same. I also read at least two mails in this list about needing to >> hard-code the >> properties, I am assuming it is for the same reason. >> >> I will try and figure out the reason but wanted to at least make this >> issue >> more concrete. >> >> -- Michael Ennen From mike.ennen at gmail.com Thu Dec 21 08:26:10 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Thu, 21 Dec 2017 01:26:10 -0700 Subject: Windows Build setupTools In-Reply-To: References: <40007848-23dd-c5ef-8137-0c7965f67cff@bestsolution.at> Message-ID: Ah I see now - the properties were not being re-generated simply because the file windows_tools.properties already existed and "gradle clean" was not working because I'm not on Cygwin. Sorry for the noise. On Thu, Dec 21, 2017 at 1:08 AM, Michael Ennen wrote: > Thanks for the tip, Tom. I understand that Cygwin is a dependency of > building on Windows but didn't > know that the properties are only configured on a cygwin shell. > > I have a pseudo-goal of removing the Cygwin dependency from building > OpenJFX on Windows and > I wonder why Cygwin is necessary for setupTools to work? I see other > obvious places in the build > files that would only work on Cygwin, but am unclear as to why the > properties would not be set > in cmd.exe or Powershell. > > Thanks again for the clarification. > > On Thu, Dec 21, 2017 at 1:04 AM, Tom Schindl > wrote: > >> Hi Michael, >> >> I did not had to setup any special variables and documented my steps at >> https://github.com/BestSolution-at/openjfx-build. >> >> I had trouble myself initially but the reason was that I ran the "gradle >> sdk" command from within a MSDOS-Shell but you really need to run it within >> cygwin. >> >> Tom >> >> >> On 21.12.17 06:40, Michael Ennen wrote: >> >>> Some people were reporting that Windows builds are difficult to setup. >>> I think this is due to the fact that the call to setupTools in >>> buildSrc/win.gradle >>> is in fact not working correctly. >>> >>> Invoking buildSrc/genVSproperties.bat directly prints the correct >>> properties. >>> >>> However adding some debugging to setupTools it is clear that something is >>> very wrong >>> with it. This is the result: >>> >>> WINDOWS_VS_DEVENVDIR= >>> WINDOWS_VS_DEVENVCMD=/VCExpress.exe >>> WINDOWS_VS_VCINSTALLDIR= >>> WINDOWS_VS_VSINSTALLDIR= >>> WINDOWS_VS_MSVCDIR= >>> WINDOWS_VS_INCLUDE= >>> WINDOWS_VS_LIB= >>> WINDOWS_VS_LIBPATH= >>> WINDOWS_VS_PATH=; >>> WINDOWS_VS_VER=120 >>> WINDOWS_SDK_DIR= >>> WINDOWS_SDK_VERSION= >>> >>> This is the reason people are needing to hard-code values for the >>> properties >>> below the call to setupTools. >>> >>> I am trying to debug what is actually wrong with setupTools but so far >>> not >>> making much >>> progress. I tried this on my local Windows 10 machine and Appveyor VMs >>> and >>> the result >>> is the same. I also read at least two mails in this list about needing to >>> hard-code the >>> properties, I am assuming it is for the same reason. >>> >>> I will try and figure out the reason but wanted to at least make this >>> issue >>> more concrete. >>> >>> > > > -- > Michael Ennen > -- Michael Ennen From javafx at use.startmail.com Thu Dec 21 17:14:46 2017 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Thu, 21 Dec 2017 12:14:46 -0500 Subject: Windows Build setupTools In-Reply-To: References: <40007848-23dd-c5ef-8137-0c7965f67cff@bestsolution.at> Message-ID: <418c4f6ac97ef8534996153df508bc88.startmail@www.startmail.com> I did not try Tom's build instructions however I can contribute that having Cygwin on Windows 7 and following the build instructions as posted on the JavaFX build instructions page is not suffcient to result in a successful build.? The exact error messages I was receiving I posted earlier . ? On Thursday, December 21, 2017 3:08 AM, Michael Ennen wrote: ? > Thanks for the tip, Tom. I understand that Cygwin is a dependency of > building on Windows but didn't > know that the properties are only configured on a cygwin shell. > > I have a pseudo-goal of removing the Cygwin dependency from building > OpenJFX on Windows and > I wonder why Cygwin is necessary for setupTools to work? I see other > obvious places in the build > files that would only work on Cygwin, but am unclear as to why the > properties would not be set > in cmd.exe or Powershell. > > Thanks again for the clarification. > > On Thu, Dec 21, 2017 at 1:04 AM, Tom Schindl > > wrote: > ? >> Hi Michael, >> >> I did not had to setup any special variables and documented my steps >> at >> https://github.com/BestSolution-at/openjfx-build. >> >> I had trouble myself initially but the reason was that I ran the >> "gradle >> sdk" command from within a MSDOS-Shell but you really need to run it >> within >> cygwin. >> >> Tom >> >> >> On 21.12.17 06:40, Michael Ennen wrote: >> ? >>> Some people were reporting that Windows builds are difficult to >>> setup. >>> I think this is due to the fact that the call to setupTools in >>> buildSrc/win.gradle >>> is in fact not working correctly. >>> >>> Invoking buildSrc/genVSproperties.bat directly prints the correct >>> properties. >>> >>> However adding some debugging to setupTools it is clear that >>> something is >>> very wrong >>> with it. This is the result: >>> >>> WINDOWS_VS_DEVENVDIR= >>> WINDOWS_VS_DEVENVCMD=/VCExpress.exe >>> WINDOWS_VS_VCINSTALLDIR= >>> WINDOWS_VS_VSINSTALLDIR= >>> WINDOWS_VS_MSVCDIR= >>> WINDOWS_VS_INCLUDE= >>> WINDOWS_VS_LIB= >>> WINDOWS_VS_LIBPATH= >>> WINDOWS_VS_PATH=; >>> WINDOWS_VS_VER=120 >>> WINDOWS_SDK_DIR= >>> WINDOWS_SDK_VERSION= >>> >>> This is the reason people are needing to hard-code values for the >>> properties >>> below the call to setupTools. >>> >>> I am trying to debug what is actually wrong with setupTools but so >>> far not >>> making much >>> progress. I tried this on my local Windows 10 machine and Appveyor >>> VMs and >>> the result >>> is the same. I also read at least two mails in this list about >>> needing to >>> hard-code the >>> properties, I am assuming it is for the same reason. >>> >>> I will try and figure out the reason but wanted to at least make >>> this >>> issue >>> more concrete. >>> >>> ? > > -- > Michael Ennen From swpalmer at gmail.com Thu Dec 21 17:23:14 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 21 Dec 2017 12:23:14 -0500 Subject: Windows Build setupTools In-Reply-To: <418c4f6ac97ef8534996153df508bc88.startmail@www.startmail.com> References: <40007848-23dd-c5ef-8137-0c7965f67cff@bestsolution.at> <418c4f6ac97ef8534996153df508bc88.startmail@www.startmail.com> Message-ID: <5168C453-88EF-4D8E-B550-1F665D017462@gmail.com> One of the reasons I would like to eliminate Cygwin is that I believe it causes more problems than it is worth. For example, lat time I check, there was a bunch of code in the build scripts to hack paths because Cygwin apparently wants non-Windows paths on Windows. It?s the ?let?s pretend we aren?t on Windows and make a mess? strategy employed by Cygwin that I find counter-productive. (As a developer, I do like having common Un*x tools installed, but I prefer Windows ports of those tools that understand how to properly run on Windows instead of creating some virtual unix environment that doesn?t quite fit.) I suspect a lot more build logic could be done within the Gradle scripts rather than using external tools. That would result in a more portable build experience with less places for things to go wrong. Regards, Scott > On Dec 21, 2017, at 12:14 PM, javafx at use.startmail.com wrote: > > I did not try Tom's build instructions however I can contribute that having Cygwin on Windows 7 and following the build instructions as posted on the JavaFX build instructions page is not suffcient to result in a successful build. > > The exact error messages I was receiving I posted earlier . > > > On Thursday, December 21, 2017 3:08 AM, Michael Ennen wrote: > >> Thanks for the tip, Tom. I understand that Cygwin is a dependency of >> building on Windows but didn't >> know that the properties are only configured on a cygwin shell. >> I have a pseudo-goal of removing the Cygwin dependency from building >> OpenJFX on Windows and >> I wonder why Cygwin is necessary for setupTools to work? I see other >> obvious places in the build >> files that would only work on Cygwin, but am unclear as to why the >> properties would not be set >> in cmd.exe or Powershell. >> Thanks again for the clarification. >> On Thu, Dec 21, 2017 at 1:04 AM, Tom Schindl >> wrote: >> >>> Hi Michael, >>> I did not had to setup any special variables and documented my steps at >>> https://github.com/BestSolution-at/openjfx-build. >>> I had trouble myself initially but the reason was that I ran the "gradle >>> sdk" command from within a MSDOS-Shell but you really need to run it within >>> cygwin. >>> Tom >>> On 21.12.17 06:40, Michael Ennen wrote: >>> >>>> Some people were reporting that Windows builds are difficult to setup. >>>> I think this is due to the fact that the call to setupTools in >>>> buildSrc/win.gradle >>>> is in fact not working correctly. >>>> Invoking buildSrc/genVSproperties.bat directly prints the correct >>>> properties. >>>> However adding some debugging to setupTools it is clear that something is >>>> very wrong >>>> with it. This is the result: >>>> WINDOWS_VS_DEVENVDIR= >>>> WINDOWS_VS_DEVENVCMD=/VCExpress.exe >>>> WINDOWS_VS_VCINSTALLDIR= >>>> WINDOWS_VS_VSINSTALLDIR= >>>> WINDOWS_VS_MSVCDIR= >>>> WINDOWS_VS_INCLUDE= >>>> WINDOWS_VS_LIB= >>>> WINDOWS_VS_LIBPATH= >>>> WINDOWS_VS_PATH=; >>>> WINDOWS_VS_VER=120 >>>> WINDOWS_SDK_DIR= >>>> WINDOWS_SDK_VERSION= >>>> This is the reason people are needing to hard-code values for the >>>> properties >>>> below the call to setupTools. >>>> I am trying to debug what is actually wrong with setupTools but so far not >>>> making much >>>> progress. I tried this on my local Windows 10 machine and Appveyor VMs and >>>> the result >>>> is the same. I also read at least two mails in this list about needing to >>>> hard-code the >>>> properties, I am assuming it is for the same reason. >>>> I will try and figure out the reason but wanted to at least make this >>>> issue >>>> more concrete. >>>> >> -- >> Michael Ennen From kevin.rushforth at oracle.com Thu Dec 21 18:24:40 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 21 Dec 2017 10:24:40 -0800 Subject: [8u] Review request: 8178275: Ensemble: Upgrade version of Lucene to 7.1.0 Message-ID: <5A3BFC68.4040902@oracle.com> Hi Phil, I request a review to backport JDK-8178275 to 8u-dev. The backport was straight-forward. https://bugs.openjdk.java.net/browse/JDK-8178275 http://cr.openjdk.java.net/~kcr/8178275/8u/webrev.00/ Thanks. -- Kevin From kevin.rushforth at oracle.com Fri Dec 22 00:53:08 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 21 Dec 2017 16:53:08 -0800 Subject: [10] Review request: 8188314: Fix typos in FX API docs Message-ID: <5A3C5774.8050302@oracle.com> I'm sending this review on behalf of Jon Gibbons who provided the fix for these javadoc errors: https://bugs.openjdk.java.net/browse/JDK-8188314 http://cr.openjdk.java.net/~jjg/8188314/webrev.00/ -- Kevin From victor.drozdov at oracle.com Fri Dec 22 01:41:00 2017 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Thu, 21 Dec 2017 17:41:00 -0800 Subject: [10] Review request: 8194040: "javapackager -help" doesn't display new option "-singleton" Message-ID: <4313bdba-def6-1d8e-7c08-96e7766f760b@oracle.com> Kevin, Please review my changes for fixing the issue: "8194040: "javapackager -help" doesn't display new option "-singleton"" JIRA: https://bugs.openjdk.java.net/browse/JDK-8194040 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8194040/webrev.00/ --Victor From prem.balakrishnan at oracle.com Fri Dec 22 11:26:39 2017 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Fri, 22 Dec 2017 03:26:39 -0800 (PST) Subject: [11] Review Request: JDK-8190411 NPE in SliderSkin:140 if Slider.Tooltip.autohide is true Message-ID: Hi Kevin, Ajit Request you to review following fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8190411 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/fx/8190411/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/fx/8190411/webrev.00/ Regards, Prem From ambarish.rapte at oracle.com Fri Dec 22 16:26:43 2017 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Fri, 22 Dec 2017 08:26:43 -0800 (PST) Subject: RFR : JDK-8192056 : Memory leak when removing javafx.scene.shape.Sphere-objects from a group or container Message-ID: <860459ae-30ae-4210-8c2b-7cd31b559e34@default> Hi Kevin & Ajit, Request you to review this fix Issue: https://bugs.openjdk.java.net/browse/JDK-8192056 Webrev: http://cr.openjdk.java.net/~arapte/fx/8192056/webrev.02 Regards, Ambarish From kevin.rushforth at oracle.com Fri Dec 22 18:13:29 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 22 Dec 2017 10:13:29 -0800 Subject: Updated OpenJFX build instructions In-Reply-To: <5A3D4AE0.1070006@oracle.com> References: <5A3D4AE0.1070006@oracle.com> Message-ID: <5A3D4B49.4040903@oracle.com> [resend with typo fixed in Subject line] I did a first pass over the build instructions on the OpenJFX Wiki [1]. I think I cleaned up the worst of the inaccuracies, and added some information that will make it easier to build. I'm not the best person to see whether anything important is missing, though. Someone less familiar with the build should look it over and let me know what I've missed. I won't be able to get back to this until after the holidays and after JDK 10 RDP1 is over, but will take another pass at it then and incorporate the feedback. -- Kevin [1] https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX From kevin.rushforth at oracle.com Fri Dec 22 18:11:44 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 22 Dec 2017 10:11:44 -0800 Subject: Updated OpenJFX buld instructions Message-ID: <5A3D4AE0.1070006@oracle.com> I did a first pass over the build instructions on the OpenJFX Wiki [1]. I think I cleaned up the worst of the inaccuracies, and added some information that will make it easier to build. I'm not the best person to see whether anything important is missing, though. Someone less familiar with the build should look it over and let me know what I've missed. I won't be able to get back to this until after the holidays and after JDK 10 RDP1 is over, but will take another pass at it then and incorporate the feedback. -- Kevin [1] https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX From mike.ennen at gmail.com Fri Dec 22 20:14:36 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 22 Dec 2017 13:14:36 -0700 Subject: Updated OpenJFX build instructions In-Reply-To: <5A3D4B49.4040903@oracle.com> References: <5A3D4AE0.1070006@oracle.com> <5A3D4B49.4040903@oracle.com> Message-ID: Thanks for taking the time to do this, Kevin. On Fri, Dec 22, 2017 at 11:13 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > [resend with typo fixed in Subject line] > > I did a first pass over the build instructions on the OpenJFX Wiki [1]. I > think I cleaned up the worst of the inaccuracies, and added some > information that will make it easier to build. > > I'm not the best person to see whether anything important is missing, > though. Someone less familiar with the build should look it over and let me > know what I've missed. I won't be able to get back to this until after the > holidays and after JDK 10 RDP1 is over, but will take another pass at it > then and incorporate the feedback. > > -- Kevin > > [1] https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX > > -- Michael Ennen From mike.ennen at gmail.com Fri Dec 22 21:57:02 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 22 Dec 2017 14:57:02 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <5A3ADEAF.6000903@oracle.com> References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> Message-ID: I have made quite a bit of good progress I think: https://github.com/brcolow/openjfx/commit/d92ef24101cf32dfc07b21bdcb575528d8a58eaf The public API is starting to look much cleaner: https://github.com/brcolow/openjfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java Still a lot to do. Currently I am running into a JNI UnsatisfiedLinkError for GtkRobot but I am unsure why: java.lang.UnsatisfiedLinkError: com.sun.glass.ui.gtk.GtkRobot.getScreenCapture(IIII[I)V at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getScreenCapture(Native Method) at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getPixelColor(GtkRobot.java:93) I have the following Java method in GtkRobot.java: @Override native protected void getScreenCapture(int x, int y, int width, int height, int[] data); Which is overriding the abstract method in Robot.java: protected abstract void getScreenCapture(int x, int y, int width, int height, int[] data); and it is implemented in GlassRobot.cpp thusly: /* * Class: com_sun_glass_ui_gtk_GtkRobot * Method: getScreenCapture * Signature: (IIII[I)V */ JNIEXPORT void JNICALL Java_com_sun_glass_ui_gtk_GtkRobot_1getScreenCapture (JNIEnv * env, jobject obj, jint x, jint y, jint width, jint height, jintArray data) { (void)obj; GdkPixbuf *screenshot, *tmp; GdkWindow *root_window = gdk_get_default_root_window(); tmp = glass_pixbuf_from_window(root_window, x, y, width, height); screenshot = gdk_pixbuf_add_alpha(tmp, FALSE, 0, 0, 0); g_object_unref(tmp); jint *pixels = (jint *)convert_BGRA_to_RGBA((int*)gdk_pixbuf_get_pixels(screenshot), width * 4, height); env->SetIntArrayRegion(data, 0, height * width, pixels); g_free(pixels); g_object_unref(screenshot); } Have I somehow messed up the signature? As you can see I removed one of the "_" prefixes to "1getScreenCapture" (which seemed to work for the other Robots) as necessary because the native method is no longer itself prefixed with "_". Thanks again. 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 < >> 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 From nlisker at gmail.com Sat Dec 23 02:04:48 2017 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 23 Dec 2017 04:04:48 +0200 Subject: Updated OpenJFX build instructions Message-ID: Thanks Kevin, I'm going through the process now on Win 10. A few things to note: - In the Platform Prerequisites/cygwin it says to make sure mercurial package is installed. Later, under Common Prerequisites/Mercurial it says "you can also install Mercurial as a cygwin package". It's not clear then if it's needed or optional and if it replaces or complements the other hg toolings. - The link to Tortoise should be https://tortoisehg.bitbucket.io (not .org). - Might be trivial but I would say it's worth noting that all commands listed there are to be ran in cygwin. - The hg clone command probably needs to have a note added about the destination folder. The problems starts after navigating to the /rt directory and executing 'gradle tasks' or `gradle projects`: $ gradle tasks :buildSrc:generateGrammarSource A problem was found with the configuration of task ':buildSrc:generateGrammarSource'. Registering invalid inputs and outputs via TaskInputs and TaskOutputs methods has been deprecated and is scheduled to be removed in Gradle 5.0. - Directory 'D:\rt\buildSrc\src\main\antlr' specified for property '$1' does not exist. :buildSrc:generateGrammarSource UP-TO-DATE :buildSrc:compileJava NO-SOURCE :buildSrc:compileGroovy UP-TO-DATE :buildSrc:processResources NO-SOURCE :buildSrc:classes UP-TO-DATE :buildSrc:jar UP-TO-DATE :buildSrc:assemble UP-TO-DATE :buildSrc:compileTestJava NO-SOURCE :buildSrc:compileTestGroovy NO-SOURCE :buildSrc:processTestResources NO-SOURCE :buildSrc:testClasses UP-TO-DATE :buildSrc:test NO-SOURCE :buildSrc:check UP-TO-DATE :buildSrc:build UP-TO-DATE FAILURE: Build failed with an exception. * Where: Script 'D:\rt\buildSrc\win.gradle' line: 93 * What went wrong: A problem occurred evaluating script. > FAIL: WINSDK_DIR not defined * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. * Get more help at https://help.gradle.org BUILD FAILED in 2s --- I did not install DirectX SDK. Also the output of the above commands in the instructions page seems out of date compared to the contents of the directory... or I messed up. Any ideas? > I did a first pass over the build instructions on the OpenJFX Wiki [1]. > I think I cleaned up the worst of the inaccuracies, and added some > information that will make it easier to build. > > I'm not the best person to see whether anything important is missing, > though. Someone less familiar with the build should look it over and let > me know what I've missed. I won't be able to get back to this until > after the holidays and after JDK 10 RDP1 is over, but will take another > pass at it then and incorporate the feedback. > > -- Kevin > > [1] https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX > From kevin.rushforth at oracle.com Sat Dec 23 02:14:14 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 22 Dec 2017 18:14:14 -0800 Subject: Updated OpenJFX build instructions In-Reply-To: References: Message-ID: <5A3DBBF6.3050208@oracle.com> Thanks for the feedback...I'll note it. As for the build failure, did you install Visual Studio 2017 and set the two env variables (VS150COMNTOOLS and MSVC_VER) to point to it? If so, then it should determine WINSDK_DIR without anything else needed. -- Kevin Nir Lisker wrote: > Thanks Kevin, > > I'm going through the process now on Win 10. > > A few things to note: > - In the Platform Prerequisites/cygwin it says to make sure mercurial > package is installed. Later, under Common Prerequisites/Mercurial it > says "you can also install Mercurial as a cygwin package". It's not > clear then if it's needed or optional and if it replaces or > complements the other hg toolings. > - The link to Tortoise should be https://tortoisehg.bitbucket.io (not > .org). > - Might be trivial but I would say it's worth noting that all commands > listed there are to be ran in cygwin. > - The hg clone command probably needs to have a note added about the > destination folder. > > The problems starts after navigating to the /rt directory and > executing 'gradle tasks' or `gradle projects`: > > $ gradle tasks > :buildSrc:generateGrammarSource > A problem was found with the configuration of task > ':buildSrc:generateGrammarSource'. Registering invalid inputs and > outputs via TaskInputs and TaskOutputs methods has been deprecated and > is scheduled to be removed in Gradle 5.0. > - Directory 'D:\rt\buildSrc\src\main\antlr' specified for property > '$1' does not exist. > :buildSrc:generateGrammarSource UP-TO-DATE > :buildSrc:compileJava NO-SOURCE > :buildSrc:compileGroovy UP-TO-DATE > :buildSrc:processResources NO-SOURCE > :buildSrc:classes UP-TO-DATE > :buildSrc:jar UP-TO-DATE > :buildSrc:assemble UP-TO-DATE > :buildSrc:compileTestJava NO-SOURCE > :buildSrc:compileTestGroovy NO-SOURCE > :buildSrc:processTestResources NO-SOURCE > :buildSrc:testClasses UP-TO-DATE > :buildSrc:test NO-SOURCE > :buildSrc:check UP-TO-DATE > :buildSrc:build UP-TO-DATE > > FAILURE: Build failed with an exception. > > * Where: > Script 'D:\rt\buildSrc\win.gradle' line: 93 > > * What went wrong: > A problem occurred evaluating script. > > FAIL: WINSDK_DIR not defined > > * Try: > Run with --stacktrace option to get the stack trace. Run with --info > or --debug option to get more log output. > > * Get more help at https://help.gradle.org > > BUILD FAILED in 2s > > --- > > I did not install DirectX SDK. Also the output of the above commands > in the instructions page seems out of date compared to the contents of > the directory... or I messed up. > > Any ideas? > > > > I did a first pass over the build instructions on the OpenJFX Wiki > [1]. > I think I cleaned up the worst of the inaccuracies, and added some > information that will make it easier to build. > > I'm not the best person to see whether anything important is missing, > though. Someone less familiar with the build should look it over > and let > me know what I've missed. I won't be able to get back to this until > after the holidays and after JDK 10 RDP1 is over, but will take > another > pass at it then and incorporate the feedback. > > -- Kevin > > [1] https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX > > From nlisker at gmail.com Sat Dec 23 03:30:27 2017 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 23 Dec 2017 05:30:27 +0200 Subject: Updated OpenJFX build instructions Message-ID: I did set them, but... if I set them in bash they disappear the next time I launch it, which made me think they are not being set properly for some reason even though they appear in `export -p` immediately after. Launching bash as admin didn't do anything (I thought write permissions issue). So I went to the /home/user/.bash_profile file and added the export declarations there. Now they appear on `export -p` properly every launch. I also did `gradle --stop` and `rm -rf build`, but `gradle clean` gives the same error. Otherwise, I also noticed that the folder VS150COMNTOOLS is pointing to does not exist. I downloaded today VS 2017 Community version 15.5.2 (which is what I set for MSVC_VER). This is as close as it gets: --- Nir at Nir-Desktop /cygdrive/c/Program Files (x86)/Microsoft Visual Studio/2017/Community $ dir Common7 Licenses MSBuild Team\ Tools Xml --- (no VC/Auxiliary/Build) Is that directory supposed to be created by some process, I needed to select some installation package for VS, or did something change from version 14.x to 15.x? Nir On Sat, Dec 23, 2017 at 4:14 AM, Kevin Rushforth wrote: > Thanks for the feedback...I'll note it. > > As for the build failure, did you install Visual Studio 2017 and set the > two env variables (VS150COMNTOOLS and MSVC_VER) to point to it? If so, then > it should determine WINSDK_DIR without anything else needed. > > -- Kevin > > > > Nir Lisker wrote: > > Thanks Kevin, > > I'm going through the process now on Win 10. > > A few things to note: > - In the Platform Prerequisites/cygwin it says to make sure mercurial > package is installed. Later, under Common Prerequisites/Mercurial it says > "you can also install Mercurial as a cygwin package". It's not clear then > if it's needed or optional and if it replaces or complements the other hg > toolings. > - The link to Tortoise should be https://tortoisehg.bitbucket.io (not > .org). > - Might be trivial but I would say it's worth noting that all commands > listed there are to be ran in cygwin. > - The hg clone command probably needs to have a note added about the > destination folder. > > The problems starts after navigating to the /rt directory and executing > 'gradle tasks' or `gradle projects`: > > $ gradle tasks > :buildSrc:generateGrammarSource > A problem was found with the configuration of task ':buildSrc:generateGrammarSource'. > Registering invalid inputs and outputs via TaskInputs and TaskOutputs > methods has been deprecated and is scheduled to be removed in Gradle 5.0. > - Directory 'D:\rt\buildSrc\src\main\antlr' specified for property '$1' > does not exist. > :buildSrc:generateGrammarSource UP-TO-DATE > :buildSrc:compileJava NO-SOURCE > :buildSrc:compileGroovy UP-TO-DATE > :buildSrc:processResources NO-SOURCE > :buildSrc:classes UP-TO-DATE > :buildSrc:jar UP-TO-DATE > :buildSrc:assemble UP-TO-DATE > :buildSrc:compileTestJava NO-SOURCE > :buildSrc:compileTestGroovy NO-SOURCE > :buildSrc:processTestResources NO-SOURCE > :buildSrc:testClasses UP-TO-DATE > :buildSrc:test NO-SOURCE > :buildSrc:check UP-TO-DATE > :buildSrc:build UP-TO-DATE > > FAILURE: Build failed with an exception. > > * Where: > Script 'D:\rt\buildSrc\win.gradle' line: 93 > > * What went wrong: > A problem occurred evaluating script. > > FAIL: WINSDK_DIR not defined > > * Try: > Run with --stacktrace option to get the stack trace. Run with --info or > --debug option to get more log output. > > * Get more help at https://help.gradle.org > > BUILD FAILED in 2s > > --- > > I did not install DirectX SDK. Also the output of the above commands in > the instructions page seems out of date compared to the contents of the > directory... or I messed up. > > Any ideas? > > > >> I did a first pass over the build instructions on the OpenJFX Wiki [1]. >> I think I cleaned up the worst of the inaccuracies, and added some >> information that will make it easier to build. >> >> I'm not the best person to see whether anything important is missing, >> though. Someone less familiar with the build should look it over and let >> me know what I've missed. I won't be able to get back to this until >> after the holidays and after JDK 10 RDP1 is over, but will take another >> pass at it then and incorporate the feedback. >> >> -- Kevin >> >> [1] https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX >> > From mike.ennen at gmail.com Sat Dec 23 05:51:25 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Fri, 22 Dec 2017 22:51:25 -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> Message-ID: I didn't realize "_1" is an escape character in JNI method naming and is only needed when the method has a "_" in its' name. Nevermind! On Fri, Dec 22, 2017 at 2:57 PM, Michael Ennen wrote: > I have made quite a bit of good progress I think: > > https://github.com/brcolow/openjfx/commit/d92ef24101cf32dfc07b21bdcb5755 > 28d8a58eaf > > The public API is starting to look much cleaner: > > https://github.com/brcolow/openjfx/blob/master/modules/ > javafx.graphics/src/main/java/javafx/scene/robot/Robot.java > > Still a lot to do. > > Currently I am running into a JNI UnsatisfiedLinkError for GtkRobot but I > am unsure why: > > java.lang.UnsatisfiedLinkError: com.sun.glass.ui.gtk.GtkRobot. > getScreenCapture(IIII[I)V > at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getScreenCapture(Native > Method) > at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getPixelColor( > GtkRobot.java:93) > > I have the following Java method in GtkRobot.java: > > @Override native protected void getScreenCapture(int x, int y, int width, > int height, int[] data); > > Which is overriding the abstract method in Robot.java: > > protected abstract void getScreenCapture(int x, int y, int width, int > height, int[] data); > > and it is implemented in GlassRobot.cpp thusly: > > /* > * Class: com_sun_glass_ui_gtk_GtkRobot > * Method: getScreenCapture > * Signature: (IIII[I)V > */ > JNIEXPORT void JNICALL Java_com_sun_glass_ui_gtk_ > GtkRobot_1getScreenCapture > (JNIEnv * env, jobject obj, jint x, jint y, jint width, jint height, > jintArray data) > { > (void)obj; > > GdkPixbuf *screenshot, *tmp; > GdkWindow *root_window = gdk_get_default_root_window(); > > tmp = glass_pixbuf_from_window(root_window, x, y, width, height); > screenshot = gdk_pixbuf_add_alpha(tmp, FALSE, 0, 0, 0); > g_object_unref(tmp); > > jint *pixels = (jint *)convert_BGRA_to_RGBA((int*) > gdk_pixbuf_get_pixels(screenshot), width * 4, height); > env->SetIntArrayRegion(data, 0, height * width, pixels); > g_free(pixels); > > g_object_unref(screenshot); > } > > Have I somehow messed up the signature? As you can see I removed one of > the "_" prefixes > to "1getScreenCapture" (which seemed to work for the other Robots) as > necessary because > the native method is no longer itself prefixed with "_". > > Thanks again. > > 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 Sat Dec 23 14:29:10 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 23 Dec 2017 06:29:10 -0800 Subject: Updated OpenJFX build instructions In-Reply-To: References: Message-ID: <5A3E6836.50907@oracle.com> It's quite possible that Microsoft changed something in their installation of Visual Studio. We are relying on the VC/Auxiliary/Build directory being created as part of the (default) Visual Studio installation so we can find vcvars32.bat. You might look in your installation and see whether that file exists somewhere else. If it does, then point VS150COMNTOOLS to the directory containing that bat file. I won't have any more time to look at it this until after the new year...maybe someone else on the list can help? -- Kevin Nir Lisker wrote: > I did set them, but... if I set them in bash they disappear the next > time I launch it, which made me think they are not being set properly > for some reason even though they appear in `export -p` immediately > after. Launching bash as admin didn't do anything (I thought write > permissions issue). > > So I went to the /home/user/.bash_profile file and added the export > declarations there. Now they appear on `export -p` properly every > launch. I also did `gradle --stop` and `rm -rf build`, but `gradle > clean` gives the same error. > > Otherwise, I also noticed that the folder VS150COMNTOOLS is pointing > to does not exist. I downloaded today VS 2017 Community version 15.5.2 > (which is what I set for MSVC_VER). This is as close as it gets: > > --- > Nir at Nir-Desktop /cygdrive/c/Program Files (x86)/Microsoft Visual > Studio/2017/Community > $ dir > Common7 Licenses MSBuild Team\ Tools Xml > --- > > (no VC/Auxiliary/Build) > > Is that directory supposed to be created by some process, I needed to > select some installation package for VS, or did something change from > version 14.x to 15.x? > > Nir > > On Sat, Dec 23, 2017 at 4:14 AM, Kevin Rushforth > > wrote: > > Thanks for the feedback...I'll note it. > > As for the build failure, did you install Visual Studio 2017 and > set the two env variables (VS150COMNTOOLS and MSVC_VER) to point > to it? If so, then it should determine WINSDK_DIR without anything > else needed. > > -- Kevin > > > > Nir Lisker wrote: >> Thanks Kevin, >> >> I'm going through the process now on Win 10. >> >> A few things to note: >> - In the Platform Prerequisites/cygwin it says to make sure >> mercurial package is installed. Later, under Common >> Prerequisites/Mercurial it says "you can also install Mercurial >> as a cygwin package". It's not clear then if it's needed or >> optional and if it replaces or complements the other hg toolings. >> - The link to Tortoise should be https://tortoisehg.bitbucket.io >> (not .org). >> - Might be trivial but I would say it's worth noting that all >> commands listed there are to be ran in cygwin. >> - The hg clone command probably needs to have a note added about >> the destination folder. >> >> The problems starts after navigating to the /rt directory and >> executing 'gradle tasks' or `gradle projects`: >> >> $ gradle tasks >> :buildSrc:generateGrammarSource >> A problem was found with the configuration of task >> ':buildSrc:generateGrammarSource'. Registering invalid inputs and >> outputs via TaskInputs and TaskOutputs methods has been >> deprecated and is scheduled to be removed in Gradle 5.0. >> - Directory 'D:\rt\buildSrc\src\main\antlr' specified for >> property '$1' does not exist. >> :buildSrc:generateGrammarSource UP-TO-DATE >> :buildSrc:compileJava NO-SOURCE >> :buildSrc:compileGroovy UP-TO-DATE >> :buildSrc:processResources NO-SOURCE >> :buildSrc:classes UP-TO-DATE >> :buildSrc:jar UP-TO-DATE >> :buildSrc:assemble UP-TO-DATE >> :buildSrc:compileTestJava NO-SOURCE >> :buildSrc:compileTestGroovy NO-SOURCE >> :buildSrc:processTestResources NO-SOURCE >> :buildSrc:testClasses UP-TO-DATE >> :buildSrc:test NO-SOURCE >> :buildSrc:check UP-TO-DATE >> :buildSrc:build UP-TO-DATE >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'D:\rt\buildSrc\win.gradle' line: 93 >> >> * What went wrong: >> A problem occurred evaluating script. >> > FAIL: WINSDK_DIR not defined >> >> * Try: >> Run with --stacktrace option to get the stack trace. Run with >> --info or --debug option to get more log output. >> >> * Get more help at https://help.gradle.org >> >> BUILD FAILED in 2s >> >> --- >> >> I did not install DirectX SDK. Also the output of the above >> commands in the instructions page seems out of date compared to >> the contents of the directory... or I messed up. >> >> Any ideas? >> >> >> >> I did a first pass over the build instructions on the OpenJFX >> Wiki [1]. >> I think I cleaned up the worst of the inaccuracies, and added >> some >> information that will make it easier to build. >> >> I'm not the best person to see whether anything important is >> missing, >> though. Someone less familiar with the build should look it >> over and let >> me know what I've missed. I won't be able to get back to this >> until >> after the holidays and after JDK 10 RDP1 is over, but will >> take another >> pass at it then and incorporate the feedback. >> >> -- Kevin >> >> [1] >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX >> >> > From kevin.rushforth at oracle.com Sat Dec 23 14:48:18 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 23 Dec 2017 06:48:18 -0800 Subject: REMINDER: Deadline for FX fixes for JDK 10 RDP1 Message-ID: <5A3E6CB2.5080501@oracle.com> As a reminder, the deadline for getting FX fixes in during RDP1 of JDK 10 is Monday, January 15, 2018 (end of the day Pacific time) [1]. To be more precise, fixes need to be reviewed, committed, and pushed to openjfx/10-dev/rt no later than 23:59 Pacific Time on that day. I note that January 15 is a US public holiday, so for practical purposes, you will need to have your fixes reviewed by Friday, January 12 in order to push before the deadline. Unless you have a very simple fix, please don't send your code review on January 12 and expect that it will be reviewed in time to meet the deadline. RDP2 formally starts on January 18, 2018, but given the FX integration schedule, we will be under RDP2 rules starting 00:00 on Tuesday, January 16, 2018. See the jdk10 project page [2] for all JDK 10 dates. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-December/021149.html [2] http://openjdk.java.net/projects/jdk/10/ From mike.ennen at gmail.com Sun Dec 24 01:00:33 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Sat, 23 Dec 2017 18:00: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> Message-ID: Kevin, You mentioned in your initial response that Jemmy would need to updated with any changes that result from moving Robot into the JavaFX public API. However, from what I can tell from a cursory glance, Jemmy seems to use "java.awt.Robot" and not the JavaFX Glass Robot API and thus no changes to Jemmy would be required after moving Robot to the JavaFX public API. Am I missing something? Thanks, happy holidays (not expecting a response for a while :) ). On Fri, Dec 22, 2017 at 10:51 PM, Michael Ennen wrote: > I didn't realize "_1" is an escape character in JNI method naming and is > only > needed when the method has a "_" in its' name. Nevermind! > > On Fri, Dec 22, 2017 at 2:57 PM, Michael Ennen > wrote: > >> I have made quite a bit of good progress I think: >> >> https://github.com/brcolow/openjfx/commit/d92ef24101cf32dfc0 >> 7b21bdcb575528d8a58eaf >> >> The public API is starting to look much cleaner: >> >> https://github.com/brcolow/openjfx/blob/master/modules/javaf >> x.graphics/src/main/java/javafx/scene/robot/Robot.java >> >> Still a lot to do. >> >> Currently I am running into a JNI UnsatisfiedLinkError for GtkRobot but I >> am unsure why: >> >> java.lang.UnsatisfiedLinkError: com.sun.glass.ui.gtk.GtkRobot. >> getScreenCapture(IIII[I)V >> at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getScreenCapture(Native >> Method) >> at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getPixelColor( >> GtkRobot.java:93) >> >> I have the following Java method in GtkRobot.java: >> >> @Override native protected void getScreenCapture(int x, int y, int width, >> int height, int[] data); >> >> Which is overriding the abstract method in Robot.java: >> >> protected abstract void getScreenCapture(int x, int y, int width, int >> height, int[] data); >> >> and it is implemented in GlassRobot.cpp thusly: >> >> /* >> * Class: com_sun_glass_ui_gtk_GtkRobot >> * Method: getScreenCapture >> * Signature: (IIII[I)V >> */ >> JNIEXPORT void JNICALL Java_com_sun_glass_ui_gtk_GtkR >> obot_1getScreenCapture >> (JNIEnv * env, jobject obj, jint x, jint y, jint width, jint height, >> jintArray data) >> { >> (void)obj; >> >> GdkPixbuf *screenshot, *tmp; >> GdkWindow *root_window = gdk_get_default_root_window(); >> >> tmp = glass_pixbuf_from_window(root_window, x, y, width, height); >> screenshot = gdk_pixbuf_add_alpha(tmp, FALSE, 0, 0, 0); >> g_object_unref(tmp); >> >> jint *pixels = (jint *)convert_BGRA_to_RGBA((int*)g >> dk_pixbuf_get_pixels(screenshot), width * 4, height); >> env->SetIntArrayRegion(data, 0, height * width, pixels); >> g_free(pixels); >> >> g_object_unref(screenshot); >> } >> >> Have I somehow messed up the signature? As you can see I removed one of >> the "_" prefixes >> to "1getScreenCapture" (which seemed to work for the other Robots) as >> necessary because >> the native method is no longer itself prefixed with "_". >> >> Thanks again. >> >> 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 Mon Dec 25 06:55:46 2017 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 25 Dec 2017 08:55:46 +0200 Subject: Updated OpenJFX build instructions In-Reply-To: <5A3E6836.50907@oracle.com> References: <5A3E6836.50907@oracle.com> Message-ID: Just as I was about to ask Santa for a successful build Iv'e managed to do it. Here are my conclusions for Win10 without WebKit: 1. vcvars32.bat VS 2017 does not create vcvars32.bat by default, some components need to be selected. I don't know which ones exactly, I think it's "VC++ 2017 v141 toolset (x86,x64)". The easiest way is to select the whole "Desktop development with C++" workload which installs ~5.5GB of libraries and IDE tools, which might or might not be useful. 2. MSVC_VER This variable is NOT the VS version, which for VS 2017 is 15.x. I don't know what that version specifies, but it needs to be the one under "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\$VERSION$". For me it was 14.12.25827. using the wrong version causes the build to fail during the task ":graphics:compileDecoraNativeShadersWin" with the cause that a file "cl.exe" cannot be found (there are 4 of these files under the above path, I don't remember which it was). 3. env variables (chapter 1) Cygwin converts the system variables on startup. Any vars that are required in addition need to be specified with `export`. The build instructions show to export JAVA_HOME, but later under Environment Variables it is set as a system env var. Additionally, for me, using `export` in cygwin did not save them and they had to be reentered on each launch. I still don't know why, gradle was not running. An alternative was to specify them under "/home/$USER$/.bash_profile" which is ran on startup, but on Windows there can be a conflict with the newline characters (\r\n vs \n) which messes up their definition. Eventually, I settled on just specifying them as system env vars. This has the advantage of not messing with slashes and quotes because Windows allows you to navigate to the file/folder and takes care of the path. Using `export -p` can verify that the paths are set correctly. 4. env variables (chapter 2) For required files or folders it will be easier to list them and ask for full paths instead of partial paths because at the end of the day this is what the build script wants. For example: - vcvars32.bat: "C:\Program Files (x86)\Microsoft Visual Studio\2017\$EDITION$\VC\Auxiliary\Build\vcvars32.bat" - cl.exe: root folder for all files "C:\Program Files (x86)\Microsoft Visual Studio\2017\$EDITION$\VC\Tools\MSVC\$VERSION$\bin" ... This bypasses installation details. It does require to change the build script though. Haven't set up anything else yet. Merry Christmas, Nir On Sat, Dec 23, 2017 at 4:29 PM, Kevin Rushforth wrote: > It's quite possible that Microsoft changed something in their installation > of Visual Studio. We are relying on the VC/Auxiliary/Build directory being > created as part of the (default) Visual Studio installation so we can find > vcvars32.bat. You might look in your installation and see whether that file > exists somewhere else. If it does, then point VS150COMNTOOLS to the > directory containing that bat file. > > I won't have any more time to look at it this until after the new > year...maybe someone else on the list can help? > > > -- Kevin > > > Nir Lisker wrote: > > I did set them, but... if I set them in bash they disappear the next time > I launch it, which made me think they are not being set properly for some > reason even though they appear in `export -p` immediately after. Launching > bash as admin didn't do anything (I thought write permissions issue). > > So I went to the /home/user/.bash_profile file and added the export > declarations there. Now they appear on `export -p` properly every launch. I > also did `gradle --stop` and `rm -rf build`, but `gradle clean` gives the > same error. > > Otherwise, I also noticed that the folder VS150COMNTOOLS is pointing to > does not exist. I downloaded today VS 2017 Community version 15.5.2 (which > is what I set for MSVC_VER). This is as close as it gets: > > --- > Nir at Nir-Desktop /cygdrive/c/Program Files (x86)/Microsoft Visual > Studio/2017/Community > $ dir > Common7 Licenses MSBuild Team\ Tools Xml > --- > > (no VC/Auxiliary/Build) > > Is that directory supposed to be created by some process, I needed to > select some installation package for VS, or did something change from > version 14.x to 15.x? > > Nir > > On Sat, Dec 23, 2017 at 4:14 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Thanks for the feedback...I'll note it. >> >> As for the build failure, did you install Visual Studio 2017 and set the >> two env variables (VS150COMNTOOLS and MSVC_VER) to point to it? If so, then >> it should determine WINSDK_DIR without anything else needed. >> >> -- Kevin >> >> >> >> Nir Lisker wrote: >> >> Thanks Kevin, >> >> I'm going through the process now on Win 10. >> >> A few things to note: >> - In the Platform Prerequisites/cygwin it says to make sure mercurial >> package is installed. Later, under Common Prerequisites/Mercurial it says >> "you can also install Mercurial as a cygwin package". It's not clear then >> if it's needed or optional and if it replaces or complements the other hg >> toolings. >> - The link to Tortoise should be https://tortoisehg.bitbucket.io (not >> .org). >> - Might be trivial but I would say it's worth noting that all commands >> listed there are to be ran in cygwin. >> - The hg clone command probably needs to have a note added about the >> destination folder. >> >> The problems starts after navigating to the /rt directory and executing >> 'gradle tasks' or `gradle projects`: >> >> $ gradle tasks >> :buildSrc:generateGrammarSource >> A problem was found with the configuration of task >> ':buildSrc:generateGrammarSource'. Registering invalid inputs and >> outputs via TaskInputs and TaskOutputs methods has been deprecated and is >> scheduled to be removed in Gradle 5.0. >> - Directory 'D:\rt\buildSrc\src\main\antlr' specified for property '$1' >> does not exist. >> :buildSrc:generateGrammarSource UP-TO-DATE >> :buildSrc:compileJava NO-SOURCE >> :buildSrc:compileGroovy UP-TO-DATE >> :buildSrc:processResources NO-SOURCE >> :buildSrc:classes UP-TO-DATE >> :buildSrc:jar UP-TO-DATE >> :buildSrc:assemble UP-TO-DATE >> :buildSrc:compileTestJava NO-SOURCE >> :buildSrc:compileTestGroovy NO-SOURCE >> :buildSrc:processTestResources NO-SOURCE >> :buildSrc:testClasses UP-TO-DATE >> :buildSrc:test NO-SOURCE >> :buildSrc:check UP-TO-DATE >> :buildSrc:build UP-TO-DATE >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'D:\rt\buildSrc\win.gradle' line: 93 >> >> * What went wrong: >> A problem occurred evaluating script. >> > FAIL: WINSDK_DIR not defined >> >> * Try: >> Run with --stacktrace option to get the stack trace. Run with --info or >> --debug option to get more log output. >> >> * Get more help at https://help.gradle.org >> >> BUILD FAILED in 2s >> >> --- >> >> I did not install DirectX SDK. Also the output of the above commands in >> the instructions page seems out of date compared to the contents of the >> directory... or I messed up. >> >> Any ideas? >> >> >> >>> I did a first pass over the build instructions on the OpenJFX Wiki [1]. >>> I think I cleaned up the worst of the inaccuracies, and added some >>> information that will make it easier to build. >>> >>> I'm not the best person to see whether anything important is missing, >>> though. Someone less familiar with the build should look it over and let >>> me know what I've missed. I won't be able to get back to this until >>> after the holidays and after JDK 10 RDP1 is over, but will take another >>> pass at it then and incorporate the feedback. >>> >>> -- Kevin >>> >>> [1] https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX >>> >> > From rajath.kamath at oracle.com Tue Dec 26 14:20:04 2017 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Tue, 26 Dec 2017 06:20:04 -0800 (PST) Subject: [11] Review Request - JDK-8088925: Non opaque background cause NumberFormatException Message-ID: <3c1bba54-2e0b-4969-a495-36709cf0b288@default> Hi Guru\Arun, Please review a fix for HTMLEditor. Details of the same mentioned in JBS: JBS : https://bugs.openjdk.java.net/browse/JDK-8088925 WebRev : http://cr.openjdk.java.net/~rkamath/8088925/webrev.00/ Thanks, Rajath From mike.ennen at gmail.com Wed Dec 27 04:35:36 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Tue, 26 Dec 2017 21:35:36 -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> Message-ID: I have completed what I would call a first draft of moving the Robot to JavaFX public API. This commit: https://github.com/brcolow/openjfx/commit/321f949575a201fe28a2ff79c9590daf8db375a8 Includes all the relevant changes necessary to move the glass robot into the public API. I have some other commits on that repository, but they are unrelated and not part of the Robot proposal at all. Except for the most recent commit: https://github.com/brcolow/openjfx/commit/e3250c95d36a467efd6002dc213cf27668b3f6e0 which explores adding support for the back/forward mouse buttons (JDK-8090930), also known as mouse buttons 4 and 5 to JavaFX. This is essentially independent from the Robot proposal except if there is interested in this and it (or something like it, or based on it), is merged then I can easily adapt the native robot implementations (GtkRobot, MonocleRobot, MacRobot, IOsRobot, and WinRobot) to support these additional mouse keys. Happy holidays all, Michael Ennen On Sat, Dec 23, 2017 at 6:00 PM, Michael Ennen wrote: > Kevin, > > You mentioned in your initial response that Jemmy would need to updated > with any changes > that result from moving Robot into the JavaFX public API. However, from > what I can tell > from a cursory glance, Jemmy seems to use "java.awt.Robot" and not the > JavaFX Glass > Robot API and thus no changes to Jemmy would be required after moving > Robot to the > JavaFX public API. > > Am I missing something? > > Thanks, happy holidays (not expecting a response for a while :) ). > > > > On Fri, Dec 22, 2017 at 10:51 PM, Michael Ennen > wrote: > >> I didn't realize "_1" is an escape character in JNI method naming and is >> only >> needed when the method has a "_" in its' name. Nevermind! >> >> On Fri, Dec 22, 2017 at 2:57 PM, Michael Ennen >> wrote: >> >>> I have made quite a bit of good progress I think: >>> >>> https://github.com/brcolow/openjfx/commit/d92ef24101cf32dfc0 >>> 7b21bdcb575528d8a58eaf >>> >>> The public API is starting to look much cleaner: >>> >>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>> >>> Still a lot to do. >>> >>> Currently I am running into a JNI UnsatisfiedLinkError for GtkRobot but >>> I am unsure why: >>> >>> java.lang.UnsatisfiedLinkError: com.sun.glass.ui.gtk.GtkRobot. >>> getScreenCapture(IIII[I)V >>> at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getScreenCapture(Native >>> Method) >>> at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getPixelColor( >>> GtkRobot.java:93) >>> >>> I have the following Java method in GtkRobot.java: >>> >>> @Override native protected void getScreenCapture(int x, int y, int >>> width, int height, int[] data); >>> >>> Which is overriding the abstract method in Robot.java: >>> >>> protected abstract void getScreenCapture(int x, int y, int width, int >>> height, int[] data); >>> >>> and it is implemented in GlassRobot.cpp thusly: >>> >>> /* >>> * Class: com_sun_glass_ui_gtk_GtkRobot >>> * Method: getScreenCapture >>> * Signature: (IIII[I)V >>> */ >>> JNIEXPORT void JNICALL Java_com_sun_glass_ui_gtk_GtkR >>> obot_1getScreenCapture >>> (JNIEnv * env, jobject obj, jint x, jint y, jint width, jint height, >>> jintArray data) >>> { >>> (void)obj; >>> >>> GdkPixbuf *screenshot, *tmp; >>> GdkWindow *root_window = gdk_get_default_root_window(); >>> >>> tmp = glass_pixbuf_from_window(root_window, x, y, width, height); >>> screenshot = gdk_pixbuf_add_alpha(tmp, FALSE, 0, 0, 0); >>> g_object_unref(tmp); >>> >>> jint *pixels = (jint *)convert_BGRA_to_RGBA((int*)g >>> dk_pixbuf_get_pixels(screenshot), width * 4, height); >>> env->SetIntArrayRegion(data, 0, height * width, pixels); >>> g_free(pixels); >>> >>> g_object_unref(screenshot); >>> } >>> >>> Have I somehow messed up the signature? As you can see I removed one of >>> the "_" prefixes >>> to "1getScreenCapture" (which seemed to work for the other Robots) as >>> necessary because >>> the native method is no longer itself prefixed with "_". >>> >>> Thanks again. >>> >>> 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 mike.ennen at gmail.com Wed Dec 27 05:08:49 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Tue, 26 Dec 2017 22:08: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> Message-ID: I forgot to mention one thing: There is quite a large amount of changes to GlassRobot.m for macOS. This was purely experimental and was copied almost wholesale from Chromium (or was it Firefox?). I wanted to see if messing around with setting the color profile of the display allowed for exact color matching via the robot on macOS. Setting the color profile is not part of the Robot proposal and will be removed (mostly because of license issues but also because it's really outside the scope). Specifically I am talking about the following static methods added to: "modules/javafx.graphics/src/main/native-glass/mac/GlassRobot.m": Starting with: "originalColorProfileURLs" and ending with "restoreUserColorProfile". I also noticed that I messed up the logging statements in some of the native Robots but will hold off changing them because it will mess up the commit hash I posted in the previous message. Once I get feedback I will incorporate make this minor fixups in addition to responding/fixing the feedback. Regards, Michael Ennen On Tue, Dec 26, 2017 at 9:35 PM, Michael Ennen wrote: > I have completed what I would call a first draft of moving the Robot to > JavaFX > public API. > > This commit: https://github.com/brcolow/openjfx/commit/ > 321f949575a201fe28a2ff79c9590daf8db375a8 > > Includes all the relevant changes necessary to move the glass robot into > the public > API. > > I have some other commits on that repository, but they are unrelated and > not > part of the Robot proposal at all. > > Except for the most recent commit: > > https://github.com/brcolow/openjfx/commit/e3250c95d36a467efd6002dc213cf2 > 7668b3f6e0 > > which explores adding support for the back/forward mouse buttons > (JDK-8090930), > also known as mouse buttons 4 and 5 to JavaFX. This is essentially > independent from > the Robot proposal except if there is interested in this and it (or > something like it, > or based on it), is merged then I can easily adapt the native robot > implementations > (GtkRobot, MonocleRobot, MacRobot, IOsRobot, and WinRobot) to support > these additional mouse keys. > > Happy holidays all, > Michael Ennen > > On Sat, Dec 23, 2017 at 6:00 PM, Michael Ennen > wrote: > >> Kevin, >> >> You mentioned in your initial response that Jemmy would need to updated >> with any changes >> that result from moving Robot into the JavaFX public API. However, from >> what I can tell >> from a cursory glance, Jemmy seems to use "java.awt.Robot" and not the >> JavaFX Glass >> Robot API and thus no changes to Jemmy would be required after moving >> Robot to the >> JavaFX public API. >> >> Am I missing something? >> >> Thanks, happy holidays (not expecting a response for a while :) ). >> >> >> >> On Fri, Dec 22, 2017 at 10:51 PM, Michael Ennen >> wrote: >> >>> I didn't realize "_1" is an escape character in JNI method naming and is >>> only >>> needed when the method has a "_" in its' name. Nevermind! >>> >>> On Fri, Dec 22, 2017 at 2:57 PM, Michael Ennen >>> wrote: >>> >>>> I have made quite a bit of good progress I think: >>>> >>>> https://github.com/brcolow/openjfx/commit/d92ef24101cf32dfc0 >>>> 7b21bdcb575528d8a58eaf >>>> >>>> The public API is starting to look much cleaner: >>>> >>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>> >>>> Still a lot to do. >>>> >>>> Currently I am running into a JNI UnsatisfiedLinkError for GtkRobot but >>>> I am unsure why: >>>> >>>> java.lang.UnsatisfiedLinkError: com.sun.glass.ui.gtk.GtkRobot. >>>> getScreenCapture(IIII[I)V >>>> at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getScreenCapture(Native >>>> Method) >>>> at javafx.graphics/com.sun.glass.ui.gtk.GtkRobot.getPixelColor( >>>> GtkRobot.java:93) >>>> >>>> I have the following Java method in GtkRobot.java: >>>> >>>> @Override native protected void getScreenCapture(int x, int y, int >>>> width, int height, int[] data); >>>> >>>> Which is overriding the abstract method in Robot.java: >>>> >>>> protected abstract void getScreenCapture(int x, int y, int width, int >>>> height, int[] data); >>>> >>>> and it is implemented in GlassRobot.cpp thusly: >>>> >>>> /* >>>> * Class: com_sun_glass_ui_gtk_GtkRobot >>>> * Method: getScreenCapture >>>> * Signature: (IIII[I)V >>>> */ >>>> JNIEXPORT void JNICALL Java_com_sun_glass_ui_gtk_GtkR >>>> obot_1getScreenCapture >>>> (JNIEnv * env, jobject obj, jint x, jint y, jint width, jint height, >>>> jintArray data) >>>> { >>>> (void)obj; >>>> >>>> GdkPixbuf *screenshot, *tmp; >>>> GdkWindow *root_window = gdk_get_default_root_window(); >>>> >>>> tmp = glass_pixbuf_from_window(root_window, x, y, width, height); >>>> screenshot = gdk_pixbuf_add_alpha(tmp, FALSE, 0, 0, 0); >>>> g_object_unref(tmp); >>>> >>>> jint *pixels = (jint *)convert_BGRA_to_RGBA((int*)g >>>> dk_pixbuf_get_pixels(screenshot), width * 4, height); >>>> env->SetIntArrayRegion(data, 0, height * width, pixels); >>>> g_free(pixels); >>>> >>>> g_object_unref(screenshot); >>>> } >>>> >>>> Have I somehow messed up the signature? As you can see I removed one of >>>> the "_" prefixes >>>> to "1getScreenCapture" (which seemed to work for the other Robots) as >>>> necessary because >>>> the native method is no longer itself prefixed with "_". >>>> >>>> Thanks again. >>>> >>>> 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 mike.ennen at gmail.com Thu Dec 28 05:58:00 2017 From: mike.ennen at gmail.com (Michael Ennen) Date: Wed, 27 Dec 2017 22:58:00 -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> Message-ID: Just a quick note for clarification: I was able to make the small changes I mentioned (removing the color profile experiments and incorrect log statement) to GlassRobot.m without affecting the commit hashes so the URLs should still work, but will reflect the newest changes from my end. Sorry for all the extra noise, just want to be clear. (P.S. Kevin: Do you prefer I use Reply-To-All or only reply to openjfx-dev? I am not sure what is the modus operandi for this list). Thanks, Michael Ennen On Tue, Dec 26, 2017 at 10:08 PM, Michael Ennen wrote: > I forgot to mention one thing: > > There is quite a large amount of changes to GlassRobot.m for macOS. > This was purely experimental and was copied almost wholesale > from Chromium (or was it Firefox?). I wanted to see if messing around > with setting the color profile of the display allowed for exact color > matching > via the robot on macOS. Setting the color profile is not part of the Robot > proposal and will be removed (mostly because of license issues but also > because it's really outside the scope). > > Specifically I am talking about the following static methods added to: > "modules/javafx.graphics/src/main/native-glass/mac/GlassRobot.m": > > Starting with: "originalColorProfileURLs" and ending with > "restoreUserColorProfile". > > I also noticed that I messed up the logging statements in some of the > native Robots but will hold off changing them because it will mess up > the commit hash I posted in the previous message. Once I get feedback > I will incorporate make this minor fixups in addition to responding/fixing > the feedback. > > Regards, > Michael Ennen > > > On Tue, Dec 26, 2017 at 9:35 PM, Michael Ennen > wrote: > >> I have completed what I would call a first draft of moving the Robot to >> JavaFX >> public API. >> >> This commit: https://github.com/brcolow/openjfx/commit/321f949575 >> a201fe28a2ff79c9590daf8db375a8 >> >> Includes all the relevant changes necessary to move the glass robot into >> the public >> API. >> >> I have some other commits on that repository, but they are unrelated and >> not >> part of the Robot proposal at all. >> >> Except for the most recent commit: >> >> https://github.com/brcolow/openjfx/commit/e3250c95d36a467efd >> 6002dc213cf27668b3f6e0 >> >> which explores adding support for the back/forward mouse buttons >> (JDK-8090930), >> also known as mouse buttons 4 and 5 to JavaFX. This is essentially >> independent from >> the Robot proposal except if there is interested in this and it (or >> something like it, >> or based on it), is merged then I can easily adapt the native robot >> implementations >> (GtkRobot, MonocleRobot, MacRobot, IOsRobot, and WinRobot) to support >> these additional mouse keys. >> >> Happy holidays all, >> Michael Ennen >> >> On Sat, Dec 23, 2017 at 6:00 PM, Michael Ennen >> wrote: >> >>> Kevin, >>> >>> You mentioned in your initial response that Jemmy would need to updated >>> with any changes >>> that result from moving Robot into the JavaFX public API. However, from >>> what I can tell >>> from a cursory glance, Jemmy seems to use "java.awt.Robot" and not the >>> JavaFX Glass >>> Robot API and thus no changes to Jemmy would be required after moving >>> Robot to the >>> JavaFX public API. >>> >>> Am I missing something? >>> >>> Thanks, happy holidays (not expecting a response for a while :) ). >>> >>> >>> >>> On Fri, Dec 22, 2017 at 10:51 PM, Michael Ennen >>> wrote: >>> >>>> I didn't realize "_1" is an escape character in JNI method naming and >>>> is only >>>> needed when the method has a "_" in its' name. Nevermind! >>>> >>>> On Fri, Dec 22, 2017 at 2:57 PM, Michael Ennen >>>> wrote: >>>> >>>>> I have made quite a bit of good progress I think: >>>>> >>>>> https://github.com/brcolow/openjfx/commit/d92ef24101cf32dfc0 >>>>> 7b21bdcb575528d8a58eaf >>>>> >>>>> The public API is starting to look much cleaner: >>>>> >>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>> >>>>> Still a lot to do. >>>>> >>>>> Currently I am running into a JNI UnsatisfiedLinkError for GtkRobot >>>>> but I am unsure why: >>>>> >>>>> java.lang.UnsatisfiedLinkError: com.sun.glass.ui.gtk.GtkRobot. >>>>> getScreenCapture(IIII[I)V >>>>> at javafx.graphics/com.sun.glass. >>>>> ui.gtk.GtkRobot.getScreenCapture(Native Method) >>>>> at javafx.graphics/com.sun.glass. >>>>> ui.gtk.GtkRobot.getPixelColor(GtkRobot.java:93) >>>>> >>>>> I have the following Java method in GtkRobot.java: >>>>> >>>>> @Override native protected void getScreenCapture(int x, int y, int >>>>> width, int height, int[] data); >>>>> >>>>> Which is overriding the abstract method in Robot.java: >>>>> >>>>> protected abstract void getScreenCapture(int x, int y, int width, int >>>>> height, int[] data); >>>>> >>>>> and it is implemented in GlassRobot.cpp thusly: >>>>> >>>>> /* >>>>> * Class: com_sun_glass_ui_gtk_GtkRobot >>>>> * Method: getScreenCapture >>>>> * Signature: (IIII[I)V >>>>> */ >>>>> JNIEXPORT void JNICALL Java_com_sun_glass_ui_gtk_GtkR >>>>> obot_1getScreenCapture >>>>> (JNIEnv * env, jobject obj, jint x, jint y, jint width, jint height, >>>>> jintArray data) >>>>> { >>>>> (void)obj; >>>>> >>>>> GdkPixbuf *screenshot, *tmp; >>>>> GdkWindow *root_window = gdk_get_default_root_window(); >>>>> >>>>> tmp = glass_pixbuf_from_window(root_window, x, y, width, height); >>>>> screenshot = gdk_pixbuf_add_alpha(tmp, FALSE, 0, 0, 0); >>>>> g_object_unref(tmp); >>>>> >>>>> jint *pixels = (jint *)convert_BGRA_to_RGBA((int*)g >>>>> dk_pixbuf_get_pixels(screenshot), width * 4, height); >>>>> env->SetIntArrayRegion(data, 0, height * width, pixels); >>>>> g_free(pixels); >>>>> >>>>> g_object_unref(screenshot); >>>>> } >>>>> >>>>> Have I somehow messed up the signature? As you can see I removed one >>>>> of the "_" prefixes >>>>> to "1getScreenCapture" (which seemed to work for the other Robots) as >>>>> necessary because >>>>> the native method is no longer itself prefixed with "_". >>>>> >>>>> Thanks again. >>>>> >>>>> 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 < >>>>>>>>> mike.ennen at gmail.com> 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 webczat_200 at poczta.onet.pl Sat Dec 30 17:36:06 2017 From: webczat_200 at poczta.onet.pl (=?UTF-8?Q?Micha=c5=82_Zegan?=) Date: Sat, 30 Dec 2017 18:36:06 +0100 Subject: javafx linux accessibility Message-ID: Hello. Any plans to add linux support for javafx accessibility for jdk10 or beyond? If not, is the public api enough for someone to write a 3'rd party module that would provide accessibility? From nlisker at gmail.com Sun Dec 31 12:43:50 2017 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 31 Dec 2017 14:43:50 +0200 Subject: JDK build fails on missing javah Message-ID: After successfully building OpenJFX (11) Iv'e went on to build OpenJDK (11) as instructed under "Integration with OpenJDK" ( http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html). When executing `bash configure --with-import-modules=jfx_path\rt\build\modular-sdk` the build fails: checking for java in Boot JDK... ok checking for javac in Boot JDK... ok checking for javah in Boot JDK... not found configure: Your Boot JDK seems broken. This might be fixed by explicitly setting --with-boot-jdk configure: error: Could not find javah in the Boot JDK configure exiting with result code 1 The boot JDK is 10, which does not have javah anymore, so it is no surprise. I could point boot JDK to a previous version, but I don't think I should. Does anyone know what I should do? Nir