From johan.vos at gluonhq.com  Thu Nov  1 10:57:52 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 1 Nov 2018 11:57:52 +0100
Subject: Problems building openjfx
In-Reply-To: <CA+0ynh__j0+SxtO90KCwajmTSQ=JwiJEjg5oxNgHJbTjqAkzOQ@mail.gmail.com>
References: <002101d4712d$87e3fe80$97abfb80$@bekwam.com>
 <CABxFH2G9HvE+1mar3Jk3wW9mGHGvoqac+7pXAwGPd-j_K3FyXA@mail.gmail.com>
 <CA+0ynh__j0+SxtO90KCwajmTSQ=JwiJEjg5oxNgHJbTjqAkzOQ@mail.gmail.com>
Message-ID: <CABxFH2HHjEZjvdBwH7C==hVgrJth3s2ZYVQx09Eh_e6aLSCd8A@mail.gmail.com>

On Wed, Oct 31, 2018 at 7:34 PM Nir Lisker <nlisker at gmail.com> wrote:

> 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.
>
>>
>>
Great, thanks for that. @Carl, can you confirm the instructions on the wiki
for 11 are correct? Or do you only build for 8?

Thanks,

- Johan

From carl at bekwam.com  Thu Nov  1 12:33:35 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Thu, 1 Nov 2018 08:33:35 -0400
Subject: Problems building openjfx
In-Reply-To: <CABxFH2HHjEZjvdBwH7C==hVgrJth3s2ZYVQx09Eh_e6aLSCd8A@mail.gmail.com>
References: <002101d4712d$87e3fe80$97abfb80$@bekwam.com>
 <CABxFH2G9HvE+1mar3Jk3wW9mGHGvoqac+7pXAwGPd-j_K3FyXA@mail.gmail.com>
 <CA+0ynh__j0+SxtO90KCwajmTSQ=JwiJEjg5oxNgHJbTjqAkzOQ@mail.gmail.com>
 <CABxFH2HHjEZjvdBwH7C==hVgrJth3s2ZYVQx09Eh_e6aLSCd8A@mail.gmail.com>
Message-ID: <008201d471df$1bbace20$53306a60$@bekwam.com>

I?ve just been compiling 8 for Windows since I can get 11 from openjfx.io.  I?m going to compile 8 for the Mac and Linux in the next week or two.   I?ll post my notes again for these platforms.

 

-Carl

 

From: Johan Vos <johan.vos at gluonhq.com> 
Sent: Thursday, November 1, 2018 6:58 AM
To: Nir Lisker <nlisker at gmail.com>; Carl Walker <carl at bekwam.com>
Cc: openjfx-dev at openjdk.java.net Mailing <openjfx-dev at openjdk.java.net>
Subject: Re: Problems building openjfx

 

 

On Wed, Oct 31, 2018 at 7:34 PM Nir Lisker <nlisker at gmail.com <mailto:nlisker at gmail.com> > wrote:

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.

 

 

Great, thanks for that. @Carl, can you confirm the instructions on the wiki for 11 are correct? Or do you only build for 8?

 

Thanks,

 

- Johan 


From david.grieve at oracle.com  Thu Nov  1 13:45:13 2018
From: david.grieve at oracle.com (David Grieve)
Date: Thu, 1 Nov 2018 09:45:13 -0400
Subject: Maybe a TitledPane bug
In-Reply-To: <CALAJ+5B8mEGL=oxeAEMDaa7KMLQCNg1MbRs7GG=DRbxjovrp1w@mail.gmail.com>
References: <CALAJ+5B8mEGL=oxeAEMDaa7KMLQCNg1MbRs7GG=DRbxjovrp1w@mail.gmail.com>
Message-ID: <91c5e8eb-4614-2cbe-f424-2e82860d401d@oracle.com>

It's hard to tell without some short, self-contained, correct example. 
This sample I crafted here doesn't reproduce the issue.

@Override public void start(Stage primaryStage) {

     final TitledPane titledPane =new TitledPane("Button Pane",new Button("Button"));
     final HBox root =new HBox();
     root.getChildren().add(titledPane);

     primaryStage.setTitle("Maybe a TitledPane bug");
     primaryStage.setScene(new Scene(root,300,250));
     primaryStage.show();

     final Region titleNode = (Region)titledPane.lookup("*.title");
     titleNode.setBackground(new Background(new BackgroundFill(Color.GREEN,null,null)));
}



On 10/31/18 6:58 PM, Sverre Moe wrote:
> 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


From sverre.moe at gmail.com  Thu Nov  1 18:19:15 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Thu, 1 Nov 2018 19:19:15 +0100
Subject: Maybe a TitledPane bug
In-Reply-To: <91c5e8eb-4614-2cbe-f424-2e82860d401d@oracle.com>
References: <CALAJ+5B8mEGL=oxeAEMDaa7KMLQCNg1MbRs7GG=DRbxjovrp1w@mail.gmail.com>
 <91c5e8eb-4614-2cbe-f424-2e82860d401d@oracle.com>
Message-ID: <CALAJ+5BAF9D5U=JUZ_+ZdSb2dViwBaODdYxYQ6F+bq=MdxOm6A@mail.gmail.com>

I am now not so sure it is a bug. Seems the problem is the hover pseudo
state that resets the background color.
>From modena.css
.titled-pane > .title:hover {
    -fx-color: -fx-hover-base;
}

Try this example:

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.TitledPane;
import javafx.scene.control.ToggleButton;
import javafx.scene.layout.Background;
import javafx.scene.layout.BackgroundFill;
import javafx.scene.layout.Region;
import javafx.scene.layout.StackPane;
import javafx.scene.paint.Color;
import javafx.stage.Stage;

public class TitledPaneApplication extends Application {

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

    @Override
    public void start(Stage primaryStage) throws Exception {
        final StackPane root = new StackPane();

        final TitledPane titledPane = new TitledPane();
        titledPane.setText("Title");
        titledPane.setAnimated(false);
        titledPane.setCollapsible(false);
        root.getChildren().add(titledPane);

        final ToggleButton button = new ToggleButton("Change");
        button.setOnAction(event -> {
            boolean selected = button.isSelected();
            final Region titleNode = (Region) titledPane.lookup(".title");
            if (selected) {
                titleNode.setBackground(new Background(new
BackgroundFill(Color.GREEN, null, null)));
            } else {
                titleNode.setBackground(null);
            }
        });

        button.setSelected(false);
        titledPane.setContent(button);

        final Scene scene = new Scene(root, 400, 400);

scene.getStylesheets().add(getClass().getResource("light.css").toExternalForm());

        primaryStage.setScene(scene);
        primaryStage.setTitle("TestApplication");
        primaryStage.show();
    }

}

Here is the CSS content for light.css
.titled-pane > .title {
    -fx-color: rgb(220, 220, 220);
}

/Sverre


Den tor. 1. nov. 2018 kl. 14:45 skrev David Grieve <david.grieve at oracle.com
>:

> It's hard to tell without some short, self-contained, correct example.
> This sample I crafted here doesn't reproduce the issue.
>
> @Override public void start(Stage primaryStage) {
>
>      final TitledPane titledPane =new TitledPane("Button Pane",new
> Button("Button"));
>      final HBox root =new HBox();
>      root.getChildren().add(titledPane);
>
>      primaryStage.setTitle("Maybe a TitledPane bug");
>      primaryStage.setScene(new Scene(root,300,250));
>      primaryStage.show();
>
>      final Region titleNode = (Region)titledPane.lookup("*.title");
>      titleNode.setBackground(new Background(new
> BackgroundFill(Color.GREEN,null,null)));
> }
>
>
>
> On 10/31/18 6:58 PM, Sverre Moe wrote:
> > 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
>
>

From david.grieve at oracle.com  Thu Nov  1 18:49:56 2018
From: david.grieve at oracle.com (David Grieve)
Date: Thu, 1 Nov 2018 14:49:56 -0400
Subject: Maybe a TitledPane bug
In-Reply-To: <CALAJ+5BAF9D5U=JUZ_+ZdSb2dViwBaODdYxYQ6F+bq=MdxOm6A@mail.gmail.com>
References: <CALAJ+5B8mEGL=oxeAEMDaa7KMLQCNg1MbRs7GG=DRbxjovrp1w@mail.gmail.com>
 <91c5e8eb-4614-2cbe-f424-2e82860d401d@oracle.com>
 <CALAJ+5BAF9D5U=JUZ_+ZdSb2dViwBaODdYxYQ6F+bq=MdxOm6A@mail.gmail.com>
Message-ID: <3456e8a0-8165-a32a-eb51-f2e0358f11cf@oracle.com>

On 11/1/18 2:19 PM, Sverre Moe wrote:

> scene.getStylesheets().add(getClass().getResource("light.css").toExternalForm());
>
>
> Here is the CSS content for light.css
> .titled-pane > .title {
> ? ? -fx-color: rgb(220, 220, 220);
>
Well, there you go. Your 'light.css' style trumps the setBackground. The 
reason for this is that this allows an application to be deployed with 
explicitly set, styleable properties - e.g. titleNode.setBackground(...) 
- but still allow that application to be styled from a stylesheet.

 From the JavaFX CSS reference:

The implementation allows designers to style an application by using style
     sheets to override property values set from code. This has implications for
     the cascade; particularly, when does a style from a style sheet override a
     value set from code? The JavaFX CSS implementation applies the following
     order of precedence;?a style from a user agent style sheet has lower
     priority than a value set from code, which has lower priority than a Scene
     or Parent style sheet. Inline styles have highest precedence. Style sheets
     from a Parent instance are considered to be more specific than those styles
     from Scene style sheets.
  


From mike.ennen at gmail.com  Thu Nov  1 22:06:18 2018
From: mike.ennen at gmail.com (Michael Ennen)
Date: Thu, 1 Nov 2018 15:06:18 -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: <CAOTPd674DR6QpoTErXbJ9=9T2fDhb9nrJKQO1nktpmBkjZHUQg@mail.gmail.com>

Also don't forget about the Windows build script:

https://github.com/javafxports/openjdk-jfx/blob/develop/tools/scripts/build.ps1

It is what I use to automate the process of building OpenJFX on Windows as
much as
possible. Any improvements to the script would be appreciated.

On Wed, Oct 31, 2018 at 7:03 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 ;)
>
>
>
>

-- 
Michael Ennen

From johan.vos at gluonhq.com  Fri Nov  2 08:59:30 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 2 Nov 2018 09:59:30 +0100
Subject: JavaFX 11.0.1-ea+1 release
Message-ID: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>

Hi,

We are about to release JavaFX 11.0.1, containing the fixes that made it
into the 11-dev repository.
An early-access build for this is available as SDK/jmods at
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
<http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip>
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip

The maven artifacts are available in the usual repositories, with version
tag being "11.0.1-ea+1" e.g.

org.openjfx:javafx-base:11.0.1-ea+1 (see
http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)

If we don't hear major issues with this ea, it should become the 11.0.1
release.

- Johan

From bourges.laurent at gmail.com  Fri Nov  2 10:52:24 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 2 Nov 2018 11:52:24 +0100
Subject: JavaFX 11.0.1-ea+1 release
In-Reply-To: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>
References: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>
Message-ID: <CAKjRUT5MGn2iZwGNDxTMftsV4UHv59jz_MgORyg-gf67Q4sAgA@mail.gmail.com>

Hi,

Could you publish the list of included bug fixed (JBS query) ?

Cheers,
Laurent

Le ven. 2 nov. 2018 ? 10:00, Johan Vos <johan.vos at gluonhq.com> a ?crit :

> Hi,
>
> We are about to release JavaFX 11.0.1, containing the fixes that made it
> into the 11-dev repository.
> An early-access build for this is available as SDK/jmods at
>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
> <
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
> >
>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
>
> The maven artifacts are available in the usual repositories, with version
> tag being "11.0.1-ea+1" e.g.
>
> org.openjfx:javafx-base:11.0.1-ea+1 (see
> http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)
>
> If we don't hear major issues with this ea, it should become the 11.0.1
> release.
>
> - Johan
>

From kevin.rushforth at oracle.com  Fri Nov  2 13:12:10 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 2 Nov 2018 06:12:10 -0700
Subject: JavaFX 11.0.1-ea+1 release
In-Reply-To: <CAKjRUT5MGn2iZwGNDxTMftsV4UHv59jz_MgORyg-gf67Q4sAgA@mail.gmail.com>
References: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>
 <CAKjRUT5MGn2iZwGNDxTMftsV4UHv59jz_MgORyg-gf67Q4sAgA@mail.gmail.com>
Message-ID: <4ddf5fa7-a85b-c7ec-6b45-81101fac5812@oracle.com>

The JBS query would only show up the one Marlin fix, because the rest 
were confidential security bugs. Here is the list, as seen in the 'hg log'

8194321: Update FX installer
8195879: Improve media support
8204365: Improve WebView processing
8204880: Enhance object method calls
8207387: WebView is not rendering html checkbox and radio buttons
8210386: Clipping problems with complex affine transforms: negative 
scaling factors or small scaling factors

-- Kevin


On 11/2/2018 3:52 AM, Laurent Bourg?s wrote:
> Hi,
>
> Could you publish the list of included bug fixed (JBS query) ?
>
> Cheers,
> Laurent
>
> Le ven. 2 nov. 2018 ? 10:00, Johan Vos <johan.vos at gluonhq.com> a ?crit :
>
>> Hi,
>>
>> We are about to release JavaFX 11.0.1, containing the fixes that made it
>> into the 11-dev repository.
>> An early-access build for this is available as SDK/jmods at
>>
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
>>
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>>
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
>>
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
>> <
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
>>
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
>>
>> The maven artifacts are available in the usual repositories, with version
>> tag being "11.0.1-ea+1" e.g.
>>
>> org.openjfx:javafx-base:11.0.1-ea+1 (see
>> http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)
>>
>> If we don't hear major issues with this ea, it should become the 11.0.1
>> release.
>>
>> - Johan
>>


From bourges.laurent at gmail.com  Fri Nov  2 13:19:38 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 2 Nov 2018 14:19:38 +0100
Subject: JavaFX 11.0.1-ea+1 release
In-Reply-To: <4ddf5fa7-a85b-c7ec-6b45-81101fac5812@oracle.com>
References: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>
 <CAKjRUT5MGn2iZwGNDxTMftsV4UHv59jz_MgORyg-gf67Q4sAgA@mail.gmail.com>
 <4ddf5fa7-a85b-c7ec-6b45-81101fac5812@oracle.com>
Message-ID: <CAKjRUT4Sy7Pbnmzc5scywnGro35bQVXUi2oHGjbpJpJfpDWj0w@mail.gmail.com>

Thanks,

That is important to me to share publicly release notes.

Cheers,
Laurent

Le ven. 2 nov. 2018 ? 14:12, Kevin Rushforth <kevin.rushforth at oracle.com> a
?crit :

> The JBS query would only show up the one Marlin fix, because the rest
> were confidential security bugs. Here is the list, as seen in the 'hg log'
>
> 8194321: Update FX installer
> 8195879: Improve media support
> 8204365: Improve WebView processing
> 8204880: Enhance object method calls
> 8207387: WebView is not rendering html checkbox and radio buttons
> 8210386: Clipping problems with complex affine transforms: negative
> scaling factors or small scaling factors
>
> -- Kevin
>
>
> On 11/2/2018 3:52 AM, Laurent Bourg?s wrote:
> > Hi,
> >
> > Could you publish the list of included bug fixed (JBS query) ?
> >
> > Cheers,
> > Laurent
> >
> > Le ven. 2 nov. 2018 ? 10:00, Johan Vos <johan.vos at gluonhq.com> a ?crit :
> >
> >> Hi,
> >>
> >> We are about to release JavaFX 11.0.1, containing the fixes that made it
> >> into the 11-dev repository.
> >> An early-access build for this is available as SDK/jmods at
> >>
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
> >>
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
> >>
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
> >>
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
> >> <
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
> >>
> >>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
> >>
> >> The maven artifacts are available in the usual repositories, with
> version
> >> tag being "11.0.1-ea+1" e.g.
> >>
> >> org.openjfx:javafx-base:11.0.1-ea+1 (see
> >>
> http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)
> >>
> >> If we don't hear major issues with this ea, it should become the 11.0.1
> >> release.
> >>
> >> - Johan
> >>
>
>

From rachel at merus.eu  Fri Nov  2 13:26:50 2018
From: rachel at merus.eu (Rachel Greenham)
Date: Fri, 2 Nov 2018 13:26:50 +0000
Subject: JavaBeanObjectPropertyBuilder has incomplete generics support
Message-ID: <4b6d56b5-8054-680d-67d6-56c821f4e313@merus.eu>

javax.beans.property.adapter.JavaBeanObjectPropertyBuilder seems to be 
only partially adapted for generics. The class itself has a generic type 
(class JavaBeanObjectPropertyBuilder<T>) and its build() method returns 
JavaBeanObjectProperty<T>, but the lack of other support means you can't 
fluently create a property without also suppressing "unchecked" warnings.

ie: One might want to do:

private ObjectProperty<Inet4Address> ip4Property;

...

this.ip4Property = JavaBeanObjectPropertyBuilder.create()
 ??? .bean(server)
 ??? .name("ip")
 ??? .build();

but this will produce "unchecked" warnings during compilation. Harmless 
but annoying when you want to keep it clean. As it stands, to compile 
cleanly you need to split it up:

var builder = new JavaBeanObjectPropertyBuilder<Inet4Address>();
builder.bean(server).name("ip"); // they return untyped builder
this.ip4Property = builder.build();

... or suppress the warning. I hate suppressing warnings. :-)

Proposed fix: (I don't have an OpenJFX build environment yet, this is 
the first time I've wanted to change something!)

* Each of the instance methods (except build()) to have declared return 
type JavaBeanObjectPropertyBuilder<T>. This allows chaining those fluent 
builder methods without losing the generic type.

* create() method to be:
public static <T> JavaBeanObjectPropertyBuilder<T> create() {
 ??? return new JavaBeanObjectPropertyBuilder<T>();
}

I think that's all it needs, and the latter only if you prefer to use 
the static builder factory method rather than just using the constructor 
directly. Then the first code example above would work cleanly as is. It 
also allows for callers to optionally explicitly specify the generic 
type to create() with eg: var builder = 
JavaBeanObjectPropertyBuilder.<Inet4Address>create().

As you can see all this is just generic type declarations, which should 
all be erased to cause no actual change to runtime. The effect on 
existing code should be null except that some people would be able to, 
if they want, remove the @SuppressWarnings
("unchecked") annotation they've so far had to put above it.

-- 
Rachel


From murali.billa at oracle.com  Fri Nov  2 14:17:46 2018
From: murali.billa at oracle.com (Murali Billa)
Date: Fri, 2 Nov 2018 07:17:46 -0700 (PDT)
Subject: [12] RFR: JDK-8213139: TooltipFXTest. testTooltipLeak  failing
 intermittently
Message-ID: <a2e9041b-ada4-4cff-99c9-1475fa8d0a77@default>

Hi Kevin, Arun, 

Please review the patch for the following bug:

JBS: https://bugs.openjdk.java.net/browse/JDK-8213139
Webrev: http://cr.openjdk.java.net/~mbilla/8213139/webrev.00/


Thanks,
Murali

From murali.billa at oracle.com  Fri Nov  2 14:32:31 2018
From: murali.billa at oracle.com (Murali Billa)
Date: Fri, 2 Nov 2018 07:32:31 -0700 (PDT)
Subject: [8u] RFR: JDK-8212014:
 JavaScriptBridgeTest::testBridgeExplicitOverloading test fails when run with
 newer JDK 8u
Message-ID: <1f7dbaa1-d9e7-4857-9ca3-217462dcbc88@default>

Hi Kevin, Arun, 

Please review the patch for the following bug:

JBS: https://bugs.openjdk.java.net/browse/JDK-8212014
Webrev: http://cr.openjdk.java.net/~mbilla/8212014/webrev.00/

Thanks,
Murali

From nlisker at gmail.com  Fri Nov  2 15:22:50 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 2 Nov 2018 17:22:50 +0200
Subject: JavaFX 11.0.1-ea+1 release
In-Reply-To: <CAKjRUT4Sy7Pbnmzc5scywnGro35bQVXUi2oHGjbpJpJfpDWj0w@mail.gmail.com>
References: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>
 <CAKjRUT5MGn2iZwGNDxTMftsV4UHv59jz_MgORyg-gf67Q4sAgA@mail.gmail.com>
 <4ddf5fa7-a85b-c7ec-6b45-81101fac5812@oracle.com>
 <CAKjRUT4Sy7Pbnmzc5scywnGro35bQVXUi2oHGjbpJpJfpDWj0w@mail.gmail.com>
Message-ID: <CA+0ynh_p1AmHjqquJApXKi7_WwSa9802vmoXze0vgTgjkXKemg@mail.gmail.com>

What is 8204880: Enhance object method calls? It's unviewable.

On Fri, Nov 2, 2018 at 3:20 PM Laurent Bourg?s <bourges.laurent at gmail.com>
wrote:

> Thanks,
>
> That is important to me to share publicly release notes.
>
> Cheers,
> Laurent
>
> Le ven. 2 nov. 2018 ? 14:12, Kevin Rushforth <kevin.rushforth at oracle.com>
> a
> ?crit :
>
> > The JBS query would only show up the one Marlin fix, because the rest
> > were confidential security bugs. Here is the list, as seen in the 'hg
> log'
> >
> > 8194321: Update FX installer
> > 8195879: Improve media support
> > 8204365: Improve WebView processing
> > 8204880: Enhance object method calls
> > 8207387: WebView is not rendering html checkbox and radio buttons
> > 8210386: Clipping problems with complex affine transforms: negative
> > scaling factors or small scaling factors
> >
> > -- Kevin
> >
> >
> > On 11/2/2018 3:52 AM, Laurent Bourg?s wrote:
> > > Hi,
> > >
> > > Could you publish the list of included bug fixed (JBS query) ?
> > >
> > > Cheers,
> > > Laurent
> > >
> > > Le ven. 2 nov. 2018 ? 10:00, Johan Vos <johan.vos at gluonhq.com> a
> ?crit :
> > >
> > >> Hi,
> > >>
> > >> We are about to release JavaFX 11.0.1, containing the fixes that made
> it
> > >> into the 11-dev repository.
> > >> An early-access build for this is available as SDK/jmods at
> > >>
> > >>
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
> > >>
> > >>
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
> > >>
> > >>
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
> > >>
> > >>
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
> > >> <
> > >>
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
> > >>
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
> > >>
> > >>
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
> > >>
> > >> The maven artifacts are available in the usual repositories, with
> > version
> > >> tag being "11.0.1-ea+1" e.g.
> > >>
> > >> org.openjfx:javafx-base:11.0.1-ea+1 (see
> > >>
> > http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/
> )
> > >>
> > >> If we don't hear major issues with this ea, it should become the
> 11.0.1
> > >> release.
> > >>
> > >> - Johan
> > >>
> >
> >
>

From kevin.rushforth at oracle.com  Fri Nov  2 15:28:59 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 2 Nov 2018 08:28:59 -0700
Subject: JavaFX 11.0.1-ea+1 release
In-Reply-To: <CA+0ynh_p1AmHjqquJApXKi7_WwSa9802vmoXze0vgTgjkXKemg@mail.gmail.com>
References: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>
 <CAKjRUT5MGn2iZwGNDxTMftsV4UHv59jz_MgORyg-gf67Q4sAgA@mail.gmail.com>
 <4ddf5fa7-a85b-c7ec-6b45-81101fac5812@oracle.com>
 <CAKjRUT4Sy7Pbnmzc5scywnGro35bQVXUi2oHGjbpJpJfpDWj0w@mail.gmail.com>
 <CA+0ynh_p1AmHjqquJApXKi7_WwSa9802vmoXze0vgTgjkXKemg@mail.gmail.com>
Message-ID: <5571158a-8e13-ff44-0431-2737cd5cba9f@oracle.com>

As I said, all but the Marlin fix are confidential security bugs. And 
no, I can't comment on them. If you are interested, you can go to 
Mercurial and look at the changeset diffs. Or you can refer to my email 
of Oct 16 with the aggregate webrev [1] for the set of fixes that were 
integrated after the October CPU release.

-- Kevin

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


On 11/2/2018 8:22 AM, Nir Lisker wrote:
> What is?8204880: Enhance object method calls? It's unviewable.
>
> On Fri, Nov 2, 2018 at 3:20 PM Laurent Bourg?s 
> <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> wrote:
>
>     Thanks,
>
>     That is important to me to share publicly release notes.
>
>     Cheers,
>     Laurent
>
>     Le ven. 2 nov. 2018 ? 14:12, Kevin Rushforth
>     <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> a
>     ?crit :
>
>     > The JBS query would only show up the one Marlin fix, because the
>     rest
>     > were confidential security bugs. Here is the list, as seen in
>     the 'hg log'
>     >
>     > 8194321: Update FX installer
>     > 8195879: Improve media support
>     > 8204365: Improve WebView processing
>     > 8204880: Enhance object method calls
>     > 8207387: WebView is not rendering html checkbox and radio buttons
>     > 8210386: Clipping problems with complex affine transforms: negative
>     > scaling factors or small scaling factors
>     >
>     > -- Kevin
>     >
>     >
>     > On 11/2/2018 3:52 AM, Laurent Bourg?s wrote:
>     > > Hi,
>     > >
>     > > Could you publish the list of included bug fixed (JBS query) ?
>     > >
>     > > Cheers,
>     > > Laurent
>     > >
>     > > Le ven. 2 nov. 2018 ? 10:00, Johan Vos <johan.vos at gluonhq.com
>     <mailto:johan.vos at gluonhq.com>> a ?crit :
>     > >
>     > >> Hi,
>     > >>
>     > >> We are about to release JavaFX 11.0.1, containing the fixes
>     that made it
>     > >> into the 11-dev repository.
>     > >> An early-access build for this is available as SDK/jmods at
>     > >>
>     > >>
>     >
>     http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
>     > >>
>     > >>
>     >
>     http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>     > >>
>     > >>
>     >
>     http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
>     > >>
>     > >>
>     >
>     http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
>     > >> <
>     > >>
>     >
>     http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>     > >>
>     >
>     http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
>     > >>
>     > >>
>     >
>     http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
>     > >>
>     > >> The maven artifacts are available in the usual repositories, with
>     > version
>     > >> tag being "11.0.1-ea+1" e.g.
>     > >>
>     > >> org.openjfx:javafx-base:11.0.1-ea+1 (see
>     > >>
>     >
>     http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)
>     > >>
>     > >> If we don't hear major issues with this ea, it should become
>     the 11.0.1
>     > >> release.
>     > >>
>     > >> - Johan
>     > >>
>     >
>     >
>


From nlisker at gmail.com  Fri Nov  2 15:30:06 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 2 Nov 2018 17:30:06 +0200
Subject: JavaFX 11.0.1-ea+1 release
In-Reply-To: <5571158a-8e13-ff44-0431-2737cd5cba9f@oracle.com>
References: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>
 <CAKjRUT5MGn2iZwGNDxTMftsV4UHv59jz_MgORyg-gf67Q4sAgA@mail.gmail.com>
 <4ddf5fa7-a85b-c7ec-6b45-81101fac5812@oracle.com>
 <CAKjRUT4Sy7Pbnmzc5scywnGro35bQVXUi2oHGjbpJpJfpDWj0w@mail.gmail.com>
 <CA+0ynh_p1AmHjqquJApXKi7_WwSa9802vmoXze0vgTgjkXKemg@mail.gmail.com>
 <5571158a-8e13-ff44-0431-2737cd5cba9f@oracle.com>
Message-ID: <CA+0ynh9tvihjNf7BRT_pAJL9kZECjWGe5JHnHU57+ptbfBBYJA@mail.gmail.com>

Oh, sorry, I missed the confidential part.

On Fri, Nov 2, 2018 at 5:29 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> As I said, all but the Marlin fix are confidential security bugs. And no,
> I can't comment on them. If you are interested, you can go to Mercurial and
> look at the changeset diffs. Or you can refer to my email of Oct 16 with
> the aggregate webrev [1] for the set of fixes that were integrated after
> the October CPU release.
>
> -- Kevin
>
> [1]
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-October/022702.html
>
>
> On 11/2/2018 8:22 AM, Nir Lisker wrote:
>
> What is 8204880: Enhance object method calls? It's unviewable.
>
> On Fri, Nov 2, 2018 at 3:20 PM Laurent Bourg?s <bourges.laurent at gmail.com>
> wrote:
>
>> Thanks,
>>
>> That is important to me to share publicly release notes.
>>
>> Cheers,
>> Laurent
>>
>> Le ven. 2 nov. 2018 ? 14:12, Kevin Rushforth <kevin.rushforth at oracle.com>
>> a
>> ?crit :
>>
>> > The JBS query would only show up the one Marlin fix, because the rest
>> > were confidential security bugs. Here is the list, as seen in the 'hg
>> log'
>> >
>> > 8194321: Update FX installer
>> > 8195879: Improve media support
>> > 8204365: Improve WebView processing
>> > 8204880: Enhance object method calls
>> > 8207387: WebView is not rendering html checkbox and radio buttons
>> > 8210386: Clipping problems with complex affine transforms: negative
>> > scaling factors or small scaling factors
>> >
>> > -- Kevin
>> >
>> >
>> > On 11/2/2018 3:52 AM, Laurent Bourg?s wrote:
>> > > Hi,
>> > >
>> > > Could you publish the list of included bug fixed (JBS query) ?
>> > >
>> > > Cheers,
>> > > Laurent
>> > >
>> > > Le ven. 2 nov. 2018 ? 10:00, Johan Vos <johan.vos at gluonhq.com> a
>> ?crit :
>> > >
>> > >> Hi,
>> > >>
>> > >> We are about to release JavaFX 11.0.1, containing the fixes that
>> made it
>> > >> into the 11-dev repository.
>> > >> An early-access build for this is available as SDK/jmods at
>> > >>
>> > >>
>> >
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
>> > >>
>> > >>
>> >
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>> > >>
>> > >>
>> >
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
>> > >>
>> > >>
>> >
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
>> > >> <
>> > >>
>> >
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>> > >>
>> >
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
>> > >>
>> > >>
>> >
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
>> > >>
>> > >> The maven artifacts are available in the usual repositories, with
>> > version
>> > >> tag being "11.0.1-ea+1" e.g.
>> > >>
>> > >> org.openjfx:javafx-base:11.0.1-ea+1 (see
>> > >>
>> >
>> http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)
>> > >>
>> > >> If we don't hear major issues with this ea, it should become the
>> 11.0.1
>> > >> release.
>> > >>
>> > >> - Johan
>> > >>
>> >
>> >
>>
>
>

From johan.vos at gluonhq.com  Fri Nov  2 18:38:44 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 2 Nov 2018 19:38:44 +0100
Subject: JavaFX 11.0.1-ea+1 release
In-Reply-To: <CAKjRUT4Sy7Pbnmzc5scywnGro35bQVXUi2oHGjbpJpJfpDWj0w@mail.gmail.com>
References: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>
 <CAKjRUT5MGn2iZwGNDxTMftsV4UHv59jz_MgORyg-gf67Q4sAgA@mail.gmail.com>
 <4ddf5fa7-a85b-c7ec-6b45-81101fac5812@oracle.com>
 <CAKjRUT4Sy7Pbnmzc5scywnGro35bQVXUi2oHGjbpJpJfpDWj0w@mail.gmail.com>
Message-ID: <CABxFH2HkD=m4jJ=4NhS0n8cpDT8MGRYmRnhxOak_C90OJ7JzyA@mail.gmail.com>

Absolutely. Since this is an ea, I didn't add a link to the release notes,
but once we go for 11.0.1, there should be release notes.

On Fri, Nov 2, 2018 at 2:19 PM Laurent Bourg?s <bourges.laurent at gmail.com>
wrote:

> Thanks,
>
> That is important to me to share publicly release notes.
>
> Cheers,
> Laurent
>
> Le ven. 2 nov. 2018 ? 14:12, Kevin Rushforth <kevin.rushforth at oracle.com>
> a ?crit :
>
>> The JBS query would only show up the one Marlin fix, because the rest
>> were confidential security bugs. Here is the list, as seen in the 'hg log'
>>
>> 8194321: Update FX installer
>> 8195879: Improve media support
>> 8204365: Improve WebView processing
>> 8204880: Enhance object method calls
>> 8207387: WebView is not rendering html checkbox and radio buttons
>> 8210386: Clipping problems with complex affine transforms: negative
>> scaling factors or small scaling factors
>>
>> -- Kevin
>>
>>
>> On 11/2/2018 3:52 AM, Laurent Bourg?s wrote:
>> > Hi,
>> >
>> > Could you publish the list of included bug fixed (JBS query) ?
>> >
>> > Cheers,
>> > Laurent
>> >
>> > Le ven. 2 nov. 2018 ? 10:00, Johan Vos <johan.vos at gluonhq.com> a ?crit
>> :
>> >
>> >> Hi,
>> >>
>> >> We are about to release JavaFX 11.0.1, containing the fixes that made
>> it
>> >> into the 11-dev repository.
>> >> An early-access build for this is available as SDK/jmods at
>> >>
>> >>
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
>> >>
>> >>
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>> >>
>> >>
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
>> >>
>> >>
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
>> >> <
>> >>
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>> >>
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
>> >>
>> >>
>> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
>> >>
>> >> The maven artifacts are available in the usual repositories, with
>> version
>> >> tag being "11.0.1-ea+1" e.g.
>> >>
>> >> org.openjfx:javafx-base:11.0.1-ea+1 (see
>> >>
>> http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)
>> >>
>> >> If we don't hear major issues with this ea, it should become the 11.0.1
>> >> release.
>> >>
>> >> - Johan
>> >>
>>
>>

From kevin.rushforth at oracle.com  Fri Nov  2 18:45:17 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 2 Nov 2018 11:45:17 -0700
Subject: JavaFX 11.0.1-ea+1 release
In-Reply-To: <CABxFH2HkD=m4jJ=4NhS0n8cpDT8MGRYmRnhxOak_C90OJ7JzyA@mail.gmail.com>
References: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>
 <CAKjRUT5MGn2iZwGNDxTMftsV4UHv59jz_MgORyg-gf67Q4sAgA@mail.gmail.com>
 <4ddf5fa7-a85b-c7ec-6b45-81101fac5812@oracle.com>
 <CAKjRUT4Sy7Pbnmzc5scywnGro35bQVXUi2oHGjbpJpJfpDWj0w@mail.gmail.com>
 <CABxFH2HkD=m4jJ=4NhS0n8cpDT8MGRYmRnhxOak_C90OJ7JzyA@mail.gmail.com>
Message-ID: <7caa5e20-2cb2-9798-fdb5-d526949eee69@oracle.com>

Yes, a good plan.

-- Kevin


On 11/2/2018 11:38 AM, Johan Vos wrote:
> Absolutely. Since this is an ea, I didn't add a link to the release 
> notes, but once we go for 11.0.1, there should be release notes.
>
> On Fri, Nov 2, 2018 at 2:19 PM Laurent Bourg?s 
> <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> wrote:
>
>     Thanks,
>
>     That is important to me to share publicly release notes.
>
>     Cheers,
>     Laurent
>
>     Le ven. 2 nov. 2018 ? 14:12, Kevin Rushforth
>     <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> a
>     ?crit?:
>
>         The JBS query would only show up the one Marlin fix, because
>         the rest
>         were confidential security bugs. Here is the list, as seen in
>         the 'hg log'
>
>         8194321: Update FX installer
>         8195879: Improve media support
>         8204365: Improve WebView processing
>         8204880: Enhance object method calls
>         8207387: WebView is not rendering html checkbox and radio buttons
>         8210386: Clipping problems with complex affine transforms:
>         negative
>         scaling factors or small scaling factors
>
>         -- Kevin
>
>
>         On 11/2/2018 3:52 AM, Laurent Bourg?s wrote:
>         > Hi,
>         >
>         > Could you publish the list of included bug fixed (JBS query) ?
>         >
>         > Cheers,
>         > Laurent
>         >
>         > Le ven. 2 nov. 2018 ? 10:00, Johan Vos
>         <johan.vos at gluonhq.com <mailto:johan.vos at gluonhq.com>> a ?crit :
>         >
>         >> Hi,
>         >>
>         >> We are about to release JavaFX 11.0.1, containing the fixes
>         that made it
>         >> into the 11-dev repository.
>         >> An early-access build for this is available as SDK/jmods at
>         >>
>         >>
>         http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
>         >>
>         >>
>         http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>         >>
>         >>
>         http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
>         >>
>         >>
>         http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
>         >> <
>         >>
>         http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>         >>
>         http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
>         >>
>         >>
>         http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
>         >>
>         >> The maven artifacts are available in the usual
>         repositories, with version
>         >> tag being "11.0.1-ea+1" e.g.
>         >>
>         >> org.openjfx:javafx-base:11.0.1-ea+1 (see
>         >>
>         http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)
>         >>
>         >> If we don't hear major issues with this ea, it should
>         become the 11.0.1
>         >> release.
>         >>
>         >> - Johan
>         >>
>


From johan.vos at gluonhq.com  Fri Nov  2 18:56:32 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 2 Nov 2018 19:56:32 +0100
Subject: Problems building openjfx
In-Reply-To: <CAOTPd674DR6QpoTErXbJ9=9T2fDhb9nrJKQO1nktpmBkjZHUQg@mail.gmail.com>
References: <20181031145703.Horde.ZQGCkkUxkwh_j5REAgomRw2@webmail.df.eu>
 <20181031150245.Horde.96kpsXfyvd5AkpBwsZ5GxQ1@webmail.df.eu>
 <CAOTPd674DR6QpoTErXbJ9=9T2fDhb9nrJKQO1nktpmBkjZHUQg@mail.gmail.com>
Message-ID: <CABxFH2Gf4msXUGgCx5_vX2wxLYiQWQfLCQUECS6MY2nM693DWg@mail.gmail.com>

Hi Michael,

What environment do you use to run that Windows build script?
The windows builds are the ones I still feel least comfortable about. We
tried to automate those on AdoptOpenJDK infrastructure, but they are using
Ansible for provisioning machines (for very good reasons), and we spent
days trying to come up with an Ansible script that allowed to build on
Windows, without 100% success.
Hence, we currently create the windows build on a Windows machine with a
fixed setup. It would be better of course to move more of the environment
and context parameters to the build procedure itself, and your script seems
a step in that direction. But what infrastructure do you use to run this?

- Johan

On Thu, Nov 1, 2018 at 11:17 PM Michael Ennen <mike.ennen at gmail.com> wrote:

> Also don't forget about the Windows build script:
>
>
> https://github.com/javafxports/openjdk-jfx/blob/develop/tools/scripts/build.ps1
>
> It is what I use to automate the process of building OpenJFX on Windows as
> much as
> possible. Any improvements to the script would be appreciated.
>
> On Wed, Oct 31, 2018 at 7:03 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 ;)
> >
> >
> >
> >
>
> --
> Michael Ennen
>

From mp at jugs.org  Sun Nov  4 14:56:21 2018
From: mp at jugs.org (Michael Paus)
Date: Sun, 4 Nov 2018 15:56:21 +0100
Subject: JavaFX 11.0.1-ea+1 release
In-Reply-To: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>
References: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>
Message-ID: <db8689d9-8dbc-89de-3756-efb1fc6c8344@jugs.org>

My application is reporting the following values for the respective 
properties:

java.runtime.version: 11.0.1+13
java.class.version: 55.0
java.version: 11.0.1
javafx.version: 11

Shouldn't "javafx.version" follow the same naming conventions as used by 
"java.version"?


Am 02.11.18 um 09:59 schrieb Johan Vos:
> Hi,
>
> We are about to release JavaFX 11.0.1, containing the fixes that made it
> into the 11-dev repository.
> An early-access build for this is available as SDK/jmods at
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
> <http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip>
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
>
> The maven artifacts are available in the usual repositories, with version
> tag being "11.0.1-ea+1" e.g.
>
> org.openjfx:javafx-base:11.0.1-ea+1 (see
> http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)
>
> If we don't hear major issues with this ea, it should become the 11.0.1
> release.
>
> - Johan



From jose.pereda at gluonhq.com  Sun Nov  4 15:17:56 2018
From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=)
Date: Sun, 4 Nov 2018 16:17:56 +0100
Subject: Running JavaFX-11 applications from within Eclipse fails
In-Reply-To: <eb8f0df2-d6c3-5b68-665e-90f38f553234@oracle.com>
References: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
 <CABxFH2HdykTWPoRcuWsLK25P-a5tc3JTREbDh6f9X1TRnCEU+w@mail.gmail.com>
 <eb8f0df2-d6c3-5b68-665e-90f38f553234@oracle.com>
Message-ID: <CAGMSBrJip3RVgmYi-Qmd33-ZDuJ-oyFcpFeY2W+_vTm_dvngng@mail.gmail.com>

I've just noticed that this issue happens not only with Maven but also with
Gradle projects (Gradle + Eclipse 2018-09 + Windows with Oracle JDK 1.8),
running gradle tasks from Eclipse.

The same proposed workaround can be applied to the build file:

run {

    systemProperty "java.library.path", "C:\tmp"

}




On Mon, Oct 22, 2018 at 4:43 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

>
> > 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 tom.schindl at bestsolution.at  Sun Nov  4 16:38:53 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Sun, 4 Nov 2018 17:38:53 +0100
Subject: Running JavaFX-11 applications from within Eclipse fails
In-Reply-To: <CAGMSBrJip3RVgmYi-Qmd33-ZDuJ-oyFcpFeY2W+_vTm_dvngng@mail.gmail.com>
References: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
 <CABxFH2HdykTWPoRcuWsLK25P-a5tc3JTREbDh6f9X1TRnCEU+w@mail.gmail.com>
 <eb8f0df2-d6c3-5b68-665e-90f38f553234@oracle.com>
 <CAGMSBrJip3RVgmYi-Qmd33-ZDuJ-oyFcpFeY2W+_vTm_dvngng@mail.gmail.com>
Message-ID: <2D6BD968-CF35-41CB-A545-DC7F34BD3FF9@bestsolution.at>

I think the more general problem is that they don?t run on the module-path - in the m2e case this because the modules are transitive deps and those are not supported properly

Tom

Von meinem iPhone gesendet

> Am 04.11.2018 um 16:17 schrieb Jos? Pereda <jose.pereda at gluonhq.com>:
> 
> I've just noticed that this issue happens not only with Maven but also with
> Gradle projects (Gradle + Eclipse 2018-09 + Windows with Oracle JDK 1.8),
> running gradle tasks from Eclipse.
> 
> The same proposed workaround can be applied to the build file:
> 
> run {
> 
>    systemProperty "java.library.path", "C:\tmp"
> 
> }
> 
> 
> 
> 
> On Mon, Oct 22, 2018 at 4:43 PM Kevin Rushforth <kevin.rushforth at oracle.com>
> wrote:
> 
>> 
>>> 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 mike at plan99.net  Sun Nov  4 19:17:20 2018
From: mike at plan99.net (Mike Hearn)
Date: Sun, 4 Nov 2018 11:17:20 -0800
Subject: DropShadow effect kills gfx responsiveness OS-wide
Message-ID: <CANEZrP2STwz0vYytJPYMyWBZAt_6cryQh7cci3AdPxFKehc-4A@mail.gmail.com>

I'm on macOS High Sierra with a very new and very high end MacBook Pro.

I have a pretty basic GUI that uses translucency fairly aggressively. I
added a DropShadow effect to some nodes, which looks great, but to my great
surprise this one line of code kills the UI performance not of my app, but
other apps on the same machine, specifically:

   - I can see the frame rate of the dock's zoom animation is lower
   - Chrome becomes nearly unusable. Opening a new tab goes from nearly
   instant to sluggish, this is very noticeable if you watch the tab in the
   tab strip itself expand. It goes from smooth and fast to being able to see
   the individual frames.

Stopping my app immediately restores the other apps to full framerate. So
presumably, the DropShadow shader is triggering some slow path not only in
JavaFX but the GPU or driver itself. I've experimenting with caching and
that speeds up scrolling of nodes with drop shadows in my own app, but the
OS-wide slowdown remains.

Has anyone seen anything like this before? I'm suspecting that I'll need to
render my own drop shadow effect using static bitmaps to work around it.

I don't have access to the OpenJDK bug tracker so I can't file a bug report
for this and I'm not sure how to reproduce it reliably. It's the first time
I noticed it.

From nlisker at gmail.com  Sun Nov  4 19:22:53 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 4 Nov 2018 21:22:53 +0200
Subject: DropShadow effect kills gfx responsiveness OS-wide
In-Reply-To: <CANEZrP2STwz0vYytJPYMyWBZAt_6cryQh7cci3AdPxFKehc-4A@mail.gmail.com>
References: <CANEZrP2STwz0vYytJPYMyWBZAt_6cryQh7cci3AdPxFKehc-4A@mail.gmail.com>
Message-ID: <CA+0ynh9W-2HXgppMt+OjRpveQO=PBEOXfaV7qbo-29UjpSW8SQ@mail.gmail.com>

>
> I don't have access to the OpenJDK bug tracker so I can't file a bug
> report for this
>

You can do it at https://bugreport.java.com/bugreport/

On Sun, Nov 4, 2018 at 9:18 PM Mike Hearn <mike at plan99.net> wrote:

> I'm on macOS High Sierra with a very new and very high end MacBook Pro.
>
> I have a pretty basic GUI that uses translucency fairly aggressively. I
> added a DropShadow effect to some nodes, which looks great, but to my great
> surprise this one line of code kills the UI performance not of my app, but
> other apps on the same machine, specifically:
>
>    - I can see the frame rate of the dock's zoom animation is lower
>    - Chrome becomes nearly unusable. Opening a new tab goes from nearly
>    instant to sluggish, this is very noticeable if you watch the tab in the
>    tab strip itself expand. It goes from smooth and fast to being able to
> see
>    the individual frames.
>
> Stopping my app immediately restores the other apps to full framerate. So
> presumably, the DropShadow shader is triggering some slow path not only in
> JavaFX but the GPU or driver itself. I've experimenting with caching and
> that speeds up scrolling of nodes with drop shadows in my own app, but the
> OS-wide slowdown remains.
>
> Has anyone seen anything like this before? I'm suspecting that I'll need to
> render my own drop shadow effect using static bitmaps to work around it.
>
> I don't have access to the OpenJDK bug tracker so I can't file a bug report
> for this and I'm not sure how to reproduce it reliably. It's the first time
> I noticed it.
>

From johan.vos at gluonhq.com  Sun Nov  4 19:26:18 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Sun, 4 Nov 2018 20:26:18 +0100
Subject: JavaFX 11.0.1-ea+1 release
In-Reply-To: <db8689d9-8dbc-89de-3756-efb1fc6c8344@jugs.org>
References: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>
 <db8689d9-8dbc-89de-3756-efb1fc6c8344@jugs.org>
Message-ID: <CABxFH2Hnd+Xv=5ke=4zFUQv4WYLG_4CJHCLWNsGmy1QjkAWVvA@mail.gmail.com>

It should.
I have the following:
javafx.version = 11.0.1-ea

Are you using an SDK or maven artifacts? For which platform?

- Johan

On Sun, Nov 4, 2018 at 4:07 PM Michael Paus <mp at jugs.org> wrote:

> My application is reporting the following values for the respective
> properties:
>
> java.runtime.version: 11.0.1+13
> java.class.version: 55.0
> java.version: 11.0.1
> javafx.version: 11
>
> Shouldn't "javafx.version" follow the same naming conventions as used by
> "java.version"?
>
>
> Am 02.11.18 um 09:59 schrieb Johan Vos:
> > Hi,
> >
> > We are about to release JavaFX 11.0.1, containing the fixes that made it
> > into the 11-dev repository.
> > An early-access build for this is available as SDK/jmods at
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
> > <
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
> >
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
> >
> http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
> >
> > The maven artifacts are available in the usual repositories, with version
> > tag being "11.0.1-ea+1" e.g.
> >
> > org.openjfx:javafx-base:11.0.1-ea+1 (see
> > http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/
> )
> >
> > If we don't hear major issues with this ea, it should become the 11.0.1
> > release.
> >
> > - Johan
>
>
>

From tom.schindl at bestsolution.at  Sun Nov  4 19:48:09 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Sun, 4 Nov 2018 20:48:09 +0100
Subject: DropShadow effect kills gfx responsiveness OS-wide
In-Reply-To: <CA+0ynh9W-2HXgppMt+OjRpveQO=PBEOXfaV7qbo-29UjpSW8SQ@mail.gmail.com>
References: <CANEZrP2STwz0vYytJPYMyWBZAt_6cryQh7cci3AdPxFKehc-4A@mail.gmail.com>
 <CA+0ynh9W-2HXgppMt+OjRpveQO=PBEOXfaV7qbo-29UjpSW8SQ@mail.gmail.com>
Message-ID: <fc3490c2-3264-19b7-91e6-833bcdf67ea9@bestsolution.at>

I've never seen and don't see it slowing down other applications (I'm on
a MacBook Pro 13'') but I reported the DropShadow slow down and
documented the solution [1].

Tom

[1]
https://openjfx-dev.openjdk.java.narkive.com/I8NIK0db/bad-dropshadow-performance

On 04.11.18 20:22, Nir Lisker wrote:
>>
>> I don't have access to the OpenJDK bug tracker so I can't file a bug
>> report for this
>>
> 
> You can do it at https://bugreport.java.com/bugreport/
> 
> On Sun, Nov 4, 2018 at 9:18 PM Mike Hearn <mike at plan99.net> wrote:
> 
>> I'm on macOS High Sierra with a very new and very high end MacBook Pro.
>>
>> I have a pretty basic GUI that uses translucency fairly aggressively. I
>> added a DropShadow effect to some nodes, which looks great, but to my great
>> surprise this one line of code kills the UI performance not of my app, but
>> other apps on the same machine, specifically:
>>
>>    - I can see the frame rate of the dock's zoom animation is lower
>>    - Chrome becomes nearly unusable. Opening a new tab goes from nearly
>>    instant to sluggish, this is very noticeable if you watch the tab in the
>>    tab strip itself expand. It goes from smooth and fast to being able to
>> see
>>    the individual frames.
>>
>> Stopping my app immediately restores the other apps to full framerate. So
>> presumably, the DropShadow shader is triggering some slow path not only in
>> JavaFX but the GPU or driver itself. I've experimenting with caching and
>> that speeds up scrolling of nodes with drop shadows in my own app, but the
>> OS-wide slowdown remains.
>>
>> Has anyone seen anything like this before? I'm suspecting that I'll need to
>> render my own drop shadow effect using static bitmaps to work around it.
>>
>> I don't have access to the OpenJDK bug tracker so I can't file a bug report
>> for this and I'm not sure how to reproduce it reliably. It's the first time
>> I noticed it.
>>

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

From mp at jugs.org  Mon Nov  5 08:54:18 2018
From: mp at jugs.org (Michael Paus)
Date: Mon, 5 Nov 2018 09:54:18 +0100
Subject: JavaFX 11.0.1-ea+1 release
In-Reply-To: <CABxFH2Hnd+Xv=5ke=4zFUQv4WYLG_4CJHCLWNsGmy1QjkAWVvA@mail.gmail.com>
References: <CABxFH2HPc9Yv9T28YDy4=Ey-7bQTjUsZdh1Pn7ikjqeQ7p+R4A@mail.gmail.com>
 <db8689d9-8dbc-89de-3756-efb1fc6c8344@jugs.org>
 <CABxFH2Hnd+Xv=5ke=4zFUQv4WYLG_4CJHCLWNsGmy1QjkAWVvA@mail.gmail.com>
Message-ID: <f9c10945-b4ac-8660-90a4-dcac8d3d0afd@jugs.org>

Hi,
sorry fo the confusion. I thought I was using the 11.0.1 SDK on my Mac
but actually I wasn't. Eclipse again played a prank on me with the 
modulepath.

Am 04.11.18 um 20:26 schrieb Johan Vos:
> It should.
> I have the following:
> javafx.version = 11.0.1-ea
>
> Are you using an SDK or maven artifacts? For which platform?
>
> - Johan
>
> On Sun, Nov 4, 2018 at 4:07 PM Michael Paus <mp at jugs.org 
> <mailto:mp at jugs.org>> wrote:
>
>     My application is reporting the following values for the respective
>     properties:
>
>     java.runtime.version: 11.0.1+13
>     java.class.version: 55.0
>     java.version: 11.0.1
>     javafx.version: 11
>
>     Shouldn't "javafx.version" follow the same naming conventions as
>     used by
>     "java.version"?
>
>
>     Am 02.11.18 um 09:59 schrieb Johan Vos:
>     > Hi,
>     >
>     > We are about to release JavaFX 11.0.1, containing the fixes that
>     made it
>     > into the 11-dev repository.
>     > An early-access build for this is available as SDK/jmods at
>     >
>     http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
>     >
>     http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>     >
>     http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
>     >
>     http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
>     >
>     <http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip>
>     >
>     http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
>     >
>     http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
>     >
>     > The maven artifacts are available in the usual repositories,
>     with version
>     > tag being "11.0.1-ea+1" e.g.
>     >
>     > org.openjfx:javafx-base:11.0.1-ea+1 (see
>     >
>     http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)
>     >
>     > If we don't hear major issues with this ea, it should become the
>     11.0.1
>     > release.
>     >
>     > - Johan
>
>


From rr at ktgis.de  Mon Nov  5 11:03:12 2018
From: rr at ktgis.de (=?UTF-8?B?UmVuw6kgUmVpw58=?=)
Date: Mon, 5 Nov 2018 12:03:12 +0100
Subject: Support of SVG ImageLoader in JavaFX
Message-ID: <8c37ba41-ef58-13b3-c16a-8335964b1671@ktgis.de>

Hi,

In Java 8 I used a SVGImageLoader to support SVGs in css-Files, 
something like
-fx-background-image : url("/svg/minusicon.svg");

see also 
https://blog.codecentric.de/en/2015/03/adding-custom-image-renderer-javafx-8/

In Java 11 I get an IllegalAccessError

java.lang.IllegalAccessError: superinterface check failed: class 
SvgImageLoaderFactory (in unnamed module @0x2a8d6c41) cannot access 
class com.sun.javafx.iio.ImageLoaderFactory (in module javafx.graphics) 
because module javafx.graphics does not export com.sun.javafx.iio to 
unnamed module @0x2a8d6c41

I know, the ImageLoaderFactory is not part of the official JavaFX public 
API. But, why not? Why it is no more possible to write an own 
ImageLoader? It is planned for the future?

Is there another possibility to support SVGs in JavaFX applications?
Otherwise I have to convert all SVGs to png or jpegs, but this will be a 
step backwards for me.

Thanks,

-- 

Ren? Rei?


From tom.schindl at bestsolution.at  Mon Nov  5 12:03:05 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Mon, 5 Nov 2018 13:03:05 +0100
Subject: Support of SVG ImageLoader in JavaFX
In-Reply-To: <8c37ba41-ef58-13b3-c16a-8335964b1671@ktgis.de>
References: <8c37ba41-ef58-13b3-c16a-8335964b1671@ktgis.de>
Message-ID: <c7631739-675b-a2c8-1c85-d46d6076a0f8@bestsolution.at>

You can use a custom URLStreamHandler not?

Tom

On 05.11.18 12:03, Ren? Rei? wrote:
> Hi,
> 
> In Java 8 I used a SVGImageLoader to support SVGs in css-Files,
> something like
> -fx-background-image : url("/svg/minusicon.svg");
> 
> see also
> https://blog.codecentric.de/en/2015/03/adding-custom-image-renderer-javafx-8/
> 
> 
> In Java 11 I get an IllegalAccessError
> 
> java.lang.IllegalAccessError: superinterface check failed: class
> SvgImageLoaderFactory (in unnamed module @0x2a8d6c41) cannot access
> class com.sun.javafx.iio.ImageLoaderFactory (in module javafx.graphics)
> because module javafx.graphics does not export com.sun.javafx.iio to
> unnamed module @0x2a8d6c41
> 
> I know, the ImageLoaderFactory is not part of the official JavaFX public
> API. But, why not? Why it is no more possible to write an own
> ImageLoader? It is planned for the future?
> 
> Is there another possibility to support SVGs in JavaFX applications?
> Otherwise I have to convert all SVGs to png or jpegs, but this will be a
> step backwards for me.
> 
> Thanks,
> 

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

From john at status6.com  Mon Nov  5 18:20:13 2018
From: john at status6.com (John Neffenger)
Date: Mon, 5 Nov 2018 10:20:13 -0800
Subject: Bitwise puzzle in com.sun.glass.ui.monocle.Framebuffer
Message-ID: <6c09225e-7d49-8721-5560-96ef30206c6e@status6.com>

I am completely puzzled by the bitwise operations in the Framebuffer 
class (package com.sun.glass.ui.monocle). I'm overriding its methods to 
support a "Y8" 8-bit grayscale frame buffer, yet I have no idea why it's 
doing what it's doing. Can anyone shed light on its complexity?

The Framebuffer class converts a buffer with 32-bit pixels in ARGB32 
format into a buffer with 16-bit pixels in RGB565 format, as illustrated 
below for one pixel.

aaaa aaaa  rrrr rrrr  gggg gggg  bbbb bbbb
     --> rrrr rggg  gggb bbbb

I would convert the pixels with a method like the following:

void copyNextPixel(IntBuffer source, ShortBuffer target) {
     int pixel32 = source.get();
     int r = (pixel32 >> 8) & 0xF800;
     int g = (pixel32 >> 5) & 0x07E0;
     int b = (pixel32 >> 3) & 0x001F;
     int pixel16 = r | g | b;
     target.put((short) pixel16);
}

The JavaFX Framebuffer class converts the pixels like this:

void copyNextPixelOriginal(IntBuffer source, ShortBuffer target) {
     int pixel32 = source.get();
     int r = ((((pixel32 >> 19) & 31) * 539219) >> 8) & (31 << 11);
     int g = ((((pixel32 >> 10) & 63) * 265395) >> 13) & (63 << 5);
     int b = (((pixel32 >> 3) & 31) * 539219) >> 19;
     int pixel16 = r | g | b;
     target.put((short) pixel16);
}

Both of these methods produce identical results when tested against all 
16,777,216 possible 24-bit RGB values. To understand what is happening, 
I show each step in the creation and positioning of the 5-bit red color 
value for both algorithms below (best viewed in a monospaced font).

My version
     int r = (pixel32 >> 8) & 0xF800;

____ ____  xxxx xxxx  ____ ____  ____ ____  pixel32 (x = red)
____ ____  ____ ____  xxxx xxxx  ____ ____  >> 8
0000 0000  0000 0000  xxxx x000  0000 0000  & 0xF800

JavaFX version
     int r = ((((pixel32 >> 19) & 31) * 539219) >> 8) & (31 << 11);

____ ____  xxxx xxxx  ____ ____  ____ ____  pixel32 (x = red)
____ ____  ____ ____  ____ ____  ___x xxxx  >> 19
0000 0000  0000 0000  0000 0000  000x xxxx  & 31 = 0x1F
0000 0000  xxxx x___  ____ ____  ____ ____  * 539219 = 2^19 + 14931
0000 0000  0000 0000  xxxx x___  ____ ____  >> 8
0000 0000  0000 0000  xxxx x000  0000 0000  & (31 << 11) = 0xF800

Why all the back and forth? Why introduce varying bits to the right of 
the red color value (* 539219), only to clear those bits later? The last 
three steps could be replaced with a single logical shift left operation 
(<< 11).

The Framebuffer class was added to the repository on January 21, 2014, 
by Daniel Blaukopf.

Thank you,
John


From johan.vos at gluonhq.com  Tue Nov  6 13:15:52 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 6 Nov 2018 14:15:52 +0100
Subject: release notes for JavaFX 11.0.1
Message-ID: <CABxFH2FUFh-cqNwEqYX0N-QNZs_JPBaKe2iEx2dtLbr0fV4RCA@mail.gmail.com>

The 11.0.1 tag is added to the 11-dev repository, and the artifacts has
been built.
I created a JBS issue [1] and webrev [2] for the release notes.

[1] https://bugs.openjdk.java.net/browse/JDK-8213417
[2] http://cr.openjdk.java.net/~jvos/8213417/webrev.00/

- Johan

From kevin.rushforth at oracle.com  Tue Nov  6 13:25:19 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 6 Nov 2018 05:25:19 -0800
Subject: release notes for JavaFX 11.0.1
In-Reply-To: <CABxFH2FUFh-cqNwEqYX0N-QNZs_JPBaKe2iEx2dtLbr0fV4RCA@mail.gmail.com>
References: <CABxFH2FUFh-cqNwEqYX0N-QNZs_JPBaKe2iEx2dtLbr0fV4RCA@mail.gmail.com>
Message-ID: <15c67a82-8719-3031-e349-e3293974ec14@oracle.com>

Release notes look good.

+1

-- Kevin

On 11/6/2018 5:15 AM, Johan Vos wrote:
> The 11.0.1 tag is added to the 11-dev repository, and the artifacts has
> been built.
> I created a JBS issue [1] and webrev [2] for the release notes.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8213417
> [2] http://cr.openjdk.java.net/~jvos/8213417/webrev.00/
>
> - Johan


From carl at bekwam.com  Tue Nov  6 17:25:19 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Tue, 6 Nov 2018 12:25:19 -0500
Subject: AudioClip Missing glib-lite.dll
Message-ID: <02a401d475f5$b14d2f90$13e78eb0$@bekwam.com>

Hi,

 

I'm running OpenJFX 8u202-b02.  I'm getting a missing DLL error on an
AudioClip object creation statement.  The Java code and stack trace follow.

 

I didn't compile webkit.  If that's needed, can someone tell me which target
or makefile to run?  The Wiki shows the dependencies like cmake but not any
actual commands or Gradle tasks.

 

If I switch to the Oracle JDK 8u192, the code works.  There is a
glib-lite.dll in the Oracle jre\bin folder.

 

Thanks,

Carl

 

clipMap.put( "0", new AudioClip(f.toURI().toString()));

 

Caused by: java.lang.UnsatisfiedLinkError: Can't load library:
D:\Java\open-jdk8u181-b13-openjfx\jre\bin\glib-lite.dll

                at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1827)

                at java.lang.Runtime.load0(Runtime.java:809)

                at java.lang.System.load(System.java:1086)

                at
com.sun.glass.utils.NativeLibLoader.loadLibraryFullPath(NativeLibLoader.java
:201)

                at
com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java
:94)

                at
com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:39)

                at
com.sun.media.jfxmediaimpl.NativeMediaManager.lambda$new$0(NativeMediaManage
r.java:108)

                at java.security.AccessController.doPrivileged(Native
Method)

                at
com.sun.media.jfxmediaimpl.NativeMediaManager.<init>(NativeMediaManager.java
:106)

                at
com.sun.media.jfxmediaimpl.NativeMediaManager$NativeMediaManagerInitializer.
<clinit>(NativeMediaManager.java:77)

                at
com.sun.media.jfxmediaimpl.NativeMediaManager.getDefaultInstance(NativeMedia
Manager.java:89)

                at
com.sun.media.jfxmedia.MediaManager.canPlayProtocol(MediaManager.java:78)

                at
com.sun.media.jfxmedia.locator.Locator.<init>(Locator.java:239)

                at
com.sun.media.jfxmediaimpl.NativeMediaAudioClip.<init>(NativeMediaAudioClip.
java:53)

                at
com.sun.media.jfxmediaimpl.NativeMediaAudioClip.load(NativeMediaAudioClip.ja
va:63)

                at
com.sun.media.jfxmediaimpl.AudioClipProvider.load(AudioClipProvider.java:66)

                at com.sun.media.jfxmedia.AudioClip.load(AudioClip.java:135)

                at javafx.scene.media.AudioClip.<init>(AudioClip.java:83)

                at com.mycompany.audio.AudioBean.load(AudioBean.java:171)


From kevin.rushforth at oracle.com  Tue Nov  6 18:06:05 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 6 Nov 2018 10:06:05 -0800
Subject: AudioClip Missing glib-lite.dll
In-Reply-To: <02a401d475f5$b14d2f90$13e78eb0$@bekwam.com>
References: <02a401d475f5$b14d2f90$13e78eb0$@bekwam.com>
Message-ID: <eafad4f4-e5f3-650a-d440-31280f1ec90b@oracle.com>

When you say "OpenJFX 8u202-b02" I'm assuming that you mean a local 
build of FX 8u-dev using the 8u202-b02 tag?

You don't need to compile webkit, but you do need to compile media 
(which is also not built by default). To compile media you need to run:

gradle -PCOMPILE_MEDIA=true ...

-- Kevin


On 11/6/2018 9:25 AM, carl at bekwam.com wrote:
> Hi,
>
>   
>
> I'm running OpenJFX 8u202-b02.  I'm getting a missing DLL error on an
> AudioClip object creation statement.  The Java code and stack trace follow.
>
>   
>
> I didn't compile webkit.  If that's needed, can someone tell me which target
> or makefile to run?  The Wiki shows the dependencies like cmake but not any
> actual commands or Gradle tasks.
>
>   
>
> If I switch to the Oracle JDK 8u192, the code works.  There is a
> glib-lite.dll in the Oracle jre\bin folder.
>
>   
>
> Thanks,
>
> Carl
>
>   
>
> clipMap.put( "0", new AudioClip(f.toURI().toString()));
>
>   
>
> Caused by: java.lang.UnsatisfiedLinkError: Can't load library:
> D:\Java\open-jdk8u181-b13-openjfx\jre\bin\glib-lite.dll
>
>                  at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1827)
>
>                  at java.lang.Runtime.load0(Runtime.java:809)
>
>                  at java.lang.System.load(System.java:1086)
>
>                  at
> com.sun.glass.utils.NativeLibLoader.loadLibraryFullPath(NativeLibLoader.java
> :201)
>
>                  at
> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java
> :94)
>
>                  at
> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:39)
>
>                  at
> com.sun.media.jfxmediaimpl.NativeMediaManager.lambda$new$0(NativeMediaManage
> r.java:108)
>
>                  at java.security.AccessController.doPrivileged(Native
> Method)
>
>                  at
> com.sun.media.jfxmediaimpl.NativeMediaManager.<init>(NativeMediaManager.java
> :106)
>
>                  at
> com.sun.media.jfxmediaimpl.NativeMediaManager$NativeMediaManagerInitializer.
> <clinit>(NativeMediaManager.java:77)
>
>                  at
> com.sun.media.jfxmediaimpl.NativeMediaManager.getDefaultInstance(NativeMedia
> Manager.java:89)
>
>                  at
> com.sun.media.jfxmedia.MediaManager.canPlayProtocol(MediaManager.java:78)
>
>                  at
> com.sun.media.jfxmedia.locator.Locator.<init>(Locator.java:239)
>
>                  at
> com.sun.media.jfxmediaimpl.NativeMediaAudioClip.<init>(NativeMediaAudioClip.
> java:53)
>
>                  at
> com.sun.media.jfxmediaimpl.NativeMediaAudioClip.load(NativeMediaAudioClip.ja
> va:63)
>
>                  at
> com.sun.media.jfxmediaimpl.AudioClipProvider.load(AudioClipProvider.java:66)
>
>                  at com.sun.media.jfxmedia.AudioClip.load(AudioClip.java:135)
>
>                  at javafx.scene.media.AudioClip.<init>(AudioClip.java:83)
>
>                  at com.mycompany.audio.AudioBean.load(AudioBean.java:171)
>


From carl at bekwam.com  Tue Nov  6 20:48:01 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Tue, 6 Nov 2018 15:48:01 -0500
Subject: AudioClip Missing glib-lite.dll
In-Reply-To: <eafad4f4-e5f3-650a-d440-31280f1ec90b@oracle.com>
References: <02a401d475f5$b14d2f90$13e78eb0$@bekwam.com>
 <eafad4f4-e5f3-650a-d440-31280f1ec90b@oracle.com>
Message-ID: <035c01d47612$02097490$061c5db0$@bekwam.com>

Hi Kevin,

That's correct.  I just pulled and am building the tip.  Commit af7c270b.

I tried the -P option.  It looks like a lot of it built, but I'm getting the following error.  

> Task :media:buildWinPlugins
make: Entering directory '/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxplugins'
make TARGET=/cygdrive/d/hg/rt/modules/media/build/native/win/Release/baseclasses.lib -f Makefile.BaseClasses
cygpath: cannot create short name of C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses
make[1]: Entering directory '/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxplugins'
Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...

I think this leads to a linker error later on.

I believe I have all the DirectX stuff from Visual Studio 2017 on my harddisk.  I tried setting DXSDK_DIR but that didn't affect the path listed above.  I don't have a \Program Files\Microsoft SDKs\Windows folder so I'm not sure where that path is coming from.

-Carl

-----Original Message-----
From: Kevin Rushforth <kevin.rushforth at oracle.com> 
Sent: Tuesday, November 6, 2018 1:06 PM
To: carl at bekwam.com; openjfx-dev at openjdk.java.net
Subject: Re: AudioClip Missing glib-lite.dll

When you say "OpenJFX 8u202-b02" I'm assuming that you mean a local build of FX 8u-dev using the 8u202-b02 tag?

You don't need to compile webkit, but you do need to compile media (which is also not built by default). To compile media you need to run:

gradle -PCOMPILE_MEDIA=true ...

-- Kevin


On 11/6/2018 9:25 AM, carl at bekwam.com wrote:
> Hi,
>
>   
>
> I'm running OpenJFX 8u202-b02.  I'm getting a missing DLL error on an 
> AudioClip object creation statement.  The Java code and stack trace follow.
>
>   
>
> I didn't compile webkit.  If that's needed, can someone tell me which 
> target or makefile to run?  The Wiki shows the dependencies like cmake 
> but not any actual commands or Gradle tasks.
>
>   
>
> If I switch to the Oracle JDK 8u192, the code works.  There is a 
> glib-lite.dll in the Oracle jre\bin folder.
>
>   
>
> Thanks,
>
> Carl
>
>   
>
> clipMap.put( "0", new AudioClip(f.toURI().toString()));
>
>   
>
> Caused by: java.lang.UnsatisfiedLinkError: Can't load library:
> D:\Java\open-jdk8u181-b13-openjfx\jre\bin\glib-lite.dll
>
>                  at 
> java.lang.ClassLoader.loadLibrary(ClassLoader.java:1827)
>
>                  at java.lang.Runtime.load0(Runtime.java:809)
>
>                  at java.lang.System.load(System.java:1086)
>
>                  at
> com.sun.glass.utils.NativeLibLoader.loadLibraryFullPath(NativeLibLoade
> r.java
> :201)
>
>                  at
> com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoade
> r.java
> :94)
>
>                  at
> com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:3
> 9)
>
>                  at
> com.sun.media.jfxmediaimpl.NativeMediaManager.lambda$new$0(NativeMedia
> Manage
> r.java:108)
>
>                  at java.security.AccessController.doPrivileged(Native
> Method)
>
>                  at
> com.sun.media.jfxmediaimpl.NativeMediaManager.<init>(NativeMediaManage
> r.java
> :106)
>
>                  at
> com.sun.media.jfxmediaimpl.NativeMediaManager$NativeMediaManagerInitializer.
> <clinit>(NativeMediaManager.java:77)
>
>                  at
> com.sun.media.jfxmediaimpl.NativeMediaManager.getDefaultInstance(Nativ
> eMedia
> Manager.java:89)
>
>                  at
> com.sun.media.jfxmedia.MediaManager.canPlayProtocol(MediaManager.java:
> 78)
>
>                  at
> com.sun.media.jfxmedia.locator.Locator.<init>(Locator.java:239)
>
>                  at
> com.sun.media.jfxmediaimpl.NativeMediaAudioClip.<init>(NativeMediaAudioClip.
> java:53)
>
>                  at
> com.sun.media.jfxmediaimpl.NativeMediaAudioClip.load(NativeMediaAudioC
> lip.ja
> va:63)
>
>                  at
> com.sun.media.jfxmediaimpl.AudioClipProvider.load(AudioClipProvider.ja
> va:66)
>
>                  at 
> com.sun.media.jfxmedia.AudioClip.load(AudioClip.java:135)
>
>                  at 
> javafx.scene.media.AudioClip.<init>(AudioClip.java:83)
>
>                  at 
> com.mycompany.audio.AudioBean.load(AudioBean.java:171)
>



From kevin.rushforth at oracle.com  Tue Nov  6 23:31:39 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 6 Nov 2018 15:31:39 -0800
Subject: [12] RFR: JDK-8211304: [macOS] Crash on focus loss from dialog on
 macOS 10.14 Mojave
Message-ID: <d5b6802b-848b-a769-89ad-ac9d6315301a@oracle.com>

Pankaj & Arun,

Please review (on Github) the fix for the macOS 10.14 Mojave crash:

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

-- Kevin


From wookey.dean at gmail.com  Wed Nov  7 07:57:56 2018
From: wookey.dean at gmail.com (Dean Wookey)
Date: Wed, 7 Nov 2018 09:57:56 +0200
Subject: JDK-8193445 Performance Test
Message-ID: <CAKZ_BFhpq7C8_6YVuKAXx8JykTk9ANRD6F=3EXXzUJXPo2thMg@mail.gmail.com>

Hi,

I was going to ask if it was possible to reopen JDK-8151756 (
https://bugs.openjdk.java.net/browse/JDK-8151756) since it was fixed but
reverted in JDK-8183100 (https://bugs.openjdk.java.net/browse/JDK-8183100)
after causing several regressions. I only noticed now that a followup bug
was created: JDK-8193445 which reopens the issue.

The code below demonstrates the problem where adding nodes to the scene
graph all at once performs exponentially slower than adding them one by
one. I get the following results with jfx11.0.1:

One by one: 138ms
All at once: 16704ms

I've made a potential fix, different to the one tried previously which
applies the css as if the nodes were being added one by one:
https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6

It passes the main tests, as well as the systemTest JDK8183100Test.java
from https://bugs.openjdk.java.net/browse/JDK-8193494.

This is probably not a suitable issue to work on for a first time
contributor, but perhaps I could work on a performance test if someone can
point me in the direction of existing performance tests?

Dean

package applycsstest;

import javafx.application.Application;
import javafx.application.Platform;
import javafx.scene.Scene;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

/**
 *
 * @author Dean
 */
public class ApplyCssTest extends Application {

    @Override
    public void start(Stage primaryStage) {
        System.out.println("One by one: " + addToSceneOneByOne() + "ms");
        System.out.println("All at once: " + addToSceneAllAtOnce() + "ms");
        Platform.exit();
    }

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

    public long addToSceneOneByOne() {
        StackPane root = new StackPane();
        Scene scene = new Scene(root, 300, 250);

        long start = System.currentTimeMillis();
        StackPane firstChild = new StackPane();
        root.getChildren().add(firstChild); //add to the scene graph first
        addNodesOneByOne(1000, firstChild); //then add children one by one
        return System.currentTimeMillis() - start;
    }

    public long addToSceneAllAtOnce() {
        StackPane root = new StackPane();
        Scene scene = new Scene(root, 300, 250);

        long start = System.currentTimeMillis();
        StackPane firstChild = new StackPane();
        addNodesOneByOne(1000, firstChild); //build the node up, then
        root.getChildren().add(firstChild); //add to scene graph all at once
        return System.currentTimeMillis() - start;
    }

    public void addNodesOneByOne(int numToAdd, StackPane parent) {
        StackPane last = parent;
        for (int i = 0; i < numToAdd; i++) {
            StackPane curr = new StackPane();
            last.getChildren().add(curr);
            last = curr;
        }
    }
}

From david.grieve at oracle.com  Wed Nov  7 13:37:05 2018
From: david.grieve at oracle.com (David Grieve)
Date: Wed, 7 Nov 2018 08:37:05 -0500
Subject: JDK-8193445 Performance Test
In-Reply-To: <CAKZ_BFhpq7C8_6YVuKAXx8JykTk9ANRD6F=3EXXzUJXPo2thMg@mail.gmail.com>
References: <CAKZ_BFhpq7C8_6YVuKAXx8JykTk9ANRD6F=3EXXzUJXPo2thMg@mail.gmail.com>
Message-ID: <fe4316ff-fb92-1e5d-f73e-a85e5a395be7@oracle.com>

One of the dangers of mucking around with the CSS code is whether or not 
the changes break things like popups, dialogs, menus. And whether or not 
the change breaks inline styles versus attributes set in code, versus 
stylesheets added to the scene/subscene/control, versus default 
stylesheets. And whether or not the changes breaks skins for controls.

Reapplying CSS to a Node but not its children could cause a problem if 
there are styles in the parent or the parent's parents that affect the 
children. It seems like bypassing children in reapplyCSS is bound to 
cause a regression.

Also, because a new scene root could affect styles, CSS is reapplied 
after calling sceneChanged - your change puts it before, so I question 
whether or not this will cause a regression. I think if you skip 
reapplying CSS when a Node's scene has changed, then the children won't 
get the correct styles, and this will affect layout.

I haven't spent much time evaluating this change in detail, but I'm 
doubtful that it won't cause regressions.


On 11/7/18 2:57 AM, Dean Wookey wrote:
> Hi,
>
> I was going to ask if it was possible to reopen JDK-8151756 (
> https://bugs.openjdk.java.net/browse/JDK-8151756) since it was fixed but
> reverted in JDK-8183100 (https://bugs.openjdk.java.net/browse/JDK-8183100)
> after causing several regressions. I only noticed now that a followup bug
> was created: JDK-8193445 which reopens the issue.
>
> The code below demonstrates the problem where adding nodes to the scene
> graph all at once performs exponentially slower than adding them one by
> one. I get the following results with jfx11.0.1:
>
> One by one: 138ms
> All at once: 16704ms
>
> I've made a potential fix, different to the one tried previously which
> applies the css as if the nodes were being added one by one:
> https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6
>
> It passes the main tests, as well as the systemTest JDK8183100Test.java
> from https://bugs.openjdk.java.net/browse/JDK-8193494.
>
> This is probably not a suitable issue to work on for a first time
> contributor, but perhaps I could work on a performance test if someone can
> point me in the direction of existing performance tests?
>
> Dean
>
> package applycsstest;
>
> import javafx.application.Application;
> import javafx.application.Platform;
> import javafx.scene.Scene;
> import javafx.scene.layout.StackPane;
> import javafx.stage.Stage;
>
> /**
>   *
>   * @author Dean
>   */
> public class ApplyCssTest extends Application {
>
>      @Override
>      public void start(Stage primaryStage) {
>          System.out.println("One by one: " + addToSceneOneByOne() + "ms");
>          System.out.println("All at once: " + addToSceneAllAtOnce() + "ms");
>          Platform.exit();
>      }
>
>      public static void main(String[] args) {
>          launch(args);
>      }
>
>      public long addToSceneOneByOne() {
>          StackPane root = new StackPane();
>          Scene scene = new Scene(root, 300, 250);
>
>          long start = System.currentTimeMillis();
>          StackPane firstChild = new StackPane();
>          root.getChildren().add(firstChild); //add to the scene graph first
>          addNodesOneByOne(1000, firstChild); //then add children one by one
>          return System.currentTimeMillis() - start;
>      }
>
>      public long addToSceneAllAtOnce() {
>          StackPane root = new StackPane();
>          Scene scene = new Scene(root, 300, 250);
>
>          long start = System.currentTimeMillis();
>          StackPane firstChild = new StackPane();
>          addNodesOneByOne(1000, firstChild); //build the node up, then
>          root.getChildren().add(firstChild); //add to scene graph all at once
>          return System.currentTimeMillis() - start;
>      }
>
>      public void addNodesOneByOne(int numToAdd, StackPane parent) {
>          StackPane last = parent;
>          for (int i = 0; i < numToAdd; i++) {
>              StackPane curr = new StackPane();
>              last.getChildren().add(curr);
>              last = curr;
>          }
>      }
> }


From nlisker at gmail.com  Wed Nov  7 16:21:53 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 7 Nov 2018 18:21:53 +0200
Subject: Running JavaFX-11 applications from within Eclipse fails
In-Reply-To: <2D6BD968-CF35-41CB-A545-DC7F34BD3FF9@bestsolution.at>
References: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
 <CABxFH2HdykTWPoRcuWsLK25P-a5tc3JTREbDh6f9X1TRnCEU+w@mail.gmail.com>
 <eb8f0df2-d6c3-5b68-665e-90f38f553234@oracle.com>
 <CAGMSBrJip3RVgmYi-Qmd33-ZDuJ-oyFcpFeY2W+_vTm_dvngng@mail.gmail.com>
 <2D6BD968-CF35-41CB-A545-DC7F34BD3FF9@bestsolution.at>
Message-ID: <CA+0ynh8tjNZYo3536595iYUTC0_z=P=Din75Eysm_7hKhn-VhA@mail.gmail.com>

I have a related problem when developing JavaFX in Eclipse and Win10 that
started in 11.

I created a modular project and in its build configuration (in Eclipse) I
added the JavaFX base and graphics projects (that point to rt\modules\...)
and OpenJDK11 to the module path.
In the module-info file I required the JavaFX modules and exported my
package.

Compilation is fine, but during runtime (with -Dprism.verbose=true) I get
an error:

Prism pipeline init order: d3d 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.d3d.D3DPipeline
Loading D3D native library ...
// Error here: //
GraphicsPipeline.createPipeline failed for com.sun.prism.d3d.D3DPipeline
java.lang.UnsatisfiedLinkError: no prism_sw in java.library.path: [see
below]
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.d3d.D3DPipeline.lambda$0(D3DPipeline.java:48)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
javafx.graphics/com.sun.prism.d3d.D3DPipeline.<clinit>(D3DPipeline.java:44)
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: [see
below]
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$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 :  d3d, sw
Error initializing QuantumRenderer: no suitable pipeline found
// ...

The paths listed at the end are those from %PATH% and none point to the
development modules. So, I added to the runtime VM args in the launch
configuration:

-Djava.library.path="...\rt\modules\javafx.graphics\bin"
and I also tried with
"...\rt\modules\javafx.graphics\bin\com\sun\prism\d3d" because this is
where com.sun.prism.d3d.D3DPipeline is.

I get the same error. Did anyone encounter this?

- Nir

On Sun, Nov 4, 2018 at 6:40 PM Tom Schindl <tom.schindl at bestsolution.at>
wrote:

> I think the more general problem is that they don?t run on the module-path
> - in the m2e case this because the modules are transitive deps and those
> are not supported properly
>
> Tom
>
> Von meinem iPhone gesendet
>
> > Am 04.11.2018 um 16:17 schrieb Jos? Pereda <jose.pereda at gluonhq.com>:
> >
> > I've just noticed that this issue happens not only with Maven but also
> with
> > Gradle projects (Gradle + Eclipse 2018-09 + Windows with Oracle JDK 1.8),
> > running gradle tasks from Eclipse.
> >
> > The same proposed workaround can be applied to the build file:
> >
> > run {
> >
> >    systemProperty "java.library.path", "C:\tmp"
> >
> > }
> >
> >
> >
> >
> > On Mon, Oct 22, 2018 at 4:43 PM Kevin Rushforth <
> kevin.rushforth at oracle.com>
> > wrote:
> >
> >>
> >>> 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 swpalmer at gmail.com  Wed Nov  7 17:04:33 2018
From: swpalmer at gmail.com (Scott Palmer)
Date: Wed, 7 Nov 2018 12:04:33 -0500
Subject: JDK-8193445 Performance Test
In-Reply-To: <fe4316ff-fb92-1e5d-f73e-a85e5a395be7@oracle.com>
References: <CAKZ_BFhpq7C8_6YVuKAXx8JykTk9ANRD6F=3EXXzUJXPo2thMg@mail.gmail.com>
 <fe4316ff-fb92-1e5d-f73e-a85e5a395be7@oracle.com>
Message-ID: <F3ECE8BD-FC1B-4570-8D58-1490C815CDAB@gmail.com>



> On Nov 7, 2018, at 8:37 AM, David Grieve <david.grieve at oracle.com> wrote:
> 
> ...
> 
> Reapplying CSS to a Node but not its children could cause a problem if there are styles in the parent or the parent's parents that affect the children. It seems like bypassing children in reapplyCSS is bound to cause a regression.

I agree that it is necessary to re-apply CSS to child nodes when the parent node CSS changes.  The issue that I originally reported was that I could see that child nodes had CSS re-applied more than once. The number of times CSS is applied is currently proportional to how deep in the scene graph hierarchy the node is.

When a subtree is added to the scene graph, I would expect that CSS can be reapplied to each node only once, so long as it is done in a top-down manner.

I could be wrong, I?m not certain how rules relating to sibling nodes might invalidate that assumption. In HTML there is the concept of adjacent sibling combinator, e.g. ?img + p" for paragraphs that come immediately after any image.  I don?t think JavaFX has anything like that thoughts o top-down should work out.

Scott




From kevin.rushforth at oracle.com  Wed Nov  7 17:33:12 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 7 Nov 2018 09:33:12 -0800
Subject: JDK-8193445 Performance Test
In-Reply-To: <fe4316ff-fb92-1e5d-f73e-a85e5a395be7@oracle.com>
References: <CAKZ_BFhpq7C8_6YVuKAXx8JykTk9ANRD6F=3EXXzUJXPo2thMg@mail.gmail.com>
 <fe4316ff-fb92-1e5d-f73e-a85e5a395be7@oracle.com>
Message-ID: <41f5f801-9bef-bb50-39ad-8c484dc9dba1@oracle.com>

My thoughts as well. I would love to see a safe robust fix for this 
issue, but there is a very real possibility of a regression: We thought 
we had a safe fix earlier and only later discovered the (multiple) 
regressions a few months after it was released.

One possible way to improve performance is to allow applications to 
manage when it is safe to skip applying CSS to certain nodes under app 
control, as proposed in 
https://bugs.openjdk.java.net/browse/JDK-8173301. I'm not sure that 
would be as effective, but at least it would only affect apps that "opt 
in" and only for those parts of the scene graph that are so designated.

I do like the idea of coming up with better tests that can be used to 
validate any potential future fix.

-- Kevin


On 11/7/2018 5:37 AM, David Grieve wrote:
> One of the dangers of mucking around with the CSS code is whether or 
> not the changes break things like popups, dialogs, menus. And whether 
> or not the change breaks inline styles versus attributes set in code, 
> versus stylesheets added to the scene/subscene/control, versus default 
> stylesheets. And whether or not the changes breaks skins for controls.
>
> Reapplying CSS to a Node but not its children could cause a problem if 
> there are styles in the parent or the parent's parents that affect the 
> children. It seems like bypassing children in reapplyCSS is bound to 
> cause a regression.
>
> Also, because a new scene root could affect styles, CSS is reapplied 
> after calling sceneChanged - your change puts it before, so I question 
> whether or not this will cause a regression. I think if you skip 
> reapplying CSS when a Node's scene has changed, then the children 
> won't get the correct styles, and this will affect layout.
>
> I haven't spent much time evaluating this change in detail, but I'm 
> doubtful that it won't cause regressions.
>
>
> On 11/7/18 2:57 AM, Dean Wookey wrote:
>> Hi,
>>
>> I was going to ask if it was possible to reopen JDK-8151756 (
>> https://bugs.openjdk.java.net/browse/JDK-8151756) since it was fixed but
>> reverted in JDK-8183100 
>> (https://bugs.openjdk.java.net/browse/JDK-8183100)
>> after causing several regressions. I only noticed now that a followup 
>> bug
>> was created: JDK-8193445 which reopens the issue.
>>
>> The code below demonstrates the problem where adding nodes to the scene
>> graph all at once performs exponentially slower than adding them one by
>> one. I get the following results with jfx11.0.1:
>>
>> One by one: 138ms
>> All at once: 16704ms
>>
>> I've made a potential fix, different to the one tried previously which
>> applies the css as if the nodes were being added one by one:
>> https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6 
>>
>>
>> It passes the main tests, as well as the systemTest JDK8183100Test.java
>> from https://bugs.openjdk.java.net/browse/JDK-8193494.
>>
>> This is probably not a suitable issue to work on for a first time
>> contributor, but perhaps I could work on a performance test if 
>> someone can
>> point me in the direction of existing performance tests?
>>
>> Dean
>>
>> package applycsstest;
>>
>> import javafx.application.Application;
>> import javafx.application.Platform;
>> import javafx.scene.Scene;
>> import javafx.scene.layout.StackPane;
>> import javafx.stage.Stage;
>>
>> /**
>> ? *
>> ? * @author Dean
>> ? */
>> public class ApplyCssTest extends Application {
>>
>> ???? @Override
>> ???? public void start(Stage primaryStage) {
>> ???????? System.out.println("One by one: " + addToSceneOneByOne() + 
>> "ms");
>> ???????? System.out.println("All at once: " + addToSceneAllAtOnce() + 
>> "ms");
>> ???????? Platform.exit();
>> ???? }
>>
>> ???? public static void main(String[] args) {
>> ???????? launch(args);
>> ???? }
>>
>> ???? public long addToSceneOneByOne() {
>> ???????? StackPane root = new StackPane();
>> ???????? Scene scene = new Scene(root, 300, 250);
>>
>> ???????? long start = System.currentTimeMillis();
>> ???????? StackPane firstChild = new StackPane();
>> ???????? root.getChildren().add(firstChild); //add to the scene graph 
>> first
>> ???????? addNodesOneByOne(1000, firstChild); //then add children one 
>> by one
>> ???????? return System.currentTimeMillis() - start;
>> ???? }
>>
>> ???? public long addToSceneAllAtOnce() {
>> ???????? StackPane root = new StackPane();
>> ???????? Scene scene = new Scene(root, 300, 250);
>>
>> ???????? long start = System.currentTimeMillis();
>> ???????? StackPane firstChild = new StackPane();
>> ???????? addNodesOneByOne(1000, firstChild); //build the node up, then
>> ???????? root.getChildren().add(firstChild); //add to scene graph all 
>> at once
>> ???????? return System.currentTimeMillis() - start;
>> ???? }
>>
>> ???? public void addNodesOneByOne(int numToAdd, StackPane parent) {
>> ???????? StackPane last = parent;
>> ???????? for (int i = 0; i < numToAdd; i++) {
>> ???????????? StackPane curr = new StackPane();
>> ???????????? last.getChildren().add(curr);
>> ???????????? last = curr;
>> ???????? }
>> ???? }
>> }
>


From wookey.dean at gmail.com  Thu Nov  8 05:30:09 2018
From: wookey.dean at gmail.com (Dean Wookey)
Date: Thu, 8 Nov 2018 07:30:09 +0200
Subject: JDK-8193445 Performance Test
In-Reply-To: <fe4316ff-fb92-1e5d-f73e-a85e5a395be7@oracle.com>
References: <CAKZ_BFhpq7C8_6YVuKAXx8JykTk9ANRD6F=3EXXzUJXPo2thMg@mail.gmail.com>
 <fe4316ff-fb92-1e5d-f73e-a85e5a395be7@oracle.com>
Message-ID: <CAKZ_BFj8ODMRh2a650dq4gxStGASnpEcDfFLdJVmVF=E5gnORQ@mail.gmail.com>

Hi,

I just wanted to clarify a few things about the fix. The test I showed
hints at a potentially safer way to implement the fix for this problem. One
would expect adding nodes 1 by 1 to the scene graph to be less efficient
than adding them all at once, but it's far worse to add them all at once.
The fix demonstrates that the test's performance problem comes from the
reapplication of css, and is not necessarily the best fix for the problem,
it's just the least impactful fix I could come up with, since the idea is
that adding nodes one by one is safe already.

Reapplying CSS to a Node but not its children could cause a problem if
> there are styles in the parent or the parent's parents that affect the
> children. It seems like bypassing children in reapplyCSS is bound to
> cause a regression.
>

CSS does get applied to the children. The problem was that each parent
would call scenesChanged, which would then call scenesChanged on all the
children recursively. As they're bubbling out they call reapplyCSS on
themselves which calls reapplyCss on themselves and all their children.
Jonathan's solution was to only allow the node that was added to the scene
graph to reapplyCSS to its children, thus applying css in a top down way. I
suspect with some modifications it could work. One thing it didn't do was
call reapplyCSS (different from reapplyCss) on every node. It only called
reapplyCss on every node, and there is some additional logic in reapplyCSS.
(The commit which undoes this change is here:
https://github.com/javafxports/openjdk-jfx/commit/cd14f72776281a2384c50a35e618f1fb258c9430#diff-4a65018af7ebb15827ff1c67a3c29e86
).

In mine, reapplyCSS happens first and doesn't propagate down to the
children. Instead, the scenesChanged method will trigger invalidatedScenes
on all the children, and they will reapplyCSS for themselves. Basically
each node calls reapplyCSS for itself, then propagates. In this way css is
applied top down in a way similar to adding the nodes 1 by 1. Also, only
this one case where nodes are added all at once is affected.

Kevin has also mentioned https://bugs.openjdk.java.net/browse/JDK-8173301
as a way to mitigate the problem. I think something like that would be fine
for this particular css performance issue, but there are several other
issues. It would be nice to have a safer way to work on these issues so
that they could get tackled.

I think there are several options here. I just wanted to share some
insights, and perhaps contribute a test or two. Kevin mentioned "We will
need a performance regression test to measure the gain." Are there any
performance tests like this already I could look at as an example?

Dean



On Wed, Nov 7, 2018 at 3:37 PM David Grieve <david.grieve at oracle.com> wrote:

> One of the dangers of mucking around with the CSS code is whether or not
> the changes break things like popups, dialogs, menus. And whether or not
> the change breaks inline styles versus attributes set in code, versus
> stylesheets added to the scene/subscene/control, versus default
> stylesheets. And whether or not the changes breaks skins for controls.
>
> Reapplying CSS to a Node but not its children could cause a problem if
> there are styles in the parent or the parent's parents that affect the
> children. It seems like bypassing children in reapplyCSS is bound to
> cause a regression.
>
> Also, because a new scene root could affect styles, CSS is reapplied
> after calling sceneChanged - your change puts it before, so I question
> whether or not this will cause a regression. I think if you skip
> reapplying CSS when a Node's scene has changed, then the children won't
> get the correct styles, and this will affect layout.
>
> I haven't spent much time evaluating this change in detail, but I'm
> doubtful that it won't cause regressions.
>
>

From kevin.rushforth at oracle.com  Thu Nov  8 13:15:20 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 8 Nov 2018 05:15:20 -0800
Subject: [11] Request approval to backport 8211304: [macOS] Crash on focus
 loss from dialog on macOS 10.14 Mojave
Message-ID: <940790a2-b2cb-12d6-3725-6b5ee0e56d52@oracle.com>

Hi Johan,

I request approval to backport the following critical bug to 11-dev (for 
11.0.2).

JBS: https://bugs.openjdk.java.net/browse/JDK-8211304
Changeset: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/e864311d97e6

The changeset patch applies cleanly to 11-dev.

-- Kevin


From johan.vos at gluonhq.com  Thu Nov  8 13:29:15 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 8 Nov 2018 14:29:15 +0100
Subject: [11] Request approval to backport 8211304: [macOS] Crash on focus
 loss from dialog on macOS 10.14 Mojave
In-Reply-To: <940790a2-b2cb-12d6-3725-6b5ee0e56d52@oracle.com>
References: <940790a2-b2cb-12d6-3725-6b5ee0e56d52@oracle.com>
Message-ID: <CABxFH2E=RSrKFfEuZ1Nh++OqqTARFVTG3UqzNJF4H5wHKd3Y6Q@mail.gmail.com>

+1 for this backport.

On Thu, Nov 8, 2018 at 2:15 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Hi Johan,
>
> I request approval to backport the following critical bug to 11-dev (for
> 11.0.2).
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8211304
> Changeset: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/e864311d97e6
>
> The changeset patch applies cleanly to 11-dev.
>
> -- Kevin
>
>

From carl at bekwam.com  Thu Nov  8 14:57:24 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Thu, 8 Nov 2018 09:57:24 -0500
Subject: Gradle File Rename Error in 8u Dev Build
Message-ID: <011d01d47773$5c24ffa0$146efee0$@bekwam.com>

Hi,

 

I was wondering if anyone's solved a renaming error I get when I run gradle.
I have a reliable workaround which is to delete the file prior to running
gradle. 

 

> Unable to rename old file (D:\hg\rt\build\sdk\rt\lib\ext\jfxrt.jar) to
temporary file

 

Thanks in advance,

Carl

 

 

 


From wookey.dean at gmail.com  Thu Nov  8 16:38:22 2018
From: wookey.dean at gmail.com (Dean Wookey)
Date: Thu, 8 Nov 2018 18:38:22 +0200
Subject: Problems building openjfx
In-Reply-To: <CABxFH2Gf4msXUGgCx5_vX2wxLYiQWQfLCQUECS6MY2nM693DWg@mail.gmail.com>
References: <20181031145703.Horde.ZQGCkkUxkwh_j5REAgomRw2@webmail.df.eu>
 <20181031150245.Horde.96kpsXfyvd5AkpBwsZ5GxQ1@webmail.df.eu>
 <CAOTPd674DR6QpoTErXbJ9=9T2fDhb9nrJKQO1nktpmBkjZHUQg@mail.gmail.com>
 <CABxFH2Gf4msXUGgCx5_vX2wxLYiQWQfLCQUECS6MY2nM693DWg@mail.gmail.com>
Message-ID: <CAKZ_BFi49-ztzVo7s3BtwM=JYcOdugu1iMHfCk5PmM+Z0Mun0w@mail.gmail.com>

Hi Johan,

Michael's build script helped me a lot. I'm on windows 10. It just runs in
powershell after installing chocolatey, (.\tools\scripts\build1.ps from the
openjdk root dir). The only environment variables I've got set are
JAVA_HOME/JDK_HOME. I did have to make some modifications however to
install the other dependencies and to handle the .dll's that weren't
packaged. Everything ran fine on my machine, but as soon as I tried using
the jars on another machine, I got linker errors. Below is the modified
version. It won't package the correct dlls if DebugNative is used though,
but as it is, it's working for me.

Dean

.\gradlew --stop
choco install ant
choco install vswhere
choco install zip
choco install visualstudio2017community
choco install visualstudio2017-workload-nativedesktop
choco install windows-sdk-7.1
choco install cygwin

$cygwinPath = (Get-ItemProperty -Path "HKLM:\SOFTWARE\Cygwin\setup").rootdir
$env:Path += ";$($cygwinPath)\bin"

$env:WINSDK_DIR = (Get-ItemProperty -Path
"HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows Kits\Installed
Roots").KitsRoot10
$env:VCINSTALLDIR = "$(vswhere -legacy -latest -property
installationPath)\VC\Auxiliary\Build"
$vcRoot = "$(vswhere -legacy -latest -property installationPath)"
$msvcToolsVer = Get-Content
"$env:VCINSTALLDIR\Microsoft.VCToolsVersion.default.txt"
$msvcRedistVer = Get-Content
"$env:VCINSTALLDIR\Microsoft.VCRedistVersion.default.txt"

if ([string]::IsNullOrWhitespace($msvcToolsVer)) {
  # The MSVC tools version file can have txt *or* props extension.
  $msvcToolsVer = Get-Content
"$env:VCINSTALLDIR\Microsoft.VCToolsVersion.default.props"
}
$env:MSVC_VER = $msvcToolsVer
$env:MSVC_REDIST_VER = $msvcRedistVer

$files = Get-ChildItem
"$($vcRoot)/VC/Redist/MSVC/$($msvcRedistVer)/x86/*.CRT/"
$crtVer = $files[0].Name.replace("Microsoft.VC","").replace(".CRT","")
$env:WINDOWS_CRT_VER = $crtVer


$env:VS150COMNTOOLS = $env:VCINSTALLDIR
$env:VSVARS32FILE = "$env:VCINSTALLDIR\vcvars32.bat"
refreshenv
if ($env:APPVEYOR -eq "true") {
  .\gradlew all test -PCOMPILE_WEBKIT=false -PCONF=Debug --stacktrace -x
:web:test --info --no-daemon
  if ($lastexitcode -ne 0) {
    exit $lastexitcode
  }
} else {
  .\gradlew all test -PCOMPILE_WEBKIT=false -PCONF=Debug --stacktrace -x
:web:test --info
}

On Fri, Nov 2, 2018 at 8:57 PM Johan Vos <johan.vos at gluonhq.com> wrote:

> Hi Michael,
>
> What environment do you use to run that Windows build script?
> The windows builds are the ones I still feel least comfortable about. We
> tried to automate those on AdoptOpenJDK infrastructure, but they are using
> Ansible for provisioning machines (for very good reasons), and we spent
> days trying to come up with an Ansible script that allowed to build on
> Windows, without 100% success.
> Hence, we currently create the windows build on a Windows machine with a
> fixed setup. It would be better of course to move more of the environment
> and context parameters to the build procedure itself, and your script seems
> a step in that direction. But what infrastructure do you use to run this?
>
> - Johan
>
> On Thu, Nov 1, 2018 at 11:17 PM Michael Ennen <mike.ennen at gmail.com>
> wrote:
>
> > Also don't forget about the Windows build script:
> >
> >
> >
> https://github.com/javafxports/openjdk-jfx/blob/develop/tools/scripts/build.ps1
> >
> > It is what I use to automate the process of building OpenJFX on Windows
> as
> > much as
> > possible. Any improvements to the script would be appreciated.
> >
> > On Wed, Oct 31, 2018 at 7:03 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 ;)
> > >
> > >
> > >
> > >
> >
> > --
> > Michael Ennen
> >
>

From kevin.rushforth at oracle.com  Thu Nov  8 16:52:57 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 8 Nov 2018 08:52:57 -0800
Subject: Gradle File Rename Error in 8u Dev Build
In-Reply-To: <011d01d47773$5c24ffa0$146efee0$@bekwam.com>
References: <011d01d47773$5c24ffa0$146efee0$@bekwam.com>
Message-ID: <43bd22f8-9d56-4a11-4ec8-13ba23a68d7c@oracle.com>

Two questions:

1) Are you using the gradle daemon?
If so, you might try disabling it.

2) Are you running any applications that might still have jfxrt.jar open?
If so, you should stop them before rebuilding.

-- Kevin





On 11/8/2018 6:57 AM, carl at bekwam.com wrote:
> Hi,
>
>   
>
> I was wondering if anyone's solved a renaming error I get when I run gradle.
> I have a reliable workaround which is to delete the file prior to running
> gradle.
>
>   
>
>> Unable to rename old file (D:\hg\rt\build\sdk\rt\lib\ext\jfxrt.jar) to
> temporary file
>
>   
>
> Thanks in advance,
>
> Carl
>
>   
>
>   
>
>   
>


From carl at bekwam.com  Thu Nov  8 17:20:27 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Thu, 8 Nov 2018 12:20:27 -0500
Subject: Gradle File Rename Error in 8u Dev Build
In-Reply-To: <43bd22f8-9d56-4a11-4ec8-13ba23a68d7c@oracle.com>
References: <011d01d47773$5c24ffa0$146efee0$@bekwam.com>
 <43bd22f8-9d56-4a11-4ec8-13ba23a68d7c@oracle.com>
Message-ID: <00c401d47787$5912ed90$0b38c8b0$@bekwam.com>

Hi,

No open files and I've tried a few variations of gradle with and without the daemon.  I can issue a quick rm following the failed gradle so I don't think there's contention.

-Carl

-----Original Message-----
From: Kevin Rushforth <kevin.rushforth at oracle.com> 
Sent: Thursday, November 8, 2018 11:53 AM
To: carl at bekwam.com; openjfx-dev at openjdk.java.net
Subject: Re: Gradle File Rename Error in 8u Dev Build

Two questions:

1) Are you using the gradle daemon?
If so, you might try disabling it.

2) Are you running any applications that might still have jfxrt.jar open?
If so, you should stop them before rebuilding.

-- Kevin





On 11/8/2018 6:57 AM, carl at bekwam.com wrote:
> Hi,
>
>   
>
> I was wondering if anyone's solved a renaming error I get when I run gradle.
> I have a reliable workaround which is to delete the file prior to 
> running gradle.
>
>   
>
>> Unable to rename old file (D:\hg\rt\build\sdk\rt\lib\ext\jfxrt.jar) 
>> to
> temporary file
>
>   
>
> Thanks in advance,
>
> Carl
>
>   
>
>   
>
>   
>



From carl at bekwam.com  Thu Nov  8 17:53:33 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Thu, 8 Nov 2018 12:53:33 -0500
Subject: COMPILE_MEDIA Error on 8udev - DirectShow Question
Message-ID: <001d01d4778b$f7ca3250$e75e96f0$@bekwam.com>

Hi,

 

I'm able to build a non-media version of 8udev successfully.  However, when
I try the -PCOMPILE_MEDIA option, I'm getting an error 

 

> Task :media:buildWinPlugins

make: Entering directory
'/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
ugins'

make
TARGET=/cygdrive/d/hg/rt/modules/media/build/native/win/Release/baseclasses.
lib -f Makefile.BaseClasses

cygpath: cannot create short name of C:\Program Files\Microsoft
SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses

make[1]: Entering directory
'/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
ugins'

Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...

 

I have a new computer with Visual Studio 2017.   I understand that the
DirectShow libraries have now been incorporated into the Windows SDK.  I
found header files like dshow.h in my hard drvie, but I don't have a
BaseClasses folder.

 

Has anyone compiled media with a recent VSS or are most people compiling
against residual artifacts from a while ago?

 

Thanks,

Carl

 


From turikhay at gmail.com  Thu Nov  8 18:20:34 2018
From: turikhay at gmail.com (Artur Khusainov)
Date: Thu, 8 Nov 2018 23:20:34 +0500
Subject: COMPILE_MEDIA Error on 8udev - DirectShow Question
In-Reply-To: <001d01d4778b$f7ca3250$e75e96f0$@bekwam.com>
References: <001d01d4778b$f7ca3250$e75e96f0$@bekwam.com>
Message-ID: <CACxS+sY6_tvCd9A_ni_cFtXWtEanx_vKfqMNC_x8dZLZje_5bg@mail.gmail.com>

Hi,

Try installing this:
https://www.microsoft.com/en-us/download/details.aspx?id=8279

??, 8 ????. 2018 ?., 22:54 <carl at bekwam.com>:

> Hi,
>
>
>
> I'm able to build a non-media version of 8udev successfully.  However, when
> I try the -PCOMPILE_MEDIA option, I'm getting an error
>
>
>
> > Task :media:buildWinPlugins
>
> make: Entering directory
>
> '/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
> ugins'
>
> make
>
> TARGET=/cygdrive/d/hg/rt/modules/media/build/native/win/Release/baseclasses.
> lib -f Makefile.BaseClasses
>
> cygpath: cannot create short name of C:\Program Files\Microsoft
> SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses
>
> make[1]: Entering directory
>
> '/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
> ugins'
>
> Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...
>
>
>
> I have a new computer with Visual Studio 2017.   I understand that the
> DirectShow libraries have now been incorporated into the Windows SDK.  I
> found header files like dshow.h in my hard drvie, but I don't have a
> BaseClasses folder.
>
>
>
> Has anyone compiled media with a recent VSS or are most people compiling
> against residual artifacts from a while ago?
>
>
>
> Thanks,
>
> Carl
>
>
>
>

From kevin.rushforth at oracle.com  Thu Nov  8 18:23:44 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 8 Nov 2018 10:23:44 -0800
Subject: COMPILE_MEDIA Error on 8udev - DirectShow Question
In-Reply-To: <001d01d4778b$f7ca3250$e75e96f0$@bekwam.com>
References: <001d01d4778b$f7ca3250$e75e96f0$@bekwam.com>
Message-ID: <08f0de18-7bf6-cd11-3a33-22ba318a4c7e@oracle.com>

You need the Windows SDK v7.1a, which has the DirectShow Base Classes.

-- Kevin


On 11/8/2018 9:53 AM, carl at bekwam.com wrote:
> Hi,
>
>   
>
> I'm able to build a non-media version of 8udev successfully.  However, when
> I try the -PCOMPILE_MEDIA option, I'm getting an error
>
>   
>
>> Task :media:buildWinPlugins
> make: Entering directory
> '/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
> ugins'
>
> make
> TARGET=/cygdrive/d/hg/rt/modules/media/build/native/win/Release/baseclasses.
> lib -f Makefile.BaseClasses
>
> cygpath: cannot create short name of C:\Program Files\Microsoft
> SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses
>
> make[1]: Entering directory
> '/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
> ugins'
>
> Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...
>
>   
>
> I have a new computer with Visual Studio 2017.   I understand that the
> DirectShow libraries have now been incorporated into the Windows SDK.  I
> found header files like dshow.h in my hard drvie, but I don't have a
> BaseClasses folder.
>
>   
>
> Has anyone compiled media with a recent VSS or are most people compiling
> against residual artifacts from a while ago?
>
>   
>
> Thanks,
>
> Carl
>
>   
>


From kevin.rushforth at oracle.com  Thu Nov  8 18:29:46 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 8 Nov 2018 10:29:46 -0800
Subject: COMPILE_MEDIA Error on 8udev - DirectShow Question
In-Reply-To: <08f0de18-7bf6-cd11-3a33-22ba318a4c7e@oracle.com>
References: <001d01d4778b$f7ca3250$e75e96f0$@bekwam.com>
 <08f0de18-7bf6-cd11-3a33-22ba318a4c7e@oracle.com>
Message-ID: <1b7cd94b-3f56-c3f7-99c9-9c87c9827b3f@oracle.com>

Sorry, that should be 'v7.1' (not 7.1a).

-- Kevin


On 11/8/2018 10:23 AM, Kevin Rushforth wrote:
> You need the Windows SDK v7.1a, which has the DirectShow Base Classes.
>
> -- Kevin
>
>
> On 11/8/2018 9:53 AM, carl at bekwam.com wrote:
>> Hi,
>>
>>
>> I'm able to build a non-media version of 8udev successfully. However, 
>> when
>> I try the -PCOMPILE_MEDIA option, I'm getting an error
>>
>>
>>> Task :media:buildWinPlugins
>> make: Entering directory
>> '/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl 
>>
>> ugins'
>>
>> make
>> TARGET=/cygdrive/d/hg/rt/modules/media/build/native/win/Release/baseclasses. 
>>
>> lib -f Makefile.BaseClasses
>>
>> cygpath: cannot create short name of C:\Program Files\Microsoft
>> SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses
>>
>> make[1]: Entering directory
>> '/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl 
>>
>> ugins'
>>
>> Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...
>>
>>
>> I have a new computer with Visual Studio 2017.?? I understand that the
>> DirectShow libraries have now been incorporated into the Windows SDK.? I
>> found header files like dshow.h in my hard drvie, but I don't have a
>> BaseClasses folder.
>>
>>
>> Has anyone compiled media with a recent VSS or are most people compiling
>> against residual artifacts from a while ago?
>>
>>
>> Thanks,
>>
>> Carl
>>
>>
>


From carl at bekwam.com  Thu Nov  8 18:53:52 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Thu, 8 Nov 2018 13:53:52 -0500
Subject: COMPILE_MEDIA Error on 8udev - DirectShow Question
In-Reply-To: <CACxS+sY6_tvCd9A_ni_cFtXWtEanx_vKfqMNC_x8dZLZje_5bg@mail.gmail.com>
References: <001d01d4778b$f7ca3250$e75e96f0$@bekwam.com>
 <CACxS+sY6_tvCd9A_ni_cFtXWtEanx_vKfqMNC_x8dZLZje_5bg@mail.gmail.com>
Message-ID: <004801d47794$649fb3c0$2ddf1b40$@bekwam.com>

Thanks.  I tried installing the Windows 7 SDK from you link, but the installer errored out mentioning that I needed the RTM .NET Framework 4.  Should I try to install this as well from here?

 

https://www.microsoft.com/en-us/download/details.aspx?id=17851

 

Is it possible to compile and link against the Windows 10 SDK or is everyone still on 7?

 

-Carl 

 

From: Artur Khusainov <turikhay at gmail.com> 
Sent: Thursday, November 8, 2018 1:21 PM
To: carl at bekwam.com
Cc: openjfx-dev at openjdk.java.net
Subject: Re: COMPILE_MEDIA Error on 8udev - DirectShow Question

 

Hi,

 

Try installing this: https://www.microsoft.com/en-us/download/details.aspx?id=8279

??, 8 ????. 2018 ?., 22:54 <carl at bekwam.com <mailto:carl at bekwam.com> >:

Hi,



I'm able to build a non-media version of 8udev successfully.  However, when
I try the -PCOMPILE_MEDIA option, I'm getting an error 



> Task :media:buildWinPlugins

make: Entering directory
'/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
ugins'

make
TARGET=/cygdrive/d/hg/rt/modules/media/build/native/win/Release/baseclasses.
lib -f Makefile.BaseClasses

cygpath: cannot create short name of C:\Program Files\Microsoft
SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses

make[1]: Entering directory
'/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
ugins'

Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...



I have a new computer with Visual Studio 2017.   I understand that the
DirectShow libraries have now been incorporated into the Windows SDK.  I
found header files like dshow.h in my hard drvie, but I don't have a
BaseClasses folder.



Has anyone compiled media with a recent VSS or are most people compiling
against residual artifacts from a while ago?



Thanks,

Carl





From turikhay at gmail.com  Thu Nov  8 19:15:50 2018
From: turikhay at gmail.com (Artur Khusainov)
Date: Fri, 9 Nov 2018 00:15:50 +0500
Subject: COMPILE_MEDIA Error on 8udev - DirectShow Question
In-Reply-To: <004801d47794$649fb3c0$2ddf1b40$@bekwam.com>
References: <001d01d4778b$f7ca3250$e75e96f0$@bekwam.com>
 <CACxS+sY6_tvCd9A_ni_cFtXWtEanx_vKfqMNC_x8dZLZje_5bg@mail.gmail.com>
 <004801d47794$649fb3c0$2ddf1b40$@bekwam.com>
Message-ID: <CACxS+sb7Zyh+9yYz+7SwchvVDgH6vxGTQ-53yavMWwhYc6L-Hw@mail.gmail.com>

This is known issue. You probably already installed Microsoft Visual C++
2010 Redistributable. Uninstall both x64 and x86, then try again.


??, 8 ????. 2018 ?. ? 23:53, <carl at bekwam.com>:

> Thanks.  I tried installing the Windows 7 SDK from you link, but the
> installer errored out mentioning that I needed the RTM .NET Framework 4.
> Should I try to install this as well from here?
>
>
>
> https://www.microsoft.com/en-us/download/details.aspx?id=17851
>
>
>
> Is it possible to compile and link against the Windows 10 SDK or is
> everyone still on 7?
>
>
>
> -Carl
>
>
>
> *From:* Artur Khusainov <turikhay at gmail.com>
> *Sent:* Thursday, November 8, 2018 1:21 PM
> *To:* carl at bekwam.com
> *Cc:* openjfx-dev at openjdk.java.net
> *Subject:* Re: COMPILE_MEDIA Error on 8udev - DirectShow Question
>
>
>
> Hi,
>
>
>
> Try installing this:
> https://www.microsoft.com/en-us/download/details.aspx?id=8279
>
> ??, 8 ????. 2018 ?., 22:54 <carl at bekwam.com>:
>
> Hi,
>
>
>
> I'm able to build a non-media version of 8udev successfully.  However, when
> I try the -PCOMPILE_MEDIA option, I'm getting an error
>
>
>
> > Task :media:buildWinPlugins
>
> make: Entering directory
>
> '/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
> ugins'
>
> make
>
> TARGET=/cygdrive/d/hg/rt/modules/media/build/native/win/Release/baseclasses.
> lib -f Makefile.BaseClasses
>
> cygpath: cannot create short name of C:\Program Files\Microsoft
> SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses
>
> make[1]: Entering directory
>
> '/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
> ugins'
>
> Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...
>
>
>
> I have a new computer with Visual Studio 2017.   I understand that the
> DirectShow libraries have now been incorporated into the Windows SDK.  I
> found header files like dshow.h in my hard drvie, but I don't have a
> BaseClasses folder.
>
>
>
> Has anyone compiled media with a recent VSS or are most people compiling
> against residual artifacts from a while ago?
>
>
>
> Thanks,
>
> Carl
>
>
>

From turikhay at gmail.com  Thu Nov  8 19:17:40 2018
From: turikhay at gmail.com (Artur Khusainov)
Date: Fri, 9 Nov 2018 00:17:40 +0500
Subject: COMPILE_MEDIA Error on 8udev - DirectShow Question
In-Reply-To: <CACxS+sb7Zyh+9yYz+7SwchvVDgH6vxGTQ-53yavMWwhYc6L-Hw@mail.gmail.com>
References: <001d01d4778b$f7ca3250$e75e96f0$@bekwam.com>
 <CACxS+sY6_tvCd9A_ni_cFtXWtEanx_vKfqMNC_x8dZLZje_5bg@mail.gmail.com>
 <004801d47794$649fb3c0$2ddf1b40$@bekwam.com>
 <CACxS+sb7Zyh+9yYz+7SwchvVDgH6vxGTQ-53yavMWwhYc6L-Hw@mail.gmail.com>
Message-ID: <CACxS+saCJcW1ZAZ5+26s7jXNkx9M20VSVpobVkZayrPRmqSq3w@mail.gmail.com>

(misleading attachment in previous message, sorry)

??, 9 ????. 2018 ?. ? 0:15, Artur Khusainov <turikhay at gmail.com>:

> This is known issue. You probably already installed Microsoft Visual C++
> 2010 Redistributable. Uninstall both x64 and x86, then try again.
>
>
> ??, 8 ????. 2018 ?. ? 23:53, <carl at bekwam.com>:
>
>> Thanks.  I tried installing the Windows 7 SDK from you link, but the
>> installer errored out mentioning that I needed the RTM .NET Framework 4.
>> Should I try to install this as well from here?
>>
>>
>>
>> https://www.microsoft.com/en-us/download/details.aspx?id=17851
>>
>>
>>
>> Is it possible to compile and link against the Windows 10 SDK or is
>> everyone still on 7?
>>
>>
>>
>> -Carl
>>
>>
>>
>> *From:* Artur Khusainov <turikhay at gmail.com>
>> *Sent:* Thursday, November 8, 2018 1:21 PM
>> *To:* carl at bekwam.com
>> *Cc:* openjfx-dev at openjdk.java.net
>> *Subject:* Re: COMPILE_MEDIA Error on 8udev - DirectShow Question
>>
>>
>>
>> Hi,
>>
>>
>>
>> Try installing this:
>> https://www.microsoft.com/en-us/download/details.aspx?id=8279
>>
>> ??, 8 ????. 2018 ?., 22:54 <carl at bekwam.com>:
>>
>> Hi,
>>
>>
>>
>> I'm able to build a non-media version of 8udev successfully.  However,
>> when
>> I try the -PCOMPILE_MEDIA option, I'm getting an error
>>
>>
>>
>> > Task :media:buildWinPlugins
>>
>> make: Entering directory
>>
>> '/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
>> ugins'
>>
>> make
>>
>> TARGET=/cygdrive/d/hg/rt/modules/media/build/native/win/Release/baseclasses.
>> lib -f Makefile.BaseClasses
>>
>> cygpath: cannot create short name of C:\Program Files\Microsoft
>> SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses
>>
>> make[1]: Entering directory
>>
>> '/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
>> ugins'
>>
>> Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...
>>
>>
>>
>> I have a new computer with Visual Studio 2017.   I understand that the
>> DirectShow libraries have now been incorporated into the Windows SDK.  I
>> found header files like dshow.h in my hard drvie, but I don't have a
>> BaseClasses folder.
>>
>>
>>
>> Has anyone compiled media with a recent VSS or are most people compiling
>> against residual artifacts from a while ago?
>>
>>
>>
>> Thanks,
>>
>> Carl
>>
>>
>>

From wowselim at gmail.com  Thu Nov  8 19:35:00 2018
From: wowselim at gmail.com (Selim Dincer)
Date: Thu, 8 Nov 2018 20:35:00 +0100
Subject: Cryptic exception when drawing in huge canvas
Message-ID: <CANp2C1xPh2DM3vyi0giGSj7V5cJYMJpR6-ii9vX-zpOP=z2RMA@mail.gmail.com>

Hey,

this morning I was doing something with the canvas control and got its size
wrong. It was way taller than I expected and I had an NPE somewhere in
NGCanvas but I didn't really understand what was wrong because nothing was
pointing to my code. I don't know how it behaves on linux, I was running
Windows 10.

A minimal example looks like following:

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.canvas.Canvas;
import javafx.scene.image.Image;
import javafx.scene.layout.BorderPane;
import javafx.stage.Stage;

public class CanvasTest extends Application {
    @Override
    public void start(Stage primaryStage) throws Exception {
        Canvas canvas = new Canvas(128, 10000);
        Image img = new
Image("https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png");
        canvas.getGraphicsContext2D().drawImage(img, 0, 0, 128, 128);

        primaryStage.setScene(new Scene(new BorderPane(canvas)));
        primaryStage.show();
    }
}

The StackTrace of the NPE looks like following:
java.lang.NullPointerException
at com.sun.javafx.sg.prism.NGCanvas$RenderBuf.validate(NGCanvas.java:213)
at com.sun.javafx.sg.prism.NGCanvas.initCanvas(NGCanvas.java:640)
at com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:603)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053)
at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945)
at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235)
at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576)
at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053)
at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945)
at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:477)
at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:330)
at
com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
at java.lang.Thread.run(Thread.java:748)

I guess you might have to make the canvas a little larger than that to
reproduce it on your system. I was creating the canvas as graphic of a
listcell and didn't realize that it was so large until I started debugging
(in this example the stage height indicates that something's wrong).
Maybe there should be a check with a more meaningful error message?

Thanks,
Selim

From carl at bekwam.com  Thu Nov  8 19:36:10 2018
From: carl at bekwam.com (carl at bekwam.com)
Date: Thu, 8 Nov 2018 14:36:10 -0500
Subject: COMPILE_MEDIA Error on 8udev - DirectShow Question
In-Reply-To: <CACxS+saCJcW1ZAZ5+26s7jXNkx9M20VSVpobVkZayrPRmqSq3w@mail.gmail.com>
References: <001d01d4778b$f7ca3250$e75e96f0$@bekwam.com>
 <CACxS+sY6_tvCd9A_ni_cFtXWtEanx_vKfqMNC_x8dZLZje_5bg@mail.gmail.com>
 <004801d47794$649fb3c0$2ddf1b40$@bekwam.com>
 <CACxS+sb7Zyh+9yYz+7SwchvVDgH6vxGTQ-53yavMWwhYc6L-Hw@mail.gmail.com>
 <CACxS+saCJcW1ZAZ5+26s7jXNkx9M20VSVpobVkZayrPRmqSq3w@mail.gmail.com>
Message-ID: <007901d4779a$4dc8a110$e959e330$@bekwam.com>

Thanks for your help Artur.  I?ve compiled successfully and AudioClip is working without throwing the glib lite link error.

 

For those also interested in compiling on a new machine, download the Windows 7 SDK.  Before installing, make sure that you?ve removed the VC++ 2010 Redistributable (x86+64).  The installer will give you a warning, but press OK.  The files will show up in the program files / Microsoft sdks / windows / v7.1 folder.

 

Return to the hg/rt source and run gradle -PCOMPILE_MEDIA=true

 

From: Artur Khusainov <turikhay at gmail.com> 
Sent: Thursday, November 8, 2018 2:18 PM
To: carl at bekwam.com
Cc: openjfx-dev at openjdk.java.net
Subject: Re: COMPILE_MEDIA Error on 8udev - DirectShow Question

 

(misleading attachment in previous message, sorry)

??, 9 ????. 2018 ?. ? 0:15, Artur Khusainov <turikhay at gmail.com <mailto:turikhay at gmail.com> >:

This is known issue. You probably already installed Microsoft Visual C++ 2010 Redistributable. Uninstall both x64 and x86, then try again. 

 

 

??, 8 ????. 2018 ?. ? 23:53, <carl at bekwam.com <mailto:carl at bekwam.com> >:

Thanks.  I tried installing the Windows 7 SDK from you link, but the installer errored out mentioning that I needed the RTM .NET Framework 4.  Should I try to install this as well from here?

 

https://www.microsoft.com/en-us/download/details.aspx?id=17851

 

Is it possible to compile and link against the Windows 10 SDK or is everyone still on 7?

 

-Carl 

 

From: Artur Khusainov <turikhay at gmail.com <mailto:turikhay at gmail.com> > 
Sent: Thursday, November 8, 2018 1:21 PM
To: carl at bekwam.com <mailto:carl at bekwam.com> 
Cc: openjfx-dev at openjdk.java.net <mailto:openjfx-dev at openjdk.java.net> 
Subject: Re: COMPILE_MEDIA Error on 8udev - DirectShow Question

 

Hi,

 

Try installing this: https://www.microsoft.com/en-us/download/details.aspx?id=8279

??, 8 ????. 2018 ?., 22:54 <carl at bekwam.com <mailto:carl at bekwam.com> >:

Hi,



I'm able to build a non-media version of 8udev successfully.  However, when
I try the -PCOMPILE_MEDIA option, I'm getting an error 



> Task :media:buildWinPlugins

make: Entering directory
'/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
ugins'

make
TARGET=/cygdrive/d/hg/rt/modules/media/build/native/win/Release/baseclasses.
lib -f Makefile.BaseClasses

cygpath: cannot create short name of C:\Program Files\Microsoft
SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses

make[1]: Entering directory
'/cygdrive/d/hg/rt/modules/media/src/main/native/gstreamer/projects/win/fxpl
ugins'

Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...



I have a new computer with Visual Studio 2017.   I understand that the
DirectShow libraries have now been incorporated into the Windows SDK.  I
found header files like dshow.h in my hard drvie, but I don't have a
BaseClasses folder.



Has anyone compiled media with a recent VSS or are most people compiling
against residual artifacts from a while ago?



Thanks,

Carl




From mike.ennen at gmail.com  Thu Nov  8 20:21:17 2018
From: mike.ennen at gmail.com (Michael Ennen)
Date: Thu, 8 Nov 2018 13:21:17 -0700
Subject: Problems building openjfx
In-Reply-To: <CAKZ_BFi49-ztzVo7s3BtwM=JYcOdugu1iMHfCk5PmM+Z0Mun0w@mail.gmail.com>
References: <20181031145703.Horde.ZQGCkkUxkwh_j5REAgomRw2@webmail.df.eu>
 <20181031150245.Horde.96kpsXfyvd5AkpBwsZ5GxQ1@webmail.df.eu>
 <CAOTPd674DR6QpoTErXbJ9=9T2fDhb9nrJKQO1nktpmBkjZHUQg@mail.gmail.com>
 <CABxFH2Gf4msXUGgCx5_vX2wxLYiQWQfLCQUECS6MY2nM693DWg@mail.gmail.com>
 <CAKZ_BFi49-ztzVo7s3BtwM=JYcOdugu1iMHfCk5PmM+Z0Mun0w@mail.gmail.com>
Message-ID: <CAOTPd64AsqA6rK7NQERcndTbP_0NHkVTtFtjy2WNuCR786LX7g@mail.gmail.com>

Indeed it requires choco package manager and it is meant to be run in
powershell.

Thank you for taking the time to report what worked for you. If there are
any changes
you think should be added to the script, feel free to open a PR on
https://github.com/javafxports/openjdk-jfx
as it is now officially part of the GitHub repository. I sort of hacked it
together very quickly and
only tested it on my local dev machine so improvements are definitely
welcome.

On Thu, Nov 8, 2018 at 9:38 AM Dean Wookey <wookey.dean at gmail.com> wrote:

> Hi Johan,
>
> Michael's build script helped me a lot. I'm on windows 10. It just runs in
> powershell after installing chocolatey, (.\tools\scripts\build1.ps from
> the openjdk root dir). The only environment variables I've got set are
> JAVA_HOME/JDK_HOME. I did have to make some modifications however to
> install the other dependencies and to handle the .dll's that weren't
> packaged. Everything ran fine on my machine, but as soon as I tried using
> the jars on another machine, I got linker errors. Below is the modified
> version. It won't package the correct dlls if DebugNative is used though,
> but as it is, it's working for me.
>
> Dean
>
> .\gradlew --stop
> choco install ant
> choco install vswhere
> choco install zip
> choco install visualstudio2017community
> choco install visualstudio2017-workload-nativedesktop
> choco install windows-sdk-7.1
> choco install cygwin
>
> $cygwinPath = (Get-ItemProperty -Path
> "HKLM:\SOFTWARE\Cygwin\setup").rootdir
> $env:Path += ";$($cygwinPath)\bin"
>
> $env:WINSDK_DIR = (Get-ItemProperty -Path
> "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows Kits\Installed
> Roots").KitsRoot10
> $env:VCINSTALLDIR = "$(vswhere -legacy -latest -property
> installationPath)\VC\Auxiliary\Build"
> $vcRoot = "$(vswhere -legacy -latest -property installationPath)"
> $msvcToolsVer = Get-Content
> "$env:VCINSTALLDIR\Microsoft.VCToolsVersion.default.txt"
> $msvcRedistVer = Get-Content
> "$env:VCINSTALLDIR\Microsoft.VCRedistVersion.default.txt"
>
> if ([string]::IsNullOrWhitespace($msvcToolsVer)) {
>   # The MSVC tools version file can have txt *or* props extension.
>   $msvcToolsVer = Get-Content
> "$env:VCINSTALLDIR\Microsoft.VCToolsVersion.default.props"
> }
> $env:MSVC_VER = $msvcToolsVer
> $env:MSVC_REDIST_VER = $msvcRedistVer
>
> $files = Get-ChildItem
> "$($vcRoot)/VC/Redist/MSVC/$($msvcRedistVer)/x86/*.CRT/"
> $crtVer = $files[0].Name.replace("Microsoft.VC","").replace(".CRT","")
> $env:WINDOWS_CRT_VER = $crtVer
>
>
> $env:VS150COMNTOOLS = $env:VCINSTALLDIR
> $env:VSVARS32FILE = "$env:VCINSTALLDIR\vcvars32.bat"
> refreshenv
> if ($env:APPVEYOR -eq "true") {
>   .\gradlew all test -PCOMPILE_WEBKIT=false -PCONF=Debug --stacktrace -x
> :web:test --info --no-daemon
>   if ($lastexitcode -ne 0) {
>     exit $lastexitcode
>   }
> } else {
>   .\gradlew all test -PCOMPILE_WEBKIT=false -PCONF=Debug --stacktrace -x
> :web:test --info
> }
>
> On Fri, Nov 2, 2018 at 8:57 PM Johan Vos <johan.vos at gluonhq.com> wrote:
>
>> Hi Michael,
>>
>> What environment do you use to run that Windows build script?
>> The windows builds are the ones I still feel least comfortable about. We
>> tried to automate those on AdoptOpenJDK infrastructure, but they are using
>> Ansible for provisioning machines (for very good reasons), and we spent
>> days trying to come up with an Ansible script that allowed to build on
>> Windows, without 100% success.
>> Hence, we currently create the windows build on a Windows machine with a
>> fixed setup. It would be better of course to move more of the environment
>> and context parameters to the build procedure itself, and your script
>> seems
>> a step in that direction. But what infrastructure do you use to run this?
>>
>> - Johan
>>
>> On Thu, Nov 1, 2018 at 11:17 PM Michael Ennen <mike.ennen at gmail.com>
>> wrote:
>>
>> > Also don't forget about the Windows build script:
>> >
>> >
>> >
>> https://github.com/javafxports/openjdk-jfx/blob/develop/tools/scripts/build.ps1
>> >
>> > It is what I use to automate the process of building OpenJFX on Windows
>> as
>> > much as
>> > possible. Any improvements to the script would be appreciated.
>> >
>> > On Wed, Oct 31, 2018 at 7:03 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 ;)
>> > >
>> > >
>> > >
>> > >
>> >
>> > --
>> > Michael Ennen
>> >
>>
>

-- 
Michael Ennen

From marcus.hirt at oracle.com  Thu Nov  8 20:25:19 2018
From: marcus.hirt at oracle.com (Marcus Hirt)
Date: Thu, 08 Nov 2018 21:25:19 +0100
Subject: RFR: JDK-8088418: Reintroducing the JFR Pulse Logger
Message-ID: <1E06CB54-4C30-499F-A7FC-0C7426BD7CCB@oracle.com>

Hi all,

Please review this PR to reintroduce the JFR Pulse Logger.

Jira:   https://bugs.openjdk.java.net/browse/JDK-8088418
PR:     https://github.com/javafxports/openjdk-jfx/pull/272

Kind regards,
Marcus





From kevin.rushforth at oracle.com  Thu Nov  8 23:25:49 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 8 Nov 2018 15:25:49 -0800
Subject: Cryptic exception when drawing in huge canvas
In-Reply-To: <CANp2C1xPh2DM3vyi0giGSj7V5cJYMJpR6-ii9vX-zpOP=z2RMA@mail.gmail.com>
References: <CANp2C1xPh2DM3vyi0giGSj7V5cJYMJpR6-ii9vX-zpOP=z2RMA@mail.gmail.com>
Message-ID: <bbba0f9f-2683-4109-9e5b-f1b91b00540f@oracle.com>

There is already a bug filed on this:

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

Yes, a more meaningful error message would be useful.

-- Kevin


On 11/8/2018 11:35 AM, Selim Dincer wrote:
> Hey,
>
> this morning I was doing something with the canvas control and got its size
> wrong. It was way taller than I expected and I had an NPE somewhere in
> NGCanvas but I didn't really understand what was wrong because nothing was
> pointing to my code. I don't know how it behaves on linux, I was running
> Windows 10.
>
> A minimal example looks like following:
>
> import javafx.application.Application;
> import javafx.scene.Scene;
> import javafx.scene.canvas.Canvas;
> import javafx.scene.image.Image;
> import javafx.scene.layout.BorderPane;
> import javafx.stage.Stage;
>
> public class CanvasTest extends Application {
>      @Override
>      public void start(Stage primaryStage) throws Exception {
>          Canvas canvas = new Canvas(128, 10000);
>          Image img = new
> Image("https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png");
>          canvas.getGraphicsContext2D().drawImage(img, 0, 0, 128, 128);
>
>          primaryStage.setScene(new Scene(new BorderPane(canvas)));
>          primaryStage.show();
>      }
> }
>
> The StackTrace of the NPE looks like following:
> java.lang.NullPointerException
> at com.sun.javafx.sg.prism.NGCanvas$RenderBuf.validate(NGCanvas.java:213)
> at com.sun.javafx.sg.prism.NGCanvas.initCanvas(NGCanvas.java:640)
> at com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:603)
> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053)
> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945)
> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:235)
> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:576)
> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053)
> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945)
> at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:477)
> at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:330)
> at
> com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
> at java.lang.Thread.run(Thread.java:748)
>
> I guess you might have to make the canvas a little larger than that to
> reproduce it on your system. I was creating the canvas as graphic of a
> listcell and didn't realize that it was so large until I started debugging
> (in this example the stage height indicates that something's wrong).
> Maybe there should be a check with a more meaningful error message?
>
> Thanks,
> Selim


From lenborje at gmail.com  Fri Nov  9 14:04:08 2018
From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=)
Date: Fri, 9 Nov 2018 15:04:08 +0100
Subject: Using the jpackager
Message-ID: <636E4480-560E-49DC-AFA1-582EF0236D63@gmail.com>

I've been trying to understand how to use the jpackager, but I'm stumped.

I have for a long been using the now defunct gradle-javafx plugin, so I've never really used the old javapackager either, only indirectly through gradle.

So I'm maybe asking terribly noob questions, but here goes:

Let's say I have a non-modular application packaged as an executable jar, i.e. a GUI I can launch with the "java -jar" command: How can I package this as a native application/dmg with jpackager?

On a more general note: What's the required layout/contents of the "input directory"?


Best regards,

/Lennart B?rjeson

From nlisker at gmail.com  Fri Nov  9 14:17:36 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 9 Nov 2018 16:17:36 +0200
Subject: Using the jpackager
In-Reply-To: <636E4480-560E-49DC-AFA1-582EF0236D63@gmail.com>
References: <636E4480-560E-49DC-AFA1-582EF0236D63@gmail.com>
Message-ID: <CA+0ynh_B73d33W1_CxSFcBP+GyTE=c8VgB4PEcQ=EnNYU9ErCw@mail.gmail.com>

There are some instructions in the JEP [1]. They show how to create a dmg.

[1]
https://bugs.openjdk.java.net/browse/JDK-8200758?focusedCommentId=14217780&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14217780

On Fri, Nov 9, 2018 at 4:06 PM Lennart B?rjeson <lenborje at gmail.com> wrote:

> I've been trying to understand how to use the jpackager, but I'm stumped.
>
> I have for a long been using the now defunct gradle-javafx plugin, so I've
> never really used the old javapackager either, only indirectly through
> gradle.
>
> So I'm maybe asking terribly noob questions, but here goes:
>
> Let's say I have a non-modular application packaged as an executable jar,
> i.e. a GUI I can launch with the "java -jar" command: How can I package
> this as a native application/dmg with jpackager?
>
> On a more general note: What's the required layout/contents of the "input
> directory"?
>
>
> Best regards,
>
> /Lennart B?rjeson

From wookey.dean at gmail.com  Fri Nov  9 14:27:14 2018
From: wookey.dean at gmail.com (Dean Wookey)
Date: Fri, 9 Nov 2018 16:27:14 +0200
Subject: RFR: 8213619: Windows powershell build script missing environment
 variables
Message-ID: <CAKZ_BFjRdfiLJz_Ukp5+PcCt5+HEHj_s3QkiJZNXr6RxAw7srg@mail.gmail.com>

Hi,

Please review the fix for JDK-8213619: Windows powershell build script
missing environment variables:
https://bugs.openjdk.java.net/browse/JDK-8213619
https://github.com/javafxports/openjdk-jfx/pull/276

Dean

From lenborje at gmail.com  Fri Nov  9 15:08:40 2018
From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=)
Date: Fri, 9 Nov 2018 16:08:40 +0100
Subject: Using the jpackager
In-Reply-To: <CA+0ynh_B73d33W1_CxSFcBP+GyTE=c8VgB4PEcQ=EnNYU9ErCw@mail.gmail.com>
References: <636E4480-560E-49DC-AFA1-582EF0236D63@gmail.com>
 <CA+0ynh_B73d33W1_CxSFcBP+GyTE=c8VgB4PEcQ=EnNYU9ErCw@mail.gmail.com>
Message-ID: <875E6B88-BB7F-44ED-AA95-A66568CA54B0@gmail.com>

You're thinking of the "HelloWorld.exe" example? That's not really informative, since it doesn't specify how to create the contents of the directory, nor the layout of the levels below app/ and runtime/.

I have a runnable jar, let's call it APP.jar.

If I try the naive: jpackager create-image -o out -j APP.jar

Error messages:

Bundler Mac Application Image skipped because of a configuration problem: The configured main jar does not exist APP.jar  
Advice to fix: The main jar must be specified relative to the app resources (not an absolute path), and must exist within those resources.



OK, let's do that. Put the jar in an "input dir": jpackager create-image -o out -i in -j APP.jar 

Error messages:

Creating app bundle: /Users/lennartb/App/out/App.app
"Adding modules: [] to runtime image."
Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException: jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing for java.base module
Error: Bundler "Mac Application Image" (mac.app) failed to produce a bundle.



I have of course tried a lot of other things, but I'd really like some pointers here...

Best regards,

/Lennart


> 9 nov. 2018 kl. 15:17 skrev Nir Lisker <nlisker at gmail.com>:
> 
> There are some instructions in the JEP [1]. They show how to create a dmg.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8200758?focusedCommentId=14217780&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14217780
> 
> On Fri, Nov 9, 2018 at 4:06 PM Lennart B?rjeson <lenborje at gmail.com> wrote:
> I've been trying to understand how to use the jpackager, but I'm stumped.
> 
> I have for a long been using the now defunct gradle-javafx plugin, so I've never really used the old javapackager either, only indirectly through gradle.
> 
> So I'm maybe asking terribly noob questions, but here goes:
> 
> Let's say I have a non-modular application packaged as an executable jar, i.e. a GUI I can launch with the "java -jar" command: How can I package this as a native application/dmg with jpackager?
> 
> On a more general note: What's the required layout/contents of the "input directory"?
> 
> 
> Best regards,
> 
> /Lennart B?rjeson


From rachel at merus.eu  Fri Nov  9 15:20:32 2018
From: rachel at merus.eu (Rachel Greenham)
Date: Fri, 9 Nov 2018 15:20:32 +0000
Subject: Using the jpackager
In-Reply-To: <636E4480-560E-49DC-AFA1-582EF0236D63@gmail.com>
References: <636E4480-560E-49DC-AFA1-582EF0236D63@gmail.com>
Message-ID: <8ca6697d-9c47-af9d-130e-93a6f610d034@merus.eu>

FWIW what I'm doing to build a windows app for jpackager, in terms of 
gradle tasks, that isn't modular. I hope this cleans up over time, but 
this is the final result of having just got the damn thing to work! :-)

I think *eventually* we'll have a single call to jpackager do the whole 
lot. But I think we're not there yet, so it's split out into separate 
steps. You *will* need to make changes for your own context:

Build the JRE needed using JLink, supplying the needed modules. The 
JLink task referenced is actually written in Java and wraps 
ToolProvider, but it's pretty trivial and could almost-more-easily be 
done with an Exec. NB: The JLink task as written puts it in a "java" 
subdirectory of the given destinationDir.

 ??? task buildAdminJre(type: JLink) {
 ??????? description 'Build the Client JRE for ' + nativeOsName
 ??????? destinationDir 
rootProject.file("deploy/bindist/"+requiredJava.merusNativeAdminJreName)
 ??????? modules = [
 ??????????? 'java.base',
 ??????????? 'java.desktop',
 ??????????? 'java.xml',
 ??????????? 'java.logging'
 ??????? ]
 ??????? bindServices false
 ??????? modulePath = 
[System.properties.getProperty('java.home')+File.separatorChar+'jmods']
 ??????? noHeaderFiles true
 ??????? noManPages true
 ??????? stripDebug true
 ??? }

Have the jar task build the application as normal. Here's mine as an 
example. The important part is, you don't need to build a single fat 
jar, but you can include the dependent jars with the Class-Path line 
below. Mine isn't a JavaFX app, so I don't know what it does now wrt 
pulling in the openjfx jars here, or whether you add them as modules to 
the jlink task above. I expect the former would be preferable.

 ??? /*
 ??? Basic non-fat jar.
 ??? */
 ??? jar {
 ??????? manifest {
 ??????????? attributes(
 ??????????????? 'Product-Name': applicationName,
 ??????????????? 'Main-Class': mainClassName,
 ??????????????? 'Package-Title': project.group,
 ??????????????? 'Package-Vendor': vendor,
 ??????????????? 'Package-Version': adminVersion,
 ??????????????? 'Permissions': "all-permissions",
 ??????????????? 'Class-Path': 
configurations.runtimeClasspath.files.collect { it.getName() }.join(' ')
 ??????????? )
 ??????? }
 ??????? archiveName = 'adm.jar'
 ??? }


Build the application image. This should be mostly platform independent. 
(I think the only thing stopping it being is probably the .ico file for 
the icon.) Note I'm supplying as --input the lib dir from the target 
built by the standard gradle installDist task, so it contains the 
dependencies as well. adm.jar's manifest lists these as dependencies in 
Class-Path as per above. The JRE is supplied in the --runtime-image 
parameter.

 ??? task createImage(type: Exec) {
 ??????? description 'Build the App Image for this platform using jpackager'
 ??????? dependsOn installDist
 ??????? dependsOn buildAdminJre
 ??????? def imageDir = "$buildDir/image"
 ??????? outputs.dir new File(imageDir,applicationName)
 ??????? commandLine 'jpackager', 'create-image',
 ??????????? '--verbose',
 ??????????? '--version',adminVersion,
 ??????????? '--input', new 
File(installDist.outputs.files.singleFile,"lib"),
 ??????????? '--output',imageDir,
 ??????????? '--name',applicationName,
 ??????????? '--description','<DESCRIPTION>',
 ??????????? '--main-jar','adm.jar',
 ??????????? '--class',mainClassName,
 ??????????? '--icon','src/main/files/app-icon.ico',
 ??????????? '--runtime-image',new 
File(buildAdminJre.outputs.files.singleFile,"java"),
 ??????????? '--vendor',vendor
 ??? }

You'll now have the application image suitable for your platform. I've 
only tried this on Windows so far.

Note: My app has a space in the applicationName value. This breaks at 
the moment. The following is a workaround task, split out for easy 
removal later when I'm sure it won't be necessary any more:

 ??? task fixWindowsImage(type: Copy) {
 ??????? /*
 ??????? This task creates a copy of the image created by createImage task
 ??????? and fixes it up for using as the source of a Windows Installer.
 ??????? As of first writing, what this means is renaming a couple of files,
 ??????? because create-image crushes out spaces in the application name but
 ??????? we want them in, we have to rename the generated .exe and .cfg 
files
 ??????? to have that space again.
 ??????? Then msiInstaller will work to actually create the shortcut and
 ??????? start menu items.
 ??????? */
 ??????? dependsOn createImage
 ??????? from createImage.outputs.files.singleFile
 ??????? into "$buildDir/fixedImage/$applicationName"
 ??????? rename ("<NAME-WITHOUT-SPACES>.exe", applicationName+".exe")
 ??????? rename ("<NAME-WITHOUT-SPACES>.cfg", applicationName+".cfg")
 ??? }

Then, as a separate stage, run the bit that puts it into an installer. 
So here the input supplied in --app-image is the complete application 
image as already created and fixed by the above tasks.

 ??? task msiInstaller(type: Exec) {
 ??????? /*
 ??????? see fixWindowsImage for a necessary fix to the created application
 ??????? image to allow shortcut and startmenu items to work.
 ??????? */
 ??????? description 'Build the Windows 64-bit MSI installer using 
jpackager'
 ??????? doFirst {
 ??????????? /*
 ??????????? For no reason I can discern, this task stopped working
 ??????????? (did nothing, as if not called) until I added this 
doFirst{} block
 ??????????? */
 ??????????? println description
 ??????? }
 ??????? dependsOn fixWindowsImage
 ??????? def msiDir = "$buildDir/msi"
 ??????? def msiName = applicationName+'-'+adminVersion+'.msi'
 ??????? outputs.file new File(msiDir, msiName)
 ??????? commandLine 'jpackager', 'create-installer', 'msi',
 ??????????? '--verbose',
 ??????????? '--version',adminVersion,
 ??????????? '--app-image',fixWindowsImage.outputs.files.singleFile,
 ??????????? '--output', msiDir,
 ??????????? '--name',applicationName,
 ??????????? '--description','<DESCRIPTION>',
 ??????????? '--icon','src/main/files/app-icon.ico',
 ??????????? '--win-per-user-install',
 ??????????? '--win-shortcut',
 ??????????? '--win-menu',
 ??????????? '--win-menu-group','<SUBMENU-NAME>',
 ??????????? '--win-upgrade-uuid','<UUID>'
 ??? }

Left for your own amusement, code-signing! (Off-Topic here although 
arguably jpackager could include that too.)

-- 
Rachel

On 09/11/2018 14:04, Lennart B?rjeson wrote:
> I've been trying to understand how to use the jpackager, but I'm stumped.
>
> I have for a long been using the now defunct gradle-javafx plugin, so I've never really used the old javapackager either, only indirectly through gradle.
>
> So I'm maybe asking terribly noob questions, but here goes:
>
> Let's say I have a non-modular application packaged as an executable jar, i.e. a GUI I can launch with the "java -jar" command: How can I package this as a native application/dmg with jpackager?
>
> On a more general note: What's the required layout/contents of the "input directory"?
>
>
> Best regards,
>
> /Lennart B?rjeson


From rachel at merus.eu  Fri Nov  9 15:41:11 2018
From: rachel at merus.eu (Rachel Greenham)
Date: Fri, 9 Nov 2018 15:41:11 +0000
Subject: Using the jpackager
In-Reply-To: <8ca6697d-9c47-af9d-130e-93a6f610d034@merus.eu>
References: <636E4480-560E-49DC-AFA1-582EF0236D63@gmail.com>
 <8ca6697d-9c47-af9d-130e-93a6f610d034@merus.eu>
Message-ID: <55732fca-e7ef-59b2-03a3-4b8a455a9888@merus.eu>

On 09/11/2018 15:20, Rachel Greenham wrote:

> Have the jar task build the application as normal. Here's mine as an 
> example. The important part is, you don't need to build a single fat 
> jar, but you can include the dependent jars with the Class-Path line 
> below. Mine isn't a JavaFX app, so I don't know what it does now wrt 
> pulling in the openjfx jars here, or whether you add them as modules 
> to the jlink task above. I expect the former would be preferable.

Correction, the *latter* would be preferable, of course.

-- 
Rachel


From randomdsdevel at gmail.com  Fri Nov  9 20:37:41 2018
From: randomdsdevel at gmail.com (Bryce Glover)
Date: Fri, 9 Nov 2018 15:37:41 -0500
Subject: OpenJFX Build Setup
Message-ID: <CALH-JHuCR3oX=7B60nCnHxs29aaWUcSkOvHg_gGq=itrmEjvSg@mail.gmail.com>

To Whom It May Concern,

     While going through the process of setting up an OpenJFX package to be
distributed via Homebrew in
https://github.com/Homebrew/homebrew-core/pull/32864, I noticed that the
results of running either plain 'gradle' or task-qualified 'gradle all'
don't include the following build products:

   - 'libfxplugins.dylib'
   - 'libglib-lite.dylib'
   - 'libgstreamer-lite.dylib'
   - 'libjfxmedia.dylib'
   - 'libjfxmedia_avf.dylib'
   - 'libjfxwebkit.dylib'

under '"$BUILD_PATH/build/artifacts/javafx-sdk-$VERSION/lib/"' (where '
$BUILD_PATH' is a temporary directory and '$VERSION' is the version being
built, currently v11.0.1+1, the latest release as of this writing) as
compared to the SDK archives you distribute on your download page
<https://gluonhq.com/products/javafx/>.  It's not immediately obvious from your
build instructions
<https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX> what
additional 'gradle' options and/or properties I might need to set in order
to fix this.  Given the presence of those dynamic libraries mentioning
GStreamer, it looks like I might be missing a dependency, too.  How might I
build these additional artifacts like you do for the pre-compiled releases?


Thanks in advance,
     Bryce Glover
     RandomDSdevel at gmail.com

From sverre.moe at gmail.com  Fri Nov  9 21:34:30 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Fri, 9 Nov 2018 22:34:30 +0100
Subject: Using the jpackager
In-Reply-To: <8ca6697d-9c47-af9d-130e-93a6f610d034@merus.eu>
References: <636E4480-560E-49DC-AFA1-582EF0236D63@gmail.com>
 <8ca6697d-9c47-af9d-130e-93a6f610d034@merus.eu>
Message-ID: <CALAJ+5A3-ZYoR+Tj5+7ExiteYwthcULoEkxevkteiUUb7Yyzqg@mail.gmail.com>

Den fre. 9. nov. 2018 kl. 16:22 skrev Rachel Greenham <rachel at merus.eu>:

> Build the JRE needed using JLink, supplying the needed modules. The
> JLink task referenced is actually written in Java and wraps
> ToolProvider, but it's pretty trivial and could almost-more-easily be
> done with an Exec. NB: The JLink task as written puts it in a "java"
> subdirectory of the given destinationDir.
>
>      task buildAdminJre(type: JLink) {
>          description 'Build the Client JRE for ' + nativeOsName
>          destinationDir
> rootProject.file("deploy/bindist/"+requiredJava.merusNativeAdminJreName)
>          modules = [
>              'java.base',
>              'java.desktop',
>              'java.xml',
>              'java.logging'
>          ]
>          bindServices false
>          modulePath =
> [System.properties.getProperty('java.home')+File.separatorChar+'jmods']
>          noHeaderFiles true
>          noManPages true
>          stripDebug true
>      }
>
>
> Which gradle plugin are you using that gives you type JLink?

From rachel at merus.eu  Fri Nov  9 23:59:27 2018
From: rachel at merus.eu (Rachel Greenham)
Date: Fri, 9 Nov 2018 23:59:27 +0000
Subject: Using the jpackager
In-Reply-To: <CALAJ+5A3-ZYoR+Tj5+7ExiteYwthcULoEkxevkteiUUb7Yyzqg@mail.gmail.com>
References: <636E4480-560E-49DC-AFA1-582EF0236D63@gmail.com>
 <8ca6697d-9c47-af9d-130e-93a6f610d034@merus.eu>
 <CALAJ+5A3-ZYoR+Tj5+7ExiteYwthcULoEkxevkteiUUb7Yyzqg@mail.gmail.com>
Message-ID: <16b78a39-db62-2c69-7a85-7692f51e3b6e@merus.eu>

None, that's just my own class task in buildSrc. It's a fairly trivial 
wrapper around a ToolProvider invocation of jlink, so I didn't think it 
was relevant enough to paste the source for that here too, when you 
could also do it trivially with an Exec task similar to the jpackager 
ones later in my first reply.

It's literally public class JLink extends DefaultTask with a bunch of 
getters and setters for the options and a run method that turns them 
into arguments and invokes via ToolProvider. The same task type is also 
used elsewhere in the root project to build the server JRE for the 
server component of this project, which was enough to make it worthwhile 
writing the task. (I also wanted to learn how to write java gradle 
tasks.) The point of the example I did paste was just about showing what 
options to set to jlink. jlink in any detail is offtopic here, this bit 
was just an illustration of using that to build the JRE first with the 
required modules, then use the result in jpackager to build a 
non-modular app.

I would expect to write a similar simple task for jpackager too at some 
point, I just haven't yet. They may be the basis of a useful packager 
plugin, but probably not before jpackager itself is more mature.

-- 
Rachel

On 09/11/2018 21:34, Sverre Moe wrote:
> Den fre. 9. nov. 2018 kl. 16:22 skrev Rachel Greenham <rachel at merus.eu 
> <mailto:rachel at merus.eu>>:
>
>     Build the JRE needed using JLink, supplying the needed modules. The
>     JLink task referenced is actually written in Java and wraps
>     ToolProvider, but it's pretty trivial and could almost-more-easily be
>     done with an Exec. NB: The JLink task as written puts it in a "java"
>     subdirectory of the given destinationDir.
>
>     ???? task buildAdminJre(type: JLink) {
>     ???????? description 'Build the Client JRE for ' + nativeOsName
>     ???????? destinationDir
>     rootProject.file("deploy/bindist/"+requiredJava.merusNativeAdminJreName)
>     ???????? modules = [
>     ???????????? 'java.base',
>     ???????????? 'java.desktop',
>     ???????????? 'java.xml',
>     ???????????? 'java.logging'
>     ???????? ]
>     ???????? bindServices false
>     ???????? modulePath =
>     [System.properties.getProperty('java.home')+File.separatorChar+'jmods']
>     ???????? noHeaderFiles true
>     ???????? noManPages true
>     ???????? stripDebug true
>     ???? }
>
>
> Which gradle plugin are you using that gives you type JLink?


From youngty1997 at gmail.com  Sat Nov 10 05:58:20 2018
From: youngty1997 at gmail.com (Ty Young)
Date: Fri, 9 Nov 2018 23:58:20 -0600
Subject: Bug: Not on FX application thread exception is inconsistent
Message-ID: <6a66d5d7-b81e-0fec-837e-0fd27a3c1684@gmail.com>

Hi,


My JavaFX program updates API objects in the background via a non FX 
thread that, when changed by another program, are reflected in my JavaFX 
GUI's controls by property binding, specifically TableView, Slider, 
TextField, and ComboBox. Problem is, while JavaFX is OK with this for 
TableView, Slider, and TextField, it throws a Not on FX application 
thread exception *only* for the ComboBox.


The code for the slider looks like this:

 ??? private class ValueListener implements ChangeListener<Integer>
 ??? {
 ??????? @Override
 ??????? public void changed(ObservableValue<? extends Integer> 
observable, Integer oldValue, Integer newValue)
 ??????? {
 ??????????? slider.getSlider().setValue(newValue);
 ??????????? slider.getTextBox().setText(newValue.toString());
 ??????? }
 ??? }


(the slider variable is misleading, it's actually a VBox that contains a 
Slider and a TextField. Need to change it but I digress.)


which works fine. However this:


 ??? private class ValueListener implements ChangeListener<E>
 ??? {
 ??????? @Override
 ??????? public void changed(ObservableValue<? extends E> observable, E 
oldValue, E newValue)
 ??????? {
 ??????????? combo.setValue(newValue);
 ??????? }
 ??? }


doesn't for the ComboBox.


Is this a bug or is there some legitimate invisible reason as to why the 
slider/textfield isn't throwing an error but the combobox one is?




From philip.race at oracle.com  Sat Nov 10 16:28:34 2018
From: philip.race at oracle.com (Philip Race)
Date: Sat, 10 Nov 2018 08:28:34 -0800
Subject: OpenJFX Build Setup
In-Reply-To: <CALH-JHuCR3oX=7B60nCnHxs29aaWUcSkOvHg_gGq=itrmEjvSg@mail.gmail.com>
References: <CALH-JHuCR3oX=7B60nCnHxs29aaWUcSkOvHg_gGq=itrmEjvSg@mail.gmail.com>
Message-ID: <5BE70732.2090507@oracle.com>

try
gradle -PCOMPILE_MEDIA=true -PCOMPILE_WEBKIT=true

-phil.

On 11/9/18, 12:37 PM, Bryce Glover wrote:
> To Whom It May Concern,
>
>       While going through the process of setting up an OpenJFX package to be
> distributed via Homebrew in
> https://github.com/Homebrew/homebrew-core/pull/32864, I noticed that the
> results of running either plain 'gradle' or task-qualified 'gradle all'
> don't include the following build products:
>
>     - 'libfxplugins.dylib'
>     - 'libglib-lite.dylib'
>     - 'libgstreamer-lite.dylib'
>     - 'libjfxmedia.dylib'
>     - 'libjfxmedia_avf.dylib'
>     - 'libjfxwebkit.dylib'
>
> under '"$BUILD_PATH/build/artifacts/javafx-sdk-$VERSION/lib/"' (where '
> $BUILD_PATH' is a temporary directory and '$VERSION' is the version being
> built, currently v11.0.1+1, the latest release as of this writing) as
> compared to the SDK archives you distribute on your download page
> <https://gluonhq.com/products/javafx/>.  It's not immediately obvious from your
> build instructions
> <https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX>  what
> additional 'gradle' options and/or properties I might need to set in order
> to fix this.  Given the presence of those dynamic libraries mentioning
> GStreamer, it looks like I might be missing a dependency, too.  How might I
> build these additional artifacts like you do for the pre-compiled releases?
>
>
> Thanks in advance,
>       Bryce Glover
>       RandomDSdevel at gmail.com

From randomdsdevel at gmail.com  Sat Nov 10 18:15:12 2018
From: randomdsdevel at gmail.com (Bryce Glover)
Date: Sat, 10 Nov 2018 13:15:12 -0500
Subject: Fwd: OpenJFX Build Setup
In-Reply-To: <CALH-JHsiU0J2h6a9eMCT=TmSwywZXYZiw3HuGNR7kd-noxbU6g@mail.gmail.com>
References: <CALH-JHuCR3oX=7B60nCnHxs29aaWUcSkOvHg_gGq=itrmEjvSg@mail.gmail.com>
 <5BE70732.2090507@oracle.com>
 <CALH-JHsiU0J2h6a9eMCT=TmSwywZXYZiw3HuGNR7kd-noxbU6g@mail.gmail.com>
Message-ID: <CALH-JHubmXAA8a=D7Mvhu41iSsckTmsAAGvJxfd1zbVPueqkGw@mail.gmail.com>

     Whoops; forgot to CC the list:

---------- Forwarded message ---------
From: Bryce Glover <randomdsdevel at gmail.com>
Date: Sat, Nov 10, 2018 at 1:11 PM
Subject: Re: OpenJFX Build Setup
To: <philip.race at oracle.com>


On Sat, Nov 10, 2018 at 11:28 AM Philip Race <philip.race at oracle.com> wrote:

> try
> gradle -PCOMPILE_MEDIA=true -PCOMPILE_WEBKIT=true
>
> -phil.
>
> On 11/9/18, 12:37 PM, Bryce Glover wrote:
> > (*Snipped?*)
>

Dear Phil,

     Ah; if those options really only control building those sub-projects'
associated '.dylib's, then you might want to change those properties' names
or document them more explicitly within your build instructions.  I didn't
think I'd need to set those because everything aside from those dynamic
libraries was already getting built for those components, hence why I
overlooked doing that.

Thanks,
     Bryce

From sverre.moe at gmail.com  Sun Nov 11 22:00:25 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Sun, 11 Nov 2018 23:00:25 +0100
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: <CALAJ+5BYYSJknS64XFOZRQBhqG2zM8Cw-1ViBGyADo+ib4iDcw@mail.gmail.com>

Johan,
has there been any new updates to jpackager in JDK12 since you backported
it?

I have found some problems with jpackager. Perhaps they might have been
fixed later.
I mentioned this to core-list-dev mailinglist on jpackager thread.

1)
The control file for debian package does not set correct description

--name test
--description This is a Test Application

/tmp/jdk.packager607148779833718376/linux/control
Package: test
Description: test

The RPM gets it correctly
Summary     : test
Description :
This is a Test Application

2)
Category is not set on either DEB or RPM
  --category
          Category or group of the application.
--category "Some/Category/Application"
Group: Unspecified
Section: unknown

Perhaps I have misunderstood what this category is for, because I see this
it is set in the generated application.desktop, but It should definitely
also be set in the RPM and DEB.

/Sverre

Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos <johan.vos at gluonhq.com>:

> 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 nlisker at gmail.com  Mon Nov 12 10:41:10 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 12 Nov 2018 12:41:10 +0200
Subject: Running JavaFX-11 applications from within Eclipse fails
In-Reply-To: <CA+0ynh8tjNZYo3536595iYUTC0_z=P=Din75Eysm_7hKhn-VhA@mail.gmail.com>
References: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
 <CABxFH2HdykTWPoRcuWsLK25P-a5tc3JTREbDh6f9X1TRnCEU+w@mail.gmail.com>
 <eb8f0df2-d6c3-5b68-665e-90f38f553234@oracle.com>
 <CAGMSBrJip3RVgmYi-Qmd33-ZDuJ-oyFcpFeY2W+_vTm_dvngng@mail.gmail.com>
 <2D6BD968-CF35-41CB-A545-DC7F34BD3FF9@bestsolution.at>
 <CA+0ynh8tjNZYo3536595iYUTC0_z=P=Din75Eysm_7hKhn-VhA@mail.gmail.com>
Message-ID: <CA+0ynh8HckmXx-E=yPV+AyWYX3r68y=+4ta3xChZ8yk6iZAzXA@mail.gmail.com>

I managed to solve my problem. It's actually looking for the dlls, so using

-Djava.library.path="...\rt\modules\javafx.graphics\build\module-lib"

will start the application properly. If anyone can confirm this problem and
solution I'll add this step to the wiki.

On Wed, Nov 7, 2018 at 6:21 PM Nir Lisker <nlisker at gmail.com> wrote:

> I have a related problem when developing JavaFX in Eclipse and Win10 that
> started in 11.
>
> I created a modular project and in its build configuration (in Eclipse) I
> added the JavaFX base and graphics projects (that point to rt\modules\...)
> and OpenJDK11 to the module path.
> In the module-info file I required the JavaFX modules and exported my
> package.
>
> Compilation is fine, but during runtime (with -Dprism.verbose=true) I get
> an error:
>
> Prism pipeline init order: d3d 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.d3d.D3DPipeline
> Loading D3D native library ...
> // Error here: //
> GraphicsPipeline.createPipeline failed for com.sun.prism.d3d.D3DPipeline
> java.lang.UnsatisfiedLinkError: no prism_sw in java.library.path: [see
> below]
> 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.d3d.D3DPipeline.lambda$0(D3DPipeline.java:48)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> javafx.graphics/com.sun.prism.d3d.D3DPipeline.<clinit>(D3DPipeline.java:44)
> 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: [see
> below]
> 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$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 :  d3d, sw
> Error initializing QuantumRenderer: no suitable pipeline found
> // ...
>
> The paths listed at the end are those from %PATH% and none point to the
> development modules. So, I added to the runtime VM args in the launch
> configuration:
>
> -Djava.library.path="...\rt\modules\javafx.graphics\bin"
> and I also tried with
> "...\rt\modules\javafx.graphics\bin\com\sun\prism\d3d" because this is
> where com.sun.prism.d3d.D3DPipeline is.
>
> I get the same error. Did anyone encounter this?
>
> - Nir
>
> On Sun, Nov 4, 2018 at 6:40 PM Tom Schindl <tom.schindl at bestsolution.at>
> wrote:
>
>> I think the more general problem is that they don?t run on the
>> module-path - in the m2e case this because the modules are transitive deps
>> and those are not supported properly
>>
>> Tom
>>
>> Von meinem iPhone gesendet
>>
>> > Am 04.11.2018 um 16:17 schrieb Jos? Pereda <jose.pereda at gluonhq.com>:
>> >
>> > I've just noticed that this issue happens not only with Maven but also
>> with
>> > Gradle projects (Gradle + Eclipse 2018-09 + Windows with Oracle JDK
>> 1.8),
>> > running gradle tasks from Eclipse.
>> >
>> > The same proposed workaround can be applied to the build file:
>> >
>> > run {
>> >
>> >    systemProperty "java.library.path", "C:\tmp"
>> >
>> > }
>> >
>> >
>> >
>> >
>> > On Mon, Oct 22, 2018 at 4:43 PM Kevin Rushforth <
>> kevin.rushforth at oracle.com>
>> > wrote:
>> >
>> >>
>> >>> 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 tom.schindl at bestsolution.at  Mon Nov 12 12:32:30 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Mon, 12 Nov 2018 13:32:30 +0100
Subject: Running JavaFX-11 applications from within Eclipse fails
In-Reply-To: <CA+0ynh8HckmXx-E=yPV+AyWYX3r68y=+4ta3xChZ8yk6iZAzXA@mail.gmail.com>
References: <ed49f79e-5191-2043-4094-9cb18eb30183@bestsolution.at>
 <CABxFH2HdykTWPoRcuWsLK25P-a5tc3JTREbDh6f9X1TRnCEU+w@mail.gmail.com>
 <eb8f0df2-d6c3-5b68-665e-90f38f553234@oracle.com>
 <CAGMSBrJip3RVgmYi-Qmd33-ZDuJ-oyFcpFeY2W+_vTm_dvngng@mail.gmail.com>
 <2D6BD968-CF35-41CB-A545-DC7F34BD3FF9@bestsolution.at>
 <CA+0ynh8tjNZYo3536595iYUTC0_z=P=Din75Eysm_7hKhn-VhA@mail.gmail.com>
 <CA+0ynh8HckmXx-E=yPV+AyWYX3r68y=+4ta3xChZ8yk6iZAzXA@mail.gmail.com>
Message-ID: <8fec3b14-d310-debb-476d-c99de207115d@bestsolution.at>

Hi,

I never used the relative version but can confirm that you have to set
the library path to the built DLLs

Tom

On 12.11.18 11:41, Nir Lisker wrote:
> I managed to solve my problem. It's actually looking for the dlls, so using
> 
> -Djava.library.path="...\rt\modules\javafx.graphics\build\module-lib"
> 
> will start the application properly. If anyone can confirm this problem
> and solution I'll add this step to the wiki.
> 
> On Wed, Nov 7, 2018 at 6:21 PM Nir Lisker <nlisker at gmail.com
> <mailto:nlisker at gmail.com>> wrote:
> 
>     I have a related problem when developing JavaFX in Eclipse and Win10
>     that started in 11.
> 
>     I created a modular project and in its build configuration (in
>     Eclipse) I added the JavaFX base and graphics projects (that point
>     to rt\modules\...) and OpenJDK11 to the module path.
>     In the module-info file I required the JavaFX modules and exported
>     my package.
> 
>     Compilation is fine, but during runtime (with?-Dprism.verbose=true)
>     I get an error:
> 
>     Prism pipeline init order: d3d 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.d3d.D3DPipeline
>     Loading D3D native library ...
>     // Error here: //
>     GraphicsPipeline.createPipeline failed for com.sun.prism.d3d.D3DPipeline
>     java.lang.UnsatisfiedLinkError: no prism_sw in java.library.path:
>     [see below]
>     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.d3d.D3DPipeline.lambda$0(D3DPipeline.java:48)
>     at java.base/java.security.AccessController.doPrivileged(Native Method)
>     at
>     javafx.graphics/com.sun.prism.d3d.D3DPipeline.<clinit>(D3DPipeline.java:44)
>     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:
>     [see below]
>     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$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 :? d3d, sw
>     Error initializing QuantumRenderer: no suitable pipeline found
>     // ...
> 
>     The paths listed at the end are those from %PATH% and none point to
>     the development modules. So, I added to the runtime VM args in the
>     launch configuration:
> 
>     -Djava.library.path="...\rt\modules\javafx.graphics\bin"
>     and I also tried with
>     "...\rt\modules\javafx.graphics\bin\com\sun\prism\d3d" because this
>     is where com.sun.prism.d3d.D3DPipeline is.
> 
>     I get the same error. Did anyone encounter this?
> 
>     - Nir
> 
>     On Sun, Nov 4, 2018 at 6:40 PM Tom Schindl
>     <tom.schindl at bestsolution.at <mailto:tom.schindl at bestsolution.at>>
>     wrote:
> 
>         I think the more general problem is that they don?t run on the
>         module-path - in the m2e case this because the modules are
>         transitive deps and those are not supported properly
> 
>         Tom
> 
>         Von meinem iPhone gesendet
> 
>         > Am 04.11.2018 um 16:17 schrieb Jos? Pereda
>         <jose.pereda at gluonhq.com <mailto:jose.pereda at gluonhq.com>>:
>         >
>         > I've just noticed that this issue happens not only with Maven
>         but also with
>         > Gradle projects (Gradle + Eclipse 2018-09 + Windows with
>         Oracle JDK 1.8),
>         > running gradle tasks from Eclipse.
>         >
>         > The same proposed workaround can be applied to the build file:
>         >
>         > run {
>         >
>         >? ? systemProperty "java.library.path", "C:\tmp"
>         >
>         > }
>         >
>         >
>         >
>         >
>         > On Mon, Oct 22, 2018 at 4:43 PM Kevin Rushforth
>         <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
>         > wrote:
>         >
>         >>
>         >>> 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 <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 youngty1997 at gmail.com  Mon Nov 12 21:04:51 2018
From: youngty1997 at gmail.com (Ty Young)
Date: Mon, 12 Nov 2018 15:04:51 -0600
Subject: Bug: Not on FX application thread exception is inconsistent
In-Reply-To: <6a66d5d7-b81e-0fec-837e-0fd27a3c1684@gmail.com>
References: <6a66d5d7-b81e-0fec-837e-0fd27a3c1684@gmail.com>
Message-ID: <7aec84cd-4237-75e6-7dd1-9fb8dba6c599@gmail.com>


On 11/9/18 11:58 PM, Ty Young wrote:
> Hi,
>
>
> My JavaFX program updates API objects in the background via a non FX 
> thread that, when changed by another program, are reflected in my 
> JavaFX GUI's controls by property binding, specifically TableView, 
> Slider, TextField, and ComboBox. Problem is, while JavaFX is OK with 
> this for TableView, Slider, and TextField, it throws a Not on FX 
> application thread exception *only* for the ComboBox.
>
>
> The code for the slider looks like this:
>
> ??? private class ValueListener implements ChangeListener<Integer>
> ??? {
> ??????? @Override
> ??????? public void changed(ObservableValue<? extends Integer> 
> observable, Integer oldValue, Integer newValue)
> ??????? {
> ??????????? slider.getSlider().setValue(newValue);
> ??????????? slider.getTextBox().setText(newValue.toString());
> ??????? }
> ??? }
>
>
> (the slider variable is misleading, it's actually a VBox that contains 
> a Slider and a TextField. Need to change it but I digress.)
>
>
> which works fine. However this:
>
>
> ??? private class ValueListener implements ChangeListener<E>
> ??? {
> ??????? @Override
> ??????? public void changed(ObservableValue<? extends E> observable, E 
> oldValue, E newValue)
> ??????? {
> ??????????? combo.setValue(newValue);
> ??????? }
> ??? }
>
>
> doesn't for the ComboBox.
>
>
> Is this a bug or is there some legitimate invisible reason as to why 
> the slider/textfield isn't throwing an error but the combobox one is?
>
>
>

Anything at all on this? Does JavaFX have bipolar thread disorder or 
something?


From tom.schindl at bestsolution.at  Mon Nov 12 23:39:45 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Tue, 13 Nov 2018 00:39:45 +0100
Subject: Bug: Not on FX application thread exception is inconsistent
In-Reply-To: <6a66d5d7-b81e-0fec-837e-0fd27a3c1684@gmail.com>
References: <6a66d5d7-b81e-0fec-837e-0fd27a3c1684@gmail.com>
Message-ID: <5863a15b-2177-b9a0-4719-ab3cbf1d1a74@bestsolution.at>

Hi,

You are supposed to interact with Nodes who are currently shown in the
SG only only the JavaFX Application Thread.

JavaFX although is not checking each and every property (change) as this
would be too resource intensive but at sensitive cases (eg when
interacting with Glass) it does check that you run on the correct thread.

Even though your TableView, ... updates seem to work you can run into
disasterous states - see eg https://bugs.openjdk.java.net/browse/JDK-8198577

Tom

On 10.11.18 06:58, Ty Young wrote:
> Hi,
> 
> 
> My JavaFX program updates API objects in the background via a non FX
> thread that, when changed by another program, are reflected in my JavaFX
> GUI's controls by property binding, specifically TableView, Slider,
> TextField, and ComboBox. Problem is, while JavaFX is OK with this for
> TableView, Slider, and TextField, it throws a Not on FX application
> thread exception *only* for the ComboBox.
> 
> 
> The code for the slider looks like this:
> 
> ??? private class ValueListener implements ChangeListener<Integer>
> ??? {
> ??????? @Override
> ??????? public void changed(ObservableValue<? extends Integer>
> observable, Integer oldValue, Integer newValue)
> ??????? {
> ??????????? slider.getSlider().setValue(newValue);
> ??????????? slider.getTextBox().setText(newValue.toString());
> ??????? }
> ??? }
> 
> 
> (the slider variable is misleading, it's actually a VBox that contains a
> Slider and a TextField. Need to change it but I digress.)
> 
> 
> which works fine. However this:
> 
> 
> ??? private class ValueListener implements ChangeListener<E>
> ??? {
> ??????? @Override
> ??????? public void changed(ObservableValue<? extends E> observable, E
> oldValue, E newValue)
> ??????? {
> ??????????? combo.setValue(newValue);
> ??????? }
> ??? }
> 
> 
> doesn't for the ComboBox.
> 
> 
> Is this a bug or is there some legitimate invisible reason as to why the
> slider/textfield isn't throwing an error but the combobox one is?
> 
> 
> 

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

From youngty1997 at gmail.com  Tue Nov 13 03:00:58 2018
From: youngty1997 at gmail.com (Ty Young)
Date: Mon, 12 Nov 2018 21:00:58 -0600
Subject: Bug: Not on FX application thread exception is inconsistent
In-Reply-To: <5863a15b-2177-b9a0-4719-ab3cbf1d1a74@bestsolution.at>
References: <6a66d5d7-b81e-0fec-837e-0fd27a3c1684@gmail.com>
 <5863a15b-2177-b9a0-4719-ab3cbf1d1a74@bestsolution.at>
Message-ID: <e6c6c2a8-c6e5-d7af-c59e-7d834994ce3c@gmail.com>


On 11/12/18 5:39 PM, Tom Schindl wrote:
> Hi,
>
> You are supposed to interact with Nodes who are currently shown in the
> SG only only the JavaFX Application Thread.


I never touch the GUI in my other threads, ever. The threads simply 
change the value of a type stored in a property. The ChangeListener that 
is used is created in the GUI JavaFX thread.


>
> JavaFX although is not checking each and every property (change) as this
> would be too resource intensive but at sensitive cases (eg when
> interacting with Glass) it does check that you run on the correct thread.


The update process for updating my API objects is slow(for reasons 
beyond my control), so even assuming I somehow manage to magically 
update everything in the GUI thread, how the hell do you fix the GUI 
stuttering at that point?


Really, having an entire application do all of it's processing on one 
thread in 2018 is really just idiotic and asking for trouble.


>
> Even though your TableView, ... updates seem to work you can run into
> disasterous states - see eg https://bugs.openjdk.java.net/browse/JDK-8198577
>
> Tom


I'm not sure what the bug is about since the description really doesn't 
give much info however I really haven't noticed anything, even long term 
with it being open for 8+ hours. These objects are update very 
frequently as well.


To be clear, this isn't some business application that gets info from a 
database or something.


> On 10.11.18 06:58, Ty Young wrote:
>> Hi,
>>
>>
>> My JavaFX program updates API objects in the background via a non FX
>> thread that, when changed by another program, are reflected in my JavaFX
>> GUI's controls by property binding, specifically TableView, Slider,
>> TextField, and ComboBox. Problem is, while JavaFX is OK with this for
>> TableView, Slider, and TextField, it throws a Not on FX application
>> thread exception *only* for the ComboBox.
>>
>>
>> The code for the slider looks like this:
>>
>>  ??? private class ValueListener implements ChangeListener<Integer>
>>  ??? {
>>  ??????? @Override
>>  ??????? public void changed(ObservableValue<? extends Integer>
>> observable, Integer oldValue, Integer newValue)
>>  ??????? {
>>  ??????????? slider.getSlider().setValue(newValue);
>>  ??????????? slider.getTextBox().setText(newValue.toString());
>>  ??????? }
>>  ??? }
>>
>>
>> (the slider variable is misleading, it's actually a VBox that contains a
>> Slider and a TextField. Need to change it but I digress.)
>>
>>
>> which works fine. However this:
>>
>>
>>  ??? private class ValueListener implements ChangeListener<E>
>>  ??? {
>>  ??????? @Override
>>  ??????? public void changed(ObservableValue<? extends E> observable, E
>> oldValue, E newValue)
>>  ??????? {
>>  ??????????? combo.setValue(newValue);
>>  ??????? }
>>  ??? }
>>
>>
>> doesn't for the ComboBox.
>>
>>
>> Is this a bug or is there some legitimate invisible reason as to why the
>> slider/textfield isn't throwing an error but the combobox one is?
>>
>>
>>

From brian.r.hudson at gmail.com  Tue Nov 13 03:12:00 2018
From: brian.r.hudson at gmail.com (Brian Hudson)
Date: Mon, 12 Nov 2018 22:12:00 -0500
Subject: Bug: Not on FX application thread exception is inconsistent
In-Reply-To: <e6c6c2a8-c6e5-d7af-c59e-7d834994ce3c@gmail.com>
References: <6a66d5d7-b81e-0fec-837e-0fd27a3c1684@gmail.com>
 <5863a15b-2177-b9a0-4719-ab3cbf1d1a74@bestsolution.at>
 <e6c6c2a8-c6e5-d7af-c59e-7d834994ce3c@gmail.com>
Message-ID: <CAJo47rVOFgneWECdqyZnj=7jbxZwZiA2Oz5K3fhoS=10DZc9-w@mail.gmail.com>

JavaFX like every other modern UI framework is single threaded.

The updating of your ?API objects? can and should remain on a background
thread, however once updated the changes which trigger an update to your UI
(changing a value in a bound property) should occur on the JavaFX thread
via Platform.runLater for example.

Also, take the attitude down a notch or two.

Brian


On Mon, Nov 12, 2018 at 10:02 PM Ty Young <youngty1997 at gmail.com> wrote:

>
> On 11/12/18 5:39 PM, Tom Schindl wrote:
> > Hi,
> >
> > You are supposed to interact with Nodes who are currently shown in the
> > SG only only the JavaFX Application Thread.
>
>
> I never touch the GUI in my other threads, ever. The threads simply
> change the value of a type stored in a property. The ChangeListener that
> is used is created in the GUI JavaFX thread.
>
>
> >
> > JavaFX although is not checking each and every property (change) as this
> > would be too resource intensive but at sensitive cases (eg when
> > interacting with Glass) it does check that you run on the correct thread.
>
>
> The update process for updating my API objects is slow(for reasons
> beyond my control), so even assuming I somehow manage to magically
> update everything in the GUI thread, how the hell do you fix the GUI
> stuttering at that point?
>
>
> Really, having an entire application do all of it's processing on one
> thread in 2018 is really just idiotic and asking for trouble.
>
>
> >
> > Even though your TableView, ... updates seem to work you can run into
> > disasterous states - see eg
> https://bugs.openjdk.java.net/browse/JDK-8198577
> >
> > Tom
>
>
> I'm not sure what the bug is about since the description really doesn't
> give much info however I really haven't noticed anything, even long term
> with it being open for 8+ hours. These objects are update very
> frequently as well.
>
>
> To be clear, this isn't some business application that gets info from a
> database or something.
>
>
> > On 10.11.18 06:58, Ty Young wrote:
> >> Hi,
> >>
> >>
> >> My JavaFX program updates API objects in the background via a non FX
> >> thread that, when changed by another program, are reflected in my JavaFX
> >> GUI's controls by property binding, specifically TableView, Slider,
> >> TextField, and ComboBox. Problem is, while JavaFX is OK with this for
> >> TableView, Slider, and TextField, it throws a Not on FX application
> >> thread exception *only* for the ComboBox.
> >>
> >>
> >> The code for the slider looks like this:
> >>
> >>      private class ValueListener implements ChangeListener<Integer>
> >>      {
> >>          @Override
> >>          public void changed(ObservableValue<? extends Integer>
> >> observable, Integer oldValue, Integer newValue)
> >>          {
> >>              slider.getSlider().setValue(newValue);
> >>              slider.getTextBox().setText(newValue.toString());
> >>          }
> >>      }
> >>
> >>
> >> (the slider variable is misleading, it's actually a VBox that contains a
> >> Slider and a TextField. Need to change it but I digress.)
> >>
> >>
> >> which works fine. However this:
> >>
> >>
> >>      private class ValueListener implements ChangeListener<E>
> >>      {
> >>          @Override
> >>          public void changed(ObservableValue<? extends E> observable, E
> >> oldValue, E newValue)
> >>          {
> >>              combo.setValue(newValue);
> >>          }
> >>      }
> >>
> >>
> >> doesn't for the ComboBox.
> >>
> >>
> >> Is this a bug or is there some legitimate invisible reason as to why the
> >> slider/textfield isn't throwing an error but the combobox one is?
> >>
> >>
> >>
>

From youngty1997 at gmail.com  Tue Nov 13 04:38:08 2018
From: youngty1997 at gmail.com (Ty Young)
Date: Mon, 12 Nov 2018 22:38:08 -0600
Subject: Bug: Not on FX application thread exception is inconsistent
In-Reply-To: <CAJo47rVOFgneWECdqyZnj=7jbxZwZiA2Oz5K3fhoS=10DZc9-w@mail.gmail.com>
References: <6a66d5d7-b81e-0fec-837e-0fd27a3c1684@gmail.com>
 <5863a15b-2177-b9a0-4719-ab3cbf1d1a74@bestsolution.at>
 <e6c6c2a8-c6e5-d7af-c59e-7d834994ce3c@gmail.com>
 <CAJo47rVOFgneWECdqyZnj=7jbxZwZiA2Oz5K3fhoS=10DZc9-w@mail.gmail.com>
Message-ID: <e9c7f96d-084a-5ef9-ff5a-d7ef248983d0@gmail.com>


On 11/12/18 9:12 PM, Brian Hudson wrote:
> JavaFX like every other modern UI framework is single threaded.


Which in itself is fine, running *just* the UI isn't much on modern 
processors. Adding a bunch of API object updates that cause thread 
slowdown to the mix that can cause UI stuttering is, again, asking for 
trouble.


And how is TableView, Slider, TextField, etc all working just fine but 
ComboBox freaks out? What's so special about ComboBox? Is there some 
hack I can do to not trigger the exception?


>
> The updating of your ?API objects? can and should remain on a 
> background thread, however once updated the changes which trigger an 
> update to your UI (changing a value in a bound property) should occur 
> on the JavaFX thread via Platform.runLater for example.
>

Doing all this is just messy, inefficient, and duplicating code. It 
would involve creating Runnable implementations that does about 10 lines 
of code with objects that get updated as fast as they can be with 
different object types, resulting in more threads and garbage being 
created. Using generic magic isn't really a solution either because 
different API objects convert data from String to some other type 
depending on the implementation.


Would it not be possible to have a runPlatformListener method that just 
runs the ChangeListener on the platform thread automatically? It would 
reduce the amount of garbage dramatically since JavaFX only ever fires a 
change event if the object is itself different(in other words, if the 
current value is 0 and the new value is 0, there is no change) which is 
nice and efficient.


> Also, take the attitude down a notch or two.
>
> Brian
>
>
> On Mon, Nov 12, 2018 at 10:02 PM Ty Young <youngty1997 at gmail.com 
> <mailto:youngty1997 at gmail.com>> wrote:
>
>
>     On 11/12/18 5:39 PM, Tom Schindl wrote:
>     > Hi,
>     >
>     > You are supposed to interact with Nodes who are currently shown
>     in the
>     > SG only only the JavaFX Application Thread.
>
>
>     I never touch the GUI in my other threads, ever. The threads simply
>     change the value of a type stored in a property. The
>     ChangeListener that
>     is used is created in the GUI JavaFX thread.
>
>
>     >
>     > JavaFX although is not checking each and every property (change)
>     as this
>     > would be too resource intensive but at sensitive cases (eg when
>     > interacting with Glass) it does check that you run on the
>     correct thread.
>
>
>     The update process for updating my API objects is slow(for reasons
>     beyond my control), so even assuming I somehow manage to magically
>     update everything in the GUI thread, how the hell do you fix the GUI
>     stuttering at that point?
>
>
>     Really, having an entire application do all of it's processing on one
>     thread in 2018 is really just idiotic and asking for trouble.
>
>
>     >
>     > Even though your TableView, ... updates seem to work you can run
>     into
>     > disasterous states - see eg
>     https://bugs.openjdk.java.net/browse/JDK-8198577
>     >
>     > Tom
>
>
>     I'm not sure what the bug is about since the description really
>     doesn't
>     give much info however I really haven't noticed anything, even
>     long term
>     with it being open for 8+ hours. These objects are update very
>     frequently as well.
>
>
>     To be clear, this isn't some business application that gets info
>     from a
>     database or something.
>
>
>     > On 10.11.18 06:58, Ty Young wrote:
>     >> Hi,
>     >>
>     >>
>     >> My JavaFX program updates API objects in the background via a
>     non FX
>     >> thread that, when changed by another program, are reflected in
>     my JavaFX
>     >> GUI's controls by property binding, specifically TableView, Slider,
>     >> TextField, and ComboBox. Problem is, while JavaFX is OK with
>     this for
>     >> TableView, Slider, and TextField, it throws a Not on FX application
>     >> thread exception *only* for the ComboBox.
>     >>
>     >>
>     >> The code for the slider looks like this:
>     >>
>     >>? ??? private class ValueListener implements ChangeListener<Integer>
>     >>? ??? {
>     >>? ??????? @Override
>     >>? ??????? public void changed(ObservableValue<? extends Integer>
>     >> observable, Integer oldValue, Integer newValue)
>     >>? ??????? {
>     >>? ??????????? slider.getSlider().setValue(newValue);
>     >> slider.getTextBox().setText(newValue.toString());
>     >>? ??????? }
>     >>? ??? }
>     >>
>     >>
>     >> (the slider variable is misleading, it's actually a VBox that
>     contains a
>     >> Slider and a TextField. Need to change it but I digress.)
>     >>
>     >>
>     >> which works fine. However this:
>     >>
>     >>
>     >>? ??? private class ValueListener implements ChangeListener<E>
>     >>? ??? {
>     >>? ??????? @Override
>     >>? ??????? public void changed(ObservableValue<? extends E>
>     observable, E
>     >> oldValue, E newValue)
>     >>? ??????? {
>     >>? ??????????? combo.setValue(newValue);
>     >>? ??????? }
>     >>? ??? }
>     >>
>     >>
>     >> doesn't for the ComboBox.
>     >>
>     >>
>     >> Is this a bug or is there some legitimate invisible reason as
>     to why the
>     >> slider/textfield isn't throwing an error but the combobox one is?
>     >>
>     >>
>     >>
>

From tom.schindl at bestsolution.at  Tue Nov 13 06:12:00 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Tue, 13 Nov 2018 07:12:00 +0100
Subject: Bug: Not on FX application thread exception is inconsistent
In-Reply-To: <e9c7f96d-084a-5ef9-ff5a-d7ef248983d0@gmail.com>
References: <6a66d5d7-b81e-0fec-837e-0fd27a3c1684@gmail.com>
 <5863a15b-2177-b9a0-4719-ab3cbf1d1a74@bestsolution.at>
 <e6c6c2a8-c6e5-d7af-c59e-7d834994ce3c@gmail.com>
 <CAJo47rVOFgneWECdqyZnj=7jbxZwZiA2Oz5K3fhoS=10DZc9-w@mail.gmail.com>
 <e9c7f96d-084a-5ef9-ff5a-d7ef248983d0@gmail.com>
Message-ID: <7c3f5190-62ef-ee43-53db-6cf86e485d98@bestsolution.at>

I'm sorry that I'm the one to bring you the bad news that you need to do
the work and can't offload multi-threading to JavaFX.

I already explain why it *seems* to work one some elements (until it
breaks like shown in the bug-report I referenced) and for others it
breaks immediately because they somehow call out to native APIs (like
win32, ...) and hence are guarded with checks.

I can simply say it won't work and it won't change (well I'm not the one
in charge of such a decision but I frankly can't believe it will). You
are the one supposed to deal with this like you have to deal with that
in Swing, Qt, WPF, Win32-API, Cocoa-API, Gtk, ... - you need to sync
yourself back to the UI-Thread if you want to access resources.

You are right. If there are many updates from the backend-system you
would queue a lot of Runnables using Platform.runLater() who can get you
in trouble.

There are others ways to sync back to the JavaFX UI-Thread but
Platform.runLater() is the simplest with the least amount of work and
until you run into problems you should stick to that.

This is my last reply in this thread, as there's nothing more to say on
this topic from my side, there are many resources out there discussing
Platform.runLater and friends but that's something you can (and could
have) googled for and anyways looks like you don't want to listen.

Tom

On 13.11.18 05:38, Ty Young wrote:
> 
> On 11/12/18 9:12 PM, Brian Hudson wrote:
>> JavaFX like every other modern UI framework is single threaded.
> 
> 
> Which in itself is fine, running *just* the UI isn't much on modern
> processors. Adding a bunch of API object updates that cause thread
> slowdown to the mix that can cause UI stuttering is, again, asking for
> trouble.
> 
> 
> And how is TableView, Slider, TextField, etc all working just fine but
> ComboBox freaks out? What's so special about ComboBox? Is there some
> hack I can do to not trigger the exception?
> 
> 
>>
>> The updating of your ?API objects? can and should remain on a
>> background thread, however once updated the changes which trigger an
>> update to your UI (changing a value in a bound property) should occur
>> on the JavaFX thread via Platform.runLater for example.
>>
> 
> Doing all this is just messy, inefficient, and duplicating code. It
> would involve creating Runnable implementations that does about 10 lines
> of code with objects that get updated as fast as they can be with
> different object types, resulting in more threads and garbage being
> created. Using generic magic isn't really a solution either because
> different API objects convert data from String to some other type
> depending on the implementation.
> 
> 
> Would it not be possible to have a runPlatformListener method that just
> runs the ChangeListener on the platform thread automatically? It would
> reduce the amount of garbage dramatically since JavaFX only ever fires a
> change event if the object is itself different(in other words, if the
> current value is 0 and the new value is 0, there is no change) which is
> nice and efficient.
> 
> 
>> Also, take the attitude down a notch or two.
>>
>> Brian
>>
>>
>> On Mon, Nov 12, 2018 at 10:02 PM Ty Young <youngty1997 at gmail.com
>> <mailto:youngty1997 at gmail.com>> wrote:
>>
>>
>> ??? On 11/12/18 5:39 PM, Tom Schindl wrote:
>> ??? > Hi,
>> ??? >
>> ??? > You are supposed to interact with Nodes who are currently shown
>> ??? in the
>> ??? > SG only only the JavaFX Application Thread.
>>
>>
>> ??? I never touch the GUI in my other threads, ever. The threads simply
>> ??? change the value of a type stored in a property. The
>> ??? ChangeListener that
>> ??? is used is created in the GUI JavaFX thread.
>>
>>
>> ??? >
>> ??? > JavaFX although is not checking each and every property (change)
>> ??? as this
>> ??? > would be too resource intensive but at sensitive cases (eg when
>> ??? > interacting with Glass) it does check that you run on the
>> ??? correct thread.
>>
>>
>> ??? The update process for updating my API objects is slow(for reasons
>> ??? beyond my control), so even assuming I somehow manage to magically
>> ??? update everything in the GUI thread, how the hell do you fix the GUI
>> ??? stuttering at that point?
>>
>>
>> ??? Really, having an entire application do all of it's processing on one
>> ??? thread in 2018 is really just idiotic and asking for trouble.
>>
>>
>> ??? >
>> ??? > Even though your TableView, ... updates seem to work you can run
>> ??? into
>> ??? > disasterous states - see eg
>> ??? https://bugs.openjdk.java.net/browse/JDK-8198577
>> ??? >
>> ??? > Tom
>>
>>
>> ??? I'm not sure what the bug is about since the description really
>> ??? doesn't
>> ??? give much info however I really haven't noticed anything, even
>> ??? long term
>> ??? with it being open for 8+ hours. These objects are update very
>> ??? frequently as well.
>>
>>
>> ??? To be clear, this isn't some business application that gets info
>> ??? from a
>> ??? database or something.
>>
>>
>> ??? > On 10.11.18 06:58, Ty Young wrote:
>> ??? >> Hi,
>> ??? >>
>> ??? >>
>> ??? >> My JavaFX program updates API objects in the background via a
>> ??? non FX
>> ??? >> thread that, when changed by another program, are reflected in
>> ??? my JavaFX
>> ??? >> GUI's controls by property binding, specifically TableView,
>> Slider,
>> ??? >> TextField, and ComboBox. Problem is, while JavaFX is OK with
>> ??? this for
>> ??? >> TableView, Slider, and TextField, it throws a Not on FX
>> application
>> ??? >> thread exception *only* for the ComboBox.
>> ??? >>
>> ??? >>
>> ??? >> The code for the slider looks like this:
>> ??? >>
>> ??? >>? ??? private class ValueListener implements
>> ChangeListener<Integer>
>> ??? >>? ??? {
>> ??? >>? ??????? @Override
>> ??? >>? ??????? public void changed(ObservableValue<? extends Integer>
>> ??? >> observable, Integer oldValue, Integer newValue)
>> ??? >>? ??????? {
>> ??? >>? ??????????? slider.getSlider().setValue(newValue);
>> ??? >> slider.getTextBox().setText(newValue.toString());
>> ??? >>? ??????? }
>> ??? >>? ??? }
>> ??? >>
>> ??? >>
>> ??? >> (the slider variable is misleading, it's actually a VBox that
>> ??? contains a
>> ??? >> Slider and a TextField. Need to change it but I digress.)
>> ??? >>
>> ??? >>
>> ??? >> which works fine. However this:
>> ??? >>
>> ??? >>
>> ??? >>? ??? private class ValueListener implements ChangeListener<E>
>> ??? >>? ??? {
>> ??? >>? ??????? @Override
>> ??? >>? ??????? public void changed(ObservableValue<? extends E>
>> ??? observable, E
>> ??? >> oldValue, E newValue)
>> ??? >>? ??????? {
>> ??? >>? ??????????? combo.setValue(newValue);
>> ??? >>? ??????? }
>> ??? >>? ??? }
>> ??? >>
>> ??? >>
>> ??? >> doesn't for the ComboBox.
>> ??? >>
>> ??? >>
>> ??? >> Is this a bug or is there some legitimate invisible reason as
>> ??? to why the
>> ??? >> slider/textfield isn't throwing an error but the combobox one is?
>> ??? >>
>> ??? >>
>> ??? >>
>>

-- 
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  Tue Nov 13 06:17:18 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Tue, 13 Nov 2018 07:17:18 +0100
Subject: Bug: Not on FX application thread exception is inconsistent
In-Reply-To: <e6c6c2a8-c6e5-d7af-c59e-7d834994ce3c@gmail.com>
References: <6a66d5d7-b81e-0fec-837e-0fd27a3c1684@gmail.com>
 <5863a15b-2177-b9a0-4719-ab3cbf1d1a74@bestsolution.at>
 <e6c6c2a8-c6e5-d7af-c59e-7d834994ce3c@gmail.com>
Message-ID: <0abca3d2-1d2f-60cc-c9cc-6f1d0cead1f7@bestsolution.at>

On 13.11.18 04:00, Ty Young wrote:
> 
> On 11/12/18 5:39 PM, Tom Schindl wrote:
>> Hi,
>>
>> You are supposed to interact with Nodes who are currently shown in the
>> SG only only the JavaFX Application Thread.
> 
> 
> I never touch the GUI in my other threads, ever. The threads simply
> change the value of a type stored in a property. The ChangeListener that
> is used is created in the GUI JavaFX thread.
> 

It does not matter on which thread you create a ChangeListener the
important thing is on Thread causes the change-listener to trigger.
*None* of the JavaFX code-structures (Property, ObservableList) are
multi-thread-safe you accessing them from multiple threads at the same
time is asking for trouble.

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 Thimo.von.Rauchhaupt at empic.de  Tue Nov 13 07:38:45 2018
From: Thimo.von.Rauchhaupt at empic.de (Thimo von Rauchhaupt)
Date: Tue, 13 Nov 2018 07:38:45 +0000
Subject: Classes seem to be too restrictive 
Message-ID: <87e044f08c554d538824f93bd638f74d@erlmx01.heitec.net>

Hello,

As a feedback, I'd like to post my experience in upgrading our software from java 8 (Oracle JDK) to java 11 ( OpenJDK / OpenJFX).
Many classes where moved from private packages to javafx packages, but there are still some classes, which are too restrictive.
Either they are in some private packages or they have package-protected access on important methods / fields.

For instance :

*         it is imposible to write an own ResizePolicy for tables, as the method TableColumn.doSetWidth() is package-private. I do see the fear that someone would use this method falsely, but IMHO protected would be a better variant to gain access for overridden classes.

*         we needed to call updateDisplayNode() / updateDisplayArea() in ComboBoxPopupControl because we developed some special skins.

*         you cannot access the behavior, nor is it impossible to override them property ass

To implement some features, we had to write own helper classes in javafx packages, to gain accessibility to the package private methods. This is not the perfect way, but as long as we do not use the module support we can have package-splits.

Best regards
Thimo




------------------------------------------------------------------------------
IMPORTANT NOTICE / WICHTIGER HINWEIS
This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any distribution, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error please notify us immediately by email or by telephone and then delete this email and any copies of it.
Diese E-Mail koennte vertrauliche und/oder rechtlich geschuetzte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet.
------------------------------------------------------------------------------

From samir.hadzic.pro at gmail.com  Tue Nov 13 09:13:12 2018
From: samir.hadzic.pro at gmail.com (Sam')
Date: Tue, 13 Nov 2018 10:13:12 +0100
Subject: Review request for JDK-8213541
Message-ID: <CAL3niDGV-grM1KyBuS4YXmsa229LS_zpk+-O7W8p8C-_hWgH0g@mail.gmail.com>

If anyone wants to review my PR for
https://bugs.openjdk.java.net/browse/JDK-8213541 , it would be valuable.

PR can be seen here : https://github.com/javafxports/openjdk-jfx/pull/281

From nlisker at gmail.com  Tue Nov 13 10:12:06 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 13 Nov 2018 12:12:06 +0200
Subject: Classes seem to be too restrictive
In-Reply-To: <87e044f08c554d538824f93bd638f74d@erlmx01.heitec.net>
References: <87e044f08c554d538824f93bd638f74d@erlmx01.heitec.net>
Message-ID: <CA+0ynh9waPo4OtMCsavjY=s_HC3qtqKdgOhJ2WeVJmmmvd4=kA@mail.gmail.com>

Hi,

it is imposible to write an own ResizePolicy for tables


Is TableView#setColumnResizePolicy not good enough?

 [1]
https://openjfx.io/javadoc/11/javafx.controls/javafx/scene/control/TableView.html#setColumnResizePolicy(javafx.util.Callback)

- Nir

On Tue, Nov 13, 2018 at 10:32 AM Thimo von Rauchhaupt <
Thimo.von.Rauchhaupt at empic.de> wrote:

> Hello,
>
> As a feedback, I'd like to post my experience in upgrading our software
> from java 8 (Oracle JDK) to java 11 ( OpenJDK / OpenJFX).
> Many classes where moved from private packages to javafx packages, but
> there are still some classes, which are too restrictive.
> Either they are in some private packages or they have package-protected
> access on important methods / fields.
>
> For instance :
>
> *         it is imposible to write an own ResizePolicy for tables, as the
> method TableColumn.doSetWidth() is package-private. I do see the fear that
> someone would use this method falsely, but IMHO protected would be a better
> variant to gain access for overridden classes.
>
> *         we needed to call updateDisplayNode() / updateDisplayArea() in
> ComboBoxPopupControl because we developed some special skins.
>
> *         you cannot access the behavior, nor is it impossible to override
> them property ass
>
> To implement some features, we had to write own helper classes in javafx
> packages, to gain accessibility to the package private methods. This is not
> the perfect way, but as long as we do not use the module support we can
> have package-splits.
>
> Best regards
> Thimo
>
>
>
>
>
> ------------------------------------------------------------------------------
> IMPORTANT NOTICE / WICHTIGER HINWEIS
> This communication contains information which is confidential and may also
> be privileged. It is for the exclusive use of the intended recipient(s). If
> you are not the intended recipient(s) please note that any distribution,
> copying or use of this communication or the information in it is strictly
> prohibited. If you have received this communication in error please notify
> us immediately by email or by telephone and then delete this email and any
> copies of it.
> Diese E-Mail koennte vertrauliche und/oder rechtlich geschuetzte
> Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder
> diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
> Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die
> unbefugte Weitergabe dieser Mail sind nicht gestattet.
>
> ------------------------------------------------------------------------------
>

From youngty1997 at gmail.com  Tue Nov 13 11:05:54 2018
From: youngty1997 at gmail.com (Ty Young)
Date: Tue, 13 Nov 2018 05:05:54 -0600
Subject: Bug: Not on FX application thread exception is inconsistent
In-Reply-To: <7c3f5190-62ef-ee43-53db-6cf86e485d98@bestsolution.at>
References: <6a66d5d7-b81e-0fec-837e-0fd27a3c1684@gmail.com>
 <5863a15b-2177-b9a0-4719-ab3cbf1d1a74@bestsolution.at>
 <e6c6c2a8-c6e5-d7af-c59e-7d834994ce3c@gmail.com>
 <CAJo47rVOFgneWECdqyZnj=7jbxZwZiA2Oz5K3fhoS=10DZc9-w@mail.gmail.com>
 <e9c7f96d-084a-5ef9-ff5a-d7ef248983d0@gmail.com>
 <7c3f5190-62ef-ee43-53db-6cf86e485d98@bestsolution.at>
Message-ID: <bef2482c-bac2-91a4-8186-4dfa0f75a6ba@gmail.com>


On 11/13/18 12:12 AM, Tom Schindl wrote:
> I'm sorry that I'm the one to bring you the bad news that you need to do
> the work and can't offload multi-threading to JavaFX.
>
> I already explain why it *seems* to work one some elements (until it
> breaks like shown in the bug-report I referenced) and for others it
> breaks immediately because they somehow call out to native APIs (like
> win32, ...) and hence are guarded with checks.
>
> I can simply say it won't work and it won't change (well I'm not the one
> in charge of such a decision but I frankly can't believe it will). You
> are the one supposed to deal with this like you have to deal with that
> in Swing, Qt, WPF, Win32-API, Cocoa-API, Gtk, ... - you need to sync
> yourself back to the UI-Thread if you want to access resources.
>
> You are right. If there are many updates from the backend-system you
> would queue a lot of Runnables using Platform.runLater() who can get you
> in trouble.
>
> There are others ways to sync back to the JavaFX UI-Thread but
> Platform.runLater() is the simplest with the least amount of work and
> until you run into problems you should stick to that.


Because everything is ran in different places and there is no built-in 
way to wait for the runnable to finish, some GUI code that notifies the 
user of an API object's change breaks because the object hasn't been 
updated yet.


>
> This is my last reply in this thread, as there's nothing more to say on
> this topic from my side, there are many resources out there discussing
> Platform.runLater and friends but that's something you can (and could
> have) googled for and anyways looks like you don't want to listen.


All Google turns up is Platform.runLater and Platform.runAndWait. 
Platform.runAndWait isn't even publicly usable unless I edit the source 
and make it public. I knew using Platform.runLater was going to cause 
problems which is why I really didn't want to use it to begin with.


This isn't me not doing my research, this is objectively JavaFX not 
providing the functionality that is necessary to do something rather 
trivial: update an API object and provide information from that API 
object right after it's updated to the user(without ChangeListener).


I understand that there may be very technical reasons for not making it 
public, however it is still *majorly* problematic that it doesn't exist. 
Not being able to tell when a runnable has finished executing(besides 
ChangeListeners) is a big deal.

>
> Tom




> On 13.11.18 05:38, Ty Young wrote:
>> On 11/12/18 9:12 PM, Brian Hudson wrote:
>>> JavaFX like every other modern UI framework is single threaded.
>>
>> Which in itself is fine, running *just* the UI isn't much on modern
>> processors. Adding a bunch of API object updates that cause thread
>> slowdown to the mix that can cause UI stuttering is, again, asking for
>> trouble.
>>
>>
>> And how is TableView, Slider, TextField, etc all working just fine but
>> ComboBox freaks out? What's so special about ComboBox? Is there some
>> hack I can do to not trigger the exception?
>>
>>
>>> The updating of your ?API objects? can and should remain on a
>>> background thread, however once updated the changes which trigger an
>>> update to your UI (changing a value in a bound property) should occur
>>> on the JavaFX thread via Platform.runLater for example.
>>>
>> Doing all this is just messy, inefficient, and duplicating code. It
>> would involve creating Runnable implementations that does about 10 lines
>> of code with objects that get updated as fast as they can be with
>> different object types, resulting in more threads and garbage being
>> created. Using generic magic isn't really a solution either because
>> different API objects convert data from String to some other type
>> depending on the implementation.
>>
>>
>> Would it not be possible to have a runPlatformListener method that just
>> runs the ChangeListener on the platform thread automatically? It would
>> reduce the amount of garbage dramatically since JavaFX only ever fires a
>> change event if the object is itself different(in other words, if the
>> current value is 0 and the new value is 0, there is no change) which is
>> nice and efficient.
>>
>>
>>> Also, take the attitude down a notch or two.
>>>
>>> Brian
>>>
>>>
>>> On Mon, Nov 12, 2018 at 10:02 PM Ty Young <youngty1997 at gmail.com
>>> <mailto:youngty1997 at gmail.com>> wrote:
>>>
>>>
>>>  ??? On 11/12/18 5:39 PM, Tom Schindl wrote:
>>>  ??? > Hi,
>>>  ??? >
>>>  ??? > You are supposed to interact with Nodes who are currently shown
>>>  ??? in the
>>>  ??? > SG only only the JavaFX Application Thread.
>>>
>>>
>>>  ??? I never touch the GUI in my other threads, ever. The threads simply
>>>  ??? change the value of a type stored in a property. The
>>>  ??? ChangeListener that
>>>  ??? is used is created in the GUI JavaFX thread.
>>>
>>>
>>>  ??? >
>>>  ??? > JavaFX although is not checking each and every property (change)
>>>  ??? as this
>>>  ??? > would be too resource intensive but at sensitive cases (eg when
>>>  ??? > interacting with Glass) it does check that you run on the
>>>  ??? correct thread.
>>>
>>>
>>>  ??? The update process for updating my API objects is slow(for reasons
>>>  ??? beyond my control), so even assuming I somehow manage to magically
>>>  ??? update everything in the GUI thread, how the hell do you fix the GUI
>>>  ??? stuttering at that point?
>>>
>>>
>>>  ??? Really, having an entire application do all of it's processing on one
>>>  ??? thread in 2018 is really just idiotic and asking for trouble.
>>>
>>>
>>>  ??? >
>>>  ??? > Even though your TableView, ... updates seem to work you can run
>>>  ??? into
>>>  ??? > disasterous states - see eg
>>>  ??? https://bugs.openjdk.java.net/browse/JDK-8198577
>>>  ??? >
>>>  ??? > Tom
>>>
>>>
>>>  ??? I'm not sure what the bug is about since the description really
>>>  ??? doesn't
>>>  ??? give much info however I really haven't noticed anything, even
>>>  ??? long term
>>>  ??? with it being open for 8+ hours. These objects are update very
>>>  ??? frequently as well.
>>>
>>>
>>>  ??? To be clear, this isn't some business application that gets info
>>>  ??? from a
>>>  ??? database or something.
>>>
>>>
>>>  ??? > On 10.11.18 06:58, Ty Young wrote:
>>>  ??? >> Hi,
>>>  ??? >>
>>>  ??? >>
>>>  ??? >> My JavaFX program updates API objects in the background via a
>>>  ??? non FX
>>>  ??? >> thread that, when changed by another program, are reflected in
>>>  ??? my JavaFX
>>>  ??? >> GUI's controls by property binding, specifically TableView,
>>> Slider,
>>>  ??? >> TextField, and ComboBox. Problem is, while JavaFX is OK with
>>>  ??? this for
>>>  ??? >> TableView, Slider, and TextField, it throws a Not on FX
>>> application
>>>  ??? >> thread exception *only* for the ComboBox.
>>>  ??? >>
>>>  ??? >>
>>>  ??? >> The code for the slider looks like this:
>>>  ??? >>
>>>  ??? >>? ??? private class ValueListener implements
>>> ChangeListener<Integer>
>>>  ??? >>? ??? {
>>>  ??? >>? ??????? @Override
>>>  ??? >>? ??????? public void changed(ObservableValue<? extends Integer>
>>>  ??? >> observable, Integer oldValue, Integer newValue)
>>>  ??? >>? ??????? {
>>>  ??? >>? ??????????? slider.getSlider().setValue(newValue);
>>>  ??? >> slider.getTextBox().setText(newValue.toString());
>>>  ??? >>? ??????? }
>>>  ??? >>? ??? }
>>>  ??? >>
>>>  ??? >>
>>>  ??? >> (the slider variable is misleading, it's actually a VBox that
>>>  ??? contains a
>>>  ??? >> Slider and a TextField. Need to change it but I digress.)
>>>  ??? >>
>>>  ??? >>
>>>  ??? >> which works fine. However this:
>>>  ??? >>
>>>  ??? >>
>>>  ??? >>? ??? private class ValueListener implements ChangeListener<E>
>>>  ??? >>? ??? {
>>>  ??? >>? ??????? @Override
>>>  ??? >>? ??????? public void changed(ObservableValue<? extends E>
>>>  ??? observable, E
>>>  ??? >> oldValue, E newValue)
>>>  ??? >>? ??????? {
>>>  ??? >>? ??????????? combo.setValue(newValue);
>>>  ??? >>? ??????? }
>>>  ??? >>? ??? }
>>>  ??? >>
>>>  ??? >>
>>>  ??? >> doesn't for the ComboBox.
>>>  ??? >>
>>>  ??? >>
>>>  ??? >> Is this a bug or is there some legitimate invisible reason as
>>>  ??? to why the
>>>  ??? >> slider/textfield isn't throwing an error but the combobox one is?
>>>  ??? >>
>>>  ??? >>
>>>  ??? >>
>>>

From neugens.limasoftware at gmail.com  Tue Nov 13 15:26:11 2018
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Tue, 13 Nov 2018 16:26:11 +0100
Subject: Bug: Not on FX application thread exception is inconsistent
In-Reply-To: <e9c7f96d-084a-5ef9-ff5a-d7ef248983d0@gmail.com>
References: <6a66d5d7-b81e-0fec-837e-0fd27a3c1684@gmail.com>
 <5863a15b-2177-b9a0-4719-ab3cbf1d1a74@bestsolution.at>
 <e6c6c2a8-c6e5-d7af-c59e-7d834994ce3c@gmail.com>
 <CAJo47rVOFgneWECdqyZnj=7jbxZwZiA2Oz5K3fhoS=10DZc9-w@mail.gmail.com>
 <e9c7f96d-084a-5ef9-ff5a-d7ef248983d0@gmail.com>
Message-ID: <CAGUMyaRr=KPZ_HpwRW74fPiFLPJ+ro+bAfdHNXThq7yOpXPzbw@mail.gmail.com>

Il giorno mar 13 nov 2018 alle ore 16:11 Ty Young
<youngty1997 at gmail.com> ha scritto:
>
>
> On 11/12/18 9:12 PM, Brian Hudson wrote:
> > JavaFX like every other modern UI framework is single threaded.
>
>
> Which in itself is fine, running *just* the UI isn't much on modern
> processors. Adding a bunch of API object updates that cause thread
> slowdown to the mix that can cause UI stuttering is, again, asking for
> trouble.

I think you're missing the key point of synchronising different
threads for different tasks. You can do all the processing of your
objects in any thread you want, but the moment they need to update UI
state, this needs to be piped into the UI thread.

>
> And how is TableView, Slider, TextField, etc all working just fine but
> ComboBox freaks out? What's so special about ComboBox? Is there some
> hack I can do to not trigger the exception?

Just luck.

I suggest you to study and learn about concurrent programming and read
some basic tutorials on graphical programming, the issues you are
encountering aren't anything new, most frameworks work the same way.

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From tbee at tbee.org  Tue Nov 13 16:06:43 2018
From: tbee at tbee.org (Tom Eugelink)
Date: Tue, 13 Nov 2018 17:06:43 +0100
Subject: Bug: Not on FX application thread exception is inconsistent
In-Reply-To: <CAGUMyaRr=KPZ_HpwRW74fPiFLPJ+ro+bAfdHNXThq7yOpXPzbw@mail.gmail.com>
References: <6a66d5d7-b81e-0fec-837e-0fd27a3c1684@gmail.com>
 <5863a15b-2177-b9a0-4719-ab3cbf1d1a74@bestsolution.at>
 <e6c6c2a8-c6e5-d7af-c59e-7d834994ce3c@gmail.com>
 <CAJo47rVOFgneWECdqyZnj=7jbxZwZiA2Oz5K3fhoS=10DZc9-w@mail.gmail.com>
 <e9c7f96d-084a-5ef9-ff5a-d7ef248983d0@gmail.com>
 <CAGUMyaRr=KPZ_HpwRW74fPiFLPJ+ro+bAfdHNXThq7yOpXPzbw@mail.gmail.com>
Message-ID: <bf1d4663-4a7b-c09d-6a26-3928fcb8a752@tbee.org>


> This isn't me not doing my research, this is objectively JavaFX not providing the functionality that is necessary to do something rather trivial: update an API object and provide information from that API object right after it's updated to the user(without ChangeListener).

You are not using the right tool for the job. Thread management is not the responsibility of the UI toolkit, all it does is require that you got your stuff in order and run its code on the appropriate thread. Platform.run and runAndWait are just entry points for doing that, not multithreading solutions. There are good libraries for asynchronous execution; just use CompletableFuture, RxJava or JDeffered. RxJava even has build in support for putting a task back onto the JavaFX UI thread: observeOn(JavaFxScheduler.platform()).



From arunprasad.rajkumar at oracle.com  Tue Nov 13 18:09:10 2018
From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar)
Date: Tue, 13 Nov 2018 23:39:10 +0530
Subject: [RFR][openjfx12] JDK-8211307: Add prefix to build tools paths
Message-ID: <A6D9BF32-0094-4163-AA72-C76A4195D371@oracle.com>

Hi,

Please review the following Github PR,

https://github.com/javafxports/openjdk-jfx/pull/283

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

Thanks,
Arun

From nakajima.akira at nttcom.co.jp  Wed Nov 14 01:50:40 2018
From: nakajima.akira at nttcom.co.jp (Nakajima Akira)
Date: Wed, 14 Nov 2018 10:50:40 +0900
Subject: Review request for JDK-8207839, JDK-8207932, JDK-8208076 (variation
 selector)
Message-ID: <301385bb-9649-e7ad-2186-84ee1db68b05@nttcom.co.jp>

Hi Kevin, Phil,

Please review the following Github PR.

JDK-8207839
https://github.com/javafxports/openjdk-jfx/pull/125
https://github.com/javafxports/openjdk-jfx/pull/125/files

JDK-8207932
https://github.com/javafxports/openjdk-jfx/pull/126
https://github.com/javafxports/openjdk-jfx/pull/126/commits/ea68aa71d94e370e739556df0afeea105b1d07cb

JDK-8208076
https://github.com/javafxports/openjdk-jfx/pull/137
https://github.com/javafxports/openjdk-jfx/pull/137/commits/4e882cc9810e63e5c2df89a935b5d7842c5df16f


Thanks,
Akira Nakajima

From cnewland at chrisnewland.com  Wed Nov 14 09:48:37 2018
From: cnewland at chrisnewland.com (Chris Newland)
Date: Wed, 14 Nov 2018 09:48:37 -0000
Subject: armv6hf build failing with multiple definition of `JNI_OnLoad'
Message-ID: <03c626769550a315a6956ee2b0f9b75a.squirrel@excalibur.xssl.net>

Hi all,

Despite all the cool new build stuff being done with OpenJFX I still get a
few queries about my nightly chriswhocodes.com OpenJFX8 builds for ARM
from the Pi community.

Someone recently noticed that my builds broke on Oct 26 2018.

I've posted a gist of the failure log here

https://gist.github.com/chriswhocodes/b48a0fa1349d52f6c68be9d4212391d8

and was wondering if anyone had any ideas what might have broken this?

Reproducible with a fresh clone of
http://hg.openjdk.java.net/openjfx/8u-dev/rt and crosslibs fetch.

Many thanks,

Chris


From kevin.rushforth at oracle.com  Wed Nov 14 11:20:27 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 14 Nov 2018 12:20:27 +0100
Subject: armv6hf build failing with multiple definition of `JNI_OnLoad'
In-Reply-To: <03c626769550a315a6956ee2b0f9b75a.squirrel@excalibur.xssl.net>
References: <03c626769550a315a6956ee2b0f9b75a.squirrel@excalibur.xssl.net>
Message-ID: <154b3996-18db-1111-5f08-42158c409ce6@oracle.com>

The main change that went in recently (On Oct 26) that would affect this 
is JDK-8212147 [1], the backport of GTK 3 to FX 8, which was pushed to 
8u-dev about 3 weeks ago.

Similar changes to those made in buildSrc/linux.gradle will likely be 
needed in buildSrc/armv6hf.gradle.

-- Kevin

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


On 11/14/2018 10:48 AM, Chris Newland wrote:
> Hi all,
>
> Despite all the cool new build stuff being done with OpenJFX I still get a
> few queries about my nightly chriswhocodes.com OpenJFX8 builds for ARM
> from the Pi community.
>
> Someone recently noticed that my builds broke on Oct 26 2018.
>
> I've posted a gist of the failure log here
>
> https://gist.github.com/chriswhocodes/b48a0fa1349d52f6c68be9d4212391d8
>
> and was wondering if anyone had any ideas what might have broken this?
>
> Reproducible with a fresh clone of
> http://hg.openjdk.java.net/openjfx/8u-dev/rt and crosslibs fetch.
>
> Many thanks,
>
> Chris
>


From kevin.rushforth at oracle.com  Wed Nov 14 12:03:48 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 14 Nov 2018 13:03:48 +0100
Subject: [12] RFR: JDK-8213837: FX samples cannot load media from
 download.java.net over http
Message-ID: <b1b18687-fc3c-432a-ffff-1f221735332e@oracle.com>

Please review the following fix:

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

This changes "http://download.java.net" to "https://download.java.net" 
in Ensemble8 and HelloMedia. Downloading via http has recently started 
to fail, so we need to use https instead.

-- Kevin


From cnewland at chrisnewland.com  Wed Nov 14 12:03:55 2018
From: cnewland at chrisnewland.com (Chris Newland)
Date: Wed, 14 Nov 2018 12:03:55 -0000
Subject: armv6hf build failing with multiple definition of `JNI_OnLoad'
In-Reply-To: <154b3996-18db-1111-5f08-42158c409ce6@oracle.com>
References: <03c626769550a315a6956ee2b0f9b75a.squirrel@excalibur.xssl.net>
 <154b3996-18db-1111-5f08-42158c409ce6@oracle.com>
Message-ID: <a69816666bb36ef89a82778afc850657.squirrel@excalibur.xssl.net>

Thanks Kevin,

I'll take a look and post a patch here if I can get it working before the
official fix.

Kind regards,

Chris

On Wed, November 14, 2018 11:20, Kevin Rushforth wrote:
> The main change that went in recently (On Oct 26) that would affect this
> is JDK-8212147 [1], the backport of GTK 3 to FX 8, which was pushed to
> 8u-dev about 3 weeks ago.
>
>
> Similar changes to those made in buildSrc/linux.gradle will likely be
> needed in buildSrc/armv6hf.gradle.
>
> -- Kevin
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8212147
>
>
>
> On 11/14/2018 10:48 AM, Chris Newland wrote:
>
>> Hi all,
>>
>>
>> Despite all the cool new build stuff being done with OpenJFX I still
>> get a few queries about my nightly chriswhocodes.com OpenJFX8 builds for
>> ARM
>> from the Pi community.
>>
>> Someone recently noticed that my builds broke on Oct 26 2018.
>>
>>
>> I've posted a gist of the failure log here
>>
>>
>> https://gist.github.com/chriswhocodes/b48a0fa1349d52f6c68be9d4212391d8
>>
>>
>> and was wondering if anyone had any ideas what might have broken this?
>>
>> Reproducible with a fresh clone of
>> http://hg.openjdk.java.net/openjfx/8u-dev/rt and crosslibs fetch.
>>
>>
>> Many thanks,
>>
>>
>> Chris
>>
>>
>
>



From elect86 at gmail.com  Fri Nov 16 22:38:11 2018
From: elect86 at gmail.com (Giuseppe Barbieri)
Date: Fri, 16 Nov 2018 23:38:11 +0100
Subject: Building on Ubuntu 18.10
Message-ID: <CAOTtYn5aBkDkTshrtP76iq4oEogXa1qeoSz1saq-mMSvjz0CsA@mail.gmail.com>

Hi,

after bleeding today trying to build it on Win 10 (
https://github.com/javafxports/openjdk-jfx/issues/288), I decided to try on
Ubuntu hoping for a more friendly iter

Luckily only a problem arises:

https://gist.github.com/elect86/47ab39ee346873fd9c84a745a137bf46

Removing `Werror` from `linux.gradle` solved the problem

Someone may want to work on those issue to easier the building process for
future users..


Now, I'd like to play a little with the graphics backends, especially the
ES2 one.

How can I be sure that OpenJFX uses that?

Also, are there any license issues if I try to modify the sources, trying
to accomodate some lwjgl interoperability, keeping everything public on
github?

What's the status of the OpenGLNode? Anybody looking forward to it? May we
work together?


Cheers,
Giuseppe

From tom.schindl at bestsolution.at  Fri Nov 16 23:25:07 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Sat, 17 Nov 2018 00:25:07 +0100
Subject: Building on Ubuntu 18.10
In-Reply-To: <CAOTtYn5aBkDkTshrtP76iq4oEogXa1qeoSz1saq-mMSvjz0CsA@mail.gmail.com>
References: <CAOTtYn5aBkDkTshrtP76iq4oEogXa1qeoSz1saq-mMSvjz0CsA@mail.gmail.com>
Message-ID: <24a6329d-d2be-24b3-e335-4b47c4f286a5@bestsolution.at>

Hi,

On Linux and OS-X it is chosen by default unless your
graphics-card/driver is black listed - only happens on Linux. On Windows
there's no OpenGL pipeline (see below) but just D3D. To integrate OpenGL
on win32 you need to do some extra work.

We (BestSolution.at together with some of our customers) are working on
Native-Surface-Support (OpenGL and D3D). We are not yet ready to share
it publicly.

Once we make our first draft implementation available we hope to receive
feedback from the OpenJFX community to improve and move it forward
together in OSS.

Tom

On 16.11.18 23:38, Giuseppe Barbieri wrote:
> Hi,
> 
> after bleeding today trying to build it on Win 10 (
> https://github.com/javafxports/openjdk-jfx/issues/288), I decided to try on
> Ubuntu hoping for a more friendly iter
> 
> Luckily only a problem arises:
> 
> https://gist.github.com/elect86/47ab39ee346873fd9c84a745a137bf46
> 
> Removing `Werror` from `linux.gradle` solved the problem
> 
> Someone may want to work on those issue to easier the building process for
> future users..
> 
> 
> Now, I'd like to play a little with the graphics backends, especially the
> ES2 one.
> 
> How can I be sure that OpenJFX uses that?
> 
> Also, are there any license issues if I try to modify the sources, trying
> to accomodate some lwjgl interoperability, keeping everything public on
> github?
> 
> What's the status of the OpenGLNode? Anybody looking forward to it? May we
> work together?
> 
> 
> Cheers,
> Giuseppe
> 

-- 
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  Sat Nov 17 13:40:43 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Sat, 17 Nov 2018 15:40:43 +0200
Subject: Bitwise puzzle in com.sun.glass.ui.monocle.Framebuffer
In-Reply-To: <6c09225e-7d49-8721-5560-96ef30206c6e@status6.com>
References: <6c09225e-7d49-8721-5560-96ef30206c6e@status6.com>
Message-ID: <CA+0ynh9gS+5gYT0ZhdG1CbYUwRAtOEUv5s3Ot4mM58LRM9KTPA@mail.gmail.com>

Hi John,

I agree with your math. I guess you could submit an enhancement request to
have it evaluated.

- Nir

On Mon, Nov 5, 2018 at 8:21 PM John Neffenger <john at status6.com> wrote:

> I am completely puzzled by the bitwise operations in the Framebuffer
> class (package com.sun.glass.ui.monocle). I'm overriding its methods to
> support a "Y8" 8-bit grayscale frame buffer, yet I have no idea why it's
> doing what it's doing. Can anyone shed light on its complexity?
>
> The Framebuffer class converts a buffer with 32-bit pixels in ARGB32
> format into a buffer with 16-bit pixels in RGB565 format, as illustrated
> below for one pixel.
>
> aaaa aaaa  rrrr rrrr  gggg gggg  bbbb bbbb
>      --> rrrr rggg  gggb bbbb
>
> I would convert the pixels with a method like the following:
>
> void copyNextPixel(IntBuffer source, ShortBuffer target) {
>      int pixel32 = source.get();
>      int r = (pixel32 >> 8) & 0xF800;
>      int g = (pixel32 >> 5) & 0x07E0;
>      int b = (pixel32 >> 3) & 0x001F;
>      int pixel16 = r | g | b;
>      target.put((short) pixel16);
> }
>
> The JavaFX Framebuffer class converts the pixels like this:
>
> void copyNextPixelOriginal(IntBuffer source, ShortBuffer target) {
>      int pixel32 = source.get();
>      int r = ((((pixel32 >> 19) & 31) * 539219) >> 8) & (31 << 11);
>      int g = ((((pixel32 >> 10) & 63) * 265395) >> 13) & (63 << 5);
>      int b = (((pixel32 >> 3) & 31) * 539219) >> 19;
>      int pixel16 = r | g | b;
>      target.put((short) pixel16);
> }
>
> Both of these methods produce identical results when tested against all
> 16,777,216 possible 24-bit RGB values. To understand what is happening,
> I show each step in the creation and positioning of the 5-bit red color
> value for both algorithms below (best viewed in a monospaced font).
>
> My version
>      int r = (pixel32 >> 8) & 0xF800;
>
> ____ ____  xxxx xxxx  ____ ____  ____ ____  pixel32 (x = red)
> ____ ____  ____ ____  xxxx xxxx  ____ ____  >> 8
> 0000 0000  0000 0000  xxxx x000  0000 0000  & 0xF800
>
> JavaFX version
>      int r = ((((pixel32 >> 19) & 31) * 539219) >> 8) & (31 << 11);
>
> ____ ____  xxxx xxxx  ____ ____  ____ ____  pixel32 (x = red)
> ____ ____  ____ ____  ____ ____  ___x xxxx  >> 19
> 0000 0000  0000 0000  0000 0000  000x xxxx  & 31 = 0x1F
> 0000 0000  xxxx x___  ____ ____  ____ ____  * 539219 = 2^19 + 14931
> 0000 0000  0000 0000  xxxx x___  ____ ____  >> 8
> 0000 0000  0000 0000  xxxx x000  0000 0000  & (31 << 11) = 0xF800
>
> Why all the back and forth? Why introduce varying bits to the right of
> the red color value (* 539219), only to clear those bits later? The last
> three steps could be replaced with a single logical shift left operation
> (<< 11).
>
> The Framebuffer class was added to the repository on January 21, 2014,
> by Daniel Blaukopf.
>
> Thank you,
> John
>
>

From fastegal at swingempire.de  Sun Nov 18 15:41:12 2018
From: fastegal at swingempire.de (fastegal at swingempire.de)
Date: Sun, 18 Nov 2018 16:41:12 +0100
Subject: Problem running tests in module controls inside Eclipse
Message-ID: <20181118164112.Horde.trc9tKvW0qYLLOeeq1BdqQ1@webmail.df.eu>


With the step-by-step debugging help provided by nlisker over at  
javafxports (https://github.com/javafxports/openjdk-jfx/issues/187 -  
which cleaned up some inherent misconception on my part, thanks!) I  
managed to run tests in base and graphics from inside Eclipse (right  
click and run as/unit test), but not in controls (complete stacktrace  
is at the end), barking with essentially:

Caused by: java.lang.IllegalStateException: Toolkit not initialized

Which is the usual complaint if the fx app thread is not yet started.  
For my own tests I have a class rule that fires it up, but how to  
start it for openjfx controls tests?

The complete stacktrace:

java.lang.ExceptionInInitializerError
	at  
javafx.controls/test.javafx.scene.control.TextAreaTest.setup(TextAreaTest.java:53)
	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  
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at  
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at  
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at  
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at  
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at  
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at  
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
	at  
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
	at  
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
	at  
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
	at  
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
	at  
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
Caused by: java.lang.IllegalStateException: Toolkit not initialized
	at  
javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:410)
	at  
javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:405)
	at  
javafx.graphics/com.sun.javafx.application.PlatformImpl.setPlatformUserAgentStylesheet(PlatformImpl.java:695)
	at  
javafx.graphics/com.sun.javafx.application.PlatformImpl.setDefaultPlatformUserAgentStylesheet(PlatformImpl.java:657)
	at javafx.controls/javafx.scene.control.Control.<clinit>(Control.java:99)



From nlisker at gmail.com  Sun Nov 18 16:00:40 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 18 Nov 2018 18:00:40 +0200
Subject: Problem running tests in module controls inside Eclipse
In-Reply-To: <20181118164112.Horde.trc9tKvW0qYLLOeeq1BdqQ1@webmail.df.eu>
References: <20181118164112.Horde.trc9tKvW0qYLLOeeq1BdqQ1@webmail.df.eu>
Message-ID: <CA+0ynh_GEMU3wHf-kharFpWL_aRh+5B-hdEhB_1WTGvwTyDd3w@mail.gmail.com>

I don't recall seeing this problem. Just to be sure, did you circumvent the
compilation error in Dialog's lambda?

On Sun, Nov 18, 2018 at 5:42 PM <fastegal at swingempire.de> wrote:

>
> With the step-by-step debugging help provided by nlisker over at
> javafxports (https://github.com/javafxports/openjdk-jfx/issues/187 -
> which cleaned up some inherent misconception on my part, thanks!) I
> managed to run tests in base and graphics from inside Eclipse (right
> click and run as/unit test), but not in controls (complete stacktrace
> is at the end), barking with essentially:
>
> Caused by: java.lang.IllegalStateException: Toolkit not initialized
>
> Which is the usual complaint if the fx app thread is not yet started.
> For my own tests I have a class rule that fires it up, but how to
> start it for openjfx controls tests?
>
> The complete stacktrace:
>
> java.lang.ExceptionInInitializerError
>         at
>
> javafx.controls/test.javafx.scene.control.TextAreaTest.setup(TextAreaTest.java:53)
>         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
>
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>         at
>
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>         at
>
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>         at
>
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>         at
>
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>         at
>
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>         at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>         at
>
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
>         at
>
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
>         at
>
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
>         at
>
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
>         at
>
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
>         at
>
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
> Caused by: java.lang.IllegalStateException: Toolkit not initialized
>         at
>
> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:410)
>         at
>
> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:405)
>         at
>
> javafx.graphics/com.sun.javafx.application.PlatformImpl.setPlatformUserAgentStylesheet(PlatformImpl.java:695)
>         at
>
> javafx.graphics/com.sun.javafx.application.PlatformImpl.setDefaultPlatformUserAgentStylesheet(PlatformImpl.java:657)
>         at
> javafx.controls/javafx.scene.control.Control.<clinit>(Control.java:99)
>
>
>

From fastegal at swingempire.de  Sun Nov 18 16:09:25 2018
From: fastegal at swingempire.de (fastegal at swingempire.de)
Date: Sun, 18 Nov 2018 17:09:25 +0100
Subject: Problem running tests in module controls inside Eclipse
In-Reply-To: <CA+0ynh_GEMU3wHf-kharFpWL_aRh+5B-hdEhB_1WTGvwTyDd3w@mail.gmail.com>
References: <20181118164112.Horde.trc9tKvW0qYLLOeeq1BdqQ1@webmail.df.eu>
 <CA+0ynh_GEMU3wHf-kharFpWL_aRh+5B-hdEhB_1WTGvwTyDd3w@mail.gmail.com>
Message-ID: <20181118170925.Horde.ZSExlvzT2KJiCZN5lIUweg9@webmail.df.eu>


Zitat von Nir Lisker <nlisker at gmail.com>:

> I don't recall seeing this problem. Just to be sure, did you circumvent the
> compilation error in Dialog's lambda?
>

yes, I did - not seeing any compile errors, nothing red but just the  
app thread doesn't seem to be fired up.

> On Sun, Nov 18, 2018 at 5:42 PM <fastegal at swingempire.de> wrote:
>
>>
>> With the step-by-step debugging help provided by nlisker over at
>> javafxports (https://github.com/javafxports/openjdk-jfx/issues/187 -
>> which cleaned up some inherent misconception on my part, thanks!) I
>> managed to run tests in base and graphics from inside Eclipse (right
>> click and run as/unit test), but not in controls (complete stacktrace
>> is at the end), barking with essentially:
>>
>> Caused by: java.lang.IllegalStateException: Toolkit not initialized
>>
>> Which is the usual complaint if the fx app thread is not yet started.
>> For my own tests I have a class rule that fires it up, but how to
>> start it for openjfx controls tests?
>>
>> The complete stacktrace:
>>
>> java.lang.ExceptionInInitializerError
>>         at
>>
>> javafx.controls/test.javafx.scene.control.TextAreaTest.setup(TextAreaTest.java:53)
>>         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
>>
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>>         at
>>
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>>         at
>>
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>>         at
>>
>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>         at
>>
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>         at
>>
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>         at
>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>         at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>         at
>>
>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
>> Caused by: java.lang.IllegalStateException: Toolkit not initialized
>>         at
>>
>> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:410)
>>         at
>>
>> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:405)
>>         at
>>
>> javafx.graphics/com.sun.javafx.application.PlatformImpl.setPlatformUserAgentStylesheet(PlatformImpl.java:695)
>>         at
>>
>> javafx.graphics/com.sun.javafx.application.PlatformImpl.setDefaultPlatformUserAgentStylesheet(PlatformImpl.java:657)
>>         at
>> javafx.controls/javafx.scene.control.Control.<clinit>(Control.java:99)
>>
>>
>>




From tom.schindl at bestsolution.at  Sun Nov 18 16:12:00 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Sun, 18 Nov 2018 17:12:00 +0100
Subject: Problem running tests in module controls inside Eclipse
In-Reply-To: <CA+0ynh_GEMU3wHf-kharFpWL_aRh+5B-hdEhB_1WTGvwTyDd3w@mail.gmail.com>
References: <20181118164112.Horde.trc9tKvW0qYLLOeeq1BdqQ1@webmail.df.eu>
 <CA+0ynh_GEMU3wHf-kharFpWL_aRh+5B-hdEhB_1WTGvwTyDd3w@mail.gmail.com>
Message-ID: <dadbc0ac-7386-2531-3145-1d591e1e369f@bestsolution.at>

i run them with

-Djava.library.path=/Users/tomschindl/OpenJFX/openjdk-jfx/build/sdk/lib
-Djavafx.toolkit=test.com.sun.javafx.pgstub.StubToolkit

Tom

On 18.11.18 17:00, Nir Lisker wrote:
> I don't recall seeing this problem. Just to be sure, did you circumvent the
> compilation error in Dialog's lambda?
> 
> On Sun, Nov 18, 2018 at 5:42 PM <fastegal at swingempire.de> wrote:
> 
>>
>> With the step-by-step debugging help provided by nlisker over at
>> javafxports (https://github.com/javafxports/openjdk-jfx/issues/187 -
>> which cleaned up some inherent misconception on my part, thanks!) I
>> managed to run tests in base and graphics from inside Eclipse (right
>> click and run as/unit test), but not in controls (complete stacktrace
>> is at the end), barking with essentially:
>>
>> Caused by: java.lang.IllegalStateException: Toolkit not initialized
>>
>> Which is the usual complaint if the fx app thread is not yet started.
>> For my own tests I have a class rule that fires it up, but how to
>> start it for openjfx controls tests?
>>
>> The complete stacktrace:
>>
>> java.lang.ExceptionInInitializerError
>>         at
>>
>> javafx.controls/test.javafx.scene.control.TextAreaTest.setup(TextAreaTest.java:53)
>>         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
>>
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>>         at
>>
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>>         at
>>
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>>         at
>>
>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>         at
>>
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>         at
>>
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>         at
>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>         at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>         at
>>
>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
>> Caused by: java.lang.IllegalStateException: Toolkit not initialized
>>         at
>>
>> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:410)
>>         at
>>
>> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:405)
>>         at
>>
>> javafx.graphics/com.sun.javafx.application.PlatformImpl.setPlatformUserAgentStylesheet(PlatformImpl.java:695)
>>         at
>>
>> javafx.graphics/com.sun.javafx.application.PlatformImpl.setDefaultPlatformUserAgentStylesheet(PlatformImpl.java:657)
>>         at
>> javafx.controls/javafx.scene.control.Control.<clinit>(Control.java:99)
>>
>>
>>

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

From fastegal at swingempire.de  Sun Nov 18 16:33:53 2018
From: fastegal at swingempire.de (fastegal at swingempire.de)
Date: Sun, 18 Nov 2018 17:33:53 +0100
Subject: Problem running tests in module controls inside Eclipse
In-Reply-To: <CA+0ynh_GEMU3wHf-kharFpWL_aRh+5B-hdEhB_1WTGvwTyDd3w@mail.gmail.com>
References: <20181118164112.Horde.trc9tKvW0qYLLOeeq1BdqQ1@webmail.df.eu>
 <CA+0ynh_GEMU3wHf-kharFpWL_aRh+5B-hdEhB_1WTGvwTyDd3w@mail.gmail.com>
Message-ID: <20181118173353.Horde.ygrRQmdtwrIYjuoRVB4l2Q1@webmail.df.eu>


okay, found something in the gradle tasks which point into direction  
of some success: it sets the stubtoolkit in a vm arg:

-Djavafx.toolkit=test.com.sun.javafx.pgstub.StubToolkit

which does indeed work inside Eclipse if I add it to the runtime  
config of the test. Next step would be to set it globally somehow -  
adding in an arg file doesn't seem to work ... hmm ... probably  
something wrong with the exact format.

I have an arg file that sets the java.library path, named openjfx-args:

-Djava.library.path=C:\Daten\data-for-work\eclipse\gitrep-openjdk\openjdk-jfx-fork\modules\javafx.graphics\build\module-lib

if I add the toolkit param, it isn't taken:

-Djava.library.path=C:\Daten\data-for-work\eclipse\gitrep-openjdk\openjdk-jfx-fork\modules\javafx.graphics\build\module-lib
-Djavafx.toolkit=test.com.sun.javafx.pgstub.StubToolkit

if I add it to the vm args of the jdk runtime environment (installed  
jres - open-11) all is fine:

vm args:
@openjfx-args -Djavafx.toolkit=test.com.sun.javafx.pgstub.StubToolkit

now all boils down to how to add two (or more) system properties to  
the arg file? darn ... back to roots ;)

Zitat von Nir Lisker <nlisker at gmail.com>:

> I don't recall seeing this problem. Just to be sure, did you circumvent the
> compilation error in Dialog's lambda?
>
> On Sun, Nov 18, 2018 at 5:42 PM <fastegal at swingempire.de> wrote:
>
>>
>> With the step-by-step debugging help provided by nlisker over at
>> javafxports (https://github.com/javafxports/openjdk-jfx/issues/187 -
>> which cleaned up some inherent misconception on my part, thanks!) I
>> managed to run tests in base and graphics from inside Eclipse (right
>> click and run as/unit test), but not in controls (complete stacktrace
>> is at the end), barking with essentially:
>>
>> Caused by: java.lang.IllegalStateException: Toolkit not initialized
>>
>> Which is the usual complaint if the fx app thread is not yet started.
>> For my own tests I have a class rule that fires it up, but how to
>> start it for openjfx controls tests?
>>
>> The complete stacktrace:
>>
>> java.lang.ExceptionInInitializerError
>>         at
>>
>> javafx.controls/test.javafx.scene.control.TextAreaTest.setup(TextAreaTest.java:53)
>>         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
>>
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>>         at
>>
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>>         at
>>
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>>         at
>>
>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>         at
>>
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>         at
>>
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>         at
>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>         at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>         at
>>
>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
>>         at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
>> Caused by: java.lang.IllegalStateException: Toolkit not initialized
>>         at
>>
>> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:410)
>>         at
>>
>> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:405)
>>         at
>>
>> javafx.graphics/com.sun.javafx.application.PlatformImpl.setPlatformUserAgentStylesheet(PlatformImpl.java:695)
>>         at
>>
>> javafx.graphics/com.sun.javafx.application.PlatformImpl.setDefaultPlatformUserAgentStylesheet(PlatformImpl.java:657)
>>         at
>> javafx.controls/javafx.scene.control.Control.<clinit>(Control.java:99)
>>
>>
>>




From fastegal at swingempire.de  Sun Nov 18 16:48:53 2018
From: fastegal at swingempire.de (fastegal at swingempire.de)
Date: Sun, 18 Nov 2018 17:48:53 +0100
Subject: Problem running tests in module controls inside Eclipse
In-Reply-To: <dadbc0ac-7386-2531-3145-1d591e1e369f@bestsolution.at>
References: <20181118164112.Horde.trc9tKvW0qYLLOeeq1BdqQ1@webmail.df.eu>
 <CA+0ynh_GEMU3wHf-kharFpWL_aRh+5B-hdEhB_1WTGvwTyDd3w@mail.gmail.com>
 <dadbc0ac-7386-2531-3145-1d591e1e369f@bestsolution.at>
Message-ID: <20181118174853.Horde.2vIeVwoUnIStLSXltaHOXw4@webmail.df.eu>


arrrggg .. head on desktop edited the arg-file of base project, not  
that of the controls ... now it's time to call it a day, tsssee

thanks for your help! and have a nice evening everybody :)

Zitat von Tom Schindl <tom.schindl at bestsolution.at>:

> i run them with
>
> -Djava.library.path=/Users/tomschindl/OpenJFX/openjdk-jfx/build/sdk/lib
> -Djavafx.toolkit=test.com.sun.javafx.pgstub.StubToolkit
>
> Tom
>
> On 18.11.18 17:00, Nir Lisker wrote:
>> I don't recall seeing this problem. Just to be sure, did you circumvent the
>> compilation error in Dialog's lambda?
>>
>> On Sun, Nov 18, 2018 at 5:42 PM <fastegal at swingempire.de> wrote:
>>
>>>
>>> With the step-by-step debugging help provided by nlisker over at
>>> javafxports (https://github.com/javafxports/openjdk-jfx/issues/187 -
>>> which cleaned up some inherent misconception on my part, thanks!) I
>>> managed to run tests in base and graphics from inside Eclipse (right
>>> click and run as/unit test), but not in controls (complete stacktrace
>>> is at the end), barking with essentially:
>>>
>>> Caused by: java.lang.IllegalStateException: Toolkit not initialized
>>>
>>> Which is the usual complaint if the fx app thread is not yet started.
>>> For my own tests I have a class rule that fires it up, but how to
>>> start it for openjfx controls tests?
>>>
>>> The complete stacktrace:
>>>
>>> java.lang.ExceptionInInitializerError
>>>         at
>>>
>>> javafx.controls/test.javafx.scene.control.TextAreaTest.setup(TextAreaTest.java:53)
>>>         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
>>>
>>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>>>         at
>>>
>>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>>>         at
>>>
>>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>>>         at
>>>
>>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>>>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>>         at
>>>
>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>>         at
>>>
>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>>         at
>>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>>         at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>>         at
>>>
>>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
>>>         at
>>>
>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
>>>         at
>>>
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
>>>         at
>>>
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
>>>         at
>>>
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
>>>         at
>>>
>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
>>> Caused by: java.lang.IllegalStateException: Toolkit not initialized
>>>         at
>>>
>>> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:410)
>>>         at
>>>
>>> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:405)
>>>         at
>>>
>>> javafx.graphics/com.sun.javafx.application.PlatformImpl.setPlatformUserAgentStylesheet(PlatformImpl.java:695)
>>>         at
>>>
>>> javafx.graphics/com.sun.javafx.application.PlatformImpl.setDefaultPlatformUserAgentStylesheet(PlatformImpl.java:657)
>>>         at
>>> javafx.controls/javafx.scene.control.Control.<clinit>(Control.java:99)
>>>
>>>
>>>
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck




From michael.dever at icloud.com  Sun Nov 18 21:01:41 2018
From: michael.dever at icloud.com (Michael Dever)
Date: Sun, 18 Nov 2018 16:01:41 -0500
Subject: Netbeans X & Java 11?
Message-ID: <DA177A08-BF63-4ED1-8055-0D8BB9C49889@icloud.com>

Oracle seems to have Destroyed the combination of:
Netbeans, JavaFX, and SceneBuilder, building JavaFX from an IDE.

Is there any other IDE that supports and builds: JavaFX FXML Applications,
out of the box that just works, and that you can design the GUI application from SceneBuilder?


Thanks,
Mike Dever



From youngty1997 at gmail.com  Mon Nov 19 00:03:04 2018
From: youngty1997 at gmail.com (Ty Young)
Date: Sun, 18 Nov 2018 18:03:04 -0600
Subject: Netbeans X & Java 11?
In-Reply-To: <DA177A08-BF63-4ED1-8055-0D8BB9C49889@icloud.com>
References: <DA177A08-BF63-4ED1-8055-0D8BB9C49889@icloud.com>
Message-ID: <3729ee28-459e-4fca-6834-3bd7d87b05aa@gmail.com>


On 11/18/18 3:01 PM, Michael Dever wrote:
> Oracle seems to have Destroyed the combination of:
> Netbeans, JavaFX, and SceneBuilder, building JavaFX from an IDE.
>
> Is there any other IDE that supports and builds: JavaFX FXML Applications,
> out of the box that just works, and that you can design the GUI application from SceneBuilder?
>
>
> Thanks,
> Mike Dever
>
>

Hi Mike,


I'm assuming you're getting a missing JavaFX deployment error which is 
the only error I could get with Java 11/JavaFX11 JDK in Netbeans with 
FXML and non modular application in Linux. As result of Oracle's 
careless deprecation and removal rampage, none of the non modular JavaFX 
applications in Netbeans(even 9!) work regardless of whether your JavaFX 
application is FXML or Java(which is all of templates/samples, by the 
by). I've brought this up before on this mailing list before in a bit of 
a rant and no one seemed to care to acknowledge that it was even an 
issue. There is some effort to make a replacement however it's being 
spearheaded by a company other than Oracle(abd IIRC is fit for primarily 
their needs. I couldn't get it to work for my jLink app) and who know 
when or if at all it will be integrated into JavaFX and Netbeans.


You can work around this by moving to a modular application. Sadly, 
Netbeans 9 does not provide any easy way to convert projects to the 
modular structure. Fortunately the process for converting it by hand is 
fairly easy for simple small projects:

1. Create a new modular application in Netbeans.

2. Copy <Project>/src/<name> to the modular applications 
<Project>/src/classes/

3. Fix module name in module-info and add exports.


This will break Git(or at least it did for me). Yes, it really sucks but 
this is what happens when companies abort useful tools/secondary 
features out of the blue like an unwanted child without warning, proper 
& complete replacement, or time for IDE developers to add features to 
help migrate users of these features gracefully. This corporate middle 
fingering "It's our way or the highway" attitude is only going to hurt 
Java as a whole as no one can depend on anything for any long period of 
time and what tools/secondary features are being supported for the time 
being don't have all the features or functionality that deprecated 
features do. To add icing to the cake, Netbeans was formerly developed 
by Oracle themselves. Ouch.


But now I'm just repeating myself and going off topic. Yeah, if it's a 
small project the above should work fine. You might even be able to 
automate it if you really need to.


Hope this helps.




From john at status6.com  Mon Nov 19 02:03:18 2018
From: john at status6.com (John Neffenger)
Date: Sun, 18 Nov 2018 18:03:18 -0800
Subject: Bitwise puzzle in com.sun.glass.ui.monocle.Framebuffer
In-Reply-To: <CA+0ynh9gS+5gYT0ZhdG1CbYUwRAtOEUv5s3Ot4mM58LRM9KTPA@mail.gmail.com>
References: <6c09225e-7d49-8721-5560-96ef30206c6e@status6.com>
 <CA+0ynh9gS+5gYT0ZhdG1CbYUwRAtOEUv5s3Ot4mM58LRM9KTPA@mail.gmail.com>
Message-ID: <1db3ba5b-0cee-7edc-8b27-34b47e2441be@status6.com>

On 11/17/18 5:40 AM, Nir Lisker wrote:
> I agree with your math. I guess you could submit an enhancement request 
> to have it evaluated.

Thank you for looking into it, Nir. I plan to include the simplified 
RGB565 conversion along with my Y8 grayscale support, as it's all done 
in the same two Framebuffer methods.

I'm still hoping to solve the puzzle, though. Maybe it was just meant to 
remain a mystery. :-)

John

From augustnagro at gmail.com  Mon Nov 19 03:53:01 2018
From: augustnagro at gmail.com (August Nagro)
Date: Sun, 18 Nov 2018 21:53:01 -0600
Subject: Javadocs Download
Message-ID: <CAHNb0ZMAtgamrYiLctOj2Kyog6fb4eRp-eX3cjcLpoFFDC-XfQ@mail.gmail.com>

Hello,

I can't seem to find a download for JavaFX's apidoc on the openjfx.io site.
Is there an alternate download link, or plans to add them on the downloads
page?

Regards,

August Nagro

From wowselim at gmail.com  Mon Nov 19 07:11:57 2018
From: wowselim at gmail.com (Selim Dincer)
Date: Mon, 19 Nov 2018 08:11:57 +0100
Subject: Netbeans X & Java 11?
In-Reply-To: <DA177A08-BF63-4ED1-8055-0D8BB9C49889@icloud.com>
References: <DA177A08-BF63-4ED1-8055-0D8BB9C49889@icloud.com>
Message-ID: <CANp2C1z6zVg7wTC3Uoh96pW_mHNqa_SJMNUiwfH_1rxtU2ovBg@mail.gmail.com>

Hi,

IntelliJ works quite OK with 11. Make sure to rightclick the fxml files ->
open in scenebuilder instead of the integrated one because that's an older
version. Also if you want to run your app without maven / gradle then you
need to download the javafx sdk and set JAVA_HOME otherwise you will get
some weird error. Also make sure to configure your run configuration
exactly like the recommended maven / gradle run configurations.
Apart from that the guide on the openjfx site (the gradle variant) kind of
worked for me.

This is why I suggested something like spring initializr or vert.x starter
before.

On Sun, 18 Nov 2018, 22:02 Michael Dever <michael.dever at icloud.com wrote:

> Oracle seems to have Destroyed the combination of:
> Netbeans, JavaFX, and SceneBuilder, building JavaFX from an IDE.
>
> Is there any other IDE that supports and builds: JavaFX FXML Applications,
> out of the box that just works, and that you can design the GUI
> application from SceneBuilder?
>
>
> Thanks,
> Mike Dever
>
>
>

From jose.pereda at gluonhq.com  Mon Nov 19 08:27:56 2018
From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=)
Date: Mon, 19 Nov 2018 09:27:56 +0100
Subject: Netbeans X & Java 11?
In-Reply-To: <CANp2C1z6zVg7wTC3Uoh96pW_mHNqa_SJMNUiwfH_1rxtU2ovBg@mail.gmail.com>
References: <DA177A08-BF63-4ED1-8055-0D8BB9C49889@icloud.com>
 <CANp2C1z6zVg7wTC3Uoh96pW_mHNqa_SJMNUiwfH_1rxtU2ovBg@mail.gmail.com>
Message-ID: <CAGMSBrJ8rY7L+b0oD8g2aNbfiLF+VMv4gUZ7VdPH4+UXd_nMPQ@mail.gmail.com>

Hi, Mike.

Did you check the docs? https://openjfx.io/openjfx-docs/

There is a whole section for IDEs, including NetBeans (
https://openjfx.io/openjfx-docs/#IDE-NetBeans), that explains how to work
with both modular and non-modular projects.

While you may have noticed that the usual JavaFX project template doesn't
work, you can use a regular Java project, instead (the ant tasks have not
been updated yet, but they are working on it).

There is a sample (a simple HelloFX that uses FXML) for each possible case
(modular/non-modular, each one with IDE tools, Maven or Gradle), that can
be found here: https://github.com/openjfx/samples/tree/master/IDE/NetBeans.

And those FXML files work of course with Scene Builder (10, but 11 will be
released very soon).

Hope this helps you. Otherwise please feel free to file an issue:
https://github.com/openjfx/openjfx-docs/issues




On Mon, Nov 19, 2018 at 8:22 AM Selim Dincer <wowselim at gmail.com> wrote:

> Hi,
>
> IntelliJ works quite OK with 11. Make sure to rightclick the fxml files ->
> open in scenebuilder instead of the integrated one because that's an older
> version. Also if you want to run your app without maven / gradle then you
> need to download the javafx sdk and set JAVA_HOME otherwise you will get
> some weird error. Also make sure to configure your run configuration
> exactly like the recommended maven / gradle run configurations.
> Apart from that the guide on the openjfx site (the gradle variant) kind of
> worked for me.
>
> This is why I suggested something like spring initializr or vert.x starter
> before.
>
> On Sun, 18 Nov 2018, 22:02 Michael Dever <michael.dever at icloud.com wrote:
>
> > Oracle seems to have Destroyed the combination of:
> > Netbeans, JavaFX, and SceneBuilder, building JavaFX from an IDE.
> >
> > Is there any other IDE that supports and builds: JavaFX FXML
> Applications,
> > out of the box that just works, and that you can design the GUI
> > application from SceneBuilder?
> >
> >
> > Thanks,
> > Mike Dever
> >
> >
> >
>


--

From julianjupiter.io at gmail.com  Mon Nov 19 12:14:21 2018
From: julianjupiter.io at gmail.com (Julian Jupiter)
Date: Mon, 19 Nov 2018 20:14:21 +0800
Subject: Netbeans X & Java 11?
In-Reply-To: <CAGMSBrJ8rY7L+b0oD8g2aNbfiLF+VMv4gUZ7VdPH4+UXd_nMPQ@mail.gmail.com>
References: <DA177A08-BF63-4ED1-8055-0D8BB9C49889@icloud.com>
 <CANp2C1z6zVg7wTC3Uoh96pW_mHNqa_SJMNUiwfH_1rxtU2ovBg@mail.gmail.com>
 <CAGMSBrJ8rY7L+b0oD8g2aNbfiLF+VMv4gUZ7VdPH4+UXd_nMPQ@mail.gmail.com>
Message-ID: <CALYU9KFxkZx9dOh6=f6u14HD0qMVRdwONm4-LxoXR81ftwfB-A@mail.gmail.com>

Hi Mike,

Check this YT video:
https://www.youtube.com/watch?v=l9aoicDiQ_A&feature=share

Thank you.

On Mon, Nov 19, 2018, 6:30 PM Jos? Pereda <jose.pereda at gluonhq.com wrote:

> Hi, Mike.
>
> Did you check the docs? https://openjfx.io/openjfx-docs/
>
> There is a whole section for IDEs, including NetBeans (
> https://openjfx.io/openjfx-docs/#IDE-NetBeans), that explains how to work
> with both modular and non-modular projects.
>
> While you may have noticed that the usual JavaFX project template doesn't
> work, you can use a regular Java project, instead (the ant tasks have not
> been updated yet, but they are working on it).
>
> There is a sample (a simple HelloFX that uses FXML) for each possible case
> (modular/non-modular, each one with IDE tools, Maven or Gradle), that can
> be found here: https://github.com/openjfx/samples/tree/master/IDE/NetBeans
> .
>
> And those FXML files work of course with Scene Builder (10, but 11 will be
> released very soon).
>
> Hope this helps you. Otherwise please feel free to file an issue:
> https://github.com/openjfx/openjfx-docs/issues
>
>
>
>
> On Mon, Nov 19, 2018 at 8:22 AM Selim Dincer <wowselim at gmail.com> wrote:
>
> > Hi,
> >
> > IntelliJ works quite OK with 11. Make sure to rightclick the fxml files
> ->
> > open in scenebuilder instead of the integrated one because that's an
> older
> > version. Also if you want to run your app without maven / gradle then you
> > need to download the javafx sdk and set JAVA_HOME otherwise you will get
> > some weird error. Also make sure to configure your run configuration
> > exactly like the recommended maven / gradle run configurations.
> > Apart from that the guide on the openjfx site (the gradle variant) kind
> of
> > worked for me.
> >
> > This is why I suggested something like spring initializr or vert.x
> starter
> > before.
> >
> > On Sun, 18 Nov 2018, 22:02 Michael Dever <michael.dever at icloud.com
> wrote:
> >
> > > Oracle seems to have Destroyed the combination of:
> > > Netbeans, JavaFX, and SceneBuilder, building JavaFX from an IDE.
> > >
> > > Is there any other IDE that supports and builds: JavaFX FXML
> > Applications,
> > > out of the box that just works, and that you can design the GUI
> > > application from SceneBuilder?
> > >
> > >
> > > Thanks,
> > > Mike Dever
> > >
> > >
> > >
> >
>
>
> --
>

From dalibor.topic at oracle.com  Mon Nov 19 13:07:24 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Mon, 19 Nov 2018 14:07:24 +0100
Subject: Netbeans X & Java 11?
In-Reply-To: <DA177A08-BF63-4ED1-8055-0D8BB9C49889@icloud.com>
References: <DA177A08-BF63-4ED1-8055-0D8BB9C49889@icloud.com>
Message-ID: <6c7646b5-4f40-7031-2d2f-9a1af3d18c83@oracle.com>

On 18.11.2018 22:01, Michael Dever wrote:
> Oracle seems to have Destroyed the combination of:
> Netbeans, JavaFX, and SceneBuilder, building JavaFX from an IDE.
> Hi,

It sounds as if you would like to discuss issues or improvements in 
Apache NetBeans. In order for your insights to have the best effect, you 
should be doing so on an Apache NetBeans mailing list.

Please see https://netbeans.apache.org/ for the many different ways of 
participating in Apache NetBeans.

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From johan.vos at gluonhq.com  Mon Nov 19 18:03:27 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Mon, 19 Nov 2018 19:03:27 +0100
Subject: Review request: Long scrolling on mac [JDK-8183399]
Message-ID: <CABxFH2Firk8Zca7jBUoMqe-NjeUgqM_CnDHpo3muOBiVxDXXxg@mail.gmail.com>

Please review the fix for issue
https://bugs.openjdk.java.net/browse/JDK-8183399 (
https://github.com/javafxports/openjdk-jfx/issues/38) which should be fixed
with PR #274
(https://github.com/javafxports/openjdk-jfx/pull/274)

It only affects mac builds.

- Johan

From anton.tarasov at jetbrains.com  Mon Nov 19 20:17:39 2018
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Mon, 19 Nov 2018 23:17:39 +0300
Subject: issue with WebView in 8u202
Message-ID: <3c07e0a8-a838-0acb-3f0f-f2e4f8cfc8c7@jetbrains.com>

Hello, JFX team!

We (at JetBrains) faced an issue with WebView after we've moved to an 
JFX update in JDK8u202. The issue is that WebView stopped loading images 
referenced by an absolute URL under some circumstances.

Below is a real html content, produced by IDEA markdown viewer. It has 
lots of style pre-loads and a sample image that it should eventually 
display. The html is loaded view WebEngine.loadContent(..) but a 
placeholder text is only displayed - that's the problem that can be 
reproduce with JDK8u202. However it worked with JDK8u152.

The style references will obviously fail for you, but if you put this 
html into a file and will load it via 
WebEngine.load(file:///path/to/file), the image will be shown with no 
problem (in 8u202 as well).

<html><head><meta http-equiv="Content-Security-Policy" 
content="default-src 'none'; script-src 
http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3 
http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3; 
style-src https: 
http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
http://localhost:63344/api/markdown-preview/styles/darcula.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
http://localhost:63344/api/markdown-preview/styles/inline.css?_ijt=ujioejund46k8cmdcsuggbpnf3; 
img-src *; connect-src 'none'; font-src *; object-src 'none'; media-src 
'none'; child-src 'none';"/><link rel="stylesheet" 
href="http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3" 
/>

<script 
src="http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script>
<script 
src="http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script></head><body 
md-src-pos="0..89"><p md-src-pos="0..88"><img 
src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
alt="Kitten" title="A cute kitten" md-src-pos="0..88" /></p></body></html>

Then, if you remove all the style loading and leave only the image, the 
image will be shown in either way: load(url) or loadContent (in 8u202)

<html><head></head><body md-src-pos="0..89"><p md-src-pos="0..88"><img 
src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
alt="Kitten" title="A cute kitten" md-src-pos="0..88" /></p></body></html>

Sorry for not submitting the code, I hope you will easily put it into a 
real demo (I played with JFX's WebViewApp).

So, could you please advice on what went wrong with it?

With regards,
Anton.

From anton.tarasov at jetbrains.com  Mon Nov 19 20:20:03 2018
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Mon, 19 Nov 2018 23:20:03 +0300
Subject: issue with WebView in 8u202
In-Reply-To: <3c07e0a8-a838-0acb-3f0f-f2e4f8cfc8c7@jetbrains.com>
References: <3c07e0a8-a838-0acb-3f0f-f2e4f8cfc8c7@jetbrains.com>
Message-ID: <2cd57728-4650-ad16-c6e6-71ce100e5d2b@jetbrains.com>

(relates to MS Windows, at least)


On 11/19/2018 11:17 PM, Anton Tarasov wrote:
> Hello, JFX team!
>
> We (at JetBrains) faced an issue with WebView after we've moved to an 
> JFX update in JDK8u202. The issue is that WebView stopped loading 
> images referenced by an absolute URL under some circumstances.
>
> Below is a real html content, produced by IDEA markdown viewer. It has 
> lots of style pre-loads and a sample image that it should eventually 
> display. The html is loaded view WebEngine.loadContent(..) but a 
> placeholder text is only displayed - that's the problem that can be 
> reproduce with JDK8u202. However it worked with JDK8u152.
>
> The style references will obviously fail for you, but if you put this 
> html into a file and will load it via 
> WebEngine.load(file:///path/to/file), the image will be shown with no 
> problem (in 8u202 as well).
>
> <html><head><meta http-equiv="Content-Security-Policy" 
> content="default-src 'none'; script-src 
> http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3 
> http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3; 
> style-src https: 
> http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
> http://localhost:63344/api/markdown-preview/styles/darcula.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
> http://localhost:63344/api/markdown-preview/styles/inline.css?_ijt=ujioejund46k8cmdcsuggbpnf3; 
> img-src *; connect-src 'none'; font-src *; object-src 'none'; 
> media-src 'none'; child-src 'none';"/><link rel="stylesheet" 
> href="http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3" 
> />
>
> <script 
> src="http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script>
> <script 
> src="http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script></head><body 
> md-src-pos="0..89"><p md-src-pos="0..88"><img 
> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
> alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
> /></p></body></html>
>
> Then, if you remove all the style loading and leave only the image, 
> the image will be shown in either way: load(url) or loadContent (in 
> 8u202)
>
> <html><head></head><body md-src-pos="0..89"><p md-src-pos="0..88"><img 
> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
> alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
> /></p></body></html>
>
> Sorry for not submitting the code, I hope you will easily put it into 
> a real demo (I played with JFX's WebViewApp).
>
> So, could you please advice on what went wrong with it?
>
> With regards,
> Anton.


From kevin.rushforth at oracle.com  Mon Nov 19 21:21:09 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 19 Nov 2018 13:21:09 -0800
Subject: issue with WebView in 8u202
In-Reply-To: <3c07e0a8-a838-0acb-3f0f-f2e4f8cfc8c7@jetbrains.com>
References: <3c07e0a8-a838-0acb-3f0f-f2e4f8cfc8c7@jetbrains.com>
Message-ID: <c1d78453-692c-2c38-2044-a8794b9d5572@oracle.com>

Hi Anton,

We'll take a look and see if we can reproduce it. Am I correct in 
understanding that the problem only happens with loadContent, which 
works on 8u152 and fails on 8u202-ea? And that load from a file works 
fine on both 8u152 and 8u202-ea?

-- Kevin


On 11/19/2018 12:17 PM, Anton Tarasov wrote:
> Hello, JFX team!
>
> We (at JetBrains) faced an issue with WebView after we've moved to an 
> JFX update in JDK8u202. The issue is that WebView stopped loading 
> images referenced by an absolute URL under some circumstances.
>
> Below is a real html content, produced by IDEA markdown viewer. It has 
> lots of style pre-loads and a sample image that it should eventually 
> display. The html is loaded view WebEngine.loadContent(..) but a 
> placeholder text is only displayed - that's the problem that can be 
> reproduce with JDK8u202. However it worked with JDK8u152.
>
> The style references will obviously fail for you, but if you put this 
> html into a file and will load it via 
> WebEngine.load(file:///path/to/file), the image will be shown with no 
> problem (in 8u202 as well).
>
> <html><head><meta http-equiv="Content-Security-Policy" 
> content="default-src 'none'; script-src 
> http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3 
> http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3; 
> style-src https: 
> http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
> http://localhost:63344/api/markdown-preview/styles/darcula.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
> http://localhost:63344/api/markdown-preview/styles/inline.css?_ijt=ujioejund46k8cmdcsuggbpnf3; 
> img-src *; connect-src 'none'; font-src *; object-src 'none'; 
> media-src 'none'; child-src 'none';"/><link rel="stylesheet" 
> href="http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3" 
> />
>
> <script 
> src="http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script>
> <script 
> src="http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script></head><body 
> md-src-pos="0..89"><p md-src-pos="0..88"><img 
> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
> alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
> /></p></body></html>
>
> Then, if you remove all the style loading and leave only the image, 
> the image will be shown in either way: load(url) or loadContent (in 
> 8u202)
>
> <html><head></head><body md-src-pos="0..89"><p md-src-pos="0..88"><img 
> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
> alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
> /></p></body></html>
>
> Sorry for not submitting the code, I hope you will easily put it into 
> a real demo (I played with JFX's WebViewApp).
>
> So, could you please advice on what went wrong with it?
>
> With regards,
> Anton.


From anton.tarasov at jetbrains.com  Mon Nov 19 21:44:01 2018
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Tue, 20 Nov 2018 00:44:01 +0300
Subject: issue with WebView in 8u202
In-Reply-To: <c1d78453-692c-2c38-2044-a8794b9d5572@oracle.com>
References: <3c07e0a8-a838-0acb-3f0f-f2e4f8cfc8c7@jetbrains.com>
 <c1d78453-692c-2c38-2044-a8794b9d5572@oracle.com>
Message-ID: <3f7cdd52-590d-53e6-dc80-92feefdc59b1@jetbrains.com>

Hi Kevin,

On 11/20/2018 12:21 AM, Kevin Rushforth wrote:
> Hi Anton,
>
> We'll take a look and see if we can reproduce it. Am I correct in 
> understanding that the problem only happens with loadContent, which 
> works on 8u152 and fails on 8u202-ea? And that load from a file works 
> fine on both 8u152 and 8u202-ea?
>
Yes, that's right. I've also checked that it's broken in the latest 
jfx12 as well. I'd appreciate your help in resolving this.

Thanks,
Anton.

>
> -- Kevin
>
>
> On 11/19/2018 12:17 PM, Anton Tarasov wrote:
>> Hello, JFX team!
>>
>> We (at JetBrains) faced an issue with WebView after we've moved to an 
>> JFX update in JDK8u202. The issue is that WebView stopped loading 
>> images referenced by an absolute URL under some circumstances.
>>
>> Below is a real html content, produced by IDEA markdown viewer. It 
>> has lots of style pre-loads and a sample image that it should 
>> eventually display. The html is loaded view WebEngine.loadContent(..) 
>> but a placeholder text is only displayed - that's the problem that 
>> can be reproduce with JDK8u202. However it worked with JDK8u152.
>>
>> The style references will obviously fail for you, but if you put this 
>> html into a file and will load it via 
>> WebEngine.load(file:///path/to/file), the image will be shown with no 
>> problem (in 8u202 as well).
>>
>> <html><head><meta http-equiv="Content-Security-Policy" 
>> content="default-src 'none'; script-src 
>> http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3 
>> http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3; 
>> style-src https: 
>> http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
>> http://localhost:63344/api/markdown-preview/styles/darcula.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
>> http://localhost:63344/api/markdown-preview/styles/inline.css?_ijt=ujioejund46k8cmdcsuggbpnf3; 
>> img-src *; connect-src 'none'; font-src *; object-src 'none'; 
>> media-src 'none'; child-src 'none';"/><link rel="stylesheet" 
>> href="http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3" 
>> />
>>
>> <script 
>> src="http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script>
>> <script 
>> src="http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script></head><body 
>> md-src-pos="0..89"><p md-src-pos="0..88"><img 
>> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
>> alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
>> /></p></body></html>
>>
>> Then, if you remove all the style loading and leave only the image, 
>> the image will be shown in either way: load(url) or loadContent (in 
>> 8u202)
>>
>> <html><head></head><body md-src-pos="0..89"><p 
>> md-src-pos="0..88"><img 
>> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
>> alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
>> /></p></body></html>
>>
>> Sorry for not submitting the code, I hope you will easily put it into 
>> a real demo (I played with JFX's WebViewApp).
>>
>> So, could you please advice on what went wrong with it?
>>
>> With regards,
>> Anton.
>


From kevin.rushforth at oracle.com  Mon Nov 19 21:51:02 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 19 Nov 2018 13:51:02 -0800
Subject: issue with WebView in 8u202
In-Reply-To: <3f7cdd52-590d-53e6-dc80-92feefdc59b1@jetbrains.com>
References: <3c07e0a8-a838-0acb-3f0f-f2e4f8cfc8c7@jetbrains.com>
 <c1d78453-692c-2c38-2044-a8794b9d5572@oracle.com>
 <3f7cdd52-590d-53e6-dc80-92feefdc59b1@jetbrains.com>
Message-ID: <10bdfde9-50e9-0762-0bf5-bf289e21b838@oracle.com>

I can reproduce it and it seems related to Cross-Site-Scripting (XSS) 
protections, which you have enabled in your HTML header with:

 ??? <meta http-equiv="Content-Security-Policy" ...>

If I remove the 'http-equiv="Content-Security-Policy"' from the 
meta-data then it displays just fine.

Perhaps Arun or Murali could comment on whether this is a bug or not. It 
seems just as likely to me that it is a feature that didn't used to be 
enabled and now is.

-- Kevin


On 11/19/2018 1:44 PM, Anton Tarasov wrote:
> Hi Kevin,
>
> On 11/20/2018 12:21 AM, Kevin Rushforth wrote:
>> Hi Anton,
>>
>> We'll take a look and see if we can reproduce it. Am I correct in 
>> understanding that the problem only happens with loadContent, which 
>> works on 8u152 and fails on 8u202-ea? And that load from a file works 
>> fine on both 8u152 and 8u202-ea?
>>
> Yes, that's right. I've also checked that it's broken in the latest 
> jfx12 as well. I'd appreciate your help in resolving this.
>
> Thanks,
> Anton.
>
>>
>> -- Kevin
>>
>>
>> On 11/19/2018 12:17 PM, Anton Tarasov wrote:
>>> Hello, JFX team!
>>>
>>> We (at JetBrains) faced an issue with WebView after we've moved to 
>>> an JFX update in JDK8u202. The issue is that WebView stopped loading 
>>> images referenced by an absolute URL under some circumstances.
>>>
>>> Below is a real html content, produced by IDEA markdown viewer. It 
>>> has lots of style pre-loads and a sample image that it should 
>>> eventually display. The html is loaded view 
>>> WebEngine.loadContent(..) but a placeholder text is only displayed - 
>>> that's the problem that can be reproduce with JDK8u202. However it 
>>> worked with JDK8u152.
>>>
>>> The style references will obviously fail for you, but if you put 
>>> this html into a file and will load it via 
>>> WebEngine.load(file:///path/to/file), the image will be shown with 
>>> no problem (in 8u202 as well).
>>>
>>> <html><head><meta http-equiv="Content-Security-Policy" 
>>> content="default-src 'none'; script-src 
>>> http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3 
>>> http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3; 
>>> style-src https: 
>>> http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
>>> http://localhost:63344/api/markdown-preview/styles/darcula.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
>>> http://localhost:63344/api/markdown-preview/styles/inline.css?_ijt=ujioejund46k8cmdcsuggbpnf3; 
>>> img-src *; connect-src 'none'; font-src *; object-src 'none'; 
>>> media-src 'none'; child-src 'none';"/><link rel="stylesheet" 
>>> href="http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3" 
>>> />
>>>
>>> <script 
>>> src="http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script>
>>> <script 
>>> src="http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script></head><body 
>>> md-src-pos="0..89"><p md-src-pos="0..88"><img 
>>> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
>>> alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
>>> /></p></body></html>
>>>
>>> Then, if you remove all the style loading and leave only the image, 
>>> the image will be shown in either way: load(url) or loadContent (in 
>>> 8u202)
>>>
>>> <html><head></head><body md-src-pos="0..89"><p 
>>> md-src-pos="0..88"><img 
>>> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
>>> alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
>>> /></p></body></html>
>>>
>>> Sorry for not submitting the code, I hope you will easily put it 
>>> into a real demo (I played with JFX's WebViewApp).
>>>
>>> So, could you please advice on what went wrong with it?
>>>
>>> With regards,
>>> Anton.
>>
>


From kevin.rushforth at oracle.com  Mon Nov 19 22:34:14 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 19 Nov 2018 14:34:14 -0800
Subject: [12] RFR: JDK-8198961: Remove old version of SceneBuilder from OpenJFX
Message-ID: <d0699fff-8a2e-3b46-a9dd-1a590ed579f2@oracle.com>

Please review the following to remove the obsolete SceneBuilder sources 
from the openjfx/jfx-dev/rt repo:

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

Details of the proposed change are in JBS.

I will leave this review open for at least one week in case anyone wants 
to comment on this. As mentioned in JBS, the sources have not been 
touched since JDK 9, and then only to fix various Jigsaw issues.

The existing sources are still present in the openjfx/11-dev repo [1].

A fork of this repo is being maintained by Gluon [2].

-- Kevin

[1] 
http://hg.openjdk.java.net/openjfx/11-dev/rt/file/9a421b0a5ab1/apps/scenebuilder
[2] https://github.com/gluonhq/scenebuilder


From anton.tarasov at jetbrains.com  Tue Nov 20 04:34:50 2018
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Tue, 20 Nov 2018 07:34:50 +0300
Subject: issue with WebView in 8u202
In-Reply-To: <10bdfde9-50e9-0762-0bf5-bf289e21b838@oracle.com>
References: <3c07e0a8-a838-0acb-3f0f-f2e4f8cfc8c7@jetbrains.com>
 <c1d78453-692c-2c38-2044-a8794b9d5572@oracle.com>
 <3f7cdd52-590d-53e6-dc80-92feefdc59b1@jetbrains.com>
 <10bdfde9-50e9-0762-0bf5-bf289e21b838@oracle.com>
Message-ID: <155bfa15-ab86-e467-39c4-0105f680fdbd@jetbrains.com>

Thanks for the catch, Kevin! Seems very likely. Is it the thing 
configured at compile-time?

Regards,
Anton.

On 11/20/2018 12:51 AM, Kevin Rushforth wrote:
> I can reproduce it and it seems related to Cross-Site-Scripting (XSS) 
> protections, which you have enabled in your HTML header with:
>
> ??? <meta http-equiv="Content-Security-Policy" ...>
>
> If I remove the 'http-equiv="Content-Security-Policy"' from the 
> meta-data then it displays just fine.
>
> Perhaps Arun or Murali could comment on whether this is a bug or not. 
> It seems just as likely to me that it is a feature that didn't used to 
> be enabled and now is.
>
> -- Kevin
>
>
> On 11/19/2018 1:44 PM, Anton Tarasov wrote:
>> Hi Kevin,
>>
>> On 11/20/2018 12:21 AM, Kevin Rushforth wrote:
>>> Hi Anton,
>>>
>>> We'll take a look and see if we can reproduce it. Am I correct in 
>>> understanding that the problem only happens with loadContent, which 
>>> works on 8u152 and fails on 8u202-ea? And that load from a file 
>>> works fine on both 8u152 and 8u202-ea?
>>>
>> Yes, that's right. I've also checked that it's broken in the latest 
>> jfx12 as well. I'd appreciate your help in resolving this.
>>
>> Thanks,
>> Anton.
>>
>>>
>>> -- Kevin
>>>
>>>
>>> On 11/19/2018 12:17 PM, Anton Tarasov wrote:
>>>> Hello, JFX team!
>>>>
>>>> We (at JetBrains) faced an issue with WebView after we've moved to 
>>>> an JFX update in JDK8u202. The issue is that WebView stopped 
>>>> loading images referenced by an absolute URL under some circumstances.
>>>>
>>>> Below is a real html content, produced by IDEA markdown viewer. It 
>>>> has lots of style pre-loads and a sample image that it should 
>>>> eventually display. The html is loaded view 
>>>> WebEngine.loadContent(..) but a placeholder text is only displayed 
>>>> - that's the problem that can be reproduce with JDK8u202. However 
>>>> it worked with JDK8u152.
>>>>
>>>> The style references will obviously fail for you, but if you put 
>>>> this html into a file and will load it via 
>>>> WebEngine.load(file:///path/to/file), the image will be shown with 
>>>> no problem (in 8u202 as well).
>>>>
>>>> <html><head><meta http-equiv="Content-Security-Policy" 
>>>> content="default-src 'none'; script-src 
>>>> http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3 
>>>> http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3; 
>>>> style-src https: 
>>>> http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
>>>> http://localhost:63344/api/markdown-preview/styles/darcula.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
>>>> http://localhost:63344/api/markdown-preview/styles/inline.css?_ijt=ujioejund46k8cmdcsuggbpnf3; 
>>>> img-src *; connect-src 'none'; font-src *; object-src 'none'; 
>>>> media-src 'none'; child-src 'none';"/><link rel="stylesheet" 
>>>> href="http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3" 
>>>> />
>>>>
>>>> <script 
>>>> src="http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script>
>>>> <script 
>>>> src="http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script></head><body 
>>>> md-src-pos="0..89"><p md-src-pos="0..88"><img 
>>>> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
>>>> alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
>>>> /></p></body></html>
>>>>
>>>> Then, if you remove all the style loading and leave only the image, 
>>>> the image will be shown in either way: load(url) or loadContent (in 
>>>> 8u202)
>>>>
>>>> <html><head></head><body md-src-pos="0..89"><p 
>>>> md-src-pos="0..88"><img 
>>>> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
>>>> alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
>>>> /></p></body></html>
>>>>
>>>> Sorry for not submitting the code, I hope you will easily put it 
>>>> into a real demo (I played with JFX's WebViewApp).
>>>>
>>>> So, could you please advice on what went wrong with it?
>>>>
>>>> With regards,
>>>> Anton.
>>>
>>
>


From nlisker at gmail.com  Tue Nov 20 05:52:20 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 20 Nov 2018 07:52:20 +0200
Subject: JavaBeanObjectPropertyBuilder has incomplete generics support
In-Reply-To: <4b6d56b5-8054-680d-67d6-56c821f4e313@merus.eu>
References: <4b6d56b5-8054-680d-67d6-56c821f4e313@merus.eu>
Message-ID: <CA+0ynh9gEtV4x+MzASMOT_d0u6DVYtXs=E=C9y7zoUMdTgbNJg@mail.gmail.com>

This is simple enough, but I think it breaks backwards compatibility at the
API level. Warnings about raw types are common in the library, though most
are internal.

If this is somehow allowed I can easily submit a patch.

- Nir

On Fri, Nov 2, 2018 at 3:27 PM Rachel Greenham <rachel at merus.eu> wrote:

> javax.beans.property.adapter.JavaBeanObjectPropertyBuilder seems to be
> only partially adapted for generics. The class itself has a generic type
> (class JavaBeanObjectPropertyBuilder<T>) and its build() method returns
> JavaBeanObjectProperty<T>, but the lack of other support means you can't
> fluently create a property without also suppressing "unchecked" warnings.
>
> ie: One might want to do:
>
> private ObjectProperty<Inet4Address> ip4Property;
>
> ...
>
> this.ip4Property = JavaBeanObjectPropertyBuilder.create()
>      .bean(server)
>      .name("ip")
>      .build();
>
> but this will produce "unchecked" warnings during compilation. Harmless
> but annoying when you want to keep it clean. As it stands, to compile
> cleanly you need to split it up:
>
> var builder = new JavaBeanObjectPropertyBuilder<Inet4Address>();
> builder.bean(server).name("ip"); // they return untyped builder
> this.ip4Property = builder.build();
>
> ... or suppress the warning. I hate suppressing warnings. :-)
>
> Proposed fix: (I don't have an OpenJFX build environment yet, this is
> the first time I've wanted to change something!)
>
> * Each of the instance methods (except build()) to have declared return
> type JavaBeanObjectPropertyBuilder<T>. This allows chaining those fluent
> builder methods without losing the generic type.
>
> * create() method to be:
> public static <T> JavaBeanObjectPropertyBuilder<T> create() {
>      return new JavaBeanObjectPropertyBuilder<T>();
> }
>
> I think that's all it needs, and the latter only if you prefer to use
> the static builder factory method rather than just using the constructor
> directly. Then the first code example above would work cleanly as is. It
> also allows for callers to optionally explicitly specify the generic
> type to create() with eg: var builder =
> JavaBeanObjectPropertyBuilder.<Inet4Address>create().
>
> As you can see all this is just generic type declarations, which should
> all be erased to cause no actual change to runtime. The effect on
> existing code should be null except that some people would be able to,
> if they want, remove the @SuppressWarnings
> ("unchecked") annotation they've so far had to put above it.
>
> --
> Rachel
>
>

From arunprasad.rajkumar at oracle.com  Tue Nov 20 07:09:19 2018
From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar)
Date: Tue, 20 Nov 2018 12:39:19 +0530
Subject: issue with WebView in 8u202
In-Reply-To: <155bfa15-ab86-e467-39c4-0105f680fdbd@jetbrains.com>
References: <3c07e0a8-a838-0acb-3f0f-f2e4f8cfc8c7@jetbrains.com>
 <c1d78453-692c-2c38-2044-a8794b9d5572@oracle.com>
 <3f7cdd52-590d-53e6-dc80-92feefdc59b1@jetbrains.com>
 <10bdfde9-50e9-0762-0bf5-bf289e21b838@oracle.com>
 <155bfa15-ab86-e467-39c4-0105f680fdbd@jetbrains.com>
Message-ID: <675A3B67-15C7-4A47-BBAE-5B1168CBBDBB@oracle.com>

Hi Anton,

Looks like this is mostly related to Content Security Policy(CSP)[1] which have got strengthened after recent WebKit upgrades.

I have reduced the given html further(PSB) & I could reproduce the problem with the following html snippet,

<html><head>
<meta http-equiv='Content-Security-Policy' content='img-src *;?/></head>
<body>
<img src='file:///Users/ARAJKUMA/Downloads/penguingun-900x900.jpg' alt='from file:?/>
<img src='https://betanews.com/wp-content/uploads/2016/04/penguingun-900x900.jpg' alt=?from http:?/>
</body></html>

In the above html snippet, CSP of img tag is set to load from all except file scheme. It would load img from http: but not from file. If you also want to load from file: scheme, then you must explicitly set that in the CSP header. Something like below,

<html><head>
<meta http-equiv='Content-Security-Policy' content='img-src file: *;?/></head>
<body>
<img src='file:///Users/ARAJKUMA/Downloads/penguingun-900x900.jpg' alt='from file:?/>
<img src='https://betanews.com/wp-content/uploads/2016/04/penguingun-900x900.jpg' alt=?from http:?/>
</body></html>

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

Thanks,
Arun

> On 20-Nov-2018, at 10:04 AM, Anton Tarasov <anton.tarasov at jetbrains.com> wrote:
> 
> Thanks for the catch, Kevin! Seems very likely. Is it the thing configured at compile-time?
> 
> Regards,
> Anton.
> 
> On 11/20/2018 12:51 AM, Kevin Rushforth wrote:
>> I can reproduce it and it seems related to Cross-Site-Scripting (XSS) protections, which you have enabled in your HTML header with:
>> 
>>     <meta http-equiv="Content-Security-Policy" ...>
>> 
>> If I remove the 'http-equiv="Content-Security-Policy"' from the meta-data then it displays just fine.
>> 
>> Perhaps Arun or Murali could comment on whether this is a bug or not. It seems just as likely to me that it is a feature that didn't used to be enabled and now is.
>> 
>> -- Kevin
>> 
>> 
>> On 11/19/2018 1:44 PM, Anton Tarasov wrote:
>>> Hi Kevin,
>>> 
>>> On 11/20/2018 12:21 AM, Kevin Rushforth wrote:
>>>> Hi Anton,
>>>> 
>>>> We'll take a look and see if we can reproduce it. Am I correct in understanding that the problem only happens with loadContent, which works on 8u152 and fails on 8u202-ea? And that load from a file works fine on both 8u152 and 8u202-ea?
>>>> 
>>> Yes, that's right. I've also checked that it's broken in the latest jfx12 as well. I'd appreciate your help in resolving this.
>>> 
>>> Thanks,
>>> Anton.
>>> 
>>>> 
>>>> -- Kevin
>>>> 
>>>> 
>>>> On 11/19/2018 12:17 PM, Anton Tarasov wrote:
>>>>> Hello, JFX team!
>>>>> 
>>>>> We (at JetBrains) faced an issue with WebView after we've moved to an JFX update in JDK8u202. The issue is that WebView stopped loading images referenced by an absolute URL under some circumstances.
>>>>> 
>>>>> Below is a real html content, produced by IDEA markdown viewer. It has lots of style pre-loads and a sample image that it should eventually display. The html is loaded view WebEngine.loadContent(..) but a placeholder text is only displayed - that's the problem that can be reproduce with JDK8u202. However it worked with JDK8u152.
>>>>> 
>>>>> The style references will obviously fail for you, but if you put this html into a file and will load it via WebEngine.load(file:///path/to/file), the image will be shown with no problem (in 8u202 as well).
>>>>> 
>>>>> <html><head><meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3 http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3; style-src https: http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3 http://localhost:63344/api/markdown-preview/styles/darcula.css?_ijt=ujioejund46k8cmdcsuggbpnf3 http://localhost:63344/api/markdown-preview/styles/inline.css?_ijt=ujioejund46k8cmdcsuggbpnf3; img-src *; connect-src 'none'; font-src *; object-src 'none'; media-src 'none'; child-src 'none';"/><link rel="stylesheet" href="http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3" />
>>>>> 
>>>>> <script src="http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script>
>>>>> <script src="http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script></head><body md-src-pos="0..89"><p md-src-pos="0..88"><img src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" alt="Kitten" title="A cute kitten" md-src-pos="0..88" /></p></body></html>
>>>>> 
>>>>> Then, if you remove all the style loading and leave only the image, the image will be shown in either way: load(url) or loadContent (in 8u202)
>>>>> 
>>>>> <html><head></head><body md-src-pos="0..89"><p md-src-pos="0..88"><img src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" alt="Kitten" title="A cute kitten" md-src-pos="0..88" /></p></body></html>
>>>>> 
>>>>> Sorry for not submitting the code, I hope you will easily put it into a real demo (I played with JFX's WebViewApp).
>>>>> 
>>>>> So, could you please advice on what went wrong with it?
>>>>> 
>>>>> With regards,
>>>>> Anton.
>>>> 
>>> 
>> 
> 


From murali.billa at oracle.com  Tue Nov 20 08:14:41 2018
From: murali.billa at oracle.com (Murali Billa)
Date: Tue, 20 Nov 2018 00:14:41 -0800 (PST)
Subject: issue with WebView in 8u202
In-Reply-To: <675A3B67-15C7-4A47-BBAE-5B1168CBBDBB@oracle.com>
References: <3c07e0a8-a838-0acb-3f0f-f2e4f8cfc8c7@jetbrains.com>
 <c1d78453-692c-2c38-2044-a8794b9d5572@oracle.com>
 <3f7cdd52-590d-53e6-dc80-92feefdc59b1@jetbrains.com>
 <10bdfde9-50e9-0762-0bf5-bf289e21b838@oracle.com>
 <155bfa15-ab86-e467-39c4-0105f680fdbd@jetbrains.com>
 <675A3B67-15C7-4A47-BBAE-5B1168CBBDBB@oracle.com>
Message-ID: <fa1a6346-7f9f-4d3a-9594-87e4db6a6f24@default>

Hi Arun,

Regarding   <meta http-equiv='Content-Security-Policy' content='img-src *;?/>
               -      In the above html snippet, CSP of img tag is set to load from all except file scheme. 

I think the above statement is not correct. For me it loads both file and https images with img-src *; (tested in hellowebview and chrome).  I guess  the reason why the 2nd image(https)  is not loaded with above code is there is a mismatch of backquote (?) for alt='from file:?
Also from spec [1]  img-src *; means  "Images may load from anywhere (note the "*" wildcard)."

I think to load from file: scheme, there is no need to specify explicitly in the CSP header (apart from "*" wild card)

Please correct me if im wrong.

Thanks,
Murali

-----Original Message-----
From: Arunprasad Rajkumar 
Sent: Tuesday, November 20, 2018 12:39 PM
To: Anton Tarasov <anton.tarasov at jetbrains.com>
Cc: openjfx-dev at openjdk.java.net
Subject: Re: issue with WebView in 8u202

Hi Anton,

Looks like this is mostly related to Content Security Policy(CSP)[1] which have got strengthened after recent WebKit upgrades.

I have reduced the given html further(PSB) & I could reproduce the problem with the following html snippet,

<html><head>
<meta http-equiv='Content-Security-Policy' content='img-src *;?/></head> <body> <img src='file:///Users/ARAJKUMA/Downloads/penguingun-900x900.jpg' alt='from file:?/> <img src='https://betanews.com/wp-content/uploads/2016/04/penguingun-900x900.jpg' alt=?from http:?/> </body></html>

In the above html snippet, CSP of img tag is set to load from all except file scheme. It would load img from http: but not from file. If you also want to load from file: scheme, then you must explicitly set that in the CSP header. Something like below,

<html><head>
<meta http-equiv='Content-Security-Policy' content='img-src file: *;?/></head> <body> <img src='file:///Users/ARAJKUMA/Downloads/penguingun-900x900.jpg' alt='from file:?/> <img src='https://betanews.com/wp-content/uploads/2016/04/penguingun-900x900.jpg' alt=?from http:?/> </body></html>

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

Thanks,
Arun

> On 20-Nov-2018, at 10:04 AM, Anton Tarasov <anton.tarasov at jetbrains.com> wrote:
> 
> Thanks for the catch, Kevin! Seems very likely. Is it the thing configured at compile-time?
> 
> Regards,
> Anton.
> 
> On 11/20/2018 12:51 AM, Kevin Rushforth wrote:
>> I can reproduce it and it seems related to Cross-Site-Scripting (XSS) protections, which you have enabled in your HTML header with:
>> 
>>     <meta http-equiv="Content-Security-Policy" ...>
>> 
>> If I remove the 'http-equiv="Content-Security-Policy"' from the meta-data then it displays just fine.
>> 
>> Perhaps Arun or Murali could comment on whether this is a bug or not. It seems just as likely to me that it is a feature that didn't used to be enabled and now is.
>> 
>> -- Kevin
>> 
>> 
>> On 11/19/2018 1:44 PM, Anton Tarasov wrote:
>>> Hi Kevin,
>>> 
>>> On 11/20/2018 12:21 AM, Kevin Rushforth wrote:
>>>> Hi Anton,
>>>> 
>>>> We'll take a look and see if we can reproduce it. Am I correct in understanding that the problem only happens with loadContent, which works on 8u152 and fails on 8u202-ea? And that load from a file works fine on both 8u152 and 8u202-ea?
>>>> 
>>> Yes, that's right. I've also checked that it's broken in the latest jfx12 as well. I'd appreciate your help in resolving this.
>>> 
>>> Thanks,
>>> Anton.
>>> 
>>>> 
>>>> -- Kevin
>>>> 
>>>> 
>>>> On 11/19/2018 12:17 PM, Anton Tarasov wrote:
>>>>> Hello, JFX team!
>>>>> 
>>>>> We (at JetBrains) faced an issue with WebView after we've moved to an JFX update in JDK8u202. The issue is that WebView stopped loading images referenced by an absolute URL under some circumstances.
>>>>> 
>>>>> Below is a real html content, produced by IDEA markdown viewer. It has lots of style pre-loads and a sample image that it should eventually display. The html is loaded view WebEngine.loadContent(..) but a placeholder text is only displayed - that's the problem that can be reproduce with JDK8u202. However it worked with JDK8u152.
>>>>> 
>>>>> The style references will obviously fail for you, but if you put this html into a file and will load it via WebEngine.load(file:///path/to/file), the image will be shown with no problem (in 8u202 as well).
>>>>> 
>>>>> <html><head><meta http-equiv="Content-Security-Policy" 
>>>>> content="default-src 'none'; script-src 
>>>>> http://localhost:63344/api/markdown-preview/scripts/processLinks.j
>>>>> s?_ijt=ujioejund46k8cmdcsuggbpnf3 
>>>>> http://localhost:63344/api/markdown-preview/scripts/scrollToElemen
>>>>> t.js?_ijt=ujioejund46k8cmdcsuggbpnf3; style-src https: 
>>>>> http://localhost:63344/api/markdown-preview/styles/default.css?_ij
>>>>> t=ujioejund46k8cmdcsuggbpnf3 
>>>>> http://localhost:63344/api/markdown-preview/styles/darcula.css?_ij
>>>>> t=ujioejund46k8cmdcsuggbpnf3 
>>>>> http://localhost:63344/api/markdown-preview/styles/inline.css?_ijt
>>>>> =ujioejund46k8cmdcsuggbpnf3; img-src *; connect-src 'none'; 
>>>>> font-src *; object-src 'none'; media-src 'none'; child-src 
>>>>> 'none';"/><link rel="stylesheet" 
>>>>> href="http://localhost:63344/api/markdown-preview/styles/default.c
>>>>> ss?_ijt=ujioejund46k8cmdcsuggbpnf3" />
>>>>> 
>>>>> <script 
>>>>> src="http://localhost:63344/api/markdown-preview/scripts/processLi
>>>>> nks.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script>
>>>>> <script 
>>>>> src="http://localhost:63344/api/markdown-preview/scripts/scrollToE
>>>>> lement.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script></head><body 
>>>>> md-src-pos="0..89"><p md-src-pos="0..88"><img 
>>>>> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg
>>>>> " alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
>>>>> /></p></body></html>
>>>>> 
>>>>> Then, if you remove all the style loading and leave only the 
>>>>> image, the image will be shown in either way: load(url) or 
>>>>> loadContent (in 8u202)
>>>>> 
>>>>> <html><head></head><body md-src-pos="0..89"><p 
>>>>> md-src-pos="0..88"><img 
>>>>> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg
>>>>> " alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
>>>>> /></p></body></html>
>>>>> 
>>>>> Sorry for not submitting the code, I hope you will easily put it into a real demo (I played with JFX's WebViewApp).
>>>>> 
>>>>> So, could you please advice on what went wrong with it?
>>>>> 
>>>>> With regards,
>>>>> Anton.
>>>> 
>>> 
>> 
> 


From anton.tarasov at jetbrains.com  Tue Nov 20 08:23:16 2018
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Tue, 20 Nov 2018 11:23:16 +0300
Subject: issue with WebView in 8u202
In-Reply-To: <675A3B67-15C7-4A47-BBAE-5B1168CBBDBB@oracle.com>
References: <3c07e0a8-a838-0acb-3f0f-f2e4f8cfc8c7@jetbrains.com>
 <c1d78453-692c-2c38-2044-a8794b9d5572@oracle.com>
 <3f7cdd52-590d-53e6-dc80-92feefdc59b1@jetbrains.com>
 <10bdfde9-50e9-0762-0bf5-bf289e21b838@oracle.com>
 <155bfa15-ab86-e467-39c4-0105f680fdbd@jetbrains.com>
 <675A3B67-15C7-4A47-BBAE-5B1168CBBDBB@oracle.com>
Message-ID: <3574851a-1bef-ea60-1a29-8ff6350baf7c@jetbrains.com>

Hi Arun,

The reason appeared to be quite simple, thank you for the details!

Regards,
Anton.

On 11/20/2018 10:09 AM, Arunprasad Rajkumar wrote:
> Hi Anton,
>
> Looks like this is mostly related to Content Security Policy(CSP)[1] 
> which have got strengthened after recent WebKit upgrades.
>
> I have reduced the given html further(PSB) & I could reproduce the 
> problem with the following html snippet,
>
> <html><head>
> <meta http-equiv='Content-Security-Policy' content='img-src *;?/></head>
> <body>
> <img src='file:///Users/ARAJKUMA/Downloads/penguingun-900x900.jpg' 
> alt='from file:?/>
> <img 
> src='https://betanews.com/wp-content/uploads/2016/04/penguingun-900x900.jpg' 
> alt=?from http:?/>
> </body></html>
>
> In the above html snippet, CSP of img tag is set to load from all 
> except file scheme. It would load img from http: but not from file. If 
> you also want to load from file: scheme, then you must explicitly set 
> that in the CSP header. Something like below,
>
> <html><head>
> <meta http-equiv='Content-Security-Policy' content='img-src file: 
> *;?/></head>
> <body>
> <img src='file:///Users/ARAJKUMA/Downloads/penguingun-900x900.jpg' 
> alt='from file:?/>
> <img 
> src='https://betanews.com/wp-content/uploads/2016/04/penguingun-900x900.jpg' 
> alt=?from http:?/>
> </body></html>
>
> [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
>
> Thanks,
> Arun
>
>> On 20-Nov-2018, at 10:04 AM, Anton Tarasov 
>> <anton.tarasov at jetbrains.com <mailto:anton.tarasov at jetbrains.com>> wrote:
>>
>> Thanks for the catch, Kevin! Seems very likely. Is it the thing 
>> configured at compile-time?
>>
>> Regards,
>> Anton.
>>
>> On 11/20/2018 12:51 AM, Kevin Rushforth wrote:
>>> I can reproduce it and it seems related to Cross-Site-Scripting 
>>> (XSS) protections, which you have enabled in your HTML header with:
>>>
>>> ??? <meta http-equiv="Content-Security-Policy" ...>
>>>
>>> If I remove the 'http-equiv="Content-Security-Policy"' from the 
>>> meta-data then it displays just fine.
>>>
>>> Perhaps Arun or Murali could comment on whether this is a bug or 
>>> not. It seems just as likely to me that it is a feature that didn't 
>>> used to be enabled and now is.
>>>
>>> -- Kevin
>>>
>>>
>>> On 11/19/2018 1:44 PM, Anton Tarasov wrote:
>>>> Hi Kevin,
>>>>
>>>> On 11/20/2018 12:21 AM, Kevin Rushforth wrote:
>>>>> Hi Anton,
>>>>>
>>>>> We'll take a look and see if we can reproduce it. Am I correct in 
>>>>> understanding that the problem only happens with loadContent, 
>>>>> which works on 8u152 and fails on 8u202-ea? And that load from a 
>>>>> file works fine on both 8u152 and 8u202-ea?
>>>>>
>>>> Yes, that's right. I've also checked that it's broken in the latest 
>>>> jfx12 as well. I'd appreciate your help in resolving this.
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>>>
>>>>> -- Kevin
>>>>>
>>>>>
>>>>> On 11/19/2018 12:17 PM, Anton Tarasov wrote:
>>>>>> Hello, JFX team!
>>>>>>
>>>>>> We (at JetBrains) faced an issue with WebView after we've moved 
>>>>>> to an JFX update in JDK8u202. The issue is that WebView stopped 
>>>>>> loading images referenced by an absolute URL under some 
>>>>>> circumstances.
>>>>>>
>>>>>> Below is a real html content, produced by IDEA markdown viewer. 
>>>>>> It has lots of style pre-loads and a sample image that it should 
>>>>>> eventually display. The html is loaded view 
>>>>>> WebEngine.loadContent(..) but a placeholder text is only 
>>>>>> displayed - that's the problem that can be reproduce with 
>>>>>> JDK8u202. However it worked with JDK8u152.
>>>>>>
>>>>>> The style references will obviously fail for you, but if you put 
>>>>>> this html into a file and will load it via 
>>>>>> WebEngine.load(file:///path/to/file), the image will be shown 
>>>>>> with no problem (in 8u202 as well).
>>>>>>
>>>>>> <html><head><meta http-equiv="Content-Security-Policy" 
>>>>>> content="default-src 'none'; script-src 
>>>>>> http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3 
>>>>>> http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3; 
>>>>>> style-src https: 
>>>>>> http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
>>>>>> http://localhost:63344/api/markdown-preview/styles/darcula.css?_ijt=ujioejund46k8cmdcsuggbpnf3 
>>>>>> http://localhost:63344/api/markdown-preview/styles/inline.css?_ijt=ujioejund46k8cmdcsuggbpnf3; 
>>>>>> img-src *; connect-src 'none'; font-src *; object-src 'none'; 
>>>>>> media-src 'none'; child-src 'none';"/><link rel="stylesheet" 
>>>>>> href="http://localhost:63344/api/markdown-preview/styles/default.css?_ijt=ujioejund46k8cmdcsuggbpnf3" 
>>>>>> />
>>>>>>
>>>>>> <script 
>>>>>> src="http://localhost:63344/api/markdown-preview/scripts/processLinks.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script>
>>>>>> <script 
>>>>>> src="http://localhost:63344/api/markdown-preview/scripts/scrollToElement.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script></head><body 
>>>>>> md-src-pos="0..89"><p md-src-pos="0..88"><img 
>>>>>> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
>>>>>> alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
>>>>>> /></p></body></html>
>>>>>>
>>>>>> Then, if you remove all the style loading and leave only the 
>>>>>> image, the image will be shown in either way: load(url) or 
>>>>>> loadContent (in 8u202)
>>>>>>
>>>>>> <html><head></head><body md-src-pos="0..89"><p 
>>>>>> md-src-pos="0..88"><img 
>>>>>> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg" 
>>>>>> alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
>>>>>> /></p></body></html>
>>>>>>
>>>>>> Sorry for not submitting the code, I hope you will easily put it 
>>>>>> into a real demo (I played with JFX's WebViewApp).
>>>>>>
>>>>>> So, could you please advice on what went wrong with it?
>>>>>>
>>>>>> With regards,
>>>>>> Anton.
>>>>>
>>>>
>>>
>>
>


From arunprasad.rajkumar at oracle.com  Tue Nov 20 09:10:34 2018
From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar)
Date: Tue, 20 Nov 2018 14:40:34 +0530
Subject: issue with WebView in 8u202
In-Reply-To: <fa1a6346-7f9f-4d3a-9594-87e4db6a6f24@default>
References: <3c07e0a8-a838-0acb-3f0f-f2e4f8cfc8c7@jetbrains.com>
 <c1d78453-692c-2c38-2044-a8794b9d5572@oracle.com>
 <3f7cdd52-590d-53e6-dc80-92feefdc59b1@jetbrains.com>
 <10bdfde9-50e9-0762-0bf5-bf289e21b838@oracle.com>
 <155bfa15-ab86-e467-39c4-0105f680fdbd@jetbrains.com>
 <675A3B67-15C7-4A47-BBAE-5B1168CBBDBB@oracle.com>
 <fa1a6346-7f9f-4d3a-9594-87e4db6a6f24@default>
Message-ID: <6A2F4AA8-1B82-436D-A406-987F29142035@oracle.com>

Quote mismatch is due to mail client?s auto formatting. For more clarity I have attached the test code as a file. Also the solution which I had suggested is only for WebEngine.loadContent.
-------------- next part --------------


Thanks,
Arun

> On 20-Nov-2018, at 1:44 PM, Murali Billa <murali.billa at oracle.com> wrote:
> 
> Hi Arun,
> 
> Regarding   <meta http-equiv='Content-Security-Policy' content='img-src *;?/>
>               -      In the above html snippet, CSP of img tag is set to load from all except file scheme. 
> 
> I think the above statement is not correct. For me it loads both file and https images with img-src *; (tested in hellowebview and chrome).  I guess  the reason why the 2nd image(https)  is not loaded with above code is there is a mismatch of backquote (?) for alt='from file:?
> Also from spec [1]  img-src *; means  "Images may load from anywhere (note the "*" wildcard)."
> 
> I think to load from file: scheme, there is no need to specify explicitly in the CSP header (apart from "*" wild card)
> 
> Please correct me if im wrong.
> 
> Thanks,
> Murali
> 
> -----Original Message-----
> From: Arunprasad Rajkumar 
> Sent: Tuesday, November 20, 2018 12:39 PM
> To: Anton Tarasov <anton.tarasov at jetbrains.com>
> Cc: openjfx-dev at openjdk.java.net
> Subject: Re: issue with WebView in 8u202
> 
> Hi Anton,
> 
> Looks like this is mostly related to Content Security Policy(CSP)[1] which have got strengthened after recent WebKit upgrades.
> 
> I have reduced the given html further(PSB) & I could reproduce the problem with the following html snippet,
> 
> <html><head>
> <meta http-equiv='Content-Security-Policy' content='img-src *;?/></head> <body> <img src='file:///Users/ARAJKUMA/Downloads/penguingun-900x900.jpg' alt='from file:?/> <img src='https://betanews.com/wp-content/uploads/2016/04/penguingun-900x900.jpg' alt=?from http:?/> </body></html>
> 
> In the above html snippet, CSP of img tag is set to load from all except file scheme. It would load img from http: but not from file. If you also want to load from file: scheme, then you must explicitly set that in the CSP header. Something like below,
> 
> <html><head>
> <meta http-equiv='Content-Security-Policy' content='img-src file: *;?/></head> <body> <img src='file:///Users/ARAJKUMA/Downloads/penguingun-900x900.jpg' alt='from file:?/> <img src='https://betanews.com/wp-content/uploads/2016/04/penguingun-900x900.jpg' alt=?from http:?/> </body></html>
> 
> [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
> 
> Thanks,
> Arun
> 
>> On 20-Nov-2018, at 10:04 AM, Anton Tarasov <anton.tarasov at jetbrains.com> wrote:
>> 
>> Thanks for the catch, Kevin! Seems very likely. Is it the thing configured at compile-time?
>> 
>> Regards,
>> Anton.
>> 
>> On 11/20/2018 12:51 AM, Kevin Rushforth wrote:
>>> I can reproduce it and it seems related to Cross-Site-Scripting (XSS) protections, which you have enabled in your HTML header with:
>>> 
>>>    <meta http-equiv="Content-Security-Policy" ...>
>>> 
>>> If I remove the 'http-equiv="Content-Security-Policy"' from the meta-data then it displays just fine.
>>> 
>>> Perhaps Arun or Murali could comment on whether this is a bug or not. It seems just as likely to me that it is a feature that didn't used to be enabled and now is.
>>> 
>>> -- Kevin
>>> 
>>> 
>>> On 11/19/2018 1:44 PM, Anton Tarasov wrote:
>>>> Hi Kevin,
>>>> 
>>>> On 11/20/2018 12:21 AM, Kevin Rushforth wrote:
>>>>> Hi Anton,
>>>>> 
>>>>> We'll take a look and see if we can reproduce it. Am I correct in understanding that the problem only happens with loadContent, which works on 8u152 and fails on 8u202-ea? And that load from a file works fine on both 8u152 and 8u202-ea?
>>>>> 
>>>> Yes, that's right. I've also checked that it's broken in the latest jfx12 as well. I'd appreciate your help in resolving this.
>>>> 
>>>> Thanks,
>>>> Anton.
>>>> 
>>>>> 
>>>>> -- Kevin
>>>>> 
>>>>> 
>>>>> On 11/19/2018 12:17 PM, Anton Tarasov wrote:
>>>>>> Hello, JFX team!
>>>>>> 
>>>>>> We (at JetBrains) faced an issue with WebView after we've moved to an JFX update in JDK8u202. The issue is that WebView stopped loading images referenced by an absolute URL under some circumstances.
>>>>>> 
>>>>>> Below is a real html content, produced by IDEA markdown viewer. It has lots of style pre-loads and a sample image that it should eventually display. The html is loaded view WebEngine.loadContent(..) but a placeholder text is only displayed - that's the problem that can be reproduce with JDK8u202. However it worked with JDK8u152.
>>>>>> 
>>>>>> The style references will obviously fail for you, but if you put this html into a file and will load it via WebEngine.load(file:///path/to/file), the image will be shown with no problem (in 8u202 as well).
>>>>>> 
>>>>>> <html><head><meta http-equiv="Content-Security-Policy" 
>>>>>> content="default-src 'none'; script-src 
>>>>>> http://localhost:63344/api/markdown-preview/scripts/processLinks.j
>>>>>> s?_ijt=ujioejund46k8cmdcsuggbpnf3 
>>>>>> http://localhost:63344/api/markdown-preview/scripts/scrollToElemen
>>>>>> t.js?_ijt=ujioejund46k8cmdcsuggbpnf3; style-src https: 
>>>>>> http://localhost:63344/api/markdown-preview/styles/default.css?_ij
>>>>>> t=ujioejund46k8cmdcsuggbpnf3 
>>>>>> http://localhost:63344/api/markdown-preview/styles/darcula.css?_ij
>>>>>> t=ujioejund46k8cmdcsuggbpnf3 
>>>>>> http://localhost:63344/api/markdown-preview/styles/inline.css?_ijt
>>>>>> =ujioejund46k8cmdcsuggbpnf3; img-src *; connect-src 'none'; 
>>>>>> font-src *; object-src 'none'; media-src 'none'; child-src 
>>>>>> 'none';"/><link rel="stylesheet" 
>>>>>> href="http://localhost:63344/api/markdown-preview/styles/default.c
>>>>>> ss?_ijt=ujioejund46k8cmdcsuggbpnf3" />
>>>>>> 
>>>>>> <script 
>>>>>> src="http://localhost:63344/api/markdown-preview/scripts/processLi
>>>>>> nks.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script>
>>>>>> <script 
>>>>>> src="http://localhost:63344/api/markdown-preview/scripts/scrollToE
>>>>>> lement.js?_ijt=ujioejund46k8cmdcsuggbpnf3"></script></head><body 
>>>>>> md-src-pos="0..89"><p md-src-pos="0..88"><img 
>>>>>> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg
>>>>>> " alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
>>>>>> /></p></body></html>
>>>>>> 
>>>>>> Then, if you remove all the style loading and leave only the 
>>>>>> image, the image will be shown in either way: load(url) or 
>>>>>> loadContent (in 8u202)
>>>>>> 
>>>>>> <html><head></head><body md-src-pos="0..89"><p 
>>>>>> md-src-pos="0..88"><img 
>>>>>> src="file:///C:/Users/tav/IdeaProjects/DummyProject/src/kitten.jpg
>>>>>> " alt="Kitten" title="A cute kitten" md-src-pos="0..88" 
>>>>>> /></p></body></html>
>>>>>> 
>>>>>> Sorry for not submitting the code, I hope you will easily put it into a real demo (I played with JFX's WebViewApp).
>>>>>> 
>>>>>> So, could you please advice on what went wrong with it?
>>>>>> 
>>>>>> With regards,
>>>>>> Anton.
>>>>> 
>>>> 
>>> 
>> 
> 


From nik_cro at abv.bg  Tue Nov 20 10:30:26 2018
From: nik_cro at abv.bg (Nikola Z.)
Date: Tue, 20 Nov 2018 12:30:26 +0200 (EET)
Subject: Building a 32-bit JavaFX lib
Message-ID: <950633559.1285445.1542709826412@nm51.abv.bg>

I have a project using java 11, since JavaFX no longer officially supports 32-bit variant, is there any possible way for me to build such myself?

From johan.vos at gluonhq.com  Tue Nov 20 10:43:04 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 20 Nov 2018 11:43:04 +0100
Subject: Building a 32-bit JavaFX lib
In-Reply-To: <950633559.1285445.1542709826412@nm51.abv.bg>
References: <950633559.1285445.1542709826412@nm51.abv.bg>
Message-ID: <CABxFH2Fq8G5w2n7waKCg0A5XX=_UnQJvZ5Atctc17xc-Sge2Bw@mail.gmail.com>

We have an internal build for JavaFX 11 on win32 as there were some
customers asking for it. It seems demand for this is bigger than I
expected, so it might make sense we add win32 to the supported list.
There is not much different in building win32 builds, you have to specify
IS_64 is false though.

- Johan

On Tue, Nov 20, 2018 at 11:40 AM Nikola Z. <nik_cro at abv.bg> wrote:

> I have a project using java 11, since JavaFX no longer officially supports
> 32-bit variant, is there any possible way for me to build such myself?
>

From johan.vos at gluonhq.com  Tue Nov 20 12:33:50 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 20 Nov 2018 13:33:50 +0100
Subject: Review request: Long scrolling on mac [JDK-8183399]
In-Reply-To: <CABxFH2Firk8Zca7jBUoMqe-NjeUgqM_CnDHpo3muOBiVxDXXxg@mail.gmail.com>
References: <CABxFH2Firk8Zca7jBUoMqe-NjeUgqM_CnDHpo3muOBiVxDXXxg@mail.gmail.com>
Message-ID: <CABxFH2H1Yz23VSa6rOKp8XoyTh8VVESUzUdzpSX8DuTBSUaMuw@mail.gmail.com>

webrev at http://cr.openjdk.java.net/~jvos/8183399/webrev.00/

On Mon, Nov 19, 2018 at 7:03 PM Johan Vos <johan.vos at gluonhq.com> wrote:

> Please review the fix for issue
> https://bugs.openjdk.java.net/browse/JDK-8183399 (
> https://github.com/javafxports/openjdk-jfx/issues/38) which should be
> fixed with PR #274
> (https://github.com/javafxports/openjdk-jfx/pull/274)
>
> It only affects mac builds.
>
> - Johan
>

From kevin.rushforth at oracle.com  Tue Nov 20 13:55:45 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 20 Nov 2018 05:55:45 -0800
Subject: Building a 32-bit JavaFX lib
In-Reply-To: <950633559.1285445.1542709826412@nm51.abv.bg>
References: <950633559.1285445.1542709826412@nm51.abv.bg>
Message-ID: <be56d65f-b285-f86b-94a2-10d917914308@oracle.com>

You will need a 32-bit JDK in order to do this, which is also not 
supported. The FX build will detect a 32-bit JDK and build 32-bit native 
libs.

-- Kevin


On 11/20/2018 2:30 AM, Nikola Z. wrote:
> I have a project using java 11, since JavaFX no longer officially supports 32-bit variant, is there any possible way for me to build such myself?


From kevin.rushforth at oracle.com  Tue Nov 20 13:58:07 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 20 Nov 2018 05:58:07 -0800
Subject: Review request: Long scrolling on mac [JDK-8183399]
In-Reply-To: <CABxFH2H1Yz23VSa6rOKp8XoyTh8VVESUzUdzpSX8DuTBSUaMuw@mail.gmail.com>
References: <CABxFH2Firk8Zca7jBUoMqe-NjeUgqM_CnDHpo3muOBiVxDXXxg@mail.gmail.com>
 <CABxFH2H1Yz23VSa6rOKp8XoyTh8VVESUzUdzpSX8DuTBSUaMuw@mail.gmail.com>
Message-ID: <b01c9495-150f-1363-e4a6-e1890211d997@oracle.com>

Since this was already reivewed / merged on GitHub there is no need for 
a webrev.

+1 in any case.

-- Kevin


On 11/20/2018 4:33 AM, Johan Vos wrote:
> webrev at http://cr.openjdk.java.net/~jvos/8183399/webrev.00/
>
> On Mon, Nov 19, 2018 at 7:03 PM Johan Vos <johan.vos at gluonhq.com> wrote:
>
>> Please review the fix for issue
>> https://bugs.openjdk.java.net/browse/JDK-8183399 (
>> https://github.com/javafxports/openjdk-jfx/issues/38) which should be
>> fixed with PR #274
>> (https://github.com/javafxports/openjdk-jfx/pull/274)
>>
>> It only affects mac builds.
>>
>> - Johan
>>


From diego.cirujano-cuesta at zeiss.com  Fri Nov 23 13:59:54 2018
From: diego.cirujano-cuesta at zeiss.com (Cirujano Cuesta, Diego)
Date: Fri, 23 Nov 2018 13:59:54 +0000
Subject: Openjfx building - gradle configuration
Message-ID: <BD52C859B4582C47B056539268A11CAE42F99DDF@adefue01sms001>

Hi,

I would like to inform about an error(innecesary step) in the build documentation page: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX

Gradle Wrapper is commited, that means, we do not need to install/configure it. We just need to make use of ./gradlew or ./gradlew.bat

Could someone update the documentation?

Thank you.

Cheers,
Diego

From tristandeloche at gmail.com  Sun Nov 25 01:58:31 2018
From: tristandeloche at gmail.com (Tristan Deloche)
Date: Sun, 25 Nov 2018 01:58:31 +0000
Subject: RFR: 8214069: Use freedesktop's xdg-open to show document on UNIX
 systems
Message-ID: <CAJNDawZKngF+XjS7RNYJun0+gKxS9W+xiQPg9PRYOT1ESrKyhQ@mail.gmail.com>

Hello,

Please review the fix for The Bug Synopsis:
https://bugs.openjdk.java.net/browse/JDK-8214069
https://github.com/javafxports/openjdk-jfx/pull/293

Best regards,
Tristan Deloche

From andreea.plocon at hexagon.com  Tue Nov 27 07:18:32 2018
From: andreea.plocon at hexagon.com (PLOCON Andreea)
Date: Tue, 27 Nov 2018 07:18:32 +0000
Subject: DatePicker size issue
In-Reply-To: <DB7PR06MB438028EAE4F10CA0D234353480DA0@DB7PR06MB4380.eurprd06.prod.outlook.com>
References: <DB7PR06MB438028EAE4F10CA0D234353480DA0@DB7PR06MB4380.eurprd06.prod.outlook.com>
Message-ID: <DB7PR06MB438001055543FADA35B247D480D00@DB7PR06MB4380.eurprd06.prod.outlook.com>

Dear all,

I am currently trying to display a DatePicker using org.openjfx:openjfx:12-ea+2:windows-x64_bin.
Therefor I am using the following code:

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.DatePicker;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

public class DatePickerIssue extends Application {

      @Override
      public void start(Stage stage) {
            VBox vBox = new VBox(new DatePicker());
             stage.setScene(new Scene(vBox));
             stage.show();
      }

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

The DatePicker is not shown completely and as a quick fix I used vBox.setStyle("-fx-padding: 0 0 10 0;").
Could someone please tell me if this is a known issue and how can it be fixed?

Thanks in advance!

Best regards,
Andreea

From johan.vos at gluonhq.com  Tue Nov 27 17:53:32 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 27 Nov 2018 18:53:32 +0100
Subject: Review Request: make caching of native libs more robust
Message-ID: <CABxFH2HXRreAp+vcEK8EAYdYatjLVCjip9xQJF9jk32hx5RVxQ@mail.gmail.com>

An easy to reproduce issue is to change permissions on the cache dir used
by Javafx for storing native libs.
If JavaFX can't write anymore to that cache dir, applications will fail
since all pipelines use native code.

The fix at https://github.com/javafxports/openjdk-jfx/pull/300 makes the
caching mechanism more robust, with a fallback to the tmp dir, and with the
option to always override the location of the cache dir.

Note: In the end, I still hope this is something that can be provide by the
JDK itself (extracting native code from jars or jmods and storing it). For
now, we probably just want to make the system more robust.

- Johan

From ambarish.rapte at oracle.com  Wed Nov 28 12:51:10 2018
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Wed, 28 Nov 2018 04:51:10 -0800 (PST)
Subject: [Openjfx12] RFR : JDK-8189926 : Elevated energy use due to constant
 CPU use on Mac
Message-ID: <48d2ddcf-76aa-4f73-8791-9ce8412bb5ad@default>

Hi All,

 

                Please review this mac specific fix,

                Webrev: http://cr.openjdk.java.net/~arapte/fx/8189926/webrev.05/

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

 

Regards,

Ambarish

From kirill.grouchnikov at gmail.com  Wed Nov 28 15:47:28 2018
From: kirill.grouchnikov at gmail.com (Kirill Grouchnikov)
Date: Wed, 28 Nov 2018 10:47:28 -0500
Subject: Text rendering on Mojave (macOS)
Message-ID: <CAMRG33aPwg7iQbSt0nCB5yL7nnG6hWp1LOMska+g0Qgirm7sHg@mail.gmail.com>

I've sent this one a couple of days ago, and looks like it fell through the
moderation cracks since it had an image attached to it. So sending this
again...

So I spent some time today looking into font rendering on the latest macOS
10.14 (Mojave), I came across https://news.ycombinator.com/item?id=17476873
that says that it has removed the subpixel anti-aliasing setting. There's a
new one under "General" named "Use font smoothing when available".

When that setting is on (which is by default), font rendering in Swing with
the recommended awt.font.desktophints system property is too heavy. Looking
at how
https://github.com/JetBrains/intellij-community/blob/master/platform/editor-ui-api/src/com/intellij/ide/ui/UISettings.kt
is doing it (lines 399-420) it appears that they are setting
KEY_TEXT_ANTIALIASING to VALUE_TEXT_ANTIALIAS_OFF, and doing that in Swing
results in font rendering that is consistent with native apps.

Then I looked at how JavaFX font rendering looks like with locally built
https://github.com/gluonhq/gluon-samples/tree/master/fifty-states

No matter if that new platform setting is off or on, all the texts look
halo'd - zoom in on
https://www.pushing-pixels.org/wp-content/uploads/2018/11/javafx-mojave.png
and see all those pink / light blue pixels around glyphs.

Am I running the demo wrong?

From bourges.laurent at gmail.com  Wed Nov 28 16:31:15 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 28 Nov 2018 17:31:15 +0100
Subject: Text rendering on Mojave (macOS)
In-Reply-To: <CAMRG33aPwg7iQbSt0nCB5yL7nnG6hWp1LOMska+g0Qgirm7sHg@mail.gmail.com>
References: <CAMRG33aPwg7iQbSt0nCB5yL7nnG6hWp1LOMska+g0Qgirm7sHg@mail.gmail.com>
Message-ID: <CAKjRUT6zD_UqOCJD9xMvJ2KoixSJwRDMMsSFH8kQyoUGsghERQ@mail.gmail.com>

Hi,

It remembers me that recently (within 2 months), somebody proposed 2 patchs
to enable freetype LCDFilter for awt & javafx.

Both patches are integrated in jdk12 & jfx 12 ... probably a backport to
jdk11u & jfx11u is in progress...

Please test latest version, first.

My 2 cents,
Laurent

Le mer. 28 nov. 2018 ? 16:49, Kirill Grouchnikov <
kirill.grouchnikov at gmail.com> a ?crit :

> I've sent this one a couple of days ago, and looks like it fell through the
> moderation cracks since it had an image attached to it. So sending this
> again...
>
> So I spent some time today looking into font rendering on the latest macOS
> 10.14 (Mojave), I came across
> https://news.ycombinator.com/item?id=17476873
> that says that it has removed the subpixel anti-aliasing setting. There's a
> new one under "General" named "Use font smoothing when available".
>
> When that setting is on (which is by default), font rendering in Swing with
> the recommended awt.font.desktophints system property is too heavy. Looking
> at how
>
> https://github.com/JetBrains/intellij-community/blob/master/platform/editor-ui-api/src/com/intellij/ide/ui/UISettings.kt
> is doing it (lines 399-420) it appears that they are setting
> KEY_TEXT_ANTIALIASING to VALUE_TEXT_ANTIALIAS_OFF, and doing that in Swing
> results in font rendering that is consistent with native apps.
>
> Then I looked at how JavaFX font rendering looks like with locally built
> https://github.com/gluonhq/gluon-samples/tree/master/fifty-states
>
> No matter if that new platform setting is off or on, all the texts look
> halo'd - zoom in on
> https://www.pushing-pixels.org/wp-content/uploads/2018/11/javafx-mojave.png
> and see all those pink / light blue pixels around glyphs.
>
> Am I running the demo wrong?
>

From philip.race at oracle.com  Wed Nov 28 17:02:42 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 28 Nov 2018 09:02:42 -0800
Subject: Text rendering on Mojave (macOS)
In-Reply-To: <CAKjRUT6zD_UqOCJD9xMvJ2KoixSJwRDMMsSFH8kQyoUGsghERQ@mail.gmail.com>
References: <CAMRG33aPwg7iQbSt0nCB5yL7nnG6hWp1LOMska+g0Qgirm7sHg@mail.gmail.com>
 <CAKjRUT6zD_UqOCJD9xMvJ2KoixSJwRDMMsSFH8kQyoUGsghERQ@mail.gmail.com>
Message-ID: <26180eba-d007-42a2-3de1-21469a86e3f7@oracle.com>

freetype is not used at all by FX on Mac and is used by JDK *only*
for dynamically loaded fonts including Type 1 fonts. All platform fonts
are rendered via the platform renderer by both toolkits.

So the freetype filter isn't relevant here.

It is possible that along with removing sub-pixel AA as a user-settable 
option,
Apple stopped caring so much about filtering the sub-pixel text and removed
some setting that said how by much to reduce the fringing.

I can quite believe that Apple's position is that 1) ios doesn't support it,
2) hidpi displays are all they ship today, 3) LCD complicates caches + 
pipelines
although we've all managed to make it work for many years ...

I suppose we'll have to look at matching what they are doing but as many
folks on that thread noted it is a quality loss on non-retina displays - 
there's
a reason sub-pixel text was introduced and it doesn't go away until ALL
displays are hi-dpi. So if there's a way that keeps it for lo-res 
displays I think
we'd want to do that even if Apple don't.

-phil.

On 11/28/18 8:31 AM, Laurent Bourg?s wrote:
> Hi,
>
> It remembers me that recently (within 2 months), somebody proposed 2 patchs
> to enable freetype LCDFilter for awt & javafx.
>
> Both patches are integrated in jdk12 & jfx 12 ... probably a backport to
> jdk11u & jfx11u is in progress...
>
> Please test latest version, first.
>
> My 2 cents,
> Laurent
>
> Le mer. 28 nov. 2018 ? 16:49, Kirill Grouchnikov <
> kirill.grouchnikov at gmail.com> a ?crit :
>
>> I've sent this one a couple of days ago, and looks like it fell through the
>> moderation cracks since it had an image attached to it. So sending this
>> again...
>>
>> So I spent some time today looking into font rendering on the latest macOS
>> 10.14 (Mojave), I came across
>> https://news.ycombinator.com/item?id=17476873
>> that says that it has removed the subpixel anti-aliasing setting. There's a
>> new one under "General" named "Use font smoothing when available".
>>
>> When that setting is on (which is by default), font rendering in Swing with
>> the recommended awt.font.desktophints system property is too heavy. Looking
>> at how
>>
>> https://github.com/JetBrains/intellij-community/blob/master/platform/editor-ui-api/src/com/intellij/ide/ui/UISettings.kt
>> is doing it (lines 399-420) it appears that they are setting
>> KEY_TEXT_ANTIALIASING to VALUE_TEXT_ANTIALIAS_OFF, and doing that in Swing
>> results in font rendering that is consistent with native apps.
>>
>> Then I looked at how JavaFX font rendering looks like with locally built
>> https://github.com/gluonhq/gluon-samples/tree/master/fifty-states
>>
>> No matter if that new platform setting is off or on, all the texts look
>> halo'd - zoom in on
>> https://www.pushing-pixels.org/wp-content/uploads/2018/11/javafx-mojave.png
>> and see all those pink / light blue pixels around glyphs.
>>
>> Am I running the demo wrong?
>>


From john at status6.com  Wed Nov 28 19:16:07 2018
From: john at status6.com (John Neffenger)
Date: Wed, 28 Nov 2018 11:16:07 -0800
Subject: Text rendering on Mojave (macOS)
In-Reply-To: <CAMRG33aPwg7iQbSt0nCB5yL7nnG6hWp1LOMska+g0Qgirm7sHg@mail.gmail.com>
References: <CAMRG33aPwg7iQbSt0nCB5yL7nnG6hWp1LOMska+g0Qgirm7sHg@mail.gmail.com>
Message-ID: <96001832-030b-3203-c3b8-20d20f28cd62@status6.com>

On 11/28/18 7:47 AM, Kirill Grouchnikov wrote:
> No matter if that new platform setting is off or on, all the texts look
> halo'd - zoom in on
> https://www.pushing-pixels.org/wp-content/uploads/2018/11/javafx-mojave.png
> and see all those pink / light blue pixels around glyphs.

The text in that image, when magnified, looks just like the unfiltered 
sub-pixel anti-aliasing we fixed for JavaFX on Linux. See the section 
called "Actual Result" here:

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

There are more samples under "ClearType Methods Enabled" here:

https://github.com/jgneff/openjdk-freetype/wiki/OpenJFX-FreeType-Tests#cleartype-methods-enabled

I'll check whether I see the same thing after I upgrade my Mac to 
Mojave. I'm currently still on macOS High Sierra.

John

From ambarish.rapte at oracle.com  Fri Nov 30 06:16:15 2018
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Thu, 29 Nov 2018 22:16:15 -0800 (PST)
Subject: [openjfx12] RFR : 8214508 : [TestBug] [Canvas] Add missing test image.
Message-ID: <a52b6aab-b048-45ed-88c1-b7af21e3e9d9@default>

Hi,

Please review this correction fix,

Webrev: http://cr.openjdk.java.net/~arapte/fx/8204060/8214508/webrev.00/

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

 

Regards,

Ambarish

From abye at 8thlight.com  Fri Nov 30 10:43:16 2018
From: abye at 8thlight.com (Ashley Bye)
Date: Fri, 30 Nov 2018 10:43:16 +0000
Subject: org.openjfx:javafx-fxml:11 is empty module
Message-ID: <CADeu5CSmUmfiV1RqAMOi9zZfxY4XE1AXQVz0CPoB1EhZ5=jjNA@mail.gmail.com>

I'm trying to import the JavaFX FXML module into a project in IntelliJ.
However, none of the expected classes, e.g. FXMLLoader, are available. When
I look in the external library, the javafx-fxml dependency is empty except
for the MANIFEST.MF in META-INF. I'm either depending on the wrong thing or
there is a problem, but since I can't find any other reference to this
problem, I suspect it's me. Any help would be appreciated.

Ashley