From swpalmer at gmail.com  Mon Oct  1 01:41:38 2018
From: swpalmer at gmail.com (Scott Palmer)
Date: Sun, 30 Sep 2018 21:41:38 -0400
Subject: State of maven artifacts
In-Reply-To: <CAOTPd67p5bNR0jdAcLnLLDtfN4tr1EtXf_os1N3un5nh03-sWA@mail.gmail.com>
References: <CA+0ynh9eMddp630NsncZR9j4aeHwK6wmLqPaZ_owt6hnk5yrhQ@mail.gmail.com>
 <CA+5qceL=sGgBUmDYt6Nmu8RriEP2oewyZAzkhsZ4kd62JagV4A@mail.gmail.com>
 <CA+0ynh_emiQCLz93KxDxD-tbcOVr9BjXB5cdEy_qYYP7qbRCew@mail.gmail.com>
 <CABek58mV1qtO5Co+ihgDzn3e_dzvFDkmKuebSuN31Frcw3auog@mail.gmail.com>
 <CAOTPd66N3A95vht7H-CNLwkQFw-XFUVYRj_H+yfRhuJtdyYB8Q@mail.gmail.com>
 <0ED45382-7510-4276-AF12-90F058C98ECD@gmail.com>
 <CAOTPd67p5bNR0jdAcLnLLDtfN4tr1EtXf_os1N3un5nh03-sWA@mail.gmail.com>
Message-ID: <1A48E982-5ACC-4A36-9F95-0929AC019D46@gmail.com>

I stopped using Maven years ago after switching to Gradle. So that could be right.  I think there was an issue with Gradle processing transitive dependencies with a classifier or something.  Thankfully Gradle makes it easy to specify the right classifier.

Scott


> On Sep 30, 2018, at 7:01 PM, Michael Ennen <mike.ennen at gmail.com> wrote:
> 
> Scott,
> 
> It seems that, for me at least, specifying the platform manually is not necessary on
> Maven but is necessary on Gradle. Looking at the POMs themselves it seems that
> the javafx-graphics, javafx-controls, etc. modules declare a dependency on the
> platform specific artifacts:
> 
> <dependency>
>     <groupId>org.openjfx</groupId>
>     <artifactId>javafx-base</artifactId>
>     <version>11</version>
>     <classifier>${javafx.platform}</classifier>
> </dependency>
> 
> and declare as their parent:
> 
> <parent>
>     <groupId>org.openjfx</groupId>
>     <artifactId>javafx</artifactId>
>     <version>11</version>
> </parent>
> 
> and the POM for that parent has the platform-specific Maven profiles built-in.
> 
> So in other words the logic is already built in to the Maven POM and therefore
> works out of the box with Maven but Gradle does not re-use the Maven profile
> logic in the POM.
> 
> Regards,
> Michael Ennen
> 
> On Sun, Sep 30, 2018 at 2:19 PM Scott Palmer <swpalmer at gmail.com <mailto:swpalmer at gmail.com>> wrote:
> I thought he was saying the exact opposite.
> You must specify the platform by using some mechanism in Maven (profiles?) or Gradle.
> 
> That?s what worked for me anyway.
> 
> Scott
> 
> > On Sep 26, 2018, at 6:19 AM, Michael Ennen <mike.ennen at gmail.com <mailto:mike.ennen at gmail.com>> wrote:
> > 
> > And just to reiterate and confirm for anyone trying to get a handle on using
> > the Maven artifacts - it is *NOT* necessary to manually specify the platform
> > classifier when using maven or gradle (nor add the automatic tricks to your
> > own project) because the JavaFX artifacts will automatically detect the
> > platform you are building on and pull in the correct artifacts, right?
> > 
> > Thanks for your work in this area Johan.
> > 
> > On Wed, Sep 26, 2018 at 12:31 AM Johan Vos <johan at lodgon.com <mailto:johan at lodgon.com>> wrote:
> > 
> >> The problem with that is that there is no cross-platform version of the
> >> jars itself. The windows-jar for the graphics module contains different
> >> Java classes than the linux jar, for example.
> >> The top-level API's are the same of course, hence the logical Java module
> >> is the same, but different physical jars are really needed.
> >> I realise this may be strange at compile time, where you only care about
> >> the top-level API's. Therefore, people added nice "tricks" to both a
> >> pom.xml and build.gradle system to automatically detect the current (host)
> >> operating system, and making sure the correct artifacts are then used.
> >> 
> >> What I really wanted to avoid is that developers had to manually add their
> >> platform (e.g. "win") in the build files, as this would break
> >> cross-platform development (imagine you're in a team with a win and a linux
> >> user, and they constantly change the pom.xml or build.gradle file for
> >> this...).
> >> 
> >> I think the current solution deals pretty well with the current situations,
> >> where there are different concepts in gradle/maven/sonatype and in the Java
> >> module system.
> >> 
> >> - Johan
> >> 
> >> 
> >> 
> >> Op wo 26 sep. 2018 om 05:46 schreef Nir Lisker <nlisker at gmail.com <mailto:nlisker at gmail.com>>:
> >> 
> >>> Thanks Sam, that solved it. For some reason I was thinking that if you
> >>> don't specify the platform it downloads a version with all native
> >>> dependencies for cross compilation.
> >>> 
> >>> On Wed, Sep 26, 2018 at 2:37 AM Sam Carlberg <sam.carlberg at gmail.com <mailto:sam.carlberg at gmail.com>>
> >>> wrote:
> >>> 
> >>>> The libraries are in artifacts with platform-specific classifiers. The
> >>>> artifacts with no classifiers that you currently depend on are
> >> completely
> >>>> empty.
> >>>> 
> >>>> You need to depend on "org.openjfx:javafx-base:11:$platform", where the
> >>>> platform is one of "win", "mac", or "linux".
> >>>> 
> >>>> On Tue, Sep 25, 2018, 5:18 PM Nir Lisker <nlisker at gmail.com <mailto:nlisker at gmail.com>> wrote:
> >>>> 
> >>>>> Hi,
> >>>>> 
> >>>>> I haven't kept up with all of the Maven artifacts discussion. The
> >>> website
> >>>>> mentioned in 2 places that there are maven artifacts, but does not
> >>> mention
> >>>>> their ID's, group etc. These are the downloads page [1] and the
> >> getting
> >>>>> started page [2] (later you can see an example pom, but that doesn't
> >>>>> count).
> >>>>> 
> >>>>> I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it
> >> finds
> >>>>> the artifacts. It should be written in the above pages if this is
> >>> correct.
> >>>>> 
> >>>>> On the usability side it's worse. I'm using Eclipse and during
> >>> compilation
> >>>>> I'm getting error messages that JavaFX classes like BooleanProperty
> >>> can't
> >>>>> be found. Is it a JavaFX problem, Eclipse problem, or me problem?
> >>>>> 
> >>>>> If I use the SDKs, can I point Gradle and Maven to them if it will
> >> solve
> >>>>> the problem?
> >>>>> 
> >>>>> - Nir
> >>>>> 
> >>>>> [1] https://gluonhq.com/products/javafx/ <https://gluonhq.com/products/javafx/>
> >>>>> [2] https://openjfx.io/openjfx-docs/#introduction <https://openjfx.io/openjfx-docs/#introduction>
> >>>>> 
> >>>> 
> >>> 
> >> 
> > 
> > 
> > -- 
> > Michael Ennen
> 
> 
> 


From nlisker at gmail.com  Mon Oct  1 10:53:55 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 1 Oct 2018 13:53:55 +0300
Subject: State of maven artifacts
In-Reply-To: <1A48E982-5ACC-4A36-9F95-0929AC019D46@gmail.com>
References: <CA+0ynh9eMddp630NsncZR9j4aeHwK6wmLqPaZ_owt6hnk5yrhQ@mail.gmail.com>
 <CA+5qceL=sGgBUmDYt6Nmu8RriEP2oewyZAzkhsZ4kd62JagV4A@mail.gmail.com>
 <CA+0ynh_emiQCLz93KxDxD-tbcOVr9BjXB5cdEy_qYYP7qbRCew@mail.gmail.com>
 <CABek58mV1qtO5Co+ihgDzn3e_dzvFDkmKuebSuN31Frcw3auog@mail.gmail.com>
 <CAOTPd66N3A95vht7H-CNLwkQFw-XFUVYRj_H+yfRhuJtdyYB8Q@mail.gmail.com>
 <0ED45382-7510-4276-AF12-90F058C98ECD@gmail.com>
 <CAOTPd67p5bNR0jdAcLnLLDtfN4tr1EtXf_os1N3un5nh03-sWA@mail.gmail.com>
 <1A48E982-5ACC-4A36-9F95-0929AC019D46@gmail.com>
Message-ID: <CA+0ynh8b2rpbDoNhoiSV01yk-j1WmBcmWdb33_05Dfo1EKTnTw@mail.gmail.com>

Well, whatever the case is, it needs to be tested and documented. If we
don't have that, we can't expect developers to use the library.

I can run a series of tests with both Maven and Gradle (on Win10 with
Eclipse).

- Nir

On Mon, Oct 1, 2018 at 12:43 PM Scott Palmer <swpalmer at gmail.com> wrote:

> I stopped using Maven years ago after switching to Gradle. So that could
> be right.  I think there was an issue with Gradle processing transitive
> dependencies with a classifier or something.  Thankfully Gradle makes it
> easy to specify the right classifier.
>
> Scott
>
>
> > On Sep 30, 2018, at 7:01 PM, Michael Ennen <mike.ennen at gmail.com> wrote:
> >
> > Scott,
> >
> > It seems that, for me at least, specifying the platform manually is not
> necessary on
> > Maven but is necessary on Gradle. Looking at the POMs themselves it
> seems that
> > the javafx-graphics, javafx-controls, etc. modules declare a dependency
> on the
> > platform specific artifacts:
> >
> > <dependency>
> >     <groupId>org.openjfx</groupId>
> >     <artifactId>javafx-base</artifactId>
> >     <version>11</version>
> >     <classifier>${javafx.platform}</classifier>
> > </dependency>
> >
> > and declare as their parent:
> >
> > <parent>
> >     <groupId>org.openjfx</groupId>
> >     <artifactId>javafx</artifactId>
> >     <version>11</version>
> > </parent>
> >
> > and the POM for that parent has the platform-specific Maven profiles
> built-in.
> >
> > So in other words the logic is already built in to the Maven POM and
> therefore
> > works out of the box with Maven but Gradle does not re-use the Maven
> profile
> > logic in the POM.
> >
> > Regards,
> > Michael Ennen
> >
> > On Sun, Sep 30, 2018 at 2:19 PM Scott Palmer <swpalmer at gmail.com
> <mailto:swpalmer at gmail.com>> wrote:
> > I thought he was saying the exact opposite.
> > You must specify the platform by using some mechanism in Maven
> (profiles?) or Gradle.
> >
> > That?s what worked for me anyway.
> >
> > Scott
> >
> > > On Sep 26, 2018, at 6:19 AM, Michael Ennen <mike.ennen at gmail.com
> <mailto:mike.ennen at gmail.com>> wrote:
> > >
> > > And just to reiterate and confirm for anyone trying to get a handle on
> using
> > > the Maven artifacts - it is *NOT* necessary to manually specify the
> platform
> > > classifier when using maven or gradle (nor add the automatic tricks to
> your
> > > own project) because the JavaFX artifacts will automatically detect the
> > > platform you are building on and pull in the correct artifacts, right?
> > >
> > > Thanks for your work in this area Johan.
> > >
> > > On Wed, Sep 26, 2018 at 12:31 AM Johan Vos <johan at lodgon.com <mailto:
> johan at lodgon.com>> wrote:
> > >
> > >> The problem with that is that there is no cross-platform version of
> the
> > >> jars itself. The windows-jar for the graphics module contains
> different
> > >> Java classes than the linux jar, for example.
> > >> The top-level API's are the same of course, hence the logical Java
> module
> > >> is the same, but different physical jars are really needed.
> > >> I realise this may be strange at compile time, where you only care
> about
> > >> the top-level API's. Therefore, people added nice "tricks" to both a
> > >> pom.xml and build.gradle system to automatically detect the current
> (host)
> > >> operating system, and making sure the correct artifacts are then used.
> > >>
> > >> What I really wanted to avoid is that developers had to manually add
> their
> > >> platform (e.g. "win") in the build files, as this would break
> > >> cross-platform development (imagine you're in a team with a win and a
> linux
> > >> user, and they constantly change the pom.xml or build.gradle file for
> > >> this...).
> > >>
> > >> I think the current solution deals pretty well with the current
> situations,
> > >> where there are different concepts in gradle/maven/sonatype and in
> the Java
> > >> module system.
> > >>
> > >> - Johan
> > >>
> > >>
> > >>
> > >> Op wo 26 sep. 2018 om 05:46 schreef Nir Lisker <nlisker at gmail.com
> <mailto:nlisker at gmail.com>>:
> > >>
> > >>> Thanks Sam, that solved it. For some reason I was thinking that if
> you
> > >>> don't specify the platform it downloads a version with all native
> > >>> dependencies for cross compilation.
> > >>>
> > >>> On Wed, Sep 26, 2018 at 2:37 AM Sam Carlberg <sam.carlberg at gmail.com
> <mailto:sam.carlberg at gmail.com>>
> > >>> wrote:
> > >>>
> > >>>> The libraries are in artifacts with platform-specific classifiers.
> The
> > >>>> artifacts with no classifiers that you currently depend on are
> > >> completely
> > >>>> empty.
> > >>>>
> > >>>> You need to depend on "org.openjfx:javafx-base:11:$platform", where
> the
> > >>>> platform is one of "win", "mac", or "linux".
> > >>>>
> > >>>> On Tue, Sep 25, 2018, 5:18 PM Nir Lisker <nlisker at gmail.com
> <mailto:nlisker at gmail.com>> wrote:
> > >>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> I haven't kept up with all of the Maven artifacts discussion. The
> > >>> website
> > >>>>> mentioned in 2 places that there are maven artifacts, but does not
> > >>> mention
> > >>>>> their ID's, group etc. These are the downloads page [1] and the
> > >> getting
> > >>>>> started page [2] (later you can see an example pom, but that
> doesn't
> > >>>>> count).
> > >>>>>
> > >>>>> I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and it
> > >> finds
> > >>>>> the artifacts. It should be written in the above pages if this is
> > >>> correct.
> > >>>>>
> > >>>>> On the usability side it's worse. I'm using Eclipse and during
> > >>> compilation
> > >>>>> I'm getting error messages that JavaFX classes like BooleanProperty
> > >>> can't
> > >>>>> be found. Is it a JavaFX problem, Eclipse problem, or me problem?
> > >>>>>
> > >>>>> If I use the SDKs, can I point Gradle and Maven to them if it will
> > >> solve
> > >>>>> the problem?
> > >>>>>
> > >>>>> - Nir
> > >>>>>
> > >>>>> [1] https://gluonhq.com/products/javafx/ <
> https://gluonhq.com/products/javafx/>
> > >>>>> [2] https://openjfx.io/openjfx-docs/#introduction <
> https://openjfx.io/openjfx-docs/#introduction>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> > >
> > > --
> > > Michael Ennen
> >
> >
> >
>
>

From johan at lodgon.com  Mon Oct  1 11:23:56 2018
From: johan at lodgon.com (Johan Vos)
Date: Mon, 1 Oct 2018 13:23:56 +0200
Subject: State of maven artifacts
In-Reply-To: <CA+0ynh8b2rpbDoNhoiSV01yk-j1WmBcmWdb33_05Dfo1EKTnTw@mail.gmail.com>
References: <CA+0ynh9eMddp630NsncZR9j4aeHwK6wmLqPaZ_owt6hnk5yrhQ@mail.gmail.com>
 <CA+5qceL=sGgBUmDYt6Nmu8RriEP2oewyZAzkhsZ4kd62JagV4A@mail.gmail.com>
 <CA+0ynh_emiQCLz93KxDxD-tbcOVr9BjXB5cdEy_qYYP7qbRCew@mail.gmail.com>
 <CABek58mV1qtO5Co+ihgDzn3e_dzvFDkmKuebSuN31Frcw3auog@mail.gmail.com>
 <CAOTPd66N3A95vht7H-CNLwkQFw-XFUVYRj_H+yfRhuJtdyYB8Q@mail.gmail.com>
 <0ED45382-7510-4276-AF12-90F058C98ECD@gmail.com>
 <CAOTPd67p5bNR0jdAcLnLLDtfN4tr1EtXf_os1N3un5nh03-sWA@mail.gmail.com>
 <1A48E982-5ACC-4A36-9F95-0929AC019D46@gmail.com>
 <CA+0ynh8b2rpbDoNhoiSV01yk-j1WmBcmWdb33_05Dfo1EKTnTw@mail.gmail.com>
Message-ID: <CABek58n2QieqqOTA5g2N7vjUTi2vUJGxFn9=nDWG5V6VmrxstQ@mail.gmail.com>

Hi,

Have a look at the sample (maven/gradle) in
https://openjfx.io/openjfx-docs/

For maven, a pom.xml without any classifier is needed. This is because the
javafx module pom files have a javafx.pom as a parent, that will test the
current OS, and then use that as a classifier to download the correct
versions of the artifacts.

For gradle, the classifier needs to be in the build.gradle (e.g. see
https://openjfx.io/openjfx-docs/build.gradle) The logic in the sample shows
that the classifier can be detected though in the build.gradle.

- Johan


Op ma 1 okt. 2018 om 12:54 schreef Nir Lisker <nlisker at gmail.com>:

> Well, whatever the case is, it needs to be tested and documented. If we
> don't have that, we can't expect developers to use the library.
>
> I can run a series of tests with both Maven and Gradle (on Win10 with
> Eclipse).
>
> - Nir
>
> On Mon, Oct 1, 2018 at 12:43 PM Scott Palmer <swpalmer at gmail.com> wrote:
>
> > I stopped using Maven years ago after switching to Gradle. So that could
> > be right.  I think there was an issue with Gradle processing transitive
> > dependencies with a classifier or something.  Thankfully Gradle makes it
> > easy to specify the right classifier.
> >
> > Scott
> >
> >
> > > On Sep 30, 2018, at 7:01 PM, Michael Ennen <mike.ennen at gmail.com>
> wrote:
> > >
> > > Scott,
> > >
> > > It seems that, for me at least, specifying the platform manually is not
> > necessary on
> > > Maven but is necessary on Gradle. Looking at the POMs themselves it
> > seems that
> > > the javafx-graphics, javafx-controls, etc. modules declare a dependency
> > on the
> > > platform specific artifacts:
> > >
> > > <dependency>
> > >     <groupId>org.openjfx</groupId>
> > >     <artifactId>javafx-base</artifactId>
> > >     <version>11</version>
> > >     <classifier>${javafx.platform}</classifier>
> > > </dependency>
> > >
> > > and declare as their parent:
> > >
> > > <parent>
> > >     <groupId>org.openjfx</groupId>
> > >     <artifactId>javafx</artifactId>
> > >     <version>11</version>
> > > </parent>
> > >
> > > and the POM for that parent has the platform-specific Maven profiles
> > built-in.
> > >
> > > So in other words the logic is already built in to the Maven POM and
> > therefore
> > > works out of the box with Maven but Gradle does not re-use the Maven
> > profile
> > > logic in the POM.
> > >
> > > Regards,
> > > Michael Ennen
> > >
> > > On Sun, Sep 30, 2018 at 2:19 PM Scott Palmer <swpalmer at gmail.com
> > <mailto:swpalmer at gmail.com>> wrote:
> > > I thought he was saying the exact opposite.
> > > You must specify the platform by using some mechanism in Maven
> > (profiles?) or Gradle.
> > >
> > > That?s what worked for me anyway.
> > >
> > > Scott
> > >
> > > > On Sep 26, 2018, at 6:19 AM, Michael Ennen <mike.ennen at gmail.com
> > <mailto:mike.ennen at gmail.com>> wrote:
> > > >
> > > > And just to reiterate and confirm for anyone trying to get a handle
> on
> > using
> > > > the Maven artifacts - it is *NOT* necessary to manually specify the
> > platform
> > > > classifier when using maven or gradle (nor add the automatic tricks
> to
> > your
> > > > own project) because the JavaFX artifacts will automatically detect
> the
> > > > platform you are building on and pull in the correct artifacts,
> right?
> > > >
> > > > Thanks for your work in this area Johan.
> > > >
> > > > On Wed, Sep 26, 2018 at 12:31 AM Johan Vos <johan at lodgon.com
> <mailto:
> > johan at lodgon.com>> wrote:
> > > >
> > > >> The problem with that is that there is no cross-platform version of
> > the
> > > >> jars itself. The windows-jar for the graphics module contains
> > different
> > > >> Java classes than the linux jar, for example.
> > > >> The top-level API's are the same of course, hence the logical Java
> > module
> > > >> is the same, but different physical jars are really needed.
> > > >> I realise this may be strange at compile time, where you only care
> > about
> > > >> the top-level API's. Therefore, people added nice "tricks" to both a
> > > >> pom.xml and build.gradle system to automatically detect the current
> > (host)
> > > >> operating system, and making sure the correct artifacts are then
> used.
> > > >>
> > > >> What I really wanted to avoid is that developers had to manually add
> > their
> > > >> platform (e.g. "win") in the build files, as this would break
> > > >> cross-platform development (imagine you're in a team with a win and
> a
> > linux
> > > >> user, and they constantly change the pom.xml or build.gradle file
> for
> > > >> this...).
> > > >>
> > > >> I think the current solution deals pretty well with the current
> > situations,
> > > >> where there are different concepts in gradle/maven/sonatype and in
> > the Java
> > > >> module system.
> > > >>
> > > >> - Johan
> > > >>
> > > >>
> > > >>
> > > >> Op wo 26 sep. 2018 om 05:46 schreef Nir Lisker <nlisker at gmail.com
> > <mailto:nlisker at gmail.com>>:
> > > >>
> > > >>> Thanks Sam, that solved it. For some reason I was thinking that if
> > you
> > > >>> don't specify the platform it downloads a version with all native
> > > >>> dependencies for cross compilation.
> > > >>>
> > > >>> On Wed, Sep 26, 2018 at 2:37 AM Sam Carlberg <
> sam.carlberg at gmail.com
> > <mailto:sam.carlberg at gmail.com>>
> > > >>> wrote:
> > > >>>
> > > >>>> The libraries are in artifacts with platform-specific classifiers.
> > The
> > > >>>> artifacts with no classifiers that you currently depend on are
> > > >> completely
> > > >>>> empty.
> > > >>>>
> > > >>>> You need to depend on "org.openjfx:javafx-base:11:$platform",
> where
> > the
> > > >>>> platform is one of "win", "mac", or "linux".
> > > >>>>
> > > >>>> On Tue, Sep 25, 2018, 5:18 PM Nir Lisker <nlisker at gmail.com
> > <mailto:nlisker at gmail.com>> wrote:
> > > >>>>
> > > >>>>> Hi,
> > > >>>>>
> > > >>>>> I haven't kept up with all of the Maven artifacts discussion. The
> > > >>> website
> > > >>>>> mentioned in 2 places that there are maven artifacts, but does
> not
> > > >>> mention
> > > >>>>> their ID's, group etc. These are the downloads page [1] and the
> > > >> getting
> > > >>>>> started page [2] (later you can see an example pom, but that
> > doesn't
> > > >>>>> count).
> > > >>>>>
> > > >>>>> I'm using "org.openjfx:javafx-base:11" (gradle syntax) etc. and
> it
> > > >> finds
> > > >>>>> the artifacts. It should be written in the above pages if this is
> > > >>> correct.
> > > >>>>>
> > > >>>>> On the usability side it's worse. I'm using Eclipse and during
> > > >>> compilation
> > > >>>>> I'm getting error messages that JavaFX classes like
> BooleanProperty
> > > >>> can't
> > > >>>>> be found. Is it a JavaFX problem, Eclipse problem, or me problem?
> > > >>>>>
> > > >>>>> If I use the SDKs, can I point Gradle and Maven to them if it
> will
> > > >> solve
> > > >>>>> the problem?
> > > >>>>>
> > > >>>>> - Nir
> > > >>>>>
> > > >>>>> [1] https://gluonhq.com/products/javafx/ <
> > https://gluonhq.com/products/javafx/>
> > > >>>>> [2] https://openjfx.io/openjfx-docs/#introduction <
> > https://openjfx.io/openjfx-docs/#introduction>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > > >
> > > >
> > > > --
> > > > Michael Ennen
> > >
> > >
> > >
> >
> >
>

From ambarish.rapte at oracle.com  Mon Oct  1 12:28:32 2018
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Mon, 1 Oct 2018 05:28:32 -0700 (PDT)
Subject: [12] RFR : JDK-8203884 : Update libjpeg to version 9c
Message-ID: <1c9f09f0-f0d7-413a-b9dd-e93cf1ba0c4f@default>

Hi All,

 

                Please review this change for updating libjpeg7 to libjpeg9c.

 

                Webrev: http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/  -> Complete patch with changes in make files and Netbeans project files.

                Webrev: http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/  ->  Partial patch, updated 9c files in earlier libjpeg7 folder for ease to go through difference.

 

                JBS: https://bugs.openjdk.java.net/browse/JDK-8203884

 

Regards,

Ambarish

From johan.vos at gluonhq.com  Mon Oct  1 17:59:09 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Mon, 1 Oct 2018 19:59:09 +0200
Subject: [12] RFR : JDK-8203884 : Update libjpeg to version 9c
In-Reply-To: <1c9f09f0-f0d7-413a-b9dd-e93cf1ba0c4f@default>
References: <1c9f09f0-f0d7-413a-b9dd-e93cf1ba0c4f@default>
Message-ID: <CABxFH2H4Mqojz8+gPbyHyZXjmBkEvdBPNWMfefjBzk+K1n198A@mail.gmail.com>

Unrelated to the patch, I wonder if there is a better way to include this
functionality.
If we bundle an application that uses JavaFX but also includes a native
library that links with libjpeg, there will be issues due to duplicate
symbols (this happens for example when running deeplearning4j on ios, where
we build a static executable).

Is it an option to prefix the public symbols?

- Johan


On Mon, Oct 1, 2018 at 5:59 PM Ambarish Rapte <ambarish.rapte at oracle.com>
wrote:

> Hi All,
>
>
>
>                 Please review this change for updating libjpeg7 to
> libjpeg9c.
>
>
>
>                 Webrev:
> http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/  ->
> Complete patch with changes in make files and Netbeans project files.
>
>                 Webrev:
> http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/
> ->  Partial patch, updated 9c files in earlier libjpeg7 folder for ease to
> go through difference.
>
>
>
>                 JBS: https://bugs.openjdk.java.net/browse/JDK-8203884
>
>
>
> Regards,
>
> Ambarish
>

From philip.race at oracle.com  Mon Oct  1 19:28:37 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 1 Oct 2018 12:28:37 -0700
Subject: Setting the FreeType LCD filter
In-Reply-To: <5BB13A3E.1000909@oracle.com>
References: <24d59238-b959-2b5e-5772-618cda2519c4@status6.com>
 <5BB13A3E.1000909@oracle.com>
Message-ID: <875d42a1-b256-a72d-de35-e8441700e3af@oracle.com>

I think I can re-open https://bugs.openjdk.java.net/browse/JDK-8188810
The submitter there is comparing windows to Linux so there are many
things that are different, but the fringing in the Linux examples are
enough to make it possible that this was the real issue there.

-phil.


On 09/30/2018 02:03 PM, Philip Race wrote:
> Hi,
>
> Your explanation makes sense.
> Compile time linking is probably best so long as we can verify that
> the function is available on all the platforms we need to build & run 
> on .. notably
> older versions of OEL&RHEL.
>
> Failing that, then as well as adding ".6" we should initialise
>
> ??? jint rc =-1;
>
> instead of to zero .. so that failure to find the function isn't confused
> as failure *of* the function, which in a nutshell, seems to be the bug 
> here.
> And I suppose we have the same bug on "older" systems where the 
> freetype library is
> found but lack the symbol.
>
> Is there no JBS bug id already open on this ? If one was closed as not 
> reproducible,
> we can re-open it. Better than creating a new one.
>
> -phil.
>
> On 9/30/18, 12:03 PM, John Neffenger wrote:
>> I think I found the cause of the text rendering problem I have always 
>> seen in JavaFX applications on Linux:
>>
>> Reduce color fringes in FreeType subpixel rendering
>> https://github.com/javafxports/openjdk-jfx/issues/229
>>
>> I'm finally seeing the fonts as they were intended! I used the Oracle 
>> bug report outline as a template for the GitHub issue to make it easy 
>> to copy to the Java Bug Database. Do I need a Java Bug ID before I 
>> submit a pull request?
>>
>> Thanks,
>> John
>>
>> P.S.: For background information, there is a great demonstration of 
>> LCD filtering algorithms by Felipe Heidrich at 1:02:47 into the video 
>> "JavaFX Text Rendering" <https://youtu.be/LCrCni6EVek?t=1h2m47s>. The 
>> link takes you directly to the two-minute segment showing the text 
>> rendered by FreeType, first with no filter, and then with its various 
>> filter options. (Note: the audio is a bit loud.)


From philip.race at oracle.com  Mon Oct  1 20:55:27 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 1 Oct 2018 13:55:27 -0700
Subject: [12] RFR : JDK-8203884 : Update libjpeg to version 9c
In-Reply-To: <CABxFH2H4Mqojz8+gPbyHyZXjmBkEvdBPNWMfefjBzk+K1n198A@mail.gmail.com>
References: <1c9f09f0-f0d7-413a-b9dd-e93cf1ba0c4f@default>
 <CABxFH2H4Mqojz8+gPbyHyZXjmBkEvdBPNWMfefjBzk+K1n198A@mail.gmail.com>
Message-ID: <827d9b98-821c-f2b8-47c3-ecc6943fd3f8@oracle.com>

The JDK has shipped a libjpeg since, well, forever.
For a long time it did export all the symbols, but what is now probably
an even longer time, it has exported only the JNI entry points.
We can do the same here.

The JDK approach used to be tediously maintained mapfiles. But recently it
was switched to use compiler directives. The default for such a library as
libjavafx_iio.so is that symbols aren't exported, and we don't need to touch
the imported source files, just add the JNIEXPORT directive to the 
declarations of
the JNI functions in the JDK's own source files which are compiled into 
the library.
And of course some makefile work.

See https://bugs.openjdk.java.net/browse/JDK-8200178 and
http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021306.html

We can do something like this for FX in a follow-on bug

Another follow-on bug opportunity, is for FX to do what JDK 11 does, which
is to defer to the system libjpeg on Linux (and Solaris, but not 
relevant to FX).
So libjavafx_iio.so on Linux would become just a small entry point to the
platform JPEG library.

-phil.

On 10/01/2018 10:59 AM, Johan Vos wrote:
> Unrelated to the patch, I wonder if there is a better way to include this
> functionality.
> If we bundle an application that uses JavaFX but also includes a native
> library that links with libjpeg, there will be issues due to duplicate
> symbols (this happens for example when running deeplearning4j on ios, where
> we build a static executable).
>
> Is it an option to prefix the public symbols?
>
> - Johan
>
>
> On Mon, Oct 1, 2018 at 5:59 PM Ambarish Rapte <ambarish.rapte at oracle.com>
> wrote:
>
>> Hi All,
>>
>>
>>
>>                  Please review this change for updating libjpeg7 to
>> libjpeg9c.
>>
>>
>>
>>                  Webrev:
>> http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/  ->
>> Complete patch with changes in make files and Netbeans project files.
>>
>>                  Webrev:
>> http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/
>> ->  Partial patch, updated 9c files in earlier libjpeg7 folder for ease to
>> go through difference.
>>
>>
>>
>>                  JBS: https://bugs.openjdk.java.net/browse/JDK-8203884
>>
>>
>>
>> Regards,
>>
>> Ambarish
>>


From philip.race at oracle.com  Mon Oct  1 21:01:11 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 1 Oct 2018 14:01:11 -0700
Subject: [12] RFR : JDK-8203884 : Update libjpeg to version 9c
In-Reply-To: <827d9b98-821c-f2b8-47c3-ecc6943fd3f8@oracle.com>
References: <1c9f09f0-f0d7-413a-b9dd-e93cf1ba0c4f@default>
 <CABxFH2H4Mqojz8+gPbyHyZXjmBkEvdBPNWMfefjBzk+K1n198A@mail.gmail.com>
 <827d9b98-821c-f2b8-47c3-ecc6943fd3f8@oracle.com>
Message-ID: <b0de7fcb-c81c-7180-663e-e3dee9a501ee@oracle.com>

On 10/1/2018 1:55 PM, Phil Race wrote:
> The JDK has shipped a libjpeg since, well, forever.

PS .. we now call it libjavajpeg.so but that is recent (JDK 9).

-phil.

> For a long time it did export all the symbols, but what is now probably
> an even longer time, it has exported only the JNI entry points.
> We can do the same here.
>
> The JDK approach used to be tediously maintained mapfiles. But 
> recently it
> was switched to use compiler directives. The default for such a 
> library as
> libjavafx_iio.so is that symbols aren't exported, and we don't need to 
> touch
> the imported source files, just add the JNIEXPORT directive to the 
> declarations of
> the JNI functions in the JDK's own source files which are compiled 
> into the library.
> And of course some makefile work.
>
> See https://bugs.openjdk.java.net/browse/JDK-8200178 and
> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021306.html
>
> We can do something like this for FX in a follow-on bug
>
> Another follow-on bug opportunity, is for FX to do what JDK 11 does, 
> which
> is to defer to the system libjpeg on Linux (and Solaris, but not 
> relevant to FX).
> So libjavafx_iio.so on Linux would become just a small entry point to the
> platform JPEG library.
>
> -phil.
>
> On 10/01/2018 10:59 AM, Johan Vos wrote:
>> Unrelated to the patch, I wonder if there is a better way to include 
>> this
>> functionality.
>> If we bundle an application that uses JavaFX but also includes a native
>> library that links with libjpeg, there will be issues due to duplicate
>> symbols (this happens for example when running deeplearning4j on ios, 
>> where
>> we build a static executable).
>>
>> Is it an option to prefix the public symbols?
>>
>> - Johan
>>
>>
>> On Mon, Oct 1, 2018 at 5:59 PM Ambarish Rapte 
>> <ambarish.rapte at oracle.com>
>> wrote:
>>
>>> Hi All,
>>>
>>>
>>>
>>> ???????????????? Please review this change for updating libjpeg7 to
>>> libjpeg9c.
>>>
>>>
>>>
>>> ???????????????? Webrev:
>>> http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/ ->
>>> Complete patch with changes in make files and Netbeans project files.
>>>
>>> ???????????????? Webrev:
>>> http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/ 
>>>
>>> ->? Partial patch, updated 9c files in earlier libjpeg7 folder for 
>>> ease to
>>> go through difference.
>>>
>>>
>>>
>>> ???????????????? JBS: https://bugs.openjdk.java.net/browse/JDK-8203884
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ambarish
>>>
>


From philip.race at oracle.com  Mon Oct  1 22:18:39 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 1 Oct 2018 15:18:39 -0700
Subject: [12] RFR : JDK-8203884 : Update libjpeg to version 9c
In-Reply-To: <b0de7fcb-c81c-7180-663e-e3dee9a501ee@oracle.com>
References: <1c9f09f0-f0d7-413a-b9dd-e93cf1ba0c4f@default>
 <CABxFH2H4Mqojz8+gPbyHyZXjmBkEvdBPNWMfefjBzk+K1n198A@mail.gmail.com>
 <827d9b98-821c-f2b8-47c3-ecc6943fd3f8@oracle.com>
 <b0de7fcb-c81c-7180-663e-e3dee9a501ee@oracle.com>
Message-ID: <2b06183e-29f1-88e9-7d6e-80fb697b4176@oracle.com>

I filed two bugs
JDK-8211362: Restrict export of libjpeg symbols from libjavafx_iio.so
JDK-8211363: Use platform version of libjpeg on Linux

-phil

On 10/01/2018 02:01 PM, Phil Race wrote:
> On 10/1/2018 1:55 PM, Phil Race wrote:
>> The JDK has shipped a libjpeg since, well, forever.
>
> PS .. we now call it libjavajpeg.so but that is recent (JDK 9).
>
> -phil.
>
>> For a long time it did export all the symbols, but what is now probably
>> an even longer time, it has exported only the JNI entry points.
>> We can do the same here.
>>
>> The JDK approach used to be tediously maintained mapfiles. But 
>> recently it
>> was switched to use compiler directives. The default for such a 
>> library as
>> libjavafx_iio.so is that symbols aren't exported, and we don't need 
>> to touch
>> the imported source files, just add the JNIEXPORT directive to the 
>> declarations of
>> the JNI functions in the JDK's own source files which are compiled 
>> into the library.
>> And of course some makefile work.
>>
>> See https://bugs.openjdk.java.net/browse/JDK-8200178 and
>> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021306.html
>>
>> We can do something like this for FX in a follow-on bug
>>
>> Another follow-on bug opportunity, is for FX to do what JDK 11 does, 
>> which
>> is to defer to the system libjpeg on Linux (and Solaris, but not 
>> relevant to FX).
>> So libjavafx_iio.so on Linux would become just a small entry point to 
>> the
>> platform JPEG library.
>>
>> -phil.
>>
>> On 10/01/2018 10:59 AM, Johan Vos wrote:
>>> Unrelated to the patch, I wonder if there is a better way to include 
>>> this
>>> functionality.
>>> If we bundle an application that uses JavaFX but also includes a native
>>> library that links with libjpeg, there will be issues due to duplicate
>>> symbols (this happens for example when running deeplearning4j on 
>>> ios, where
>>> we build a static executable).
>>>
>>> Is it an option to prefix the public symbols?
>>>
>>> - Johan
>>>
>>>
>>> On Mon, Oct 1, 2018 at 5:59 PM Ambarish Rapte 
>>> <ambarish.rapte at oracle.com>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>>
>>>>
>>>> ???????????????? Please review this change for updating libjpeg7 to
>>>> libjpeg9c.
>>>>
>>>>
>>>>
>>>> ???????????????? Webrev:
>>>> http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/ 
>>>> ->
>>>> Complete patch with changes in make files and Netbeans project files.
>>>>
>>>> ???????????????? Webrev:
>>>> http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/ 
>>>>
>>>> ->? Partial patch, updated 9c files in earlier libjpeg7 folder for 
>>>> ease to
>>>> go through difference.
>>>>
>>>>
>>>>
>>>> ???????????????? JBS: https://bugs.openjdk.java.net/browse/JDK-8203884
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Ambarish
>>>>
>>
>


From krichter at posteo.de  Mon Oct  1 22:45:11 2018
From: krichter at posteo.de (Karl-Philipp Richter)
Date: Tue, 2 Oct 2018 00:45:11 +0200
Subject: tutorial
In-Reply-To: <f2931d2c-3530-9bc6-4029-f290b4dfa5f7@kolabnow.com>
References: <f2931d2c-3530-9bc6-4029-f290b4dfa5f7@kolabnow.com>
Message-ID: <33b500e6-8be7-ec14-0ad2-0c527dff7567@posteo.de>

Hi,

Am 27.09.2018 um 16:39 schrieb Glenn Holmer:
> On https://openjfx.io/openjfx-docs/ I don't see any content, just
> buttons and links that don't seem to do anything. Tried both Firefox and
> Chrome. Is it just me?
Works for me on Firefox on Ubuntu 18.04. I have NoScript installed and
needed to active some scripts (jsdelivr.net) in order to be able to see
the content. Provide a screenshot if you have further trouble.

-Kalle


From cenbe at kolabnow.com  Mon Oct  1 23:05:33 2018
From: cenbe at kolabnow.com (Glenn Holmer)
Date: Mon, 1 Oct 2018 18:05:33 -0500
Subject: tutorial
In-Reply-To: <33b500e6-8be7-ec14-0ad2-0c527dff7567@posteo.de>
References: <f2931d2c-3530-9bc6-4029-f290b4dfa5f7@kolabnow.com>
 <33b500e6-8be7-ec14-0ad2-0c527dff7567@posteo.de>
Message-ID: <fe0bae4b-86f6-2cfa-93c1-b59ea432c23f@kolabnow.com>

On 10/01/2018 05:45 PM, Karl-Philipp Richter wrote:
> Am 27.09.2018 um 16:39 schrieb Glenn Holmer:
>> On https://openjfx.io/openjfx-docs/ I don't see any content, just
>> buttons and links that don't seem to do anything. Tried both Firefox and
>> Chrome. Is it just me?

> Works for me on Firefox on Ubuntu 18.04. I have NoScript installed and
> needed to active some scripts (jsdelivr.net) in order to be able to see
> the content. Provide a screenshot if you have further trouble.

I tried it again this afternoon and it was working properly.

-- 
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."

From johan.vos at gluonhq.com  Tue Oct  2 09:43:31 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 2 Oct 2018 11:43:31 +0200
Subject: Mailinglist for JavaFX discussions
Message-ID: <CABxFH2HLa727g7cVMFA3WWQSSYPUyBKcXb=Wwf1NavLyHkundA@mail.gmail.com>

Hi,

A new mailinglist related to JavaFX has been created:
openjfx-discuss at openjdk.java.net <openjfx-interest at openjdk.java.net> (manage
subscriptions via the listinfo [1])

See [2] for the welcome mail on that list. You're all invited to join the
new mailinglist, and discuss this (the purpose of the list itself) on that
list (rather than on this openjfx-dev list).

- Johan

[1] http://mail.openjdk.java.net/mailman/listinfo
[2]
http://mail.openjdk.java.net/pipermail/openjfx-discuss/2018-October/000000.html

From john at status6.com  Tue Oct  2 22:59:40 2018
From: john at status6.com (John Neffenger)
Date: Tue, 2 Oct 2018 15:59:40 -0700
Subject: Review request for 8188810, "Fonts are blurry on Ubuntu 16.04 and
 Debian 9"
Message-ID: <e0b03982-12ba-aa3f-16f7-68995bdf0f4f@status6.com>

Please review the GitHub pull request:

JDK-8188810: Fonts are blurry on Ubuntu 16.04 and Debian 9
https://github.com/javafxports/openjdk-jfx/pull/235

which fixes:

Fonts are blurry on Ubuntu 16.04 and Debian 9
https://bugs.openjdk.java.net/browse/JDK-8188810

Thank you,
John

From pankaj.b.bansal at oracle.com  Wed Oct  3 10:26:28 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 3 Oct 2018 10:26:28 +0000 (UTC)
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK 3 on
 Linux
Message-ID: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>

Hi All,

 

Please review the patch for 8u-dev backport for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8087516"JDK-8087516. It adds conditional support for gtk3. 

 

Along with the enhancement, following bug fixes have also been included in the backport webrev

 

1.      https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] invalid rendering of FX app stage in case of scaling

2.      https://bugs.openjdk.java.net/browse/JDK-8163496: Rework Glass GTK to correct gtk3 structure sizes

3.      https://bugs.openjdk.java.net/browse/JDK-8145837: Remove deprecated GTK2 calls in JavaFX

4.      https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to newer version of SWT for build/test

5.      https://bugs.openjdk.java.net/browse/JDK-8171330: Issues with transparent stage and GTK

6.      https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: JavaFX window not painted with background when using GTK 3

7.      https://bugs.openjdk.java.net/browse/JDK-8166414: Scene returns incorrect coordinates

8.      https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04: expandable content goes outside of the alert dialog

9.      https://bugs.openjdk.java.net/browse/JDK-8152421: After initing the modality of a non-primary stage to MODAL, closing that stage causes the primary stage to become non-resizable

10.   https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux] Restoring owner stage after minimize does not restore position of child stage

11.   https://bugs.openjdk.java.net/browse/JDK-8173901: Linux: Position of Stage is not restored after exiting full screen

12.   https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: Dialog windows come up 1-pixel wide

13.   https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: Stage initially in full-screen mode not shown when exiting full-screen

14.   https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown position regression and not painting correctly tooltips regression

15.   https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not always selected properly with GTK 3

16.   https://bugs.openjdk.java.net/browse/JDK-8172219: Allow compiling without GTK 3.0 being installed

17.   https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk version if SWT used via FXCanvas

18.   https://bugs.openjdk.java.net/browse/JDK-8156491: Autodetect GTK version for JFX

 

 

The original gtk3 backport patch applied cleanly, but the bugs did not apply cleanly. So a review is required. 

I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux 7.5. 

 

webrev: http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/

JBS: https://bugs.openjdk.java.net/browse/JDK-8087516

JDK 9 Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5

 

 

Regards,

Pankaj

 

From tom.schindl at bestsolution.at  Wed Oct  3 11:00:48 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Wed, 3 Oct 2018 13:00:48 +0200
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK
 3 on Linux
In-Reply-To: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
References: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
Message-ID: <ff382c0b-43d3-c939-7c50-ca59e77f20a9@bestsolution.at>

Hi,

While i can not comment on the change. This is really really great news
for all people integrating JavaFX into SWT!

Tom

On 03.10.18 12:26, Pankaj Bansal wrote:
> Hi All,
> 
>  
> 
> Please review the patch for 8u-dev backport for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8087516"JDK-8087516. It adds conditional support for gtk3. 
> 
>  
> 
> Along with the enhancement, following bug fixes have also been included in the backport webrev
> 
>  
> 
> 1.      https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] invalid rendering of FX app stage in case of scaling
> 
> 2.      https://bugs.openjdk.java.net/browse/JDK-8163496: Rework Glass GTK to correct gtk3 structure sizes
> 
> 3.      https://bugs.openjdk.java.net/browse/JDK-8145837: Remove deprecated GTK2 calls in JavaFX
> 
> 4.      https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to newer version of SWT for build/test
> 
> 5.      https://bugs.openjdk.java.net/browse/JDK-8171330: Issues with transparent stage and GTK
> 
> 6.      https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: JavaFX window not painted with background when using GTK 3
> 
> 7.      https://bugs.openjdk.java.net/browse/JDK-8166414: Scene returns incorrect coordinates
> 
> 8.      https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04: expandable content goes outside of the alert dialog
> 
> 9.      https://bugs.openjdk.java.net/browse/JDK-8152421: After initing the modality of a non-primary stage to MODAL, closing that stage causes the primary stage to become non-resizable
> 
> 10.   https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux] Restoring owner stage after minimize does not restore position of child stage
> 
> 11.   https://bugs.openjdk.java.net/browse/JDK-8173901: Linux: Position of Stage is not restored after exiting full screen
> 
> 12.   https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: Dialog windows come up 1-pixel wide
> 
> 13.   https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: Stage initially in full-screen mode not shown when exiting full-screen
> 
> 14.   https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown position regression and not painting correctly tooltips regression
> 
> 15.   https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not always selected properly with GTK 3
> 
> 16.   https://bugs.openjdk.java.net/browse/JDK-8172219: Allow compiling without GTK 3.0 being installed
> 
> 17.   https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk version if SWT used via FXCanvas
> 
> 18.   https://bugs.openjdk.java.net/browse/JDK-8156491: Autodetect GTK version for JFX
> 
>  
> 
>  
> 
> The original gtk3 backport patch applied cleanly, but the bugs did not apply cleanly. So a review is required. 
> 
> I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux 7.5. 
> 
>  
> 
> webrev: http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8087516
> 
> JDK 9 Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
> 
>  
> 
>  
> 
> Regards,
> 
> Pankaj
> 
>  
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From kevin.rushforth at oracle.com  Wed Oct  3 13:00:37 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 3 Oct 2018 06:00:37 -0700
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK
 3 on Linux
In-Reply-To: <ff382c0b-43d3-c939-7c50-ca59e77f20a9@bestsolution.at>
References: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
 <ff382c0b-43d3-c939-7c50-ca59e77f20a9@bestsolution.at>
Message-ID: <1d8a4a17-1e19-9406-1ec1-57825f096abf@oracle.com>

Tom,

I'll be sure to test SWT interop as part of my review of this fix.

-- Kevin


On 10/3/2018 4:00 AM, Tom Schindl wrote:
> Hi,
>
> While i can not comment on the change. This is really really great news
> for all people integrating JavaFX into SWT!
>
> Tom
>
> On 03.10.18 12:26, Pankaj Bansal wrote:
>> Hi All,
>>
>>   
>>
>> Please review the patch for 8u-dev backport for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8087516"JDK-8087516. It adds conditional support for gtk3.
>>
>>   
>>
>> Along with the enhancement, following bug fixes have also been included in the backport webrev
>>
>>   
>>
>> 1.      https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] invalid rendering of FX app stage in case of scaling
>>
>> 2.      https://bugs.openjdk.java.net/browse/JDK-8163496: Rework Glass GTK to correct gtk3 structure sizes
>>
>> 3.      https://bugs.openjdk.java.net/browse/JDK-8145837: Remove deprecated GTK2 calls in JavaFX
>>
>> 4.      https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to newer version of SWT for build/test
>>
>> 5.      https://bugs.openjdk.java.net/browse/JDK-8171330: Issues with transparent stage and GTK
>>
>> 6.      https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: JavaFX window not painted with background when using GTK 3
>>
>> 7.      https://bugs.openjdk.java.net/browse/JDK-8166414: Scene returns incorrect coordinates
>>
>> 8.      https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04: expandable content goes outside of the alert dialog
>>
>> 9.      https://bugs.openjdk.java.net/browse/JDK-8152421: After initing the modality of a non-primary stage to MODAL, closing that stage causes the primary stage to become non-resizable
>>
>> 10.   https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux] Restoring owner stage after minimize does not restore position of child stage
>>
>> 11.   https://bugs.openjdk.java.net/browse/JDK-8173901: Linux: Position of Stage is not restored after exiting full screen
>>
>> 12.   https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: Dialog windows come up 1-pixel wide
>>
>> 13.   https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: Stage initially in full-screen mode not shown when exiting full-screen
>>
>> 14.   https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown position regression and not painting correctly tooltips regression
>>
>> 15.   https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not always selected properly with GTK 3
>>
>> 16.   https://bugs.openjdk.java.net/browse/JDK-8172219: Allow compiling without GTK 3.0 being installed
>>
>> 17.   https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk version if SWT used via FXCanvas
>>
>> 18.   https://bugs.openjdk.java.net/browse/JDK-8156491: Autodetect GTK version for JFX
>>
>>   
>>
>>   
>>
>> The original gtk3 backport patch applied cleanly, but the bugs did not apply cleanly. So a review is required.
>>
>> I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux 7.5.
>>
>>   
>>
>> webrev: http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8087516
>>
>> JDK 9 Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
>>
>>   
>>
>>   
>>
>> Regards,
>>
>> Pankaj
>>
>>   
>>


From kevin.rushforth at oracle.com  Wed Oct  3 17:16:52 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 3 Oct 2018 10:16:52 -0700
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK
 3 on Linux
In-Reply-To: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
References: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
Message-ID: <83da2996-f6a9-ac90-65f5-25679c1a0d4c@oracle.com>

My initial testing shows a couple problems which will need to be resolved:

1) I get many GTK warnings relating to Pango when running HelloWebView
2) Running any program that uses media crashes

This is on Ubuntu 16.04 LTS using the default GTK 2 mode.

-- Kevin


On 10/3/2018 3:26 AM, Pankaj Bansal wrote:
>
> Hi All,
>
> Please review the patch for 8u-dev backport for JDK-8087516 
> <https://bugs.openjdk.java.net/browse/JDK-8087516>. It adds 
> conditional support for gtk3.
>
> Along with the enhancement, following bug fixes have also been 
> included in the backport webrev
>
> 1.https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] invalid 
> rendering of FX app stage in case of scaling
>
> 2.https://bugs.openjdk.java.net/browse/JDK-8163496: Rework Glass GTK 
> to correct gtk3 structure sizes
>
> 3.https://bugs.openjdk.java.net/browse/JDK-8145837: Remove deprecated 
> GTK2 calls in JavaFX
>
> 4.https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to newer 
> version of SWT for build/test
>
> 5.https://bugs.openjdk.java.net/browse/JDK-8171330: Issues with 
> transparent stage and GTK
>
> 6.https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: JavaFX 
> window not painted with background when using GTK 3
>
> 7.https://bugs.openjdk.java.net/browse/JDK-8166414: Scene returns 
> incorrect coordinates
>
> 8.https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04: 
> expandable content goes outside of the alert dialog
>
> 9.https://bugs.openjdk.java.net/browse/JDK-8152421: After initing the 
> modality of a non-primary stage to MODAL, closing that stage causes 
> the primary stage to become non-resizable
>
> 10.https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux] Restoring 
> owner stage after minimize does not restore position of child stage
>
> 11.https://bugs.openjdk.java.net/browse/JDK-8173901: Linux: Position 
> of Stage is not restored after exiting full screen
>
> 12.https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: Dialog 
> windows come up 1-pixel wide
>
> 13.https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: Stage 
> initially in full-screen mode not shown when exiting full-screen
>
> 14.https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown position 
> regression and not painting correctly tooltips regression
>
> 15.https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not always 
> selected properly with GTK 3
>
> 16.https://bugs.openjdk.java.net/browse/JDK-8172219: Allow compiling 
> without GTK 3.0 being installed
>
> 17.https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk version 
> if SWT used via FXCanvas
>
> 18.https://bugs.openjdk.java.net/browse/JDK-8156491: Autodetect GTK 
> version for JFX
>
> The original gtk3 backport patch applied cleanly, but the bugs did not 
> apply cleanly. So a review is required.
>
> I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu 16.04 
> LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux 7.5.
>
> webrev: http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8087516
>
> JDK 9 Changeset: 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
>
> Regards,
>
> Pankaj
>


From kevin.rushforth at oracle.com  Thu Oct  4 02:11:23 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 3 Oct 2018 19:11:23 -0700
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK
 3 on Linux
In-Reply-To: <83da2996-f6a9-ac90-65f5-25679c1a0d4c@oracle.com>
References: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
 <83da2996-f6a9-ac90-65f5-25679c1a0d4c@oracle.com>
Message-ID: <8f955a90-7e21-9369-6b8d-bce84c36dfd4@oracle.com>

I debugged this offline earlier today, and it looks related to a 
collision in the glib library. As I mentioned offline, a possible 
solution is to remove RTLD_GLOBAL from the dlopen of the 
libglassgtk{2,3}.so library. I was able to do a full build / test on 
both GTK 2 and GTK 3 including media and webkit with that modification.

Overall, this is looking quite good.

One more thing: the patch adds several new tests, so you will need to 
run at least the new tests on all three platforms (a quick check on Mac 
shows a couple failures).

I also see a couple differences between jfx-dev and 8u-dev in the native 
code that should be looked into to make sure there wasn't a missed fix 
on the backport (the Hi-DPI diffs are expected, but I see a couple others).

-- Kevin


On 10/3/2018 10:16 AM, Kevin Rushforth wrote:
> My initial testing shows a couple problems which will need to be 
> resolved:
>
> 1) I get many GTK warnings relating to Pango when running HelloWebView
> 2) Running any program that uses media crashes
>
> This is on Ubuntu 16.04 LTS using the default GTK 2 mode.
>
> -- Kevin
>
>
> On 10/3/2018 3:26 AM, Pankaj Bansal wrote:
>>
>> Hi All,
>>
>> Please review the patch for 8u-dev backport for JDK-8087516 
>> <https://bugs.openjdk.java.net/browse/JDK-8087516>. It adds 
>> conditional support for gtk3.
>>
>> Along with the enhancement, following bug fixes have also been 
>> included in the backport webrev
>>
>> 1.https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] invalid 
>> rendering of FX app stage in case of scaling
>>
>> 2.https://bugs.openjdk.java.net/browse/JDK-8163496: Rework Glass GTK 
>> to correct gtk3 structure sizes
>>
>> 3.https://bugs.openjdk.java.net/browse/JDK-8145837: Remove deprecated 
>> GTK2 calls in JavaFX
>>
>> 4.https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to newer 
>> version of SWT for build/test
>>
>> 5.https://bugs.openjdk.java.net/browse/JDK-8171330: Issues with 
>> transparent stage and GTK
>>
>> 6.https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: JavaFX 
>> window not painted with background when using GTK 3
>>
>> 7.https://bugs.openjdk.java.net/browse/JDK-8166414: Scene returns 
>> incorrect coordinates
>>
>> 8.https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04: 
>> expandable content goes outside of the alert dialog
>>
>> 9.https://bugs.openjdk.java.net/browse/JDK-8152421: After initing the 
>> modality of a non-primary stage to MODAL, closing that stage causes 
>> the primary stage to become non-resizable
>>
>> 10.https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux] 
>> Restoring owner stage after minimize does not restore position of 
>> child stage
>>
>> 11.https://bugs.openjdk.java.net/browse/JDK-8173901: Linux: Position 
>> of Stage is not restored after exiting full screen
>>
>> 12.https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: Dialog 
>> windows come up 1-pixel wide
>>
>> 13.https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: Stage 
>> initially in full-screen mode not shown when exiting full-screen
>>
>> 14.https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown 
>> position regression and not painting correctly tooltips regression
>>
>> 15.https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not always 
>> selected properly with GTK 3
>>
>> 16.https://bugs.openjdk.java.net/browse/JDK-8172219: Allow compiling 
>> without GTK 3.0 being installed
>>
>> 17.https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk 
>> version if SWT used via FXCanvas
>>
>> 18.https://bugs.openjdk.java.net/browse/JDK-8156491: Autodetect GTK 
>> version for JFX
>>
>> The original gtk3 backport patch applied cleanly, but the bugs did 
>> not apply cleanly. So a review is required.
>>
>> I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu 16.04 
>> LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux 7.5.
>>
>> webrev: http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8087516
>>
>> JDK 9 Changeset: 
>> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
>>
>> Regards,
>>
>> Pankaj
>>
>


From tom.schindl at bestsolution.at  Thu Oct  4 11:10:30 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Thu, 4 Oct 2018 13:10:30 +0200
Subject: Bad DropShadow performance
Message-ID: <1d865181-c33f-d09f-7adb-de98aaeeb405@bestsolution.at>

Hi,

Why does applying a DropShadow on a large region cause problem when
animating nodes contained in that region?

> package fxbugs;
> 
> import javafx.animation.ScaleTransition;
> import javafx.application.Application;
> import javafx.geometry.Insets;
> import javafx.scene.Node;
> import javafx.scene.Scene;
> import javafx.scene.control.Button;
> import javafx.scene.effect.BlurType;
> import javafx.scene.effect.DropShadow;
> import javafx.scene.layout.BorderPane;
> import javafx.scene.layout.GridPane;
> import javafx.scene.paint.Color;
> import javafx.stage.Stage;
> import javafx.util.Duration;
> 
> public class DropShadowPerformance extends Application {
> 
>     @Override
>     public void start(Stage primaryStage) throws Exception {
>         BorderPane p = new BorderPane();
>         p.setPadding(new Insets(30));
>         
>         GridPane container = new GridPane();
>         container.setHgap(10);
>         container.setVgap(10);
>         container.setStyle("-fx-background-color: green; -fx-padding: 10;");
>         container.setEffect(new DropShadow(BlurType.GAUSSIAN, Color.rgb(0, 0, 0, 0.3), 10, 0.5, 0, 0));
>         for( int i = 0; i < 8; i++ ) {
>             for( int j = 0; j < 14; j++ ) {
>                 container.add(createButton(), i, j);
>             }
>         }
>         p.setCenter(container);
>         
>         Scene s = new Scene(p, 800, 600);
>         primaryStage.setScene(s);
>         primaryStage.show();
>     }
> 
>     private Node createButton() {
>         Button button = new Button("hello world");
>         button.hoverProperty().addListener((ob,ol,ne) -> {
>             ScaleTransition t = new ScaleTransition(Duration.millis(500), button);
>             
>             if( ne ) {
>                 t.setFromX(1);
>                 t.setFromY(1);
>                 t.setToX(1.2);
>                 t.setToY(1.2);
>             } else {
>                 t.setFromX(1.2);
>                 t.setFromY(1.2);
>                 t.setToX(1);
>                 t.setToY(1);
>             }
>             
>             t.play();
>         });
>         return button;
>     }
>     
>     public static void main(String[] args) {
>         launch(args);
>     }
> }


If you run the following application:
* Maximize the window
* Hover over a button (eg the one in the right lower corner)

You'll notice that the animation is not smooth, setting cache flags on
the container does not improve the situation, nor does using a ONE_PASS_BOX.

Removing the effect on the container node "fixes" the problem.

This is on a MacBook Pro and Windows Surface both having a Intel Iris
Plus 650 graphics card.

Tom

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From marcel.au at web.de  Thu Oct  4 13:03:02 2018
From: marcel.au at web.de (marcel Austenfeld)
Date: Thu, 4 Oct 2018 15:03:02 +0200
Subject: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
In-Reply-To: <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
References: <trinity-8859f5f3-6c80-4309-bc9c-abfdc1ae31ed-1537960969645@3c-app-webde-bs17>
 <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
Message-ID: <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>

Hello Kevin,
?
I still have problems with the error: "java.lang.IllegalStateException: Toolkit already initialized".
?
However I found out that this error only occurs if I call SWT FXCanvas classes located in different Eclipse plugins.
?
I can create multiple JavaFX canvas if they are located in one Eclipse plugin.
?
Vice versa if I try to to open the JavaFX SceneBuilder canvas which is located in a seperate Eclipse plugin this error occurs again.
?
So I wonder that beginning with Java 9 the JavaFX toolkit doesn't recognize an already started toolkit in another Eclipse plugin (which was definitely the case with Java 8!).
?
Maybee this has something to do with the new module system of Java >=9?
?
?
?

Gesendet:?Mittwoch, 26. September 2018 um 14:09 Uhr
Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
An:?"marcel Austenfeld" <marcel.au at web.de>, openjfx-dev at openjdk.java.net
Betreff:?Re: "Toolkit already initialized" error with OpenJDK 11
I'm' not aware of anything that intentionally changed between FX in JDK
8 and FX 11, but my guess is that the FX runtime is being shutdown after
your first FXCanvas exits. Try making the following call (only needed
one time) before creating your first FXCanvas:

??? Platform.setImplicitExit(false);

-- Kevin

On 9/26/2018 4:22 AM, marcel Austenfeld wrote:
> First of all congratulation to the new release and thank you for the hard work on JavaFX.
>
>
> I have a problem with JavaFX which in my case is embedded in a Rich Client Platform of Eclipse.
>
> I integrated several SWT FXCanvas (some with SwingNode panels as a SWT_AWT replacement) into my app.
>
> This works fine in Java 8 which my current release depends on.
>
> However in Java 11 after the second panel is initialized at startup I get the following error:
>
> "Caused by: java.lang.IllegalStateException: Toolkit already initialized"
>
> Is there a new option available to avoid a new initialization of the toolkit if several FXCanvas are embedded in an application?
> Or do you now any changes since Java 8 which could the cause of such an exception?
>
>
> Thanks in advance for any help.
?

From kevin.rushforth at oracle.com  Thu Oct  4 14:13:51 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 4 Oct 2018 07:13:51 -0700
Subject: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
In-Reply-To: <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
References: <trinity-8859f5f3-6c80-4309-bc9c-abfdc1ae31ed-1537960969645@3c-app-webde-bs17>
 <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
 <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
Message-ID: <62f72fa3-fe83-33f7-60f8-1545579b3d55@oracle.com>

I think I see what caused this. In FX 8 we called FXCanvas::initFx from 
the constructor of every FXCanvas. It then called an internal startup 
method, PlatformImpl::startup, that permits calling it when the Toolkit 
is already initialized, turning it into a runLater if it is. As part of 
the refactoring for FX 9 I changed it to call FXCanvas::initFx one time 
from the static block. At the same time, I changed the startup call to 
use the public Platform::startup method. This change was necessary 
because the javafx.swt module does not have the needed qualified exports 
to call internal methods until after initialization. The public 
Platform::startup method is specified to throw an exception if called 
more than once.

So if the FXCanvas class is loaded more than once, for example, if it is 
called from different ClassLoaders, then that would cause the problem. 
Please file a bug and I'll take a look at it. It might be as simple as 
wrapping the call to Platform::startup in a try/catch and calling 
Platform::runLater in the catch block.

-- Kevin


On 10/4/2018 6:03 AM, marcel Austenfeld wrote:
> Hello Kevin,
>   
> I still have problems with the error: "java.lang.IllegalStateException: Toolkit already initialized".
>   
> However I found out that this error only occurs if I call SWT FXCanvas classes located in different Eclipse plugins.
>   
> I can create multiple JavaFX canvas if they are located in one Eclipse plugin.
>   
> Vice versa if I try to to open the JavaFX SceneBuilder canvas which is located in a seperate Eclipse plugin this error occurs again.
>   
> So I wonder that beginning with Java 9 the JavaFX toolkit doesn't recognize an already started toolkit in another Eclipse plugin (which was definitely the case with Java 8!).
>   
> Maybee this has something to do with the new module system of Java >=9?
>   
>   
>   
>
> Gesendet:?Mittwoch, 26. September 2018 um 14:09 Uhr
> Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
> An:?"marcel Austenfeld" <marcel.au at web.de>, openjfx-dev at openjdk.java.net
> Betreff:?Re: "Toolkit already initialized" error with OpenJDK 11
> I'm' not aware of anything that intentionally changed between FX in JDK
> 8 and FX 11, but my guess is that the FX runtime is being shutdown after
> your first FXCanvas exits. Try making the following call (only needed
> one time) before creating your first FXCanvas:
>
>  ??? Platform.setImplicitExit(false);
>
> -- Kevin
>
> On 9/26/2018 4:22 AM, marcel Austenfeld wrote:
>> First of all congratulation to the new release and thank you for the hard work on JavaFX.
>>
>>
>> I have a problem with JavaFX which in my case is embedded in a Rich Client Platform of Eclipse.
>>
>> I integrated several SWT FXCanvas (some with SwingNode panels as a SWT_AWT replacement) into my app.
>>
>> This works fine in Java 8 which my current release depends on.
>>
>> However in Java 11 after the second panel is initialized at startup I get the following error:
>>
>> "Caused by: java.lang.IllegalStateException: Toolkit already initialized"
>>
>> Is there a new option available to avoid a new initialization of the toolkit if several FXCanvas are embedded in an application?
>> Or do you now any changes since Java 8 which could the cause of such an exception?
>>
>>
>> Thanks in advance for any help.
>   


From tom.schindl at bestsolution.at  Thu Oct  4 14:35:17 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Thu, 4 Oct 2018 16:35:17 +0200
Subject: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
In-Reply-To: <62f72fa3-fe83-33f7-60f8-1545579b3d55@oracle.com>
References: <trinity-8859f5f3-6c80-4309-bc9c-abfdc1ae31ed-1537960969645@3c-app-webde-bs17>
 <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
 <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
 <62f72fa3-fe83-33f7-60f8-1545579b3d55@oracle.com>
Message-ID: <9bd067e5-609f-f4b4-ad9a-00927ac0853b@bestsolution.at>

Hi,

FXCanvas should not be loaded multiple times. This sounds like a severe
bug in e(fx)clipse OSGi-Adapterhooks.

Tom

On 04.10.18 16:13, Kevin Rushforth wrote:
> I think I see what caused this. In FX 8 we called FXCanvas::initFx from
> the constructor of every FXCanvas. It then called an internal startup
> method, PlatformImpl::startup, that permits calling it when the Toolkit
> is already initialized, turning it into a runLater if it is. As part of
> the refactoring for FX 9 I changed it to call FXCanvas::initFx one time
> from the static block. At the same time, I changed the startup call to
> use the public Platform::startup method. This change was necessary
> because the javafx.swt module does not have the needed qualified exports
> to call internal methods until after initialization. The public
> Platform::startup method is specified to throw an exception if called
> more than once.
> 
> So if the FXCanvas class is loaded more than once, for example, if it is
> called from different ClassLoaders, then that would cause the problem.
> Please file a bug and I'll take a look at it. It might be as simple as
> wrapping the call to Platform::startup in a try/catch and calling
> Platform::runLater in the catch block.
> 
> -- Kevin
> 
> 
> On 10/4/2018 6:03 AM, marcel Austenfeld wrote:
>> Hello Kevin,
>> ? I still have problems with the error:
>> "java.lang.IllegalStateException: Toolkit already initialized".
>> ? However I found out that this error only occurs if I call SWT
>> FXCanvas classes located in different Eclipse plugins.
>> ? I can create multiple JavaFX canvas if they are located in one
>> Eclipse plugin.
>> ? Vice versa if I try to to open the JavaFX SceneBuilder canvas which
>> is located in a seperate Eclipse plugin this error occurs again.
>> ? So I wonder that beginning with Java 9 the JavaFX toolkit doesn't
>> recognize an already started toolkit in another Eclipse plugin (which
>> was definitely the case with Java 8!).
>> ? Maybee this has something to do with the new module system of Java >=9?
>> ? ? ?
>> Gesendet:?Mittwoch, 26. September 2018 um 14:09 Uhr
>> Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
>> An:?"marcel Austenfeld" <marcel.au at web.de>, openjfx-dev at openjdk.java.net
>> Betreff:?Re: "Toolkit already initialized" error with OpenJDK 11
>> I'm' not aware of anything that intentionally changed between FX in JDK
>> 8 and FX 11, but my guess is that the FX runtime is being shutdown after
>> your first FXCanvas exits. Try making the following call (only needed
>> one time) before creating your first FXCanvas:
>>
>> ???? Platform.setImplicitExit(false);
>>
>> -- Kevin
>>
>> On 9/26/2018 4:22 AM, marcel Austenfeld wrote:
>>> First of all congratulation to the new release and thank you for the
>>> hard work on JavaFX.
>>>
>>>
>>> I have a problem with JavaFX which in my case is embedded in a Rich
>>> Client Platform of Eclipse.
>>>
>>> I integrated several SWT FXCanvas (some with SwingNode panels as a
>>> SWT_AWT replacement) into my app.
>>>
>>> This works fine in Java 8 which my current release depends on.
>>>
>>> However in Java 11 after the second panel is initialized at startup I
>>> get the following error:
>>>
>>> "Caused by: java.lang.IllegalStateException: Toolkit already
>>> initialized"
>>>
>>> Is there a new option available to avoid a new initialization of the
>>> toolkit if several FXCanvas are embedded in an application?
>>> Or do you now any changes since Java 8 which could the cause of such
>>> an exception?
>>>
>>>
>>> Thanks in advance for any help.
>> ? 
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From tom.schindl at bestsolution.at  Thu Oct  4 14:44:29 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Thu, 4 Oct 2018 16:44:29 +0200
Subject: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
In-Reply-To: <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
References: <trinity-8859f5f3-6c80-4309-bc9c-abfdc1ae31ed-1537960969645@3c-app-webde-bs17>
 <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
 <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
Message-ID: <a27d3ad7-fedd-3a92-7cf2-61e45597a7b0@bestsolution.at>

Hi,

Just to make sure I understand. Do you say that other OSGi-Bundles bring
with them their own FXCanvas?

I've been looking at the e(fx)clipse code [1] who deals with FXCanvas,
... but I can't think of a situation where we create multiple classloaders.

Tom

[1]
https://github.com/eclipse/efxclipse-rt/blob/3.x/modules/core/org.eclipse.fx.osgi/src/main/java/org/eclipse/fx/osgi/fxloader/FXClassLoader.java

On 04.10.18 15:03, marcel Austenfeld wrote:
> Hello Kevin,
> ?
> I still have problems with the error: "java.lang.IllegalStateException: Toolkit already initialized".
> ?
> However I found out that this error only occurs if I call SWT FXCanvas classes located in different Eclipse plugins.
> ?
> I can create multiple JavaFX canvas if they are located in one Eclipse plugin.
> ?
> Vice versa if I try to to open the JavaFX SceneBuilder canvas which is located in a seperate Eclipse plugin this error occurs again.
> ?
> So I wonder that beginning with Java 9 the JavaFX toolkit doesn't recognize an already started toolkit in another Eclipse plugin (which was definitely the case with Java 8!).
> ?
> Maybee this has something to do with the new module system of Java >=9?
> ?
> ?
> ?
> 
> Gesendet:?Mittwoch, 26. September 2018 um 14:09 Uhr
> Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
> An:?"marcel Austenfeld" <marcel.au at web.de>, openjfx-dev at openjdk.java.net
> Betreff:?Re: "Toolkit already initialized" error with OpenJDK 11
> I'm' not aware of anything that intentionally changed between FX in JDK
> 8 and FX 11, but my guess is that the FX runtime is being shutdown after
> your first FXCanvas exits. Try making the following call (only needed
> one time) before creating your first FXCanvas:
> 
> ??? Platform.setImplicitExit(false);
> 
> -- Kevin
> 
> On 9/26/2018 4:22 AM, marcel Austenfeld wrote:
>> First of all congratulation to the new release and thank you for the hard work on JavaFX.
>>
>>
>> I have a problem with JavaFX which in my case is embedded in a Rich Client Platform of Eclipse.
>>
>> I integrated several SWT FXCanvas (some with SwingNode panels as a SWT_AWT replacement) into my app.
>>
>> This works fine in Java 8 which my current release depends on.
>>
>> However in Java 11 after the second panel is initialized at startup I get the following error:
>>
>> "Caused by: java.lang.IllegalStateException: Toolkit already initialized"
>>
>> Is there a new option available to avoid a new initialization of the toolkit if several FXCanvas are embedded in an application?
>> Or do you now any changes since Java 8 which could the cause of such an exception?
>>
>>
>> Thanks in advance for any help.
> ?
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From johan.vos at gluonhq.com  Thu Oct  4 17:01:08 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 4 Oct 2018 19:01:08 +0200
Subject: JavaFX 11 on Android
Message-ID: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>

Hi,

I worked from the openjfx/develop repository and created a version that
works on Android (will work on iOS soon).
This required some changes, as we're running on top of the Android VM,
which is not really Java (not even close).
The longer-term goal is to run a JVM on Android as well, but that is not
something to discuss in this topic.

The changes I had to make are in this diff:
https://github.com/javafxports/openjdk-jfx/compare/develop...johanvos:android

There are a number of changes:

1. Changes in the Android specific files (e.g. FXDalvikEntity): those are
mainly changes we did in the 8-tree, but that were never sent upstream. I
think most of those can be upstreamed (after cleanup and review of course)

2. Changes in Monocle, mainly related to scale factor and HiDPI. Those can
probably be upstreamed as well

3. Changes in the buildSrc/dalvik.gradle. Those are android-only, so can be
upstreamed too.

4. Changes in common java classes (e.g. no System.Logger). Those are a
problem.

While I am in favour of leveraging the latest version of Java for doing
JavaFX development, I do realise this breaks the Android port (not the iOS
port, as we use a VM based on OpenJDK already there).
While in theory we could deal with this using reflection (and this has been
done in the 8-tree, e.g. for isIdeographic()), I don't think this is a good
idea.

My proposal would therefore be that I split the changes into
Android/Dalvik/Monocle changes that do not affect any other platform, and
create PR's for merging these changes in upstream. While my prototype is
working (see https://twitter.com/johanvos/status/1047804607320260608)  I
need to clean up the patches, and I suggest I create smaller PR's that are
easier to digest.

For the changes in the common classes, I think it's best to use a fork, or
to patch the system at build time -- rather than polluting the main
repository with reflection-based checks.

Thoughts?

- Johan

From sverre.moe at gmail.com  Thu Oct  4 17:10:24 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Thu, 4 Oct 2018 19:10:24 +0200
Subject: JavaFX 11 on Android
In-Reply-To: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>
References: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>
Message-ID: <CALAJ+5AK+d1Wwvme_oMT7xBeaVv1N9qK1-QCz4sfFztun5YeLg@mail.gmail.com>

Den tor. 4. okt. 2018 kl. 19:01 skrev Johan Vos <johan.vos at gluonhq.com>:

> Hi,
>
> I worked from the openjfx/develop repository and created a version that
> works on Android (will work on iOS soon).
> This required some changes, as we're running on top of the Android VM,
> which is not really Java (not even close).
>
> How so? Didn't Google replace their own Java implementation with OpenJDK?
That switch was made in Android N two years ago.
Maybe I am off base here. I haven't been fiddling around Android much for
some years.

/Sverre

From nlisker at gmail.com  Thu Oct  4 18:00:48 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 4 Oct 2018 21:00:48 +0300
Subject: JavaFX 11 on Android
In-Reply-To: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>
References: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>
Message-ID: <CA+0ynh-3rPgiuZExOhm5Hn9uJ3eiM+rwpRb+i5x7YJUH4LNkWg@mail.gmail.com>

Hi Johan,

Thanks for the work. A couple of questions:


> I worked from the openjfx/develop repository and created a version that
> works on Android (will work on iOS soon).


I'm not very familiar with the state of mobile. Doesn't Android support
only up to Java 8 API? What happens if there is 'var' in the codebase, for
example?

4. Changes in common java classes (e.g. no System.Logger). Those are a
> problem.


If System.Logger is not available on Android an iOS, what is available
instead? jul or a native logger?

- Nir

On Thu, Oct 4, 2018 at 8:01 PM Johan Vos <johan.vos at gluonhq.com> wrote:

> Hi,
>
> I worked from the openjfx/develop repository and created a version that
> works on Android (will work on iOS soon).
> This required some changes, as we're running on top of the Android VM,
> which is not really Java (not even close).
> The longer-term goal is to run a JVM on Android as well, but that is not
> something to discuss in this topic.
>
> The changes I had to make are in this diff:
>
> https://github.com/javafxports/openjdk-jfx/compare/develop...johanvos:android
>
> There are a number of changes:
>
> 1. Changes in the Android specific files (e.g. FXDalvikEntity): those are
> mainly changes we did in the 8-tree, but that were never sent upstream. I
> think most of those can be upstreamed (after cleanup and review of course)
>
> 2. Changes in Monocle, mainly related to scale factor and HiDPI. Those can
> probably be upstreamed as well
>
> 3. Changes in the buildSrc/dalvik.gradle. Those are android-only, so can be
> upstreamed too.
>
> 4. Changes in common java classes (e.g. no System.Logger). Those are a
> problem.
>
> While I am in favour of leveraging the latest version of Java for doing
> JavaFX development, I do realise this breaks the Android port (not the iOS
> port, as we use a VM based on OpenJDK already there).
> While in theory we could deal with this using reflection (and this has been
> done in the 8-tree, e.g. for isIdeographic()), I don't think this is a good
> idea.
>
> My proposal would therefore be that I split the changes into
> Android/Dalvik/Monocle changes that do not affect any other platform, and
> create PR's for merging these changes in upstream. While my prototype is
> working (see https://twitter.com/johanvos/status/1047804607320260608)  I
> need to clean up the patches, and I suggest I create smaller PR's that are
> easier to digest.
>
> For the changes in the common classes, I think it's best to use a fork, or
> to patch the system at build time -- rather than polluting the main
> repository with reflection-based checks.
>
> Thoughts?
>
> - Johan
>

From johan.vos at gluonhq.com  Thu Oct  4 18:07:20 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 4 Oct 2018 20:07:20 +0200
Subject: JavaFX 11 on Android
In-Reply-To: <CALAJ+5AK+d1Wwvme_oMT7xBeaVv1N9qK1-QCz4sfFztun5YeLg@mail.gmail.com>
References: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>
 <CALAJ+5AK+d1Wwvme_oMT7xBeaVv1N9qK1-QCz4sfFztun5YeLg@mail.gmail.com>
Message-ID: <CABxFH2FP0zVgRdUWJuGc-5P_Fx3PbK5nwe5kSMpDAthxSp461A@mail.gmail.com>

On Thu, Oct 4, 2018 at 7:10 PM Sverre Moe <sverre.moe at gmail.com> wrote:

> Den tor. 4. okt. 2018 kl. 19:01 skrev Johan Vos <johan.vos at gluonhq.com>:
>
>> Hi,
>>
>> I worked from the openjfx/develop repository and created a version that
>> works on Android (will work on iOS soon).
>> This required some changes, as we're running on top of the Android VM,
>> which is not really Java (not even close).
>>
>> How so? Didn't Google replace their own Java implementation with OpenJDK?
> That switch was made in Android N two years ago.
> Maybe I am off base here. I haven't been fiddling around Android much for
> some years.
>

They're pretty selective.
For some reason, they have some classes (e.g. sun.misc.SharedSecrets) that
are missing some methods.

Even if Android would be OpenJDK 8 (which it is not), that's not 11 and
it's impossible to predict when Google wants to move to 9/10/11

From johan.vos at gluonhq.com  Thu Oct  4 18:13:26 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 4 Oct 2018 20:13:26 +0200
Subject: JavaFX 11 on Android
In-Reply-To: <CA+0ynh-3rPgiuZExOhm5Hn9uJ3eiM+rwpRb+i5x7YJUH4LNkWg@mail.gmail.com>
References: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>
 <CA+0ynh-3rPgiuZExOhm5Hn9uJ3eiM+rwpRb+i5x7YJUH4LNkWg@mail.gmail.com>
Message-ID: <CABxFH2FzUCXLbs1jk2=yAnNR70c-WUbp+8-npoP3xf_78Tdz3Q@mail.gmail.com>

On Thu, Oct 4, 2018 at 8:01 PM Nir Lisker <nlisker at gmail.com> wrote:

> Hi Johan,
>
> Thanks for the work. A couple of questions:
>
>
>> I worked from the openjfx/develop repository and created a version that
>> works on Android (will work on iOS soon).
>
>
> I'm not very familiar with the state of mobile. Doesn't Android support
> only up to Java 8 API? What happens if there is 'var' in the codebase, for
> example?
>

"var" will be ok as I think that has no influence at runtime?
But indeed, there are other things (e.g. try-resource with variable) that
can not be used on Android. In general, there are too much restrictions,
which is why we need a bundled Java 11 in the longer term.


>
> 4. Changes in common java classes (e.g. no System.Logger). Those are a
>> problem.
>
>
> If System.Logger is not available on Android an iOS, what is available
> instead? jul or a native logger?
>

We use java.util.logging for now.


>
> - Nir
>
> On Thu, Oct 4, 2018 at 8:01 PM Johan Vos <johan.vos at gluonhq.com> wrote:
>
>> Hi,
>>
>> I worked from the openjfx/develop repository and created a version that
>> works on Android (will work on iOS soon).
>> This required some changes, as we're running on top of the Android VM,
>> which is not really Java (not even close).
>> The longer-term goal is to run a JVM on Android as well, but that is not
>> something to discuss in this topic.
>>
>> The changes I had to make are in this diff:
>>
>> https://github.com/javafxports/openjdk-jfx/compare/develop...johanvos:android
>>
>> There are a number of changes:
>>
>> 1. Changes in the Android specific files (e.g. FXDalvikEntity): those are
>> mainly changes we did in the 8-tree, but that were never sent upstream. I
>> think most of those can be upstreamed (after cleanup and review of course)
>>
>> 2. Changes in Monocle, mainly related to scale factor and HiDPI. Those can
>> probably be upstreamed as well
>>
>> 3. Changes in the buildSrc/dalvik.gradle. Those are android-only, so can
>> be
>> upstreamed too.
>>
>> 4. Changes in common java classes (e.g. no System.Logger). Those are a
>> problem.
>>
>> While I am in favour of leveraging the latest version of Java for doing
>> JavaFX development, I do realise this breaks the Android port (not the iOS
>> port, as we use a VM based on OpenJDK already there).
>> While in theory we could deal with this using reflection (and this has
>> been
>> done in the 8-tree, e.g. for isIdeographic()), I don't think this is a
>> good
>> idea.
>>
>> My proposal would therefore be that I split the changes into
>> Android/Dalvik/Monocle changes that do not affect any other platform, and
>> create PR's for merging these changes in upstream. While my prototype is
>> working (see https://twitter.com/johanvos/status/1047804607320260608)  I
>> need to clean up the patches, and I suggest I create smaller PR's that are
>> easier to digest.
>>
>> For the changes in the common classes, I think it's best to use a fork, or
>> to patch the system at build time -- rather than polluting the main
>> repository with reflection-based checks.
>>
>> Thoughts?
>>
>> - Johan
>>
>

From tom.schindl at bestsolution.at  Thu Oct  4 18:14:16 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Thu, 4 Oct 2018 20:14:16 +0200
Subject: JavaFX 11 on Android
In-Reply-To: <CA+0ynh-3rPgiuZExOhm5Hn9uJ3eiM+rwpRb+i5x7YJUH4LNkWg@mail.gmail.com>
References: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>
 <CA+0ynh-3rPgiuZExOhm5Hn9uJ3eiM+rwpRb+i5x7YJUH4LNkWg@mail.gmail.com>
Message-ID: <34248616-265c-5c23-c009-b783920906a5@bestsolution.at>



On 04.10.18 20:00, Nir Lisker wrote:
> Hi Johan,
> 
> Thanks for the work. A couple of questions:
> 
> 
>> I worked from the openjfx/develop repository and created a version that
>> works on Android (will work on iOS soon).
> 
> 
> I'm not very familiar with the state of mobile. Doesn't Android support
> only up to Java 8 API? What happens if there is 'var' in the codebase, for
> example?

var is a compiler only thing so it is independent of the runtime where
the bytecode is 100% the same ;-)

Tom

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From dlemmermann at gmail.com  Thu Oct  4 18:32:31 2018
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Thu, 4 Oct 2018 20:32:31 +0200
Subject: Bad DropShadow performance
In-Reply-To: <1d865181-c33f-d09f-7adb-de98aaeeb405@bestsolution.at>
References: <1d865181-c33f-d09f-7adb-de98aaeeb405@bestsolution.at>
Message-ID: <26CF2772-B099-42D2-A4E9-9A5A866DF079@gmail.com>

Yes, I also noticed that DropShadow causes severe performance degradation.

Dirk

> On 4 Oct 2018, at 13:10, Tom Schindl <tom.schindl at bestsolution.at> wrote:
> 
> Hi,
> 
> Why does applying a DropShadow on a large region cause problem when
> animating nodes contained in that region?
> 
>> package fxbugs;
>> 
>> import javafx.animation.ScaleTransition;
>> import javafx.application.Application;
>> import javafx.geometry.Insets;
>> import javafx.scene.Node;
>> import javafx.scene.Scene;
>> import javafx.scene.control.Button;
>> import javafx.scene.effect.BlurType;
>> import javafx.scene.effect.DropShadow;
>> import javafx.scene.layout.BorderPane;
>> import javafx.scene.layout.GridPane;
>> import javafx.scene.paint.Color;
>> import javafx.stage.Stage;
>> import javafx.util.Duration;
>> 
>> public class DropShadowPerformance extends Application {
>> 
>>    @Override
>>    public void start(Stage primaryStage) throws Exception {
>>        BorderPane p = new BorderPane();
>>        p.setPadding(new Insets(30));
>> 
>>        GridPane container = new GridPane();
>>        container.setHgap(10);
>>        container.setVgap(10);
>>        container.setStyle("-fx-background-color: green; -fx-padding: 10;");
>>        container.setEffect(new DropShadow(BlurType.GAUSSIAN, Color.rgb(0, 0, 0, 0.3), 10, 0.5, 0, 0));
>>        for( int i = 0; i < 8; i++ ) {
>>            for( int j = 0; j < 14; j++ ) {
>>                container.add(createButton(), i, j);
>>            }
>>        }
>>        p.setCenter(container);
>> 
>>        Scene s = new Scene(p, 800, 600);
>>        primaryStage.setScene(s);
>>        primaryStage.show();
>>    }
>> 
>>    private Node createButton() {
>>        Button button = new Button("hello world");
>>        button.hoverProperty().addListener((ob,ol,ne) -> {
>>            ScaleTransition t = new ScaleTransition(Duration.millis(500), button);
>> 
>>            if( ne ) {
>>                t.setFromX(1);
>>                t.setFromY(1);
>>                t.setToX(1.2);
>>                t.setToY(1.2);
>>            } else {
>>                t.setFromX(1.2);
>>                t.setFromY(1.2);
>>                t.setToX(1);
>>                t.setToY(1);
>>            }
>> 
>>            t.play();
>>        });
>>        return button;
>>    }
>> 
>>    public static void main(String[] args) {
>>        launch(args);
>>    }
>> }
> 
> 
> If you run the following application:
> * Maximize the window
> * Hover over a button (eg the one in the right lower corner)
> 
> You'll notice that the animation is not smooth, setting cache flags on
> the container does not improve the situation, nor does using a ONE_PASS_BOX.
> 
> Removing the effect on the container node "fixes" the problem.
> 
> This is on a MacBook Pro and Windows Surface both having a Intel Iris
> Plus 650 graphics card.
> 
> Tom
> 
> -- 
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck


From nlisker at gmail.com  Thu Oct  4 18:45:43 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 4 Oct 2018 21:45:43 +0300
Subject: JavaFX 11 on Android
In-Reply-To: <CABxFH2FzUCXLbs1jk2=yAnNR70c-WUbp+8-npoP3xf_78Tdz3Q@mail.gmail.com>
References: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>
 <CA+0ynh-3rPgiuZExOhm5Hn9uJ3eiM+rwpRb+i5x7YJUH4LNkWg@mail.gmail.com>
 <CABxFH2FzUCXLbs1jk2=yAnNR70c-WUbp+8-npoP3xf_78Tdz3Q@mail.gmail.com>
Message-ID: <CA+0ynh8OuF6ke2jGobzNQtY=pAvmpNHj_oMyMhAkdyUM4a2uww@mail.gmail.com>

>
> But indeed, there are other things (e.g. try-resource with variable) that
> can not be used on Android. In general, there are too much restrictions,
> which is why we need a bundled Java 11 in the longer term.


How does JavaFXPorts deal with this?

We use java.util.logging for now.


That will require reverting the work of removing it [1] :) So yes, a fork
seems adequate for now and in the future we can re-evaluate the need for
j.u.l. (related: [2]).

[1] https://bugs.openjdk.java.net/browse/JDK-8195974
[2] https://bugs.openjdk.java.net/browse/JDK-8209036

On Thu, Oct 4, 2018 at 9:13 PM Johan Vos <johan.vos at gluonhq.com> wrote:

>
>
> On Thu, Oct 4, 2018 at 8:01 PM Nir Lisker <nlisker at gmail.com> wrote:
>
>> Hi Johan,
>>
>> Thanks for the work. A couple of questions:
>>
>>
>>> I worked from the openjfx/develop repository and created a version that
>>> works on Android (will work on iOS soon).
>>
>>
>> I'm not very familiar with the state of mobile. Doesn't Android support
>> only up to Java 8 API? What happens if there is 'var' in the codebase, for
>> example?
>>
>
> "var" will be ok as I think that has no influence at runtime?
> But indeed, there are other things (e.g. try-resource with variable) that
> can not be used on Android. In general, there are too much restrictions,
> which is why we need a bundled Java 11 in the longer term.
>
>
>>
>> 4. Changes in common java classes (e.g. no System.Logger). Those are a
>>> problem.
>>
>>
>> If System.Logger is not available on Android an iOS, what is available
>> instead? jul or a native logger?
>>
>
> We use java.util.logging for now.
>
>
>>
>> - Nir
>>
>> On Thu, Oct 4, 2018 at 8:01 PM Johan Vos <johan.vos at gluonhq.com> wrote:
>>
>>> Hi,
>>>
>>> I worked from the openjfx/develop repository and created a version that
>>> works on Android (will work on iOS soon).
>>> This required some changes, as we're running on top of the Android VM,
>>> which is not really Java (not even close).
>>> The longer-term goal is to run a JVM on Android as well, but that is not
>>> something to discuss in this topic.
>>>
>>> The changes I had to make are in this diff:
>>>
>>> https://github.com/javafxports/openjdk-jfx/compare/develop...johanvos:android
>>>
>>> There are a number of changes:
>>>
>>> 1. Changes in the Android specific files (e.g. FXDalvikEntity): those are
>>> mainly changes we did in the 8-tree, but that were never sent upstream. I
>>> think most of those can be upstreamed (after cleanup and review of
>>> course)
>>>
>>> 2. Changes in Monocle, mainly related to scale factor and HiDPI. Those
>>> can
>>> probably be upstreamed as well
>>>
>>> 3. Changes in the buildSrc/dalvik.gradle. Those are android-only, so can
>>> be
>>> upstreamed too.
>>>
>>> 4. Changes in common java classes (e.g. no System.Logger). Those are a
>>> problem.
>>>
>>> While I am in favour of leveraging the latest version of Java for doing
>>> JavaFX development, I do realise this breaks the Android port (not the
>>> iOS
>>> port, as we use a VM based on OpenJDK already there).
>>> While in theory we could deal with this using reflection (and this has
>>> been
>>> done in the 8-tree, e.g. for isIdeographic()), I don't think this is a
>>> good
>>> idea.
>>>
>>> My proposal would therefore be that I split the changes into
>>> Android/Dalvik/Monocle changes that do not affect any other platform, and
>>> create PR's for merging these changes in upstream. While my prototype is
>>> working (see https://twitter.com/johanvos/status/1047804607320260608)  I
>>> need to clean up the patches, and I suggest I create smaller PR's that
>>> are
>>> easier to digest.
>>>
>>> For the changes in the common classes, I think it's best to use a fork,
>>> or
>>> to patch the system at build time -- rather than polluting the main
>>> repository with reflection-based checks.
>>>
>>> Thoughts?
>>>
>>> - Johan
>>>
>>

From david.grieve at oracle.com  Thu Oct  4 19:17:54 2018
From: david.grieve at oracle.com (David Grieve)
Date: Thu, 4 Oct 2018 15:17:54 -0400
Subject: JavaFX 11 on Android
In-Reply-To: <CA+0ynh8OuF6ke2jGobzNQtY=pAvmpNHj_oMyMhAkdyUM4a2uww@mail.gmail.com>
References: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>
 <CA+0ynh-3rPgiuZExOhm5Hn9uJ3eiM+rwpRb+i5x7YJUH4LNkWg@mail.gmail.com>
 <CABxFH2FzUCXLbs1jk2=yAnNR70c-WUbp+8-npoP3xf_78Tdz3Q@mail.gmail.com>
 <CA+0ynh8OuF6ke2jGobzNQtY=pAvmpNHj_oMyMhAkdyUM4a2uww@mail.gmail.com>
Message-ID: <3209d159-4882-b7a2-f9bd-7d648de75fe2@oracle.com>

You just need Android Studio 3 for try-with-resources. See 
https://developer.android.com/studio/write/java8-support

I've never had a problem using java.util.logging with Android. Logging 
ends up in logcat.

On 10/4/18 2:45 PM, Nir Lisker wrote:
>> But indeed, there are other things (e.g. try-resource with variable) that
>> can not be used on Android. In general, there are too much restrictions,
>> which is why we need a bundled Java 11 in the longer term.

>
> How does JavaFXPorts deal with this?
>
> We use java.util.logging for now.
>
>
> That will require reverting the work of removing it [1] :) So yes, a fork
> seems adequate for now and in the future we can re-evaluate the need for
> j.u.l. (related: [2]).
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8195974
> [2] https://bugs.openjdk.java.net/browse/JDK-8209036
>
> On Thu, Oct 4, 2018 at 9:13 PM Johan Vos <johan.vos at gluonhq.com> wrote:
>
>>
>> On Thu, Oct 4, 2018 at 8:01 PM Nir Lisker <nlisker at gmail.com> wrote:
>>
>>> Hi Johan,
>>>
>>> Thanks for the work. A couple of questions:
>>>
>>>
>>>> I worked from the openjfx/develop repository and created a version that
>>>> works on Android (will work on iOS soon).
>>>
>>> I'm not very familiar with the state of mobile. Doesn't Android support
>>> only up to Java 8 API? What happens if there is 'var' in the codebase, for
>>> example?
>>>
>> "var" will be ok as I think that has no influence at runtime?
>> But indeed, there are other things (e.g. try-resource with variable) that
>> can not be used on Android. In general, there are too much restrictions,
>> which is why we need a bundled Java 11 in the longer term.
>>
>>
>>> 4. Changes in common java classes (e.g. no System.Logger). Those are a
>>>> problem.
>>>
>>> If System.Logger is not available on Android an iOS, what is available
>>> instead? jul or a native logger?
>>>
>> We use java.util.logging for now.
>>
>>
>>> - Nir
>>>
>>> On Thu, Oct 4, 2018 at 8:01 PM Johan Vos <johan.vos at gluonhq.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I worked from the openjfx/develop repository and created a version that
>>>> works on Android (will work on iOS soon).
>>>> This required some changes, as we're running on top of the Android VM,
>>>> which is not really Java (not even close).
>>>> The longer-term goal is to run a JVM on Android as well, but that is not
>>>> something to discuss in this topic.
>>>>
>>>> The changes I had to make are in this diff:
>>>>
>>>> https://github.com/javafxports/openjdk-jfx/compare/develop...johanvos:android
>>>>
>>>> There are a number of changes:
>>>>
>>>> 1. Changes in the Android specific files (e.g. FXDalvikEntity): those are
>>>> mainly changes we did in the 8-tree, but that were never sent upstream. I
>>>> think most of those can be upstreamed (after cleanup and review of
>>>> course)
>>>>
>>>> 2. Changes in Monocle, mainly related to scale factor and HiDPI. Those
>>>> can
>>>> probably be upstreamed as well
>>>>
>>>> 3. Changes in the buildSrc/dalvik.gradle. Those are android-only, so can
>>>> be
>>>> upstreamed too.
>>>>
>>>> 4. Changes in common java classes (e.g. no System.Logger). Those are a
>>>> problem.
>>>>
>>>> While I am in favour of leveraging the latest version of Java for doing
>>>> JavaFX development, I do realise this breaks the Android port (not the
>>>> iOS
>>>> port, as we use a VM based on OpenJDK already there).
>>>> While in theory we could deal with this using reflection (and this has
>>>> been
>>>> done in the 8-tree, e.g. for isIdeographic()), I don't think this is a
>>>> good
>>>> idea.
>>>>
>>>> My proposal would therefore be that I split the changes into
>>>> Android/Dalvik/Monocle changes that do not affect any other platform, and
>>>> create PR's for merging these changes in upstream. While my prototype is
>>>> working (see https://twitter.com/johanvos/status/1047804607320260608)  I
>>>> need to clean up the patches, and I suggest I create smaller PR's that
>>>> are
>>>> easier to digest.
>>>>
>>>> For the changes in the common classes, I think it's best to use a fork,
>>>> or
>>>> to patch the system at build time -- rather than polluting the main
>>>> repository with reflection-based checks.
>>>>
>>>> Thoughts?
>>>>
>>>> - Johan
>>>>


From johan at lodgon.com  Thu Oct  4 19:23:19 2018
From: johan at lodgon.com (Johan Vos)
Date: Thu, 4 Oct 2018 21:23:19 +0200
Subject: JavaFX 11 on Android
In-Reply-To: <3209d159-4882-b7a2-f9bd-7d648de75fe2@oracle.com>
References: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>
 <CA+0ynh-3rPgiuZExOhm5Hn9uJ3eiM+rwpRb+i5x7YJUH4LNkWg@mail.gmail.com>
 <CABxFH2FzUCXLbs1jk2=yAnNR70c-WUbp+8-npoP3xf_78Tdz3Q@mail.gmail.com>
 <CA+0ynh8OuF6ke2jGobzNQtY=pAvmpNHj_oMyMhAkdyUM4a2uww@mail.gmail.com>
 <3209d159-4882-b7a2-f9bd-7d648de75fe2@oracle.com>
Message-ID: <CABek58nWEnVC9ztmQVhDmakBwReQKDrRMBmf-Mb1_kscZt0Xig@mail.gmail.com>

Hi David,

Thanks for chiming in :)
see inline

Op do 4 okt. 2018 om 21:18 schreef David Grieve <david.grieve at oracle.com>:

> You just need Android Studio 3 for try-with-resources. See
> https://developer.android.com/studio/write/java8-support


Right, but there is Java 9 specific support for final variables:
https://blogs.oracle.com/darcy/more-concise-try-with-resources-statements-in-jdk-9
and
that doesn't work with 8 (we compile with --source 1.8 --target 1.8),
unless that is a compile time change only?


> I've never had a problem using java.util.logging with Android. Logging
> ends up in logcat.
>

That's why we are using java.util.logging indeed and that works fine. But
since 11, the JavaFX PlatformLogger uses the System.Logger which is not
available on Android.

- Johan



>
> On 10/4/18 2:45 PM, Nir Lisker wrote:
> >> But indeed, there are other things (e.g. try-resource with variable)
> that
> >> can not be used on Android. In general, there are too much restrictions,
> >> which is why we need a bundled Java 11 in the longer term.
>
> >
> > How does JavaFXPorts deal with this?
> >
> > We use java.util.logging for now.
> >
> >
> > That will require reverting the work of removing it [1] :) So yes, a fork
> > seems adequate for now and in the future we can re-evaluate the need for
> > j.u.l. (related: [2]).
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8195974
> > [2] https://bugs.openjdk.java.net/browse/JDK-8209036
> >
> > On Thu, Oct 4, 2018 at 9:13 PM Johan Vos <johan.vos at gluonhq.com> wrote:
> >
> >>
> >> On Thu, Oct 4, 2018 at 8:01 PM Nir Lisker <nlisker at gmail.com> wrote:
> >>
> >>> Hi Johan,
> >>>
> >>> Thanks for the work. A couple of questions:
> >>>
> >>>
> >>>> I worked from the openjfx/develop repository and created a version
> that
> >>>> works on Android (will work on iOS soon).
> >>>
> >>> I'm not very familiar with the state of mobile. Doesn't Android support
> >>> only up to Java 8 API? What happens if there is 'var' in the codebase,
> for
> >>> example?
> >>>
> >> "var" will be ok as I think that has no influence at runtime?
> >> But indeed, there are other things (e.g. try-resource with variable)
> that
> >> can not be used on Android. In general, there are too much restrictions,
> >> which is why we need a bundled Java 11 in the longer term.
> >>
> >>
> >>> 4. Changes in common java classes (e.g. no System.Logger). Those are a
> >>>> problem.
> >>>
> >>> If System.Logger is not available on Android an iOS, what is available
> >>> instead? jul or a native logger?
> >>>
> >> We use java.util.logging for now.
> >>
> >>
> >>> - Nir
> >>>
> >>> On Thu, Oct 4, 2018 at 8:01 PM Johan Vos <johan.vos at gluonhq.com>
> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I worked from the openjfx/develop repository and created a version
> that
> >>>> works on Android (will work on iOS soon).
> >>>> This required some changes, as we're running on top of the Android VM,
> >>>> which is not really Java (not even close).
> >>>> The longer-term goal is to run a JVM on Android as well, but that is
> not
> >>>> something to discuss in this topic.
> >>>>
> >>>> The changes I had to make are in this diff:
> >>>>
> >>>>
> https://github.com/javafxports/openjdk-jfx/compare/develop...johanvos:android
> >>>>
> >>>> There are a number of changes:
> >>>>
> >>>> 1. Changes in the Android specific files (e.g. FXDalvikEntity): those
> are
> >>>> mainly changes we did in the 8-tree, but that were never sent
> upstream. I
> >>>> think most of those can be upstreamed (after cleanup and review of
> >>>> course)
> >>>>
> >>>> 2. Changes in Monocle, mainly related to scale factor and HiDPI. Those
> >>>> can
> >>>> probably be upstreamed as well
> >>>>
> >>>> 3. Changes in the buildSrc/dalvik.gradle. Those are android-only, so
> can
> >>>> be
> >>>> upstreamed too.
> >>>>
> >>>> 4. Changes in common java classes (e.g. no System.Logger). Those are a
> >>>> problem.
> >>>>
> >>>> While I am in favour of leveraging the latest version of Java for
> doing
> >>>> JavaFX development, I do realise this breaks the Android port (not the
> >>>> iOS
> >>>> port, as we use a VM based on OpenJDK already there).
> >>>> While in theory we could deal with this using reflection (and this has
> >>>> been
> >>>> done in the 8-tree, e.g. for isIdeographic()), I don't think this is a
> >>>> good
> >>>> idea.
> >>>>
> >>>> My proposal would therefore be that I split the changes into
> >>>> Android/Dalvik/Monocle changes that do not affect any other platform,
> and
> >>>> create PR's for merging these changes in upstream. While my prototype
> is
> >>>> working (see https://twitter.com/johanvos/status/1047804607320260608)
> I
> >>>> need to clean up the patches, and I suggest I create smaller PR's that
> >>>> are
> >>>> easier to digest.
> >>>>
> >>>> For the changes in the common classes, I think it's best to use a
> fork,
> >>>> or
> >>>> to patch the system at build time -- rather than polluting the main
> >>>> repository with reflection-based checks.
> >>>>
> >>>> Thoughts?
> >>>>
> >>>> - Johan
> >>>>
>
>

From kevin.rushforth at oracle.com  Thu Oct  4 20:00:53 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 4 Oct 2018 13:00:53 -0700
Subject: JavaFX 11 on Android
In-Reply-To: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>
References: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>
Message-ID: <077f1096-e85c-fb18-eaf7-9349dac20a9f@oracle.com>


> My proposal would therefore be that I split the changes into
> Android/Dalvik/Monocle changes that do not affect any other platform, and
> create PR's for merging these changes in upstream. While my prototype is
> working (see https://twitter.com/johanvos/status/1047804607320260608)  I
> need to clean up the patches, and I suggest I create smaller PR's that are
> easier to digest.

This seems like a fine idea.

> For the changes in the common classes, I think it's best to use a fork, or
> to patch the system at build time -- rather than polluting the main
> repository with reflection-based checks.

As does this.

-- Kevin


On 10/4/2018 10:01 AM, Johan Vos wrote:
> Hi,
>
> I worked from the openjfx/develop repository and created a version that
> works on Android (will work on iOS soon).
> This required some changes, as we're running on top of the Android VM,
> which is not really Java (not even close).
> The longer-term goal is to run a JVM on Android as well, but that is not
> something to discuss in this topic.
>
> The changes I had to make are in this diff:
> https://github.com/javafxports/openjdk-jfx/compare/develop...johanvos:android
>
> There are a number of changes:
>
> 1. Changes in the Android specific files (e.g. FXDalvikEntity): those are
> mainly changes we did in the 8-tree, but that were never sent upstream. I
> think most of those can be upstreamed (after cleanup and review of course)
>
> 2. Changes in Monocle, mainly related to scale factor and HiDPI. Those can
> probably be upstreamed as well
>
> 3. Changes in the buildSrc/dalvik.gradle. Those are android-only, so can be
> upstreamed too.
>
> 4. Changes in common java classes (e.g. no System.Logger). Those are a
> problem.
>
> While I am in favour of leveraging the latest version of Java for doing
> JavaFX development, I do realise this breaks the Android port (not the iOS
> port, as we use a VM based on OpenJDK already there).
> While in theory we could deal with this using reflection (and this has been
> done in the 8-tree, e.g. for isIdeographic()), I don't think this is a good
> idea.
>
> My proposal would therefore be that I split the changes into
> Android/Dalvik/Monocle changes that do not affect any other platform, and
> create PR's for merging these changes in upstream. While my prototype is
> working (see https://twitter.com/johanvos/status/1047804607320260608)  I
> need to clean up the patches, and I suggest I create smaller PR's that are
> easier to digest.
>
> For the changes in the common classes, I think it's best to use a fork, or
> to patch the system at build time -- rather than polluting the main
> repository with reflection-based checks.
>
> Thoughts?
>
> - Johan


From kevin.rushforth at oracle.com  Thu Oct  4 20:08:52 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 4 Oct 2018 13:08:52 -0700
Subject: Bad DropShadow performance
In-Reply-To: <26CF2772-B099-42D2-A4E9-9A5A866DF079@gmail.com>
References: <1d865181-c33f-d09f-7adb-de98aaeeb405@bestsolution.at>
 <26CF2772-B099-42D2-A4E9-9A5A866DF079@gmail.com>
Message-ID: <3ebd902c-1b2d-7b81-acfc-ed5bc9e71a77@oracle.com>

Any effect has the potential for slowing down depending on the size if 
the node being rendered, since it is done as an image operation on the 
entire area (bounding box) covered by the Parent. Have you noticed 
whether DropShadow is worse than other effects, say, GaussianBlur? One 
other thing to note is that caching a Parent will have no effect if the 
children are animating, since it will need to be recreated each time.

-- Kevin


On 10/4/2018 11:32 AM, Dirk Lemmermann wrote:
> Yes, I also noticed that DropShadow causes severe performance degradation.
>
> Dirk
>
>> On 4 Oct 2018, at 13:10, Tom Schindl <tom.schindl at bestsolution.at> wrote:
>>
>> Hi,
>>
>> Why does applying a DropShadow on a large region cause problem when
>> animating nodes contained in that region?
>>
>>> package fxbugs;
>>>
>>> import javafx.animation.ScaleTransition;
>>> import javafx.application.Application;
>>> import javafx.geometry.Insets;
>>> import javafx.scene.Node;
>>> import javafx.scene.Scene;
>>> import javafx.scene.control.Button;
>>> import javafx.scene.effect.BlurType;
>>> import javafx.scene.effect.DropShadow;
>>> import javafx.scene.layout.BorderPane;
>>> import javafx.scene.layout.GridPane;
>>> import javafx.scene.paint.Color;
>>> import javafx.stage.Stage;
>>> import javafx.util.Duration;
>>>
>>> public class DropShadowPerformance extends Application {
>>>
>>>     @Override
>>>     public void start(Stage primaryStage) throws Exception {
>>>         BorderPane p = new BorderPane();
>>>         p.setPadding(new Insets(30));
>>>
>>>         GridPane container = new GridPane();
>>>         container.setHgap(10);
>>>         container.setVgap(10);
>>>         container.setStyle("-fx-background-color: green; -fx-padding: 10;");
>>>         container.setEffect(new DropShadow(BlurType.GAUSSIAN, Color.rgb(0, 0, 0, 0.3), 10, 0.5, 0, 0));
>>>         for( int i = 0; i < 8; i++ ) {
>>>             for( int j = 0; j < 14; j++ ) {
>>>                 container.add(createButton(), i, j);
>>>             }
>>>         }
>>>         p.setCenter(container);
>>>
>>>         Scene s = new Scene(p, 800, 600);
>>>         primaryStage.setScene(s);
>>>         primaryStage.show();
>>>     }
>>>
>>>     private Node createButton() {
>>>         Button button = new Button("hello world");
>>>         button.hoverProperty().addListener((ob,ol,ne) -> {
>>>             ScaleTransition t = new ScaleTransition(Duration.millis(500), button);
>>>
>>>             if( ne ) {
>>>                 t.setFromX(1);
>>>                 t.setFromY(1);
>>>                 t.setToX(1.2);
>>>                 t.setToY(1.2);
>>>             } else {
>>>                 t.setFromX(1.2);
>>>                 t.setFromY(1.2);
>>>                 t.setToX(1);
>>>                 t.setToY(1);
>>>             }
>>>
>>>             t.play();
>>>         });
>>>         return button;
>>>     }
>>>
>>>     public static void main(String[] args) {
>>>         launch(args);
>>>     }
>>> }
>>
>> If you run the following application:
>> * Maximize the window
>> * Hover over a button (eg the one in the right lower corner)
>>
>> You'll notice that the animation is not smooth, setting cache flags on
>> the container does not improve the situation, nor does using a ONE_PASS_BOX.
>>
>> Removing the effect on the container node "fixes" the problem.
>>
>> This is on a MacBook Pro and Windows Surface both having a Intel Iris
>> Plus 650 graphics card.
>>
>> Tom
>>
>> -- 
>> Tom Schindl, CTO
>> BestSolution.at EDV Systemhaus GmbH
>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck


From johnvalrose at gmail.com  Thu Oct  4 20:32:59 2018
From: johnvalrose at gmail.com (John-Val Rose)
Date: Fri, 5 Oct 2018 06:32:59 +1000
Subject: JavaFX 11 on Android
In-Reply-To: <077f1096-e85c-fb18-eaf7-9349dac20a9f@oracle.com>
References: <CABxFH2FCFb2EO4RcWS-4Mwp014JWSAD_oRuVrEb2e0z_J8GNEQ@mail.gmail.com>
 <077f1096-e85c-fb18-eaf7-9349dac20a9f@oracle.com>
Message-ID: <4E9DBB78-3508-411C-B1C3-7ACE11A59180@gmail.com>

Johan,

I?m guessing that Gluon Mobile and GluonVM will run on Android with JavaFX 11 (eventually at least).

Is this correct?

Graciously,

John-Val Rose
Rosethorn Technology

> On 5 Oct 2018, at 06:00, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> 
>> My proposal would therefore be that I split the changes into
>> Android/Dalvik/Monocle changes that do not affect any other platform, and
>> create PR's for merging these changes in upstream. While my prototype is
>> working (see https://twitter.com/johanvos/status/1047804607320260608)  I
>> need to clean up the patches, and I suggest I create smaller PR's that are
>> easier to digest.
> 
> This seems like a fine idea.
> 
>> For the changes in the common classes, I think it's best to use a fork, or
>> to patch the system at build time -- rather than polluting the main
>> repository with reflection-based checks.
> 
> As does this.
> 
> -- Kevin
> 
> 
>> On 10/4/2018 10:01 AM, Johan Vos wrote:
>> Hi,
>> 
>> I worked from the openjfx/develop repository and created a version that
>> works on Android (will work on iOS soon).
>> This required some changes, as we're running on top of the Android VM,
>> which is not really Java (not even close).
>> The longer-term goal is to run a JVM on Android as well, but that is not
>> something to discuss in this topic.
>> 
>> The changes I had to make are in this diff:
>> https://github.com/javafxports/openjdk-jfx/compare/develop...johanvos:android
>> 
>> There are a number of changes:
>> 
>> 1. Changes in the Android specific files (e.g. FXDalvikEntity): those are
>> mainly changes we did in the 8-tree, but that were never sent upstream. I
>> think most of those can be upstreamed (after cleanup and review of course)
>> 
>> 2. Changes in Monocle, mainly related to scale factor and HiDPI. Those can
>> probably be upstreamed as well
>> 
>> 3. Changes in the buildSrc/dalvik.gradle. Those are android-only, so can be
>> upstreamed too.
>> 
>> 4. Changes in common java classes (e.g. no System.Logger). Those are a
>> problem.
>> 
>> While I am in favour of leveraging the latest version of Java for doing
>> JavaFX development, I do realise this breaks the Android port (not the iOS
>> port, as we use a VM based on OpenJDK already there).
>> While in theory we could deal with this using reflection (and this has been
>> done in the 8-tree, e.g. for isIdeographic()), I don't think this is a good
>> idea.
>> 
>> My proposal would therefore be that I split the changes into
>> Android/Dalvik/Monocle changes that do not affect any other platform, and
>> create PR's for merging these changes in upstream. While my prototype is
>> working (see https://twitter.com/johanvos/status/1047804607320260608)  I
>> need to clean up the patches, and I suggest I create smaller PR's that are
>> easier to digest.
>> 
>> For the changes in the common classes, I think it's best to use a fork, or
>> to patch the system at build time -- rather than polluting the main
>> repository with reflection-based checks.
>> 
>> Thoughts?
>> 
>> - Johan
> 

From tom.schindl at bestsolution.at  Thu Oct  4 20:44:07 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Thu, 4 Oct 2018 22:44:07 +0200
Subject: Bad DropShadow performance
In-Reply-To: <3ebd902c-1b2d-7b81-acfc-ed5bc9e71a77@oracle.com>
References: <1d865181-c33f-d09f-7adb-de98aaeeb405@bestsolution.at>
 <26CF2772-B099-42D2-A4E9-9A5A866DF079@gmail.com>
 <3ebd902c-1b2d-7b81-acfc-ed5bc9e71a77@oracle.com>
Message-ID: <ac010d2d-07c0-eeac-55b3-98daaebe70aa@bestsolution.at>

Hi Kevin,

Thank you for the comment so the trick to fix my problems is that I
don't apply the effect on the container but create a 2nd node who has
the same size and is a sibling of my area and apply the effect there?

This looks like it is working ;-)

package fxbugs;

import javafx.animation.ScaleTransition;
import javafx.application.Application;
import javafx.scene.Node;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.effect.BlurType;
import javafx.scene.effect.DropShadow;
import javafx.scene.layout.AnchorPane;
import javafx.scene.layout.GridPane;
import javafx.scene.layout.Region;
import javafx.scene.paint.Color;
import javafx.stage.Stage;
import javafx.util.Duration;

public class DropShadowPerformance extends Application {

    @Override
    public void start(Stage primaryStage) throws Exception {
        AnchorPane p = new AnchorPane();

//
// Use a shadow
        Region shadow = new Region();
        shadow.setStyle("-fx-background-color: black;");
        shadow.setEffect(new DropShadow(BlurType.GAUSSIAN, Color.rgb(0,
0, 0, 0.3), 10, 0.5, 0, 0));
        shadow.setCache(true);
        AnchorPane.setBottomAnchor(shadow, 30.0);
        AnchorPane.setTopAnchor(shadow, 30.0);
        AnchorPane.setLeftAnchor(shadow, 30.0);
        AnchorPane.setRightAnchor(shadow, 30.0);

        p.getChildren().add(shadow);

        GridPane container = new GridPane();
        container.setHgap(10);
        container.setVgap(10);
        container.setStyle("-fx-background-color: green; -fx-padding: 10;");
//        container.setEffect(new DropShadow(BlurType.GAUSSIAN,
Color.rgb(0, 0, 0, 0.3), 10, 0.5, 0, 0));
        for( int i = 0; i < 8; i++ ) {
            for( int j = 0; j < 14; j++ ) {
                container.add(createButton(), i, j);
            }
        }
        AnchorPane.setBottomAnchor(container, 30.0);
        AnchorPane.setTopAnchor(container, 30.0);
        AnchorPane.setLeftAnchor(container, 30.0);
        AnchorPane.setRightAnchor(container, 30.0);
        p.getChildren().add(container);

        Scene s = new Scene(p, 800, 600);
        primaryStage.setScene(s);
        primaryStage.show();
    }

    private Node createButton() {
        Button button = new Button("hello world");
        button.hoverProperty().addListener((ob,ol,ne) -> {
            ScaleTransition t = new
ScaleTransition(Duration.millis(500), button);

            if( ne ) {
                t.setFromX(1);
                t.setFromY(1);
                t.setToX(1.2);
                t.setToY(1.2);
            } else {
                t.setFromX(1.2);
                t.setFromY(1.2);
                t.setToX(1);
                t.setToY(1);
            }

            t.play();
        });
        return button;
    }

    public static void main(String[] args) {
        launch(args);
    }
}


Tom

On 04.10.18 22:08, Kevin Rushforth wrote:
> Any effect has the potential for slowing down depending on the size if
> the node being rendered, since it is done as an image operation on the
> entire area (bounding box) covered by the Parent. Have you noticed
> whether DropShadow is worse than other effects, say, GaussianBlur? One
> other thing to note is that caching a Parent will have no effect if the
> children are animating, since it will need to be recreated each time.
> 
> -- Kevin
> 
> 
> On 10/4/2018 11:32 AM, Dirk Lemmermann wrote:
>> Yes, I also noticed that DropShadow causes severe performance
>> degradation.
>>
>> Dirk
>>
>>> On 4 Oct 2018, at 13:10, Tom Schindl <tom.schindl at bestsolution.at>
>>> wrote:
>>>
>>> Hi,
>>>
>>> Why does applying a DropShadow on a large region cause problem when
>>> animating nodes contained in that region?
>>>
>>>> package fxbugs;
>>>>
>>>> import javafx.animation.ScaleTransition;
>>>> import javafx.application.Application;
>>>> import javafx.geometry.Insets;
>>>> import javafx.scene.Node;
>>>> import javafx.scene.Scene;
>>>> import javafx.scene.control.Button;
>>>> import javafx.scene.effect.BlurType;
>>>> import javafx.scene.effect.DropShadow;
>>>> import javafx.scene.layout.BorderPane;
>>>> import javafx.scene.layout.GridPane;
>>>> import javafx.scene.paint.Color;
>>>> import javafx.stage.Stage;
>>>> import javafx.util.Duration;
>>>>
>>>> public class DropShadowPerformance extends Application {
>>>>
>>>> ??? @Override
>>>> ??? public void start(Stage primaryStage) throws Exception {
>>>> ??????? BorderPane p = new BorderPane();
>>>> ??????? p.setPadding(new Insets(30));
>>>>
>>>> ??????? GridPane container = new GridPane();
>>>> ??????? container.setHgap(10);
>>>> ??????? container.setVgap(10);
>>>> ??????? container.setStyle("-fx-background-color: green;
>>>> -fx-padding: 10;");
>>>> ??????? container.setEffect(new DropShadow(BlurType.GAUSSIAN,
>>>> Color.rgb(0, 0, 0, 0.3), 10, 0.5, 0, 0));
>>>> ??????? for( int i = 0; i < 8; i++ ) {
>>>> ??????????? for( int j = 0; j < 14; j++ ) {
>>>> ??????????????? container.add(createButton(), i, j);
>>>> ??????????? }
>>>> ??????? }
>>>> ??????? p.setCenter(container);
>>>>
>>>> ??????? Scene s = new Scene(p, 800, 600);
>>>> ??????? primaryStage.setScene(s);
>>>> ??????? primaryStage.show();
>>>> ??? }
>>>>
>>>> ??? private Node createButton() {
>>>> ??????? Button button = new Button("hello world");
>>>> ??????? button.hoverProperty().addListener((ob,ol,ne) -> {
>>>> ??????????? ScaleTransition t = new
>>>> ScaleTransition(Duration.millis(500), button);
>>>>
>>>> ??????????? if( ne ) {
>>>> ??????????????? t.setFromX(1);
>>>> ??????????????? t.setFromY(1);
>>>> ??????????????? t.setToX(1.2);
>>>> ??????????????? t.setToY(1.2);
>>>> ??????????? } else {
>>>> ??????????????? t.setFromX(1.2);
>>>> ??????????????? t.setFromY(1.2);
>>>> ??????????????? t.setToX(1);
>>>> ??????????????? t.setToY(1);
>>>> ??????????? }
>>>>
>>>> ??????????? t.play();
>>>> ??????? });
>>>> ??????? return button;
>>>> ??? }
>>>>
>>>> ??? public static void main(String[] args) {
>>>> ??????? launch(args);
>>>> ??? }
>>>> }
>>>
>>> If you run the following application:
>>> * Maximize the window
>>> * Hover over a button (eg the one in the right lower corner)
>>>
>>> You'll notice that the animation is not smooth, setting cache flags on
>>> the container does not improve the situation, nor does using a
>>> ONE_PASS_BOX.
>>>
>>> Removing the effect on the container node "fixes" the problem.
>>>
>>> This is on a MacBook Pro and Windows Surface both having a Intel Iris
>>> Plus 650 graphics card.
>>>
>>> Tom
>>>
>>> --?
>>> Tom Schindl, CTO
>>> BestSolution.at EDV Systemhaus GmbH
>>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From kevin.rushforth at oracle.com  Thu Oct  4 23:58:31 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 4 Oct 2018 16:58:31 -0700
Subject: Bad DropShadow performance
In-Reply-To: <ac010d2d-07c0-eeac-55b3-98daaebe70aa@bestsolution.at>
References: <1d865181-c33f-d09f-7adb-de98aaeeb405@bestsolution.at>
 <26CF2772-B099-42D2-A4E9-9A5A866DF079@gmail.com>
 <3ebd902c-1b2d-7b81-acfc-ed5bc9e71a77@oracle.com>
 <ac010d2d-07c0-eeac-55b3-98daaebe70aa@bestsolution.at>
Message-ID: <408239f4-d1cd-e98e-c2e2-980a762f4ef5@oracle.com>

Glad you were able to fix your issue. If you don't need to apply the 
effect to the group with the animating content, then it will be able to 
be cached, which is where I guess the speedup is coming from.

-- Kevin


On 10/4/2018 1:44 PM, Tom Schindl wrote:
> Hi Kevin,
>
> Thank you for the comment so the trick to fix my problems is that I
> don't apply the effect on the container but create a 2nd node who has
> the same size and is a sibling of my area and apply the effect there?
>
> This looks like it is working ;-)
>
> package fxbugs;
>
> import javafx.animation.ScaleTransition;
> import javafx.application.Application;
> import javafx.scene.Node;
> import javafx.scene.Scene;
> import javafx.scene.control.Button;
> import javafx.scene.effect.BlurType;
> import javafx.scene.effect.DropShadow;
> import javafx.scene.layout.AnchorPane;
> import javafx.scene.layout.GridPane;
> import javafx.scene.layout.Region;
> import javafx.scene.paint.Color;
> import javafx.stage.Stage;
> import javafx.util.Duration;
>
> public class DropShadowPerformance extends Application {
>
>      @Override
>      public void start(Stage primaryStage) throws Exception {
>          AnchorPane p = new AnchorPane();
>
> //
> // Use a shadow
>          Region shadow = new Region();
>          shadow.setStyle("-fx-background-color: black;");
>          shadow.setEffect(new DropShadow(BlurType.GAUSSIAN, Color.rgb(0,
> 0, 0, 0.3), 10, 0.5, 0, 0));
>          shadow.setCache(true);
>          AnchorPane.setBottomAnchor(shadow, 30.0);
>          AnchorPane.setTopAnchor(shadow, 30.0);
>          AnchorPane.setLeftAnchor(shadow, 30.0);
>          AnchorPane.setRightAnchor(shadow, 30.0);
>
>          p.getChildren().add(shadow);
>
>          GridPane container = new GridPane();
>          container.setHgap(10);
>          container.setVgap(10);
>          container.setStyle("-fx-background-color: green; -fx-padding: 10;");
> //        container.setEffect(new DropShadow(BlurType.GAUSSIAN,
> Color.rgb(0, 0, 0, 0.3), 10, 0.5, 0, 0));
>          for( int i = 0; i < 8; i++ ) {
>              for( int j = 0; j < 14; j++ ) {
>                  container.add(createButton(), i, j);
>              }
>          }
>          AnchorPane.setBottomAnchor(container, 30.0);
>          AnchorPane.setTopAnchor(container, 30.0);
>          AnchorPane.setLeftAnchor(container, 30.0);
>          AnchorPane.setRightAnchor(container, 30.0);
>          p.getChildren().add(container);
>
>          Scene s = new Scene(p, 800, 600);
>          primaryStage.setScene(s);
>          primaryStage.show();
>      }
>
>      private Node createButton() {
>          Button button = new Button("hello world");
>          button.hoverProperty().addListener((ob,ol,ne) -> {
>              ScaleTransition t = new
> ScaleTransition(Duration.millis(500), button);
>
>              if( ne ) {
>                  t.setFromX(1);
>                  t.setFromY(1);
>                  t.setToX(1.2);
>                  t.setToY(1.2);
>              } else {
>                  t.setFromX(1.2);
>                  t.setFromY(1.2);
>                  t.setToX(1);
>                  t.setToY(1);
>              }
>
>              t.play();
>          });
>          return button;
>      }
>
>      public static void main(String[] args) {
>          launch(args);
>      }
> }
>
>
> Tom
>
> On 04.10.18 22:08, Kevin Rushforth wrote:
>> Any effect has the potential for slowing down depending on the size if
>> the node being rendered, since it is done as an image operation on the
>> entire area (bounding box) covered by the Parent. Have you noticed
>> whether DropShadow is worse than other effects, say, GaussianBlur? One
>> other thing to note is that caching a Parent will have no effect if the
>> children are animating, since it will need to be recreated each time.
>>
>> -- Kevin
>>
>>
>> On 10/4/2018 11:32 AM, Dirk Lemmermann wrote:
>>> Yes, I also noticed that DropShadow causes severe performance
>>> degradation.
>>>
>>> Dirk
>>>
>>>> On 4 Oct 2018, at 13:10, Tom Schindl <tom.schindl at bestsolution.at>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Why does applying a DropShadow on a large region cause problem when
>>>> animating nodes contained in that region?
>>>>
>>>>> package fxbugs;
>>>>>
>>>>> import javafx.animation.ScaleTransition;
>>>>> import javafx.application.Application;
>>>>> import javafx.geometry.Insets;
>>>>> import javafx.scene.Node;
>>>>> import javafx.scene.Scene;
>>>>> import javafx.scene.control.Button;
>>>>> import javafx.scene.effect.BlurType;
>>>>> import javafx.scene.effect.DropShadow;
>>>>> import javafx.scene.layout.BorderPane;
>>>>> import javafx.scene.layout.GridPane;
>>>>> import javafx.scene.paint.Color;
>>>>> import javafx.stage.Stage;
>>>>> import javafx.util.Duration;
>>>>>
>>>>> public class DropShadowPerformance extends Application {
>>>>>
>>>>>  ??? @Override
>>>>>  ??? public void start(Stage primaryStage) throws Exception {
>>>>>  ??????? BorderPane p = new BorderPane();
>>>>>  ??????? p.setPadding(new Insets(30));
>>>>>
>>>>>  ??????? GridPane container = new GridPane();
>>>>>  ??????? container.setHgap(10);
>>>>>  ??????? container.setVgap(10);
>>>>>  ??????? container.setStyle("-fx-background-color: green;
>>>>> -fx-padding: 10;");
>>>>>  ??????? container.setEffect(new DropShadow(BlurType.GAUSSIAN,
>>>>> Color.rgb(0, 0, 0, 0.3), 10, 0.5, 0, 0));
>>>>>  ??????? for( int i = 0; i < 8; i++ ) {
>>>>>  ??????????? for( int j = 0; j < 14; j++ ) {
>>>>>  ??????????????? container.add(createButton(), i, j);
>>>>>  ??????????? }
>>>>>  ??????? }
>>>>>  ??????? p.setCenter(container);
>>>>>
>>>>>  ??????? Scene s = new Scene(p, 800, 600);
>>>>>  ??????? primaryStage.setScene(s);
>>>>>  ??????? primaryStage.show();
>>>>>  ??? }
>>>>>
>>>>>  ??? private Node createButton() {
>>>>>  ??????? Button button = new Button("hello world");
>>>>>  ??????? button.hoverProperty().addListener((ob,ol,ne) -> {
>>>>>  ??????????? ScaleTransition t = new
>>>>> ScaleTransition(Duration.millis(500), button);
>>>>>
>>>>>  ??????????? if( ne ) {
>>>>>  ??????????????? t.setFromX(1);
>>>>>  ??????????????? t.setFromY(1);
>>>>>  ??????????????? t.setToX(1.2);
>>>>>  ??????????????? t.setToY(1.2);
>>>>>  ??????????? } else {
>>>>>  ??????????????? t.setFromX(1.2);
>>>>>  ??????????????? t.setFromY(1.2);
>>>>>  ??????????????? t.setToX(1);
>>>>>  ??????????????? t.setToY(1);
>>>>>  ??????????? }
>>>>>
>>>>>  ??????????? t.play();
>>>>>  ??????? });
>>>>>  ??????? return button;
>>>>>  ??? }
>>>>>
>>>>>  ??? public static void main(String[] args) {
>>>>>  ??????? launch(args);
>>>>>  ??? }
>>>>> }
>>>> If you run the following application:
>>>> * Maximize the window
>>>> * Hover over a button (eg the one in the right lower corner)
>>>>
>>>> You'll notice that the animation is not smooth, setting cache flags on
>>>> the container does not improve the situation, nor does using a
>>>> ONE_PASS_BOX.
>>>>
>>>> Removing the effect on the container node "fixes" the problem.
>>>>
>>>> This is on a MacBook Pro and Windows Surface both having a Intel Iris
>>>> Plus 650 graphics card.
>>>>
>>>> Tom
>>>>
>>>> -- 
>>>> Tom Schindl, CTO
>>>> BestSolution.at EDV Systemhaus GmbH
>>>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>>>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck


From marcel.au at web.de  Fri Oct  5 06:38:30 2018
From: marcel.au at web.de (marcel Austenfeld)
Date: Fri, 5 Oct 2018 08:38:30 +0200
Subject: Aw: Re:  Re: "Toolkit already initialized" error with OpenJDK 11
In-Reply-To: <62f72fa3-fe83-33f7-60f8-1545579b3d55@oracle.com>
References: <trinity-8859f5f3-6c80-4309-bc9c-abfdc1ae31ed-1537960969645@3c-app-webde-bs17>
 <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
 <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
 <62f72fa3-fe83-33f7-60f8-1545579b3d55@oracle.com>
Message-ID: <trinity-3b1c8e5c-7780-4b0d-8c8a-d2f3e109bc1e-1538721510497@3c-app-webde-bs53>

Hello Kevin,

thanks for the analysis. 

I think this is the cause since each Eclipse plugins have their own classloader and I have several plugins with JavaFX classes. I will write a bug report on:

https://bugs.java.com/




?
?

Gesendet:?Donnerstag, 04. Oktober 2018 um 16:13 Uhr
Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
An:?"marcel Austenfeld" <marcel.au at web.de>
Cc:?openjfx-dev at openjdk.java.net
Betreff:?Re: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
I think I see what caused this. In FX 8 we called FXCanvas::initFx from
the constructor of every FXCanvas. It then called an internal startup
method, PlatformImpl::startup, that permits calling it when the Toolkit
is already initialized, turning it into a runLater if it is. As part of
the refactoring for FX 9 I changed it to call FXCanvas::initFx one time
from the static block. At the same time, I changed the startup call to
use the public Platform::startup method. This change was necessary
because the javafx.swt module does not have the needed qualified exports
to call internal methods until after initialization. The public
Platform::startup method is specified to throw an exception if called
more than once.

So if the FXCanvas class is loaded more than once, for example, if it is
called from different ClassLoaders, then that would cause the problem.
Please file a bug and I'll take a look at it. It might be as simple as
wrapping the call to Platform::startup in a try/catch and calling
Platform::runLater in the catch block.

-- Kevin


On 10/4/2018 6:03 AM, marcel Austenfeld wrote:
> Hello Kevin,
>
> I still have problems with the error: "java.lang.IllegalStateException: Toolkit already initialized".
>
> However I found out that this error only occurs if I call SWT FXCanvas classes located in different Eclipse plugins.
>
> I can create multiple JavaFX canvas if they are located in one Eclipse plugin.
>
> Vice versa if I try to to open the JavaFX SceneBuilder canvas which is located in a seperate Eclipse plugin this error occurs again.
>
> So I wonder that beginning with Java 9 the JavaFX toolkit doesn't recognize an already started toolkit in another Eclipse plugin (which was definitely the case with Java 8!).
>
> Maybee this has something to do with the new module system of Java >=9?
>
>
>
>
> Gesendet:?Mittwoch, 26. September 2018 um 14:09 Uhr
> Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
> An:?"marcel Austenfeld" <marcel.au at web.de>, openjfx-dev at openjdk.java.net
> Betreff:?Re: "Toolkit already initialized" error with OpenJDK 11
> I'm' not aware of anything that intentionally changed between FX in JDK
> 8 and FX 11, but my guess is that the FX runtime is being shutdown after
> your first FXCanvas exits. Try making the following call (only needed
> one time) before creating your first FXCanvas:
>
> ??? Platform.setImplicitExit(false);
>
> -- Kevin
>
> On 9/26/2018 4:22 AM, marcel Austenfeld wrote:
>> First of all congratulation to the new release and thank you for the hard work on JavaFX.
>>
>>
>> I have a problem with JavaFX which in my case is embedded in a Rich Client Platform of Eclipse.
>>
>> I integrated several SWT FXCanvas (some with SwingNode panels as a SWT_AWT replacement) into my app.
>>
>> This works fine in Java 8 which my current release depends on.
>>
>> However in Java 11 after the second panel is initialized at startup I get the following error:
>>
>> "Caused by: java.lang.IllegalStateException: Toolkit already initialized"
>>
>> Is there a new option available to avoid a new initialization of the toolkit if several FXCanvas are embedded in an application?
>> Or do you now any changes since Java 8 which could the cause of such an exception?
>>
>>
>> Thanks in advance for any help.
>
?

From marcel.au at web.de  Fri Oct  5 06:46:40 2018
From: marcel.au at web.de (marcel Austenfeld)
Date: Fri, 5 Oct 2018 08:46:40 +0200
Subject: Aw: Re:  Re: "Toolkit already initialized" error with OpenJDK 11
In-Reply-To: <a27d3ad7-fedd-3a92-7cf2-61e45597a7b0@bestsolution.at>
References: <trinity-8859f5f3-6c80-4309-bc9c-abfdc1ae31ed-1537960969645@3c-app-webde-bs17>
 <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
 <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
 <a27d3ad7-fedd-3a92-7cf2-61e45597a7b0@bestsolution.at>
Message-ID: <trinity-cad6d7bd-4013-4611-b9e5-ce9b0227e9da-1538722000266@3c-app-webde-bs53>


From marcel.au at web.de  Fri Oct  5 07:10:44 2018
From: marcel.au at web.de (marcel Austenfeld)
Date: Fri, 5 Oct 2018 09:10:44 +0200
Subject: Aw: Re:  Re: "Toolkit already initialized" error with OpenJDK 11
In-Reply-To: <62f72fa3-fe83-33f7-60f8-1545579b3d55@oracle.com>
References: <trinity-8859f5f3-6c80-4309-bc9c-abfdc1ae31ed-1537960969645@3c-app-webde-bs17>
 <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
 <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
 <62f72fa3-fe83-33f7-60f8-1545579b3d55@oracle.com>
Message-ID: <trinity-461026c9-c516-4288-a951-f8375f5de57f-1538723444580@3c-app-webde-bs53>


From marcel.au at web.de  Fri Oct  5 07:15:26 2018
From: marcel.au at web.de (marcel Austenfeld)
Date: Fri, 5 Oct 2018 09:15:26 +0200
Subject: Aw: Re:  Re: "Toolkit already initialized" error with OpenJDK 11
In-Reply-To: <62f72fa3-fe83-33f7-60f8-1545579b3d55@oracle.com>
References: <trinity-8859f5f3-6c80-4309-bc9c-abfdc1ae31ed-1537960969645@3c-app-webde-bs17>
 <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
 <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
 <62f72fa3-fe83-33f7-60f8-1545579b3d55@oracle.com>
Message-ID: <trinity-944ea707-c4e2-4907-aaf4-d69ff961593e-1538723726300@3c-app-webde-bs53>

I created a bug report on https://bugs.java.com/
?
Bug ID is: 9057517
?
?
?

Gesendet:?Donnerstag, 04. Oktober 2018 um 16:13 Uhr
Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
An:?"marcel Austenfeld" <marcel.au at web.de>
Cc:?openjfx-dev at openjdk.java.net
Betreff:?Re: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
I think I see what caused this. In FX 8 we called FXCanvas::initFx from
the constructor of every FXCanvas. It then called an internal startup
method, PlatformImpl::startup, that permits calling it when the Toolkit
is already initialized, turning it into a runLater if it is. As part of
the refactoring for FX 9 I changed it to call FXCanvas::initFx one time
from the static block. At the same time, I changed the startup call to
use the public Platform::startup method. This change was necessary
because the javafx.swt module does not have the needed qualified exports
to call internal methods until after initialization. The public
Platform::startup method is specified to throw an exception if called
more than once.

So if the FXCanvas class is loaded more than once, for example, if it is
called from different ClassLoaders, then that would cause the problem.
Please file a bug and I'll take a look at it. It might be as simple as
wrapping the call to Platform::startup in a try/catch and calling
Platform::runLater in the catch block.

-- Kevin


On 10/4/2018 6:03 AM, marcel Austenfeld wrote:
> Hello Kevin,
>
> I still have problems with the error: "java.lang.IllegalStateException: Toolkit already initialized".
>
> However I found out that this error only occurs if I call SWT FXCanvas classes located in different Eclipse plugins.
>
> I can create multiple JavaFX canvas if they are located in one Eclipse plugin.
>
> Vice versa if I try to to open the JavaFX SceneBuilder canvas which is located in a seperate Eclipse plugin this error occurs again.
>
> So I wonder that beginning with Java 9 the JavaFX toolkit doesn't recognize an already started toolkit in another Eclipse plugin (which was definitely the case with Java 8!).
>
> Maybee this has something to do with the new module system of Java >=9?
>
>
>
>
> Gesendet:?Mittwoch, 26. September 2018 um 14:09 Uhr
> Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
> An:?"marcel Austenfeld" <marcel.au at web.de>, openjfx-dev at openjdk.java.net
> Betreff:?Re: "Toolkit already initialized" error with OpenJDK 11
> I'm' not aware of anything that intentionally changed between FX in JDK
> 8 and FX 11, but my guess is that the FX runtime is being shutdown after
> your first FXCanvas exits. Try making the following call (only needed
> one time) before creating your first FXCanvas:
>
> ??? Platform.setImplicitExit(false);
>
> -- Kevin
>
> On 9/26/2018 4:22 AM, marcel Austenfeld wrote:
>> First of all congratulation to the new release and thank you for the hard work on JavaFX.
>>
>>
>> I have a problem with JavaFX which in my case is embedded in a Rich Client Platform of Eclipse.
>>
>> I integrated several SWT FXCanvas (some with SwingNode panels as a SWT_AWT replacement) into my app.
>>
>> This works fine in Java 8 which my current release depends on.
>>
>> However in Java 11 after the second panel is initialized at startup I get the following error:
>>
>> "Caused by: java.lang.IllegalStateException: Toolkit already initialized"
>>
>> Is there a new option available to avoid a new initialization of the toolkit if several FXCanvas are embedded in an application?
>> Or do you now any changes since Java 8 which could the cause of such an exception?
>>
>>
>> Thanks in advance for any help.
>
??
?

From tom.schindl at bestsolution.at  Fri Oct  5 07:27:51 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Fri, 5 Oct 2018 09:27:51 +0200
Subject: Aw: Re: Re: "Toolkit already initialized" error with OpenJDK 11
In-Reply-To: <trinity-cad6d7bd-4013-4611-b9e5-ce9b0227e9da-1538722000266@3c-app-webde-bs53>
References: <trinity-8859f5f3-6c80-4309-bc9c-abfdc1ae31ed-1537960969645@3c-app-webde-bs17>
 <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
 <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
 <a27d3ad7-fedd-3a92-7cf2-61e45597a7b0@bestsolution.at>
 <trinity-cad6d7bd-4013-4611-b9e5-ce9b0227e9da-1538722000266@3c-app-webde-bs53>
Message-ID: <74ac9e5c-979f-592e-c1e3-6a8ef525e4cb@bestsolution.at>

So how do you then load FXCanvas? It will not be found on any classpath
unless you ship the FXCanvas class directly which as you see is a bad idea.

I'm naturally biased but I think the approach take by e(fx)clipse is the
right one as it makes sure there's ever only one instance of FXCanvas
loaded in your runtime.

There is more static stuff in FXCanvas (eg Transfer and DropTargets) who
might or might not cause problems.

BTW IIRC the SceneBuilder Eclipse integration [1] is using e(fx)clipse
to load the FXCanvas.

Tom

[1]https://gitlab.stud.iie.ntnu.no/tobiaas/scene-builder-plugin

On 05.10.18 08:46, marcel Austenfeld wrote:
> Hello Tom,
> ?
> thanks for the answer. However I don't use e(fx)clipse to integrate
> Javafx panels in SWT and a Rich Client Platform.
> ?
> I believe that Kevin found the problem related to different classloaders
> ?
> *Gesendet:*?Donnerstag, 04. Oktober 2018 um 16:44 Uhr
> *Von:*?"Tom Schindl" <tom.schindl at bestsolution.at>
> *An:*?openjfx-dev at openjdk.java.net
> *Betreff:*?Re: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
> Hi,
> 
> Just to make sure I understand. Do you say that other OSGi-Bundles bring
> with them their own FXCanvas?
> 
> I've been looking at the e(fx)clipse code [1] who deals with FXCanvas,
> ... but I can't think of a situation where we create multiple classloaders.
> 
> Tom
> 
> [1]
> https://github.com/eclipse/efxclipse-rt/blob/3.x/modules/core/org.eclipse.fx.osgi/src/main/java/org/eclipse/fx/osgi/fxloader/FXClassLoader.java
> 
> On 04.10.18 15:03, marcel Austenfeld wrote:
>> Hello Kevin,
>> ?
>> I still have problems with the error:
> "java.lang.IllegalStateException: Toolkit already initialized".
>> ?
>> However I found out that this error only occurs if I call SWT FXCanvas
> classes located in different Eclipse plugins.
>> ?
>> I can create multiple JavaFX canvas if they are located in one Eclipse
> plugin.
>> ?
>> Vice versa if I try to to open the JavaFX SceneBuilder canvas which is
> located in a seperate Eclipse plugin this error occurs again.
>> ?
>> So I wonder that beginning with Java 9 the JavaFX toolkit doesn't
> recognize an already started toolkit in another Eclipse plugin (which
> was definitely the case with Java 8!).
>> ?
>> Maybee this has something to do with the new module system of Java >=9?
>> ?
>> ?
>> ?
>>
>> Gesendet:?Mittwoch, 26. September 2018 um 14:09 Uhr
>> Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
>> An:?"marcel Austenfeld" <marcel.au at web.de>, openjfx-dev at openjdk.java.net
>> Betreff:?Re: "Toolkit already initialized" error with OpenJDK 11
>> I'm' not aware of anything that intentionally changed between FX in JDK
>> 8 and FX 11, but my guess is that the FX runtime is being shutdown after
>> your first FXCanvas exits. Try making the following call (only needed
>> one time) before creating your first FXCanvas:
>>
>> ??? Platform.setImplicitExit(false);
>>
>> -- Kevin
>>
>> On 9/26/2018 4:22 AM, marcel Austenfeld wrote:
>>> First of all congratulation to the new release and thank you for the
> hard work on JavaFX.
>>>
>>>
>>> I have a problem with JavaFX which in my case is embedded in a Rich
> Client Platform of Eclipse.
>>>
>>> I integrated several SWT FXCanvas (some with SwingNode panels as a
> SWT_AWT replacement) into my app.
>>>
>>> This works fine in Java 8 which my current release depends on.
>>>
>>> However in Java 11 after the second panel is initialized at startup I
> get the following error:
>>>
>>> "Caused by: java.lang.IllegalStateException: Toolkit already initialized"
>>>
>>> Is there a new option available to avoid a new initialization of the
> toolkit if several FXCanvas are embedded in an application?
>>> Or do you now any changes since Java 8 which could the cause of such
> an exception?
>>>
>>>
>>> Thanks in advance for any help.
>> ?
>>
> 
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From marcel.au at web.de  Fri Oct  5 08:18:58 2018
From: marcel.au at web.de (marcel Austenfeld)
Date: Fri, 5 Oct 2018 10:18:58 +0200
Subject: Aw: Re:  Re: Re: "Toolkit already initialized" error with OpenJDK 11
In-Reply-To: <74ac9e5c-979f-592e-c1e3-6a8ef525e4cb@bestsolution.at>
References: <trinity-8859f5f3-6c80-4309-bc9c-abfdc1ae31ed-1537960969645@3c-app-webde-bs17>
 <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
 <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
 <a27d3ad7-fedd-3a92-7cf2-61e45597a7b0@bestsolution.at>
 <trinity-cad6d7bd-4013-4611-b9e5-ce9b0227e9da-1538722000266@3c-app-webde-bs53>
 <74ac9e5c-979f-592e-c1e3-6a8ef525e4cb@bestsolution.at>
Message-ID: <trinity-74646e44-94f6-40cf-918a-cf0bb75751a5-1538727538133@3c-app-webde-bs53>

Hello Tom,
?
I wrote you a few years ago in the e(fx)clipse forum (2014) that I implemented the SceneBuilder as an Eclipse plugin (please scroll down), see:
?
https://www.eclipse.org/forums/index.php/t/796180/

YouTube:

https://youtu.be/nO9H-iy-lvk
https://youtu.be/F5HFN8AznJU

?
The SceneBuilder Kit is integrated into a scientific RCP application (statistics, image analysis, modeling environment, etc.) which I develop since 2004:
?
https://bio7.org
?
One feature of this application is to compile Java dynamically (in process compilation) and to create Java GUI's with JavaFX or SWT on the fly. Here an older overview of Bio7:
?
https://youtu.be/pyYn690KaNE

The idea behind the integration and dynamic compilation is to allow other users to create easily software inside Bio7 reusing all integrated API's 
(R statistics, ImageJ, Java Scientific libs, SWT, JavaFX etc.) and special modeling components (Custom perspective and views, etc.) in an very easy way.

The integration of JavaFX is done in the plugins via the Bundle-ClassPath as described in the e(fx)clipse forum above (Java 11 will be bundled with the RCP!):

Bundle-ClassPath: 
 bin/,
 src/,
 external:$java.home$/lib/javafx-swt.jar,


This worked for years and even now (with the exception of the classloader bug analyzed by Kevin)
?

Gesendet:?Freitag, 05. Oktober 2018 um 09:27 Uhr
Von:?"Tom Schindl" <tom.schindl at bestsolution.at>
An:?open <openjfx-dev at openjdk.java.net>
Betreff:?Re: Aw: Re: Re: "Toolkit already initialized" error with OpenJDK 11
So how do you then load FXCanvas? It will not be found on any classpath
unless you ship the FXCanvas class directly which as you see is a bad idea.

I'm naturally biased but I think the approach take by e(fx)clipse is the
right one as it makes sure there's ever only one instance of FXCanvas
loaded in your runtime.

There is more static stuff in FXCanvas (eg Transfer and DropTargets) who
might or might not cause problems.

BTW IIRC the SceneBuilder Eclipse integration [1] is using e(fx)clipse
to load the FXCanvas.

Tom

[1]https://gitlab.stud.iie.ntnu.no/tobiaas/scene-builder-plugin

On 05.10.18 08:46, marcel Austenfeld wrote:
> Hello Tom,
> ?
> thanks for the answer. However I don't use e(fx)clipse to integrate
> Javafx panels in SWT and a Rich Client Platform.
> ?
> I believe that Kevin found the problem related to different classloaders
> ?
> *Gesendet:*?Donnerstag, 04. Oktober 2018 um 16:44 Uhr
> *Von:*?"Tom Schindl" <tom.schindl at bestsolution.at>
> *An:*?openjfx-dev at openjdk.java.net
> *Betreff:*?Re: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
> Hi,
>
> Just to make sure I understand. Do you say that other OSGi-Bundles bring
> with them their own FXCanvas?
>
> I've been looking at the e(fx)clipse code [1] who deals with FXCanvas,
> ... but I can't think of a situation where we create multiple classloaders.
>
> Tom
>
> [1]
> https://github.com/eclipse/efxclipse-rt/blob/3.x/modules/core/org.eclipse.fx.osgi/src/main/java/org/eclipse/fx/osgi/fxloader/FXClassLoader.java[https://github.com/eclipse/efxclipse-rt/blob/3.x/modules/core/org.eclipse.fx.osgi/src/main/java/org/eclipse/fx/osgi/fxloader/FXClassLoader.java]
>
> On 04.10.18 15:03, marcel Austenfeld wrote:
>> Hello Kevin,
>> ?
>> I still have problems with the error:
> "java.lang.IllegalStateException: Toolkit already initialized".
>> ?
>> However I found out that this error only occurs if I call SWT FXCanvas
> classes located in different Eclipse plugins.
>> ?
>> I can create multiple JavaFX canvas if they are located in one Eclipse
> plugin.
>> ?
>> Vice versa if I try to to open the JavaFX SceneBuilder canvas which is
> located in a seperate Eclipse plugin this error occurs again.
>> ?
>> So I wonder that beginning with Java 9 the JavaFX toolkit doesn't
> recognize an already started toolkit in another Eclipse plugin (which
> was definitely the case with Java 8!).
>> ?
>> Maybee this has something to do with the new module system of Java >=9?
>> ?
>> ?
>> ?
>>
>> Gesendet:?Mittwoch, 26. September 2018 um 14:09 Uhr
>> Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
>> An:?"marcel Austenfeld" <marcel.au at web.de>, openjfx-dev at openjdk.java.net
>> Betreff:?Re: "Toolkit already initialized" error with OpenJDK 11
>> I'm' not aware of anything that intentionally changed between FX in JDK
>> 8 and FX 11, but my guess is that the FX runtime is being shutdown after
>> your first FXCanvas exits. Try making the following call (only needed
>> one time) before creating your first FXCanvas:
>>
>> ??? Platform.setImplicitExit(false);
>>
>> -- Kevin
>>
>> On 9/26/2018 4:22 AM, marcel Austenfeld wrote:
>>> First of all congratulation to the new release and thank you for the
> hard work on JavaFX.
>>>
>>>
>>> I have a problem with JavaFX which in my case is embedded in a Rich
> Client Platform of Eclipse.
>>>
>>> I integrated several SWT FXCanvas (some with SwingNode panels as a
> SWT_AWT replacement) into my app.
>>>
>>> This works fine in Java 8 which my current release depends on.
>>>
>>> However in Java 11 after the second panel is initialized at startup I
> get the following error:
>>>
>>> "Caused by: java.lang.IllegalStateException: Toolkit already initialized"
>>>
>>> Is there a new option available to avoid a new initialization of the
> toolkit if several FXCanvas are embedded in an application?
>>> Or do you now any changes since Java 8 which could the cause of such
> an exception?
>>>
>>>
>>> Thanks in advance for any help.
>> ?
>>
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From marcel.au at web.de  Fri Oct  5 10:55:31 2018
From: marcel.au at web.de (marcel Austenfeld)
Date: Fri, 5 Oct 2018 12:55:31 +0200
Subject: Aw: Re:  Re: "Toolkit already initialized" error with OpenJDK 11
In-Reply-To: <62f72fa3-fe83-33f7-60f8-1545579b3d55@oracle.com>
References: <trinity-8859f5f3-6c80-4309-bc9c-abfdc1ae31ed-1537960969645@3c-app-webde-bs17>
 <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
 <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
 <62f72fa3-fe83-33f7-60f8-1545579b3d55@oracle.com>
Message-ID: <trinity-2c94dff3-6854-4f54-8535-bee7a1c19324-1538736931685@3c-app-webde-bap09>

Bug (now ID is: 8211754) can be found here:
?
https://bugs.java.com/view_bug.do?bug_id=8211754
?

Gesendet:?Donnerstag, 04. Oktober 2018 um 16:13 Uhr
Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
An:?"marcel Austenfeld" <marcel.au at web.de>
Cc:?openjfx-dev at openjdk.java.net
Betreff:?Re: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
I think I see what caused this. In FX 8 we called FXCanvas::initFx from
the constructor of every FXCanvas. It then called an internal startup
method, PlatformImpl::startup, that permits calling it when the Toolkit
is already initialized, turning it into a runLater if it is. As part of
the refactoring for FX 9 I changed it to call FXCanvas::initFx one time
from the static block. At the same time, I changed the startup call to
use the public Platform::startup method. This change was necessary
because the javafx.swt module does not have the needed qualified exports
to call internal methods until after initialization. The public
Platform::startup method is specified to throw an exception if called
more than once.

So if the FXCanvas class is loaded more than once, for example, if it is
called from different ClassLoaders, then that would cause the problem.
Please file a bug and I'll take a look at it. It might be as simple as
wrapping the call to Platform::startup in a try/catch and calling
Platform::runLater in the catch block.

-- Kevin


On 10/4/2018 6:03 AM, marcel Austenfeld wrote:
> Hello Kevin,
>
> I still have problems with the error: "java.lang.IllegalStateException: Toolkit already initialized".
>
> However I found out that this error only occurs if I call SWT FXCanvas classes located in different Eclipse plugins.
>
> I can create multiple JavaFX canvas if they are located in one Eclipse plugin.
>
> Vice versa if I try to to open the JavaFX SceneBuilder canvas which is located in a seperate Eclipse plugin this error occurs again.
>
> So I wonder that beginning with Java 9 the JavaFX toolkit doesn't recognize an already started toolkit in another Eclipse plugin (which was definitely the case with Java 8!).
>
> Maybee this has something to do with the new module system of Java >=9?
>
>
>
>
> Gesendet:?Mittwoch, 26. September 2018 um 14:09 Uhr
> Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
> An:?"marcel Austenfeld" <marcel.au at web.de>, openjfx-dev at openjdk.java.net
> Betreff:?Re: "Toolkit already initialized" error with OpenJDK 11
> I'm' not aware of anything that intentionally changed between FX in JDK
> 8 and FX 11, but my guess is that the FX runtime is being shutdown after
> your first FXCanvas exits. Try making the following call (only needed
> one time) before creating your first FXCanvas:
>
> ??? Platform.setImplicitExit(false);
>
> -- Kevin
>
> On 9/26/2018 4:22 AM, marcel Austenfeld wrote:
>> First of all congratulation to the new release and thank you for the hard work on JavaFX.
>>
>>
>> I have a problem with JavaFX which in my case is embedded in a Rich Client Platform of Eclipse.
>>
>> I integrated several SWT FXCanvas (some with SwingNode panels as a SWT_AWT replacement) into my app.
>>
>> This works fine in Java 8 which my current release depends on.
>>
>> However in Java 11 after the second panel is initialized at startup I get the following error:
>>
>> "Caused by: java.lang.IllegalStateException: Toolkit already initialized"
>>
>> Is there a new option available to avoid a new initialization of the toolkit if several FXCanvas are embedded in an application?
>> Or do you now any changes since Java 8 which could the cause of such an exception?
>>
>>
>> Thanks in advance for any help.
>
?

From kevin.rushforth at oracle.com  Fri Oct  5 11:20:07 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 5 Oct 2018 04:20:07 -0700
Subject: Aw: Re: Re: "Toolkit already initialized" error with OpenJDK 11
In-Reply-To: <trinity-461026c9-c516-4288-a951-f8375f5de57f-1538723444580@3c-app-webde-bs53>
References: <trinity-8859f5f3-6c80-4309-bc9c-abfdc1ae31ed-1537960969645@3c-app-webde-bs17>
 <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
 <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
 <62f72fa3-fe83-33f7-60f8-1545579b3d55@oracle.com>
 <trinity-461026c9-c516-4288-a951-f8375f5de57f-1538723444580@3c-app-webde-bs53>
Message-ID: <850f44d9-4d3b-529d-101c-e7f46f37ae54@oracle.com>

Thanks.

-- Kevin


On 10/5/2018 12:10 AM, marcel Austenfeld wrote:
> I created a bug report on https://bugs.java.com/
> Bug ID is: 9057517
> *Gesendet:*?Donnerstag, 04. Oktober 2018 um 16:13 Uhr
> *Von:*?"Kevin Rushforth" <kevin.rushforth at oracle.com>
> *An:*?"marcel Austenfeld" <marcel.au at web.de>
> *Cc:*?openjfx-dev at openjdk.java.net
> *Betreff:*?Re: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
> I think I see what caused this. In FX 8 we called FXCanvas::initFx from
> the constructor of every FXCanvas. It then called an internal startup
> method, PlatformImpl::startup, that permits calling it when the Toolkit
> is already initialized, turning it into a runLater if it is. As part of
> the refactoring for FX 9 I changed it to call FXCanvas::initFx one time
> from the static block. At the same time, I changed the startup call to
> use the public Platform::startup method. This change was necessary
> because the javafx.swt module does not have the needed qualified exports
> to call internal methods until after initialization. The public
> Platform::startup method is specified to throw an exception if called
> more than once.
>
> So if the FXCanvas class is loaded more than once, for example, if it is
> called from different ClassLoaders, then that would cause the problem.
> Please file a bug and I'll take a look at it. It might be as simple as
> wrapping the call to Platform::startup in a try/catch and calling
> Platform::runLater in the catch block.
>
> -- Kevin
>
>
> On 10/4/2018 6:03 AM, marcel Austenfeld wrote:
> > Hello Kevin,
> >
> > I still have problems with the error: 
> "java.lang.IllegalStateException: Toolkit already initialized".
> >
> > However I found out that this error only occurs if I call SWT 
> FXCanvas classes located in different Eclipse plugins.
> >
> > I can create multiple JavaFX canvas if they are located in one 
> Eclipse plugin.
> >
> > Vice versa if I try to to open the JavaFX SceneBuilder canvas which 
> is located in a seperate Eclipse plugin this error occurs again.
> >
> > So I wonder that beginning with Java 9 the JavaFX toolkit doesn't 
> recognize an already started toolkit in another Eclipse plugin (which 
> was definitely the case with Java 8!).
> >
> > Maybee this has something to do with the new module system of Java >=9?
> >
> >
> >
> >
> > Gesendet:?Mittwoch, 26. September 2018 um 14:09 Uhr
> > Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
> > An:?"marcel Austenfeld" <marcel.au at web.de>, openjfx-dev at openjdk.java.net
> > Betreff:?Re: "Toolkit already initialized" error with OpenJDK 11
> > I'm' not aware of anything that intentionally changed between FX in JDK
> > 8 and FX 11, but my guess is that the FX runtime is being shutdown after
> > your first FXCanvas exits. Try making the following call (only needed
> > one time) before creating your first FXCanvas:
> >
> > ??? Platform.setImplicitExit(false);
> >
> > -- Kevin
> >
> > On 9/26/2018 4:22 AM, marcel Austenfeld wrote:
> >> First of all congratulation to the new release and thank you for 
> the hard work on JavaFX.
> >>
> >>
> >> I have a problem with JavaFX which in my case is embedded in a Rich 
> Client Platform of Eclipse.
> >>
> >> I integrated several SWT FXCanvas (some with SwingNode panels as a 
> SWT_AWT replacement) into my app.
> >>
> >> This works fine in Java 8 which my current release depends on.
> >>
> >> However in Java 11 after the second panel is initialized at startup 
> I get the following error:
> >>
> >> "Caused by: java.lang.IllegalStateException: Toolkit already 
> initialized"
> >>
> >> Is there a new option available to avoid a new initialization of 
> the toolkit if several FXCanvas are embedded in an application?
> >> Or do you now any changes since Java 8 which could the cause of 
> such an exception?
> >>
> >>
> >> Thanks in advance for any help.
> >


From kevin.rushforth at oracle.com  Fri Oct  5 11:54:20 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 5 Oct 2018 04:54:20 -0700
Subject: Aw: Re: Re: "Toolkit already initialized" error with OpenJDK 11
In-Reply-To: <trinity-2c94dff3-6854-4f54-8535-bee7a1c19324-1538736931685@3c-app-webde-bap09>
References: <trinity-8859f5f3-6c80-4309-bc9c-abfdc1ae31ed-1537960969645@3c-app-webde-bs17>
 <dd60245b-8229-12f7-a301-93fbd1a559a1@oracle.com>
 <trinity-f3576e08-023c-4095-99e9-f84c152dd4ec-1538658182501@3c-app-webde-bap64>
 <62f72fa3-fe83-33f7-60f8-1545579b3d55@oracle.com>
 <trinity-2c94dff3-6854-4f54-8535-bee7a1c19324-1538736931685@3c-app-webde-bap09>
Message-ID: <1f1f13fb-f959-3ab6-b397-12e0d8d86577@oracle.com>

Or more directly, here:

https://bugs.openjdk.java.net/browse/JDK-8211754

-- Kevin

On 10/5/2018 3:55 AM, marcel Austenfeld wrote:
> Bug (now ID is: 8211754) can be found here:
>   
> https://bugs.java.com/view_bug.do?bug_id=8211754
>   
>
> Gesendet:?Donnerstag, 04. Oktober 2018 um 16:13 Uhr
> Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
> An:?"marcel Austenfeld" <marcel.au at web.de>
> Cc:?openjfx-dev at openjdk.java.net
> Betreff:?Re: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
> I think I see what caused this. In FX 8 we called FXCanvas::initFx from
> the constructor of every FXCanvas. It then called an internal startup
> method, PlatformImpl::startup, that permits calling it when the Toolkit
> is already initialized, turning it into a runLater if it is. As part of
> the refactoring for FX 9 I changed it to call FXCanvas::initFx one time
> from the static block. At the same time, I changed the startup call to
> use the public Platform::startup method. This change was necessary
> because the javafx.swt module does not have the needed qualified exports
> to call internal methods until after initialization. The public
> Platform::startup method is specified to throw an exception if called
> more than once.
>
> So if the FXCanvas class is loaded more than once, for example, if it is
> called from different ClassLoaders, then that would cause the problem.
> Please file a bug and I'll take a look at it. It might be as simple as
> wrapping the call to Platform::startup in a try/catch and calling
> Platform::runLater in the catch block.
>
> -- Kevin
>
>
> On 10/4/2018 6:03 AM, marcel Austenfeld wrote:
>> Hello Kevin,
>>
>> I still have problems with the error: "java.lang.IllegalStateException: Toolkit already initialized".
>>
>> However I found out that this error only occurs if I call SWT FXCanvas classes located in different Eclipse plugins.
>>
>> I can create multiple JavaFX canvas if they are located in one Eclipse plugin.
>>
>> Vice versa if I try to to open the JavaFX SceneBuilder canvas which is located in a seperate Eclipse plugin this error occurs again.
>>
>> So I wonder that beginning with Java 9 the JavaFX toolkit doesn't recognize an already started toolkit in another Eclipse plugin (which was definitely the case with Java 8!).
>>
>> Maybee this has something to do with the new module system of Java >=9?
>>
>>
>>
>>
>> Gesendet:?Mittwoch, 26. September 2018 um 14:09 Uhr
>> Von:?"Kevin Rushforth" <kevin.rushforth at oracle.com>
>> An:?"marcel Austenfeld" <marcel.au at web.de>, openjfx-dev at openjdk.java.net
>> Betreff:?Re: "Toolkit already initialized" error with OpenJDK 11
>> I'm' not aware of anything that intentionally changed between FX in JDK
>> 8 and FX 11, but my guess is that the FX runtime is being shutdown after
>> your first FXCanvas exits. Try making the following call (only needed
>> one time) before creating your first FXCanvas:
>>
>>  ??? Platform.setImplicitExit(false);
>>
>> -- Kevin
>>
>> On 9/26/2018 4:22 AM, marcel Austenfeld wrote:
>>> First of all congratulation to the new release and thank you for the hard work on JavaFX.
>>>
>>>
>>> I have a problem with JavaFX which in my case is embedded in a Rich Client Platform of Eclipse.
>>>
>>> I integrated several SWT FXCanvas (some with SwingNode panels as a SWT_AWT replacement) into my app.
>>>
>>> This works fine in Java 8 which my current release depends on.
>>>
>>> However in Java 11 after the second panel is initialized at startup I get the following error:
>>>
>>> "Caused by: java.lang.IllegalStateException: Toolkit already initialized"
>>>
>>> Is there a new option available to avoid a new initialization of the toolkit if several FXCanvas are embedded in an application?
>>> Or do you now any changes since Java 8 which could the cause of such an exception?
>>>
>>>
>>> Thanks in advance for any help.
>   


From sverre.moe at gmail.com  Fri Oct  5 20:26:05 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Fri, 5 Oct 2018 22:26:05 +0200
Subject: Filling the Packager gap
In-Reply-To: <34c29678-24a0-c94f-5321-b4dfa6d96c33@gmail.com>
References: <CABxFH2EMME=PJGpQMvYnpe=XpnvBQEadKMJyou8UOtFy6Bo=Hg@mail.gmail.com>
 <0e66d63a-f87d-396c-1b48-123a707c92ca@gmail.com>
 <CABxFH2GwUkZ1Vf=hXut6TH8rbzAu31kiFxXxh1EvmSq9yDd37A@mail.gmail.com>
 <34c29678-24a0-c94f-5321-b4dfa6d96c33@gmail.com>
Message-ID: <CALAJ+5BjKaftV28P3H1gjemF-qy7MNz65V0y4tXjMS-8z-_grQ@mail.gmail.com>

I am having some problems accessing the jpackager from symlinks, seems it
cannot find the jdk.packager.jar

/usr/bin/jpackager -> /etc/alternatives/jpackager
/etc/alternatives/jpackager -> /usr/java/jpackager/jpackager

:/ # jpackager --help
Error occurred during initialization of boot layer
java.lang.module.FindException: Module jdk.packager not found

Though accessing the jpackager directly works fine:
/usr/java/jpackager/jpackager

Any suggestion what the problem might be and how to remedy this?

/Sverre

From john at status6.com  Mon Oct  8 20:29:38 2018
From: john at status6.com (John Neffenger)
Date: Mon, 8 Oct 2018 13:29:38 -0700
Subject: OpenJFX FreeType Tests
Message-ID: <13a29b8c-e5c0-93d8-ca9e-e1e27132b1d7@status6.com>

I ran tests of the latest OpenJFX, built with and without the fix to set 
the LCD filter, against 5 versions of the FreeType library, built with 
and without the ClearType subpixel rendering techniques enabled, and 
posted the results of all 20 tests on the page below.

OpenJFX FreeType Tests
https://github.com/jgneff/openjdk-freetype/blob/master/javafx.md

The test results might make more sense if you first read the history 
section at the start of the page "OpenJDK FreeType Font Fix" [1].

I'm posting the results here because two of the test results could be 
considered a regression. Before the fix, OpenJFX (accidentally) got the 
new FreeType "Harmony" subpixel rendering, equal in quality to 
ClearType. After the fix, OpenJFX reverts to grayscale anti-aliasing (as 
designed).

The Harmony rendering is better, mostly due to its subpixel positioning, 
but I suggest we could wait a year before making any more related 
changes (see link above for details).

John

[1] https://github.com/jgneff/openjdk-freetype

From fluidlogix.fi at gmail.com  Tue Oct  9 04:24:48 2018
From: fluidlogix.fi at gmail.com (Fluid Logix)
Date: Tue, 9 Oct 2018 07:24:48 +0300
Subject: Undecorated Stages should display minimize & maximize animations on
 Windows
Message-ID: <CA+RjSq8mGkk_x4TZ23KrKtcyEYwFSjmDwKm4hc7ZUgG24Q01DQ@mail.gmail.com>

As the title says. Currently, undecorated Stages on Windows just instantly
disappear/appear when iconified/maximized. This looks quite unprofessional.

In addition to this, undecorated Stages cannot be minimized/restored by
clicking the taskbar-icon, without some JNA hackery.

For more details, see this StackOverflow post:
https://stackoverflow.com/questions/51008461/javafx-minimizing-maximing-undecorated-stage-with-animations

From mike.ennen at gmail.com  Tue Oct  9 05:37:32 2018
From: mike.ennen at gmail.com (Michael Ennen)
Date: Mon, 8 Oct 2018 22:37:32 -0700
Subject: Undecorated Stages should display minimize & maximize animations
 on Windows
In-Reply-To: <CA+RjSq8mGkk_x4TZ23KrKtcyEYwFSjmDwKm4hc7ZUgG24Q01DQ@mail.gmail.com>
References: <CA+RjSq8mGkk_x4TZ23KrKtcyEYwFSjmDwKm4hc7ZUgG24Q01DQ@mail.gmail.com>
Message-ID: <CAOTPd65tQCeQf_TLemSJfVxTNEcd57+RxcyEBTCusKE3rRw28g@mail.gmail.com>

I am not familiar with Windows styling but looking at the native code in
the Stackoverflow
answer it seems that it's a matter of setting the bit mask for
"WS_MINIMIZEBOX" for the
window? Looking at the native code:

https://github.com/javafxports/openjdk-jfx/blob/develop/modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp#L1233

In com.sun.glass.ui.Window there are different types of windows:

https://github.com/javafxports/openjdk-jfx/blob/develop/modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java#L114

I believe that the UTILITY mask corresponds to an undecorated stage, but am
not positive.
However, "WS_MINIMIZEBOX" is only set when:

if (mask & com_sun_glass_ui_Window_MINIMIZABLE) {
dwStyle |= WS_MINIMIZEBOX;
}

In other words, when the Window.MINIMIZABLE bit mask is set.

I am not sure if it is as simple as adding:

if (mask & com_sun_glass_ui_Window_UTILITY) {
dwStyle |= WS_MINIMIZEBOX;
dwExStyle |= WS_EX_TOOLWINDOW;
}

It looks like the Electron developers have already encountered a similar
issue
and done all of the research necessary:

https://github.com/electron/electron/issues/751
https://github.com/electron/electron/pull/800

If someone was motivated enough it should be possible to fix this behavior
by
applying the approach used above at the places I outlined in the OpenJFX
source.

Cheers,
Michael Ennen


On Mon, Oct 8, 2018 at 9:25 PM Fluid Logix <fluidlogix.fi at gmail.com> wrote:

> As the title says. Currently, undecorated Stages on Windows just instantly
> disappear/appear when iconified/maximized. This looks quite unprofessional.
>
> In addition to this, undecorated Stages cannot be minimized/restored by
> clicking the taskbar-icon, without some JNA hackery.
>
> For more details, see this StackOverflow post:
>
> https://stackoverflow.com/questions/51008461/javafx-minimizing-maximing-undecorated-stage-with-animations
>

From work at norrisfamily.org  Tue Oct  9 13:32:25 2018
From: work at norrisfamily.org (Graham Norris)
Date: Tue, 9 Oct 2018 14:32:25 +0100
Subject: Compiling using javac
Message-ID: <20181009133226.E4C5B102E9@mailuser.nyi.internal>

I have an existing Java application which uses JavaFX. It is currently compiled
(on Windows) and working using Oracle's Java 10 JDK. I am now trying to get it
to compile using OpenJDK 11 and OpenJFX 11, and failing miserably!

I use the JDK's command line tools to compile the application and haven't
managed to find anything which shows how to make the combination of an existing
application, OpenJDK 11 and OpenJFX 11 compile. Basically, I can't get javac to
find and use either OpenJFX's jmods or jars.

I feel there should be somewhere I could read instructions on how to use
OpenJFX with OpenJDK 11's javac, but if there is, I just can't find it!

Any help appreciated.

Graham.

From mp at jugs.org  Tue Oct  9 13:47:29 2018
From: mp at jugs.org (Michael Paus)
Date: Tue, 9 Oct 2018 15:47:29 +0200
Subject: Compiling using javac
In-Reply-To: <20181009133226.E4C5B102E9@mailuser.nyi.internal>
References: <20181009133226.E4C5B102E9@mailuser.nyi.internal>
Message-ID: <5c962c99-e63a-4a07-f14e-b5eed429c072@jugs.org>

The documentation you are looking for can be found here:
https://openjfx.io/openjfx-docs/

Am 09.10.18 um 15:32 schrieb Graham Norris:
> I have an existing Java application which uses JavaFX. It is currently compiled
> (on Windows) and working using Oracle's Java 10 JDK. I am now trying to get it
> to compile using OpenJDK 11 and OpenJFX 11, and failing miserably!
>
> I use the JDK's command line tools to compile the application and haven't
> managed to find anything which shows how to make the combination of an existing
> application, OpenJDK 11 and OpenJFX 11 compile. Basically, I can't get javac to
> find and use either OpenJFX's jmods or jars.
>
> I feel there should be somewhere I could read instructions on how to use
> OpenJFX with OpenJDK 11's javac, but if there is, I just can't find it!
>
> Any help appreciated.
>
> Graham.



From work at norrisfamily.org  Tue Oct  9 16:09:31 2018
From: work at norrisfamily.org (Graham Norris)
Date: Tue, 9 Oct 2018 17:09:31 +0100
Subject: Compiling using javac
In-Reply-To: <5c962c99-e63a-4a07-f14e-b5eed429c072@jugs.org>
References: <20181009133226.E4C5B102E9@mailuser.nyi.internal>
 <5c962c99-e63a-4a07-f14e-b5eed429c072@jugs.org>
Message-ID: <20181009160933.B7B27102D3@mailuser.nyi.internal>

** Reply to message from Michael Paus <mp at jugs.org> on Tue, 9 Oct 2018 15:47:29
+0200

Thank you, I'd already found this, but it isn't exactly "documentation." Also,
it is for Linux (Windows doesn't have export,) but I have put the path directly
on the --module-path option, which should be equivalent for this.

Crucially, it does not work: I get "error: module not found: javafx.controls"
I'm not entirely sure why I'd use javafx.controls as my application does not
use that, but not finding javafx.controls seems to be unrelated to lack of use,
which is also borne out by the fact that the compile fails immediately rather
than churning out dozens of errors as it tries to compile things.

Graham.

> The documentation you are looking for can be found here:
> https://openjfx.io/openjfx-docs/
> 
> Am 09.10.18 um 15:32 schrieb Graham Norris:
> > I have an existing Java application which uses JavaFX. It is currently compiled
> > (on Windows) and working using Oracle's Java 10 JDK. I am now trying to get it
> > to compile using OpenJDK 11 and OpenJFX 11, and failing miserably!
> >
> > I use the JDK's command line tools to compile the application and haven't
> > managed to find anything which shows how to make the combination of an existing
> > application, OpenJDK 11 and OpenJFX 11 compile. Basically, I can't get javac to
> > find and use either OpenJFX's jmods or jars.
> >
> > I feel there should be somewhere I could read instructions on how to use
> > OpenJFX with OpenJDK 11's javac, but if there is, I just can't find it!
> >
> > Any help appreciated.
> >
> > Graham.

From abhinay_agarwal at live.com  Tue Oct  9 16:30:18 2018
From: abhinay_agarwal at live.com (Abhinay Agarwal)
Date: Tue, 9 Oct 2018 16:30:18 +0000
Subject: Compiling using javac
In-Reply-To: <20181009160933.B7B27102D3@mailuser.nyi.internal>
References: <20181009133226.E4C5B102E9@mailuser.nyi.internal>
 <5c962c99-e63a-4a07-f14e-b5eed429c072@jugs.org>,
 <20181009160933.B7B27102D3@mailuser.nyi.internal>
Message-ID: <HK2PR0301MB205244C7365AE985F57FEB65E7E70@HK2PR0301MB2052.apcprd03.prod.outlook.com>

Hi Graham,

Its really difficult to help without checking out the failing command first.

Could you reply back with the "javac" command you are trying to execute, along with the stacktrace?

-- Abhinay
________________________________
From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> on behalf of Graham Norris <work at norrisfamily.org>
Sent: Tuesday, October 9, 2018 9:39 PM
To: openjfx-dev at openjdk.java.net
Subject: Re: Compiling using javac

** Reply to message from Michael Paus <mp at jugs.org> on Tue, 9 Oct 2018 15:47:29
+0200

Thank you, I'd already found this, but it isn't exactly "documentation." Also,
it is for Linux (Windows doesn't have export,) but I have put the path directly
on the --module-path option, which should be equivalent for this.

Crucially, it does not work: I get "error: module not found: javafx.controls"
I'm not entirely sure why I'd use javafx.controls as my application does not
use that, but not finding javafx.controls seems to be unrelated to lack of use,
which is also borne out by the fact that the compile fails immediately rather
than churning out dozens of errors as it tries to compile things.

Graham.

> The documentation you are looking for can be found here:
> https://openjfx.io/openjfx-docs/
>
> Am 09.10.18 um 15:32 schrieb Graham Norris:
> > I have an existing Java application which uses JavaFX. It is currently compiled
> > (on Windows) and working using Oracle's Java 10 JDK. I am now trying to get it
> > to compile using OpenJDK 11 and OpenJFX 11, and failing miserably!
> >
> > I use the JDK's command line tools to compile the application and haven't
> > managed to find anything which shows how to make the combination of an existing
> > application, OpenJDK 11 and OpenJFX 11 compile. Basically, I can't get javac to
> > find and use either OpenJFX's jmods or jars.
> >
> > I feel there should be somewhere I could read instructions on how to use
> > OpenJFX with OpenJDK 11's javac, but if there is, I just can't find it!
> >
> > Any help appreciated.
> >
> > Graham.

From marcel.au at web.de  Wed Oct 10 07:58:16 2018
From: marcel.au at web.de (marcel Austenfeld)
Date: Wed, 10 Oct 2018 09:58:16 +0200
Subject: CSS Import Error with Java 11
Message-ID: <trinity-34f1b51a-edc6-452a-8872-c9be1b171b97-1539158296003@3c-app-webde-bap14>

For my application I apply a custom stylesheet for the JavafX components, e.g., to switch from a light to a dark theme to colorize, e.g., the SceneBuilder and
other JavaFX components I use.
?
So at startup I load and apply a custom stylesheet with: javafx.application.Application.setUserAgentStylesheet(myPath/my.css);
?
In the file my.css I import the default modena.css with:
?
@import "com/sun/javafx/scene/control/skin/modena/modena.css";
?
Then in my.css I overwrite some styles.
?
This works fine in Java 8 but fails with Java 11 with the following message:
?
WARNING: resolveRuntimeImport cannot resolve: com/sun/javafx/scene/control/skin/modena/modena.css
Okt. 10, 2018 9:45:36 VORM. com.sun.javafx.css.StyleManager loadStylesheetUnPrivileged
INFO: Could not find stylesheet: bundleentry://273.fwk1678623942/javafx/com/sun/javafx/scene/control/skin/modena/modena.css
Okt. 10, 2018 9:45:36 VORM. javafx.css.CssParser handleImport
?
Is this not valid anymore in Java 11? Are there any workarounds to apply a theme in Java 11?
?
Thanks in advance for any answer.

From work at norrisfamily.org  Wed Oct 10 09:29:06 2018
From: work at norrisfamily.org (Graham Norris)
Date: Wed, 10 Oct 2018 10:29:06 +0100
Subject: Compiling using javac
In-Reply-To: <HK2PR0301MB205244C7365AE985F57FEB65E7E70@HK2PR0301MB2052.apcprd03.prod.outlook.com>
References: <20181009133226.E4C5B102E9@mailuser.nyi.internal>
 <5c962c99-e63a-4a07-f14e-b5eed429c072@jugs.org>,
 <20181009160933.B7B27102D3@mailuser.nyi.internal> 
 <HK2PR0301MB205244C7365AE985F57FEB65E7E70@HK2PR0301MB2052.apcprd03.prod.outlook.com>
Message-ID: <20181010092907.322BE102EA@mailuser.nyi.internal>

** Reply to message from Abhinay Agarwal <abhinay_agarwal at live.com> on Tue, 9
Oct 2018 16:30:18 +0000

No stack trace from either type of failure, just error messages. I've tried
compiling that example program, with the following result:

D:\pbmdev>dir HelloFX.java&set PATH_TO_FX&dir %PATH_TO_FX%javafx.*&javac
--module-path %PATH_TO_FX% --add-modules=javafx.controls HelloFX
 Volume in drive D is DataVolume
 Volume Serial Number is 64B0-54F9

 Directory of D:\pbmdev

10/10/2018  10:19               642 HelloFX.java
               1 File(s)            642 bytes
               0 Dir(s)  80,740,716,544 bytes free
PATH_TO_FX="c:\Program Files\Java\JDK-11.028\lib\"
 Volume in drive C is System
 Volume Serial Number is 5EC2-1518

 Directory of c:\Program Files\Java\JDK-11.028\lib

13/09/2018  15:57           749,886 javafx.base.jar
13/09/2018  15:57         2,511,103 javafx.controls.jar
13/09/2018  15:57           127,394 javafx.fxml.jar
13/09/2018  15:57         4,292,697 javafx.graphics.jar
13/09/2018  15:57           270,594 javafx.media.jar
13/09/2018  15:57                71 javafx.properties
13/09/2018  15:57           119,848 javafx.swing.jar
13/09/2018  15:57           712,651 javafx.web.jar
               8 File(s)      8,784,244 bytes
               0 Dir(s)  41,713,242,112 bytes free
error: no source files

D:\pbmdev>

> Hi Graham,
> 
> Its really difficult to help without checking out the failing command first.
> 
> Could you reply back with the "javac" command you are trying to execute, along with the stacktrace?
> 
> -- Abhinay
> ________________________________
> From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> on behalf of Graham Norris <work at norrisfamily.org>
> Sent: Tuesday, October 9, 2018 9:39 PM
> To: openjfx-dev at openjdk.java.net
> Subject: Re: Compiling using javac
> 
> ** Reply to message from Michael Paus <mp at jugs.org> on Tue, 9 Oct 2018 15:47:29
> +0200
> 
> Thank you, I'd already found this, but it isn't exactly "documentation." Also,
> it is for Linux (Windows doesn't have export,) but I have put the path directly
> on the --module-path option, which should be equivalent for this.
> 
> Crucially, it does not work: I get "error: module not found: javafx.controls"
> I'm not entirely sure why I'd use javafx.controls as my application does not
> use that, but not finding javafx.controls seems to be unrelated to lack of use,
> which is also borne out by the fact that the compile fails immediately rather
> than churning out dozens of errors as it tries to compile things.
> 
> Graham.
> 
> > The documentation you are looking for can be found here:
> > https://openjfx.io/openjfx-docs/
> >
> > Am 09.10.18 um 15:32 schrieb Graham Norris:
> > > I have an existing Java application which uses JavaFX. It is currently compiled
> > > (on Windows) and working using Oracle's Java 10 JDK. I am now trying to get it
> > > to compile using OpenJDK 11 and OpenJFX 11, and failing miserably!
> > >
> > > I use the JDK's command line tools to compile the application and haven't
> > > managed to find anything which shows how to make the combination of an existing
> > > application, OpenJDK 11 and OpenJFX 11 compile. Basically, I can't get javac to
> > > find and use either OpenJFX's jmods or jars.
> > >
> > > I feel there should be somewhere I could read instructions on how to use
> > > OpenJFX with OpenJDK 11's javac, but if there is, I just can't find it!
> > >
> > > Any help appreciated.
> > >
> > > Graham.

From abhinay_agarwal at live.com  Wed Oct 10 09:48:59 2018
From: abhinay_agarwal at live.com (Abhinay Agarwal)
Date: Wed, 10 Oct 2018 09:48:59 +0000
Subject: Compiling using javac
In-Reply-To: <20181010092907.322BE102EA@mailuser.nyi.internal>
References: <20181010092907.322BE102EA@mailuser.nyi.internal>
Message-ID: <HK2PR0301MB20524AA630E63236FF3CF0EBE7E00@HK2PR0301MB2052.apcprd03.prod.outlook.com>

Hi Graham,

The error "module not found: javafx.controls" can be caused when env variable 'PATH_TO_FX' is targeting the 'JavaFX SDK' instead of 'JavaFX SDK/lib' directory

The following works for me on a Windows machine:

> set JAVA_HOME="C:\Program Files\Java\jdk-11"
> set PATH_TO_FX="C:\Program Files\Java\javafx-sdk-11\lib"
> %JAVA_HOME%\bin\javac --module-path %PATH_TO_FX% --add-modules=javafx.controls HelloFX.java
> %JAVA_HOME%\bin\java --module-path %PATH_TO_FX% --add-modules=javafx.controls HelloFX

-- Abhinay


On Oct 10 2018, at 2:59 pm, Graham Norris <work at norrisfamily.org> wrote:

** Reply to message from Abhinay Agarwal <abhinay_agarwal at live.com> on Tue, 9
Oct 2018 16:30:18 +0000

No stack trace from either type of failure, just error messages. I've tried
compiling that example program, with the following result:

D:\pbmdev>dir HelloFX.java&set PATH_TO_FX&dir %PATH_TO_FX%javafx.*&javac
--module-path %PATH_TO_FX% --add-modules=javafx.controls HelloFX
Volume in drive D is DataVolume
Volume Serial Number is 64B0-54F9

Directory of D:\pbmdev

10/10/2018 10:19 642 HelloFX.java
1 File(s) 642 bytes
0 Dir(s) 80,740,716,544 bytes free
PATH_TO_FX="c:\Program Files\Java\JDK-11.028\lib\"
Volume in drive C is System
Volume Serial Number is 5EC2-1518

Directory of c:\Program Files\Java\JDK-11.028\lib

13/09/2018 15:57 749,886 javafx.base.jar
13/09/2018 15:57 2,511,103 javafx.controls.jar
13/09/2018 15:57 127,394 javafx.fxml.jar
13/09/2018 15:57 4,292,697 javafx.graphics.jar
13/09/2018 15:57 270,594 javafx.media.jar
13/09/2018 15:57 71 javafx.properties
13/09/2018 15:57 119,848 javafx.swing.jar
13/09/2018 15:57 712,651 javafx.web.jar
8 File(s) 8,784,244 bytes
0 Dir(s) 41,713,242,112 bytes free
error: no source files

D:\pbmdev>

Hi Graham,

Its really difficult to help without checking out the failing command first.

Could you reply back with the "javac" command you are trying to execute, along with the stacktrace?

-- Abhinay
________________________________
From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> on behalf of Graham Norris <work at norrisfamily.org>
Sent: Tuesday, October 9, 2018 9:39 PM
To: openjfx-dev at openjdk.java.net
Subject: Re: Compiling using javac

** Reply to message from Michael Paus <mp at jugs.org> on Tue, 9 Oct 2018 15:47:29
+0200

Thank you, I'd already found this, but it isn't exactly "documentation." Also,
it is for Linux (Windows doesn't have export,) but I have put the path directly
on the --module-path option, which should be equivalent for this.

Crucially, it does not work: I get "error: module not found: javafx.controls"
I'm not entirely sure why I'd use javafx.controls as my application does not
use that, but not finding javafx.controls seems to be unrelated to lack of use,
which is also borne out by the fact that the compile fails immediately rather
than churning out dozens of errors as it tries to compile things.

Graham.

The documentation you are looking for can be found here:
https://openjfx.io/openjfx-docs/

Am 09.10.18 um 15:32 schrieb Graham Norris:
I have an existing Java application which uses JavaFX. It is currently compiled
(on Windows) and working using Oracle's Java 10 JDK. I am now trying to get it
to compile using OpenJDK 11 and OpenJFX 11, and failing miserably!

I use the JDK's command line tools to compile the application and haven't
managed to find anything which shows how to make the combination of an existing
application, OpenJDK 11 and OpenJFX 11 compile. Basically, I can't get javac to
find and use either OpenJFX's jmods or jars.

I feel there should be somewhere I could read instructions on how to use
OpenJFX with OpenJDK 11's javac, but if there is, I just can't find it!

Any help appreciated.

Graham.


From abhinay_agarwal at live.com  Wed Oct 10 09:49:06 2018
From: abhinay_agarwal at live.com (Abhinay Agarwal)
Date: Wed, 10 Oct 2018 09:49:06 +0000
Subject: Compiling using javac
In-Reply-To: <20181010092907.322BE102EA@mailuser.nyi.internal>
References: <20181010092907.322BE102EA@mailuser.nyi.internal>
Message-ID: <HK2PR0301MB20529E7028BDC18FC1AE1BD5E7E00@HK2PR0301MB2052.apcprd03.prod.outlook.com>

Hi Graham,

The error "module not found: javafx.controls" can be caused when env variable 'PATH_TO_FX' is targeting the 'JavaFX SDK' instead of 'JavaFX SDK/lib' directory

The following works for me on a Windows machine:

> set JAVA_HOME="C:\Program Files\Java\jdk-11"
> set PATH_TO_FX="C:\Program Files\Java\javafx-sdk-11\lib"
> %JAVA_HOME%\bin\javac --module-path %PATH_TO_FX% --add-modules=javafx.controls HelloFX.java
> %JAVA_HOME%\bin\java --module-path %PATH_TO_FX% --add-modules=javafx.controls HelloFX

-- Abhinay


On Oct 10 2018, at 2:59 pm, Graham Norris <work at norrisfamily.org> wrote:

** Reply to message from Abhinay Agarwal <abhinay_agarwal at live.com> on Tue, 9
Oct 2018 16:30:18 +0000

No stack trace from either type of failure, just error messages. I've tried
compiling that example program, with the following result:

D:\pbmdev>dir HelloFX.java&set PATH_TO_FX&dir %PATH_TO_FX%javafx.*&javac
--module-path %PATH_TO_FX% --add-modules=javafx.controls HelloFX
Volume in drive D is DataVolume
Volume Serial Number is 64B0-54F9

Directory of D:\pbmdev

10/10/2018 10:19 642 HelloFX.java
1 File(s) 642 bytes
0 Dir(s) 80,740,716,544 bytes free
PATH_TO_FX="c:\Program Files\Java\JDK-11.028\lib\"
Volume in drive C is System
Volume Serial Number is 5EC2-1518

Directory of c:\Program Files\Java\JDK-11.028\lib

13/09/2018 15:57 749,886 javafx.base.jar
13/09/2018 15:57 2,511,103 javafx.controls.jar
13/09/2018 15:57 127,394 javafx.fxml.jar
13/09/2018 15:57 4,292,697 javafx.graphics.jar
13/09/2018 15:57 270,594 javafx.media.jar
13/09/2018 15:57 71 javafx.properties
13/09/2018 15:57 119,848 javafx.swing.jar
13/09/2018 15:57 712,651 javafx.web.jar
8 File(s) 8,784,244 bytes
0 Dir(s) 41,713,242,112 bytes free
error: no source files

D:\pbmdev>

Hi Graham,

Its really difficult to help without checking out the failing command first.

Could you reply back with the "javac" command you are trying to execute, along with the stacktrace?

-- Abhinay
________________________________
From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> on behalf of Graham Norris <work at norrisfamily.org>
Sent: Tuesday, October 9, 2018 9:39 PM
To: openjfx-dev at openjdk.java.net
Subject: Re: Compiling using javac

** Reply to message from Michael Paus <mp at jugs.org> on Tue, 9 Oct 2018 15:47:29
+0200

Thank you, I'd already found this, but it isn't exactly "documentation." Also,
it is for Linux (Windows doesn't have export,) but I have put the path directly
on the --module-path option, which should be equivalent for this.

Crucially, it does not work: I get "error: module not found: javafx.controls"
I'm not entirely sure why I'd use javafx.controls as my application does not
use that, but not finding javafx.controls seems to be unrelated to lack of use,
which is also borne out by the fact that the compile fails immediately rather
than churning out dozens of errors as it tries to compile things.

Graham.

The documentation you are looking for can be found here:
https://openjfx.io/openjfx-docs/

Am 09.10.18 um 15:32 schrieb Graham Norris:
I have an existing Java application which uses JavaFX. It is currently compiled
(on Windows) and working using Oracle's Java 10 JDK. I am now trying to get it
to compile using OpenJDK 11 and OpenJFX 11, and failing miserably!

I use the JDK's command line tools to compile the application and haven't
managed to find anything which shows how to make the combination of an existing
application, OpenJDK 11 and OpenJFX 11 compile. Basically, I can't get javac to
find and use either OpenJFX's jmods or jars.

I feel there should be somewhere I could read instructions on how to use
OpenJFX with OpenJDK 11's javac, but if there is, I just can't find it!

Any help appreciated.

Graham.


From work at norrisfamily.org  Wed Oct 10 11:39:53 2018
From: work at norrisfamily.org (Graham Norris)
Date: Wed, 10 Oct 2018 12:39:53 +0100
Subject: Compiling using javac
In-Reply-To: <20181010092907.322BE102EA@mailuser.nyi.internal>
References: <20181009133226.E4C5B102E9@mailuser.nyi.internal>
 <5c962c99-e63a-4a07-f14e-b5eed429c072@jugs.org>, 
 <20181009160933.B7B27102D3@mailuser.nyi.internal>
 <HK2PR0301MB205244C7365AE985F57FEB65E7E70@HK2PR0301MB2052.apcprd03.prod.outlook.com>
 <20181010092907.322BE102EA@mailuser.nyi.internal>
Message-ID: <20181010113953.B121A102DD@mailuser.nyi.internal>

** Reply to message from "Graham Norris" <work at norrisfamily.org> on Wed, 10 Oct
2018 10:29:06 +0100

Correction to previous test (omitted ".java":)

D:\pbmdev>dir HelloFX.java&set PATH_TO_FX&dir %PATH_TO_FX%javafx.*&javac
--module-path %PATH_TO_FX% --add-modules=javafx.controls HelloFX.java
 Volume in drive D is DataVolume
 Volume Serial Number is 64B0-54F9

 Directory of D:\pbmdev

10/10/2018  10:19               642 HelloFX.java
               1 File(s)            642 bytes
               0 Dir(s)  80,738,893,824 bytes free
PATH_TO_FX="c:\Program Files\Java\JDK-11.028\lib\"
 Volume in drive C is System
 Volume Serial Number is 5EC2-1518

 Directory of c:\Program Files\Java\JDK-11.028\lib

13/09/2018  15:57           749,886 javafx.base.jar
13/09/2018  15:57         2,511,103 javafx.controls.jar
13/09/2018  15:57           127,394 javafx.fxml.jar
13/09/2018  15:57         4,292,697 javafx.graphics.jar
13/09/2018  15:57           270,594 javafx.media.jar
13/09/2018  15:57                71 javafx.properties
13/09/2018  15:57           119,848 javafx.swing.jar
13/09/2018  15:57           712,651 javafx.web.jar
               8 File(s)      8,784,244 bytes
               0 Dir(s)  41,705,066,496 bytes free
error: no source files

> ** Reply to message from Abhinay Agarwal <abhinay_agarwal at live.com> on Tue, 9
> Oct 2018 16:30:18 +0000
> 
> No stack trace from either type of failure, just error messages. I've tried
> compiling that example program, with the following result:
> 
> D:\pbmdev>dir HelloFX.java&set PATH_TO_FX&dir %PATH_TO_FX%javafx.*&javac
> --module-path %PATH_TO_FX% --add-modules=javafx.controls HelloFX
>  Volume in drive D is DataVolume
>  Volume Serial Number is 64B0-54F9
> 
>  Directory of D:\pbmdev
> 
> 10/10/2018  10:19               642 HelloFX.java
>                1 File(s)            642 bytes
>                0 Dir(s)  80,740,716,544 bytes free
> PATH_TO_FX="c:\Program Files\Java\JDK-11.028\lib\"
>  Volume in drive C is System
>  Volume Serial Number is 5EC2-1518
> 
>  Directory of c:\Program Files\Java\JDK-11.028\lib
> 
> 13/09/2018  15:57           749,886 javafx.base.jar
> 13/09/2018  15:57         2,511,103 javafx.controls.jar
> 13/09/2018  15:57           127,394 javafx.fxml.jar
> 13/09/2018  15:57         4,292,697 javafx.graphics.jar
> 13/09/2018  15:57           270,594 javafx.media.jar
> 13/09/2018  15:57                71 javafx.properties
> 13/09/2018  15:57           119,848 javafx.swing.jar
> 13/09/2018  15:57           712,651 javafx.web.jar
>                8 File(s)      8,784,244 bytes
>                0 Dir(s)  41,713,242,112 bytes free
> error: no source files
> 
> D:\pbmdev>
> 
> > Hi Graham,
> > 
> > Its really difficult to help without checking out the failing command first.
> > 
> > Could you reply back with the "javac" command you are trying to execute, along with the stacktrace?
> > 
> > -- Abhinay
> > ________________________________
> > From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> on behalf of Graham Norris <work at norrisfamily.org>
> > Sent: Tuesday, October 9, 2018 9:39 PM
> > To: openjfx-dev at openjdk.java.net
> > Subject: Re: Compiling using javac
> > 
> > ** Reply to message from Michael Paus <mp at jugs.org> on Tue, 9 Oct 2018 15:47:29
> > +0200
> > 
> > Thank you, I'd already found this, but it isn't exactly "documentation." Also,
> > it is for Linux (Windows doesn't have export,) but I have put the path directly
> > on the --module-path option, which should be equivalent for this.
> > 
> > Crucially, it does not work: I get "error: module not found: javafx.controls"
> > I'm not entirely sure why I'd use javafx.controls as my application does not
> > use that, but not finding javafx.controls seems to be unrelated to lack of use,
> > which is also borne out by the fact that the compile fails immediately rather
> > than churning out dozens of errors as it tries to compile things.
> > 
> > Graham.
> > 
> > > The documentation you are looking for can be found here:
> > > https://openjfx.io/openjfx-docs/
> > >
> > > Am 09.10.18 um 15:32 schrieb Graham Norris:
> > > > I have an existing Java application which uses JavaFX. It is currently compiled
> > > > (on Windows) and working using Oracle's Java 10 JDK. I am now trying to get it
> > > > to compile using OpenJDK 11 and OpenJFX 11, and failing miserably!
> > > >
> > > > I use the JDK's command line tools to compile the application and haven't
> > > > managed to find anything which shows how to make the combination of an existing
> > > > application, OpenJDK 11 and OpenJFX 11 compile. Basically, I can't get javac to
> > > > find and use either OpenJFX's jmods or jars.
> > > >
> > > > I feel there should be somewhere I could read instructions on how to use
> > > > OpenJFX with OpenJDK 11's javac, but if there is, I just can't find it!
> > > >
> > > > Any help appreciated.
> > > >
> > > > Graham.

From pankaj.b.bansal at oracle.com  Wed Oct 10 12:09:18 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Wed, 10 Oct 2018 12:09:18 +0000 (UTC)
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK
 3 on Linux
In-Reply-To: <8f955a90-7e21-9369-6b8d-bce84c36dfd4@oracle.com>
References: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
 <83da2996-f6a9-ac90-65f5-25679c1a0d4c@oracle.com>
 <8f955a90-7e21-9369-6b8d-bce84c36dfd4@oracle.com>
Message-ID: <6f235abc-5ccb-4bed-b3ea-63fe9e5db546@default>

Hi Kevin,

Thanks for review and the information provided.

I have updated the webrev for the proposed change from RTLD_GLOBAL to RTLD_LOCAL in launcher.c. Along with the this change, the new patch also includes the backport of two more fixes mentioned below. So now we have backported total of 20 bugs. 

19. JDK-8171985: Fx applet fails to get loaded on Ubuntu with jre9-b150
20. JDK-8171928: Build fails on Oracle Linux 7 with unused parameter warning

I have tested it on all three platforms (Windows 10, Linux (Ubuntu 18.4 LTS, Ubuntu 16.04 LTS) and and Mac) and no new test failures are found. I have tested the "HelloWebView" and "Ensemble" and I don't see any issue. I did some sanity testing on OL 7.5 as well and things look good to me.

Webrev:
http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.01/

Regards,
Pankaj


-----Original Message-----
From: Kevin Rushforth 
Sent: Thursday, October 4, 2018 7:41 AM
To: Pankaj Bansal; openjfx-dev at openjdk.java.net
Subject: Re: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK 3 on Linux

I debugged this offline earlier today, and it looks related to a collision in the glib library. As I mentioned offline, a possible solution is to remove RTLD_GLOBAL from the dlopen of the libglassgtk{2,3}.so library. I was able to do a full build / test on both GTK 2 and GTK 3 including media and webkit with that modification.

Overall, this is looking quite good.

One more thing: the patch adds several new tests, so you will need to run at least the new tests on all three platforms (a quick check on Mac shows a couple failures).

I also see a couple differences between jfx-dev and 8u-dev in the native code that should be looked into to make sure there wasn't a missed fix on the backport (the Hi-DPI diffs are expected, but I see a couple others).

-- Kevin


On 10/3/2018 10:16 AM, Kevin Rushforth wrote:
> My initial testing shows a couple problems which will need to be
> resolved:
>
> 1) I get many GTK warnings relating to Pango when running HelloWebView
> 2) Running any program that uses media crashes
>
> This is on Ubuntu 16.04 LTS using the default GTK 2 mode.
>
> -- Kevin
>
>
> On 10/3/2018 3:26 AM, Pankaj Bansal wrote:
>>
>> Hi All,
>>
>> Please review the patch for 8u-dev backport for JDK-8087516 
>> <https://bugs.openjdk.java.net/browse/JDK-8087516>. It adds 
>> conditional support for gtk3.
>>
>> Along with the enhancement, following bug fixes have also been 
>> included in the backport webrev
>>
>> 1.https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] invalid 
>> rendering of FX app stage in case of scaling
>>
>> 2.https://bugs.openjdk.java.net/browse/JDK-8163496: Rework Glass GTK 
>> to correct gtk3 structure sizes
>>
>> 3.https://bugs.openjdk.java.net/browse/JDK-8145837: Remove deprecated
>> GTK2 calls in JavaFX
>>
>> 4.https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to newer 
>> version of SWT for build/test
>>
>> 5.https://bugs.openjdk.java.net/browse/JDK-8171330: Issues with 
>> transparent stage and GTK
>>
>> 6.https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: JavaFX 
>> window not painted with background when using GTK 3
>>
>> 7.https://bugs.openjdk.java.net/browse/JDK-8166414: Scene returns 
>> incorrect coordinates
>>
>> 8.https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04: 
>> expandable content goes outside of the alert dialog
>>
>> 9.https://bugs.openjdk.java.net/browse/JDK-8152421: After initing the 
>> modality of a non-primary stage to MODAL, closing that stage causes 
>> the primary stage to become non-resizable
>>
>> 10.https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux] 
>> Restoring owner stage after minimize does not restore position of 
>> child stage
>>
>> 11.https://bugs.openjdk.java.net/browse/JDK-8173901: Linux: Position 
>> of Stage is not restored after exiting full screen
>>
>> 12.https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: Dialog 
>> windows come up 1-pixel wide
>>
>> 13.https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: Stage 
>> initially in full-screen mode not shown when exiting full-screen
>>
>> 14.https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown 
>> position regression and not painting correctly tooltips regression
>>
>> 15.https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not always 
>> selected properly with GTK 3
>>
>> 16.https://bugs.openjdk.java.net/browse/JDK-8172219: Allow compiling 
>> without GTK 3.0 being installed
>>
>> 17.https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk 
>> version if SWT used via FXCanvas
>>
>> 18.https://bugs.openjdk.java.net/browse/JDK-8156491: Autodetect GTK 
>> version for JFX
>>
>> The original gtk3 backport patch applied cleanly, but the bugs did 
>> not apply cleanly. So a review is required.
>>
>> I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu 16.04 
>> LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux 7.5.
>>
>> webrev: 
>> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8087516
>>
>> JDK 9 Changeset: 
>> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
>>
>> Regards,
>>
>> Pankaj
>>
>


From kevin.rushforth at oracle.com  Wed Oct 10 17:04:23 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 10 Oct 2018 10:04:23 -0700
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK
 3 on Linux
In-Reply-To: <6f235abc-5ccb-4bed-b3ea-63fe9e5db546@default>
References: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
 <83da2996-f6a9-ac90-65f5-25679c1a0d4c@oracle.com>
 <8f955a90-7e21-9369-6b8d-bce84c36dfd4@oracle.com>
 <6f235abc-5ccb-4bed-b3ea-63fe9e5db546@default>
Message-ID: <646f953d-c6cd-c3fb-2649-0bf88371775b@oracle.com>

Looks good. I have done full testing with both GTK 2 and GTK 3 on Ubuntu 
16.04 with a sanity check on Oracle Linux.

+1 (note that you will need a second reviewer)

As a reminder of what we discussed off-line, please use "8206246" as the 
bug ID when pushing this change (rather than 8087516), since this fix is 
the accumulation of 20 bugs.

-- Kevin


On 10/10/2018 5:09 AM, Pankaj Bansal wrote:
> Hi Kevin,
>
> Thanks for review and the information provided.
>
> I have updated the webrev for the proposed change from RTLD_GLOBAL to RTLD_LOCAL in launcher.c. Along with the this change, the new patch also includes the backport of two more fixes mentioned below. So now we have backported total of 20 bugs.
>
> 19. JDK-8171985: Fx applet fails to get loaded on Ubuntu with jre9-b150
> 20. JDK-8171928: Build fails on Oracle Linux 7 with unused parameter warning
>
> I have tested it on all three platforms (Windows 10, Linux (Ubuntu 18.4 LTS, Ubuntu 16.04 LTS) and and Mac) and no new test failures are found. I have tested the "HelloWebView" and "Ensemble" and I don't see any issue. I did some sanity testing on OL 7.5 as well and things look good to me.
>
> Webrev:
> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.01/
>
> Regards,
> Pankaj
>
>
> -----Original Message-----
> From: Kevin Rushforth
> Sent: Thursday, October 4, 2018 7:41 AM
> To: Pankaj Bansal; openjfx-dev at openjdk.java.net
> Subject: Re: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK 3 on Linux
>
> I debugged this offline earlier today, and it looks related to a collision in the glib library. As I mentioned offline, a possible solution is to remove RTLD_GLOBAL from the dlopen of the libglassgtk{2,3}.so library. I was able to do a full build / test on both GTK 2 and GTK 3 including media and webkit with that modification.
>
> Overall, this is looking quite good.
>
> One more thing: the patch adds several new tests, so you will need to run at least the new tests on all three platforms (a quick check on Mac shows a couple failures).
>
> I also see a couple differences between jfx-dev and 8u-dev in the native code that should be looked into to make sure there wasn't a missed fix on the backport (the Hi-DPI diffs are expected, but I see a couple others).
>
> -- Kevin
>
>
> On 10/3/2018 10:16 AM, Kevin Rushforth wrote:
>> My initial testing shows a couple problems which will need to be
>> resolved:
>>
>> 1) I get many GTK warnings relating to Pango when running HelloWebView
>> 2) Running any program that uses media crashes
>>
>> This is on Ubuntu 16.04 LTS using the default GTK 2 mode.
>>
>> -- Kevin
>>
>>
>> On 10/3/2018 3:26 AM, Pankaj Bansal wrote:
>>> Hi All,
>>>
>>> Please review the patch for 8u-dev backport for JDK-8087516
>>> <https://bugs.openjdk.java.net/browse/JDK-8087516>. It adds
>>> conditional support for gtk3.
>>>
>>> Along with the enhancement, following bug fixes have also been
>>> included in the backport webrev
>>>
>>> 1.https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] invalid
>>> rendering of FX app stage in case of scaling
>>>
>>> 2.https://bugs.openjdk.java.net/browse/JDK-8163496: Rework Glass GTK
>>> to correct gtk3 structure sizes
>>>
>>> 3.https://bugs.openjdk.java.net/browse/JDK-8145837: Remove deprecated
>>> GTK2 calls in JavaFX
>>>
>>> 4.https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to newer
>>> version of SWT for build/test
>>>
>>> 5.https://bugs.openjdk.java.net/browse/JDK-8171330: Issues with
>>> transparent stage and GTK
>>>
>>> 6.https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: JavaFX
>>> window not painted with background when using GTK 3
>>>
>>> 7.https://bugs.openjdk.java.net/browse/JDK-8166414: Scene returns
>>> incorrect coordinates
>>>
>>> 8.https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04:
>>> expandable content goes outside of the alert dialog
>>>
>>> 9.https://bugs.openjdk.java.net/browse/JDK-8152421: After initing the
>>> modality of a non-primary stage to MODAL, closing that stage causes
>>> the primary stage to become non-resizable
>>>
>>> 10.https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux]
>>> Restoring owner stage after minimize does not restore position of
>>> child stage
>>>
>>> 11.https://bugs.openjdk.java.net/browse/JDK-8173901: Linux: Position
>>> of Stage is not restored after exiting full screen
>>>
>>> 12.https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: Dialog
>>> windows come up 1-pixel wide
>>>
>>> 13.https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: Stage
>>> initially in full-screen mode not shown when exiting full-screen
>>>
>>> 14.https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown
>>> position regression and not painting correctly tooltips regression
>>>
>>> 15.https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not always
>>> selected properly with GTK 3
>>>
>>> 16.https://bugs.openjdk.java.net/browse/JDK-8172219: Allow compiling
>>> without GTK 3.0 being installed
>>>
>>> 17.https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk
>>> version if SWT used via FXCanvas
>>>
>>> 18.https://bugs.openjdk.java.net/browse/JDK-8156491: Autodetect GTK
>>> version for JFX
>>>
>>> The original gtk3 backport patch applied cleanly, but the bugs did
>>> not apply cleanly. So a review is required.
>>>
>>> I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu 16.04
>>> LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux 7.5.
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8087516
>>>
>>> JDK 9 Changeset:
>>> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
>>>
>>> Regards,
>>>
>>> Pankaj
>>>


From johan.vos at gluonhq.com  Wed Oct 10 20:08:51 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 10 Oct 2018 22:08:51 +0200
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK
 3 on Linux
In-Reply-To: <646f953d-c6cd-c3fb-2649-0bf88371775b@oracle.com>
References: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
 <83da2996-f6a9-ac90-65f5-25679c1a0d4c@oracle.com>
 <8f955a90-7e21-9369-6b8d-bce84c36dfd4@oracle.com>
 <6f235abc-5ccb-4bed-b3ea-63fe9e5db546@default>
 <646f953d-c6cd-c3fb-2649-0bf88371775b@oracle.com>
Message-ID: <CABxFH2Fqhf+NQn62HaX97xBNWF6M--2_WazkT9oBoNZNVkJSGg@mail.gmail.com>

I will test on Ubuntu 18.04 and 16.04 tomorrow.

On Wed, Oct 10, 2018 at 10:05 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Looks good. I have done full testing with both GTK 2 and GTK 3 on Ubuntu
> 16.04 with a sanity check on Oracle Linux.
>
> +1 (note that you will need a second reviewer)
>
> As a reminder of what we discussed off-line, please use "8206246" as the
> bug ID when pushing this change (rather than 8087516), since this fix is
> the accumulation of 20 bugs.
>
> -- Kevin
>
>
> On 10/10/2018 5:09 AM, Pankaj Bansal wrote:
> > Hi Kevin,
> >
> > Thanks for review and the information provided.
> >
> > I have updated the webrev for the proposed change from RTLD_GLOBAL to
> RTLD_LOCAL in launcher.c. Along with the this change, the new patch also
> includes the backport of two more fixes mentioned below. So now we have
> backported total of 20 bugs.
> >
> > 19. JDK-8171985: Fx applet fails to get loaded on Ubuntu with jre9-b150
> > 20. JDK-8171928: Build fails on Oracle Linux 7 with unused parameter
> warning
> >
> > I have tested it on all three platforms (Windows 10, Linux (Ubuntu 18.4
> LTS, Ubuntu 16.04 LTS) and and Mac) and no new test failures are found. I
> have tested the "HelloWebView" and "Ensemble" and I don't see any issue. I
> did some sanity testing on OL 7.5 as well and things look good to me.
> >
> > Webrev:
> > http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.01/
> >
> > Regards,
> > Pankaj
> >
> >
> > -----Original Message-----
> > From: Kevin Rushforth
> > Sent: Thursday, October 4, 2018 7:41 AM
> > To: Pankaj Bansal; openjfx-dev at openjdk.java.net
> > Subject: Re: [8u-backport] JDK-8087516 : [JavaFX] Conditional support
> for GTK 3 on Linux
> >
> > I debugged this offline earlier today, and it looks related to a
> collision in the glib library. As I mentioned offline, a possible solution
> is to remove RTLD_GLOBAL from the dlopen of the libglassgtk{2,3}.so
> library. I was able to do a full build / test on both GTK 2 and GTK 3
> including media and webkit with that modification.
> >
> > Overall, this is looking quite good.
> >
> > One more thing: the patch adds several new tests, so you will need to
> run at least the new tests on all three platforms (a quick check on Mac
> shows a couple failures).
> >
> > I also see a couple differences between jfx-dev and 8u-dev in the native
> code that should be looked into to make sure there wasn't a missed fix on
> the backport (the Hi-DPI diffs are expected, but I see a couple others).
> >
> > -- Kevin
> >
> >
> > On 10/3/2018 10:16 AM, Kevin Rushforth wrote:
> >> My initial testing shows a couple problems which will need to be
> >> resolved:
> >>
> >> 1) I get many GTK warnings relating to Pango when running HelloWebView
> >> 2) Running any program that uses media crashes
> >>
> >> This is on Ubuntu 16.04 LTS using the default GTK 2 mode.
> >>
> >> -- Kevin
> >>
> >>
> >> On 10/3/2018 3:26 AM, Pankaj Bansal wrote:
> >>> Hi All,
> >>>
> >>> Please review the patch for 8u-dev backport for JDK-8087516
> >>> <https://bugs.openjdk.java.net/browse/JDK-8087516>. It adds
> >>> conditional support for gtk3.
> >>>
> >>> Along with the enhancement, following bug fixes have also been
> >>> included in the backport webrev
> >>>
> >>> 1.https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] invalid
> >>> rendering of FX app stage in case of scaling
> >>>
> >>> 2.https://bugs.openjdk.java.net/browse/JDK-8163496: Rework Glass GTK
> >>> to correct gtk3 structure sizes
> >>>
> >>> 3.https://bugs.openjdk.java.net/browse/JDK-8145837: Remove deprecated
> >>> GTK2 calls in JavaFX
> >>>
> >>> 4.https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to newer
> >>> version of SWT for build/test
> >>>
> >>> 5.https://bugs.openjdk.java.net/browse/JDK-8171330: Issues with
> >>> transparent stage and GTK
> >>>
> >>> 6.https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: JavaFX
> >>> window not painted with background when using GTK 3
> >>>
> >>> 7.https://bugs.openjdk.java.net/browse/JDK-8166414: Scene returns
> >>> incorrect coordinates
> >>>
> >>> 8.https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04:
> >>> expandable content goes outside of the alert dialog
> >>>
> >>> 9.https://bugs.openjdk.java.net/browse/JDK-8152421: After initing the
> >>> modality of a non-primary stage to MODAL, closing that stage causes
> >>> the primary stage to become non-resizable
> >>>
> >>> 10.https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux]
> >>> Restoring owner stage after minimize does not restore position of
> >>> child stage
> >>>
> >>> 11.https://bugs.openjdk.java.net/browse/JDK-8173901: Linux: Position
> >>> of Stage is not restored after exiting full screen
> >>>
> >>> 12.https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: Dialog
> >>> windows come up 1-pixel wide
> >>>
> >>> 13.https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: Stage
> >>> initially in full-screen mode not shown when exiting full-screen
> >>>
> >>> 14.https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown
> >>> position regression and not painting correctly tooltips regression
> >>>
> >>> 15.https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not always
> >>> selected properly with GTK 3
> >>>
> >>> 16.https://bugs.openjdk.java.net/browse/JDK-8172219: Allow compiling
> >>> without GTK 3.0 being installed
> >>>
> >>> 17.https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk
> >>> version if SWT used via FXCanvas
> >>>
> >>> 18.https://bugs.openjdk.java.net/browse/JDK-8156491: Autodetect GTK
> >>> version for JFX
> >>>
> >>> The original gtk3 backport patch applied cleanly, but the bugs did
> >>> not apply cleanly. So a review is required.
> >>>
> >>> I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu 16.04
> >>> LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux 7.5.
> >>>
> >>> webrev:
> >>> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/
> >>>
> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8087516
> >>>
> >>> JDK 9 Changeset:
> >>> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
> >>>
> >>> Regards,
> >>>
> >>> Pankaj
> >>>
>
>

From johan.vos at gluonhq.com  Thu Oct 11 10:35:02 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 11 Oct 2018 12:35:02 +0200
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK
 3 on Linux
In-Reply-To: <6f235abc-5ccb-4bed-b3ea-63fe9e5db546@default>
References: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
 <83da2996-f6a9-ac90-65f5-25679c1a0d4c@oracle.com>
 <8f955a90-7e21-9369-6b8d-bce84c36dfd4@oracle.com>
 <6f235abc-5ccb-4bed-b3ea-63fe9e5db546@default>
Message-ID: <CABxFH2EtaECwdyGx3MrHrSx_TxfZuuSd5VwQC6BSqO781Y2u_A@mail.gmail.com>

Hi Pankaj,

What gcc version did you use to build on Ubuntu 18.04? Default, I think gcc
7.3 is used in 18.04 and that has the issue with wait() in
modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp
(which was later replaced with
wait(&status);
)

This is blocking me to build 8u-dev on Ubuntu 18.04.
On Ubuntu 16.04, there are no issues and it works fine there.

- Johan

On Wed, Oct 10, 2018 at 5:10 PM Pankaj Bansal <pankaj.b.bansal at oracle.com>
wrote:

> Hi Kevin,
>
> Thanks for review and the information provided.
>
> I have updated the webrev for the proposed change from RTLD_GLOBAL to
> RTLD_LOCAL in launcher.c. Along with the this change, the new patch also
> includes the backport of two more fixes mentioned below. So now we have
> backported total of 20 bugs.
>
> 19. JDK-8171985: Fx applet fails to get loaded on Ubuntu with jre9-b150
> 20. JDK-8171928: Build fails on Oracle Linux 7 with unused parameter
> warning
>
> I have tested it on all three platforms (Windows 10, Linux (Ubuntu 18.4
> LTS, Ubuntu 16.04 LTS) and and Mac) and no new test failures are found. I
> have tested the "HelloWebView" and "Ensemble" and I don't see any issue. I
> did some sanity testing on OL 7.5 as well and things look good to me.
>
> Webrev:
> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.01/
>
> Regards,
> Pankaj
>
>
> -----Original Message-----
> From: Kevin Rushforth
> Sent: Thursday, October 4, 2018 7:41 AM
> To: Pankaj Bansal; openjfx-dev at openjdk.java.net
> Subject: Re: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for
> GTK 3 on Linux
>
> I debugged this offline earlier today, and it looks related to a collision
> in the glib library. As I mentioned offline, a possible solution is to
> remove RTLD_GLOBAL from the dlopen of the libglassgtk{2,3}.so library. I
> was able to do a full build / test on both GTK 2 and GTK 3 including media
> and webkit with that modification.
>
> Overall, this is looking quite good.
>
> One more thing: the patch adds several new tests, so you will need to run
> at least the new tests on all three platforms (a quick check on Mac shows a
> couple failures).
>
> I also see a couple differences between jfx-dev and 8u-dev in the native
> code that should be looked into to make sure there wasn't a missed fix on
> the backport (the Hi-DPI diffs are expected, but I see a couple others).
>
> -- Kevin
>
>
> On 10/3/2018 10:16 AM, Kevin Rushforth wrote:
> > My initial testing shows a couple problems which will need to be
> > resolved:
> >
> > 1) I get many GTK warnings relating to Pango when running HelloWebView
> > 2) Running any program that uses media crashes
> >
> > This is on Ubuntu 16.04 LTS using the default GTK 2 mode.
> >
> > -- Kevin
> >
> >
> > On 10/3/2018 3:26 AM, Pankaj Bansal wrote:
> >>
> >> Hi All,
> >>
> >> Please review the patch for 8u-dev backport for JDK-8087516
> >> <https://bugs.openjdk.java.net/browse/JDK-8087516>. It adds
> >> conditional support for gtk3.
> >>
> >> Along with the enhancement, following bug fixes have also been
> >> included in the backport webrev
> >>
> >> 1.https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] invalid
> >> rendering of FX app stage in case of scaling
> >>
> >> 2.https://bugs.openjdk.java.net/browse/JDK-8163496: Rework Glass GTK
> >> to correct gtk3 structure sizes
> >>
> >> 3.https://bugs.openjdk.java.net/browse/JDK-8145837: Remove deprecated
> >> GTK2 calls in JavaFX
> >>
> >> 4.https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to newer
> >> version of SWT for build/test
> >>
> >> 5.https://bugs.openjdk.java.net/browse/JDK-8171330: Issues with
> >> transparent stage and GTK
> >>
> >> 6.https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: JavaFX
> >> window not painted with background when using GTK 3
> >>
> >> 7.https://bugs.openjdk.java.net/browse/JDK-8166414: Scene returns
> >> incorrect coordinates
> >>
> >> 8.https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04:
> >> expandable content goes outside of the alert dialog
> >>
> >> 9.https://bugs.openjdk.java.net/browse/JDK-8152421: After initing the
> >> modality of a non-primary stage to MODAL, closing that stage causes
> >> the primary stage to become non-resizable
> >>
> >> 10.https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux]
> >> Restoring owner stage after minimize does not restore position of
> >> child stage
> >>
> >> 11.https://bugs.openjdk.java.net/browse/JDK-8173901: Linux: Position
> >> of Stage is not restored after exiting full screen
> >>
> >> 12.https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: Dialog
> >> windows come up 1-pixel wide
> >>
> >> 13.https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: Stage
> >> initially in full-screen mode not shown when exiting full-screen
> >>
> >> 14.https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown
> >> position regression and not painting correctly tooltips regression
> >>
> >> 15.https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not always
> >> selected properly with GTK 3
> >>
> >> 16.https://bugs.openjdk.java.net/browse/JDK-8172219: Allow compiling
> >> without GTK 3.0 being installed
> >>
> >> 17.https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk
> >> version if SWT used via FXCanvas
> >>
> >> 18.https://bugs.openjdk.java.net/browse/JDK-8156491: Autodetect GTK
> >> version for JFX
> >>
> >> The original gtk3 backport patch applied cleanly, but the bugs did
> >> not apply cleanly. So a review is required.
> >>
> >> I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu 16.04
> >> LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux 7.5.
> >>
> >> webrev:
> >> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/
> >>
> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8087516
> >>
> >> JDK 9 Changeset:
> >> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
> >>
> >> Regards,
> >>
> >> Pankaj
> >>
> >
>
>

From pankaj.b.bansal at oracle.com  Thu Oct 11 10:47:36 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 11 Oct 2018 10:47:36 +0000 (UTC)
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK
 3 on Linux
In-Reply-To: <CABxFH2EtaECwdyGx3MrHrSx_TxfZuuSd5VwQC6BSqO781Y2u_A@mail.gmail.com>
References: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
 <83da2996-f6a9-ac90-65f5-25679c1a0d4c@oracle.com>
 <8f955a90-7e21-9369-6b8d-bce84c36dfd4@oracle.com>
 <6f235abc-5ccb-4bed-b3ea-63fe9e5db546@default>
 <CABxFH2EtaECwdyGx3MrHrSx_TxfZuuSd5VwQC6BSqO781Y2u_A@mail.gmail.com>
Message-ID: <423bd143-4c8f-4c7a-8fb7-85072dbd3d8e@default>

Hi Johan,

?

Thanks for the review.

?

I used same gcc 7.3 and I was getting the compilation error in fxpackager. I used to build by making these changes locally on 18.04.

?

I discussed this with Kevin about backporting https://bugs.openjdk.java.net/browse/JDK-8189689. This fixes the issue you are facing. But I have been told that we have some Hudson machines where we get the successful build on gcc 7.3 without these changes. So this issue may not be specific to gcc version and we decided not to backport this. Let me talk to Kevin and I will get back to you.

?

Regards,

Pankaj

?

From: Johan Vos [mailto:johan.vos at gluonhq.com] 
Sent: Thursday, October 11, 2018 4:05 PM
To: Pankaj Bansal
Cc: Kevin Rushforth; openjfx-dev at openjdk.java.net
Subject: Re: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK 3 on Linux

?

Hi Pankaj,

?

What gcc version did you use to build on Ubuntu 18.04? Default, I think gcc 7.3 is used in 18.04 and that has the issue with wait() in
modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp

(which was later replaced with

wait(&status);

)

?

This is blocking me to build 8u-dev on Ubuntu 18.04.?

On Ubuntu 16.04, there are no issues and it works fine there.

?

- Johan

?

On Wed, Oct 10, 2018 at 5:10 PM Pankaj Bansal <HYPERLINK "mailto:pankaj.b.bansal at oracle.com"pankaj.b.bansal at oracle.com> wrote:

Hi Kevin,

Thanks for review and the information provided.

I have updated the webrev for the proposed change from RTLD_GLOBAL to RTLD_LOCAL in launcher.c. Along with the this change, the new patch also includes the backport of two more fixes mentioned below. So now we have backported total of 20 bugs. 

19. JDK-8171985: Fx applet fails to get loaded on Ubuntu with jre9-b150
20. JDK-8171928: Build fails on Oracle Linux 7 with unused parameter warning

I have tested it on all three platforms (Windows 10, Linux (Ubuntu 18.4 LTS, Ubuntu 16.04 LTS) and and Mac) and no new test failures are found. I have tested the "HelloWebView" and "Ensemble" and I don't see any issue. I did some sanity testing on OL 7.5 as well and things look good to me.

Webrev:
http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.01/

Regards,
Pankaj


-----Original Message-----
From: Kevin Rushforth 
Sent: Thursday, October 4, 2018 7:41 AM
To: Pankaj Bansal; HYPERLINK "mailto:openjfx-dev at openjdk.java.net"openjfx-dev at openjdk.java.net
Subject: Re: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK 3 on Linux

I debugged this offline earlier today, and it looks related to a collision in the glib library. As I mentioned offline, a possible solution is to remove RTLD_GLOBAL from the dlopen of the libglassgtk{2,3}.so library. I was able to do a full build / test on both GTK 2 and GTK 3 including media and webkit with that modification.

Overall, this is looking quite good.

One more thing: the patch adds several new tests, so you will need to run at least the new tests on all three platforms (a quick check on Mac shows a couple failures).

I also see a couple differences between jfx-dev and 8u-dev in the native code that should be looked into to make sure there wasn't a missed fix on the backport (the Hi-DPI diffs are expected, but I see a couple others).

-- Kevin


On 10/3/2018 10:16 AM, Kevin Rushforth wrote:
> My initial testing shows a couple problems which will need to be
> resolved:
>
> 1) I get many GTK warnings relating to Pango when running HelloWebView
> 2) Running any program that uses media crashes
>
> This is on Ubuntu 16.04 LTS using the default GTK 2 mode.
>
> -- Kevin
>
>
> On 10/3/2018 3:26 AM, Pankaj Bansal wrote:
>>
>> Hi All,
>>
>> Please review the patch for 8u-dev backport for JDK-8087516 
>> <https://bugs.openjdk.java.net/browse/JDK-8087516>. It adds 
>> conditional support for gtk3.
>>
>> Along with the enhancement, following bug fixes have also been 
>> included in the backport webrev
>>
>> 1.https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] invalid 
>> rendering of FX app stage in case of scaling
>>
>> 2.https://bugs.openjdk.java.net/browse/JDK-8163496: Rework Glass GTK 
>> to correct gtk3 structure sizes
>>
>> 3.https://bugs.openjdk.java.net/browse/JDK-8145837: Remove deprecated
>> GTK2 calls in JavaFX
>>
>> 4.https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to newer 
>> version of SWT for build/test
>>
>> 5.https://bugs.openjdk.java.net/browse/JDK-8171330: Issues with 
>> transparent stage and GTK
>>
>> 6.https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: JavaFX 
>> window not painted with background when using GTK 3
>>
>> 7.https://bugs.openjdk.java.net/browse/JDK-8166414: Scene returns 
>> incorrect coordinates
>>
>> 8.https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04: 
>> expandable content goes outside of the alert dialog
>>
>> 9.https://bugs.openjdk.java.net/browse/JDK-8152421: After initing the 
>> modality of a non-primary stage to MODAL, closing that stage causes 
>> the primary stage to become non-resizable
>>
>> 10.https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux] 
>> Restoring owner stage after minimize does not restore position of 
>> child stage
>>
>> 11.https://bugs.openjdk.java.net/browse/JDK-8173901: Linux: Position 
>> of Stage is not restored after exiting full screen
>>
>> 12.https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: Dialog 
>> windows come up 1-pixel wide
>>
>> 13.https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: Stage 
>> initially in full-screen mode not shown when exiting full-screen
>>
>> 14.https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown 
>> position regression and not painting correctly tooltips regression
>>
>> 15.https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not always 
>> selected properly with GTK 3
>>
>> 16.https://bugs.openjdk.java.net/browse/JDK-8172219: Allow compiling 
>> without GTK 3.0 being installed
>>
>> 17.https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk 
>> version if SWT used via FXCanvas
>>
>> 18.https://bugs.openjdk.java.net/browse/JDK-8156491: Autodetect GTK 
>> version for JFX
>>
>> The original gtk3 backport patch applied cleanly, but the bugs did 
>> not apply cleanly. So a review is required.
>>
>> I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu 16.04 
>> LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux 7.5.
>>
>> webrev: 
>> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8087516
>>
>> JDK 9 Changeset: 
>> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
>>
>> Regards,
>>
>> Pankaj
>>
>

From work at norrisfamily.org  Thu Oct 11 11:34:35 2018
From: work at norrisfamily.org (Graham Norris)
Date: Thu, 11 Oct 2018 12:34:35 +0100
Subject: Compiling using javac
In-Reply-To: <HK2PR0301MB20529E7028BDC18FC1AE1BD5E7E00@HK2PR0301MB2052.apcprd03.prod.outlook.com>
References: <20181010092907.322BE102EA@mailuser.nyi.internal>
 <HK2PR0301MB20529E7028BDC18FC1AE1BD5E7E00@HK2PR0301MB2052.apcprd03.prod.outlook.com>
Message-ID: <20181011113436.3FFEF102A0@mailuser.nyi.internal>

** Reply to message from Abhinay Agarwal <abhinay_agarwal at live.com> on Wed, 10
Oct 2018 09:49:06 +0000

Abhinay,

I've found I actually had two problems.

The later one was while trying to get the sample to compile: --module-path will
not tolerate a trailing "\" on the path. It doesn't reject it, it just makes it
not work.

My original problem turned out to be the fact that --module-path in a parm file
requires "/", not "\", even on Windows. Again, not rejected, just doesn't work.

Thanks for your help.

Graham.

> Hi Graham,
> 
> The error "module not found: javafx.controls" can be caused when env variable
> 'PATH_TO_FX' is targeting the 'JavaFX SDK' instead of 'JavaFX SDK/lib' directory
> 
> The following works for me on a Windows machine:
> 
> > set JAVA_HOME="C:\Program Files\Java\jdk-11"
> > set PATH_TO_FX="C:\Program Files\Java\javafx-sdk-11\lib"
> > %JAVA_HOME%\bin\javac --module-path %PATH_TO_FX% --add-modules=javafx.controls HelloFX.java
> > %JAVA_HOME%\bin\java --module-path %PATH_TO_FX% --add-modules=javafx.controls HelloFX
> 
> -- Abhinay
> 
> 
> On Oct 10 2018, at 2:59 pm, Graham Norris <work at norrisfamily.org> wrote:
> 
> ** Reply to message from Abhinay Agarwal <abhinay_agarwal at live.com> on Tue, 9
> Oct 2018 16:30:18 +0000
> 
> No stack trace from either type of failure, just error messages. I've tried
> compiling that example program, with the following result:
> 
> D:\pbmdev>dir HelloFX.java&set PATH_TO_FX&dir %PATH_TO_FX%javafx.*&javac
> --module-path %PATH_TO_FX% --add-modules=javafx.controls HelloFX
> Volume in drive D is DataVolume
> Volume Serial Number is 64B0-54F9
> 
> Directory of D:\pbmdev
> 
> 10/10/2018 10:19 642 HelloFX.java
> 1 File(s) 642 bytes
> 0 Dir(s) 80,740,716,544 bytes free
> PATH_TO_FX="c:\Program Files\Java\JDK-11.028\lib\"
> Volume in drive C is System
> Volume Serial Number is 5EC2-1518
> 
> Directory of c:\Program Files\Java\JDK-11.028\lib
> 
> 13/09/2018 15:57 749,886 javafx.base.jar
> 13/09/2018 15:57 2,511,103 javafx.controls.jar
> 13/09/2018 15:57 127,394 javafx.fxml.jar
> 13/09/2018 15:57 4,292,697 javafx.graphics.jar
> 13/09/2018 15:57 270,594 javafx.media.jar
> 13/09/2018 15:57 71 javafx.properties
> 13/09/2018 15:57 119,848 javafx.swing.jar
> 13/09/2018 15:57 712,651 javafx.web.jar
> 8 File(s) 8,784,244 bytes
> 0 Dir(s) 41,713,242,112 bytes free
> error: no source files
> 
> D:\pbmdev>
> 
> Hi Graham,
> 
> Its really difficult to help without checking out the failing command first.
> 
> Could you reply back with the "javac" command you are trying to execute, along with the stacktrace?
> 
> -- Abhinay
> ________________________________
> From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> on behalf of Graham Norris <work at norrisfamily.org>
> Sent: Tuesday, October 9, 2018 9:39 PM
> To: openjfx-dev at openjdk.java.net
> Subject: Re: Compiling using javac
> 
> ** Reply to message from Michael Paus <mp at jugs.org> on Tue, 9 Oct 2018 15:47:29
> +0200
> 
> Thank you, I'd already found this, but it isn't exactly "documentation." Also,
> it is for Linux (Windows doesn't have export,) but I have put the path directly
> on the --module-path option, which should be equivalent for this.
> 
> Crucially, it does not work: I get "error: module not found: javafx.controls"
> I'm not entirely sure why I'd use javafx.controls as my application does not
> use that, but not finding javafx.controls seems to be unrelated to lack of use,
> which is also borne out by the fact that the compile fails immediately rather
> than churning out dozens of errors as it tries to compile things.
> 
> Graham.
> 
> The documentation you are looking for can be found here:
> https://openjfx.io/openjfx-docs/
> 
> Am 09.10.18 um 15:32 schrieb Graham Norris:
> I have an existing Java application which uses JavaFX. It is currently compiled
> (on Windows) and working using Oracle's Java 10 JDK. I am now trying to get it
> to compile using OpenJDK 11 and OpenJFX 11, and failing miserably!
> 
> I use the JDK's command line tools to compile the application and haven't
> managed to find anything which shows how to make the combination of an existing
> application, OpenJDK 11 and OpenJFX 11 compile. Basically, I can't get javac to
> find and use either OpenJFX's jmods or jars.
> 
> I feel there should be somewhere I could read instructions on how to use
> OpenJFX with OpenJDK 11's javac, but if there is, I just can't find it!
> 
> Any help appreciated.
> 
> Graham.

From kevin.rushforth at oracle.com  Thu Oct 11 15:28:32 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 11 Oct 2018 08:28:32 -0700
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK
 3 on Linux
In-Reply-To: <CABxFH2EtaECwdyGx3MrHrSx_TxfZuuSd5VwQC6BSqO781Y2u_A@mail.gmail.com>
References: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
 <83da2996-f6a9-ac90-65f5-25679c1a0d4c@oracle.com>
 <8f955a90-7e21-9369-6b8d-bce84c36dfd4@oracle.com>
 <6f235abc-5ccb-4bed-b3ea-63fe9e5db546@default>
 <CABxFH2EtaECwdyGx3MrHrSx_TxfZuuSd5VwQC6BSqO781Y2u_A@mail.gmail.com>
Message-ID: <e03029e2-5606-cadd-5ad3-53fe54a8935f@oracle.com>

We use gcc 7.3 (and Oracle Linux 6 / 7) for our Hudson builds of FX 8 
and don't see this problem. Pankaj asked about backporting the fix for 
that JDK-8203884, but I suggested it wasn't needed, since it is 
unrelated to this change.

It sounds like we should backport JDK-8203884, though I prefer it as a 
separate fix not tied to the GTK 3 work.

-- Kevin


On 10/11/2018 3:35 AM, Johan Vos wrote:
> Hi Pankaj,
>
> What gcc version did you use to build on Ubuntu 18.04? Default, I 
> think gcc 7.3 is used in 18.04 and that has the issue with wait() in
> modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp
> (which was later replaced with
> wait(&status);
> )
>
> This is blocking me to build 8u-dev on Ubuntu 18.04.
> On Ubuntu 16.04, there are no issues and it works fine there.
>
> - Johan
>
> On Wed, Oct 10, 2018 at 5:10 PM Pankaj Bansal 
> <pankaj.b.bansal at oracle.com <mailto:pankaj.b.bansal at oracle.com>> wrote:
>
>     Hi Kevin,
>
>     Thanks for review and the information provided.
>
>     I have updated the webrev for the proposed change from RTLD_GLOBAL
>     to RTLD_LOCAL in launcher.c. Along with the this change, the new
>     patch also includes the backport of two more fixes mentioned
>     below. So now we have backported total of 20 bugs.
>
>     19. JDK-8171985: Fx applet fails to get loaded on Ubuntu with
>     jre9-b150
>     20. JDK-8171928: Build fails on Oracle Linux 7 with unused
>     parameter warning
>
>     I have tested it on all three platforms (Windows 10, Linux (Ubuntu
>     18.4 LTS, Ubuntu 16.04 LTS) and and Mac) and no new test failures
>     are found. I have tested the "HelloWebView" and "Ensemble" and I
>     don't see any issue. I did some sanity testing on OL 7.5 as well
>     and things look good to me.
>
>     Webrev:
>     http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.01/
>     <http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.01/>
>
>     Regards,
>     Pankaj
>
>
>     -----Original Message-----
>     From: Kevin Rushforth
>     Sent: Thursday, October 4, 2018 7:41 AM
>     To: Pankaj Bansal; openjfx-dev at openjdk.java.net
>     <mailto:openjfx-dev at openjdk.java.net>
>     Subject: Re: [8u-backport] JDK-8087516 : [JavaFX] Conditional
>     support for GTK 3 on Linux
>
>     I debugged this offline earlier today, and it looks related to a
>     collision in the glib library. As I mentioned offline, a possible
>     solution is to remove RTLD_GLOBAL from the dlopen of the
>     libglassgtk{2,3}.so library. I was able to do a full build / test
>     on both GTK 2 and GTK 3 including media and webkit with that
>     modification.
>
>     Overall, this is looking quite good.
>
>     One more thing: the patch adds several new tests, so you will need
>     to run at least the new tests on all three platforms (a quick
>     check on Mac shows a couple failures).
>
>     I also see a couple differences between jfx-dev and 8u-dev in the
>     native code that should be looked into to make sure there wasn't a
>     missed fix on the backport (the Hi-DPI diffs are expected, but I
>     see a couple others).
>
>     -- Kevin
>
>
>     On 10/3/2018 10:16 AM, Kevin Rushforth wrote:
>     > My initial testing shows a couple problems which will need to be
>     > resolved:
>     >
>     > 1) I get many GTK warnings relating to Pango when running
>     HelloWebView
>     > 2) Running any program that uses media crashes
>     >
>     > This is on Ubuntu 16.04 LTS using the default GTK 2 mode.
>     >
>     > -- Kevin
>     >
>     >
>     > On 10/3/2018 3:26 AM, Pankaj Bansal wrote:
>     >>
>     >> Hi All,
>     >>
>     >> Please review the patch for 8u-dev backport for JDK-8087516
>     >> <https://bugs.openjdk.java.net/browse/JDK-8087516>. It adds
>     >> conditional support for gtk3.
>     >>
>     >> Along with the enhancement, following bug fixes have also been
>     >> included in the backport webrev
>     >>
>     >> 1.https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] invalid
>     >> rendering of FX app stage in case of scaling
>     >>
>     >> 2.https://bugs.openjdk.java.net/browse/JDK-8163496: Rework
>     Glass GTK
>     >> to correct gtk3 structure sizes
>     >>
>     >> 3.https://bugs.openjdk.java.net/browse/JDK-8145837: Remove
>     deprecated
>     >> GTK2 calls in JavaFX
>     >>
>     >> 4.https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to
>     newer
>     >> version of SWT for build/test
>     >>
>     >> 5.https://bugs.openjdk.java.net/browse/JDK-8171330: Issues with
>     >> transparent stage and GTK
>     >>
>     >> 6.https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: JavaFX
>     >> window not painted with background when using GTK 3
>     >>
>     >> 7.https://bugs.openjdk.java.net/browse/JDK-8166414: Scene returns
>     >> incorrect coordinates
>     >>
>     >> 8.https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04:
>     >> expandable content goes outside of the alert dialog
>     >>
>     >> 9.https://bugs.openjdk.java.net/browse/JDK-8152421: After
>     initing the
>     >> modality of a non-primary stage to MODAL, closing that stage
>     causes
>     >> the primary stage to become non-resizable
>     >>
>     >> 10.https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux]
>     >> Restoring owner stage after minimize does not restore position of
>     >> child stage
>     >>
>     >> 11.https://bugs.openjdk.java.net/browse/JDK-8173901: Linux:
>     Position
>     >> of Stage is not restored after exiting full screen
>     >>
>     >> 12.https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: Dialog
>     >> windows come up 1-pixel wide
>     >>
>     >> 13.https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: Stage
>     >> initially in full-screen mode not shown when exiting full-screen
>     >>
>     >> 14.https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown
>     >> position regression and not painting correctly tooltips regression
>     >>
>     >> 15.https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not
>     always
>     >> selected properly with GTK 3
>     >>
>     >> 16.https://bugs.openjdk.java.net/browse/JDK-8172219: Allow
>     compiling
>     >> without GTK 3.0 being installed
>     >>
>     >> 17.https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk
>     >> version if SWT used via FXCanvas
>     >>
>     >> 18.https://bugs.openjdk.java.net/browse/JDK-8156491: Autodetect
>     GTK
>     >> version for JFX
>     >>
>     >> The original gtk3 backport patch applied cleanly, but the bugs did
>     >> not apply cleanly. So a review is required.
>     >>
>     >> I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu 16.04
>     >> LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux 7.5.
>     >>
>     >> webrev:
>     >>
>     http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/
>     <http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.00/>
>     >>
>     >> JBS: https://bugs.openjdk.java.net/browse/JDK-8087516
>     >>
>     >> JDK 9 Changeset:
>     >> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
>     >>
>     >> Regards,
>     >>
>     >> Pankaj
>     >>
>     >
>


From kevin.rushforth at oracle.com  Thu Oct 11 15:47:29 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 11 Oct 2018 08:47:29 -0700
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK
 3 on Linux
In-Reply-To: <e03029e2-5606-cadd-5ad3-53fe54a8935f@oracle.com>
References: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
 <83da2996-f6a9-ac90-65f5-25679c1a0d4c@oracle.com>
 <8f955a90-7e21-9369-6b8d-bce84c36dfd4@oracle.com>
 <6f235abc-5ccb-4bed-b3ea-63fe9e5db546@default>
 <CABxFH2EtaECwdyGx3MrHrSx_TxfZuuSd5VwQC6BSqO781Y2u_A@mail.gmail.com>
 <e03029e2-5606-cadd-5ad3-53fe54a8935f@oracle.com>
Message-ID: <be1b5537-6178-6910-87b4-cecabe7a92eb@oracle.com>

I used the wrong bug ID below. Here is the right one:

8189689: JavaFX build fails with gcc 6 [1]

Pankaj will send a backport request for this tomorrow. We should get 
this one in ASAP since 8u-dev is unable to compile on Ubuntu 18.04 today.

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8189689


On 10/11/2018 8:28 AM, Kevin Rushforth wrote:
> We use gcc 7.3 (and Oracle Linux 6 / 7) for our Hudson builds of FX 8 
> and don't see this problem. Pankaj asked about backporting the fix for 
> that JDK-8203884, but I suggested it wasn't needed, since it is 
> unrelated to this change.
>
> It sounds like we should backport JDK-8203884, though I prefer it as a 
> separate fix not tied to the GTK 3 work.
>
> -- Kevin
>
>
> On 10/11/2018 3:35 AM, Johan Vos wrote:
>> Hi Pankaj,
>>
>> What gcc version did you use to build on Ubuntu 18.04? Default, I 
>> think gcc 7.3 is used in 18.04 and that has the issue with wait() in
>> modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp
>> (which was later replaced with
>> wait(&status);
>> )
>>
>> This is blocking me to build 8u-dev on Ubuntu 18.04.
>> On Ubuntu 16.04, there are no issues and it works fine there.
>>
>> - Johan
>>
>> On Wed, Oct 10, 2018 at 5:10 PM Pankaj Bansal 
>> <pankaj.b.bansal at oracle.com <mailto:pankaj.b.bansal at oracle.com>> wrote:
>>
>> ??? Hi Kevin,
>>
>> ??? Thanks for review and the information provided.
>>
>> ??? I have updated the webrev for the proposed change from RTLD_GLOBAL
>> ??? to RTLD_LOCAL in launcher.c. Along with the this change, the new
>> ??? patch also includes the backport of two more fixes mentioned
>> ??? below. So now we have backported total of 20 bugs.
>>
>> ??? 19. JDK-8171985: Fx applet fails to get loaded on Ubuntu with
>> ??? jre9-b150
>> ??? 20. JDK-8171928: Build fails on Oracle Linux 7 with unused
>> ??? parameter warning
>>
>> ??? I have tested it on all three platforms (Windows 10, Linux (Ubuntu
>> ??? 18.4 LTS, Ubuntu 16.04 LTS) and and Mac) and no new test failures
>> ??? are found. I have tested the "HelloWebView" and "Ensemble" and I
>> ??? don't see any issue. I did some sanity testing on OL 7.5 as well
>> ??? and things look good to me.
>>
>> ??? Webrev:
>> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.01/
>> <http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.01/>
>>
>> ??? Regards,
>> ??? Pankaj
>>
>>
>> ??? -----Original Message-----
>> ??? From: Kevin Rushforth
>> ??? Sent: Thursday, October 4, 2018 7:41 AM
>> ??? To: Pankaj Bansal; openjfx-dev at openjdk.java.net
>> ??? <mailto:openjfx-dev at openjdk.java.net>
>> ??? Subject: Re: [8u-backport] JDK-8087516 : [JavaFX] Conditional
>> ??? support for GTK 3 on Linux
>>
>> ??? I debugged this offline earlier today, and it looks related to a
>> ??? collision in the glib library. As I mentioned offline, a possible
>> ??? solution is to remove RTLD_GLOBAL from the dlopen of the
>> ??? libglassgtk{2,3}.so library. I was able to do a full build / test
>> ??? on both GTK 2 and GTK 3 including media and webkit with that
>> ??? modification.
>>
>> ??? Overall, this is looking quite good.
>>
>> ??? One more thing: the patch adds several new tests, so you will need
>> ??? to run at least the new tests on all three platforms (a quick
>> ??? check on Mac shows a couple failures).
>>
>> ??? I also see a couple differences between jfx-dev and 8u-dev in the
>> ??? native code that should be looked into to make sure there wasn't a
>> ??? missed fix on the backport (the Hi-DPI diffs are expected, but I
>> ??? see a couple others).
>>
>> ??? -- Kevin
>>
>>
>> ??? On 10/3/2018 10:16 AM, Kevin Rushforth wrote:
>> ??? > My initial testing shows a couple problems which will need to be
>> ??? > resolved:
>> ??? >
>> ??? > 1) I get many GTK warnings relating to Pango when running
>> ??? HelloWebView
>> ??? > 2) Running any program that uses media crashes
>> ??? >
>> ??? > This is on Ubuntu 16.04 LTS using the default GTK 2 mode.
>> ??? >
>> ??? > -- Kevin
>> ??? >
>> ??? >
>> ??? > On 10/3/2018 3:26 AM, Pankaj Bansal wrote:
>> ??? >>
>> ??? >> Hi All,
>> ??? >>
>> ??? >> Please review the patch for 8u-dev backport for JDK-8087516
>> ??? >> <https://bugs.openjdk.java.net/browse/JDK-8087516>. It adds
>> ??? >> conditional support for gtk3.
>> ??? >>
>> ??? >> Along with the enhancement, following bug fixes have also been
>> ??? >> included in the backport webrev
>> ??? >>
>> ??? >> 1.https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] 
>> invalid
>> ??? >> rendering of FX app stage in case of scaling
>> ??? >>
>> ??? >> 2.https://bugs.openjdk.java.net/browse/JDK-8163496: Rework
>> ??? Glass GTK
>> ??? >> to correct gtk3 structure sizes
>> ??? >>
>> ??? >> 3.https://bugs.openjdk.java.net/browse/JDK-8145837: Remove
>> ??? deprecated
>> ??? >> GTK2 calls in JavaFX
>> ??? >>
>> ??? >> 4.https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to
>> ??? newer
>> ??? >> version of SWT for build/test
>> ??? >>
>> ??? >> 5.https://bugs.openjdk.java.net/browse/JDK-8171330: Issues with
>> ??? >> transparent stage and GTK
>> ??? >>
>> ??? >> 6.https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: JavaFX
>> ??? >> window not painted with background when using GTK 3
>> ??? >>
>> ??? >> 7.https://bugs.openjdk.java.net/browse/JDK-8166414: Scene returns
>> ??? >> incorrect coordinates
>> ??? >>
>> ??? >> 8.https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04:
>> ??? >> expandable content goes outside of the alert dialog
>> ??? >>
>> ??? >> 9.https://bugs.openjdk.java.net/browse/JDK-8152421: After
>> ??? initing the
>> ??? >> modality of a non-primary stage to MODAL, closing that stage
>> ??? causes
>> ??? >> the primary stage to become non-resizable
>> ??? >>
>> ??? >> 10.https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux]
>> ??? >> Restoring owner stage after minimize does not restore position of
>> ??? >> child stage
>> ??? >>
>> ??? >> 11.https://bugs.openjdk.java.net/browse/JDK-8173901: Linux:
>> ??? Position
>> ??? >> of Stage is not restored after exiting full screen
>> ??? >>
>> ??? >> 12.https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: 
>> Dialog
>> ??? >> windows come up 1-pixel wide
>> ??? >>
>> ??? >> 13.https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: Stage
>> ??? >> initially in full-screen mode not shown when exiting full-screen
>> ??? >>
>> ??? >> 14.https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown
>> ??? >> position regression and not painting correctly tooltips 
>> regression
>> ??? >>
>> ??? >> 15.https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not
>> ??? always
>> ??? >> selected properly with GTK 3
>> ??? >>
>> ??? >> 16.https://bugs.openjdk.java.net/browse/JDK-8172219: Allow
>> ??? compiling
>> ??? >> without GTK 3.0 being installed
>> ??? >>
>> ??? >> 17.https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk
>> ??? >> version if SWT used via FXCanvas
>> ??? >>
>> ??? >> 18.https://bugs.openjdk.java.net/browse/JDK-8156491: Autodetect
>> ??? GTK
>> ??? >> version for JFX
>> ??? >>
>> ??? >> The original gtk3 backport patch applied cleanly, but the bugs 
>> did
>> ??? >> not apply cleanly. So a review is required.
>> ??? >>
>> ??? >> I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu 
>> 16.04
>> ??? >> LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux 
>> 7.5.
>> ??? >>
>> ??? >> webrev:
>> ??? >>
>> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/
>> <http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.00/>
>> ??? >>
>> ??? >> JBS: https://bugs.openjdk.java.net/browse/JDK-8087516
>> ??? >>
>> ??? >> JDK 9 Changeset:
>> ??? >> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
>> ??? >>
>> ??? >> Regards,
>> ??? >>
>> ??? >> Pankaj
>> ??? >>
>> ??? >
>>
>


From thiago.sayao at clamed.com.br  Thu Oct 11 17:03:00 2018
From: thiago.sayao at clamed.com.br (Thiago Milczarek =?ISO-8859-1?Q?Say=E3o?=)
Date: Thu, 11 Oct 2018 14:03:00 -0300
Subject: Window opening glitch on ubuntu 18.04
Message-ID: <ca3aef82d8bca1af398043ecd11890447529035d.camel@clamed.com.br>


I have migrated our development environment from java-10 javafx to
java-11 and openjfx-11.

One thing I have noticed is that windows opens on the top left corner
of the screen and than moves to a center location. The weird thing is
that we can see the window moving. It appears to be a glitch.

This also happened on java-10 with the bundled javafx when setting it
to use gtk-3 instead of gtk-2.

So it appears to be a gtk-3 bug/glitch.

We use x.org (not wayland).




From kevin.rushforth at oracle.com  Thu Oct 11 17:10:20 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 11 Oct 2018 10:10:20 -0700
Subject: Window opening glitch on ubuntu 18.04
In-Reply-To: <ca3aef82d8bca1af398043ecd11890447529035d.camel@clamed.com.br>
References: <ca3aef82d8bca1af398043ecd11890447529035d.camel@clamed.com.br>
Message-ID: <9157da23-ee5d-a4eb-0600-5dde4deaca90@oracle.com>

Someone reported a similar issue with a differrent Linux distro (Manjaro 
17.1.12) also related to GTK 3:

https://github.com/javafxports/openjdk-jfx/issues/217

I'll file a JBS bug for this. In the mean time, you can add a comment to 
the above GitHub issue if you like.

-- Kevin


On 10/11/2018 10:03 AM, Thiago Milczarek Say?o wrote:
> I have migrated our development environment from java-10 javafx to
> java-11 and openjfx-11.
>
> One thing I have noticed is that windows opens on the top left corner
> of the screen and than moves to a center location. The weird thing is
> that we can see the window moving. It appears to be a glitch.
>
> This also happened on java-10 with the bundled javafx when setting it
> to use gtk-3 instead of gtk-2.
>
> So it appears to be a gtk-3 bug/glitch.
>
> We use x.org (not wayland).
>
>
>


From kevin.rushforth at oracle.com  Thu Oct 11 17:16:47 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 11 Oct 2018 10:16:47 -0700
Subject: Window opening glitch on ubuntu 18.04
In-Reply-To: <9157da23-ee5d-a4eb-0600-5dde4deaca90@oracle.com>
References: <ca3aef82d8bca1af398043ecd11890447529035d.camel@clamed.com.br>
 <9157da23-ee5d-a4eb-0600-5dde4deaca90@oracle.com>
Message-ID: <bea3cb40-5d1e-6814-f550-42d766adbf2e@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8212060


On 10/11/2018 10:10 AM, Kevin Rushforth wrote:
> Someone reported a similar issue with a differrent Linux distro 
> (Manjaro 17.1.12) also related to GTK 3:
>
> https://github.com/javafxports/openjdk-jfx/issues/217
>
> I'll file a JBS bug for this. In the mean time, you can add a comment 
> to the above GitHub issue if you like.
>
> -- Kevin
>
>
> On 10/11/2018 10:03 AM, Thiago Milczarek Say?o wrote:
>> I have migrated our development environment from java-10 javafx to
>> java-11 and openjfx-11.
>>
>> One thing I have noticed is that windows opens on the top left corner
>> of the screen and than moves to a center location. The weird thing is
>> that we can see the window moving. It appears to be a glitch.
>>
>> This also happened on java-10 with the bundled javafx when setting it
>> to use gtk-3 instead of gtk-2.
>>
>> So it appears to be a gtk-3 bug/glitch.
>>
>> We use x.org (not wayland).
>>
>>
>>
>


From kevin.rushforth at oracle.com  Thu Oct 11 17:23:16 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 11 Oct 2018 10:23:16 -0700
Subject: Window opening glitch on ubuntu 18.04
In-Reply-To: <bea3cb40-5d1e-6814-f550-42d766adbf2e@oracle.com>
References: <ca3aef82d8bca1af398043ecd11890447529035d.camel@clamed.com.br>
 <9157da23-ee5d-a4eb-0600-5dde4deaca90@oracle.com>
 <bea3cb40-5d1e-6814-f550-42d766adbf2e@oracle.com>
Message-ID: <3e9c88db-5d1e-2ad1-c06c-99e3b45684f0@oracle.com>

And this was reported even earlier at:

https://github.com/javafxports/openjdk-jfx/issues/129

also with Ubuntu 18.04. I have added a pointer to both in the JBS bug.

-- Kevin


On 10/11/2018 10:16 AM, Kevin Rushforth wrote:
> https://bugs.openjdk.java.net/browse/JDK-8212060
>
>
> On 10/11/2018 10:10 AM, Kevin Rushforth wrote:
>> Someone reported a similar issue with a differrent Linux distro 
>> (Manjaro 17.1.12) also related to GTK 3:
>>
>> https://github.com/javafxports/openjdk-jfx/issues/217
>>
>> I'll file a JBS bug for this. In the mean time, you can add a comment 
>> to the above GitHub issue if you like.
>>
>> -- Kevin
>>
>>
>> On 10/11/2018 10:03 AM, Thiago Milczarek Say?o wrote:
>>> I have migrated our development environment from java-10 javafx to
>>> java-11 and openjfx-11.
>>>
>>> One thing I have noticed is that windows opens on the top left corner
>>> of the screen and than moves to a center location. The weird thing is
>>> that we can see the window moving. It appears to be a glitch.
>>>
>>> This also happened on java-10 with the bundled javafx when setting it
>>> to use gtk-3 instead of gtk-2.
>>>
>>> So it appears to be a gtk-3 bug/glitch.
>>>
>>> We use x.org (not wayland).
>>>
>>>
>>>
>>
>


From sverre.moe at gmail.com  Thu Oct 11 17:32:02 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Thu, 11 Oct 2018 19:32:02 +0200
Subject: Window opening glitch on ubuntu 18.04
In-Reply-To: <bea3cb40-5d1e-6814-f550-42d766adbf2e@oracle.com>
References: <ca3aef82d8bca1af398043ecd11890447529035d.camel@clamed.com.br>
 <9157da23-ee5d-a4eb-0600-5dde4deaca90@oracle.com>
 <bea3cb40-5d1e-6814-f550-42d766adbf2e@oracle.com>
Message-ID: <CALAJ+5ALpmmBC_3wcpnhshGoR3Z6xqLxOoN+M6n_2=nm_cY06w@mail.gmail.com>

Den tor. 11. okt. 2018 kl. 19:17 skrev Kevin Rushforth <
kevin.rushforth at oracle.com>:

> https://bugs.openjdk.java.net/browse/JDK-8212060
>
>
I have not noticed this on OpenSUSE Leap 15. The window pop up right in the
center of my screen in an instant.
NVIDIA graphics with NVIDIA proprietary drivers.

Running my modular test application on Java 11 and JavaFX 11.
https://github.com/DJViking/FxMovies.git

/Sverre

From sverre.moe at gmail.com  Thu Oct 11 17:38:18 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Thu, 11 Oct 2018 19:38:18 +0200
Subject: Window opening glitch on ubuntu 18.04
In-Reply-To: <CALAJ+5ALpmmBC_3wcpnhshGoR3Z6xqLxOoN+M6n_2=nm_cY06w@mail.gmail.com>
References: <ca3aef82d8bca1af398043ecd11890447529035d.camel@clamed.com.br>
 <9157da23-ee5d-a4eb-0600-5dde4deaca90@oracle.com>
 <bea3cb40-5d1e-6814-f550-42d766adbf2e@oracle.com>
 <CALAJ+5ALpmmBC_3wcpnhshGoR3Z6xqLxOoN+M6n_2=nm_cY06w@mail.gmail.com>
Message-ID: <CALAJ+5BgrSBdLgAD4EOvg=v8-eq-UApz6S5bGY8bXocHMWMs1A@mail.gmail.com>

Den tor. 11. okt. 2018 kl. 19:32 skrev Sverre Moe <sverre.moe at gmail.com>:

> Den tor. 11. okt. 2018 kl. 19:17 skrev Kevin Rushforth <
> kevin.rushforth at oracle.com>:
>
>> https://bugs.openjdk.java.net/browse/JDK-8212060
>>
>>
> I have not noticed this on OpenSUSE Leap 15. The window pop up right in
> the center of my screen in an instant.
> NVIDIA graphics with NVIDIA proprietary drivers.
>
> Running my modular test application on Java 11 and JavaFX 11.
> https://github.com/DJViking/FxMovies.git
>
> /Sverre
>
>
I did however noticed for a split second that a dialog I opened was in the
upper left corner. It was hardly noticeable.

/Sverre

From pankaj.b.bansal at oracle.com  Thu Oct 11 19:53:23 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Thu, 11 Oct 2018 19:53:23 +0000 (UTC)
Subject: [RFR][8u-dev] : JDK-8189689 : JavaFX build fails with gcc 6
Message-ID: <f86e0e4e-3e79-4c26-8340-c8bde38facbf@default>

Hi Kevin, 

 

Please review the backport fix for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8189689"JDK-8189689.

Webrev: http://cr.openjdk.java.net/~pbansal/8189689/webrev.00/

 

 

Thanks,

Pankaj

 

From kevin.rushforth at oracle.com  Fri Oct 12 02:45:13 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 11 Oct 2018 19:45:13 -0700
Subject: [RFR][8u-dev] : JDK-8189689 : JavaFX build fails with gcc 6
In-Reply-To: <f86e0e4e-3e79-4c26-8340-c8bde38facbf@default>
References: <f86e0e4e-3e79-4c26-8340-c8bde38facbf@default>
Message-ID: <e09ac974-f068-cb7e-c38e-c2493e87047b@oracle.com>

Looks good.

+1

I'll push it tomorrow morning my time.

-- Kevin


On 10/11/2018 12:53 PM, Pankaj Bansal wrote:
>
> Hi Kevin,
>
> Please review the backport fix for JDK-8189689 
> <https://bugs.openjdk.java.net/browse/JDK-8189689>.
>
> Webrev: http://cr.openjdk.java.net/~pbansal/8189689/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epbansal/8189689/webrev.00/>
>
> Thanks,
>
> Pankaj
>


From pankaj.b.bansal at oracle.com  Fri Oct 12 09:25:47 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Fri, 12 Oct 2018 09:25:47 +0000 (UTC)
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK
 3 on Linux
In-Reply-To: <be1b5537-6178-6910-87b4-cecabe7a92eb@oracle.com>
References: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
 <83da2996-f6a9-ac90-65f5-25679c1a0d4c@oracle.com>
 <8f955a90-7e21-9369-6b8d-bce84c36dfd4@oracle.com>
 <6f235abc-5ccb-4bed-b3ea-63fe9e5db546@default>
 <CABxFH2EtaECwdyGx3MrHrSx_TxfZuuSd5VwQC6BSqO781Y2u_A@mail.gmail.com>
 <e03029e2-5606-cadd-5ad3-53fe54a8935f@oracle.com>
 <be1b5537-6178-6910-87b4-cecabe7a92eb@oracle.com>
Message-ID: <ef04f0f8-5866-498c-85e6-c2d9adb8ae1d@default>

Hello Johan,

We have backported https://bugs.openjdk.java.net/browse/JDK-8189689 in 8u-dev under https://bugs.openjdk.java.net/browse/JDK-8212106. 

Can you please try now to build on 18.04 LTS ? It should pass.

Regards,
Pankaj

-----Original Message-----
From: Kevin Rushforth 
Sent: Thursday, October 11, 2018 9:17 PM
To: Johan Vos; Pankaj Bansal
Cc: openjfx-dev at openjdk.java.net
Subject: Re: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK 3 on Linux

I used the wrong bug ID below. Here is the right one:

8189689: JavaFX build fails with gcc 6 [1]

Pankaj will send a backport request for this tomorrow. We should get this one in ASAP since 8u-dev is unable to compile on Ubuntu 18.04 today.

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8189689


On 10/11/2018 8:28 AM, Kevin Rushforth wrote:
> We use gcc 7.3 (and Oracle Linux 6 / 7) for our Hudson builds of FX 8 
> and don't see this problem. Pankaj asked about backporting the fix for 
> that JDK-8203884, but I suggested it wasn't needed, since it is 
> unrelated to this change.
>
> It sounds like we should backport JDK-8203884, though I prefer it as a 
> separate fix not tied to the GTK 3 work.
>
> -- Kevin
>
>
> On 10/11/2018 3:35 AM, Johan Vos wrote:
>> Hi Pankaj,
>>
>> What gcc version did you use to build on Ubuntu 18.04? Default, I 
>> think gcc 7.3 is used in 18.04 and that has the issue with wait() in 
>> modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp
>> (which was later replaced with
>> wait(&status);
>> )
>>
>> This is blocking me to build 8u-dev on Ubuntu 18.04.
>> On Ubuntu 16.04, there are no issues and it works fine there.
>>
>> - Johan
>>
>> On Wed, Oct 10, 2018 at 5:10 PM Pankaj Bansal 
>> <pankaj.b.bansal at oracle.com <mailto:pankaj.b.bansal at oracle.com>> wrote:
>>
>> ??? Hi Kevin,
>>
>> ??? Thanks for review and the information provided.
>>
>> ??? I have updated the webrev for the proposed change from 
>> RTLD_GLOBAL
>> ??? to RTLD_LOCAL in launcher.c. Along with the this change, the new
>> ??? patch also includes the backport of two more fixes mentioned
>> ??? below. So now we have backported total of 20 bugs.
>>
>> ??? 19. JDK-8171985: Fx applet fails to get loaded on Ubuntu with
>> ??? jre9-b150
>> ??? 20. JDK-8171928: Build fails on Oracle Linux 7 with unused
>> ??? parameter warning
>>
>> ??? I have tested it on all three platforms (Windows 10, Linux 
>> (Ubuntu
>> ??? 18.4 LTS, Ubuntu 16.04 LTS) and and Mac) and no new test failures
>> ??? are found. I have tested the "HelloWebView" and "Ensemble" and I
>> ??? don't see any issue. I did some sanity testing on OL 7.5 as well
>> ??? and things look good to me.
>>
>> ??? Webrev:
>> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.01/
>> <http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.01/>
>>
>> ??? Regards,
>> ??? Pankaj
>>
>>
>> ??? -----Original Message-----
>> ??? From: Kevin Rushforth
>> ??? Sent: Thursday, October 4, 2018 7:41 AM
>> ??? To: Pankaj Bansal; openjfx-dev at openjdk.java.net
>> ??? <mailto:openjfx-dev at openjdk.java.net>
>> ??? Subject: Re: [8u-backport] JDK-8087516 : [JavaFX] Conditional
>> ??? support for GTK 3 on Linux
>>
>> ??? I debugged this offline earlier today, and it looks related to a
>> ??? collision in the glib library. As I mentioned offline, a possible
>> ??? solution is to remove RTLD_GLOBAL from the dlopen of the
>> ??? libglassgtk{2,3}.so library. I was able to do a full build / test
>> ??? on both GTK 2 and GTK 3 including media and webkit with that
>> ??? modification.
>>
>> ??? Overall, this is looking quite good.
>>
>> ??? One more thing: the patch adds several new tests, so you will 
>> need
>> ??? to run at least the new tests on all three platforms (a quick
>> ??? check on Mac shows a couple failures).
>>
>> ??? I also see a couple differences between jfx-dev and 8u-dev in the
>> ??? native code that should be looked into to make sure there wasn't 
>> a
>> ??? missed fix on the backport (the Hi-DPI diffs are expected, but I
>> ??? see a couple others).
>>
>> ??? -- Kevin
>>
>>
>> ??? On 10/3/2018 10:16 AM, Kevin Rushforth wrote:
>> ??? > My initial testing shows a couple problems which will need to 
>> be
>> ??? > resolved:
>> ??? >
>> ??? > 1) I get many GTK warnings relating to Pango when running
>> ??? HelloWebView
>> ??? > 2) Running any program that uses media crashes
>> ??? >
>> ??? > This is on Ubuntu 16.04 LTS using the default GTK 2 mode.
>> ??? >
>> ??? > -- Kevin
>> ??? >
>> ??? >
>> ??? > On 10/3/2018 3:26 AM, Pankaj Bansal wrote:
>> ??? >>
>> ??? >> Hi All,
>> ??? >>
>> ??? >> Please review the patch for 8u-dev backport for JDK-8087516
>> ??? >> <https://bugs.openjdk.java.net/browse/JDK-8087516>. It adds
>> ??? >> conditional support for gtk3.
>> ??? >>
>> ??? >> Along with the enhancement, following bug fixes have also been
>> ??? >> included in the backport webrev
>> ??? >>
>> ??? >> 1.https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] 
>> invalid
>> ??? >> rendering of FX app stage in case of scaling
>> ??? >>
>> ??? >> 2.https://bugs.openjdk.java.net/browse/JDK-8163496: Rework
>> ??? Glass GTK
>> ??? >> to correct gtk3 structure sizes
>> ??? >>
>> ??? >> 3.https://bugs.openjdk.java.net/browse/JDK-8145837: Remove
>> ??? deprecated
>> ??? >> GTK2 calls in JavaFX
>> ??? >>
>> ??? >> 4.https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to
>> ??? newer
>> ??? >> version of SWT for build/test
>> ??? >>
>> ??? >> 5.https://bugs.openjdk.java.net/browse/JDK-8171330: Issues 
>> with
>> ??? >> transparent stage and GTK
>> ??? >>
>> ??? >> 6.https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: 
>> JavaFX
>> ??? >> window not painted with background when using GTK 3
>> ??? >>
>> ??? >> 7.https://bugs.openjdk.java.net/browse/JDK-8166414: Scene 
>> returns
>> ??? >> incorrect coordinates
>> ??? >>
>> ??? >> 8.https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04:
>> ??? >> expandable content goes outside of the alert dialog
>> ??? >>
>> ??? >> 9.https://bugs.openjdk.java.net/browse/JDK-8152421: After
>> ??? initing the
>> ??? >> modality of a non-primary stage to MODAL, closing that stage
>> ??? causes
>> ??? >> the primary stage to become non-resizable
>> ??? >>
>> ??? >> 10.https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux]
>> ??? >> Restoring owner stage after minimize does not restore position 
>> of
>> ??? >> child stage
>> ??? >>
>> ??? >> 11.https://bugs.openjdk.java.net/browse/JDK-8173901: Linux:
>> ??? Position
>> ??? >> of Stage is not restored after exiting full screen
>> ??? >>
>> ??? >> 12.https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: 
>> Dialog
>> ??? >> windows come up 1-pixel wide
>> ??? >>
>> ??? >> 13.https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: 
>> Stage
>> ??? >> initially in full-screen mode not shown when exiting 
>> full-screen
>> ??? >>
>> ??? >> 14.https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown
>> ??? >> position regression and not painting correctly tooltips 
>> regression
>> ??? >>
>> ??? >> 15.https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not
>> ??? always
>> ??? >> selected properly with GTK 3
>> ??? >>
>> ??? >> 16.https://bugs.openjdk.java.net/browse/JDK-8172219: Allow
>> ??? compiling
>> ??? >> without GTK 3.0 being installed
>> ??? >>
>> ??? >> 17.https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk
>> ??? >> version if SWT used via FXCanvas
>> ??? >>
>> ??? >> 18.https://bugs.openjdk.java.net/browse/JDK-8156491: 
>> Autodetect
>> ??? GTK
>> ??? >> version for JFX
>> ??? >>
>> ??? >> The original gtk3 backport patch applied cleanly, but the bugs 
>> did
>> ??? >> not apply cleanly. So a review is required.
>> ??? >>
>> ??? >> I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu
>> 16.04
>> ??? >> LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux 
>> 7.5.
>> ??? >>
>> ??? >> webrev:
>> ??? >>
>> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/
>> <http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.00/>
>> ??? >>
>> ??? >> JBS: https://bugs.openjdk.java.net/browse/JDK-8087516
>> ??? >>
>> ??? >> JDK 9 Changeset:
>> ??? >> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
>> ??? >>
>> ??? >> Regards,
>> ??? >>
>> ??? >> Pankaj
>> ??? >>
>> ??? >
>>
>


From johan.vos at gluonhq.com  Fri Oct 12 10:10:53 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 12 Oct 2018 12:10:53 +0200
Subject: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK
 3 on Linux
In-Reply-To: <ef04f0f8-5866-498c-85e6-c2d9adb8ae1d@default>
References: <d58d1dd1-3e67-46f6-8c81-b77fe315fbb9@default>
 <83da2996-f6a9-ac90-65f5-25679c1a0d4c@oracle.com>
 <8f955a90-7e21-9369-6b8d-bce84c36dfd4@oracle.com>
 <6f235abc-5ccb-4bed-b3ea-63fe9e5db546@default>
 <CABxFH2EtaECwdyGx3MrHrSx_TxfZuuSd5VwQC6BSqO781Y2u_A@mail.gmail.com>
 <e03029e2-5606-cadd-5ad3-53fe54a8935f@oracle.com>
 <be1b5537-6178-6910-87b4-cecabe7a92eb@oracle.com>
 <ef04f0f8-5866-498c-85e6-c2d9adb8ae1d@default>
Message-ID: <CABxFH2EGk9Zvq=65w3DH9yrmyVNhpx+pOSdH+Rb7QrVPV2uXtA@mail.gmail.com>

Hi Pankaj,

Now the build succeeds, and my basic tests are working.
+1

Thanks,

- Johan

On Fri, Oct 12, 2018 at 11:25 AM Pankaj Bansal <pankaj.b.bansal at oracle.com>
wrote:

> Hello Johan,
>
> We have backported https://bugs.openjdk.java.net/browse/JDK-8189689 in
> 8u-dev under https://bugs.openjdk.java.net/browse/JDK-8212106.
>
> Can you please try now to build on 18.04 LTS ? It should pass.
>
> Regards,
> Pankaj
>
> -----Original Message-----
> From: Kevin Rushforth
> Sent: Thursday, October 11, 2018 9:17 PM
> To: Johan Vos; Pankaj Bansal
> Cc: openjfx-dev at openjdk.java.net
> Subject: Re: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for
> GTK 3 on Linux
>
> I used the wrong bug ID below. Here is the right one:
>
> 8189689: JavaFX build fails with gcc 6 [1]
>
> Pankaj will send a backport request for this tomorrow. We should get this
> one in ASAP since 8u-dev is unable to compile on Ubuntu 18.04 today.
>
> -- Kevin
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8189689
>
>
> On 10/11/2018 8:28 AM, Kevin Rushforth wrote:
> > We use gcc 7.3 (and Oracle Linux 6 / 7) for our Hudson builds of FX 8
> > and don't see this problem. Pankaj asked about backporting the fix for
> > that JDK-8203884, but I suggested it wasn't needed, since it is
> > unrelated to this change.
> >
> > It sounds like we should backport JDK-8203884, though I prefer it as a
> > separate fix not tied to the GTK 3 work.
> >
> > -- Kevin
> >
> >
> > On 10/11/2018 3:35 AM, Johan Vos wrote:
> >> Hi Pankaj,
> >>
> >> What gcc version did you use to build on Ubuntu 18.04? Default, I
> >> think gcc 7.3 is used in 18.04 and that has the issue with wait() in
> >> modules/fxpackager/src/main/native/library/common/PosixPlatform.cpp
> >> (which was later replaced with
> >> wait(&status);
> >> )
> >>
> >> This is blocking me to build 8u-dev on Ubuntu 18.04.
> >> On Ubuntu 16.04, there are no issues and it works fine there.
> >>
> >> - Johan
> >>
> >> On Wed, Oct 10, 2018 at 5:10 PM Pankaj Bansal
> >> <pankaj.b.bansal at oracle.com <mailto:pankaj.b.bansal at oracle.com>> wrote:
> >>
> >>     Hi Kevin,
> >>
> >>     Thanks for review and the information provided.
> >>
> >>     I have updated the webrev for the proposed change from
> >> RTLD_GLOBAL
> >>     to RTLD_LOCAL in launcher.c. Along with the this change, the new
> >>     patch also includes the backport of two more fixes mentioned
> >>     below. So now we have backported total of 20 bugs.
> >>
> >>     19. JDK-8171985: Fx applet fails to get loaded on Ubuntu with
> >>     jre9-b150
> >>     20. JDK-8171928: Build fails on Oracle Linux 7 with unused
> >>     parameter warning
> >>
> >>     I have tested it on all three platforms (Windows 10, Linux
> >> (Ubuntu
> >>     18.4 LTS, Ubuntu 16.04 LTS) and and Mac) and no new test failures
> >>     are found. I have tested the "HelloWebView" and "Ensemble" and I
> >>     don't see any issue. I did some sanity testing on OL 7.5 as well
> >>     and things look good to me.
> >>
> >>     Webrev:
> >> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.01/
> >> <http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.01/>
> >>
> >>     Regards,
> >>     Pankaj
> >>
> >>
> >>     -----Original Message-----
> >>     From: Kevin Rushforth
> >>     Sent: Thursday, October 4, 2018 7:41 AM
> >>     To: Pankaj Bansal; openjfx-dev at openjdk.java.net
> >>     <mailto:openjfx-dev at openjdk.java.net>
> >>     Subject: Re: [8u-backport] JDK-8087516 : [JavaFX] Conditional
> >>     support for GTK 3 on Linux
> >>
> >>     I debugged this offline earlier today, and it looks related to a
> >>     collision in the glib library. As I mentioned offline, a possible
> >>     solution is to remove RTLD_GLOBAL from the dlopen of the
> >>     libglassgtk{2,3}.so library. I was able to do a full build / test
> >>     on both GTK 2 and GTK 3 including media and webkit with that
> >>     modification.
> >>
> >>     Overall, this is looking quite good.
> >>
> >>     One more thing: the patch adds several new tests, so you will
> >> need
> >>     to run at least the new tests on all three platforms (a quick
> >>     check on Mac shows a couple failures).
> >>
> >>     I also see a couple differences between jfx-dev and 8u-dev in the
> >>     native code that should be looked into to make sure there wasn't
> >> a
> >>     missed fix on the backport (the Hi-DPI diffs are expected, but I
> >>     see a couple others).
> >>
> >>     -- Kevin
> >>
> >>
> >>     On 10/3/2018 10:16 AM, Kevin Rushforth wrote:
> >>     > My initial testing shows a couple problems which will need to
> >> be
> >>     > resolved:
> >>     >
> >>     > 1) I get many GTK warnings relating to Pango when running
> >>     HelloWebView
> >>     > 2) Running any program that uses media crashes
> >>     >
> >>     > This is on Ubuntu 16.04 LTS using the default GTK 2 mode.
> >>     >
> >>     > -- Kevin
> >>     >
> >>     >
> >>     > On 10/3/2018 3:26 AM, Pankaj Bansal wrote:
> >>     >>
> >>     >> Hi All,
> >>     >>
> >>     >> Please review the patch for 8u-dev backport for JDK-8087516
> >>     >> <https://bugs.openjdk.java.net/browse/JDK-8087516>. It adds
> >>     >> conditional support for gtk3.
> >>     >>
> >>     >> Along with the enhancement, following bug fixes have also been
> >>     >> included in the backport webrev
> >>     >>
> >>     >> 1.https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3]
> >> invalid
> >>     >> rendering of FX app stage in case of scaling
> >>     >>
> >>     >> 2.https://bugs.openjdk.java.net/browse/JDK-8163496: Rework
> >>     Glass GTK
> >>     >> to correct gtk3 structure sizes
> >>     >>
> >>     >> 3.https://bugs.openjdk.java.net/browse/JDK-8145837: Remove
> >>     deprecated
> >>     >> GTK2 calls in JavaFX
> >>     >>
> >>     >> 4.https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to
> >>     newer
> >>     >> version of SWT for build/test
> >>     >>
> >>     >> 5.https://bugs.openjdk.java.net/browse/JDK-8171330: Issues
> >> with
> >>     >> transparent stage and GTK
> >>     >>
> >>     >> 6.https://bugs.openjdk.java.net/browse/JDK-8171976: Linux:
> >> JavaFX
> >>     >> window not painted with background when using GTK 3
> >>     >>
> >>     >> 7.https://bugs.openjdk.java.net/browse/JDK-8166414: Scene
> >> returns
> >>     >> incorrect coordinates
> >>     >>
> >>     >> 8.https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu
> 16.04:
> >>     >> expandable content goes outside of the alert dialog
> >>     >>
> >>     >> 9.https://bugs.openjdk.java.net/browse/JDK-8152421: After
> >>     initing the
> >>     >> modality of a non-primary stage to MODAL, closing that stage
> >>     causes
> >>     >> the primary stage to become non-resizable
> >>     >>
> >>     >> 10.https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux]
> >>     >> Restoring owner stage after minimize does not restore position
> >> of
> >>     >> child stage
> >>     >>
> >>     >> 11.https://bugs.openjdk.java.net/browse/JDK-8173901: Linux:
> >>     Position
> >>     >> of Stage is not restored after exiting full screen
> >>     >>
> >>     >> 12.https://bugs.openjdk.java.net/browse/JDK-8175204: Linux:
> >> Dialog
> >>     >> windows come up 1-pixel wide
> >>     >>
> >>     >> 13.https://bugs.openjdk.java.net/browse/JDK-8175205: Linux:
> >> Stage
> >>     >> initially in full-screen mode not shown when exiting
> >> full-screen
> >>     >>
> >>     >> 14.https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown
> >>     >> position regression and not painting correctly tooltips
> >> regression
> >>     >>
> >>     >> 15.https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not
> >>     always
> >>     >> selected properly with GTK 3
> >>     >>
> >>     >> 16.https://bugs.openjdk.java.net/browse/JDK-8172219: Allow
> >>     compiling
> >>     >> without GTK 3.0 being installed
> >>     >>
> >>     >> 17.https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk
> >>     >> version if SWT used via FXCanvas
> >>     >>
> >>     >> 18.https://bugs.openjdk.java.net/browse/JDK-8156491:
> >> Autodetect
> >>     GTK
> >>     >> version for JFX
> >>     >>
> >>     >> The original gtk3 backport patch applied cleanly, but the bugs
> >> did
> >>     >> not apply cleanly. So a review is required.
> >>     >>
> >>     >> I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu
> >> 16.04
> >>     >> LTS, Ubuntu 18.04 and have done sanity testing on Oracle Linux
> >> 7.5.
> >>     >>
> >>     >> webrev:
> >>     >>
> >> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/
> >> <http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.00/>
> >>     >>
> >>     >> JBS: https://bugs.openjdk.java.net/browse/JDK-8087516
> >>     >>
> >>     >> JDK 9 Changeset:
> >>     >> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
> >>     >>
> >>     >> Regards,
> >>     >>
> >>     >> Pankaj
> >>     >>
> >>     >
> >>
> >
>
>

From ljyiiima at gmail.com  Wed Oct 10 02:49:21 2018
From: ljyiiima at gmail.com (LJY)
Date: Wed, 10 Oct 2018 10:49:21 +0800
Subject: TableViewFocusModel.focusedCellProperty() using raw type TablePosition
Message-ID: <CAKm0DbUDXxbz+ZhZhAs27HrmAOhNrXPmb0c0QNjbHc6H-ZO8YA@mail.gmail.com>

Can I check is there any reason why this is designed so? This causes anyone
who actually uses it to do casts/suppresses.

From mkroening at posteo.net  Fri Oct 12 11:23:38 2018
From: mkroening at posteo.net (Martin =?ISO-8859-1?Q?Kr=F6ning?=)
Date: Fri, 12 Oct 2018 13:23:38 +0200
Subject: RFR: JDK-8212115 : Typo in javadoc for javafx.stage.Window
Message-ID: <8a5db09cd1a503b364f5434ba2ff165cad3deeda.camel@posteo.net>

Please review the following fix for a typo in the javadocs:

https://bugs.openjdk.java.net/browse/JDK-8212115
https://github.com/javafxports/openjdk-jfx/pull/227

Thanks,
Martin


From kevin.rushforth at oracle.com  Fri Oct 12 18:46:10 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 12 Oct 2018 11:46:10 -0700
Subject: [8u] RFR: JDK-8212139: FX 8u-dev fails to build on Oracle Linux 6
 after fix for JDK-8206246
Message-ID: <81cd2ebe-1bf1-7abc-62b2-ad9208745e62@oracle.com>

Phil,

Please review the following:

https://bugs.openjdk.java.net/browse/JDK-8212139
http://cr.openjdk.java.net/~kcr/8212139/webrev/

The recently-pushed GTK3 update for JDK-8206246 [1] has caused a fatal 
build failure on our production Linux build machines. Please review the 
following webrev, which backs out JDK-8206246 using "hg backout":

The production builds of FX 8u are done on an Oracle Linux 6 machine, 
which doesn't have the needed libraries for GTK 3. We need to explore 
upgrading to Oracle Linux 7, but in the mean time we need to backout 
this change.

Sorry for the trouble. We will look at getting this back in as soon as 
we can.

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8206246


From philip.race at oracle.com  Fri Oct 12 20:03:53 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 12 Oct 2018 13:03:53 -0700
Subject: [8u] RFR: JDK-8212139: FX 8u-dev fails to build on Oracle Linux 6
 after fix for JDK-8206246
In-Reply-To: <81cd2ebe-1bf1-7abc-62b2-ad9208745e62@oracle.com>
References: <81cd2ebe-1bf1-7abc-62b2-ad9208745e62@oracle.com>
Message-ID: <a66bc364-e322-8441-3393-c2d465c8f81b@oracle.com>

+1

-phil.

On 10/12/2018 11:46 AM, Kevin Rushforth wrote:
> Phil,
>
> Please review the following:
>
> https://bugs.openjdk.java.net/browse/JDK-8212139
> http://cr.openjdk.java.net/~kcr/8212139/webrev/
>
> The recently-pushed GTK3 update for JDK-8206246 [1] has caused a fatal 
> build failure on our production Linux build machines. Please review 
> the following webrev, which backs out JDK-8206246 using "hg backout":
>
> The production builds of FX 8u are done on an Oracle Linux 6 machine, 
> which doesn't have the needed libraries for GTK 3. We need to explore 
> upgrading to Oracle Linux 7, but in the mean time we need to backout 
> this change.
>
> Sorry for the trouble. We will look at getting this back in as soon as 
> we can.
>
> -- Kevin
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8206246
>


From org.openjdk at io7m.com  Sat Oct 13 16:19:09 2018
From: org.openjdk at io7m.com (Mark Raynsford)
Date: Sat, 13 Oct 2018 17:19:09 +0100
Subject: Error: JavaFX runtime components are missing, and are required to
 run this application
Message-ID: <20181013171909.73ca6eec@almond.int.arc7.info>

Hello!

Now that Java 11 is at general availability, I decided to give OpenJFX
11 a shot today. Unfortunately, I encountered the above error with an
extremely trivial example project:

Error: JavaFX runtime components are missing, and are required to run
this application

The Maven project setup I'm using is here:

  https://github.com/io7m/javafxhello

$ java -version
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

$ mvn --version
Apache Maven 3.5.4 (NON-CANONICAL_2018-09-08T01:02:16+02:00_root;
2018-09-08T00:02:16+01:00) Maven home: /opt/maven
Java version: 11, vendor: Oracle Corporation,
runtime: /usr/lib/jvm/jdk-11 Default locale: en_GB, platform encoding:
UTF-8 OS name: "linux", version: "4.18.12-arch1-1-arch", arch: "amd64",
family: "unix"

If I try to run the program from the IDE (Intellij), the exact command
line used is:

$ /usr/lib/jvm/jdk-11/bin/java
  -javaagent:/usr/share/idea/lib/idea_rt.jar=34729:/usr/share/idea/bin \
  -Dfile.encoding=UTF-8 \
  -classpath /home/rm/doc/dev/2018/10/javafxhello/target/classes:/home/rm/var/maven/org/openjfx/javafx-controls/11/javafx-controls-11.jar:/home/rm/var/maven/org/openjfx/javafx-controls/11/javafx-controls-11-linux.jar:/home/rm/var/maven/org/openjfx/javafx-graphics/11/javafx-graphics-11.jar:/home/rm/var/maven/org/openjfx/javafx-graphics/11/javafx-graphics-11-linux.jar:/home/rm/var/maven/org/openjfx/javafx-base/11/javafx-base-11.jar:/home/rm/var/maven/org/openjfx/javafx-base/11/javafx-base-11-linux.jar
  com.io7m.javafxhello.Main

Am I doing something wrong? I feel like I've set things up the same way
as shown in the documentation.

-- 
Mark Raynsford | http://www.io7m.com


From johan.vos at gluonhq.com  Sat Oct 13 17:46:34 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Sat, 13 Oct 2018 19:46:34 +0200
Subject: Error: JavaFX runtime components are missing, and are required to
 run this application
In-Reply-To: <20181013171909.73ca6eec@almond.int.arc7.info>
References: <20181013171909.73ca6eec@almond.int.arc7.info>
Message-ID: <CABxFH2GkZ4aGene0w4jL5nR6NMLU0MaORXxYbPP_+Ws43yshJg@mail.gmail.com>

The Java launcher (in the Java 11 JDK) checks if your main class extends
Application, and in that case it checks the module path and tries to find
javafx.graphics module. If you have that module on the classpath, but not
as a module, the launcher will exit with the message you see.

There are some workarounds (e.g. you can have a Main class that doesn't
extend Application that calls your Application), but the best approach is
go modular, as explained here:
https://stackoverflow.com/questions/52467561/intellij-cant-recognize-javafx-11-with-openjdk-11/52470141#52470141

- Johan

On Sat, Oct 13, 2018 at 6:29 PM Mark Raynsford <org.openjdk at io7m.com> wrote:

> Hello!
>
> Now that Java 11 is at general availability, I decided to give OpenJFX
> 11 a shot today. Unfortunately, I encountered the above error with an
> extremely trivial example project:
>
> Error: JavaFX runtime components are missing, and are required to run
> this application
>
> The Maven project setup I'm using is here:
>
>   https://github.com/io7m/javafxhello
>
> $ java -version
> openjdk version "11" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11+28)
> OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
>
> $ mvn --version
> Apache Maven 3.5.4 (NON-CANONICAL_2018-09-08T01:02:16+02:00_root;
> 2018-09-08T00:02:16+01:00) Maven home: /opt/maven
> Java version: 11, vendor: Oracle Corporation,
> runtime: /usr/lib/jvm/jdk-11 Default locale: en_GB, platform encoding:
> UTF-8 OS name: "linux", version: "4.18.12-arch1-1-arch", arch: "amd64",
> family: "unix"
>
> If I try to run the program from the IDE (Intellij), the exact command
> line used is:
>
> $ /usr/lib/jvm/jdk-11/bin/java
>   -javaagent:/usr/share/idea/lib/idea_rt.jar=34729:/usr/share/idea/bin \
>   -Dfile.encoding=UTF-8 \
>   -classpath
> /home/rm/doc/dev/2018/10/javafxhello/target/classes:/home/rm/var/maven/org/openjfx/javafx-controls/11/javafx-controls-11.jar:/home/rm/var/maven/org/openjfx/javafx-controls/11/javafx-controls-11-linux.jar:/home/rm/var/maven/org/openjfx/javafx-graphics/11/javafx-graphics-11.jar:/home/rm/var/maven/org/openjfx/javafx-graphics/11/javafx-graphics-11-linux.jar:/home/rm/var/maven/org/openjfx/javafx-base/11/javafx-base-11.jar:/home/rm/var/maven/org/openjfx/javafx-base/11/javafx-base-11-linux.jar
>   com.io7m.javafxhello.Main
>
> Am I doing something wrong? I feel like I've set things up the same way
> as shown in the documentation.
>
> --
> Mark Raynsford | http://www.io7m.com
>
>

From org.openjdk at io7m.com  Sat Oct 13 17:58:12 2018
From: org.openjdk at io7m.com (Mark Raynsford)
Date: Sat, 13 Oct 2018 18:58:12 +0100
Subject: Error: JavaFX runtime components are missing, and are required
 to run this application
In-Reply-To: <CABxFH2GkZ4aGene0w4jL5nR6NMLU0MaORXxYbPP_+Ws43yshJg@mail.gmail.com>
References: <20181013171909.73ca6eec@almond.int.arc7.info>
 <CABxFH2GkZ4aGene0w4jL5nR6NMLU0MaORXxYbPP_+Ws43yshJg@mail.gmail.com>
Message-ID: <20181013185812.743fe8ec@almond.int.arc7.info>

On 2018-10-13T19:46:34 +0200
Johan Vos <johan.vos at gluonhq.com> wrote:

> The Java launcher (in the Java 11 JDK) checks if your main class extends
> Application, and in that case it checks the module path and tries to find
> javafx.graphics module. If you have that module on the classpath, but not
> as a module, the launcher will exit with the message you see.
> 
> There are some workarounds (e.g. you can have a Main class that doesn't
> extend Application that calls your Application), but the best approach is
> go modular, as explained here:
> https://stackoverflow.com/questions/52467561/intellij-cant-recognize-javafx-11-with-openjdk-11/52470141#52470141

Ah, ok, thanks!

I'm an OSGi user and although the vast majority of the library code I
write is JPMS modularized, the application code I write almost
certainly won't ever be (because I use OSGi rather than the JPMS).

I'm fine with not extending Application - in fact I won't even have the
option to do so because OSGi applications don't have that traditional
main() method.

Is there documentation somewhere on the workaround you mentioned?

-- 
Mark Raynsford | http://www.io7m.com


From org.openjdk at io7m.com  Sat Oct 13 18:29:41 2018
From: org.openjdk at io7m.com (Mark Raynsford)
Date: Sat, 13 Oct 2018 19:29:41 +0100
Subject: Error: JavaFX runtime components are missing, and are required
 to run this application
In-Reply-To: <CABxFH2GkZ4aGene0w4jL5nR6NMLU0MaORXxYbPP_+Ws43yshJg@mail.gmail.com>
References: <20181013171909.73ca6eec@almond.int.arc7.info>
 <CABxFH2GkZ4aGene0w4jL5nR6NMLU0MaORXxYbPP_+Ws43yshJg@mail.gmail.com>
Message-ID: <20181013192941.151eeab2@almond.int.arc7.info>

On 2018-10-13T19:46:34 +0200
Johan Vos <johan.vos at gluonhq.com> wrote:
>
> There are some workarounds (e.g. you can have a Main class that doesn't
> extend Application that calls your Application), but the best approach is
> go modular, as explained here:
> https://stackoverflow.com/questions/52467561/intellij-cant-recognize-javafx-11-with-openjdk-11/52470141#52470141
> 

The following appears to work: Given an unsurprising subclass of
Application:

public final class ExampleApplication extends Application
{
  private static final Logger LOG =
    Logger.getLogger(ExampleApplication.class.getCanonicalName());

  public ExampleApplication()
  {

  }

  @Override
  public void start(
    final Stage stage)
  {
    LOG.info("started");

    final Button button = new Button();
    button.setText("Click");

    final BorderPane pane = new BorderPane();
    pane.setCenter(button);

    final Scene scene = new Scene(pane, 640.0, 480.0);
    stage.setScene(scene);
    stage.setTitle("Example");
    stage.show();
  }
}

Then a main method that passes a class reference rather than allowing
the launcher to reflectively find the application:

public final class Main
{
  private Main()
  {

  }

  public static void main(
    final String[] args)
  {
    /*
     * Non-modular applications must specify the application class explicitly rather
     * than allowing the launcher to use reflection to try to instantiate and start
     * an application.
     */

    Application.launch(ExampleApplication.class, args);
  }
}

The application starts up and runs without issue.

-- 
Mark Raynsford | http://www.io7m.com


From org.openjdk at io7m.com  Sun Oct 14 20:22:23 2018
From: org.openjdk at io7m.com (Mark Raynsford)
Date: Sun, 14 Oct 2018 21:22:23 +0100
Subject: Some visual issues with a test application
Message-ID: <20181014212223.0b75d2d6@almond.int.arc7.info>

Hello!

I've been developing with Swing for many years, and I'm just now giving
JavaFX a serious look now that the distribution issues are fixed
(packages on Maven Central and the like).

I've run into a couple of odd issues and I'm not sure that either of
them are my fault.

I've been putting together a little API and GUI application for
browsing OSGi repositories:

  https://github.com/io7m/osgibrowse

I've recorded the issues here:

  http://ataxia.io7m.com/2018/10/14/javafx.mp4

You may notice that things look a little odd in that all windows appear
to be fullscreen. This is because I'm using a tiling window manager
(i3). Historically, Swing had a bit of trouble with this sort of window
manager. I'm not sure if JavaFX also does.

The first issue: The menu bar I created seems to behave erratically.
Sometimes I can click on the menu to open it, other times it flashes
open and then immediately closes. In both cases, the menu seems to be
detached from the menu bar (there's a gap between the menu and the bar).

The menu is created here and added to a BorderPane:

  https://github.com/io7m/osgibrowse/blob/develop/com.io7m.osgibrowse.gui.javafx/src/main/java/com/io7m/osgibrowse/gui/javafx/OBBrowserWindow.java#L30

The second issue: Icons set on TreeItem values seem to be corrupted
when the TreeTableView containing them is scrolled. You can see this
happen in the video. The table in question is populated from an
immutable snapshot of data returned by the underlying repository API.
Once a repository is added, the table is populated once and then does
not change until the user adds another repository.

Double clicking on a row "selects" a bundle from the repository
and this triggers a refresh of the table view. When I scroll up and
down, it seems like icon views are incorrectly reused from other rows.

The entirety of the table configuration happens here:

  https://github.com/io7m/osgibrowse/blob/develop/com.io7m.osgibrowse.gui.javafx/src/main/java/com/io7m/osgibrowse/gui/javafx/OBTableView.java#L188

Icons are set on the tree table nodes here:

  https://github.com/io7m/osgibrowse/blob/develop/com.io7m.osgibrowse.gui.javafx/src/main/java/com/io7m/osgibrowse/gui/javafx/OBTableView.java#L92

Any advice would be appreciated. "YOU ARE NOT USING THE API CORRECTLY"
criticism is also welcome.

-- 
Mark Raynsford | http://www.io7m.com


From org.openjdk at io7m.com  Sun Oct 14 20:27:55 2018
From: org.openjdk at io7m.com (Mark Raynsford)
Date: Sun, 14 Oct 2018 21:27:55 +0100
Subject: Some visual issues with a test application
In-Reply-To: <20181014212223.0b75d2d6@almond.int.arc7.info>
References: <20181014212223.0b75d2d6@almond.int.arc7.info>
Message-ID: <20181014212755.46d3b2aa@almond.int.arc7.info>

On 2018-10-14T21:22:23 +0100
Mark Raynsford <org.openjdk at io7m.com> wrote:

> Hello!
> 
> I've been developing with Swing for many years, and I'm just now giving
> JavaFX a serious look now that the distribution issues are fixed
> (packages on Maven Central and the like).

Forgot to mention:

$ uname -a
Linux almond.int.arc7.info 4.18.12-arch1-1-ARCH #1 SMP PREEMPT Thu Oct
4 01:01:27 UTC 2018 x86_64 GNU/Linux

$ java -version
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

-- 
Mark Raynsford | http://www.io7m.com


From youngty1997 at gmail.com  Mon Oct 15 04:36:37 2018
From: youngty1997 at gmail.com (Ty Young)
Date: Sun, 14 Oct 2018 23:36:37 -0500
Subject: Some visual issues with a test application
In-Reply-To: <20181014212223.0b75d2d6@almond.int.arc7.info>
References: <20181014212223.0b75d2d6@almond.int.arc7.info>
Message-ID: <899e8de2-7d53-d8f3-62f5-9749e1c70b0f@gmail.com>

On 10/14/18 3:22 PM, Mark Raynsford wrote:

> Hello!
>
> I've been developing with Swing for many years, and I'm just now giving
> JavaFX a serious look now that the distribution issues are fixed
> (packages on Maven Central and the like).
>
> I've run into a couple of odd issues and I'm not sure that either of
> them are my fault.
>
> I've been putting together a little API and GUI application for
> browsing OSGi repositories:
>
>    https://github.com/io7m/osgibrowse
>
> I've recorded the issues here:
>
>    http://ataxia.io7m.com/2018/10/14/javafx.mp4
>
> You may notice that things look a little odd in that all windows appear
> to be fullscreen. This is because I'm using a tiling window manager
> (i3). Historically, Swing had a bit of trouble with this sort of window
> manager. I'm not sure if JavaFX also does.
>
> The first issue: The menu bar I created seems to behave erratically.
> Sometimes I can click on the menu to open it, other times it flashes
> open and then immediately closes. In both cases, the menu seems to be
> detached from the menu bar (there's a gap between the menu and the bar).
>
> The menu is created here and added to a BorderPane:
>
>    https://github.com/io7m/osgibrowse/blob/develop/com.io7m.osgibrowse.gui.javafx/src/main/java/com/io7m/osgibrowse/gui/javafx/OBBrowserWindow.java#L30
>
> The second issue: Icons set on TreeItem values seem to be corrupted
> when the TreeTableView containing them is scrolled. You can see this
> happen in the video. The table in question is populated from an
> immutable snapshot of data returned by the underlying repository API.
> Once a repository is added, the table is populated once and then does
> not change until the user adds another repository.
>
> Double clicking on a row "selects" a bundle from the repository
> and this triggers a refresh of the table view. When I scroll up and
> down, it seems like icon views are incorrectly reused from other rows.
>
> The entirety of the table configuration happens here:
>
>    https://github.com/io7m/osgibrowse/blob/develop/com.io7m.osgibrowse.gui.javafx/src/main/java/com/io7m/osgibrowse/gui/javafx/OBTableView.java#L188
>
> Icons are set on the tree table nodes here:
>
>    https://github.com/io7m/osgibrowse/blob/develop/com.io7m.osgibrowse.gui.javafx/src/main/java/com/io7m/osgibrowse/gui/javafx/OBTableView.java#L92
>
> Any advice would be appreciated.


The code ultimately does everything correctly. Some JavaFX components 
expose a getChildren() method which doesn't actually do anything because 
your supposed to use getItems() or something like that and it causes odd 
behavior but you're using the right methods...


but I digress, JDK 11 switched to GTK3 by default which has caused some 
bugs. Try setting:


-Djdk.gtk.version=2


wherever you add run args in your Maven project(I use Ant and have no 
experience with Maven). It will force GTK2. I tried to run your program 
myself but there doesn't seem to be a way to add local dependencies like 
you can with Ant in Netbeans 9, causing a build fail and Netbeans 9 
can't find a main class.


>   "YOU ARE NOT USING THE API CORRECTLY"
> criticism is also welcome.
>

If I may ask, why are you sidestepping constructors and using static 
everywhere? It works all the same, just never seen anyone write code the 
way you did.


From youngty1997 at gmail.com  Mon Oct 15 05:05:50 2018
From: youngty1997 at gmail.com (Ty Young)
Date: Mon, 15 Oct 2018 00:05:50 -0500
Subject: JavaFX in-memory dynamic CSS file editing and applying
Message-ID: <4cbfcef6-b8cc-237e-f948-35699efd7429@gmail.com>

Does JavaFX have an API for dynamically editing and applying CSS files 
in-memory? If not, would there be any possibility in one ever being made?


My reasoning for such an API is, instead of switching between completely 
separate CSS files and having to update each whenever I need to support 
a new component, I'd like the ability to just have 1 CSS file and edit 
it's values in-memory and have it reflected in JavaFX as soon as the 
change is made. For example instead of changing the individual 
components themselves I'd like to get all of this:


*
{
 ??? -fx-theme-header: #444444;
 ??? -fx-theme-background: #3D3D3D;
 ??? -fx-theme-background-alt: #2E2E2E;
 ??? -fx-theme-selected: #F0544C;
 ??? -fx-theme-label-text: #D2D2D2;
 ??? -fx-theme-selectable-hover: #454545;
 ??? -fx-theme-tab-close-color: -fx-theme-label-text;

 ??? -fx-highlight-fill: -fx-theme-selected;
}


and modify it via a JavaFX API to change it to something like:


*
{
 ??? -fx-theme-header: #FFFFFF;
 ??? -fx-theme-background: -fx-theme-header;
 ??? -fx-theme-background-alt: #F2F2F2;
 ??? -fx-theme-selected: #CBEAFF;
 ??? -fx-theme-label-text: #333333;
 ??? -fx-theme-selectable-hover: #E1E1E1;
 ??? -fx-theme-tab-close-color: -fx-theme-label-text;

 ??? -fx-highlight-fill: -fx-theme-selected;
}


Since these are used throughout the CSS file, all the components that 
use these will be updated.






From org.openjdk at io7m.com  Mon Oct 15 08:54:36 2018
From: org.openjdk at io7m.com (Mark Raynsford)
Date: Mon, 15 Oct 2018 09:54:36 +0100
Subject: Some visual issues with a test application
In-Reply-To: <899e8de2-7d53-d8f3-62f5-9749e1c70b0f@gmail.com>
References: <20181014212223.0b75d2d6@almond.int.arc7.info>
 <899e8de2-7d53-d8f3-62f5-9749e1c70b0f@gmail.com>
Message-ID: <20181015095436.484926f8@almond.int.arc7.info>

Hello!

On 2018-10-14T23:36:37 -0500
Ty Young <youngty1997 at gmail.com> wrote:
>
> but I digress, JDK 11 switched to GTK3 by default which has caused some 
> bugs. Try setting:
> 
> 
> -Djdk.gtk.version=2

This fixes the menu issue (thanks!) but it doesn't fix the issue with
the icons in the table. Is there an open bug for the menu issue that I
can track?

Is there anything I can do about the table icons? I mean, not having
them at all is one option, but I'm mildly concerned that that's a
band-aid on a more serious problem (although you seem to be suggesting
that I've not made any obvious mistakes in the code).

> >   "YOU ARE NOT USING THE API CORRECTLY"
> > criticism is also welcome.
> >  
> 
> If I may ask, why are you sidestepping constructors and using static 
> everywhere? It works all the same, just never seen anyone write code the 
> way you did.

It's a couple of things: One is that I prefer to keep constructors as
side-effect free as possible. The other is that I approached this code
as I would have done with Swing. In Swing, it's more typical to extend
existing API classes like JFrame and so on than it is to aggregate
them. Doing so inevitably leads to rather large constructors that do
all sorts of work like instantiating other components, setting up
layouts and the like. This almost inevitably leads to the code leaking
the "this" reference to other code within the constructor, and this is
rather bad practice (passing a not-yet-completely-constructed value to
other code is a recipe for bugs). As such, I tended to write Swing code
where all of the complex initialization happens in static factory
methods. I agree it looks rather odd. There's actually a "bug" in the
OBBrowserWindow code in the sense that I don't pass any references to
the constructor. This whole project is very much a sketch pad for
getting to grips with how to write a real application with JavaFX, so
I'm not too bothered.

-- 
Mark Raynsford | http://www.io7m.com


From david.grieve at oracle.com  Mon Oct 15 12:02:10 2018
From: david.grieve at oracle.com (David Grieve)
Date: Mon, 15 Oct 2018 08:02:10 -0400
Subject: JavaFX in-memory dynamic CSS file editing and applying
In-Reply-To: <4cbfcef6-b8cc-237e-f948-35699efd7429@gmail.com>
References: <4cbfcef6-b8cc-237e-f948-35699efd7429@gmail.com>
Message-ID: <578ea8e1-45e3-a89b-d276-995da1a231e9@oracle.com>

Just setStyle -fx-theme-header (etc.) on the root node.


On 10/15/18 1:05 AM, Ty Young wrote:
> Does JavaFX have an API for dynamically editing and applying CSS files 
> in-memory? If not, would there be any possibility in one ever being made?
>
>
> My reasoning for such an API is, instead of switching between 
> completely separate CSS files and having to update each whenever I 
> need to support a new component, I'd like the ability to just have 1 
> CSS file and edit it's values in-memory and have it reflected in 
> JavaFX as soon as the change is made. For example instead of changing 
> the individual components themselves I'd like to get all of this:
>
>
> *
> {
> ??? -fx-theme-header: #444444;
> ??? -fx-theme-background: #3D3D3D;
> ??? -fx-theme-background-alt: #2E2E2E;
> ??? -fx-theme-selected: #F0544C;
> ??? -fx-theme-label-text: #D2D2D2;
> ??? -fx-theme-selectable-hover: #454545;
> ??? -fx-theme-tab-close-color: -fx-theme-label-text;
>
> ??? -fx-highlight-fill: -fx-theme-selected;
> }
>
>
> and modify it via a JavaFX API to change it to something like:
>
>
> *
> {
> ??? -fx-theme-header: #FFFFFF;
> ??? -fx-theme-background: -fx-theme-header;
> ??? -fx-theme-background-alt: #F2F2F2;
> ??? -fx-theme-selected: #CBEAFF;
> ??? -fx-theme-label-text: #333333;
> ??? -fx-theme-selectable-hover: #E1E1E1;
> ??? -fx-theme-tab-close-color: -fx-theme-label-text;
>
> ??? -fx-highlight-fill: -fx-theme-selected;
> }
>
>
> Since these are used throughout the CSS file, all the components that 
> use these will be updated.
>
>
>
>
>


From samir.hadzic.pro at gmail.com  Mon Oct 15 12:27:50 2018
From: samir.hadzic.pro at gmail.com (Sam')
Date: Mon, 15 Oct 2018 14:27:50 +0200
Subject: Review request for #151 Open VirtualFlow and other relating classes
 API for sublclassing
Message-ID: <CAL3niDFz6pxsANsnr8W00do=mbgkQTCinusg06ukwa7eZTuHhQ@mail.gmail.com>

Please review the GitHub pull request:
https://github.com/javafxports/openjdk-jfx/pull/163
<https://github.com/javafxports/openjdk-jfx/pull/235>

which fixes:


Open VirtualFlow API for subclassing

https://github.com/javafxports/openjdk-jfx/issues/151
<https://bugs.openjdk.java.net/browse/JDK-8188810>

Thank you,
Samir

From chengen.zhao at whitewoodcity.com  Mon Oct 15 01:32:40 2018
From: chengen.zhao at whitewoodcity.com (Chengen Zhao)
Date: Mon, 15 Oct 2018 09:32:40 +0800
Subject: =?UTF-8?B?M0QgQ2FudmFzIE5vZGU/?=
Message-ID: <9312e331-8763-42a0-9999-7bbc59a3be52.chengen.zhao@whitewoodcity.com>

Hi:

We are currently developing games by using JavaFX
one feature would be nice to have is 3D Canvas node
so is it possible to have this feature in the future release?

Thanks

From kevin.rushforth at oracle.com  Mon Oct 15 13:00:27 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 15 Oct 2018 06:00:27 -0700
Subject: Review request for #151 Open VirtualFlow and other relating
 classes API for sublclassing
In-Reply-To: <CAL3niDFz6pxsANsnr8W00do=mbgkQTCinusg06ukwa7eZTuHhQ@mail.gmail.com>
References: <CAL3niDFz6pxsANsnr8W00do=mbgkQTCinusg06ukwa7eZTuHhQ@mail.gmail.com>
Message-ID: <cd593ae5-74a6-9c4c-d422-3070ea59792a@oracle.com>

Note that since this is request for a new feature there are a couple 
other steps needed:

1. The proposed feature, along with the new API should be discussed and 
general agreement reached. This is already in progress and is happening 
in the PR itself. Mainly what needs to be ironed out now is to make sure 
that each new API method is needed, and its purpose and use is well 
understood and documents. Some of you have already provided valuable 
feedback on this.

2. Once we have general agreement on the API additions, a CSR will be 
needed (Eugene has graciously agreed to file it with my help). The CSR 
will then need review / approval from a lead: Johan or myself.

The code review can proceed in parallel with #2 -- it will need (at 
least) two reviewers.

With Oracle Code One approaching, I expect there will be some delay in 
the first two items, but we still have plenty of time to get this in for 
openjfx12.

Thanks!

-- Kevin


On 10/15/2018 5:27 AM, Sam' wrote:
> Please review the GitHub pull request:
> https://github.com/javafxports/openjdk-jfx/pull/163
> <https://github.com/javafxports/openjdk-jfx/pull/235>
>
> which fixes:
>
>
> Open VirtualFlow API for subclassing
>
> https://github.com/javafxports/openjdk-jfx/issues/151
> <https://bugs.openjdk.java.net/browse/JDK-8188810>
>
> Thank you,
> Samir


From kevin.rushforth at oracle.com  Mon Oct 15 13:02:50 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 15 Oct 2018 06:02:50 -0700
Subject: Review request for #151 Open VirtualFlow and other relating
 classes API for sublclassing
In-Reply-To: <cd593ae5-74a6-9c4c-d422-3070ea59792a@oracle.com>
References: <CAL3niDFz6pxsANsnr8W00do=mbgkQTCinusg06ukwa7eZTuHhQ@mail.gmail.com>
 <cd593ae5-74a6-9c4c-d422-3070ea59792a@oracle.com>
Message-ID: <4d62a89a-218b-98c9-bea6-f8fcb00a7f0a@oracle.com>

Samir,

Also, can you provide JBS bug ID? The one you listed in your review 
request is the wrong Bug ID.

Thanks.

-- Kevin


On 10/15/2018 6:00 AM, Kevin Rushforth wrote:
> Note that since this is request for a new feature there are a couple 
> other steps needed:
>
> 1. The proposed feature, along with the new API should be discussed 
> and general agreement reached. This is already in progress and is 
> happening in the PR itself. Mainly what needs to be ironed out now is 
> to make sure that each new API method is needed, and its purpose and 
> use is well understood and documents. Some of you have already 
> provided valuable feedback on this.
>
> 2. Once we have general agreement on the API additions, a CSR will be 
> needed (Eugene has graciously agreed to file it with my help). The CSR 
> will then need review / approval from a lead: Johan or myself.
>
> The code review can proceed in parallel with #2 -- it will need (at 
> least) two reviewers.
>
> With Oracle Code One approaching, I expect there will be some delay in 
> the first two items, but we still have plenty of time to get this in 
> for openjfx12.
>
> Thanks!
>
> -- Kevin
>
>
> On 10/15/2018 5:27 AM, Sam' wrote:
>> Please review the GitHub pull request:
>> https://github.com/javafxports/openjdk-jfx/pull/163
>> <https://github.com/javafxports/openjdk-jfx/pull/235>
>>
>> which fixes:
>>
>>
>> Open VirtualFlow API for subclassing
>>
>> https://github.com/javafxports/openjdk-jfx/issues/151
>> <https://bugs.openjdk.java.net/browse/JDK-8188810>
>>
>> Thank you,
>> Samir
>


From r.lichtenberger at gmail.com  Mon Oct 15 13:29:14 2018
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Mon, 15 Oct 2018 15:29:14 +0200
Subject: Backport for https://bugs.openjdk.java.net/browse/JDK-8157913 to jdk8?
Message-ID: <50f7402f-93ca-0139-a561-f42696205cc2@gmail.com>

Is there a chance that the fix for 
https://bugs.openjdk.java.net/browse/JDK-8157913 will be backported to jdk8?

It seems like a major error to me, if packaged applications don't start 
and I have just been affected by this problem.


Best regards,

Robert Lichtenberger


From pedro.duquevieira at gmail.com  Mon Oct 15 14:32:20 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Mon, 15 Oct 2018 15:32:20 +0100
Subject: JavaFX in-memory dynamic CSS file editing and applying
Message-ID: <CAAEud6YqCxwedFPrPRCNSCbH3tHavXrEqoT46eC550azazQBEA@mail.gmail.com>

Not sure if I totally understand what you want but you can change the
values of CSS variables through code by setting inline styles on
components, via setStyle method.

Pardon the publicity but yesterday I just happened to mention exactly that
on one of my posts and might help you:
https://pixelduke.com/2018/10/14/fxribbon-version-1-2-released/

-- 
Pedro Duque Vieira - https://www.pixelduke.com

From johnvalrose at gmail.com  Mon Oct 15 16:08:18 2018
From: johnvalrose at gmail.com (John-Val Rose)
Date: Tue, 16 Oct 2018 03:08:18 +1100
Subject: 3D Canvas Node?
In-Reply-To: <9312e331-8763-42a0-9999-7bbc59a3be52.chengen.zhao@whitewoodcity.com>
References: <9312e331-8763-42a0-9999-7bbc59a3be52.chengen.zhao@whitewoodcity.com>
Message-ID: <A6B107DA-7CA1-4A48-928F-4EB89F5A92C1@gmail.com>

I also believe that such a component would be highly beneficial & I myself have suggested it many times in the past.

To Chengen Zhao, you may not be aware but there is a new mailing list where it may be more appropriate to ask this question.

That list is openjfx-discuss at openjdk.java.net

I hope this helps.

Graciously,

John-Val Rose

> On 15 Oct 2018, at 12:32, Chengen Zhao <chengen.zhao at whitewoodcity.com> wrote:
> 
> Hi:
> 
> We are currently developing games by using JavaFX
> one feature would be nice to have is 3D Canvas node
> so is it possible to have this feature in the future release?
> 
> Thanks

From ambarish.rapte at oracle.com  Mon Oct 15 19:29:27 2018
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Mon, 15 Oct 2018 12:29:27 -0700 (PDT)
Subject: Fix proposal: boolean flag & public API for JDK-8204060 - Disable
 smoothing at javafx.scene.canvas.GraphicsContext.drawImage()
Message-ID: <1cc58dd3-69e4-4ef1-8990-0b2622bf09b0@default>

Hi All,

 

This email is for discussion regarding the fix https://bugs.openjdk.java.net/browse/JDK-8204060 .

 

Issue: 

Images drawn using javafx.scene.canvas .GraphicsContext::drawImage() always apply filtering to the image.

 

Solution:

javafx.scene.canvas.GraphicsContext should provide an option to enable and disable smoothing.

 

Proposal: 

Adding a Boolean flag & APIs to control smoothing.

 

Add a boolean flag to control smoothing
Add two public APIs

public void setImageSmoothing(boolean imageSmoothing) {} to enable or disable smoothing.
public boolean getImageSmoothing() {}

If image smoothing is true, images will be scaled using a higher quality filtering when transforming or scaling the source image to fit in the destination rectangle.
If image smoothing is false, images will be scaled without filtering (or by using a lower quality filtering) when transforming or scaling the source image to fit in the destination rectangle.

 

Please provide your comments on the proposal.

 

 

Regards,

Ambarish

From andrew at nmedia.net  Mon Oct 15 19:36:33 2018
From: andrew at nmedia.net (Andrew Munn)
Date: Mon, 15 Oct 2018 12:36:33 -0700 (PDT)
Subject: Java-FX 11. Missing toolkit?  Error initializing QuantumRenderer
Message-ID: <alpine.BSO.2.21.1810151224520.78448@nmedia.net>

I'm using x2go to connect to a session running the Mate window manager and 
seein this error.  Could it be related to a missing jfxrt.jar?  I don't 
see that jar under /opt/javafx-sdk-11

I'm starting my application with these:

--add-opens javafx.fxml/javafx.fxml=ALL-UNNAMED"
--illegal-access=permit"
--module-path /opt/javafx-sdk-11/lib"
--add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing"
--add-exports=javafx.base/com.sun.javafx.beans=ALL-UNNAMED"
--add-exports=javafx.base/com.sun.javafx.reflect=ALL-UNNAMED"
--add-exports=javafx.graphics/com.sun.javafx.util=ALL-UNNAMED"
--add-exports=javafx.graphics/com.sun.glass.utils=ALL-UNNAMED"
--add-exports=javafx.graphics/com.sun.javafx.tk=ALL-UNNAMED"
-Djdk.gtk.version=2"  (worth a try?)
-Dprism.verbose=true"
## add to classpath:
CP=$CP:/opt/javafx-sdk-11/lib/*


I'm not using the console but in case it matters, the video hardware is:
# dmesg|grep g200
[    5.129761] mgag200 0000:01:04.0: fb0: mgadrmfb frame buffer device
[    5.224550] [drm] Initialized mgag200 1.0.0 20110418 for 0000:01:04.0 on minor 0


java version "11" 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11+28)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)
Prism pipeline init order: es2 sw
Using Double Precision Marlin Rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
Prism pipeline name = com.sun.prism.es2.ES2Pipeline
GraphicsPipeline.createPipeline failed for com.sun.prism.es2.ES2Pipeline
java.lang.ClassNotFoundException: com.sun.prism.es2.ES2Pipeline
        at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
        at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:315)
        at 
javafx.graphics/com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:187)
        at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91)
        at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
        at java.base/java.lang.Thread.run(Thread.java:834)
*** Fallback to Prism SW pipeline
Prism pipeline name = com.sun.prism.sw.SWPipeline
GraphicsPipeline.createPipeline failed for com.sun.prism.sw.SWPipeline
java.lang.UnsatisfiedLinkError: no prism_sw in java.library.path: [., 
/usr/java/packages/lib, /usr/lib64, /lib64, /lib, /usr/lib]
        at 
java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660)
        at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829)
        at java.base/java.lang.System.loadLibrary(System.java:1867)
        at 
javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:150)
        at 
javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:52)
        at 
javafx.graphics/com.sun.prism.sw.SWPipeline.lambda$static$0(SWPipeline.java:42)
        at java.base/java.security.AccessController.doPrivileged(Native 
Method)
        at 
javafx.graphics/com.sun.prism.sw.SWPipeline.<clinit>(SWPipeline.java:41)
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:315)
        at 
javafx.graphics/com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:187)
        at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91)
        at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
        at java.base/java.lang.Thread.run(Thread.java:834)
Graphics Device initialization failed for :  es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing 
QuantumRenderer: no suitable pipeline found
        at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)
        at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222)
        at 
javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260)
        at 
javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
        at 
javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
        at 
javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
        at 
javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409)
        at 
javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363)
        at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
        at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at 
java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1051)
Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: 
no suitable pipeline found
        at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94)
        at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
        at java.base/java.lang.Thread.run(Thread.java:834)
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
        at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at 
java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1051)
Caused by: java.lang.RuntimeException: No toolkit found
        at 
javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272)
        at 
javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
        at 
javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
        at 
javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
        at 
javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409)
        at 
javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363)


From kevin.rushforth at oracle.com  Mon Oct 15 20:13:13 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 15 Oct 2018 13:13:13 -0700
Subject: Java-FX 11. Missing toolkit? Error initializing QuantumRenderer
In-Reply-To: <alpine.BSO.2.21.1810151224520.78448@nmedia.net>
References: <alpine.BSO.2.21.1810151224520.78448@nmedia.net>
Message-ID: <425f0df1-d8d2-641d-f02f-8f47294314c4@oracle.com>

There is no more jfxrt.jar as of JDK 9, so no, that isn't the problem. 
It looks like it can't load the native libraries. Two things to try to 
get more information:

1. Run with "-Dprism.verbose=true" and "-Djavafx.verbose=true" and see 
if that gives a better error message.

2. Check to see that the .so files are in "/opt/javafx-sdk-11/lib" and 
that you have the dependent libraries on your system. For example:

$ ldd /opt/javafx-sdk-11/lib/prism_es2.so

-- Kevin


On 10/15/2018 12:36 PM, Andrew Munn wrote:
> I'm using x2go to connect to a session running the Mate window manager and
> seein this error.  Could it be related to a missing jfxrt.jar?  I don't
> see that jar under /opt/javafx-sdk-11
>
> I'm starting my application with these:
>
> --add-opens javafx.fxml/javafx.fxml=ALL-UNNAMED"
> --illegal-access=permit"
> --module-path /opt/javafx-sdk-11/lib"
> --add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing"
> --add-exports=javafx.base/com.sun.javafx.beans=ALL-UNNAMED"
> --add-exports=javafx.base/com.sun.javafx.reflect=ALL-UNNAMED"
> --add-exports=javafx.graphics/com.sun.javafx.util=ALL-UNNAMED"
> --add-exports=javafx.graphics/com.sun.glass.utils=ALL-UNNAMED"
> --add-exports=javafx.graphics/com.sun.javafx.tk=ALL-UNNAMED"
> -Djdk.gtk.version=2"  (worth a try?)
> -Dprism.verbose=true"
> ## add to classpath:
> CP=$CP:/opt/javafx-sdk-11/lib/*
>
>
> I'm not using the console but in case it matters, the video hardware is:
> # dmesg|grep g200
> [    5.129761] mgag200 0000:01:04.0: fb0: mgadrmfb frame buffer device
> [    5.224550] [drm] Initialized mgag200 1.0.0 20110418 for 0000:01:04.0 on minor 0
>
>
> java version "11" 2018-09-25
> Java(TM) SE Runtime Environment 18.9 (build 11+28)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)
> Prism pipeline init order: es2 sw
> Using Double Precision Marlin Rasterizer
> Using dirty region optimizations
> Not using texture mask for primitives
> Not forcing power of 2 sizes for textures
> Using hardware CLAMP_TO_ZERO mode
> Opting in for HiDPI pixel scaling
> Prism pipeline name = com.sun.prism.es2.ES2Pipeline
> GraphicsPipeline.createPipeline failed for com.sun.prism.es2.ES2Pipeline
> java.lang.ClassNotFoundException: com.sun.prism.es2.ES2Pipeline
>          at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
>          at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
>          at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>          at java.base/java.lang.Class.forName0(Native Method)
>          at java.base/java.lang.Class.forName(Class.java:315)
>          at
> javafx.graphics/com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:187)
>          at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91)
>          at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
>          at java.base/java.lang.Thread.run(Thread.java:834)
> *** Fallback to Prism SW pipeline
> Prism pipeline name = com.sun.prism.sw.SWPipeline
> GraphicsPipeline.createPipeline failed for com.sun.prism.sw.SWPipeline
> java.lang.UnsatisfiedLinkError: no prism_sw in java.library.path: [.,
> /usr/java/packages/lib, /usr/lib64, /lib64, /lib, /usr/lib]
>          at
> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660)
>          at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829)
>          at java.base/java.lang.System.loadLibrary(System.java:1867)
>          at
> javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:150)
>          at
> javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:52)
>          at
> javafx.graphics/com.sun.prism.sw.SWPipeline.lambda$static$0(SWPipeline.java:42)
>          at java.base/java.security.AccessController.doPrivileged(Native
> Method)
>          at
> javafx.graphics/com.sun.prism.sw.SWPipeline.<clinit>(SWPipeline.java:41)
>          at java.base/java.lang.Class.forName0(Native Method)
>          at java.base/java.lang.Class.forName(Class.java:315)
>          at
> javafx.graphics/com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:187)
>          at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91)
>          at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
>          at java.base/java.lang.Thread.run(Thread.java:834)
> Graphics Device initialization failed for :  es2, sw
> Error initializing QuantumRenderer: no suitable pipeline found
> java.lang.RuntimeException: java.lang.RuntimeException: Error initializing
> QuantumRenderer: no suitable pipeline found
>          at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)
>          at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222)
>          at
> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260)
>          at
> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
>          at
> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
>          at
> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
>          at
> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409)
>          at
> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363)
>          at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>          at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>          at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>          at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>          at
> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1051)
> Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer:
> no suitable pipeline found
>          at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94)
>          at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
>          at java.base/java.lang.Thread.run(Thread.java:834)
> Exception in thread "main" java.lang.reflect.InvocationTargetException
>          at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>          at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>          at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>          at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>          at
> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1051)
> Caused by: java.lang.RuntimeException: No toolkit found
>          at
> javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272)
>          at
> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
>          at
> javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
>          at
> javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
>          at
> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409)
>          at
> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363)
>


From andrew at nmedia.net  Mon Oct 15 20:47:33 2018
From: andrew at nmedia.net (Andrew Munn)
Date: Mon, 15 Oct 2018 13:47:33 -0700 (PDT)
Subject: Java-FX 11. Missing toolkit? Error initializing
 QuantumRenderer
In-Reply-To: <425f0df1-d8d2-641d-f02f-8f47294314c4@oracle.com>
References: <alpine.BSO.2.21.1810151224520.78448@nmedia.net>
 <425f0df1-d8d2-641d-f02f-8f47294314c4@oracle.com>
Message-ID: <alpine.BSO.2.21.1810151346410.6157@nmedia.net>

Thanks Kevin.  It was missing .so files.  

On Mon, 15 Oct 2018, Kevin Rushforth wrote:

> There is no more jfxrt.jar as of JDK 9, so no, that isn't the problem. It
> looks like it can't load the native libraries. Two things to try to get more
> information:
> 
> 1. Run with "-Dprism.verbose=true" and "-Djavafx.verbose=true" and see if that
> gives a better error message.
> 
> 2. Check to see that the .so files are in "/opt/javafx-sdk-11/lib" and that
> you have the dependent libraries on your system. For example:
> 
> $ ldd /opt/javafx-sdk-11/lib/prism_es2.so
> 
> -- Kevin
> 
> 
> On 10/15/2018 12:36 PM, Andrew Munn wrote:
> > I'm using x2go to connect to a session running the Mate window manager and
> > seein this error.  Could it be related to a missing jfxrt.jar?  I don't
> > see that jar under /opt/javafx-sdk-11
> > 
> > I'm starting my application with these:
> > 
> > --add-opens javafx.fxml/javafx.fxml=ALL-UNNAMED"
> > --illegal-access=permit"
> > --module-path /opt/javafx-sdk-11/lib"
> > --add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing"
> > --add-exports=javafx.base/com.sun.javafx.beans=ALL-UNNAMED"
> > --add-exports=javafx.base/com.sun.javafx.reflect=ALL-UNNAMED"
> > --add-exports=javafx.graphics/com.sun.javafx.util=ALL-UNNAMED"
> > --add-exports=javafx.graphics/com.sun.glass.utils=ALL-UNNAMED"
> > --add-exports=javafx.graphics/com.sun.javafx.tk=ALL-UNNAMED"
> > -Djdk.gtk.version=2"  (worth a try?)
> > -Dprism.verbose=true"
> > ## add to classpath:
> > CP=$CP:/opt/javafx-sdk-11/lib/*
> > 
> > 
> > I'm not using the console but in case it matters, the video hardware is:
> > # dmesg|grep g200
> > [    5.129761] mgag200 0000:01:04.0: fb0: mgadrmfb frame buffer device
> > [    5.224550] [drm] Initialized mgag200 1.0.0 20110418 for 0000:01:04.0 on
> > minor 0
> > 
> > 
> > java version "11" 2018-09-25
> > Java(TM) SE Runtime Environment 18.9 (build 11+28)
> > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)
> > Prism pipeline init order: es2 sw
> > Using Double Precision Marlin Rasterizer
> > Using dirty region optimizations
> > Not using texture mask for primitives
> > Not forcing power of 2 sizes for textures
> > Using hardware CLAMP_TO_ZERO mode
> > Opting in for HiDPI pixel scaling
> > Prism pipeline name = com.sun.prism.es2.ES2Pipeline
> > GraphicsPipeline.createPipeline failed for com.sun.prism.es2.ES2Pipeline
> > java.lang.ClassNotFoundException: com.sun.prism.es2.ES2Pipeline
> >          at
> > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
> >          at
> > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> >          at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> >          at java.base/java.lang.Class.forName0(Native Method)
> >          at java.base/java.lang.Class.forName(Class.java:315)
> >          at
> > javafx.graphics/com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:187)
> >          at
> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91)
> >          at
> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
> >          at java.base/java.lang.Thread.run(Thread.java:834)
> > *** Fallback to Prism SW pipeline
> > Prism pipeline name = com.sun.prism.sw.SWPipeline
> > GraphicsPipeline.createPipeline failed for com.sun.prism.sw.SWPipeline
> > java.lang.UnsatisfiedLinkError: no prism_sw in java.library.path: [.,
> > /usr/java/packages/lib, /usr/lib64, /lib64, /lib, /usr/lib]
> >          at
> > java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660)
> >          at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829)
> >          at java.base/java.lang.System.loadLibrary(System.java:1867)
> >          at
> > javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:150)
> >          at
> > javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:52)
> >          at
> > javafx.graphics/com.sun.prism.sw.SWPipeline.lambda$static$0(SWPipeline.java:42)
> >          at java.base/java.security.AccessController.doPrivileged(Native
> > Method)
> >          at
> > javafx.graphics/com.sun.prism.sw.SWPipeline.<clinit>(SWPipeline.java:41)
> >          at java.base/java.lang.Class.forName0(Native Method)
> >          at java.base/java.lang.Class.forName(Class.java:315)
> >          at
> > javafx.graphics/com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:187)
> >          at
> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91)
> >          at
> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
> >          at java.base/java.lang.Thread.run(Thread.java:834)
> > Graphics Device initialization failed for :  es2, sw
> > Error initializing QuantumRenderer: no suitable pipeline found
> > java.lang.RuntimeException: java.lang.RuntimeException: Error initializing
> > QuantumRenderer: no suitable pipeline found
> >          at
> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)
> >          at
> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222)
> >          at
> > javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260)
> >          at
> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
> >          at
> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
> >          at
> > javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
> >          at
> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409)
> >          at
> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363)
> >          at
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> >          at
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >          at
> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >          at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> >          at
> > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1051)
> > Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer:
> > no suitable pipeline found
> >          at
> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94)
> >          at
> > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
> >          at java.base/java.lang.Thread.run(Thread.java:834)
> > Exception in thread "main" java.lang.reflect.InvocationTargetException
> >          at
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> >          at
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >          at
> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >          at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> >          at
> > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1051)
> > Caused by: java.lang.RuntimeException: No toolkit found
> >          at
> > javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272)
> >          at
> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
> >          at
> > javafx.graphics/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
> >          at
> > javafx.graphics/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
> >          at
> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409)
> >          at
> > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363)
> > 
> 

From youngty1997 at gmail.com  Mon Oct 15 20:53:04 2018
From: youngty1997 at gmail.com (Ty Young)
Date: Mon, 15 Oct 2018 15:53:04 -0500
Subject: JavaFX in-memory dynamic CSS file editing and applying
In-Reply-To: <578ea8e1-45e3-a89b-d276-995da1a231e9@oracle.com>
References: <4cbfcef6-b8cc-237e-f948-35699efd7429@gmail.com>
 <578ea8e1-45e3-a89b-d276-995da1a231e9@oracle.com>
Message-ID: <e584f9a5-a488-4925-7202-8f213351d406@gmail.com>


On 10/15/18 7:02 AM, David Grieve wrote:
> Just setStyle -fx-theme-header (etc.) on the root node.
>
>

That doesn't work, sadly. The actual FX CSS properties that utilize 
-fx-theme-header don't update after setting a new value.


> On 10/15/18 1:05 AM, Ty Young wrote:
>> Does JavaFX have an API for dynamically editing and applying CSS 
>> files in-memory? If not, would there be any possibility in one ever 
>> being made?
>>
>>
>> My reasoning for such an API is, instead of switching between 
>> completely separate CSS files and having to update each whenever I 
>> need to support a new component, I'd like the ability to just have 1 
>> CSS file and edit it's values in-memory and have it reflected in 
>> JavaFX as soon as the change is made. For example instead of changing 
>> the individual components themselves I'd like to get all of this:
>>
>>
>> *
>> {
>> ??? -fx-theme-header: #444444;
>> ??? -fx-theme-background: #3D3D3D;
>> ??? -fx-theme-background-alt: #2E2E2E;
>> ??? -fx-theme-selected: #F0544C;
>> ??? -fx-theme-label-text: #D2D2D2;
>> ??? -fx-theme-selectable-hover: #454545;
>> ??? -fx-theme-tab-close-color: -fx-theme-label-text;
>>
>> ??? -fx-highlight-fill: -fx-theme-selected;
>> }
>>
>>
>> and modify it via a JavaFX API to change it to something like:
>>
>>
>> *
>> {
>> ??? -fx-theme-header: #FFFFFF;
>> ??? -fx-theme-background: -fx-theme-header;
>> ??? -fx-theme-background-alt: #F2F2F2;
>> ??? -fx-theme-selected: #CBEAFF;
>> ??? -fx-theme-label-text: #333333;
>> ??? -fx-theme-selectable-hover: #E1E1E1;
>> ??? -fx-theme-tab-close-color: -fx-theme-label-text;
>>
>> ??? -fx-highlight-fill: -fx-theme-selected;
>> }
>>
>>
>> Since these are used throughout the CSS file, all the components that 
>> use these will be updated.
>>
>>
>>
>>
>>
>

From sproket at videotron.ca  Mon Oct 15 22:36:03 2018
From: sproket at videotron.ca (Dan Howard)
Date: Mon, 15 Oct 2018 18:36:03 -0400
Subject: Fix proposal: boolean flag & public API for JDK-8204060 - Disable
 smoothing at javafx.scene.canvas.GraphicsContext.drawImage()
In-Reply-To: <C8YygjJfiZTRAC8Yzgnigk@videotron.ca>
References: <C8YygjJfiZTRAC8Yzgnigk@videotron.ca>
Message-ID: <dc1b3700-7d95-876c-5d22-d4393eb40278@videotron.ca>

Shouldn't it be "is" rather than "get" for boolean?? Other than that, 
sounds good!


On 10/15/2018 3:29 PM, Ambarish Rapte wrote:
> Hi All,
>
>   
>
> This email is for discussion regarding the fix https://bugs.openjdk.java.net/browse/JDK-8204060 .
>
>   
>
> Issue:
>
> Images drawn using javafx.scene.canvas .GraphicsContext::drawImage() always apply filtering to the image.
>
>   
>
> Solution:
>
> javafx.scene.canvas.GraphicsContext should provide an option to enable and disable smoothing.
>
>   
>
> Proposal:
>
> Adding a Boolean flag & APIs to control smoothing.
>
>   
>
> Add a boolean flag to control smoothing
> Add two public APIs
>
> public void setImageSmoothing(boolean imageSmoothing) {} to enable or disable smoothing.
> public boolean getImageSmoothing() {}
>
> If image smoothing is true, images will be scaled using a higher quality filtering when transforming or scaling the source image to fit in the destination rectangle.
> If image smoothing is false, images will be scaled without filtering (or by using a lower quality filtering) when transforming or scaling the source image to fit in the destination rectangle.
>
>   
>
> Please provide your comments on the proposal.
>
>   
>
>   
>
> Regards,
>
> Ambarish
>


From nlisker at gmail.com  Mon Oct 15 22:52:37 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 16 Oct 2018 01:52:37 +0300
Subject: Fix proposal: boolean flag & public API for JDK-8204060 - Disable
 smoothing at javafx.scene.canvas.GraphicsContext.drawImage()
In-Reply-To: <1cc58dd3-69e4-4ef1-8990-0b2622bf09b0@default>
References: <1cc58dd3-69e4-4ef1-8990-0b2622bf09b0@default>
Message-ID: <CA+0ynh-3dWeoybBTS52EAgdyYp42X=_Z912x0m=heAQ6k9Z4Rw@mail.gmail.com>

>
> public void setImageSmoothing(boolean imageSmoothing) {} to enable or
> disable smoothing.


A bit of forward thinking here. Will there always be only 2 ways of doing
smoothing: "on" or "off"?
If there will be different algorithms for smoothing, will they be set
separately by "setSmoothingAlgorithm" a la strategy pattern?
Some similar cases use an enum, like CacheHint [1], or what I think should
have been an enum, like SceneAntialiasing [2] (which has another 2
commented-out settings). Is adding elements to an enum even allowed by
backwards compatibility?

[1]
https://openjfx.io/javadoc/11/javafx.graphics/javafx/scene/CacheHint.html
[2]
https://openjfx.io/javadoc/11/javafx.graphics/javafx/scene/SceneAntialiasing.html


On Mon, Oct 15, 2018 at 10:30 PM Ambarish Rapte <ambarish.rapte at oracle.com>
wrote:

> Hi All,
>
>
>
> This email is for discussion regarding the fix
> https://bugs.openjdk.java.net/browse/JDK-8204060 .
>
>
>
> Issue:
>
> Images drawn using javafx.scene.canvas .GraphicsContext::drawImage()
> always apply filtering to the image.
>
>
>
> Solution:
>
> javafx.scene.canvas.GraphicsContext should provide an option to enable and
> disable smoothing.
>
>
>
> Proposal:
>
> Adding a Boolean flag & APIs to control smoothing.
>
>
>
> Add a boolean flag to control smoothing
> Add two public APIs
>
> public void setImageSmoothing(boolean imageSmoothing) {} to enable or
> disable smoothing.
> public boolean getImageSmoothing() {}
>
> If image smoothing is true, images will be scaled using a higher quality
> filtering when transforming or scaling the source image to fit in the
> destination rectangle.
> If image smoothing is false, images will be scaled without filtering (or
> by using a lower quality filtering) when transforming or scaling the source
> image to fit in the destination rectangle.
>
>
>
> Please provide your comments on the proposal.
>
>
>
>
>
> Regards,
>
> Ambarish
>

From kevin.rushforth at oracle.com  Mon Oct 15 22:55:08 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 15 Oct 2018 15:55:08 -0700
Subject: Fix proposal: boolean flag & public API for JDK-8204060 - Disable
 smoothing at javafx.scene.canvas.GraphicsContext.drawImage()
In-Reply-To: <dc1b3700-7d95-876c-5d22-d4393eb40278@videotron.ca>
References: <C8YygjJfiZTRAC8Yzgnigk@videotron.ca>
 <dc1b3700-7d95-876c-5d22-d4393eb40278@videotron.ca>
Message-ID: <1095bd38-52b2-2cad-c495-cccbea6c7150@oracle.com>

Yes, it should be "isImageSmoothing", thanks for catching this!

This looks good to me to other than that.

The only other comment is that when you write the docs, make sure you 
indicate that this applies to drawImage calls, both in the docs of the 
new setImageSmooth method, and in the docs of the drawImage calls. 
Perhaps you post the proposed javadoc changes, since they will be needed 
for the CSR?

-- Kevin


On 10/15/2018 3:36 PM, Dan Howard wrote:
> Shouldn't it be "is" rather than "get" for boolean?? Other than that, 
> sounds good!
>
>
> On 10/15/2018 3:29 PM, Ambarish Rapte wrote:
>> Hi All,
>>
>>
>> This email is for discussion regarding the fix 
>> https://bugs.openjdk.java.net/browse/JDK-8204060 .
>>
>>
>> Issue:
>>
>> Images drawn using javafx.scene.canvas .GraphicsContext::drawImage() 
>> always apply filtering to the image.
>>
>>
>> Solution:
>>
>> javafx.scene.canvas.GraphicsContext should provide an option to 
>> enable and disable smoothing.
>>
>>
>> Proposal:
>>
>> Adding a Boolean flag & APIs to control smoothing.
>>
>>
>> Add a boolean flag to control smoothing
>> Add two public APIs
>>
>> public void setImageSmoothing(boolean imageSmoothing) {} to enable or 
>> disable smoothing.
>> public boolean getImageSmoothing() {}
>>
>> If image smoothing is true, images will be scaled using a higher 
>> quality filtering when transforming or scaling the source image to 
>> fit in the destination rectangle.
>> If image smoothing is false, images will be scaled without filtering 
>> (or by using a lower quality filtering) when transforming or scaling 
>> the source image to fit in the destination rectangle.
>>
>>
>> Please provide your comments on the proposal.
>>
>>
>>
>> Regards,
>>
>> Ambarish
>>
>


From kevin.rushforth at oracle.com  Mon Oct 15 22:58:58 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 15 Oct 2018 15:58:58 -0700
Subject: Fix proposal: boolean flag & public API for JDK-8204060 - Disable
 smoothing at javafx.scene.canvas.GraphicsContext.drawImage()
In-Reply-To: <CA+0ynh-3dWeoybBTS52EAgdyYp42X=_Z912x0m=heAQ6k9Z4Rw@mail.gmail.com>
References: <1cc58dd3-69e4-4ef1-8990-0b2622bf09b0@default>
 <CA+0ynh-3dWeoybBTS52EAgdyYp42X=_Z912x0m=heAQ6k9Z4Rw@mail.gmail.com>
Message-ID: <8b5a091f-3658-cd24-3d36-d33d609f6849@oracle.com>

A good question. In this case it is intended to match the 
ImageView::smooth property, which is a boolean. If there is a need later 
that more than one value is needed we would have to add a new enum 
attribute that would take effect if imageSmooth==true, but that would be 
the case for any of the smooth attributes for shapes as well.

-- Kevin


On 10/15/2018 3:52 PM, Nir Lisker wrote:
>> public void setImageSmoothing(boolean imageSmoothing) {} to enable or
>> disable smoothing.
>
> A bit of forward thinking here. Will there always be only 2 ways of doing
> smoothing: "on" or "off"?
> If there will be different algorithms for smoothing, will they be set
> separately by "setSmoothingAlgorithm" a la strategy pattern?
> Some similar cases use an enum, like CacheHint [1], or what I think should
> have been an enum, like SceneAntialiasing [2] (which has another 2
> commented-out settings). Is adding elements to an enum even allowed by
> backwards compatibility?
>
> [1]
> https://openjfx.io/javadoc/11/javafx.graphics/javafx/scene/CacheHint.html
> [2]
> https://openjfx.io/javadoc/11/javafx.graphics/javafx/scene/SceneAntialiasing.html
>
>
> On Mon, Oct 15, 2018 at 10:30 PM Ambarish Rapte <ambarish.rapte at oracle.com>
> wrote:
>
>> Hi All,
>>
>>
>>
>> This email is for discussion regarding the fix
>> https://bugs.openjdk.java.net/browse/JDK-8204060 .
>>
>>
>>
>> Issue:
>>
>> Images drawn using javafx.scene.canvas .GraphicsContext::drawImage()
>> always apply filtering to the image.
>>
>>
>>
>> Solution:
>>
>> javafx.scene.canvas.GraphicsContext should provide an option to enable and
>> disable smoothing.
>>
>>
>>
>> Proposal:
>>
>> Adding a Boolean flag & APIs to control smoothing.
>>
>>
>>
>> Add a boolean flag to control smoothing
>> Add two public APIs
>>
>> public void setImageSmoothing(boolean imageSmoothing) {} to enable or
>> disable smoothing.
>> public boolean getImageSmoothing() {}
>>
>> If image smoothing is true, images will be scaled using a higher quality
>> filtering when transforming or scaling the source image to fit in the
>> destination rectangle.
>> If image smoothing is false, images will be scaled without filtering (or
>> by using a lower quality filtering) when transforming or scaling the source
>> image to fit in the destination rectangle.
>>
>>
>>
>> Please provide your comments on the proposal.
>>
>>
>>
>>
>>
>> Regards,
>>
>> Ambarish
>>


From matthieu at brouillard.fr  Tue Oct 16 06:19:00 2018
From: matthieu at brouillard.fr (Matthieu BROUILLARD)
Date: Tue, 16 Oct 2018 08:19:00 +0200
Subject: JavaFX in-memory dynamic CSS file editing and applying
In-Reply-To: <e584f9a5-a488-4925-7202-8f213351d406@gmail.com>
References: <4cbfcef6-b8cc-237e-f948-35699efd7429@gmail.com>
 <578ea8e1-45e3-a89b-d276-995da1a231e9@oracle.com>
 <e584f9a5-a488-4925-7202-8f213351d406@gmail.com>
Message-ID: <CADsuJr8G6TOE_i9bdc133em7UC5Rs1Btbj-mq48drYKHjQ5kgQ@mail.gmail.com>

If what you want is to be able to test CSS changes on the fly on a running
javafx application during development for example; then you can also have a
look at CSSFX (https://github.com/McFoggy/cssfx).
If you do not want to setup CSSFX on your own, it has been integrated
inside Jonathan Giles "Scenic View" tool (
http://fxexperience.com/scenic-view/).
If you use a standard layout for your sources then the magic should apply;
if not you still can integrate CSSFX yourself to give it the good path to
your sources.

On Mon, Oct 15, 2018 at 10:54 PM Ty Young <youngty1997 at gmail.com> wrote:

>
> On 10/15/18 7:02 AM, David Grieve wrote:
> > Just setStyle -fx-theme-header (etc.) on the root node.
> >
> >
>
> That doesn't work, sadly. The actual FX CSS properties that utilize
> -fx-theme-header don't update after setting a new value.
>
>
> > On 10/15/18 1:05 AM, Ty Young wrote:
> >> Does JavaFX have an API for dynamically editing and applying CSS
> >> files in-memory? If not, would there be any possibility in one ever
> >> being made?
> >>
> >>
> >> My reasoning for such an API is, instead of switching between
> >> completely separate CSS files and having to update each whenever I
> >> need to support a new component, I'd like the ability to just have 1
> >> CSS file and edit it's values in-memory and have it reflected in
> >> JavaFX as soon as the change is made. For example instead of changing
> >> the individual components themselves I'd like to get all of this:
> >>
> >>
> >> *
> >> {
> >>     -fx-theme-header: #444444;
> >>     -fx-theme-background: #3D3D3D;
> >>     -fx-theme-background-alt: #2E2E2E;
> >>     -fx-theme-selected: #F0544C;
> >>     -fx-theme-label-text: #D2D2D2;
> >>     -fx-theme-selectable-hover: #454545;
> >>     -fx-theme-tab-close-color: -fx-theme-label-text;
> >>
> >>     -fx-highlight-fill: -fx-theme-selected;
> >> }
> >>
> >>
> >> and modify it via a JavaFX API to change it to something like:
> >>
> >>
> >> *
> >> {
> >>     -fx-theme-header: #FFFFFF;
> >>     -fx-theme-background: -fx-theme-header;
> >>     -fx-theme-background-alt: #F2F2F2;
> >>     -fx-theme-selected: #CBEAFF;
> >>     -fx-theme-label-text: #333333;
> >>     -fx-theme-selectable-hover: #E1E1E1;
> >>     -fx-theme-tab-close-color: -fx-theme-label-text;
> >>
> >>     -fx-highlight-fill: -fx-theme-selected;
> >> }
> >>
> >>
> >> Since these are used throughout the CSS file, all the components that
> >> use these will be updated.
> >>
> >>
> >>
> >>
> >>
> >
>

From kevin.rushforth at oracle.com  Tue Oct 16 16:38:22 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 16 Oct 2018 09:38:22 -0700
Subject: Changes for October 2018 CPU release synced into FX 8u-dev
Message-ID: <fdc5ff39-6f29-1bcf-0b74-14f3de7f9f83@oracle.com>

All,

As a heads-up I have synced the FX 8u192 changes from the just-released? 
October 2018 CPU release into 8u-dev. For those who are interested, here 
is the aggregate webrev for the fixes, for those who don't want to wade 
through all 66 changesets, most of which are merge or tagging changesets:

http://cr.openjdk.java.net/~kcr/cpu-1810-sync/8u-dev/webrev/

-- Kevin


From kevin.rushforth at oracle.com  Tue Oct 16 16:39:29 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 16 Oct 2018 09:39:29 -0700
Subject: [12] RFR: Request to sync October 2018 CPU changes into jfx-dev
Message-ID: <37584db3-bc89-937c-5877-f9464adde75f@oracle.com>

Johan and Phil,

I request approval to sync changes from to the just-released October 
2018 CPU release into jfx-dev. Here is the aggregate webrev for the fixes:

http://cr.openjdk.java.net/~kcr/cpu-1810-sync/jfx-dev/webrev/

-- Kevin


From johan.vos at gluonhq.com  Tue Oct 16 17:07:08 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 16 Oct 2018 19:07:08 +0200
Subject: [12] RFR: Request to sync October 2018 CPU changes into jfx-dev
In-Reply-To: <37584db3-bc89-937c-5877-f9464adde75f@oracle.com>
References: <37584db3-bc89-937c-5877-f9464adde75f@oracle.com>
Message-ID: <CABxFH2G0vPOpp1NynKsFQBkvzBVrZoiuofu+ZYx2XRehLS1f_A@mail.gmail.com>

+1

On Tue, Oct 16, 2018 at 6:39 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Johan and Phil,
>
> I request approval to sync changes from to the just-released October
> 2018 CPU release into jfx-dev. Here is the aggregate webrev for the fixes:
>
> http://cr.openjdk.java.net/~kcr/cpu-1810-sync/jfx-dev/webrev/
>
> -- Kevin
>
>

From kevin.rushforth at oracle.com  Tue Oct 16 17:24:38 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 16 Oct 2018 10:24:38 -0700
Subject: [11-dev] RFR: Request to sync October 2018 CPU changes into FX 11-dev
Message-ID: <c6c6754e-c163-3f92-eb34-12bc641ab40b@oracle.com>

By way of background, Johan and I have decided to use the existing 
11-dev repo to accumulated fixes for 11.x update releases. Fixes will 
need approval by either Johan or myself. We will send out the guidelines 
for approval to get fixes to 11-dev.

Johan: As an initial set of fixes, I request approval to sync the jfx-11 
backports from the just-released October 2018 CPU release into 11-dev. 
Here is the aggregate webrev for the fixes:

http://cr.openjdk.java.net/~kcr/cpu-1810-sync/11-dev/webrev/

This is identical to the just-posted jfx-dev webrev except for an 
additional fix to javapackager, since javapackager sources have been 
removed from the mainline jfx-dev repo.

-- Kevin


From philip.race at oracle.com  Tue Oct 16 17:32:51 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 16 Oct 2018 10:32:51 -0700
Subject: [12] RFR: Request to sync October 2018 CPU changes into jfx-dev
In-Reply-To: <37584db3-bc89-937c-5877-f9464adde75f@oracle.com>
References: <37584db3-bc89-937c-5877-f9464adde75f@oracle.com>
Message-ID: <aae46076-f044-7be3-af94-b9713a236770@oracle.com>

+1

-phil.

On 10/16/2018 09:39 AM, Kevin Rushforth wrote:
> Johan and Phil,
>
> I request approval to sync changes from to the just-released October 
> 2018 CPU release into jfx-dev. Here is the aggregate webrev for the 
> fixes:
>
> http://cr.openjdk.java.net/~kcr/cpu-1810-sync/jfx-dev/webrev/
>
> -- Kevin
>


From ambarish.rapte at oracle.com  Tue Oct 16 17:56:22 2018
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Tue, 16 Oct 2018 10:56:22 -0700 (PDT)
Subject: Fix proposal: boolean flag & public API for JDK-8204060 - Disable
 smoothing at javafx.scene.canvas.GraphicsContext.drawImage()
In-Reply-To: <1095bd38-52b2-2cad-c495-cccbea6c7150@oracle.com>
References: <C8YygjJfiZTRAC8Yzgnigk@videotron.ca>
 <dc1b3700-7d95-876c-5d22-d4393eb40278@videotron.ca>
 <1095bd38-52b2-2cad-c495-cccbea6c7150@oracle.com>
Message-ID: <e9f44d06-2fc3-4f4e-9d31-1977e723047d@default>

Hi All,

Below is documentation for the new APIs and a slight modification in the description of existing drawImage() APIs

New APIs setImageSmoothing() & isImageSmoothing()
*****************************************************************
setImageSmoothing () API
*****************************************************************

     /**
     * Sets the image smoothing flag.
     * The default value is {@code true}.<br>
     * Image smoothing is an <a href="#image-attr">Image attribute</a>
     * used to enable or disable image smoothing for
     * {@link #drawImage(javafx.scene.image.Image, double, double) drawImage(all forms)}
     * as specified in the <a href="#attr-ops-table">Rendering Attributes Table</a>.<br>
     * If image smoothing is {@code true}, images will be scaled using a higher
     * quality filtering when transforming or scaling the source image to fit
     * in the destination rectangle.<br>
     * If image smoothing is {@code false}, images will be scaled without filtering
     * (or by using a lower quality filtering) when transforming or scaling the
     * source image to fit in the destination rectangle.
     *
     * @since 12
     * @param imageSmoothing true to enable or false to disable smoothing.
     * @defaultValue {@code true}
     */
    public void setImageSmoothing(boolean imageSmoothing) {
    //......
    }

*****************************************************************
isImageSmoothing () API
*****************************************************************
    /**
     * Gets the current state of image smoothing.
     * The default value is {@code true}.
     *
     * @since 12
     * @return image smoothing state.
     */
    public boolean isImageSmoothing() {
	//......
	}

*****************************************************************
Image smoothing attribute shall be added to GraphicsContext class docs, in the table "List of Rendering Attributes".
And reference to new image smoothing attribute shall be mentioned in the description of drawImage()
*****************************************************************
      * <p>
      * This method will be affected by any of the
      * <a href="#comm-attr">global common</a>
+     * or <a href="#image-attr">image</a>
      * attributes as specified in the
      * <a href="#attr-ops-table">Rendering Attributes Table</a>.
      * </p>
*****************************************************************

Regards,
Ambarish

-----Original Message-----
From: Kevin Rushforth 
Sent: Tuesday, October 16, 2018 4:25 AM
To: Dan Howard <sproket at videotron.ca>; Ambarish Rapte <ambarish.rapte at oracle.com>; openjfx-dev at openjdk.java.net
Subject: Re: Fix proposal: boolean flag & public API for JDK-8204060 - Disable smoothing at javafx.scene.canvas.GraphicsContext.drawImage()

Yes, it should be "isImageSmoothing", thanks for catching this!

This looks good to me to other than that.

The only other comment is that when you write the docs, make sure you indicate that this applies to drawImage calls, both in the docs of the new setImageSmooth method, and in the docs of the drawImage calls. 
Perhaps you post the proposed javadoc changes, since they will be needed for the CSR?

-- Kevin


On 10/15/2018 3:36 PM, Dan Howard wrote:
> Shouldn't it be "is" rather than "get" for boolean?? Other than that, 
> sounds good!
>
>
> On 10/15/2018 3:29 PM, Ambarish Rapte wrote:
>> Hi All,
>>
>>
>> This email is for discussion regarding the fix
>> https://bugs.openjdk.java.net/browse/JDK-8204060 .
>>
>>
>> Issue:
>>
>> Images drawn using javafx.scene.canvas .GraphicsContext::drawImage() 
>> always apply filtering to the image.
>>
>>
>> Solution:
>>
>> javafx.scene.canvas.GraphicsContext should provide an option to 
>> enable and disable smoothing.
>>
>>
>> Proposal:
>>
>> Adding a Boolean flag & APIs to control smoothing.
>>
>>
>> Add a boolean flag to control smoothing Add two public APIs
>>
>> public void setImageSmoothing(boolean imageSmoothing) {} to enable or 
>> disable smoothing.
>> public boolean getImageSmoothing() {}
>>
>> If image smoothing is true, images will be scaled using a higher 
>> quality filtering when transforming or scaling the source image to 
>> fit in the destination rectangle.
>> If image smoothing is false, images will be scaled without filtering 
>> (or by using a lower quality filtering) when transforming or scaling 
>> the source image to fit in the destination rectangle.
>>
>>
>> Please provide your comments on the proposal.
>>
>>
>>
>> Regards,
>>
>> Ambarish
>>
>


From nlisker at gmail.com  Wed Oct 17 07:54:26 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 17 Oct 2018 10:54:26 +0300
Subject: Fix proposal: boolean flag & public API for JDK-8204060 - Disable
 smoothing at javafx.scene.canvas.GraphicsContext.drawImage()
In-Reply-To: <e9f44d06-2fc3-4f4e-9d31-1977e723047d@default>
References: <C8YygjJfiZTRAC8Yzgnigk@videotron.ca>
 <dc1b3700-7d95-876c-5d22-d4393eb40278@videotron.ca>
 <1095bd38-52b2-2cad-c495-cccbea6c7150@oracle.com>
 <e9f44d06-2fc3-4f4e-9d31-1977e723047d@default>
Message-ID: <CA+0ynh8s+qzC26UGdsTVtrH1a_FCqm5F4aLTZ_4Ku1aqE1yi5g@mail.gmail.com>

Hi Ambarish,

* I don't think you need to list the default value in the description if
you use @default (which I see other properties don't), for both get and set.
* "true" and "false" in @param need @code.
* I would choose either "image smoothing flag" (used in setter) or "image
smoothing state" (used in getter) consistently.

Thanks,
Nir


On Tue, Oct 16, 2018 at 8:57 PM Ambarish Rapte <ambarish.rapte at oracle.com>
wrote:

> Hi All,
>
> Below is documentation for the new APIs and a slight modification in the
> description of existing drawImage() APIs
>
> New APIs setImageSmoothing() & isImageSmoothing()
> *****************************************************************
> setImageSmoothing () API
> *****************************************************************
>
>      /**
>      * Sets the image smoothing flag.
>      * The default value is {@code true}.<br>
>      * Image smoothing is an <a href="#image-attr">Image attribute</a>
>      * used to enable or disable image smoothing for
>      * {@link #drawImage(javafx.scene.image.Image, double, double)
> drawImage(all forms)}
>      * as specified in the <a href="#attr-ops-table">Rendering Attributes
> Table</a>.<br>
>      * If image smoothing is {@code true}, images will be scaled using a
> higher
>      * quality filtering when transforming or scaling the source image to
> fit
>      * in the destination rectangle.<br>
>      * If image smoothing is {@code false}, images will be scaled without
> filtering
>      * (or by using a lower quality filtering) when transforming or
> scaling the
>      * source image to fit in the destination rectangle.
>      *
>      * @since 12
>      * @param imageSmoothing true to enable or false to disable smoothing.
>      * @defaultValue {@code true}
>      */
>     public void setImageSmoothing(boolean imageSmoothing) {
>     //......
>     }
>
> *****************************************************************
> isImageSmoothing () API
> *****************************************************************
>     /**
>      * Gets the current state of image smoothing.
>      * The default value is {@code true}.
>      *
>      * @since 12
>      * @return image smoothing state.
>      */
>     public boolean isImageSmoothing() {
>         //......
>         }
>
> *****************************************************************
> Image smoothing attribute shall be added to GraphicsContext class docs, in
> the table "List of Rendering Attributes".
> And reference to new image smoothing attribute shall be mentioned in the
> description of drawImage()
> *****************************************************************
>       * <p>
>       * This method will be affected by any of the
>       * <a href="#comm-attr">global common</a>
> +     * or <a href="#image-attr">image</a>
>       * attributes as specified in the
>       * <a href="#attr-ops-table">Rendering Attributes Table</a>.
>       * </p>
> *****************************************************************
>
> Regards,
> Ambarish
>
> -----Original Message-----
> From: Kevin Rushforth
> Sent: Tuesday, October 16, 2018 4:25 AM
> To: Dan Howard <sproket at videotron.ca>; Ambarish Rapte <
> ambarish.rapte at oracle.com>; openjfx-dev at openjdk.java.net
> Subject: Re: Fix proposal: boolean flag & public API for JDK-8204060 -
> Disable smoothing at javafx.scene.canvas.GraphicsContext.drawImage()
>
> Yes, it should be "isImageSmoothing", thanks for catching this!
>
> This looks good to me to other than that.
>
> The only other comment is that when you write the docs, make sure you
> indicate that this applies to drawImage calls, both in the docs of the new
> setImageSmooth method, and in the docs of the drawImage calls.
> Perhaps you post the proposed javadoc changes, since they will be needed
> for the CSR?
>
> -- Kevin
>
>
> On 10/15/2018 3:36 PM, Dan Howard wrote:
> > Shouldn't it be "is" rather than "get" for boolean?  Other than that,
> > sounds good!
> >
> >
> > On 10/15/2018 3:29 PM, Ambarish Rapte wrote:
> >> Hi All,
> >>
> >>
> >> This email is for discussion regarding the fix
> >> https://bugs.openjdk.java.net/browse/JDK-8204060 .
> >>
> >>
> >> Issue:
> >>
> >> Images drawn using javafx.scene.canvas .GraphicsContext::drawImage()
> >> always apply filtering to the image.
> >>
> >>
> >> Solution:
> >>
> >> javafx.scene.canvas.GraphicsContext should provide an option to
> >> enable and disable smoothing.
> >>
> >>
> >> Proposal:
> >>
> >> Adding a Boolean flag & APIs to control smoothing.
> >>
> >>
> >> Add a boolean flag to control smoothing Add two public APIs
> >>
> >> public void setImageSmoothing(boolean imageSmoothing) {} to enable or
> >> disable smoothing.
> >> public boolean getImageSmoothing() {}
> >>
> >> If image smoothing is true, images will be scaled using a higher
> >> quality filtering when transforming or scaling the source image to
> >> fit in the destination rectangle.
> >> If image smoothing is false, images will be scaled without filtering
> >> (or by using a lower quality filtering) when transforming or scaling
> >> the source image to fit in the destination rectangle.
> >>
> >>
> >> Please provide your comments on the proposal.
> >>
> >>
> >>
> >> Regards,
> >>
> >> Ambarish
> >>
> >
>
>

From ooo_saturn7 at mail.ru  Wed Oct 17 11:27:02 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Wed, 17 Oct 2018 14:27:02 +0300
Subject: =?UTF-8?B?aHR0cHM6Ly9idWdzLm9wZW5qZGsuamF2YS5uZXQvYnJvd3NlL0pESy04MDky?=
 =?UTF-8?B?Mjk3?=
Message-ID: <1539775622.883062289@f42.i.mail.ru>

Dear JavaFX developers

Seven years ago this issue?https://bugs.openjdk.java.net/browse/JDK-8092297 was opened 
suggesting to add serialization of javafx properties. Seven years have passed and we still
don't have it. I think you should not harry. We still can wait many years - 10, 20 etc. So that's ok.


-- 
Alex Sviridov

From johan.vos at gluonhq.com  Wed Oct 17 12:54:05 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 17 Oct 2018 14:54:05 +0200
Subject: [11-dev] RFR: Request to sync October 2018 CPU changes into FX
 11-dev
In-Reply-To: <c6c6754e-c163-3f92-eb34-12bc641ab40b@oracle.com>
References: <c6c6754e-c163-3f92-eb34-12bc641ab40b@oracle.com>
Message-ID: <CABxFH2G=wsKRe8b0SOc06mNTyM4tOQDHZ-gyNJXghzQ_qTmWVQ@mail.gmail.com>

+1

On Tue, Oct 16, 2018 at 7:24 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> By way of background, Johan and I have decided to use the existing
> 11-dev repo to accumulated fixes for 11.x update releases. Fixes will
> need approval by either Johan or myself. We will send out the guidelines
> for approval to get fixes to 11-dev.
>
> Johan: As an initial set of fixes, I request approval to sync the jfx-11
> backports from the just-released October 2018 CPU release into 11-dev.
> Here is the aggregate webrev for the fixes:
>
> http://cr.openjdk.java.net/~kcr/cpu-1810-sync/11-dev/webrev/
>
> This is identical to the just-posted jfx-dev webrev except for an
> additional fix to javapackager, since javapackager sources have been
> removed from the mainline jfx-dev repo.
>
> -- Kevin
>
>

From samir.hadzic.pro at gmail.com  Tue Oct 16 14:37:08 2018
From: samir.hadzic.pro at gmail.com (Sam')
Date: Tue, 16 Oct 2018 16:37:08 +0200
Subject: Review request for #151 Open VirtualFlow and other relating
Message-ID: <CAL3niDEMKzUO_9Qu3=r4nfxbM-488gE=ZnUFGjLK5ZT8aLYLew@mail.gmail.com>

I'm sorry if I'm created a new thread as I don't understand how mailing
lists work and I tend to avoid them as much as possible.

The JBS bug can be found here :
https://bugs.openjdk.java.net/browse/JDK-8207942

Sorry for the wrong one I initially posted.

1) I guess we are doing great work on the API thanks to "nlisker" awesome
involvement. We may need some help around some method naming in
TableViewSkinBase. The discussion can be found here :

https://github.com/javafxports/openjdk-jfx/pull/163#discussion_r225394151


2) I'm guessing the CSR stands for *Compatibility & Specification Review *
: https://openjdk.java.net/groups/csr/
I'm grateful to Eugene to fill it. If you need any help, don't hesitate to
ask.

I apologize for the trouble I make in Github or this mailing list as I have
never done such a thing before and I have not anticipated the work and the
process would be so big.

Thank you all

From wowselim at gmail.com  Wed Oct 17 17:22:33 2018
From: wowselim at gmail.com (Selim Dincer)
Date: Wed, 17 Oct 2018 19:22:33 +0200
Subject: Spring Initializr / vert.x starter like tool for javafx
Message-ID: <CANp2C1wh8ydyOnRnYqWXOOk9cJkTgP_xDb_apRtMxZuf8LiKng@mail.gmail.com>

Hey,

I was wondering if there are plans to have a small tool on the new
openjfx.io page similar to spring initializr
<https://start.spring.io/> or vert.x
starter <http://start.vertx.io/>. I noticed that there have been multiple
mails here regarding difficulties with project setups and this might be a
nice way to tackle these problems.
I think a tool like this would be quite helpful and more user friendly.
Additionally users might choose from frameworks they would like to add like
afterburner.fx, jfoenix, controlsfx etc.

Best regards,
Selim

From kevin.rushforth at oracle.com  Thu Oct 18 01:02:53 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 17 Oct 2018 18:02:53 -0700
Subject: Backport for https://bugs.openjdk.java.net/browse/JDK-8157913 to
 jdk8?
In-Reply-To: <50f7402f-93ca-0139-a561-f42696205cc2@gmail.com>
References: <50f7402f-93ca-0139-a561-f42696205cc2@gmail.com>
Message-ID: <0875e54a-a73f-3e59-fd86-643e94079fa7@oracle.com>

We hadn't planned to backport this, although it does look like a pretty 
serious problem.

-- Kevin


On 10/15/2018 6:29 AM, Robert Lichtenberger wrote:
> Is there a chance that the fix for 
> https://bugs.openjdk.java.net/browse/JDK-8157913 will be backported to 
> jdk8?
>
> It seems like a major error to me, if packaged applications don't 
> start and I have just been affected by this problem.
>
>
> Best regards,
>
> Robert Lichtenberger
>


From kevin.rushforth at oracle.com  Thu Oct 18 01:43:03 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 17 Oct 2018 18:43:03 -0700
Subject: Backport for https://bugs.openjdk.java.net/browse/JDK-8157913 to
 jdk8?
In-Reply-To: <0875e54a-a73f-3e59-fd86-643e94079fa7@oracle.com>
References: <50f7402f-93ca-0139-a561-f42696205cc2@gmail.com>
 <0875e54a-a73f-3e59-fd86-643e94079fa7@oracle.com>
Message-ID: <9b306ce9-83a0-37ca-5500-2239f857d765@oracle.com>

A closer look suggests it would be a good one to take, as long as there 
are no complications with the backport.

-- Kevin


On 10/17/2018 6:02 PM, Kevin Rushforth wrote:
> We hadn't planned to backport this, although it does look like a 
> pretty serious problem.
>
> -- Kevin
>
>
> On 10/15/2018 6:29 AM, Robert Lichtenberger wrote:
>> Is there a chance that the fix for 
>> https://bugs.openjdk.java.net/browse/JDK-8157913 will be backported 
>> to jdk8?
>>
>> It seems like a major error to me, if packaged applications don't 
>> start and I have just been affected by this problem.
>>
>>
>> Best regards,
>>
>> Robert Lichtenberger
>>
>


From r.lichtenberger at gmail.com  Thu Oct 18 05:38:36 2018
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Thu, 18 Oct 2018 07:38:36 +0200
Subject: Backport for https://bugs.openjdk.java.net/browse/JDK-8157913 to
 jdk8?
In-Reply-To: <9b306ce9-83a0-37ca-5500-2239f857d765@oracle.com>
References: <50f7402f-93ca-0139-a561-f42696205cc2@gmail.com>
 <0875e54a-a73f-3e59-fd86-643e94079fa7@oracle.com>
 <9b306ce9-83a0-37ca-5500-2239f857d765@oracle.com>
Message-ID: <2cab306f-cbf2-5217-4447-27ca88a9fdc8@gmail.com>

I was pretty shell-shocked when my applications no longer worked after 
some changes to my machine. And the console output wasn't exactly 
helpful either:

[rli at rlimbus ~]$ /opt/QA/current/QA
/home/rli/devel/sys/opt/QA/current/QA have received a copy of the GNU 
General Public License
# along with this program; if not, see <http://www.gnu.org/licenses/>.

# The format of this file is the same as for the corresponding file of
# the X Window System, which normally can be found in
#?????? /usr/lib/X11/locale/libpackager.so not found.


So a backport would be most welcome :-).


On 10/18/18 3:43 AM, Kevin Rushforth wrote:
> A closer look suggests it would be a good one to take, as long as 
> there are no complications with the backport.
>
> -- Kevin
>
>
> On 10/17/2018 6:02 PM, Kevin Rushforth wrote:
>> We hadn't planned to backport this, although it does look like a 
>> pretty serious problem.
>>
>> -- Kevin
>>
>>
>> On 10/15/2018 6:29 AM, Robert Lichtenberger wrote:
>>> Is there a chance that the fix for 
>>> https://bugs.openjdk.java.net/browse/JDK-8157913 will be backported 
>>> to jdk8?
>>>
>>> It seems like a major error to me, if packaged applications don't 
>>> start and I have just been affected by this problem.
>>>
>>>
>>> Best regards,
>>>
>>> Robert Lichtenberger
>>>
>>
>

From tom.schindl at bestsolution.at  Thu Oct 18 10:38:39 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Thu, 18 Oct 2018 12:38:39 +0200
Subject: Running JavaFX-11 applications from within Eclipse fails
Message-ID: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>

Hi,

I just wanted to make you aware that if you run a JavaFX-11 application
from within Eclipse it is very likely that you'll get an error like this.

> Exception in thread "WindowsNativeRunloopThread" java.lang.NoSuchMethodError: <init>
>     at javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native Method)
>     at javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
>     at javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
>     at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
>     at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>     at java.base/java.lang.Thread.run(Thread.java:834)
> Exception in thread "JavaFX Application Thread" java.lang.NullPointerException
>     at javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
>     at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
>     at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
>     at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
>     at javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
>     at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
>     at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>     at java.base/java.lang.Thread.run(Thread.java:834) 

Scary right! The reason is that JavaFX-11 is loading the wrong glass.dll
because Eclipse sets a java.library.path who also contains the
JVM-Directories used to launch your Eclipse IDE.

The simple work-around is to add
-Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
configuration.

Small tiny question on the side: Wouldn't it make sense to version our
.dlls somehow to match the release eg glass-11.dll?

Tom

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From kevin.rushforth at oracle.com  Thu Oct 18 12:15:15 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 18 Oct 2018 05:15:15 -0700
Subject: https://bugs.openjdk.java.net/browse/JDK-8092297
In-Reply-To: <1539775622.883062289@f42.i.mail.ru>
References: <1539775622.883062289@f42.i.mail.ru>
Message-ID: <9668c1a8-0c7b-85e7-495f-6e53014616b9@oracle.com>

As mentioned in a thread on openjfx-discuss, we do not plan to ever 
implement this. I have closed JDK-8092297 as "Won't fix".

-- Kevin

On 10/17/2018 4:27 AM, Alex Sviridov wrote:
> Dear JavaFX developers
>
> Seven years ago this issue?https://bugs.openjdk.java.net/browse/JDK-8092297 was opened
> suggesting to add serialization of javafx properties. Seven years have passed and we still
> don't have it. I think you should not harry. We still can wait many years - 10, 20 etc. So that's ok.
>
>


From nlisker at gmail.com  Thu Oct 18 14:10:33 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 18 Oct 2018 17:10:33 +0300
Subject: 3D Canvas Node?
In-Reply-To: <A6B107DA-7CA1-4A48-928F-4EB89F5A92C1@gmail.com>
References: <9312e331-8763-42a0-9999-7bbc59a3be52.chengen.zhao@whitewoodcity.com>
 <A6B107DA-7CA1-4A48-928F-4EB89F5A92C1@gmail.com>
Message-ID: <CA+0ynh83PYtg0T=QDcyDf9iDm+J8Q8LMniPU4zcJi-1RW==LiQ@mail.gmail.com>

Iv'e continued the discussion on openjfx-discuss [1]

[1]
http://mail.openjdk.java.net/pipermail/openjfx-discuss/2018-October/000049.html

On Mon, Oct 15, 2018 at 7:08 PM John-Val Rose <johnvalrose at gmail.com> wrote:

> I also believe that such a component would be highly beneficial & I myself
> have suggested it many times in the past.
>
> To Chengen Zhao, you may not be aware but there is a new mailing list
> where it may be more appropriate to ask this question.
>
> That list is openjfx-discuss at openjdk.java.net
>
> I hope this helps.
>
> Graciously,
>
> John-Val Rose
>
> > On 15 Oct 2018, at 12:32, Chengen Zhao <chengen.zhao at whitewoodcity.com>
> wrote:
> >
> > Hi:
> >
> > We are currently developing games by using JavaFX
> > one feature would be nice to have is 3D Canvas node
> > so is it possible to have this feature in the future release?
> >
> > Thanks
>

From amnojeeuw at gmail.com  Fri Oct 19 02:27:34 2018
From: amnojeeuw at gmail.com (Amno Jeeuw)
Date: Thu, 18 Oct 2018 22:27:34 -0400
Subject: No subject
Message-ID: <CAKX+xxEnFt7jk58r4z6A5teg_--u-SiWZXHzTHMmw7znyo_Drw@mail.gmail.com>

I have downloaded openjfx-11_windows-x64_bin-sdk.zip and unzipped it in
C:\Program Files\Java\jdk-11 and I have also placed openfx in the
C:\Program Files\Java\jdk-11\javafx-sdk-11 directory. Now I'd like to
configure eclipse to use this two j/sdk(s), but I have not been able to
find adequate information regarding this matter. Any suggestions?

*ArbolOne
Using Fire Fox and Thunderbird.
Developing for Android using Java, C/C++, HTM/CSS and SQLite as our
platform has been exciting and most rewarding.
[ ? ]*

From marcel.au at web.de  Fri Oct 19 06:41:56 2018
From: marcel.au at web.de (marcel Austenfeld)
Date: Fri, 19 Oct 2018 08:41:56 +0200
Subject: Aw:
In-Reply-To: <CAKX+xxEnFt7jk58r4z6A5teg_--u-SiWZXHzTHMmw7znyo_Drw@mail.gmail.com>
References: <CAKX+xxEnFt7jk58r4z6A5teg_--u-SiWZXHzTHMmw7znyo_Drw@mail.gmail.com>
Message-ID: <trinity-ca6fb418-c7f3-4b30-a4a7-1554eb602ce2-1539931316393@3c-app-webde-bs24>


From marcel.au at web.de  Fri Oct 19 06:43:06 2018
From: marcel.au at web.de (marcel Austenfeld)
Date: Fri, 19 Oct 2018 08:43:06 +0200
Subject: Aw:
In-Reply-To: <CAKX+xxEnFt7jk58r4z6A5teg_--u-SiWZXHzTHMmw7znyo_Drw@mail.gmail.com>
References: <CAKX+xxEnFt7jk58r4z6A5teg_--u-SiWZXHzTHMmw7znyo_Drw@mail.gmail.com>
Message-ID: <trinity-a847831d-9b2a-4494-a880-5ee939831d63-1539931386528@3c-app-webde-bs24>

Just add the OpenJDK to
?
Window->Preferences->Java->Installed JREs (you can make it the default)
?
See also: https://stackoverflow.com/questions/15099530/how-to-change-default-jre-for-all-eclipse-workspaces[https://deref-web-02.de/mail/client/-nLC318xNiM/dereferrer/?redirectUrl=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F15099530%2Fhow-to-change-default-jre-for-all-eclipse-workspaces]
?
To add Openjfx see this nice answer on StackOverflow:
?
https://stackoverflow.com/questions/52013505/how-do-i-use-javafx-11-in-eclipse[https://deref-web-02.de/mail/client/PwC97i2atSk/dereferrer/?redirectUrl=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F52013505%2Fhow-do-i-use-javafx-11-in-eclipse]
?
More information for OpenJFX and links can be found here:
?
https://openjfx.io/index.html[https://deref-web-02.de/mail/client/0g2G3LnK6CE/dereferrer/?redirectUrl=https%3A%2F%2Fopenjfx.io%2Findex.html]
?

Gesendet:?Freitag, 19. Oktober 2018 um 04:27 Uhr
Von:?"Amno Jeeuw" <amnojeeuw at gmail.com>
An:?openjfx-dev at openjdk.java.net
Betreff:?Kein Betreff
I have downloaded openjfx-11_windows-x64_bin-sdk.zip and unzipped it in
C:\Program Files\Java\jdk-11 and I have also placed openfx in the
C:\Program Files\Java\jdk-11\javafx-sdk-11 directory. Now I'd like to
configure eclipse to use this two j/sdk(s), but I have not been able to
find adequate information regarding this matter. Any suggestions?

*ArbolOne
Using Fire Fox and Thunderbird.
Developing for Android using Java, C/C++, HTM/CSS and SQLite as our
platform has been exciting and most rewarding.
[ ? ]*?
?

From nlisker at gmail.com  Fri Oct 19 07:30:44 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 19 Oct 2018 10:30:44 +0300
Subject: 
In-Reply-To: <CAKX+xxEnFt7jk58r4z6A5teg_--u-SiWZXHzTHMmw7znyo_Drw@mail.gmail.com>
References: <CAKX+xxEnFt7jk58r4z6A5teg_--u-SiWZXHzTHMmw7znyo_Drw@mail.gmail.com>
Message-ID: <CA+0ynh-cPFtbonU-nS1LFAfkkwP5aHXJq5hpORoKtzWOcmKY-w@mail.gmail.com>

Hi Amno,

I don't understand what "two j/sdk(s)" is. If you've unzipped the openjfx
SDK's, point to them in Eclipse in the Java Build Path of your project by
adding a library or external jars like you would any other dependency.

- Nir

On Fri, Oct 19, 2018 at 5:28 AM Amno Jeeuw <amnojeeuw at gmail.com> wrote:

> I have downloaded openjfx-11_windows-x64_bin-sdk.zip and unzipped it in
> C:\Program Files\Java\jdk-11 and I have also placed openfx in the
> C:\Program Files\Java\jdk-11\javafx-sdk-11 directory. Now I'd like to
> configure eclipse to use this two j/sdk(s), but I have not been able to
> find adequate information regarding this matter. Any suggestions?
>
> *ArbolOne
> Using Fire Fox and Thunderbird.
> Developing for Android using Java, C/C++, HTM/CSS and SQLite as our
> platform has been exciting and most rewarding.
> [ ? ]*
>

From carl at bekwam.com  Fri Oct 19 17:05:09 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Fri, 19 Oct 2018 13:05:09 -0400
Subject: Compiling with Visual Studio 2017
Message-ID: <000e01d467cd$e4a0b140$ade213c0$@bekwam.com>

Hi,

 

I'm trying to build 8.0-b132 for Windows with Visual Studio 2017.  I was
able to build the Java code successfully, but am getting a path error

 

13:00:54.444 [ERROR] [org.gradle.BuildExceptionReporter] Caused by:
java.io.IOException: Cannot run program "C:/cygwin64/VC/BIN/amd64/cl.exe"
(in directory "D:\hg\rt\modules\fxpackager"): CreateProcess error=2, The
system cannot find the file specified

 

This is my environment

 

export JAVA_HOME=D:/Java/open-jdk8u172-b11

export GRADLE_HOME=C:/gradle/gradle-1.8

export
PATH="/cygdrive/d/Java/open-jdk8u172-b11:/cygdrive/d/gradle/gradle-1.8/bin:$
PATH"

 

export VS150COMNTOOLS="C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Professional\\VC\\Auxiliary\\Build"

export MSVC_VER=14.15.26706

export WINSDK_DIR="C:/Program Files (x86)/Microsoft SDKs/Windows/v10.0A"

 

I tried replacing the win.gradle from the 8.0-b132 with the file from the
tip.  In that case, I got a "WINSDK_DIR" not defined error.

 

Does anyone build openjfx 8 with 2017 or is everyone using the older VS for
the backports?  DirectX gave me an error when I tried to install the 2010
SDK.  Are the DirectX APIs embedded in VS now?

 

Thanks,

Carl

 

 

 

 


From nlisker at gmail.com  Fri Oct 19 17:30:41 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 19 Oct 2018 20:30:41 +0300
Subject: Compiling with Visual Studio 2017
In-Reply-To: <000e01d467cd$e4a0b140$ade213c0$@bekwam.com>
References: <000e01d467cd$e4a0b140$ade213c0$@bekwam.com>
Message-ID: <CA+0ynh_uzVXBgm_0J9X=ztpGZtxJEaemQ7MwOWUhgHEUjbPsuQ@mail.gmail.com>

Hi Carl,

The instructions for building OpenJFX 8 are in the wiki [1], though I never
built this version myself.

Usually when "cl.exe" is not found it's because of a wrong MSVC_VER
variable value. In VS 2017, this file is located under
"VC\Tools\MSVC\<MSVC_VER>\bin" (there are 4 versions under this folder
tree). It could be that the MSVC_VER value does not match the folder name
in this path. I don't know why you're looking for it inside cygwin64, but,
again, I am unfamiliar with this build.

Also, the Gradle version needs to be 4.8, not 1.8.

Good luck,
Nir

[1] https://wiki.openjdk.java.net/pages/viewpage.action?pageId=40271889

On Fri, Oct 19, 2018 at 8:05 PM <carl at bekwam.com> wrote:

> Hi,
>
>
>
> I'm trying to build 8.0-b132 for Windows with Visual Studio 2017.  I was
> able to build the Java code successfully, but am getting a path error
>
>
>
> 13:00:54.444 [ERROR] [org.gradle.BuildExceptionReporter] Caused by:
> java.io.IOException: Cannot run program "C:/cygwin64/VC/BIN/amd64/cl.exe"
> (in directory "D:\hg\rt\modules\fxpackager"): CreateProcess error=2, The
> system cannot find the file specified
>
>
>
> This is my environment
>
>
>
> export JAVA_HOME=D:/Java/open-jdk8u172-b11
>
> export GRADLE_HOME=C:/gradle/gradle-1.8
>
> export
>
> PATH="/cygdrive/d/Java/open-jdk8u172-b11:/cygdrive/d/gradle/gradle-1.8/bin:$
> PATH"
>
>
>
> export VS150COMNTOOLS="C:\\Program Files (x86)\\Microsoft Visual
> Studio\\2017\\Professional\\VC\\Auxiliary\\Build"
>
> export MSVC_VER=14.15.26706
>
> export WINSDK_DIR="C:/Program Files (x86)/Microsoft SDKs/Windows/v10.0A"
>
>
>
> I tried replacing the win.gradle from the 8.0-b132 with the file from the
> tip.  In that case, I got a "WINSDK_DIR" not defined error.
>
>
>
> Does anyone build openjfx 8 with 2017 or is everyone using the older VS for
> the backports?  DirectX gave me an error when I tried to install the 2010
> SDK.  Are the DirectX APIs embedded in VS now?
>
>
>
> Thanks,
>
> Carl
>
>
>
>
>
>
>
>
>
>

From carl at bekwam.com  Fri Oct 19 17:46:34 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Fri, 19 Oct 2018 13:46:34 -0400
Subject: Compiling with Visual Studio 2017
In-Reply-To: <CA+0ynh_uzVXBgm_0J9X=ztpGZtxJEaemQ7MwOWUhgHEUjbPsuQ@mail.gmail.com>
References: <000e01d467cd$e4a0b140$ade213c0$@bekwam.com>
 <CA+0ynh_uzVXBgm_0J9X=ztpGZtxJEaemQ7MwOWUhgHEUjbPsuQ@mail.gmail.com>
Message-ID: <003e01d467d3$adaa5a50$08ff0ef0$@bekwam.com>

Hi,

 

Thanks for the reply.  I?m following both wiki pages on building the tip and the 8u versions.

 

For this tag (8.0-b132), I get the following error with Gradle 4, so I downgraded to 1.8.

 

> java.lang.String cannot be cast to org.gradle.api.artifacts.Configuration

 

I pulled the version 14.15.26706 from here.  It?s the only subfolder on my system.

 

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Redist\MSVC

 

-Carl

 

From: Nir Lisker <nlisker at gmail.com> 
Sent: Friday, October 19, 2018 1:31 PM
To: carl at bekwam.com
Cc: openjfx-dev at openjdk.java.net Mailing <openjfx-dev at openjdk.java.net>
Subject: Re: Compiling with Visual Studio 2017

 

Hi Carl,

 

The instructions for building OpenJFX 8 are in the wiki [1], though I never built this version myself.

 

Usually when "cl.exe" is not found it's because of a wrong MSVC_VER variable value. In VS 2017, this file is located under "VC\Tools\MSVC\<MSVC_VER>\bin" (there are 4 versions under this folder tree). It could be that the MSVC_VER value does not match the folder name in this path. I don't know why you're looking for it inside cygwin64, but, again, I am unfamiliar with this build.

 

Also, the Gradle version needs to be 4.8, not 1.8.

 

Good luck,

Nir

 

[1] https://wiki.openjdk.java.net/pages/viewpage.action?pageId=40271889

 

On Fri, Oct 19, 2018 at 8:05 PM <carl at bekwam.com <mailto:carl at bekwam.com> > wrote:

Hi,



I'm trying to build 8.0-b132 for Windows with Visual Studio 2017.  I was
able to build the Java code successfully, but am getting a path error



13:00:54.444 [ERROR] [org.gradle.BuildExceptionReporter] Caused by:
java.io.IOException: Cannot run program "C:/cygwin64/VC/BIN/amd64/cl.exe"
(in directory "D:\hg\rt\modules\fxpackager"): CreateProcess error=2, The
system cannot find the file specified



This is my environment



export JAVA_HOME=D:/Java/open-jdk8u172-b11

export GRADLE_HOME=C:/gradle/gradle-1.8

export
PATH="/cygdrive/d/Java/open-jdk8u172-b11:/cygdrive/d/gradle/gradle-1.8/bin:$
PATH"



export VS150COMNTOOLS="C:\\Program Files (x86)\\Microsoft <file://Microsoft>  Visual
Studio\\2017\\Professional\\VC\\Auxiliary\\Build"

export MSVC_VER=14.15.26706

export WINSDK_DIR="C:/Program Files (x86)/Microsoft SDKs/Windows/v10.0A"



I tried replacing the win.gradle from the 8.0-b132 with the file from the
tip.  In that case, I got a "WINSDK_DIR" not defined error.



Does anyone build openjfx 8 with 2017 or is everyone using the older VS for
the backports?  DirectX gave me an error when I tried to install the 2010
SDK.  Are the DirectX APIs embedded in VS now?



Thanks,

Carl











From kevin.rushforth at oracle.com  Fri Oct 19 18:38:53 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 19 Oct 2018 11:38:53 -0700
Subject: Compiling with Visual Studio 2017
In-Reply-To: <003e01d467d3$adaa5a50$08ff0ef0$@bekwam.com>
References: <000e01d467cd$e4a0b140$ade213c0$@bekwam.com>
 <CA+0ynh_uzVXBgm_0J9X=ztpGZtxJEaemQ7MwOWUhgHEUjbPsuQ@mail.gmail.com>
 <003e01d467d3$adaa5a50$08ff0ef0$@bekwam.com>
Message-ID: <3669525b-2cfa-4db5-90ed-ac70c6f5c2db@oracle.com>

Just so you are aware, the 8.0-b132 tag is for the JDK 8 GA release, 
which was shipped in March 2014. That one does require gradle 1.8, and 
also requires Visual Studio 2010 on Windows, since the changes to 
support VS 2017 went in much later. I'm not sure why you want to build 
something that old, but if you do, it might also require other changes 
that aren't well documented.

-- Kevin


On 10/19/2018 10:46 AM, carl at bekwam.com wrote:
> Hi,
>
>   
>
> Thanks for the reply.  I?m following both wiki pages on building the tip and the 8u versions.
>
>   
>
> For this tag (8.0-b132), I get the following error with Gradle 4, so I downgraded to 1.8.
>
>   
>
>> java.lang.String cannot be cast to org.gradle.api.artifacts.Configuration
>   
>
> I pulled the version 14.15.26706 from here.  It?s the only subfolder on my system.
>
>   
>
> C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Redist\MSVC
>
>   
>
> -Carl
>
>   
>
> From: Nir Lisker <nlisker at gmail.com>
> Sent: Friday, October 19, 2018 1:31 PM
> To: carl at bekwam.com
> Cc: openjfx-dev at openjdk.java.net Mailing <openjfx-dev at openjdk.java.net>
> Subject: Re: Compiling with Visual Studio 2017
>
>   
>
> Hi Carl,
>
>   
>
> The instructions for building OpenJFX 8 are in the wiki [1], though I never built this version myself.
>
>   
>
> Usually when "cl.exe" is not found it's because of a wrong MSVC_VER variable value. In VS 2017, this file is located under "VC\Tools\MSVC\<MSVC_VER>\bin" (there are 4 versions under this folder tree). It could be that the MSVC_VER value does not match the folder name in this path. I don't know why you're looking for it inside cygwin64, but, again, I am unfamiliar with this build.
>
>   
>
> Also, the Gradle version needs to be 4.8, not 1.8.
>
>   
>
> Good luck,
>
> Nir
>
>   
>
> [1] https://wiki.openjdk.java.net/pages/viewpage.action?pageId=40271889
>
>   
>
> On Fri, Oct 19, 2018 at 8:05 PM <carl at bekwam.com <mailto:carl at bekwam.com> > wrote:
>
> Hi,
>
>
>
> I'm trying to build 8.0-b132 for Windows with Visual Studio 2017.  I was
> able to build the Java code successfully, but am getting a path error
>
>
>
> 13:00:54.444 [ERROR] [org.gradle.BuildExceptionReporter] Caused by:
> java.io.IOException: Cannot run program "C:/cygwin64/VC/BIN/amd64/cl.exe"
> (in directory "D:\hg\rt\modules\fxpackager"): CreateProcess error=2, The
> system cannot find the file specified
>
>
>
> This is my environment
>
>
>
> export JAVA_HOME=D:/Java/open-jdk8u172-b11
>
> export GRADLE_HOME=C:/gradle/gradle-1.8
>
> export
> PATH="/cygdrive/d/Java/open-jdk8u172-b11:/cygdrive/d/gradle/gradle-1.8/bin:$
> PATH"
>
>
>
> export VS150COMNTOOLS="C:\\Program Files (x86)\\Microsoft <file://Microsoft>  Visual
> Studio\\2017\\Professional\\VC\\Auxiliary\\Build"
>
> export MSVC_VER=14.15.26706
>
> export WINSDK_DIR="C:/Program Files (x86)/Microsoft SDKs/Windows/v10.0A"
>
>
>
> I tried replacing the win.gradle from the 8.0-b132 with the file from the
> tip.  In that case, I got a "WINSDK_DIR" not defined error.
>
>
>
> Does anyone build openjfx 8 with 2017 or is everyone using the older VS for
> the backports?  DirectX gave me an error when I tried to install the 2010
> SDK.  Are the DirectX APIs embedded in VS now?
>
>
>
> Thanks,
>
> Carl
>
>
>
>
>
>
>
>
>
>


From kevin.rushforth at oracle.com  Fri Oct 19 21:18:22 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 19 Oct 2018 14:18:22 -0700
Subject: Updated code review policies posted on OpenJFX Project Wiki
Message-ID: <26fd168f-7b18-2eb5-e217-5580766e1621@oracle.com>

The updated code review policies that we discussed last spring are now 
posted on the OpenJFX Project Wiki [1]. For the most part, we have 
effectively been following these for the past several months. This will 
formalize the policies in a way that will be easier to point new 
contributors at. If any of you have any suggestions for making it easier 
to understand, please send them our way.

The executive summary is:

1. Recorded the fact that Johan and I are co-leads of the OpenJFX Project

2. Formalized the concept of a Reviewer role and recorded the initial 
list of Reviewers

3. Formalized the code review requirements:
* simple fixes: 1"R"eviewer
* higher-impact fixes: 2 reviewers (one of whom must be "R"eviewer)
* new features / API changes: discus proposed changes on this list, CSR 
review (including approval by a Lead) for API changes + 2 reviewers for 
implementation

4. Formalized the streamlined GitHub code review (as long as you 
complete all review steps, including RFR email to this list, prior to PR 
being merged, there is no need for a webrev or additional review to push 
it to HG jfx-dev repo)

I am working on an update to the GitHub CONTRIBUTING.md page [2] to 
align with these newly-formalized policies, primarily to help first time 
contributors, but also as a reminder for all contributors. I'll send a 
PR when ready (tomorrow or Monday).

-- Kevin

[1] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews
[2] 
https://github.com/javafxports/openjdk-jfx/blob/develop/.github/CONTRIBUTING.md


From amnojeeuw at gmail.com  Sat Oct 20 00:19:26 2018
From: amnojeeuw at gmail.com (Amno Jeeuw)
Date: Fri, 19 Oct 2018 20:19:26 -0400
Subject: 
In-Reply-To: <CA+0ynh-cPFtbonU-nS1LFAfkkwP5aHXJq5hpORoKtzWOcmKY-w@mail.gmail.com>
References: <CAKX+xxEnFt7jk58r4z6A5teg_--u-SiWZXHzTHMmw7znyo_Drw@mail.gmail.com>
 <CA+0ynh-cPFtbonU-nS1LFAfkkwP5aHXJq5hpORoKtzWOcmKY-w@mail.gmail.com>
Message-ID: <CAKX+xxFuqH+SdpBi_tDU6ZuZK3OkFjV9RfWJZ63W1cYNHtN_RA@mail.gmail.com>

Thanks everyone. I think I got it. Next step is to port the project from
Java 8 to Java 11, wish me luck ??


On Fri, Oct 19, 2018, 3:31 AM Nir Lisker, <nlisker at gmail.com> wrote:

> Hi Amno,
>
> I don't understand what "two j/sdk(s)" is. If you've unzipped the openjfx
> SDK's, point to them in Eclipse in the Java Build Path of your project by
> adding a library or external jars like you would any other dependency.
>
> - Nir
>
> On Fri, Oct 19, 2018 at 5:28 AM Amno Jeeuw <amnojeeuw at gmail.com> wrote:
>
>> I have downloaded openjfx-11_windows-x64_bin-sdk.zip and unzipped it in
>> C:\Program Files\Java\jdk-11 and I have also placed openfx in the
>> C:\Program Files\Java\jdk-11\javafx-sdk-11 directory. Now I'd like to
>> configure eclipse to use this two j/sdk(s), but I have not been able to
>> find adequate information regarding this matter. Any suggestions?
>>
>> *ArbolOne
>> Using Fire Fox and Thunderbird.
>> Developing for Android using Java, C/C++, HTM/CSS and SQLite as our
>> platform has been exciting and most rewarding.
>> [ ? ]*
>>
>

From carl at bekwam.com  Sat Oct 20 02:27:32 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Fri, 19 Oct 2018 22:27:32 -0400
Subject: Compiling OpenJFX 8
Message-ID: <002301d4681c$7504aa40$5f0dfec0$@bekwam.com>

Hi,

 

Kevin R. replied to an email I put to the list about compiling with Visual
Studio 2017.  I'm not very good with Mercurial and thought 8.0b132 was the
most current JavaFX 8.  What tag, branch, or repo would I use to compile the
version of JavaFX 8 closest to what just shipped in Oracle's JDK 1.8.0_191.

 

I'll probably make more headway with the current Microsoft tools and a more
recent version.

 

Thanks,

Carl

 


From Stephen.Fitch at oracle.com  Sat Oct 20 02:49:10 2018
From: Stephen.Fitch at oracle.com (Stephen Fitch)
Date: Fri, 19 Oct 2018 19:49:10 -0700
Subject: Compiling OpenJFX 8
In-Reply-To: <002301d4681c$7504aa40$5f0dfec0$@bekwam.com>
References: <002301d4681c$7504aa40$5f0dfec0$@bekwam.com>
Message-ID: <298047ca-2cf3-c687-dd09-5cf2423af917@oracle.com>

Hi Carl,

As FYI weare getting towards the end of a major effort to allow VS2017
to be usedto build JDK 8(inc. JavaFX).

We are about to carry out some internal (to Oracle) final build runs with
JavaFX/JDK 8 and VS2017.

I'd say we need another couple of weeks to run a few builds and knock down
anyremaining issues.

I suspect waitinghere might give you something saving you time in the
long run.

I'll take the AI to get back to the yourself and the alias with news.

With OC1 next week we need a little extra time...

Regards,

Stephen

On 10/19/18 19:27, carl at bekwam.com wrote:
> Hi,
>
>   
>
> Kevin R. replied to an email I put to the list about compiling with Visual
> Studio 2017.  I'm not very good with Mercurial and thought 8.0b132 was the
> most current JavaFX 8.  What tag, branch, or repo would I use to compile the
> version of JavaFX 8 closest to what just shipped in Oracle's JDK 1.8.0_191.
>
>   
>
> I'll probably make more headway with the current Microsoft tools and a more
> recent version.
>
>   
>
> Thanks,
>
> Carl
>
>   
>


From carl at bekwam.com  Sat Oct 20 03:00:54 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Fri, 19 Oct 2018 23:00:54 -0400
Subject: Compiling OpenJFX 8
In-Reply-To: <298047ca-2cf3-c687-dd09-5cf2423af917@oracle.com>
References: <002301d4681c$7504aa40$5f0dfec0$@bekwam.com>
 <298047ca-2cf3-c687-dd09-5cf2423af917@oracle.com>
Message-ID: <003601d46821$1e42c9d0$5ac85d70$@bekwam.com>

Thanks Stephen.  I?d be happy to be an early adopter/tester or to help with documentation and blog posts.  -Carl

 

From: Stephen Fitch <Stephen.Fitch at oracle.com> 
Sent: Friday, October 19, 2018 10:49 PM
To: carl at bekwam.com; openjfx-dev at openjdk.java.net
Subject: Re: Compiling OpenJFX 8

 

Hi Carl,

As FYI we are getting towards the end of a major effort to allow VS2017 
to be used to build JDK 8 (inc. JavaFX). 

We are about to carry out some internal (to Oracle) final build runs with
JavaFX/JDK 8 and VS2017.

I'd say we need another couple of weeks to run a few builds and knock down 
any remaining issues.

I suspect waiting here might give you something saving you time in the 
long run.

I'll take the AI to get back to the yourself and the alias with news.

With OC1 next week we need a little extra time...

Regards,

Stephen

On 10/19/18 19:27, carl at bekwam.com <mailto:carl at bekwam.com>  wrote:

Hi,
 
 
 
Kevin R. replied to an email I put to the list about compiling with Visual
Studio 2017.  I'm not very good with Mercurial and thought 8.0b132 was the
most current JavaFX 8.  What tag, branch, or repo would I use to compile the
version of JavaFX 8 closest to what just shipped in Oracle's JDK 1.8.0_191.
 
 
 
I'll probably make more headway with the current Microsoft tools and a more
recent version.
 
 
 
Thanks,
 
Carl
 
 
 

 


From kevin.rushforth at oracle.com  Sat Oct 20 11:42:31 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 20 Oct 2018 04:42:31 -0700
Subject: Compiling OpenJFX 8
In-Reply-To: <002301d4681c$7504aa40$5f0dfec0$@bekwam.com>
References: <002301d4681c$7504aa40$5f0dfec0$@bekwam.com>
Message-ID: <b32d655e-9908-79dc-c9c1-b8a86c48df3c@oracle.com>

If you want to build the latest 8u, you should clone this repo instead 
of jfx-dev:

http://hg.openjdk.java.net/openjfx/8u-dev/rt

The tip of that repo is the current development repo for 8u202. There 
are also tags for all of the 8uNNN releases, for example, the tag 
corresponding to the just-shipped 8u191 release is 8u191-b10.

-- Kevin


On 10/19/2018 7:27 PM, carl at bekwam.com wrote:
> Hi,
>
>   
>
> Kevin R. replied to an email I put to the list about compiling with Visual
> Studio 2017.  I'm not very good with Mercurial and thought 8.0b132 was the
> most current JavaFX 8.  What tag, branch, or repo would I use to compile the
> version of JavaFX 8 closest to what just shipped in Oracle's JDK 1.8.0_191.
>
>   
>
> I'll probably make more headway with the current Microsoft tools and a more
> recent version.
>
>   
>
> Thanks,
>
> Carl
>
>   
>


From kevin.rushforth at oracle.com  Sat Oct 20 11:52:06 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 20 Oct 2018 04:52:06 -0700
Subject: Compiling OpenJFX 8
In-Reply-To: <298047ca-2cf3-c687-dd09-5cf2423af917@oracle.com>
References: <002301d4681c$7504aa40$5f0dfec0$@bekwam.com>
 <298047ca-2cf3-c687-dd09-5cf2423af917@oracle.com>
Message-ID: <33991545-5b64-4742-2d09-210e78486354@oracle.com>

This is true for building the JDK 8u. I note that if all he is trying to 
do is build FX 8u, it already builds with VS 2017. The problem was he 
was building FX 8 GA when what he wanted was FX 8u191. I just sent a 
pointer.

-- Kevin


On 10/19/2018 7:49 PM, Stephen Fitch wrote:
> Hi Carl,
>
> As FYI weare getting towards the end of a major effort to allow VS2017
> to be usedto build JDK 8(inc. JavaFX).
>
> We are about to carry out some internal (to Oracle) final build runs with
> JavaFX/JDK 8 and VS2017.
>
> I'd say we need another couple of weeks to run a few builds and knock 
> down
> anyremaining issues.
>
> I suspect waitinghere might give you something saving you time in the
> long run.
>
> I'll take the AI to get back to the yourself and the alias with news.
>
> With OC1 next week we need a little extra time...
>
> Regards,
>
> Stephen
>
> On 10/19/18 19:27, carl at bekwam.com wrote:
>> Hi,
>>
>>
>> Kevin R. replied to an email I put to the list about compiling with 
>> Visual
>> Studio 2017.? I'm not very good with Mercurial and thought 8.0b132 
>> was the
>> most current JavaFX 8.? What tag, branch, or repo would I use to 
>> compile the
>> version of JavaFX 8 closest to what just shipped in Oracle's JDK 
>> 1.8.0_191.
>>
>>
>> I'll probably make more headway with the current Microsoft tools and 
>> a more
>> recent version.
>>
>>
>> Thanks,
>>
>> Carl
>>
>>
>


From nlisker at gmail.com  Sun Oct 21 09:35:19 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 21 Oct 2018 12:35:19 +0300
Subject: Running JavaFX-11 applications from within Eclipse fails
In-Reply-To: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
References: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
Message-ID: <CA+0ynh9Q9pFJEbXQGQHtyXaCVLwsvVtnmj=RkXKv9uMbyzsPug@mail.gmail.com>

Hi Tom,

Iv'e never gotten this error. How do you reproduce this?

- Nir

On Thu, Oct 18, 2018 at 1:39 PM Tom Schindl <tom.schindl at bestsolution.at>
wrote:

> Hi,
>
> I just wanted to make you aware that if you run a JavaFX-11 application
> from within Eclipse it is very likely that you'll get an error like this.
>
> > Exception in thread "WindowsNativeRunloopThread"
> java.lang.NoSuchMethodError: <init>
> >     at
> javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native
> Method)
> >     at
> javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
> >     at
> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
> >     at
> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
> >     at
> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
> >     at java.base/java.lang.Thread.run(Thread.java:834)
> > Exception in thread "JavaFX Application Thread"
> java.lang.NullPointerException
> >     at
> javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
> >     at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
> >     at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
> >     at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
> >     at
> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
> >     at
> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
> >     at
> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
> >     at java.base/java.lang.Thread.run(Thread.java:834)
>
> Scary right! The reason is that JavaFX-11 is loading the wrong glass.dll
> because Eclipse sets a java.library.path who also contains the
> JVM-Directories used to launch your Eclipse IDE.
>
> The simple work-around is to add
> -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
> configuration.
>
> Small tiny question on the side: Wouldn't it make sense to version our
> .dlls somehow to match the release eg glass-11.dll?
>
> Tom
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

From nlisker at gmail.com  Sun Oct 21 10:05:43 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 21 Oct 2018 13:05:43 +0300
Subject: Updated code review policies posted on OpenJFX Project Wiki
In-Reply-To: <26fd168f-7b18-2eb5-e217-5580766e1621@oracle.com>
References: <26fd168f-7b18-2eb5-e217-5580766e1621@oracle.com>
Message-ID: <CA+0ynh93RYx9T+gJgCsVUhOAZVLtwku3PE-+jC-KgCpnXPpm-w@mail.gmail.com>

Hi Kevin,

I suggest to add an "areas of expertise" (modules or JBS components) to the
list of reviewers on the Code Reviews page, at least for active Reviewers,
similarly to how it is done on the Code Ownership page.
It doesn't need to have a formal function (I brought up that idea during
the spring discussion), but would help to know who to consult with when
working on some part of OpenJFX.

- Nir

On Sat, Oct 20, 2018 at 12:18 AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> The updated code review policies that we discussed last spring are now
> posted on the OpenJFX Project Wiki [1]. For the most part, we have
> effectively been following these for the past several months. This will
> formalize the policies in a way that will be easier to point new
> contributors at. If any of you have any suggestions for making it easier
> to understand, please send them our way.
>
> The executive summary is:
>
> 1. Recorded the fact that Johan and I are co-leads of the OpenJFX Project
>
> 2. Formalized the concept of a Reviewer role and recorded the initial
> list of Reviewers
>
> 3. Formalized the code review requirements:
> * simple fixes: 1"R"eviewer
> * higher-impact fixes: 2 reviewers (one of whom must be "R"eviewer)
> * new features / API changes: discus proposed changes on this list, CSR
> review (including approval by a Lead) for API changes + 2 reviewers for
> implementation
>
> 4. Formalized the streamlined GitHub code review (as long as you
> complete all review steps, including RFR email to this list, prior to PR
> being merged, there is no need for a webrev or additional review to push
> it to HG jfx-dev repo)
>
> I am working on an update to the GitHub CONTRIBUTING.md page [2] to
> align with these newly-formalized policies, primarily to help first time
> contributors, but also as a reminder for all contributors. I'll send a
> PR when ready (tomorrow or Monday).
>
> -- Kevin
>
> [1] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews
> [2]
>
> https://github.com/javafxports/openjdk-jfx/blob/develop/.github/CONTRIBUTING.md
>
>

From tom.schindl at bestsolution.at  Sun Oct 21 17:38:34 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Sun, 21 Oct 2018 19:38:34 +0200
Subject: Running JavaFX-11 applications from within Eclipse fails
In-Reply-To: <CA+0ynh9Q9pFJEbXQGQHtyXaCVLwsvVtnmj=RkXKv9uMbyzsPug@mail.gmail.com>
References: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
 <CA+0ynh9Q9pFJEbXQGQHtyXaCVLwsvVtnmj=RkXKv9uMbyzsPug@mail.gmail.com>
Message-ID: <006a8869-3f3e-19eb-d98d-b29b104569f2@bestsolution.at>

Well:
- Launch Eclipse 2018-09 with Orcale-Java-8
- Create a maven-enabled project (I think this is important because if
  you launch with the FX-SDK on the command line you won't run into
  this)
- Boom

Tom

On 21.10.18 11:35, Nir Lisker wrote:
> Hi Tom,
> 
> Iv'e never gotten this error. How do you reproduce this?
> 
> - Nir
> 
> On Thu, Oct 18, 2018 at 1:39 PM Tom Schindl <tom.schindl at bestsolution.at
> <mailto:tom.schindl at bestsolution.at>> wrote:
> 
>     Hi,
> 
>     I just wanted to make you aware that if you run a JavaFX-11 application
>     from within Eclipse it is very likely that you'll get an error like
>     this.
> 
>     > Exception in thread "WindowsNativeRunloopThread"
>     java.lang.NoSuchMethodError: <init>
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native
>     Method)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>     Method)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>     >? ? ?at java.base/java.lang.Thread.run(Thread.java:834)
>     > Exception in thread "JavaFX Application Thread"
>     java.lang.NullPointerException
>     >? ? ?at
>     javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
>     >? ? ?at
>     javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
>     >? ? ?at
>     javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
>     >? ? ?at
>     javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>     Method)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>     >? ? ?at java.base/java.lang.Thread.run(Thread.java:834)
> 
>     Scary right! The reason is that JavaFX-11 is loading the wrong glass.dll
>     because Eclipse sets a java.library.path who also contains the
>     JVM-Directories used to launch your Eclipse IDE.
> 
>     The simple work-around is to add
>     -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
>     configuration.
> 
>     Small tiny question on the side: Wouldn't it make sense to version our
>     .dlls somehow to match the release eg glass-11.dll?
> 
>     Tom
> 
>     -- 
>     Tom Schindl, CTO
>     BestSolution.at EDV Systemhaus GmbH
>     Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>     Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From johan.vos at gluonhq.com  Sun Oct 21 17:45:58 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Sun, 21 Oct 2018 10:45:58 -0700
Subject: Running JavaFX-11 applications from within Eclipse fails
In-Reply-To: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
References: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
Message-ID: <CABxFH2HdykTWPoRcuWsLK25P-a5tc3JTREbDh6f9X1TRnCEU+w@mail.gmail.com>

Hi Tom,

Nice workaround, but what do you think needs to be done to fix it? Can the
java.library.path somehow be changed in a plugin or so?
Renaming the native libraries in JavaFX would probably solve this, but that
seems the wrong solution to me.

- Johan

On Thu, Oct 18, 2018 at 3:39 PM Tom Schindl <tom.schindl at bestsolution.at>
wrote:

> Hi,
>
> I just wanted to make you aware that if you run a JavaFX-11 application
> from within Eclipse it is very likely that you'll get an error like this.
>
> > Exception in thread "WindowsNativeRunloopThread"
> java.lang.NoSuchMethodError: <init>
> >     at
> javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native
> Method)
> >     at
> javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
> >     at
> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
> >     at
> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
> >     at
> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
> >     at java.base/java.lang.Thread.run(Thread.java:834)
> > Exception in thread "JavaFX Application Thread"
> java.lang.NullPointerException
> >     at
> javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
> >     at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
> >     at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
> >     at
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
> >     at
> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
> >     at
> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
> >     at
> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
> >     at java.base/java.lang.Thread.run(Thread.java:834)
>
> Scary right! The reason is that JavaFX-11 is loading the wrong glass.dll
> because Eclipse sets a java.library.path who also contains the
> JVM-Directories used to launch your Eclipse IDE.
>
> The simple work-around is to add
> -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
> configuration.
>
> Small tiny question on the side: Wouldn't it make sense to version our
> .dlls somehow to match the release eg glass-11.dll?
>
> Tom
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

From tom.schindl at bestsolution.at  Sun Oct 21 17:55:53 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Sun, 21 Oct 2018 19:55:53 +0200
Subject: Running JavaFX-11 applications from within Eclipse fails
In-Reply-To: <CABxFH2HdykTWPoRcuWsLK25P-a5tc3JTREbDh6f9X1TRnCEU+w@mail.gmail.com>
References: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
 <CABxFH2HdykTWPoRcuWsLK25P-a5tc3JTREbDh6f9X1TRnCEU+w@mail.gmail.com>
Message-ID: <75bf38a3-8ee6-340c-4d07-7f480ea787db@bestsolution.at>

Well fixing the bug in Eclipse is the right way to address this ;-) Once
I have time I'll provide a patch.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=540247

Tom

On 21.10.18 19:45, Johan Vos wrote:
> Hi Tom,
> 
> Nice workaround, but what do you think needs to be done to fix it? Can
> the java.library.path somehow be changed in a plugin or so?
> Renaming the native libraries in JavaFX would probably solve this, but
> that seems the wrong solution to me.
> 
> - Johan
> 
> On Thu, Oct 18, 2018 at 3:39 PM Tom Schindl <tom.schindl at bestsolution.at
> <mailto:tom.schindl at bestsolution.at>> wrote:
> 
>     Hi,
> 
>     I just wanted to make you aware that if you run a JavaFX-11 application
>     from within Eclipse it is very likely that you'll get an error like
>     this.
> 
>     > Exception in thread "WindowsNativeRunloopThread"
>     java.lang.NoSuchMethodError: <init>
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native
>     Method)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>     Method)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>     >? ? ?at java.base/java.lang.Thread.run(Thread.java:834)
>     > Exception in thread "JavaFX Application Thread"
>     java.lang.NullPointerException
>     >? ? ?at
>     javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
>     >? ? ?at
>     javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
>     >? ? ?at
>     javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
>     >? ? ?at
>     javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>     Method)
>     >? ? ?at
>     javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>     >? ? ?at java.base/java.lang.Thread.run(Thread.java:834)
> 
>     Scary right! The reason is that JavaFX-11 is loading the wrong glass.dll
>     because Eclipse sets a java.library.path who also contains the
>     JVM-Directories used to launch your Eclipse IDE.
> 
>     The simple work-around is to add
>     -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
>     configuration.
> 
>     Small tiny question on the side: Wouldn't it make sense to version our
>     .dlls somehow to match the release eg glass-11.dll?
> 
>     Tom
> 
>     -- 
>     Tom Schindl, CTO
>     BestSolution.at EDV Systemhaus GmbH
>     Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>     Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From johan.vos at gluonhq.com  Sun Oct 21 18:35:06 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Sun, 21 Oct 2018 11:35:06 -0700
Subject: Running JavaFX-11 applications from within Eclipse fails
In-Reply-To: <75bf38a3-8ee6-340c-4d07-7f480ea787db@bestsolution.at>
References: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
 <CABxFH2HdykTWPoRcuWsLK25P-a5tc3JTREbDh6f9X1TRnCEU+w@mail.gmail.com>
 <75bf38a3-8ee6-340c-4d07-7f480ea787db@bestsolution.at>
Message-ID: <CABxFH2H81c9+HNf8n5okFvnb6=Yt5JPgoZjxQ9YxoL+rG3-3ww@mail.gmail.com>

Thanks, that was what I was hoping for but didn't dare to ask :)

- Johan

On Sun, Oct 21, 2018 at 8:06 PM Tom Schindl <tom.schindl at bestsolution.at>
wrote:

> Well fixing the bug in Eclipse is the right way to address this ;-) Once
> I have time I'll provide a patch.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=540247
>
> Tom
>
> On 21.10.18 19:45, Johan Vos wrote:
> > Hi Tom,
> >
> > Nice workaround, but what do you think needs to be done to fix it? Can
> > the java.library.path somehow be changed in a plugin or so?
> > Renaming the native libraries in JavaFX would probably solve this, but
> > that seems the wrong solution to me.
> >
> > - Johan
> >
> > On Thu, Oct 18, 2018 at 3:39 PM Tom Schindl <tom.schindl at bestsolution.at
> > <mailto:tom.schindl at bestsolution.at>> wrote:
> >
> >     Hi,
> >
> >     I just wanted to make you aware that if you run a JavaFX-11
> application
> >     from within Eclipse it is very likely that you'll get an error like
> >     this.
> >
> >     > Exception in thread "WindowsNativeRunloopThread"
> >     java.lang.NoSuchMethodError: <init>
> >     >     at
> >
>  javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native
> >     Method)
> >     >     at
> >     javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
> >     >     at
> >
>  javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
> >     >     at
> >     javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
> >     Method)
> >     >     at
> >
>  javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
> >     >     at java.base/java.lang.Thread.run(Thread.java:834)
> >     > Exception in thread "JavaFX Application Thread"
> >     java.lang.NullPointerException
> >     >     at
> >
>  javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
> >     >     at
> >
>  javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
> >     >     at
> >
>  javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
> >     >     at
> >
>  javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
> >     >     at
> >
>  javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
> >     >     at
> >     javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
> >     Method)
> >     >     at
> >
>  javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
> >     >     at java.base/java.lang.Thread.run(Thread.java:834)
> >
> >     Scary right! The reason is that JavaFX-11 is loading the wrong
> glass.dll
> >     because Eclipse sets a java.library.path who also contains the
> >     JVM-Directories used to launch your Eclipse IDE.
> >
> >     The simple work-around is to add
> >     -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
> >     configuration.
> >
> >     Small tiny question on the side: Wouldn't it make sense to version
> our <https://maps.google.com/?q=sense+to+version+our&entry=gmail&source=g>
> >     .dlls somehow to match the release eg glass-11.dll?
> >
> >     Tom
> >
> >     --
> >     Tom Schindl, CTO
> >     BestSolution.at EDV Systemhaus GmbH
> >     Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> >     Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> >
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

From nlisker at gmail.com  Sun Oct 21 19:15:23 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 21 Oct 2018 22:15:23 +0300
Subject: Running JavaFX-11 applications from within Eclipse fails
In-Reply-To: <006a8869-3f3e-19eb-d98d-b29b104569f2@bestsolution.at>
References: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
 <CA+0ynh9Q9pFJEbXQGQHtyXaCVLwsvVtnmj=RkXKv9uMbyzsPug@mail.gmail.com>
 <006a8869-3f3e-19eb-d98d-b29b104569f2@bestsolution.at>
Message-ID: <CA+0ynh-1U5aR6L-oDR1JJrtTjTkGka3XDbvE9UYNFVTzsx5RJA@mail.gmail.com>

Ah, I didn't realize you were talking about Java 8.

On Sun, Oct 21, 2018 at 10:09 PM Tom Schindl <tom.schindl at bestsolution.at>
wrote:

> Well:
> - Launch Eclipse 2018-09 with Orcale-Java-8
> - Create a maven-enabled project (I think this is important because if
>   you launch with the FX-SDK on the command line you won't run into
>   this)
> - Boom
>
> Tom
>
> On 21.10.18 11:35, Nir Lisker wrote:
> > Hi Tom,
> >
> > Iv'e never gotten this error. How do you reproduce this?
> >
> > - Nir
> >
> > On Thu, Oct 18, 2018 at 1:39 PM Tom Schindl <tom.schindl at bestsolution.at
> > <mailto:tom.schindl at bestsolution.at>> wrote:
> >
> >     Hi,
> >
> >     I just wanted to make you aware that if you run a JavaFX-11
> application
> >     from within Eclipse it is very likely that you'll get an error like
> >     this.
> >
> >     > Exception in thread "WindowsNativeRunloopThread"
> >     java.lang.NoSuchMethodError: <init>
> >     >     at
> >
>  javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native
> >     Method)
> >     >     at
> >     javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
> >     >     at
> >
>  javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
> >     >     at
> >     javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
> >     Method)
> >     >     at
> >
>  javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
> >     >     at java.base/java.lang.Thread.run(Thread.java:834)
> >     > Exception in thread "JavaFX Application Thread"
> >     java.lang.NullPointerException
> >     >     at
> >
>  javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
> >     >     at
> >
>  javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
> >     >     at
> >
>  javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
> >     >     at
> >
>  javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
> >     >     at
> >
>  javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
> >     >     at
> >     javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
> >     Method)
> >     >     at
> >
>  javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
> >     >     at java.base/java.lang.Thread.run(Thread.java:834)
> >
> >     Scary right! The reason is that JavaFX-11 is loading the wrong
> glass.dll
> >     because Eclipse sets a java.library.path who also contains the
> >     JVM-Directories used to launch your Eclipse IDE.
> >
> >     The simple work-around is to add
> >     -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
> >     configuration.
> >
> >     Small tiny question on the side: Wouldn't it make sense to version
> our
> >     .dlls somehow to match the release eg glass-11.dll?
> >
> >     Tom
> >
> >     --
> >     Tom Schindl, CTO
> >     BestSolution.at EDV Systemhaus GmbH
> >     Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> >     Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> >
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

From nlisker at gmail.com  Sun Oct 21 19:49:01 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 21 Oct 2018 22:49:01 +0300
Subject: Review Request: JDK-8212728: Update the Eclipse classpath file for
 the Swing module
Message-ID: <CA+0ynh8+2i7T_JUgk6YSvWjX4Bj_eMyo2p5HDZh1=aJ7erbWUQ@mail.gmail.com>

Hi,

Please review the simple fix for:

https://bugs.openjdk.java.net/browse/JDK-8212728
http://cr.openjdk.java.net/~nlisker/8212728/webrev.00/

Thanks,
Nir

From tom.schindl at bestsolution.at  Sun Oct 21 22:03:07 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Mon, 22 Oct 2018 00:03:07 +0200
Subject: Running JavaFX-11 applications from within Eclipse fails
In-Reply-To: <CA+0ynh-1U5aR6L-oDR1JJrtTjTkGka3XDbvE9UYNFVTzsx5RJA@mail.gmail.com>
References: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
 <CA+0ynh9Q9pFJEbXQGQHtyXaCVLwsvVtnmj=RkXKv9uMbyzsPug@mail.gmail.com>
 <006a8869-3f3e-19eb-d98d-b29b104569f2@bestsolution.at>
 <CA+0ynh-1U5aR6L-oDR1JJrtTjTkGka3XDbvE9UYNFVTzsx5RJA@mail.gmail.com>
Message-ID: <bc40d7b9-9bfa-67f5-cc7a-60a3f1fcbb07@bestsolution.at>

Hi,

Well we talk about JavaFX-11 but the important thing is that this bug
only happens if your Eclipse IDE is running Oracle-Java-8 ;-)

Tom

On 21.10.18 21:15, Nir Lisker wrote:
> Ah, I didn't realize you were talking about Java 8.
> 
> On Sun, Oct 21, 2018 at 10:09 PM Tom Schindl
> <tom.schindl at bestsolution.at <mailto:tom.schindl at bestsolution.at>> wrote:
> 
>     Well:
>     - Launch Eclipse 2018-09 with Orcale-Java-8
>     - Create a maven-enabled project (I think this is important because if
>     ? you launch with the FX-SDK on the command line you won't run into
>     ? this)
>     - Boom
> 
>     Tom
> 
>     On 21.10.18 11:35, Nir Lisker wrote:
>     > Hi Tom,
>     >
>     > Iv'e never gotten this error. How do you reproduce this?
>     >
>     > - Nir
>     >
>     > On Thu, Oct 18, 2018 at 1:39 PM Tom Schindl
>     <tom.schindl at bestsolution.at <mailto:tom.schindl at bestsolution.at>
>     > <mailto:tom.schindl at bestsolution.at
>     <mailto:tom.schindl at bestsolution.at>>> wrote:
>     >
>     >? ? ?Hi,
>     >
>     >? ? ?I just wanted to make you aware that if you run a JavaFX-11
>     application
>     >? ? ?from within Eclipse it is very likely that you'll get an error
>     like
>     >? ? ?this.
>     >
>     >? ? ?> Exception in thread "WindowsNativeRunloopThread"
>     >? ? ?java.lang.NoSuchMethodError: <init>
>     >? ? ?>? ? ?at
>     >? ?
>     ?javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native
>     >? ? ?Method)
>     >? ? ?>? ? ?at
>     >? ?
>     ?javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
>     >? ? ?>? ? ?at
>     >? ?
>     ?javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
>     >? ? ?>? ? ?at
>     >? ?
>     ?javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>     >? ? ?Method)
>     >? ? ?>? ? ?at
>     >? ?
>     ?javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>     >? ? ?>? ? ?at java.base/java.lang.Thread.run(Thread.java:834)
>     >? ? ?> Exception in thread "JavaFX Application Thread"
>     >? ? ?java.lang.NullPointerException
>     >? ? ?>? ? ?at
>     >? ?
>     ?javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
>     >? ? ?>? ? ?at
>     >? ?
>     ?javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
>     >? ? ?>? ? ?at
>     >? ?
>     ?javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
>     >? ? ?>? ? ?at
>     >? ?
>     ?javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
>     >? ? ?>? ? ?at
>     >? ?
>     ?javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
>     >? ? ?>? ? ?at
>     >? ?
>     ?javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>     >? ? ?Method)
>     >? ? ?>? ? ?at
>     >? ?
>     ?javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>     >? ? ?>? ? ?at java.base/java.lang.Thread.run(Thread.java:834)
>     >
>     >? ? ?Scary right! The reason is that JavaFX-11 is loading the wrong
>     glass.dll
>     >? ? ?because Eclipse sets a java.library.path who also contains the
>     >? ? ?JVM-Directories used to launch your Eclipse IDE.
>     >
>     >? ? ?The simple work-around is to add
>     >? ? ?-Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
>     >? ? ?configuration.
>     >
>     >? ? ?Small tiny question on the side: Wouldn't it make sense to
>     version our
>     >? ? ?.dlls somehow to match the release eg glass-11.dll?
>     >
>     >? ? ?Tom
>     >
>     >? ? ?--
>     >? ? ?Tom Schindl, CTO
>     >? ? ?BestSolution.at EDV Systemhaus GmbH
>     >? ? ?Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>     >? ? ?Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>     >
> 
>     -- 
>     Tom Schindl, CTO
>     BestSolution.at EDV Systemhaus GmbH
>     Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>     Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From kevin.rushforth at oracle.com  Mon Oct 22 12:12:26 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 22 Oct 2018 05:12:26 -0700
Subject: Running JavaFX-11 applications from within Eclipse fails
In-Reply-To: <CABxFH2HdykTWPoRcuWsLK25P-a5tc3JTREbDh6f9X1TRnCEU+w@mail.gmail.com>
References: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
 <CABxFH2HdykTWPoRcuWsLK25P-a5tc3JTREbDh6f9X1TRnCEU+w@mail.gmail.com>
Message-ID: <eb8f0df2-d6c3-5b68-665e-90f38f553234@oracle.com>


> Renaming the native libraries in JavaFX would probably solve this, but that
> seems the wrong solution to me.

Yes, it seems like a workaround rather than a fix...

-- Kevin


On 10/21/2018 10:45 AM, Johan Vos wrote:
> Hi Tom,
>
> Nice workaround, but what do you think needs to be done to fix it? Can the
> java.library.path somehow be changed in a plugin or so?
> Renaming the native libraries in JavaFX would probably solve this, but that
> seems the wrong solution to me.
>
> - Johan
>
> On Thu, Oct 18, 2018 at 3:39 PM Tom Schindl <tom.schindl at bestsolution.at>
> wrote:
>
>> Hi,
>>
>> I just wanted to make you aware that if you run a JavaFX-11 application
>> from within Eclipse it is very likely that you'll get an error like this.
>>
>>> Exception in thread "WindowsNativeRunloopThread"
>> java.lang.NoSuchMethodError: <init>
>>>      at
>> javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native
>> Method)
>>>      at
>> javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
>>>      at
>> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
>>>      at
>> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
>>>      at
>> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>>>      at java.base/java.lang.Thread.run(Thread.java:834)
>>> Exception in thread "JavaFX Application Thread"
>> java.lang.NullPointerException
>>>      at
>> javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
>>>      at
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
>>>      at
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
>>>      at
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
>>>      at
>> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
>>>      at
>> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
>>>      at
>> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>>>      at java.base/java.lang.Thread.run(Thread.java:834)
>> Scary right! The reason is that JavaFX-11 is loading the wrong glass.dll
>> because Eclipse sets a java.library.path who also contains the
>> JVM-Directories used to launch your Eclipse IDE.
>>
>> The simple work-around is to add
>> -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
>> configuration.
>>
>> Small tiny question on the side: Wouldn't it make sense to version our
>> .dlls somehow to match the release eg glass-11.dll?
>>
>> Tom
>>
>> --
>> Tom Schindl, CTO
>> BestSolution.at EDV Systemhaus GmbH
>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>>


From kevin.rushforth at oracle.com  Mon Oct 22 12:28:05 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 22 Oct 2018 05:28:05 -0700
Subject: Review Request: JDK-8212728: Update the Eclipse classpath file
 for the Swing module
In-Reply-To: <CA+0ynh8+2i7T_JUgk6YSvWjX4Bj_eMyo2p5HDZh1=aJ7erbWUQ@mail.gmail.com>
References: <CA+0ynh8+2i7T_JUgk6YSvWjX4Bj_eMyo2p5HDZh1=aJ7erbWUQ@mail.gmail.com>
Message-ID: <1fba94cd-0267-12e7-3cbd-c3ac91e2a58d@oracle.com>

+1

My mistake for missing this. Sorry about that. I'll get it pushed for 
you shortly.

-- Kevin

On 10/21/2018 12:49 PM, Nir Lisker wrote:
> Hi,
>
> Please review the simple fix for:
>
> https://bugs.openjdk.java.net/browse/JDK-8212728
> http://cr.openjdk.java.net/~nlisker/8212728/webrev.00/
>
> Thanks,
> Nir


From kevin.rushforth at oracle.com  Mon Oct 22 12:32:59 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 22 Oct 2018 05:32:59 -0700
Subject: Updated code review policies posted on OpenJFX Project Wiki
In-Reply-To: <CA+0ynh93RYx9T+gJgCsVUhOAZVLtwku3PE-+jC-KgCpnXPpm-w@mail.gmail.com>
References: <26fd168f-7b18-2eb5-e217-5580766e1621@oracle.com>
 <CA+0ynh93RYx9T+gJgCsVUhOAZVLtwku3PE-+jC-KgCpnXPpm-w@mail.gmail.com>
Message-ID: <019f7202-7a83-c7a9-ff28-cb08d478bfde@oracle.com>

A great idea that I had forgotten about. One of the Reviewers mentioned 
the same to me off list.

-- Kevin


On 10/21/2018 3:05 AM, Nir Lisker wrote:
> Hi Kevin,
>
> I suggest to add an "areas of expertise" (modules or JBS components) 
> to the list of reviewers on the Code Reviews page, at least for active 
> Reviewers, similarly to how it is done on the Code Ownership page.
> It doesn't need to have a formal function (I brought up that idea 
> during the spring discussion), but would help to know who to consult 
> with when working on some part of OpenJFX.
>
> - Nir
>
> On Sat, Oct 20, 2018 at 12:18 AM Kevin Rushforth 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>
>     The updated code review policies that we discussed last spring are
>     now
>     posted on the OpenJFX Project Wiki [1]. For the most part, we have
>     effectively been following these for the past several months. This
>     will
>     formalize the policies in a way that will be easier to point new
>     contributors at. If any of you have any suggestions for making it
>     easier
>     to understand, please send them our way.
>
>     The executive summary is:
>
>     1. Recorded the fact that Johan and I are co-leads of the OpenJFX
>     Project
>
>     2. Formalized the concept of a Reviewer role and recorded the initial
>     list of Reviewers
>
>     3. Formalized the code review requirements:
>     * simple fixes: 1"R"eviewer
>     * higher-impact fixes: 2 reviewers (one of whom must be "R"eviewer)
>     * new features / API changes: discus proposed changes on this
>     list, CSR
>     review (including approval by a Lead) for API changes + 2
>     reviewers for
>     implementation
>
>     4. Formalized the streamlined GitHub code review (as long as you
>     complete all review steps, including RFR email to this list, prior
>     to PR
>     being merged, there is no need for a webrev or additional review
>     to push
>     it to HG jfx-dev repo)
>
>     I am working on an update to the GitHub CONTRIBUTING.md page [2] to
>     align with these newly-formalized policies, primarily to help
>     first time
>     contributors, but also as a reminder for all contributors. I'll
>     send a
>     PR when ready (tomorrow or Monday).
>
>     -- Kevin
>
>     [1] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews
>     [2]
>     https://github.com/javafxports/openjdk-jfx/blob/develop/.github/CONTRIBUTING.md
>


From m.ciglan at sino.sk  Mon Oct 22 12:52:46 2018
From: m.ciglan at sino.sk (Martin Ciglan)
Date: Mon, 22 Oct 2018 14:52:46 +0200
Subject: openJFX11 app deployed in browser?
Message-ID: <16bbe04a-8997-87d7-ff08-fb9f32ce6c2b@sino.sk>

Hi

I am developing openJFX11 desktop client application and I would like to 
deploy it to browser, to be able to have 2 options - thick and thin client.

Is there any up-to-date manual how to do it? Many thanks

-- 

Best Regards

      Martin


From sverre.moe at gmail.com  Mon Oct 22 17:14:30 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Mon, 22 Oct 2018 19:14:30 +0200
Subject: openJFX11 app deployed in browser?
In-Reply-To: <16bbe04a-8997-87d7-ff08-fb9f32ce6c2b@sino.sk>
References: <16bbe04a-8997-87d7-ff08-fb9f32ce6c2b@sino.sk>
Message-ID: <CALAJ+5BzGQLSxXoimWfwaX4J5ZR4wgpkyuOCjK7fV+5SoQ+7uw@mail.gmail.com>

Deployment by web browser is no longer possible with Java 11 as they
removed Java Web Start.
If you want your JavaFX application to run in a web browser, take a look at
JPro https://www.jpro.one/.

/Sverre


Den man. 22. okt. 2018 kl. 14:53 skrev Martin Ciglan <m.ciglan at sino.sk>:

> Hi
>
> I am developing openJFX11 desktop client application and I would like to
> deploy it to browser, to be able to have 2 options - thick and thin client.
>
> Is there any up-to-date manual how to do it? Many thanks
>
> --
>
> Best Regards
>
>       Martin
>
>

From m.ciglan at sino.sk  Mon Oct 22 17:15:51 2018
From: m.ciglan at sino.sk (Martin Ciglan)
Date: Mon, 22 Oct 2018 19:15:51 +0200
Subject: openJFX11 app deployed in browser?
In-Reply-To: <CALAJ+5BzGQLSxXoimWfwaX4J5ZR4wgpkyuOCjK7fV+5SoQ+7uw@mail.gmail.com>
References: <16bbe04a-8997-87d7-ff08-fb9f32ce6c2b@sino.sk>
 <CALAJ+5BzGQLSxXoimWfwaX4J5ZR4wgpkyuOCjK7fV+5SoQ+7uw@mail.gmail.com>
Message-ID: <70fac437-701c-2f07-28a4-8c18280a0876@sino.sk>

OK.

Is it still possible to do it with Java8?

D?a 22/10/2018 o 19:14 Sverre Moe nap?sal(a):
> Deployment by web browser is no longer possible with Java 11 as they 
> removed Java Web Start.
> If you want your JavaFX application to run in a web browser, take a 
> look at JPro https://www.jpro.one/.
>
> /Sverre
>
>
> Den man. 22. okt. 2018 kl. 14:53 skrev Martin Ciglan <m.ciglan at sino.sk 
> <mailto:m.ciglan at sino.sk>>:
>
>     Hi
>
>     I am developing openJFX11 desktop client application and I would
>     like to
>     deploy it to browser, to be able to have 2 options - thick and
>     thin client.
>
>     Is there any up-to-date manual how to do it? Many thanks
>
>     -- 
>
>     Best Regards
>
>     ? ? ? Martin
>
-- 

S pozdravom

      Martin


From sverre.moe at gmail.com  Mon Oct 22 17:20:42 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Mon, 22 Oct 2018 19:20:42 +0200
Subject: openJFX11 app deployed in browser?
In-Reply-To: <70fac437-701c-2f07-28a4-8c18280a0876@sino.sk>
References: <16bbe04a-8997-87d7-ff08-fb9f32ce6c2b@sino.sk>
 <CALAJ+5BzGQLSxXoimWfwaX4J5ZR4wgpkyuOCjK7fV+5SoQ+7uw@mail.gmail.com>
 <70fac437-701c-2f07-28a4-8c18280a0876@sino.sk>
Message-ID: <CALAJ+5CieFcPb-hFidMGs43mxDEbNuAQzkr+pW0HQQK_j9sXyA@mail.gmail.com>

Yes it still works with Java 8 and up to Java 10. The Java Web Start was
removed in Java 11.

/Sverre


Den man. 22. okt. 2018 kl. 19:15 skrev Martin Ciglan <m.ciglan at sino.sk>:

> OK.
>
> Is it still possible to do it with Java8?
> D?a 22/10/2018 o 19:14 Sverre Moe nap?sal(a):
>
> Deployment by web browser is no longer possible with Java 11 as they
> removed Java Web Start.
> If you want your JavaFX application to run in a web browser, take a look
> at JPro https://www.jpro.one/.
>
> /Sverre
>
>
> Den man. 22. okt. 2018 kl. 14:53 skrev Martin Ciglan <m.ciglan at sino.sk>:
>
>> Hi
>>
>> I am developing openJFX11 desktop client application and I would like to
>> deploy it to browser, to be able to have 2 options - thick and thin
>> client.
>>
>> Is there any up-to-date manual how to do it? Many thanks
>>
>> --
>>
>> Best Regards
>>
>>       Martin
>>
>> --
>
> S pozdravom
>
>      Martin
>
>

From sverre.moe at gmail.com  Mon Oct 22 21:00:13 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Mon, 22 Oct 2018 23:00:13 +0200
Subject: openJFX11 app deployed in browser?
In-Reply-To: <CALAJ+5CieFcPb-hFidMGs43mxDEbNuAQzkr+pW0HQQK_j9sXyA@mail.gmail.com>
References: <16bbe04a-8997-87d7-ff08-fb9f32ce6c2b@sino.sk>
 <CALAJ+5BzGQLSxXoimWfwaX4J5ZR4wgpkyuOCjK7fV+5SoQ+7uw@mail.gmail.com>
 <70fac437-701c-2f07-28a4-8c18280a0876@sino.sk>
 <CALAJ+5CieFcPb-hFidMGs43mxDEbNuAQzkr+pW0HQQK_j9sXyA@mail.gmail.com>
Message-ID: <CALAJ+5AKKuCpjk0c=_p_oOzUkLBR_C_ApAL7eXch+F-65p9hDg@mail.gmail.com>

You also mentioned a "up-to-date" manual.
Take a look at javafx-gradle-plugin
https://github.com/FibreFoX/javafx-gradle-plugin
You can use it to build an JavaFX 8 application with Java Web Start
deployment.

/Sverre


Den man. 22. okt. 2018 kl. 19:20 skrev Sverre Moe <sverre.moe at gmail.com>:

> Yes it still works with Java 8 and up to Java 10. The Java Web Start was
> removed in Java 11.
>
> /Sverre
>
>
> Den man. 22. okt. 2018 kl. 19:15 skrev Martin Ciglan <m.ciglan at sino.sk>:
>
>> OK.
>>
>> Is it still possible to do it with Java8?
>> D?a 22/10/2018 o 19:14 Sverre Moe nap?sal(a):
>>
>> Deployment by web browser is no longer possible with Java 11 as they
>> removed Java Web Start.
>> If you want your JavaFX application to run in a web browser, take a look
>> at JPro https://www.jpro.one/.
>>
>> /Sverre
>>
>>
>> Den man. 22. okt. 2018 kl. 14:53 skrev Martin Ciglan <m.ciglan at sino.sk>:
>>
>>> Hi
>>>
>>> I am developing openJFX11 desktop client application and I would like to
>>> deploy it to browser, to be able to have 2 options - thick and thin
>>> client.
>>>
>>> Is there any up-to-date manual how to do it? Many thanks
>>>
>>> --
>>>
>>> Best Regards
>>>
>>>       Martin
>>>
>>> --
>>
>> S pozdravom
>>
>>      Martin
>>
>>

From alexander.matveev at oracle.com  Tue Oct 23 00:31:35 2018
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Mon, 22 Oct 2018 17:31:35 -0700
Subject: [8u] RFR: 8157913: Launcher can not find path to libpackager.so
Message-ID: <b4b39159-13b0-e174-226f-741c6e09a72e@oracle.com>

Hi Kevin,

Please review 8u backport for JDK-8157913:
https://bugs.openjdk.java.net/browse/JDK-8157913

Thanks,
Alexander

From m.ciglan at sino.sk  Tue Oct 23 05:49:38 2018
From: m.ciglan at sino.sk (Martin Ciglan)
Date: Tue, 23 Oct 2018 07:49:38 +0200
Subject: openJFX11 app deployed in browser?
In-Reply-To: <CALAJ+5AKKuCpjk0c=_p_oOzUkLBR_C_ApAL7eXch+F-65p9hDg@mail.gmail.com>
References: <16bbe04a-8997-87d7-ff08-fb9f32ce6c2b@sino.sk>
 <CALAJ+5BzGQLSxXoimWfwaX4J5ZR4wgpkyuOCjK7fV+5SoQ+7uw@mail.gmail.com>
 <70fac437-701c-2f07-28a4-8c18280a0876@sino.sk>
 <CALAJ+5CieFcPb-hFidMGs43mxDEbNuAQzkr+pW0HQQK_j9sXyA@mail.gmail.com>
 <CALAJ+5AKKuCpjk0c=_p_oOzUkLBR_C_ApAL7eXch+F-65p9hDg@mail.gmail.com>
Message-ID: <7f0c7170-3bc2-688a-1385-3f99a31e6734@sino.sk>

Thank you, I'll take a look.

If you say it works up to Java 10, how does it look with browser support.

Are you able to run JavaFX app in latest versions of Chrome or Firefox? 
Thanks.

D?a 22/10/2018 o 23:00 Sverre Moe nap?sal(a):
> You also mentioned a "up-to-date" manual.
> Take a look at javafx-gradle-plugin
> https://github.com/FibreFoX/javafx-gradle-plugin
> You can use it to build an JavaFX 8 application with Java Web Start 
> deployment.
>
> /Sverre
>
>
> Den man. 22. okt. 2018 kl. 19:20 skrev Sverre Moe 
> <sverre.moe at gmail.com <mailto:sverre.moe at gmail.com>>:
>
>     Yes it still works with Java 8 and up to Java 10. The Java Web
>     Start was removed in Java 11.
>
>     /Sverre
>
>
>     Den man. 22. okt. 2018 kl. 19:15 skrev Martin Ciglan
>     <m.ciglan at sino.sk <mailto:m.ciglan at sino.sk>>:
>
>         OK.
>
>         Is it still possible to do it with Java8?
>
>         D?a 22/10/2018 o 19:14 Sverre Moe nap?sal(a):
>>         Deployment by web browser is no longer possible with Java 11
>>         as they removed Java Web Start.
>>         If you want your JavaFX application to run in a web browser,
>>         take a look at JPro https://www.jpro.one/.
>>
>>         /Sverre
>>
>>
>>         Den man. 22. okt. 2018 kl. 14:53 skrev Martin Ciglan
>>         <m.ciglan at sino.sk <mailto:m.ciglan at sino.sk>>:
>>
>>             Hi
>>
>>             I am developing openJFX11 desktop client application and
>>             I would like to
>>             deploy it to browser, to be able to have 2 options -
>>             thick and thin client.
>>
>>             Is there any up-to-date manual how to do it? Many thanks
>>
>>             -- 
>>
>>             Best Regards
>>
>>             ? ? ? Martin
>>
>         -- 
>
>         S pozdravom
>
>               Martin
>
-- 

S pozdravom

      Martin


From carl at bekwam.com  Tue Oct 23 11:32:18 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Tue, 23 Oct 2018 07:32:18 -0400
Subject: openjfx.io Down?
Message-ID: <006901d46ac4$0e1f8cf0$2a5ea6d0$@bekwam.com>

Hi,

 

This is giving me a 404 this morning (October 23, 2018 07:30 EDT). 

 

-Carl

 


From kevin.rushforth at oracle.com  Tue Oct 23 11:45:25 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 23 Oct 2018 04:45:25 -0700
Subject: openjfx.io Down?
In-Reply-To: <006901d46ac4$0e1f8cf0$2a5ea6d0$@bekwam.com>
References: <006901d46ac4$0e1f8cf0$2a5ea6d0$@bekwam.com>
Message-ID: <08a71fb2-61e2-9e84-acaf-803ff5cec51b@oracle.com>

It works fine for me.

-- Kevin

On 10/23/2018 4:32 AM, carl at bekwam.com wrote:
> Hi,
>
>   
>
> This is giving me a 404 this morning (October 23, 2018 07:30 EDT).
>
>   
>
> -Carl
>
>   
>


From abhinay_agarwal at live.com  Tue Oct 23 12:04:21 2018
From: abhinay_agarwal at live.com (Abhinay Agarwal)
Date: Tue, 23 Oct 2018 12:04:21 +0000
Subject: openjfx.io Down?
In-Reply-To: <006901d46ac4$0e1f8cf0$2a5ea6d0$@bekwam.com>
References: <006901d46ac4$0e1f8cf0$2a5ea6d0$@bekwam.com>
Message-ID: <HK2PR0301MB205278AA1940074992401BACE7F50@HK2PR0301MB2052.apcprd03.prod.outlook.com>

Hi Carl,

We integrated Travis CI to https://github.com/openjfx/openjfx.github.io 
repository to ease deployment to Github pages. The first deployment 
deleted the CNAME file causing the site to become inaccessible? via 
openjfx.io.

Thanks for reporting. We've fixed it now.

- Abhinay

On 23-10-2018 17:02, carl at bekwam.com wrote:
> Hi,
>
>   
>
> This is giving me a 404 this morning (October 23, 2018 07:30 EDT).
>
>   
>
> -Carl
>
>   
>

From ambarish.rapte at oracle.com  Tue Oct 23 12:14:41 2018
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Tue, 23 Oct 2018 05:14:41 -0700 (PDT)
Subject: Fix proposal: boolean flag & public API for JDK-8204060 - Disable
 smoothing at javafx.scene.canvas.GraphicsContext.drawImage()
In-Reply-To: <CA+0ynh8s+qzC26UGdsTVtrH1a_FCqm5F4aLTZ_4Ku1aqE1yi5g@mail.gmail.com>
References: <C8YygjJfiZTRAC8Yzgnigk@videotron.ca>
 <dc1b3700-7d95-876c-5d22-d4393eb40278@videotron.ca>
 <1095bd38-52b2-2cad-c495-cccbea6c7150@oracle.com>
 <e9f44d06-2fc3-4f4e-9d31-1977e723047d@default>
 <CA+0ynh8s+qzC26UGdsTVtrH1a_FCqm5F4aLTZ_4Ku1aqE1yi5g@mail.gmail.com>
Message-ID: <613193de-304b-423b-8f71-adb475176df9@default>

Thanks Kevin, Nir & Dan for the review.

?

I shall make these changes and share the fix for review on new email.

?

Regards,

Ambarish

?

From: Nir Lisker <nlisker at gmail.com> 
Sent: Wednesday, October 17, 2018 1:24 PM
To: Ambarish Rapte <ambarish.rapte at oracle.com>
Cc: openjfx-dev at openjdk.java.net Mailing <openjfx-dev at openjdk.java.net>
Subject: Re: Fix proposal: boolean flag & public API for JDK-8204060 - Disable smoothing at javafx.scene.canvas.GraphicsContext.drawImage()

?

Hi Ambarish,

?

* I don't think you need to list the default value in the description if you use?@default (which I see other properties don't), for both get and set.

* "true" and "false" in @param need?@code.

* I would choose either "image smoothing flag" (used in setter) or "image smoothing state" (used in getter) consistently.

?

Thanks,

Nir

?

?

On Tue, Oct 16, 2018 at 8:57 PM Ambarish Rapte <HYPERLINK "mailto:ambarish.rapte at oracle.com"ambarish.rapte at oracle.com> wrote:

Hi All,

Below is documentation for the new APIs and a slight modification in the description of existing drawImage() APIs

New APIs setImageSmoothing() & isImageSmoothing()
*****************************************************************
setImageSmoothing () API
*****************************************************************

? ? ?/**
? ? ?* Sets the image smoothing flag.
? ? ?* The default value is {@code true}.<br>
? ? ?* Image smoothing is an <a href="#image-attr">Image attribute</a>
? ? ?* used to enable or disable image smoothing for
? ? ?* {@link #drawImage(javafx.scene.image.Image, double, double) drawImage(all forms)}
? ? ?* as specified in the <a href="#attr-ops-table">Rendering Attributes Table</a>.<br>
? ? ?* If image smoothing is {@code true}, images will be scaled using a higher
? ? ?* quality filtering when transforming or scaling the source image to fit
? ? ?* in the destination rectangle.<br>
? ? ?* If image smoothing is {@code false}, images will be scaled without filtering
? ? ?* (or by using a lower quality filtering) when transforming or scaling the
? ? ?* source image to fit in the destination rectangle.
? ? ?*
? ? ?* @since 12
? ? ?* @param imageSmoothing true to enable or false to disable smoothing.
? ? ?* @defaultValue {@code true}
? ? ?*/
? ? public void setImageSmoothing(boolean imageSmoothing) {
? ? //......
? ? }

*****************************************************************
isImageSmoothing () API
*****************************************************************
? ? /**
? ? ?* Gets the current state of image smoothing.
? ? ?* The default value is {@code true}.
? ? ?*
? ? ?* @since 12
? ? ?* @return image smoothing state.
? ? ?*/
? ? public boolean isImageSmoothing() {
? ? ? ? //......
? ? ? ? }

*****************************************************************
Image smoothing attribute shall be added to GraphicsContext class docs, in the table "List of Rendering Attributes".
And reference to new image smoothing attribute shall be mentioned in the description of drawImage()
*****************************************************************
? ? ? * <p>
? ? ? * This method will be affected by any of the
? ? ? * <a href="#comm-attr">global common</a>
+? ? ?* or <a href="#image-attr">image</a>
? ? ? * attributes as specified in the
? ? ? * <a href="#attr-ops-table">Rendering Attributes Table</a>.
? ? ? * </p>
*****************************************************************

Regards,
Ambarish

-----Original Message-----
From: Kevin Rushforth 
Sent: Tuesday, October 16, 2018 4:25 AM
To: Dan Howard <HYPERLINK "mailto:sproket at videotron.ca"sproket at videotron.ca>; Ambarish Rapte <HYPERLINK "mailto:ambarish.rapte at oracle.com"ambarish.rapte at oracle.com>; HYPERLINK "mailto:openjfx-dev at openjdk.java.net"openjfx-dev at openjdk.java.net
Subject: Re: Fix proposal: boolean flag & public API for JDK-8204060 - Disable smoothing at javafx.scene.canvas.GraphicsContext.drawImage()

Yes, it should be "isImageSmoothing", thanks for catching this!

This looks good to me to other than that.

The only other comment is that when you write the docs, make sure you indicate that this applies to drawImage calls, both in the docs of the new setImageSmooth method, and in the docs of the drawImage calls. 
Perhaps you post the proposed javadoc changes, since they will be needed for the CSR?

-- Kevin


On 10/15/2018 3:36 PM, Dan Howard wrote:
> Shouldn't it be "is" rather than "get" for boolean?? Other than that, 
> sounds good!
>
>
> On 10/15/2018 3:29 PM, Ambarish Rapte wrote:
>> Hi All,
>>
>>
>> This email is for discussion regarding the fix
>> https://bugs.openjdk.java.net/browse/JDK-8204060 .
>>
>>
>> Issue:
>>
>> Images drawn using javafx.scene.canvas .GraphicsContext::drawImage() 
>> always apply filtering to the image.
>>
>>
>> Solution:
>>
>> javafx.scene.canvas.GraphicsContext should provide an option to 
>> enable and disable smoothing.
>>
>>
>> Proposal:
>>
>> Adding a Boolean flag & APIs to control smoothing.
>>
>>
>> Add a boolean flag to control smoothing Add two public APIs
>>
>> public void setImageSmoothing(boolean imageSmoothing) {} to enable or 
>> disable smoothing.
>> public boolean getImageSmoothing() {}
>>
>> If image smoothing is true, images will be scaled using a higher 
>> quality filtering when transforming or scaling the source image to 
>> fit in the destination rectangle.
>> If image smoothing is false, images will be scaled without filtering 
>> (or by using a lower quality filtering) when transforming or scaling 
>> the source image to fit in the destination rectangle.
>>
>>
>> Please provide your comments on the proposal.
>>
>>
>>
>> Regards,
>>
>> Ambarish
>>
>

From carl at bekwam.com  Tue Oct 23 12:17:29 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Tue, 23 Oct 2018 08:17:29 -0400
Subject: openjfx.io Down? 
Message-ID: <008401d46aca$5e250710$1a6f1530$@bekwam.com>

This is working for me now.  There was a problem with the CNAME earlier.
-Carl


From ambarish.rapte at oracle.com  Tue Oct 23 12:36:55 2018
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Tue, 23 Oct 2018 05:36:55 -0700 (PDT)
Subject: [12] RFR : JDK-802040 : Disable smoothing at
 javafx.scene.canvas.GraphicsContext.drawImage()
Message-ID: <c9a1e975-1c9d-4758-8e12-bc74e0e23d7c@default>

Hi All,

 

                Please review this fix:

                JBS: https://bugs.openjdk.java.net/browse/JDK-8204060

                Webrev: http://cr.openjdk.java.net/~arapte/fx/8204060/webrev.00/

 

Regards,

Ambarish

From kevin.rushforth at oracle.com  Tue Oct 23 13:16:33 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 23 Oct 2018 06:16:33 -0700
Subject: [12] RFR : JDK-802040 : Disable smoothing at
 javafx.scene.canvas.GraphicsContext.drawImage()
In-Reply-To: <c9a1e975-1c9d-4758-8e12-bc74e0e23d7c@default>
References: <c9a1e975-1c9d-4758-8e12-bc74e0e23d7c@default>
Message-ID: <148d9575-090a-eb4f-a73d-8717bf48808b@oracle.com>

Will review after Oracle Code One...

As a reminder, this needs a CSR.

-- Kevin

On 10/23/2018 5:36 AM, Ambarish Rapte wrote:
> Hi All,
>
>   
>
>                  Please review this fix:
>
>                  JBS: https://bugs.openjdk.java.net/browse/JDK-8204060
>
>                  Webrev: http://cr.openjdk.java.net/~arapte/fx/8204060/webrev.00/
>
>   
>
> Regards,
>
> Ambarish


From sverre.moe at gmail.com  Tue Oct 23 14:14:32 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Tue, 23 Oct 2018 16:14:32 +0200
Subject: openJFX11 app deployed in browser?
In-Reply-To: <7f0c7170-3bc2-688a-1385-3f99a31e6734@sino.sk>
References: <16bbe04a-8997-87d7-ff08-fb9f32ce6c2b@sino.sk>
 <CALAJ+5BzGQLSxXoimWfwaX4J5ZR4wgpkyuOCjK7fV+5SoQ+7uw@mail.gmail.com>
 <70fac437-701c-2f07-28a4-8c18280a0876@sino.sk>
 <CALAJ+5CieFcPb-hFidMGs43mxDEbNuAQzkr+pW0HQQK_j9sXyA@mail.gmail.com>
 <CALAJ+5AKKuCpjk0c=_p_oOzUkLBR_C_ApAL7eXch+F-65p9hDg@mail.gmail.com>
 <7f0c7170-3bc2-688a-1385-3f99a31e6734@sino.sk>
Message-ID: <CALAJ+5CL47mZFDQjTAywWvA4hLLSLq7UZ8bCHj49jjQw3uuT7w@mail.gmail.com>

Den tir. 23. okt. 2018 kl. 07:49 skrev Martin Ciglan <m.ciglan at sino.sk>:

> Thank you, I'll take a look.
>
> If you say it works up to Java 10, how does it look with browser support.
>
> Are you able to run JavaFX app in latest versions of Chrome or Firefox?
> Thanks.
>
> You don't have to contend with browser support. The application does not
run within the browser, but with Java.
The Java Web Start is about deployment. You download an JNLP file, which
you then execute using the Java Web Start utility installed with the JDK.
The application still runs in a java process started by the Java Web Start,
after it has downloaded all resources for the application.

/Sverre

From pankaj.b.bansal at oracle.com  Tue Oct 23 16:59:43 2018
From: pankaj.b.bansal at oracle.com (Pankaj Bansal)
Date: Tue, 23 Oct 2018 09:59:43 -0700 (PDT)
Subject: [8u-backport] JDK-8212147: [JavaFX] Conditional support for GTK 3 on
 Linux
Message-ID: <832f378d-70b3-471d-94f8-07bf6cd4a61b@default>

Hi All,

 

Please review the patch for 8u-dev backport for HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8087516"JDK-8087516. It adds conditional support for gtk3. 

As part of the enhancement backport, we will be backporting 18 more bugs fixes done for GTK3 related issues since jdk9. Due to this, the backport will be pushed under https://bugs.openjdk.java.net/browse/JDK-8212147. More information about the 18 bugs can be found at https://bugs.openjdk.java.net/browse/JDK-8212147.

 

The https://bugs.openjdk.java.net/browse/JDK-8212147 is a re-creation of https://bugs.openjdk.java.net/browse/JDK-8206246. The fix for  https://bugs.openjdk.java.net/browse/JDK-8206246 was backed out under https://bugs.openjdk.java.net/browse/JDK-8212139 due to some build issues. Those issues have been resolved and now this fix can be pushed.

 

Under https://bugs.openjdk.java.net/browse/JDK-8206246 the approved version was 01 [1]. We have removed some un-used code, which was added by mistake as it was moved under gtk3 work and bug fixes. There is no change in functionality though. The updated webrev is version 02 [2]. Only following files have been changed in version 02 as compared to 01.

1.      modules/graphics/src/main/native-glass/gtk/glass_general.cpp

2.      modules/graphics/src/main/native-glass/gtk/glass_general.h

3.      modules/graphics/src/main/native-glass/gtk/wrapped.c

4.      modules/graphics/src/main/native-glass/gtk/wrapped.h

 

webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.02/"http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.02/

Enhancement under which this change will be pushed: https://bugs.openjdk.java.net/browse/JDK-8212147

JDK 9 Enhancement: https://bugs.openjdk.java.net/browse/JDK-8087516

JDK 9 Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5

 

[1] HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.01/"http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.01/

[2] HYPERLINK "http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.02/"http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.02/

 

 

Regards,

Pankaj

 

From wookey.dean at gmail.com  Wed Oct 24 10:12:22 2018
From: wookey.dean at gmail.com (Dean Wookey)
Date: Wed, 24 Oct 2018 12:12:22 +0200
Subject: Filling the Packager gap
In-Reply-To: <CABxFH2EMME=PJGpQMvYnpe=XpnvBQEadKMJyou8UOtFy6Bo=Hg@mail.gmail.com>
References: <CABxFH2EMME=PJGpQMvYnpe=XpnvBQEadKMJyou8UOtFy6Bo=Hg@mail.gmail.com>
Message-ID: <CAKZ_BFhqiAT4ZKOHuVnZhq7BgxYivV=79y++gnAddwy1+AqSCA@mail.gmail.com>

Hi,

I got jpackager working with OpenJDK11.0.1 after a bit of trial and error.
I'm now able to create a windows image like I had before with javapackager.
I thought I'd share some of the issues I've had in case it helps anyone out.

The first one was that you need to copy jdk.packager.jar not only into the
bin directory, but also into the jmods directory. If you don't, you get a
cryptic nullpointer exception from the jpackager in verbose mode. I'm sure
it's expecting a jdk.packager.jmod there that contains the list of files
it's looking for.

The second is that --jvm-args only seems to respect the first instance of
an argument. For example, you can have multiple--add-exports arguments. All
of them will get stored in the cfg file in the image's app directory, but
only the first instance will get passed to the jvm by the native executable.

Otherwise, works well, at least for our needs. Thank you.

Dean

On Wed, Sep 19, 2018 at 10:56 AM Johan Vos <johan.vos at gluonhq.com> wrote:

> Hi,
>
> As promised, we looked into an interim solution for the packager-gap. Work
> for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
> We backported the required changes to an OpenJDK 11 mirror:
> https://github.com/johanvos/openjdk-mobile11/tree/packager
>
> With this, we created modified OpenJDK 11 builds that contain the packager
> (wrapper/exe + module including native library). They can be downloaded and
> tested/used at
>
> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
>
> For Windows, you have to unzip the bundle in the same directory as the JDK,
> as the packager wrapper expect to find the java binary at the same level.
>
> Note that these are not products. We use them internally to create
> installers (e.g. we're using them for Scene Builder 11 and that works
> fine), and they do what we expect them to do, but there are no guarantees
> of course so at least for now I recommend using them in development only
> (or even better, look at the changes and contribute to
> https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
>
> - Johan
>

From kevin.rushforth at oracle.com  Wed Oct 24 12:10:44 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 24 Oct 2018 05:10:44 -0700
Subject: Code review of jpackager tool (JEP 343)
Message-ID: <7c17ba49-39ad-e7a9-2234-373d06af8e19@oracle.com>

The code review for the jpackager tool, JEP 343, is underway:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056186.html

The review is being done on the core-libs-dev at openjdk.java.net mailing 
list, so please direct all feedback on the implementation of the JEP to 
that list.

-- Kevin


From kevin.rushforth at oracle.com  Wed Oct 24 12:42:51 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 24 Oct 2018 05:42:51 -0700
Subject: Proposed schedule for JavaFX 12
Message-ID: <b524f05f-e8e5-f1dd-c7e0-b521cce22923@oracle.com>

Here is the proposed schedule for JavaFX 12.

RDP1: Jan 7, 2019 (aka ?feature freeze?)
RDP2: Feb 4, 2019
Freeze: Feb 25, 2019
GA: March 12, 2019

We plan to fork a 12-dev stabilization repo some time between RDP1 and 
RDP2. The GA date is one week ahead of JDK 12, matching what we did for 11.

Please let Johan or I know if you have any questions.

-- Kevin


From rachel at merus.eu  Wed Oct 24 13:09:50 2018
From: rachel at merus.eu (Rachel Greenham)
Date: Wed, 24 Oct 2018 14:09:50 +0100
Subject: Code review of jpackager tool (JEP 343)
In-Reply-To: <7c17ba49-39ad-e7a9-2234-373d06af8e19@oracle.com>
References: <7c17ba49-39ad-e7a9-2234-373d06af8e19@oracle.com>
Message-ID: <d895f214-23c5-247c-bc44-0ab5cbb25482@merus.eu>

ah. as i only followed this list to follow progress on this, turns out 
I'm in the wrong place. :-)

-- 
Rachel

On 24/10/2018 13:10, Kevin Rushforth wrote:
> The code review for the jpackager tool, JEP 343, is underway:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056186.html 
>
>
> The review is being done on the core-libs-dev at openjdk.java.net mailing 
> list, so please direct all feedback on the implementation of the JEP 
> to that list.
>
> -- Kevin
>


From kevin.rushforth at oracle.com  Thu Oct 25 12:13:35 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 25 Oct 2018 05:13:35 -0700
Subject: [12,8u] RFR: JDK-8212158: FX: Update copyright year in docs, readme
 files to 2019
Message-ID: <87f2383c-83a5-2433-e590-32453b01f706@oracle.com>

Hi Murali,

Please review the following to update the copyright year for the API 
docs to 2019:

JBS: https://bugs.openjdk.java.net/browse/JDK-8212158
12 webrev: http://cr.openjdk.java.net/~kcr/8212158/webrev/
8u webrev: http://cr.openjdk.java.net/~kcr/8212158/8u/webrev/

I'm sending the 8u backport for review at the same time to expedite 
getting this into the 8u-dev repo ahead of the RDP2 freeze for 8u202.

-- Kevin


From murali.billa at oracle.com  Thu Oct 25 12:37:29 2018
From: murali.billa at oracle.com (Murali Billa)
Date: Thu, 25 Oct 2018 05:37:29 -0700 (PDT)
Subject: [12,8u] RFR: JDK-8212158: FX: Update copyright year in docs,
 readme files to 2019
In-Reply-To: <87f2383c-83a5-2433-e590-32453b01f706@oracle.com>
References: <87f2383c-83a5-2433-e590-32453b01f706@oracle.com>
Message-ID: <f4201c3c-e281-4580-876f-9ea51c5b2f3e@default>

Hi Kevin,

+1  for 12 and 8u.

Giving +1 in mail since currently not able to login to JBS.

Thanks
Murali

-----Original Message-----
From: Kevin Rushforth 
Sent: Thursday, October 25, 2018 5:44 PM
To: Murali Billa <murali.billa at oracle.com>; openjfx-dev at openjdk.java.net
Subject: [12,8u] RFR: JDK-8212158: FX: Update copyright year in docs, readme files to 2019

Hi Murali,

Please review the following to update the copyright year for the API docs to 2019:

JBS: https://bugs.openjdk.java.net/browse/JDK-8212158
12 webrev: http://cr.openjdk.java.net/~kcr/8212158/webrev/
8u webrev: http://cr.openjdk.java.net/~kcr/8212158/8u/webrev/

I'm sending the 8u backport for review at the same time to expedite getting this into the 8u-dev repo ahead of the RDP2 freeze for 8u202.

-- Kevin


From kevin.rushforth at oracle.com  Thu Oct 25 12:47:16 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 25 Oct 2018 05:47:16 -0700
Subject: [8u] RFR: 8157913: Launcher can not find path to libpackager.so
In-Reply-To: <b4b39159-13b0-e174-226f-741c6e09a72e@oracle.com>
References: <b4b39159-13b0-e174-226f-741c6e09a72e@oracle.com>
Message-ID: <bf375b2a-4242-c5ae-3b91-0c371da2e43a@oracle.com>

+1

Approved to push to 8u-dev for 8u202.

(JBS login is down at the moment...I'll record this in JBS once it is 
back up)

-- Kevin


On 10/22/2018 5:31 PM, Alexander Matveev wrote:
> Hi Kevin,
>
> Please review 8u backport for JDK-8157913:
> https://bugs.openjdk.java.net/browse/JDK-8157913
>
> Thanks,
> Alexander


From kevin.rushforth at oracle.com  Thu Oct 25 13:54:14 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 25 Oct 2018 06:54:14 -0700
Subject: [8u-backport] JDK-8212147: [JavaFX] Conditional support for GTK 3
 on Linux
In-Reply-To: <832f378d-70b3-471d-94f8-07bf6cd4a61b@default>
References: <832f378d-70b3-471d-94f8-07bf6cd4a61b@default>
Message-ID: <3a4807ec-3b76-fd70-37ab-86812fddf631@oracle.com>

+1

As with last time, this will need a second reviewer before pushing it to 
8u-dev.

-- Kevin


On 10/23/2018 9:59 AM, Pankaj Bansal wrote:
>
> Hi All,
>
> Please review the patch for 8u-dev backport for JDK-8087516 
> <https://bugs.openjdk.java.net/browse/JDK-8087516>. It adds 
> conditional support for gtk3.
>
> As part of the enhancement backport, we will be backporting 18 more 
> bugs fixes done for GTK3 related issues since jdk9. Due to this, the 
> backport will be pushed under 
> https://bugs.openjdk.java.net/browse/JDK-8212147. More information 
> about the 18 bugs can be found at 
> https://bugs.openjdk.java.net/browse/JDK-8212147.
>
> The https://bugs.openjdk.java.net/browse/JDK-8212147 is a re-creation 
> of https://bugs.openjdk.java.net/browse/JDK-8206246. The fix for 
> https://bugs.openjdk.java.net/browse/JDK-8206246 was backed out under 
> https://bugs.openjdk.java.net/browse/JDK-8212139 due to some build 
> issues. Those issues have been resolved and now this fix can be pushed.
>
> Under https://bugs.openjdk.java.net/browse/JDK-8206246 the approved 
> version was 01 [1]. We have removed some un-used code, which was added 
> by mistake as it was moved under gtk3 work and bug fixes. There is no 
> change in functionality though. The updated webrev is version 02 [2]. 
> Only following files have been changed in version 02 as compared to 01.
>
> 1.modules/graphics/src/main/native-glass/gtk/glass_general.cpp
>
> 2.modules/graphics/src/main/native-glass/gtk/glass_general.h
>
> 3.modules/graphics/src/main/native-glass/gtk/wrapped.c
>
> 4.modules/graphics/src/main/native-glass/gtk/wrapped.h
>
> webrev: 
> http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.02/ 
> <http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.02/>
>
> Enhancement under which this change will be pushed: 
> https://bugs.openjdk.java.net/browse/JDK-8212147
>
> JDK 9 Enhancement: https://bugs.openjdk.java.net/browse/JDK-8087516
>
> JDK 9 Changeset: 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5
>
> [1] http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.01/ 
> <http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.01/>
>
> [2] http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.02/ 
> <http://cr.openjdk.java.net/%7Epbansal/gtk3_JFX_backport/webrev.02/>
>
> Regards,
>
> Pankaj
>


From thiago.sayao at clamed.com.br  Thu Oct 25 19:14:07 2018
From: thiago.sayao at clamed.com.br (Thiago Milczarek =?ISO-8859-1?Q?Say=E3o?=)
Date: Thu, 25 Oct 2018 16:14:07 -0300
Subject: Using awt calls within OpenJfx context
Message-ID: <69fa636d9f33657b63dc37b26e4de9677c1f037e.camel@clamed.com.br>


With JavaFx that shipped with Oracle Java 10 I was able to do:

Toolkit.getDefaultToolkit().getLockingKeyState(KeyEvent.VK_CAPS_LOCK)

This is used to get if caps lock key is On.

With OpenJfx 11 this call produces:

java.awt.HeadlessException: null


Is there a way to get the caps lock key state with openjfx?








From johan.vos at gluonhq.com  Thu Oct 25 21:04:44 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 25 Oct 2018 14:04:44 -0700
Subject: Retrieving JS HeapSize from webkit
Message-ID: <CABxFH2Ei73yFj9A_+fXsFBJn7Y2Kb-6O+F8_cpcvPmGMOgq2hw@mail.gmail.com>

In the current webkit implementation, there is no boundary on the size of
the JavaScript heap (afaik). As a consequence, a memory leak or malicious
code in a JavaScript function can cause a whole system to crash.

In order to at least allow applications to be informed about the current
size of the JavaScript heap (and take action if it exceed an
application-specific threshold), I was playing with adding a call to
retrieve the current heapsize.
My experiment for this is at
https://github.com/johanvos/openjdk-jfx/commit/1b3d79a685b014d229e82d79d67ed4c3ea54a77d

This works fine, but it is drastic as it adds a method to WebEngine.
In order to make WebEngine more robust, we might need more interaction
between WebKit and WebEngine, and I'm not in favour of randomly adding
methods hence I think we need a more structured approach to this issue.

Thoughts?

- Johan

From webczat_200 at poczta.onet.pl  Fri Oct 26 10:18:02 2018
From: webczat_200 at poczta.onet.pl (=?UTF-8?Q?Micha=c5=82_Zegan?=)
Date: Fri, 26 Oct 2018 12:18:02 +0200
Subject: implementing javafx accessibility for linux
Message-ID: <e7b7fa35-2da5-edeb-a5e8-48a345093b76@poczta.onet.pl>

Hello, few questions:
- is javafx accessibility support for windows/mac that is currently
present in javafx being maintained?
- what would be required for someone to implement javafx accessibility
for other platforms such as linux? Is it supported by public api or does
it require javafx modification/contribution?
- is it planned in the future to implement linux javafx support?


From kevin.rushforth at oracle.com  Fri Oct 26 13:19:41 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 26 Oct 2018 06:19:41 -0700
Subject: implementing javafx accessibility for linux
In-Reply-To: <e7b7fa35-2da5-edeb-a5e8-48a345093b76@poczta.onet.pl>
References: <e7b7fa35-2da5-edeb-a5e8-48a345093b76@poczta.onet.pl>
Message-ID: <3220b8e8-f0f1-2588-c590-7e43b957caa6@oracle.com>

Yes, JavaFX accessibility is being maintained for Windows and Mac. We 
have no plan to ever implement accessibility for Linux.

The implementation of accessibility is in the glass windowing toolkit. 
If you are interesting in exploring it, you could take a look at the 
Windows and Mac implementations. Be aware that implementing 
accessibility for Linux would be a fairly large project that would 
require significant effort in implementation and testing. You would have 
do a proof of concept / prototype before we could evaluate whether it 
could be included into OpenJFX.

If you are interested in trying this, you might want to take a look at 
our GitHub mirror [1], and read the CONTRIBUTING [2] page.

-- Kevin

[1] https://github.com/javafxports/openjdk-jfx
[2] 
https://github.com/javafxports/openjdk-jfx/blob/develop/.github/CONTRIBUTING.md


On 10/26/2018 3:18 AM, Micha? Zegan wrote:
> Hello, few questions:
> - is javafx accessibility support for windows/mac that is currently
> present in javafx being maintained?
> - what would be required for someone to implement javafx accessibility
> for other platforms such as linux? Is it supported by public api or does
> it require javafx modification/contribution?
> - is it planned in the future to implement linux javafx support?
>


From webczat_200 at poczta.onet.pl  Fri Oct 26 15:05:12 2018
From: webczat_200 at poczta.onet.pl (=?UTF-8?Q?Micha=c5=82_Zegan?=)
Date: Fri, 26 Oct 2018 17:05:12 +0200
Subject: implementing javafx accessibility for linux
In-Reply-To: <3220b8e8-f0f1-2588-c590-7e43b957caa6@oracle.com>
References: <e7b7fa35-2da5-edeb-a5e8-48a345093b76@poczta.onet.pl>
 <3220b8e8-f0f1-2588-c590-7e43b957caa6@oracle.com>
Message-ID: <2e607d00-f098-5a1a-93fc-f83ef7aff17e@poczta.onet.pl>



W dniu 26.10.2018 o?15:19, Kevin Rushforth pisze:
> Yes, JavaFX accessibility is being maintained for Windows and Mac. We
> have no plan to ever implement accessibility for Linux.
Why it is not planned to implement accessibility for linux? I would say
that the reasons to implement it are exactly the same as reasons to
implement javafx itself there. I am one of the people that would benefit
from that.
> 
> The implementation of accessibility is in the glass windowing toolkit.
> If you are interesting in exploring it, you could take a look at the
> Windows and Mac implementations. Be aware that implementing
> accessibility for Linux would be a fairly large project that would
> require significant effort in implementation and testing. You would have
> do a proof of concept / prototype before we could evaluate whether it
> could be included into OpenJFX.
Well, not quite sure. I believe it requires implementing ATK interfaces
in a native library, and then hook it up to the subclass derived from
com.sun.glass.ui.Accessible, not sure if anything else is required
javafx side? Mapping of concepts between atk and javafx may be tricky,
but shouldn't be impossible.
Also i was wondering about implementing atk accessible window interface.
It seems to me like javafx does not even treat windows as accessible
objects, rather it starts from the scene level... However atk doesn't
have concept similar to a scene, and actually fires events on things
like window activated/deactivated/maximized.
I am not yet planning to implement anything, but trying to look into how
much work/efford would it require in case I would like to do this.
> 
> If you are interested in trying this, you might want to take a look at
> our GitHub mirror [1], and read the CONTRIBUTING [2] page.
> 
> -- Kevin
> 
> [1] https://github.com/javafxports/openjdk-jfx
> [2]
> https://github.com/javafxports/openjdk-jfx/blob/develop/.github/CONTRIBUTING.md
> 
> 
> 
> On 10/26/2018 3:18 AM, Micha? Zegan wrote:
>> Hello, few questions:
>> - is javafx accessibility support for windows/mac that is currently
>> present in javafx being maintained?
>> - what would be required for someone to implement javafx accessibility
>> for other platforms such as linux? Is it supported by public api or does
>> it require javafx modification/contribution?
>> - is it planned in the future to implement linux javafx support?
>>
> 


From kevin.rushforth at oracle.com  Mon Oct 29 14:54:50 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 29 Oct 2018 07:54:50 -0700
Subject: [11] RFR: JDK-8213047: Change JavaFX release version in 11-dev to
 11.0.1
Message-ID: <38f753a4-ff62-3675-fb02-66b5c2522b46@oracle.com>

Hi Johan,

I request approval to push this fix to 11-dev.

Please review the following fix to bump the release version for FX 
11-dev to 11.0.1 in preparation for 11.x builds:

https://bugs.openjdk.java.net/browse/JDK-8213047
http://cr.openjdk.java.net/~kcr/8213047/webrev/

-- Kevin


From johan at lodgon.com  Mon Oct 29 14:56:37 2018
From: johan at lodgon.com (Johan Vos)
Date: Mon, 29 Oct 2018 15:56:37 +0100
Subject: [11] RFR: JDK-8213047: Change JavaFX release version in 11-dev to
 11.0.1
In-Reply-To: <38f753a4-ff62-3675-fb02-66b5c2522b46@oracle.com>
References: <38f753a4-ff62-3675-fb02-66b5c2522b46@oracle.com>
Message-ID: <CABek58m6_+6y2BpkiutnTPwkn=BivfjPN9gQ8=DdHms2kZXVfg@mail.gmail.com>

+1 for pushing this fix to 11-dev

Op ma 29 okt. 2018 om 15:55 schreef Kevin Rushforth <
kevin.rushforth at oracle.com>:

> Hi Johan,
>
> I request approval to push this fix to 11-dev.
>
> Please review the following fix to bump the release version for FX
> 11-dev to 11.0.1 in preparation for 11.x builds:
>
> https://bugs.openjdk.java.net/browse/JDK-8213047
> http://cr.openjdk.java.net/~kcr/8213047/webrev/
>
> -- Kevin
>
>

From johan.vos at gluonhq.com  Mon Oct 29 16:39:18 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Mon, 29 Oct 2018 17:39:18 +0100
Subject: Review request backport 8210386
Message-ID: <CABxFH2H3w-=ET-6kX5eeMFzAo+yppD5f-ULSJp2S_0Jg6tzdaQ@mail.gmail.com>

Hi Kevin,

Please review the backport of 8210386 (Marlin fixes) into 11-dev (target
11.0.1)
http://cr.openjdk.java.net/~jvos/8210386/webrev.00/

- Johan

From kevin.rushforth at oracle.com  Mon Oct 29 16:55:18 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 29 Oct 2018 09:55:18 -0700
Subject: Review request backport 8210386
In-Reply-To: <CABxFH2H3w-=ET-6kX5eeMFzAo+yppD5f-ULSJp2S_0Jg6tzdaQ@mail.gmail.com>
References: <CABxFH2H3w-=ET-6kX5eeMFzAo+yppD5f-ULSJp2S_0Jg6tzdaQ@mail.gmail.com>
Message-ID: <f9cf057c-1197-05b6-4e3b-ae9f67ba2825@oracle.com>

The newly added test, which was pushed to jfx-dev as part of the fix for 
12, is missing from the webrev:

tests/system/src/test/java/test/com/sun/marlin/ScaleClipTest.java

The rest looks OK.

-- Kevin


On 10/29/2018 9:39 AM, Johan Vos wrote:
> Hi Kevin,
>
> Please review the backport of 8210386 (Marlin fixes) into 11-dev (target
> 11.0.1)
> http://cr.openjdk.java.net/~jvos/8210386/webrev.00/
>
> - Johan


From johan.vos at gluonhq.com  Mon Oct 29 18:27:31 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Mon, 29 Oct 2018 19:27:31 +0100
Subject: Review request backport 8210386
In-Reply-To: <f9cf057c-1197-05b6-4e3b-ae9f67ba2825@oracle.com>
References: <CABxFH2H3w-=ET-6kX5eeMFzAo+yppD5f-ULSJp2S_0Jg6tzdaQ@mail.gmail.com>
 <f9cf057c-1197-05b6-4e3b-ae9f67ba2825@oracle.com>
Message-ID: <CABxFH2E450BL-HVYZKry1RfU89PhT7g4e2iVSgxTdNO+m9_u6g@mail.gmail.com>

new webrev including test:
http://cr.openjdk.java.net/~jvos/8210386/webrev.01/
<http://cr.openjdk.java.net/~jvos/8210386/webrev.00/>

On Mon, Oct 29, 2018 at 5:55 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> The newly added test, which was pushed to jfx-dev as part of the fix for
> 12, is missing from the webrev:
>
> tests/system/src/test/java/test/com/sun/marlin/ScaleClipTest.java
>
> The rest looks OK.
>
> -- Kevin
>
>
> On 10/29/2018 9:39 AM, Johan Vos wrote:
> > Hi Kevin,
> >
> > Please review the backport of 8210386 (Marlin fixes) into 11-dev (target
> > 11.0.1)
> > http://cr.openjdk.java.net/~jvos/8210386/webrev.00/
> >
> > - Johan
>
>

From kevin.rushforth at oracle.com  Mon Oct 29 18:35:28 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 29 Oct 2018 11:35:28 -0700
Subject: Review request backport 8210386
In-Reply-To: <CABxFH2E450BL-HVYZKry1RfU89PhT7g4e2iVSgxTdNO+m9_u6g@mail.gmail.com>
References: <CABxFH2H3w-=ET-6kX5eeMFzAo+yppD5f-ULSJp2S_0Jg6tzdaQ@mail.gmail.com>
 <f9cf057c-1197-05b6-4e3b-ae9f67ba2825@oracle.com>
 <CABxFH2E450BL-HVYZKry1RfU89PhT7g4e2iVSgxTdNO+m9_u6g@mail.gmail.com>
Message-ID: <d8876add-bfc7-5fbb-3795-efc4f12ca46e@oracle.com>

Looks good. Approved for pushing to 11-dev.

-- Kevin

On 10/29/2018 11:27 AM, Johan Vos wrote:
> new webrev including test:
> http://cr.openjdk.java.net/~jvos/8210386/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ejvos/8210386/webrev.00/>
>
> On Mon, Oct 29, 2018 at 5:55 PM Kevin Rushforth 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>
>     The newly added test, which was pushed to jfx-dev as part of the
>     fix for
>     12, is missing from the webrev:
>
>     tests/system/src/test/java/test/com/sun/marlin/ScaleClipTest.java
>
>     The rest looks OK.
>
>     -- Kevin
>
>
>     On 10/29/2018 9:39 AM, Johan Vos wrote:
>     > Hi Kevin,
>     >
>     > Please review the backport of 8210386 (Marlin fixes) into 11-dev
>     (target
>     > 11.0.1)
>     > http://cr.openjdk.java.net/~jvos/8210386/webrev.00/
>     <http://cr.openjdk.java.net/%7Ejvos/8210386/webrev.00/>
>     >
>     > - Johan
>


From bourges.laurent at gmail.com  Tue Oct 30 06:19:37 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 30 Oct 2018 07:19:37 +0100
Subject: Review request backport 8210386
In-Reply-To: <d8876add-bfc7-5fbb-3795-efc4f12ca46e@oracle.com>
References: <CABxFH2H3w-=ET-6kX5eeMFzAo+yppD5f-ULSJp2S_0Jg6tzdaQ@mail.gmail.com>
 <f9cf057c-1197-05b6-4e3b-ae9f67ba2825@oracle.com>
 <CABxFH2E450BL-HVYZKry1RfU89PhT7g4e2iVSgxTdNO+m9_u6g@mail.gmail.com>
 <d8876add-bfc7-5fbb-3795-efc4f12ca46e@oracle.com>
Message-ID: <CAKjRUT7F-_pNritoN8N3UDWA-moLcRBdWRAuGf=-1AKhsn788A@mail.gmail.com>

Thank you,

Laurent

Le lun. 29 oct. 2018 ? 19:35, Kevin Rushforth <kevin.rushforth at oracle.com>
a ?crit :

> Looks good. Approved for pushing to 11-dev.
>
> -- Kevin
>
> On 10/29/2018 11:27 AM, Johan Vos wrote:
> > new webrev including test:
> > http://cr.openjdk.java.net/~jvos/8210386/webrev.01/
> > <http://cr.openjdk.java.net/%7Ejvos/8210386/webrev.00/>
> >
> > On Mon, Oct 29, 2018 at 5:55 PM Kevin Rushforth
> > <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
> >
> >     The newly added test, which was pushed to jfx-dev as part of the
> >     fix for
> >     12, is missing from the webrev:
> >
> >     tests/system/src/test/java/test/com/sun/marlin/ScaleClipTest.java
> >
> >     The rest looks OK.
> >
> >     -- Kevin
> >
> >
> >     On 10/29/2018 9:39 AM, Johan Vos wrote:
> >     > Hi Kevin,
> >     >
> >     > Please review the backport of 8210386 (Marlin fixes) into 11-dev
> >     (target
> >     > 11.0.1)
> >     > http://cr.openjdk.java.net/~jvos/8210386/webrev.00/
> >     <http://cr.openjdk.java.net/%7Ejvos/8210386/webrev.00/>
> >     >
> >     > - Johan
> >
>
>

From johan.vos at gluonhq.com  Tue Oct 30 12:15:08 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 30 Oct 2018 13:15:08 +0100
Subject: JDK-8090930: Add Support for Extended Mouse Buttons
In-Reply-To: <CAOTPd67B_xcuseqdre6i23PxY_+8wPhWA8Lg7Ka33BSj8GKh_g@mail.gmail.com>
References: <CAOTPd67B_xcuseqdre6i23PxY_+8wPhWA8Lg7Ka33BSj8GKh_g@mail.gmail.com>
Message-ID: <CABxFH2Go-Qmiy=JQWdXY7Kipent1_L3+opd82WeHa3bj=3WRRA@mail.gmail.com>

Hi Michael,

I only started to look into this now, sorry for being late at the party.
Overall, this looks good to me. The risk is indeed minimal (developers
relying on switch-default cases to select e.g. middle button will be
punished).

I am not entirely sure about the naming though. Should it really be
"BACK/FORWARD" or should it rather be "BUTTON4/BUTTON5" as it can be mapped
to whatever?

- Johan

On Thu, Aug 30, 2018 at 12:54 AM Michael Ennen <mike.ennen at gmail.com> wrote:

> Hello All,
>
> I am working on JDK-8090930 which is a request to add
> support for the BACK/FORWARD mouse buttons that are
> supported by some mice. I have opened a proof-of-concept
> pull request on Github which can be found here:
>
> https://github.com/javafxports/openjdk-jfx/pull/173
>
> This is still in the early stages (no CSR has been created yet,
> however there is a preliminary one in the comments on the
> above Github issue) but Kevin wanted me to post a notification
> to this list so that people can review and comment on it (and
> I think that's a good idea, too).
>
> Thanks,
>
> Michael Ennen
>

From murali.billa at oracle.com  Tue Oct 30 12:29:38 2018
From: murali.billa at oracle.com (Murali Billa)
Date: Tue, 30 Oct 2018 05:29:38 -0700 (PDT)
Subject: [RFR] [12] JDK-8207772: File API and FileReader should be supported
 in WebView
Message-ID: <afb71dd2-b763-4f5b-ac77-7dc8fa56dca6@default>

?

Hi Kevin, Johan, Arun,


Please review the below enhancement for File Reader support in JavaFX WebView.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8207772

?

Github PR: https://github.com/javafxports/openjdk-jfx/pull/250

?


Thanks,

Murali

From mike.ennen at gmail.com  Tue Oct 30 19:33:58 2018
From: mike.ennen at gmail.com (Michael Ennen)
Date: Tue, 30 Oct 2018 12:33:58 -0700
Subject: JDK-8090930: Add Support for Extended Mouse Buttons
In-Reply-To: <CABxFH2Go-Qmiy=JQWdXY7Kipent1_L3+opd82WeHa3bj=3WRRA@mail.gmail.com>
References: <CAOTPd67B_xcuseqdre6i23PxY_+8wPhWA8Lg7Ka33BSj8GKh_g@mail.gmail.com>
 <CABxFH2Go-Qmiy=JQWdXY7Kipent1_L3+opd82WeHa3bj=3WRRA@mail.gmail.com>
Message-ID: <CAOTPd65TTpqRX7JFkWPLs7KSDX5p4hDzZEADXgSmf97tz_kG5w@mail.gmail.com>

Great question. It seems to be pretty standard that mouse buttons 4 and 5
are called
back and forward. So either way would be fine with me. In my opinion the
descriptive
names may be better as then EventListeners responding to these new buttons
would
be more human-readable.

On Tue, Oct 30, 2018 at 5:15 AM Johan Vos <johan.vos at gluonhq.com> wrote:

> Hi Michael,
>
> I only started to look into this now, sorry for being late at the party.
> Overall, this looks good to me. The risk is indeed minimal (developers
> relying on switch-default cases to select e.g. middle button will be
> punished).
>
> I am not entirely sure about the naming though. Should it really be
> "BACK/FORWARD" or should it rather be "BUTTON4/BUTTON5" as it can be mapped
> to whatever?
>
> - Johan
>
> On Thu, Aug 30, 2018 at 12:54 AM Michael Ennen <mike.ennen at gmail.com>
> wrote:
>
>> Hello All,
>>
>> I am working on JDK-8090930 which is a request to add
>> support for the BACK/FORWARD mouse buttons that are
>> supported by some mice. I have opened a proof-of-concept
>> pull request on Github which can be found here:
>>
>> https://github.com/javafxports/openjdk-jfx/pull/173
>>
>> This is still in the early stages (no CSR has been created yet,
>> however there is a preliminary one in the comments on the
>> above Github issue) but Kevin wanted me to post a notification
>> to this list so that people can review and comment on it (and
>> I think that's a good idea, too).
>>
>> Thanks,
>>
>> Michael Ennen
>>
>

-- 
Michael Ennen

From murray at math.umass.edu  Tue Oct 30 21:05:46 2018
From: murray at math.umass.edu (Murray Eisenberg)
Date: Tue, 30 Oct 2018 17:05:46 -0400
Subject: Why cannot run compiled JavaFX 11 class?
Message-ID: <7CA2A36B-B6AC-41B0-B5FC-632418751DBE@math.umass.edu>

This is under macOS Mojave (10.14).

Following instructions at https://openjfx.io/openjfx-docs/#install-javafx, I compiled the sample HelloFX.java via:

     javac --module-path $PATH_TO_FX --add-modules=javafx.controls /Users/me/Documents/java/HelloFX.java 

But now if I attempt to run that...

     java --module-path $PATH_TO_FX --add-modules=javafx.controls /Users/me/Documents/java/HelloFX

... I get error:

     Error: Could not find or load main class .Users.me.Documents.java.HelloFX
     Caused by: java.lang.ClassNotFoundException: /Users/me/Documents/java/HelloFX 

Yet the file reported as not found is there:

     ls -l /Users/me/Documents/java/HelloFX.class
     -rwxr--r--  1 me  staff  1336 Oct 30 16:01 /Users/murray/Documents/java/HelloFX.class

(I had already changed permissions to add `u+x` in case that was the issue, but apparently that was not the trouble.

What's wrong?

(Yes, `$PATH_TO_FX` does point to `javafx-sdk-11/lib`.)

??
Murray Eisenberg                                murray at math.umass.edu
Mathematics & Statistics Dept.       
University of Massachusetts Amherst              





From steve at weblite.ca  Tue Oct 30 21:17:59 2018
From: steve at weblite.ca (Steve Hannah)
Date: Tue, 30 Oct 2018 14:17:59 -0700
Subject: Why cannot run compiled JavaFX 11 class?
In-Reply-To: <7CA2A36B-B6AC-41B0-B5FC-632418751DBE@math.umass.edu>
References: <7CA2A36B-B6AC-41B0-B5FC-632418751DBE@math.umass.edu>
Message-ID: <CABiRg+Ss0Lv0xrdGt81XGy5pUOEMaCq+=nGVA5E7GQaFEyNrgQ@mail.gmail.com>

The "java" command expects a fully-qualified class name, not a file path as
its argument.

E.g.
cd  /Users/me/Documents/java
java --module-path $PATH_TO_FX --add-modules=javafx.controls HelloFX



On Tue, Oct 30, 2018 at 2:06 PM Murray Eisenberg <murray at math.umass.edu>
wrote:

> This is under macOS Mojave (10.14).
>
> Following instructions at https://openjfx.io/openjfx-docs/#install-javafx,
> I compiled the sample HelloFX.java via:
>
>      javac --module-path $PATH_TO_FX --add-modules=javafx.controls
> /Users/me/Documents/java/HelloFX.java
>
> But now if I attempt to run that...
>
>      java --module-path $PATH_TO_FX --add-modules=javafx.controls
> /Users/me/Documents/java/HelloFX
>
> ... I get error:
>
>      Error: Could not find or load main class
> .Users.me.Documents.java.HelloFX
>      Caused by: java.lang.ClassNotFoundException:
> /Users/me/Documents/java/HelloFX
>
> Yet the file reported as not found is there:
>
>      ls -l /Users/me/Documents/java/HelloFX.class
>      -rwxr--r--  1 me  staff  1336 Oct 30 16:01
> /Users/murray/Documents/java/HelloFX.class
>
> (I had already changed permissions to add `u+x` in case that was the
> issue, but apparently that was not the trouble.
>
> What's wrong?
>
> (Yes, `$PATH_TO_FX` does point to `javafx-sdk-11/lib`.)
>
> ??
> Murray Eisenberg                                murray at math.umass.edu
> Mathematics & Statistics Dept.
> University of Massachusetts Amherst
>
>
>
>
>

-- 
Steve Hannah
Web Lite Solutions Corp.

From kevin.rushforth at oracle.com  Tue Oct 30 22:17:13 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 30 Oct 2018 15:17:13 -0700
Subject: JDK-8090930: Add Support for Extended Mouse Buttons
In-Reply-To: <CAOTPd65TTpqRX7JFkWPLs7KSDX5p4hDzZEADXgSmf97tz_kG5w@mail.gmail.com>
References: <CAOTPd67B_xcuseqdre6i23PxY_+8wPhWA8Lg7Ka33BSj8GKh_g@mail.gmail.com>
 <CABxFH2Go-Qmiy=JQWdXY7Kipent1_L3+opd82WeHa3bj=3WRRA@mail.gmail.com>
 <CAOTPd65TTpqRX7JFkWPLs7KSDX5p4hDzZEADXgSmf97tz_kG5w@mail.gmail.com>
Message-ID: <5b2ede53-8a62-2baa-00db-75667a737e88@oracle.com>

I don't have a strong opinion. On the one hand, the platform libraries 
(at least Mac and Windows) use some variation of BUTTON4 and BUTTON5 
rather than a name. On the other hand, we already use symbolic names for 
the PRIMARY, SECONDARY, and MIDDLE buttons, rather than using 1, 2, 3. 
I'm OK with the symbolic names FORWARD and BACK, but I also see Johan's 
point.

-- Kevin


On 10/30/2018 12:33 PM, Michael Ennen wrote:
> Great question. It seems to be pretty standard that mouse buttons 4 and 5
> are called
> back and forward. So either way would be fine with me. In my opinion the
> descriptive
> names may be better as then EventListeners responding to these new buttons
> would
> be more human-readable.
>
> On Tue, Oct 30, 2018 at 5:15 AM Johan Vos <johan.vos at gluonhq.com> wrote:
>
>> Hi Michael,
>>
>> I only started to look into this now, sorry for being late at the party.
>> Overall, this looks good to me. The risk is indeed minimal (developers
>> relying on switch-default cases to select e.g. middle button will be
>> punished).
>>
>> I am not entirely sure about the naming though. Should it really be
>> "BACK/FORWARD" or should it rather be "BUTTON4/BUTTON5" as it can be mapped
>> to whatever?
>>
>> - Johan
>>
>> On Thu, Aug 30, 2018 at 12:54 AM Michael Ennen <mike.ennen at gmail.com>
>> wrote:
>>
>>> Hello All,
>>>
>>> I am working on JDK-8090930 which is a request to add
>>> support for the BACK/FORWARD mouse buttons that are
>>> supported by some mice. I have opened a proof-of-concept
>>> pull request on Github which can be found here:
>>>
>>> https://github.com/javafxports/openjdk-jfx/pull/173
>>>
>>> This is still in the early stages (no CSR has been created yet,
>>> however there is a preliminary one in the comments on the
>>> above Github issue) but Kevin wanted me to post a notification
>>> to this list so that people can review and comment on it (and
>>> I think that's a good idea, too).
>>>
>>> Thanks,
>>>
>>> Michael Ennen
>>>


From murray at math.umass.edu  Tue Oct 30 22:20:01 2018
From: murray at math.umass.edu (Murray Eisenberg)
Date: Tue, 30 Oct 2018 18:20:01 -0400
Subject: Why cannot run compiled JavaFX 11 class?
In-Reply-To: <CABiRg+Ss0Lv0xrdGt81XGy5pUOEMaCq+=nGVA5E7GQaFEyNrgQ@mail.gmail.com>
References: <7CA2A36B-B6AC-41B0-B5FC-632418751DBE@math.umass.edu>
 <CABiRg+Ss0Lv0xrdGt81XGy5pUOEMaCq+=nGVA5E7GQaFEyNrgQ@mail.gmail.com>
Message-ID: <9F528220-7D90-4C07-AD8D-54595F5A2186@math.umass.edu>

But the run command I gave, ending in just ?HelloFX?, is exactly what was shown at https://openjfx.io/openjfx-docs/#install-javafx.

What exactly is it that I?d have to enter instead? 

(I did try adding extension ?.class? but that didn?t help.)



> On 30 Oct2018, at 5:17 PM, Steve Hannah <steve at weblite.ca> wrote:
> 
> The "java" command expects a fully-qualified class name, not a file path as its argument.
> 
> E.g.  
> cd  /Users/me/Documents/java
> java --module-path $PATH_TO_FX --add-modules=javafx.controls HelloFX
> 
> 
> 
> On Tue, Oct 30, 2018 at 2:06 PM Murray Eisenberg <murray at math.umass.edu <mailto:murray at math.umass.edu>> wrote:
> This is under macOS Mojave (10.14).
> 
> Following instructions at https://openjfx.io/openjfx-docs/#install-javafx <https://openjfx.io/openjfx-docs/#install-javafx>, I compiled the sample HelloFX.java via:
> 
>      javac --module-path $PATH_TO_FX --add-modules=javafx.controls /Users/me/Documents/java/HelloFX.java 
> 
> But now if I attempt to run that...
> 
>      java --module-path $PATH_TO_FX --add-modules=javafx.controls /Users/me/Documents/java/HelloFX
> 
> ... I get error:
> 
>      Error: Could not find or load main class .Users.me.Documents.java.HelloFX
>      Caused by: java.lang.ClassNotFoundException: /Users/me/Documents/java/HelloFX 
> 
> Yet the file reported as not found is there:
> 
>      ls -l /Users/me/Documents/java/HelloFX.class
>      -rwxr--r--  1 me  staff  1336 Oct 30 16:01 /Users/murray/Documents/java/HelloFX.class
> 
> (I had already changed permissions to add `u+x` in case that was the issue, but apparently that was not the trouble.
> 
> What's wrong?
> 
> (Yes, `$PATH_TO_FX` does point to `javafx-sdk-11/lib`.)
> 
> ??
> Murray Eisenberg                                murray at math.umass.edu <mailto:murray at math.umass.edu>
> Mathematics & Statistics Dept.       
> University of Massachusetts Amherst              
> 
> 
> 
> 
> 
> 
> -- 
> Steve Hannah
> Web Lite Solutions Corp.

??
Murray Eisenberg                                murray at math.umass.edu
Mathematics & Statistics Dept.       
Lederle Graduate Research Tower      phone 240 246-7240 (H)
University of Massachusetts                
710 North Pleasant Street                 
Amherst, MA 01003-9305





From fastegal at swingempire.de  Wed Oct 31 13:57:03 2018
From: fastegal at swingempire.de (fastegal at swingempire.de)
Date: Wed, 31 Oct 2018 14:57:03 +0100
Subject: Problems building openjfx
Message-ID: <20181031145703.Horde.ZQGCkkUxkwh_j5REAgomRw2@webmail.df.eu>


first try, following the instructions (for win10) at:

that is having downloaded, installed the required tools, added env  
vars as desribed.

Then in cygwin, navigate to the git working dir, typing

gradle tasks

fails with:

FAILURE: Build failed with an exception.

* Where:
Script  
'C:\Daten\data-for-work\eclipse\gitrep-openjdk\openjdk-jfx\buildSrc\win.gradle' line:  
92

* What went wrong:
A problem occurred evaluating script.
> FAIL: WINSDK_DIR not defined

to me, it looks the env var WINSDK_DIR is not set - what should go in there?

Thanks, Jeanette

BTW: did I ever mention that I hate command line tools - and they feel  
it, fighting back with all they got ;)


From fastegal at swingempire.de  Wed Oct 31 14:02:45 2018
From: fastegal at swingempire.de (fastegal at swingempire.de)
Date: Wed, 31 Oct 2018 15:02:45 +0100
Subject: Problems building openjfx
In-Reply-To: <20181031145703.Horde.ZQGCkkUxkwh_j5REAgomRw2@webmail.df.eu>
References: <20181031145703.Horde.ZQGCkkUxkwh_j5REAgomRw2@webmail.df.eu>
Message-ID: <20181031150245.Horde.96kpsXfyvd5AkpBwsZ5GxQ1@webmail.df.eu>

forgot the link to the instruction page, just in case there's another:

https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-EnvironmentVariables

Zitat von fastegal at swingempire.de:

> first try, following the instructions (for win10) at:
>
> that is having downloaded, installed the required tools, added env  
> vars as desribed.
>
> Then in cygwin, navigate to the git working dir, typing
>
> gradle tasks
>
> fails with:
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Script  
> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\openjdk-jfx\buildSrc\win.gradle' line:  
> 92
>
> * What went wrong:
> A problem occurred evaluating script.
>> FAIL: WINSDK_DIR not defined
>
> to me, it looks the env var WINSDK_DIR is not set - what should go in there?
>
> Thanks, Jeanette
>
> BTW: did I ever mention that I hate command line tools - and they  
> feel it, fighting back with all they got ;)




From kevin.rushforth at oracle.com  Wed Oct 31 14:08:56 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 31 Oct 2018 07:08:56 -0700
Subject: Problems building openjfx
In-Reply-To: <20181031150245.Horde.96kpsXfyvd5AkpBwsZ5GxQ1@webmail.df.eu>
References: <20181031145703.Horde.ZQGCkkUxkwh_j5REAgomRw2@webmail.df.eu>
 <20181031150245.Horde.96kpsXfyvd5AkpBwsZ5GxQ1@webmail.df.eu>
Message-ID: <6280c155-20e2-5452-c9a4-f4ce10c371d6@oracle.com>

One thing that might help diagnose this is to look at is the output of 
'build/windows_tools.properties'.

Those env variables should be set automatically by the build if you have 
VS 2017 installed in the default location. If you have changed anything 
in your system (installed new packages or set different env vars) then 
manually "rm -rf build" and try running "gradle" again and see if that 
helps.

-- Kevin


On 10/31/2018 7:02 AM, fastegal at swingempire.de wrote:
> forgot the link to the instruction page, just in case there's another:
>
> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-EnvironmentVariables 
>
>
> Zitat von fastegal at swingempire.de:
>
>> first try, following the instructions (for win10) at:
>>
>> that is having downloaded, installed the required tools, added env 
>> vars as desribed.
>>
>> Then in cygwin, navigate to the git working dir, typing
>>
>> gradle tasks
>>
>> fails with:
>>
>> FAILURE: Build failed with an exception.
>>
>> * Where:
>> Script 
>> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\openjdk-jfx\buildSrc\win.gradle' 
>> line: 92
>>
>> * What went wrong:
>> A problem occurred evaluating script.
>>> FAIL: WINSDK_DIR not defined
>>
>> to me, it looks the env var WINSDK_DIR is not set - what should go in 
>> there?
>>
>> Thanks, Jeanette
>>
>> BTW: did I ever mention that I hate command line tools - and they 
>> feel it, fighting back with all they got ;)
>
>
>


From fastegal at swingempire.de  Wed Oct 31 14:22:29 2018
From: fastegal at swingempire.de (fastegal at swingempire.de)
Date: Wed, 31 Oct 2018 15:22:29 +0100
Subject: Problems building openjfx
In-Reply-To: <6280c155-20e2-5452-c9a4-f4ce10c371d6@oracle.com>
References: <20181031145703.Horde.ZQGCkkUxkwh_j5REAgomRw2@webmail.df.eu>
 <20181031150245.Horde.96kpsXfyvd5AkpBwsZ5GxQ1@webmail.df.eu>
 <6280c155-20e2-5452-c9a4-f4ce10c371d6@oracle.com>
Message-ID: <20181031152229.Horde.tYyNYQzeWmqPOoXpX-_aqA4@webmail.df.eu>

thanks for the quick answer :)

hmm, those are nearly all empty:

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=;C:/java/jdk/open-11/bin;C:/ProgramData/Oracle/Java/javapath;C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;C:/WINDOWS/System32/WindowsPowerShell/v1.0/;C:/Program Files/Intel/WiFi/bin/;C:/Program Files/Common Files/Intel/WirelessCommon/;C:/DevTools/openjfx-build/tortoise-hg/;C:/Program  
Files/dotnet/;C:/WINDOWS/System32/OpenSSH/;C:/DevTools/gradle/bin;C:/DevTools/ant/bin;C:/Users/kleopatra/AppData/Local/Microsoft/WindowsApps;C:/Users/kleopatra/AppData/Local/GitHubDesktop/bin
WINDOWS_VS_VER=100
WINDOWS_SDK_DIR=
WINDOWS_SDK_VERSION=

actually can't even start my visual vc (community edition) - keeps  
telling me that the eval time has expired, isn't it supposed to be free?



Zitat von Kevin Rushforth <kevin.rushforth at oracle.com>:

> One thing that might help diagnose this is to look at is the output  
> of 'build/windows_tools.properties'.
>
> Those env variables should be set automatically by the build if you  
> have VS 2017 installed in the default location. If you have changed  
> anything in your system (installed new packages or set different env  
> vars) then manually "rm -rf build" and try running "gradle" again  
> and see if that helps.
>
> -- Kevin
>
>
> On 10/31/2018 7:02 AM, fastegal at swingempire.de wrote:
>> forgot the link to the instruction page, just in case there's another:
>>
>> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-EnvironmentVariables Zitat von  
>> fastegal at swingempire.de:
>>
>>> first try, following the instructions (for win10) at:
>>>
>>> that is having downloaded, installed the required tools, added env  
>>> vars as desribed.
>>>
>>> Then in cygwin, navigate to the git working dir, typing
>>>
>>> gradle tasks
>>>
>>> fails with:
>>>
>>> FAILURE: Build failed with an exception.
>>>
>>> * Where:
>>> Script  
>>> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\openjdk-jfx\buildSrc\win.gradle' line:  
>>> 92
>>>
>>> * What went wrong:
>>> A problem occurred evaluating script.
>>>> FAIL: WINSDK_DIR not defined
>>>
>>> to me, it looks the env var WINSDK_DIR is not set - what should go  
>>> in there?
>>>
>>> Thanks, Jeanette
>>>
>>> BTW: did I ever mention that I hate command line tools - and they  
>>> feel it, fighting back with all they got ;)
>>
>>
>>




From fastegal at swingempire.de  Wed Oct 31 14:30:06 2018
From: fastegal at swingempire.de (fastegal at swingempire.de)
Date: Wed, 31 Oct 2018 15:30:06 +0100
Subject: Problems building openjfx
In-Reply-To: <20181031152229.Horde.tYyNYQzeWmqPOoXpX-_aqA4@webmail.df.eu>
References: <20181031145703.Horde.ZQGCkkUxkwh_j5REAgomRw2@webmail.df.eu>
 <20181031150245.Horde.96kpsXfyvd5AkpBwsZ5GxQ1@webmail.df.eu>
 <6280c155-20e2-5452-c9a4-f4ce10c371d6@oracle.com>
 <20181031152229.Horde.tYyNYQzeWmqPOoXpX-_aqA4@webmail.df.eu>
Message-ID: <20181031153006.Horde.LuV1IR5jysPK_qWj_0X81A2@webmail.df.eu>


okay after deleting the properties and running again, it at least  
lists the tasks without error - thanks :)

now will try a real build - expecting all hell breaking loose <g>

Zitat von fastegal at swingempire.de:

> thanks for the quick answer :)
>
> hmm, those are nearly all empty:
>
> 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=;C:/java/jdk/open-11/bin;C:/ProgramData/Oracle/Java/javapath;C:/WINDOWS/system32;C:/WINDOWS;C:/WINDOWS/System32/Wbem;C:/WINDOWS/System32/WindowsPowerShell/v1.0/;C:/Program Files/Intel/WiFi/bin/;C:/Program Files/Common Files/Intel/WirelessCommon/;C:/DevTools/openjfx-build/tortoise-hg/;C:/Program  
> Files/dotnet/;C:/WINDOWS/System32/OpenSSH/;C:/DevTools/gradle/bin;C:/DevTools/ant/bin;C:/Users/kleopatra/AppData/Local/Microsoft/WindowsApps;C:/Users/kleopatra/AppData/Local/GitHubDesktop/bin
> WINDOWS_VS_VER=100
> WINDOWS_SDK_DIR=
> WINDOWS_SDK_VERSION=
>
> actually can't even start my visual vc (community edition) - keeps  
> telling me that the eval time has expired, isn't it supposed to be  
> free?
>
>
>
> Zitat von Kevin Rushforth <kevin.rushforth at oracle.com>:
>
>> One thing that might help diagnose this is to look at is the output  
>> of 'build/windows_tools.properties'.
>>
>> Those env variables should be set automatically by the build if you  
>> have VS 2017 installed in the default location. If you have changed  
>> anything in your system (installed new packages or set different  
>> env vars) then manually "rm -rf build" and try running "gradle"  
>> again and see if that helps.
>>
>> -- Kevin
>>
>>
>> On 10/31/2018 7:02 AM, fastegal at swingempire.de wrote:
>>> forgot the link to the instruction page, just in case there's another:
>>>
>>> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-EnvironmentVariables Zitat von  
>>> fastegal at swingempire.de:
>>>
>>>> first try, following the instructions (for win10) at:
>>>>
>>>> that is having downloaded, installed the required tools, added  
>>>> env vars as desribed.
>>>>
>>>> Then in cygwin, navigate to the git working dir, typing
>>>>
>>>> gradle tasks
>>>>
>>>> fails with:
>>>>
>>>> FAILURE: Build failed with an exception.
>>>>
>>>> * Where:
>>>> Script  
>>>> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\openjdk-jfx\buildSrc\win.gradle' line:  
>>>> 92
>>>>
>>>> * What went wrong:
>>>> A problem occurred evaluating script.
>>>>> FAIL: WINSDK_DIR not defined
>>>>
>>>> to me, it looks the env var WINSDK_DIR is not set - what should  
>>>> go in there?
>>>>
>>>> Thanks, Jeanette
>>>>
>>>> BTW: did I ever mention that I hate command line tools - and they  
>>>> feel it, fighting back with all they got ;)
>>>
>>>
>>>




From fastegal at swingempire.de  Wed Oct 31 14:58:43 2018
From: fastegal at swingempire.de (fastegal at swingempire.de)
Date: Wed, 31 Oct 2018 15:58:43 +0100
Subject: Problems building openjfx
In-Reply-To: <20181031153006.Horde.LuV1IR5jysPK_qWj_0X81A2@webmail.df.eu>
References: <20181031145703.Horde.ZQGCkkUxkwh_j5REAgomRw2@webmail.df.eu>
 <20181031150245.Horde.96kpsXfyvd5AkpBwsZ5GxQ1@webmail.df.eu>
 <6280c155-20e2-5452-c9a4-f4ce10c371d6@oracle.com>
 <20181031152229.Horde.tYyNYQzeWmqPOoXpX-_aqA4@webmail.df.eu>
 <20181031153006.Horde.LuV1IR5jysPK_qWj_0X81A2@webmail.df.eu>
Message-ID: <20181031155843.Horde.YlgBHdCUWn9mZEd2W_asOw5@webmail.df.eu>


wasn't as bad as expected, just had to interrupt because it took ages  
to test the webkit (which wasn't build so all its tests ran until each  
timed out)

> Task :web:test
*****************************************************
WARNING: running web tests without building webkit.
The webkit native library will be copied from the JDK,
which might lead to failures in some web tests.
To avoid these failures, you should either build
webkit locally, copy the native webkit library from a
recent build, or skip execution of web test cases with
'-x :web:test'
*****************************************************

fine to get informed after the fact <g> Hmm .. I would expect the default
script to behave the other way round: if the the webkit isn't built, then its
tests aren't run by default (but can be included if need be)

but well, I'm just starting to get my pants wet, so take whatever I expect
with a bag of salt :)

On another track: building everything from scratch takes some time - can I
use those build artefacts (namely the test infrastructure) and copy it over to
a single module project and just use it?

hmm .. need to try, tomorrow or so. Thanks so far!


Zitat von fastegal at swingempire.de:

> okay after deleting the properties and running again, it at least  
> lists the tasks without error - thanks :)
>
> now will try a real build - expecting all hell breaking loose <g>
>
> Zitat von fastegal at swingempire.de:
>



From nlisker at gmail.com  Wed Oct 31 15:17:25 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 31 Oct 2018 17:17:25 +0200
Subject: Problems building openjfx
In-Reply-To: <20181031155843.Horde.YlgBHdCUWn9mZEd2W_asOw5@webmail.df.eu>
References: <20181031145703.Horde.ZQGCkkUxkwh_j5REAgomRw2@webmail.df.eu>
 <20181031150245.Horde.96kpsXfyvd5AkpBwsZ5GxQ1@webmail.df.eu>
 <6280c155-20e2-5452-c9a4-f4ce10c371d6@oracle.com>
 <20181031152229.Horde.tYyNYQzeWmqPOoXpX-_aqA4@webmail.df.eu>
 <20181031153006.Horde.LuV1IR5jysPK_qWj_0X81A2@webmail.df.eu>
 <20181031155843.Horde.YlgBHdCUWn9mZEd2W_asOw5@webmail.df.eu>
Message-ID: <CA+0ynh-ArC+4q=gS2G8ohoxNTDCKyfYo9ipzSvSiHQ3w61i=dQ@mail.gmail.com>

Can I remove the step for "DirectX SDK June 2010"? I think it was already
verified that it's not needed.

- Nir

On Wed, Oct 31, 2018 at 4:59 PM <fastegal at swingempire.de> wrote:

>
> wasn't as bad as expected, just had to interrupt because it took ages
> to test the webkit (which wasn't build so all its tests ran until each
> timed out)
>
> > Task :web:test
> *****************************************************
> WARNING: running web tests without building webkit.
> The webkit native library will be copied from the JDK,
> which might lead to failures in some web tests.
> To avoid these failures, you should either build
> webkit locally, copy the native webkit library from a
> recent build, or skip execution of web test cases with
> '-x :web:test'
> *****************************************************
>
> fine to get informed after the fact <g> Hmm .. I would expect the default
> script to behave the other way round: if the the webkit isn't built, then
> its
> tests aren't run by default (but can be included if need be)
>
> but well, I'm just starting to get my pants wet, so take whatever I expect
> with a bag of salt :)
>
> On another track: building everything from scratch takes some time - can I
> use those build artefacts (namely the test infrastructure) and copy it
> over to
> a single module project and just use it?
>
> hmm .. need to try, tomorrow or so. Thanks so far!
>
>
> Zitat von fastegal at swingempire.de:
>
> > okay after deleting the properties and running again, it at least
> > lists the tasks without error - thanks :)
> >
> > now will try a real build - expecting all hell breaking loose <g>
> >
> > Zitat von fastegal at swingempire.de:
> >
>
>
>

From carl at bekwam.com  Wed Oct 31 15:22:26 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Wed, 31 Oct 2018 11:22:26 -0400
Subject: Problems building openjfx
Message-ID: <002101d4712d$87e3fe80$97abfb80$@bekwam.com>

I've been pulling the latest and building successfully on Windows for the
past week.  Here's a supplement to the official docs.

 

https://courses.bekwam.net/public_tutorials/bkcourse_building_openjfx_8_win.
html

-Carl

 


From fastegal at swingempire.de  Wed Oct 31 15:26:33 2018
From: fastegal at swingempire.de (fastegal at swingempire.de)
Date: Wed, 31 Oct 2018 16:26:33 +0100
Subject: Problems building openjfx
In-Reply-To: <CA+0ynh-ArC+4q=gS2G8ohoxNTDCKyfYo9ipzSvSiHQ3w61i=dQ@mail.gmail.com>
References: <20181031145703.Horde.ZQGCkkUxkwh_j5REAgomRw2@webmail.df.eu>
 <20181031150245.Horde.96kpsXfyvd5AkpBwsZ5GxQ1@webmail.df.eu>
 <6280c155-20e2-5452-c9a4-f4ce10c371d6@oracle.com>
 <20181031152229.Horde.tYyNYQzeWmqPOoXpX-_aqA4@webmail.df.eu>
 <20181031153006.Horde.LuV1IR5jysPK_qWj_0X81A2@webmail.df.eu>
 <20181031155843.Horde.YlgBHdCUWn9mZEd2W_asOw5@webmail.df.eu>
 <CA+0ynh-ArC+4q=gS2G8ohoxNTDCKyfYo9ipzSvSiHQ3w61i=dQ@mail.gmail.com>
Message-ID: <20181031162633.Horde.FLhW3m0Cnh3AuJ5-iY0cyg1@webmail.df.eu>

yes, I think so - don't have it and nothing barked at me

Zitat von Nir Lisker <nlisker at gmail.com>:

> Can I remove the step for "DirectX SDK June 2010"? I think it was already
> verified that it's not needed.
>
> - Nir
>
> On Wed, Oct 31, 2018 at 4:59 PM <fastegal at swingempire.de> wrote:
>
>>
>> wasn't as bad as expected, just had to interrupt because it took ages
>> to test the webkit (which wasn't build so all its tests ran until each
>> timed out)
>>
>> > Task :web:test
>> *****************************************************
>> WARNING: running web tests without building webkit.
>> The webkit native library will be copied from the JDK,
>> which might lead to failures in some web tests.
>> To avoid these failures, you should either build
>> webkit locally, copy the native webkit library from a
>> recent build, or skip execution of web test cases with
>> '-x :web:test'
>> *****************************************************
>>
>> fine to get informed after the fact <g> Hmm .. I would expect the default
>> script to behave the other way round: if the the webkit isn't built, then
>> its
>> tests aren't run by default (but can be included if need be)
>>
>> but well, I'm just starting to get my pants wet, so take whatever I expect
>> with a bag of salt :)
>>
>> On another track: building everything from scratch takes some time - can I
>> use those build artefacts (namely the test infrastructure) and copy it
>> over to
>> a single module project and just use it?
>>
>> hmm .. need to try, tomorrow or so. Thanks so far!
>>
>>
>> Zitat von fastegal at swingempire.de:
>>
>> > okay after deleting the properties and running again, it at least
>> > lists the tasks without error - thanks :)
>> >
>> > now will try a real build - expecting all hell breaking loose <g>
>> >
>> > Zitat von fastegal at swingempire.de:
>> >
>>
>>
>>




From kevin.rushforth at oracle.com  Wed Oct 31 16:08:30 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 31 Oct 2018 09:08:30 -0700
Subject: Problems building openjfx
In-Reply-To: <20181031162633.Horde.FLhW3m0Cnh3AuJ5-iY0cyg1@webmail.df.eu>
References: <20181031145703.Horde.ZQGCkkUxkwh_j5REAgomRw2@webmail.df.eu>
 <20181031150245.Horde.96kpsXfyvd5AkpBwsZ5GxQ1@webmail.df.eu>
 <6280c155-20e2-5452-c9a4-f4ce10c371d6@oracle.com>
 <20181031152229.Horde.tYyNYQzeWmqPOoXpX-_aqA4@webmail.df.eu>
 <20181031153006.Horde.LuV1IR5jysPK_qWj_0X81A2@webmail.df.eu>
 <20181031155843.Horde.YlgBHdCUWn9mZEd2W_asOw5@webmail.df.eu>
 <CA+0ynh-ArC+4q=gS2G8ohoxNTDCKyfYo9ipzSvSiHQ3w61i=dQ@mail.gmail.com>
 <20181031162633.Horde.FLhW3m0Cnh3AuJ5-iY0cyg1@webmail.df.eu>
Message-ID: <4e469d3d-cd39-f4a0-1e34-ea9d02d172d0@oracle.com>

Make it so. :)

-- Kevin


On 10/31/2018 8:26 AM, fastegal at swingempire.de wrote:
> yes, I think so - don't have it and nothing barked at me
>
> Zitat von Nir Lisker <nlisker at gmail.com>:
>
>> Can I remove the step for "DirectX SDK June 2010"? I think it was 
>> already
>> verified that it's not needed.
>>
>> - Nir
>>
>> On Wed, Oct 31, 2018 at 4:59 PM <fastegal at swingempire.de> wrote:
>>
>>>
>>> wasn't as bad as expected, just had to interrupt because it took ages
>>> to test the webkit (which wasn't build so all its tests ran until each
>>> timed out)
>>>
>>> > Task :web:test
>>> *****************************************************
>>> WARNING: running web tests without building webkit.
>>> The webkit native library will be copied from the JDK,
>>> which might lead to failures in some web tests.
>>> To avoid these failures, you should either build
>>> webkit locally, copy the native webkit library from a
>>> recent build, or skip execution of web test cases with
>>> '-x :web:test'
>>> *****************************************************
>>>
>>> fine to get informed after the fact <g> Hmm .. I would expect the 
>>> default
>>> script to behave the other way round: if the the webkit isn't built, 
>>> then
>>> its
>>> tests aren't run by default (but can be included if need be)
>>>
>>> but well, I'm just starting to get my pants wet, so take whatever I 
>>> expect
>>> with a bag of salt :)
>>>
>>> On another track: building everything from scratch takes some time - 
>>> can I
>>> use those build artefacts (namely the test infrastructure) and copy it
>>> over to
>>> a single module project and just use it?
>>>
>>> hmm .. need to try, tomorrow or so. Thanks so far!
>>>
>>>
>>> Zitat von fastegal at swingempire.de:
>>>
>>> > okay after deleting the properties and running again, it at least
>>> > lists the tasks without error - thanks :)
>>> >
>>> > now will try a real build - expecting all hell breaking loose <g>
>>> >
>>> > Zitat von fastegal at swingempire.de:
>>> >
>>>
>>>
>>>
>
>
>


From johan.vos at gluonhq.com  Wed Oct 31 16:55:22 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 31 Oct 2018 17:55:22 +0100
Subject: Problems building openjfx
In-Reply-To: <002101d4712d$87e3fe80$97abfb80$@bekwam.com>
References: <002101d4712d$87e3fe80$97abfb80$@bekwam.com>
Message-ID: <CABxFH2G9HvE+1mar3Jk3wW9mGHGvoqac+7pXAwGPd-j_K3FyXA@mail.gmail.com>

Your site says these are for 8, but I assume it is very similar to 11? If
so, we should probably update the wiki with the instructions on your site.
Are there any particular parts of the wiki where you think corrections are
needed?
I think we should focus on 11 on the wiki, so it's really good you have
instructions for 8 on your site. But the 11 instructions on the wiki should
be working for everyone who wants to build 11.

- Johan

On Wed, Oct 31, 2018 at 4:32 PM <carl at bekwam.com> wrote:

> I've been pulling the latest and building successfully on Windows for the
> past week.  Here's a supplement to the official docs.
>
>
>
>
> https://courses.bekwam.net/public_tutorials/bkcourse_building_openjfx_8_win.
> html
> <https://courses.bekwam.net/public_tutorials/bkcourse_building_openjfx_8_win.html>
>
> -Carl
>
>
>
>

From arunprasad.rajkumar at oracle.com  Wed Oct 31 18:33:03 2018
From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar)
Date: Thu, 1 Nov 2018 00:03:03 +0530
Subject: [RFR] [openjfx12] 8213135: HTMLEditorTest.checkStyleProperty fails
 intermittently
Message-ID: <E4F5C82D-249A-4C5A-8480-A663DED37336@oracle.com>

Hi Kevin/Murali,

Please review the patch for the following bug,

Root cause: 
WebView load workers's state change notification received for the default page of HTMLEditor and not for the html doc which loaded using setHtmlText. The erroneous notification caused assertion check on invalid html document. The problem is not just specific to `checkStyleProperty`, it is applicable for all of the tests present in HTMLEditorTest. 

Proposed solution: 
Cancel the default page load before attaching the loader state change observer.

Webrev: http://cr.openjdk.java.net/~arajkumar/8213135/webrev/ 

Following changes are made in the webrev,
1. Cancel the default page load of HTMLEditor before loading test page (for all tests in HTMLEditorTest).
2. Moved common test object initialisation to separate method using junit @Before.
3. Added helper method in Util.java to wait for the latch to complete.

Regards,
Arun


From nlisker at gmail.com  Wed Oct 31 18:34:31 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 31 Oct 2018 20:34:31 +0200
Subject: Problems building openjfx
In-Reply-To: <CABxFH2G9HvE+1mar3Jk3wW9mGHGvoqac+7pXAwGPd-j_K3FyXA@mail.gmail.com>
References: <002101d4712d$87e3fe80$97abfb80$@bekwam.com>
 <CABxFH2G9HvE+1mar3Jk3wW9mGHGvoqac+7pXAwGPd-j_K3FyXA@mail.gmail.com>
Message-ID: <CA+0ynh__j0+SxtO90KCwajmTSQ=JwiJEjg5oxNgHJbTjqAkzOQ@mail.gmail.com>

>
> I think we should focus on 11 on the wiki, so it's really good you have
> instructions for 8 on your site. But the 11 instructions on the wiki should
> be working for everyone who wants to build 11.


There are instructions for 8 on the wiki too, though I don't know if they
are correct.
As for 11, in the"Platform Prerequisites" section, I only updated the Win
instructions because that's what I have. Someone should look at Mac and
Linux.

On Wed, Oct 31, 2018 at 6:56 PM Johan Vos <johan.vos at gluonhq.com> wrote:

> Your site says these are for 8, but I assume it is very similar to 11? If
> so, we should probably update the wiki with the instructions on your site.
> Are there any particular parts of the wiki where you think corrections are
> needed?
> I think we should focus on 11 on the wiki, so it's really good you have
> instructions for 8 on your site. But the 11 instructions on the wiki should
> be working for everyone who wants to build 11.
>
> - Johan
>
> On Wed, Oct 31, 2018 at 4:32 PM <carl at bekwam.com> wrote:
>
> > I've been pulling the latest and building successfully on Windows for the
> > past week.  Here's a supplement to the official docs.
> >
> >
> >
> >
> >
> https://courses.bekwam.net/public_tutorials/bkcourse_building_openjfx_8_win
> .
> > html
> > <
> https://courses.bekwam.net/public_tutorials/bkcourse_building_openjfx_8_win.html
> >
> >
> > -Carl
> >
> >
> >
> >
>

From philip.race at oracle.com  Wed Oct 31 19:24:06 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 31 Oct 2018 12:24:06 -0700
Subject: Code review of jpackager tool (JEP 343)
In-Reply-To: <d895f214-23c5-247c-bc44-0ab5cbb25482@merus.eu>
References: <7c17ba49-39ad-e7a9-2234-373d06af8e19@oracle.com>
 <d895f214-23c5-247c-bc44-0ab5cbb25482@merus.eu>
Message-ID: <aec162ff-a4fb-c611-bbb5-66821b1a0a91@oracle.com>

Anyone interested in jpackager should definitely subscribe to 
core-libs-dev at openjdk.java.net
to comment on it and follow the review. Admittedly core-libs-dev is a 
very active list and
this is just one topic, but it is the place to make your views known on 
the tool, since
it is a "core" JDK feature, not an FX feature, even though it is 
inspired by javapackager.

-phil.

On 10/24/18 6:09 AM, Rachel Greenham wrote:
> ah. as i only followed this list to follow progress on this, turns out 
> I'm in the wrong place. :-)
>
> -- 
> Rachel
>
> On 24/10/2018 13:10, Kevin Rushforth wrote:
>> The code review for the jpackager tool, JEP 343, is underway:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056186.html 
>>
>>
>> The review is being done on the core-libs-dev at openjdk.java.net 
>> mailing list, so please direct all feedback on the implementation of 
>> the JEP to that list.


From sverre.moe at gmail.com  Wed Oct 31 22:58:12 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Wed, 31 Oct 2018 23:58:12 +0100
Subject: Maybe a TitledPane bug
Message-ID: <CALAJ+5B8mEGL=oxeAEMDaa7KMLQCNg1MbRs7GG=DRbxjovrp1w@mail.gmail.com>

I am not sure if I have stumbled upon a bug in JavaFX, or perhaps it is
simply something I am doing wrong.

After setting the TitledPane title background programmatically, then when
hovering the background color is reset to the previous value from CSS.
I get same behavior in both JavaFX 8 and JavaFX 11.

Color color = Color.valueOf("#00ff11");
titleNode.setBackground(new Background(new BackgroundFill(color, null,
null)));

titleNode.setStyle("-fx-background-color:#00ff11;");

Setting the style property seems to work, but why doesn't the
programmatically approach work?

https://stackoverflow.com/questions/53083005/javafx-titledpane-changed-title-background-is-reset-on-mouse-entered/

/Sverre