Re: Draft JEP for new Packaging Tool (replacement for javapackager)

[Weiqi Gao]

You are right.  Here's an updated version of the app that take into account
the time before Main::main() is invoked.

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

public class Main extends Application {
private static long t0;
private static long t1;
private static long t2;
private static long t3;
private static long t4;

public void start(Stage stage) {
t2 = System.currentTimeMillis();
Label l0 = new Label("java: " + t0);
Label l1 = new Label("main: " + (t1 - t0));
Label l2 = new Label("start: " + (t2 - t1) + ", " + (t2 - t0));
Label l3 = new Label("");
Label l4 = new Label("");
VBox vbox = new VBox(l0, l1, l2, l3, l4);
Scene scene = new Scene(vbox);
stage.setScene(scene);
stage.setTitle("Timing Demo");
stage.setOnShowing(e -> {
t3 = System.currentTimeMillis();
l3.setText("showing: " + (t3 - t2) + ", " + (t3 - t0));
});
stage.setOnShown(e -> {
t4 = System.currentTimeMillis();
l4.setText("shown: " + (t4 - t3) + ", " + (t4 - t0));
});
stage.show();
}

public static void main(String[] args) {
t0 = Long.parseLong(args[0])/100;
t1 = System.currentTimeMillis();
launch(args);
}
}

Invoke it with the command line

java Main `date +%s%N`

This seems to add 500 milliseconds to the time.  A screenshot is attached.

If I go really minimalist and not do all the Labels, and print the numbers
to the console instead, the number goes down to 750-800: 787, 782, 778,
790, 748, 747, 777, 775, 763, 785.

Here's one of those invocations:

$ java Main1 `date +%s%N`
1528225502595
494
519
658
785

Beat Regards,
--
Weiqi Gao
weiqi...@gmail.com

On Tue, Jun 5, 2018 at 12:53 PM, Mario Ivankovits 
wrote:

> Hi!
>
> Just for the records: My test included the JVM startup time. Yours start
> counting in main() where the JVM is already up - and probably some of the
> classpath scanning already took place because of the inheritance from
> „javafx.application.Application“ .
> Your test shows „showing: 298 shown: 468“ on my machine.
>
> A „native“ splash screen usually should start up at the very first, before
> the JVM starts.
>
>
> Best regards,
> Mario
>
>
> > Am 05.06.2018 um 19:04 schrieb Weiqi Gao :
> >
> > Here's a more accurate (but still rough) timing application:
> >
> > import javafx.application.Application;
> > import javafx.stage.Stage;
> > import javafx.scene.Scene;
> > import javafx.scene.control.*;
> > import javafx.scene.layout.*;
> >
> > public class Main extends Application {
> >private static long t1;
> >private static long t2;
> >private static long t3;
> >private static long t4;
> >
> >public void start(Stage stage) {
> >t2 = System.currentTimeMillis();
> >Label l1 = new Label("main:" + t1);
> >Label l2 = new Label("start:   " + (t2 - t1));
> >Label l3 = new Label("");
> >Label l4 = new Label("");
> >VBox vbox = new VBox(l1, l2, l3, l4);
> >Scene scene = new Scene(vbox);
> >stage.setScene(scene);
> >stage.setTitle("Timing Demo");
> >stage.setOnShowing(e -> {
> >t3 = System.currentTimeMillis();
> >l3.setText("showing: " + (t3 - t2) + ", " + (t3 - t1));
> >});
> >stage.setOnShown(e -> {
> >t4 = System.currentTimeMillis();
> >l4.setText("shown:   " + (t4 - t3) + ", " + (t4 - t1));
> >});
> >stage.show();
> >}
> >
> >public static void main(String[] args) {
> >t1 = System.currentTimeMillis();
> >launch(args);
> >}
> > }
> >
> > The result of running it on my Dell laptop with Intel Core i7-6820HQ
> > @2.70GHz,CPU and NVIDIA Quadro M1000M display adapter is attached:
> >
> > Essentially, it took less than half a second for a dead simple JavaFX
> Stage
> > to be visible.
> >
> > Here's the timing number for 10 consecutive runs: 422, 440, 426, 442,
> 418,
> > 441, 432, 444, 470, 453
> >
> > --
> > Weiqi Gao
> > weiqi...@gmail.com
> >
> > On Tue, Jun 5, 2018 at 10:46 AM, Scott Palmer 
> wrote:
> >
> >> Yes, my only comment was that if we can get a window up using standard
> Java
> >> GUI frameworks fast enough, then the complexity of adding splashscreen
> >> support to the launcher isn't justified.
> >> Mario's example shows that is it 1-2 seconds to get a window up.  That
> is a
> >> bit high.  If it was under 1s then I would suggest not bothering, it
> isn't,
> >> so keep it on the list of desired features.
> >>
> >> Scott
> >>
> >> On Tue, Jun 5, 2018 at 8:21 AM Pedro Duque Vieira <
> >> pedro.duquevie...@gmail.com> wrote:
> >>
> >>> Sorry, perhaps it was I who misunderstood the debate..
> >>>
> >>> On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus  wrote:
> >>>
>  Maybe I 

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

[Mario Ivankovits]

Hi!

Just for the records: My test included the JVM startup time. Yours start 
counting in main() where the JVM is already up - and probably some of the 
classpath scanning already took place because of the inheritance from 
„javafx.application.Application“ .
Your test shows „showing: 298 shown: 468“ on my machine.

A „native“ splash screen usually should start up at the very first, before the 
JVM starts.


Best regards,
Mario


> Am 05.06.2018 um 19:04 schrieb Weiqi Gao :
> 
> Here's a more accurate (but still rough) timing application:
> 
> import javafx.application.Application;
> import javafx.stage.Stage;
> import javafx.scene.Scene;
> import javafx.scene.control.*;
> import javafx.scene.layout.*;
> 
> public class Main extends Application {
>private static long t1;
>private static long t2;
>private static long t3;
>private static long t4;
> 
>public void start(Stage stage) {
>t2 = System.currentTimeMillis();
>Label l1 = new Label("main:" + t1);
>Label l2 = new Label("start:   " + (t2 - t1));
>Label l3 = new Label("");
>Label l4 = new Label("");
>VBox vbox = new VBox(l1, l2, l3, l4);
>Scene scene = new Scene(vbox);
>stage.setScene(scene);
>stage.setTitle("Timing Demo");
>stage.setOnShowing(e -> {
>t3 = System.currentTimeMillis();
>l3.setText("showing: " + (t3 - t2) + ", " + (t3 - t1));
>});
>stage.setOnShown(e -> {
>t4 = System.currentTimeMillis();
>l4.setText("shown:   " + (t4 - t3) + ", " + (t4 - t1));
>});
>stage.show();
>}
> 
>public static void main(String[] args) {
>t1 = System.currentTimeMillis();
>launch(args);
>}
> }
> 
> The result of running it on my Dell laptop with Intel Core i7-6820HQ
> @2.70GHz,CPU and NVIDIA Quadro M1000M display adapter is attached:
> 
> Essentially, it took less than half a second for a dead simple JavaFX Stage
> to be visible.
> 
> Here's the timing number for 10 consecutive runs: 422, 440, 426, 442, 418,
> 441, 432, 444, 470, 453
> 
> --
> Weiqi Gao
> weiqi...@gmail.com
> 
> On Tue, Jun 5, 2018 at 10:46 AM, Scott Palmer  wrote:
> 
>> Yes, my only comment was that if we can get a window up using standard Java
>> GUI frameworks fast enough, then the complexity of adding splashscreen
>> support to the launcher isn't justified.
>> Mario's example shows that is it 1-2 seconds to get a window up.  That is a
>> bit high.  If it was under 1s then I would suggest not bothering, it isn't,
>> so keep it on the list of desired features.
>> 
>> Scott
>> 
>> On Tue, Jun 5, 2018 at 8:21 AM Pedro Duque Vieira <
>> pedro.duquevie...@gmail.com> wrote:
>> 
>>> Sorry, perhaps it was I who misunderstood the debate..
>>> 
>>> On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus  wrote:
>>> 
 Maybe I misunderstood the question but to my opinion the real question
>> is
 whether the new java packager has to provide the support for a splash
 screen
 or not. This has nothing to do with the question whether applications
 should
 have a splash screen or not because if we find that todays Java is fast
 enough
 to display a simple window in less than a second or so, then the Java
>> GUI
 (Swing or JavaFX) could provide a splash screen itself. There is then
>> no
 need
 for an additional mechanism provided my the packager.
 
 Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira:
 
 Hi,
> 
> I agree with Johan and others, a splash screen is valuable and needed.
> 
> Microsoft applications that run on Windows itself (think Word, Excel,
> etc),
> they have a splash screen, Intelllij has a splash screen (it's swing
>>> based
> AFAIK), etc.. If a Microsoft application running on its own operating
> system needs a splash screen then chances are pretty high that there
>>> will
> be Java apps that'll need a splash screen.
> 
> Cheers,
> 
> 
> 
 
>>> 
>>> 
>>> --
>>> Pedro Duque Vieira
>>> 
>> 
> 
> 
> 
> -- 
> Weiqi Gao (高为奇)
> weiqi...@gmail.com
> http://weiqigao.blogspot.com/

Re: launching JavaFX in 11

[Kevin Rushforth]

Hi Johan,

The intention is to launch using --module-path

    java --module-path path-to-sdk/javafx-sdk-11/lib ...

For non-modular applications you also need to add the modules to the 
module graph, for example:


    java --module-path path-to-sdk/javafx-sdk-11/lib --add-modules 
javafx.fxml,javafx.controls ...


You say that running an app from maven works fine. Have you verified 
that the jar files you publish to Maven include a module-info.class file 
in each modular jar?


I suspect that many things could be made to work with javafx modules on 
the classpath instead of the module path, but I don't really recommend 
that. I suspect there will be a few things that won't work without some 
modifications. I think effort would be better spent getting everything 
to work with javafx.* modules as proper named modules.


-- Kevin


On 6/5/2018 6:40 AM, Johan Vos wrote:

Hi,

I'm a bit confused on the different options for launching JavaFX
applications with the latest Java 11 code.
When running an app from maven, it worked fine. Maven uses the classpath
and not the module path, so I assumed that running the same app using

java -cp all-javafx-jars Main

would work too. But it doesn't. The error I got is this:

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

This error comes from sun.launcher.LauncherHelper in the java.base module.
The reason for this is that the Main app extends Application and has a main
method. If that is the case, the LauncherHelper will check for the
javafx.graphics module to be present as a named module:

Optional om =
ModuleLayer.boot().findModule(JAVAFX_GRAPHICS_MODULE_NAME);

If that module is not present, the launch is aborted.
Hence, having the JavaFX libraries as jars on the classpath is not allowed
in this case.

Fair, but that doesn't explain why it works via maven. The reason is that
maven doesn't start a new VM process, hence the main class is in this
case  org.codehaus.plexus.classworlds.launcher.Launcher which does not
extend Application, hence it doesn't do the check on javafx.graphics module
to be present as a named module, and when the required jars (including
native code) are on the classpath, it works fine.

I thought the check on the main class extending
javafx.application.Application was removed from the core JDK, but it is
still there, so I understand why it works using maven and fails using a
standalone java invocation.

While I fully agree the goal is to have the JavaFX modules as named modules
on the module path, I think this will create confusion. A simple workaround
is to have a separate main class that doesn't extend Application, but that
seems a real dirty solution.

But maybe I'm missing something?

- Johan

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

[Weiqi Gao]

Here's a more accurate (but still rough) timing application:

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

public class Main extends Application {
private static long t1;
private static long t2;
private static long t3;
private static long t4;

public void start(Stage stage) {
t2 = System.currentTimeMillis();
Label l1 = new Label("main:" + t1);
Label l2 = new Label("start:   " + (t2 - t1));
Label l3 = new Label("");
Label l4 = new Label("");
VBox vbox = new VBox(l1, l2, l3, l4);
Scene scene = new Scene(vbox);
stage.setScene(scene);
stage.setTitle("Timing Demo");
stage.setOnShowing(e -> {
t3 = System.currentTimeMillis();
l3.setText("showing: " + (t3 - t2) + ", " + (t3 - t1));
});
stage.setOnShown(e -> {
t4 = System.currentTimeMillis();
l4.setText("shown:   " + (t4 - t3) + ", " + (t4 - t1));
});
stage.show();
}

public static void main(String[] args) {
t1 = System.currentTimeMillis();
launch(args);
}
}

The result of running it on my Dell laptop with Intel Core i7-6820HQ
@2.70GHz,CPU and NVIDIA Quadro M1000M display adapter is attached:

Essentially, it took less than half a second for a dead simple JavaFX Stage
to be visible.

Here's the timing number for 10 consecutive runs: 422, 440, 426, 442, 418,
441, 432, 444, 470, 453

--
Weiqi Gao
weiqi...@gmail.com

On Tue, Jun 5, 2018 at 10:46 AM, Scott Palmer  wrote:

> Yes, my only comment was that if we can get a window up using standard Java
> GUI frameworks fast enough, then the complexity of adding splashscreen
> support to the launcher isn't justified.
> Mario's example shows that is it 1-2 seconds to get a window up.  That is a
> bit high.  If it was under 1s then I would suggest not bothering, it isn't,
> so keep it on the list of desired features.
>
> Scott
>
> On Tue, Jun 5, 2018 at 8:21 AM Pedro Duque Vieira <
> pedro.duquevie...@gmail.com> wrote:
>
> >  Sorry, perhaps it was I who misunderstood the debate..
> >
> > On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus  wrote:
> >
> > > Maybe I misunderstood the question but to my opinion the real question
> is
> > > whether the new java packager has to provide the support for a splash
> > > screen
> > > or not. This has nothing to do with the question whether applications
> > > should
> > > have a splash screen or not because if we find that todays Java is fast
> > > enough
> > > to display a simple window in less than a second or so, then the Java
> GUI
> > > (Swing or JavaFX) could provide a splash screen itself. There is then
> no
> > > need
> > > for an additional mechanism provided my the packager.
> > >
> > > Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira:
> > >
> > > Hi,
> > >>
> > >> I agree with Johan and others, a splash screen is valuable and needed.
> > >>
> > >> Microsoft applications that run on Windows itself (think Word, Excel,
> > >> etc),
> > >> they have a splash screen, Intelllij has a splash screen (it's swing
> > based
> > >> AFAIK), etc.. If a Microsoft application running on its own operating
> > >> system needs a splash screen then chances are pretty high that there
> > will
> > >> be Java apps that'll need a splash screen.
> > >>
> > >> Cheers,
> > >>
> > >>
> > >>
> > >
> >
> >
> > --
> > Pedro Duque Vieira
> >
>



-- 
Weiqi Gao (高为奇)
weiqi...@gmail.com
http://weiqigao.blogspot.com/

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

[Scott Palmer]

Yes, my only comment was that if we can get a window up using standard Java
GUI frameworks fast enough, then the complexity of adding splashscreen
support to the launcher isn't justified.
Mario's example shows that is it 1-2 seconds to get a window up.  That is a
bit high.  If it was under 1s then I would suggest not bothering, it isn't,
so keep it on the list of desired features.

Scott

On Tue, Jun 5, 2018 at 8:21 AM Pedro Duque Vieira <
pedro.duquevie...@gmail.com> wrote:

>  Sorry, perhaps it was I who misunderstood the debate..
>
> On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus  wrote:
>
> > Maybe I misunderstood the question but to my opinion the real question is
> > whether the new java packager has to provide the support for a splash
> > screen
> > or not. This has nothing to do with the question whether applications
> > should
> > have a splash screen or not because if we find that todays Java is fast
> > enough
> > to display a simple window in less than a second or so, then the Java GUI
> > (Swing or JavaFX) could provide a splash screen itself. There is then no
> > need
> > for an additional mechanism provided my the packager.
> >
> > Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira:
> >
> > Hi,
> >>
> >> I agree with Johan and others, a splash screen is valuable and needed.
> >>
> >> Microsoft applications that run on Windows itself (think Word, Excel,
> >> etc),
> >> they have a splash screen, Intelllij has a splash screen (it's swing
> based
> >> AFAIK), etc.. If a Microsoft application running on its own operating
> >> system needs a splash screen then chances are pretty high that there
> will
> >> be Java apps that'll need a splash screen.
> >>
> >> Cheers,
> >>
> >>
> >>
> >
>
>
> --
> Pedro Duque Vieira
>

launching JavaFX in 11

[Johan Vos]

Hi,

I'm a bit confused on the different options for launching JavaFX
applications with the latest Java 11 code.
When running an app from maven, it worked fine. Maven uses the classpath
and not the module path, so I assumed that running the same app using

java -cp all-javafx-jars Main

would work too. But it doesn't. The error I got is this:

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

This error comes from sun.launcher.LauncherHelper in the java.base module.
The reason for this is that the Main app extends Application and has a main
method. If that is the case, the LauncherHelper will check for the
javafx.graphics module to be present as a named module:

Optional om =
ModuleLayer.boot().findModule(JAVAFX_GRAPHICS_MODULE_NAME);

If that module is not present, the launch is aborted.
Hence, having the JavaFX libraries as jars on the classpath is not allowed
in this case.

Fair, but that doesn't explain why it works via maven. The reason is that
maven doesn't start a new VM process, hence the main class is in this
case  org.codehaus.plexus.classworlds.launcher.Launcher which does not
extend Application, hence it doesn't do the check on javafx.graphics module
to be present as a named module, and when the required jars (including
native code) are on the classpath, it works fine.

I thought the check on the main class extending
javafx.application.Application was removed from the core JDK, but it is
still there, so I understand why it works using maven and fails using a
standalone java invocation.

While I fully agree the goal is to have the JavaFX modules as named modules
on the module path, I think this will create confusion. A simple workaround
is to have a separate main class that doesn't extend Application, but that
seems a real dirty solution.

But maybe I'm missing something?

- Johan

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

[Pedro Duque Vieira]

 Sorry, perhaps it was I who misunderstood the debate..

On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus  wrote:

> Maybe I misunderstood the question but to my opinion the real question is
> whether the new java packager has to provide the support for a splash
> screen
> or not. This has nothing to do with the question whether applications
> should
> have a splash screen or not because if we find that todays Java is fast
> enough
> to display a simple window in less than a second or so, then the Java GUI
> (Swing or JavaFX) could provide a splash screen itself. There is then no
> need
> for an additional mechanism provided my the packager.
>
> Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira:
>
> Hi,
>>
>> I agree with Johan and others, a splash screen is valuable and needed.
>>
>> Microsoft applications that run on Windows itself (think Word, Excel,
>> etc),
>> they have a splash screen, Intelllij has a splash screen (it's swing based
>> AFAIK), etc.. If a Microsoft application running on its own operating
>> system needs a splash screen then chances are pretty high that there will
>> be Java apps that'll need a splash screen.
>>
>> Cheers,
>>
>>
>>
>


-- 
Pedro Duque Vieira

Re: Removal of apps/scenebuilder from OpenJFX repo

[Johan Vos]

I wasn't entirely correct. There are 2 changesets that are not in SB9 but
that will be part of SB 10:

https://github.com/gluonhq/scenebuilder/commit/88f89eb674110ba62d26aec9e6683fc5577bc1ce

https://github.com/gluonhq/scenebuilder/commit/a051b9e52a65b918a8711071c9afc8c08f7a3c30

- Johan


On Tue, Jun 5, 2018 at 9:56 AM Johan Vos  wrote:

> Sorry, I missed this question.
> We incorporated the changes that were in OpenJFX 9 into the butbucket repo
> and they are part of the Gluon Scene Builder 9 release.
>
> - Johan
>
> On Tue, Mar 13, 2018 at 10:17 PM Michael Paus  wrote:
>
>> How will these changes then be synchronized with the work Gluon is doing
>> for the version
>> distributed by them? Do they work on the same repo?
>>
>> Am 12.03.18 um 23:25 schrieb Kevin Rushforth:
>> > Hi Florian,
>> >
>> > By way of update, after thinking about this for a week (and getting
>> > some offline feedback), I no longer propose doing this -- at least not
>> > for the short-mid term. I've retargeted this RFE to tbd_major and
>> > lowered the priority to P4.
>> >
>> > Having said that, we don't have any plans to modify SceneBuilder, but
>> > will happily accept contributions.
>> >
>> > -- Kevin
>> >
>> >
>> > Florian Brunner wrote:
>> >> OK, this still comes a bit as a surprise as the source code has been
>> >> kept in the repo and was not just provided as a ZIP file.
>> >>
>> >> I'm currently working on a tool based on the SceneBuilder Kit. I
>> >> needed to work on the code a bit and was planning to donate the code
>> >> back to OpenJFX once released, as I was under the impression OpenJFX
>> >> would serve as the master / upstream-repo for all SceneBuilder forks.
>> >> I was also under the impression that OpenJFX at least would make sure
>> >> the code works with any new JDK / JavaFX version and hoped it would
>> >> get support for new controls, if any were added to JavaFX.
>> >>
>> >> -Florian
>> >>
>> >> Am Freitag, 2. März 2018, 09:12:15 CET schrieb Kevin Rushforth:
>> >>> I filed the following JBS isuse to remova the SceneBuilder sources
>> >>> from the OpenJFX repo.
>> >>>
>> >>> https://bugs.openjdk.java.net/browse/JDK-8198961
>> >>>
>> >>> As mentioned in the Description of that issue, the OpenJFX repo
>> >>> contains the source code for a no-longer-maintained version of the
>> >>> SceneBuilder tool. Active development on SceneBuilder in the OpenJFX
>> >>> repo was stopped over three years ago. Since that time, the only
>> >>> changes have been either jigsaw-related changes to keep it buildable
>> >>> and runnable, or global changes that happened to touch some of the
>> >>> files in apps/scenebuilder.
>> >>>
>> >>> A fork of SceneBuilder is maintained by Gluon, so anyone wanting to
>> >>> get the latest SceneBuilder should go there.
>> >>>
>> >>> Before I proceed, I wanted to poll the list to see whether anyone
>> >>> has a concern with this. I don't plan to take any action for at
>> >>> least a week.
>> >>>
>> >>> -- Kevin
>> >>>
>> >>>
>> >>
>> >>
>>
>>

Re: Removal of apps/scenebuilder from OpenJFX repo

[Johan Vos]

Hi Sverre,

That is true, we are moving Scene Builder to GitHub. It was a labour
intensive process as we looked into PR's and issues and history etc, but
it's almost done now.

While the process doesn't change, we understood most developers prefer to
work with github for these kinds of open-source projects, so we hope to
increase contributions and feedback.

We are about to release Scene Builder 10 and then the focus is of course on
Scene Builder 11.

- Johan

On Tue, Jun 5, 2018 at 12:12 AM Sverre Moe  wrote:

> Looks like Gluon has moved SceneBuilder from Bitbucket for GitHub.
> https://github.com/gluonhq/scenebuilder
> I like this move. GitHub is much better to work with.
>
>
> Den fre. 27. apr. 2018 kl. 13:31 skrev Sverre Moe :
> >
> > I would like to hear from Gluon about their work on SceneBuilder.
> > Do they have any plans for improve on SceneBuilder, both bug fixed and
> > new features?
> >
> > I guess Gluon only work on their own fork of SceneBuilder, but do they
> > send changes back to the OpenJFX repository?
> >
> > We have migrated our application from Swing to JavaFX and have thus
> > begun to use SceneBuilder. I therefor hope it will be actively
> > maintained further.
> >
> > How can we the community contribute to the continued development of
> > SceneBuilder.
> > Should we work against the OpenJFX SceneBuilder or the Gluon
> SceneBuilder?
> > https://bitbucket.org/gluon-oss/scenebuilder
> >
> https://github.com/javafxports/openjdk-jfx/tree/develop/apps/scenebuilder
> >
> > /Sverre
> >
> >
> > 2018-03-13 22:11 GMT+01:00 Kevin Rushforth :
> > > That will be a question for Gluon.
> > >
> > > -- Kevin
> > >
> > >
> > >
> > > Michael Paus wrote:
> > >>
> > >> How will these changes then be synchronized with the work Gluon is
> doing
> > >> for the version
> > >> distributed by them? Do they work on the same repo?
> > >>
> > >> Am 12.03.18 um 23:25 schrieb Kevin Rushforth:
> > >>>
> > >>> Hi Florian,
> > >>>
> > >>> By way of update, after thinking about this for a week (and getting
> some
> > >>> offline feedback), I no longer propose doing this -- at least not
> for the
> > >>> short-mid term. I've retargeted this RFE to tbd_major and lowered the
> > >>> priority to P4.
> > >>>
> > >>> Having said that, we don't have any plans to modify SceneBuilder, but
> > >>> will happily accept contributions.
> > >>>
> > >>> -- Kevin
> > >>>
> > >>>
> > >>> Florian Brunner wrote:
> > 
> >  OK, this still comes a bit as a surprise as the source code has been
> >  kept in the repo and was not just provided as a ZIP file.
> > 
> >  I'm currently working on a tool based on the SceneBuilder Kit. I
> needed
> >  to work on the code a bit and was planning to donate the code back
> to
> >  OpenJFX once released, as I was under the impression OpenJFX would
> serve as
> >  the master / upstream-repo for all SceneBuilder forks. I was also
> under the
> >  impression that OpenJFX at least would make sure the code works
> with any new
> >  JDK / JavaFX version and hoped it would get support for new
> controls, if any
> >  were added to JavaFX.
> > 
> >  -Florian
> > 
> >  Am Freitag, 2. März 2018, 09:12:15 CET schrieb Kevin Rushforth:
> > >
> > > I filed the following JBS isuse to remova the SceneBuilder sources
> from
> > > the OpenJFX repo.
> > >
> > > https://bugs.openjdk.java.net/browse/JDK-8198961
> > >
> > > As mentioned in the Description of that issue, the OpenJFX repo
> > > contains the source code for a no-longer-maintained version of the
> > > SceneBuilder tool. Active development on SceneBuilder in the
> OpenJFX repo
> > > was stopped over three years ago. Since that time, the only
> changes have
> > > been either jigsaw-related changes to keep it buildable and
> runnable, or
> > > global changes that happened to touch some of the files in
> > > apps/scenebuilder.
> > >
> > > A fork of SceneBuilder is maintained by Gluon, so anyone wanting
> to get
> > > the latest SceneBuilder should go there.
> > >
> > > Before I proceed, I wanted to poll the list to see whether anyone
> has a
> > > concern with this. I don't plan to take any action for at least a
> week.
> > >
> > > -- Kevin
> > >
> > >
> > 
> > 
> > >>
> > >
>

Re: OpenGL deprecated in OS-X

[Michael Paus]

Hi,
in the light of this announcement it might be a good idea to consider ANGLE

again as a unified rendering platform for JavaFX. Do not try to reinvent 
the wheel

again. The JavaFX community is much too small to always do its own thing.
Relying on a rendering technology which is used by giants like Google 
and Mozilla

is probably a better idea than once again cooking our own soup. Using ANGLE
should also make it possible to finally support WebGL in WebView.
Michael


Am 04.06.18 um 22:51 schrieb Tom Schindl:

Hi,

I don‘t know what the Apple guys are smoking but they just deprecated OpenGL. 
The question is what does this mean for JavaFX.

See https://developer.apple.com/macos/whats-new/

Tom

Von meinem iPhone gesendet

Re: Removal of apps/scenebuilder from OpenJFX repo

[Johan Vos]

Sorry, I missed this question.
We incorporated the changes that were in OpenJFX 9 into the butbucket repo
and they are part of the Gluon Scene Builder 9 release.

- Johan

On Tue, Mar 13, 2018 at 10:17 PM Michael Paus  wrote:

> How will these changes then be synchronized with the work Gluon is doing
> for the version
> distributed by them? Do they work on the same repo?
>
> Am 12.03.18 um 23:25 schrieb Kevin Rushforth:
> > Hi Florian,
> >
> > By way of update, after thinking about this for a week (and getting
> > some offline feedback), I no longer propose doing this -- at least not
> > for the short-mid term. I've retargeted this RFE to tbd_major and
> > lowered the priority to P4.
> >
> > Having said that, we don't have any plans to modify SceneBuilder, but
> > will happily accept contributions.
> >
> > -- Kevin
> >
> >
> > Florian Brunner wrote:
> >> OK, this still comes a bit as a surprise as the source code has been
> >> kept in the repo and was not just provided as a ZIP file.
> >>
> >> I'm currently working on a tool based on the SceneBuilder Kit. I
> >> needed to work on the code a bit and was planning to donate the code
> >> back to OpenJFX once released, as I was under the impression OpenJFX
> >> would serve as the master / upstream-repo for all SceneBuilder forks.
> >> I was also under the impression that OpenJFX at least would make sure
> >> the code works with any new JDK / JavaFX version and hoped it would
> >> get support for new controls, if any were added to JavaFX.
> >>
> >> -Florian
> >>
> >> Am Freitag, 2. März 2018, 09:12:15 CET schrieb Kevin Rushforth:
> >>> I filed the following JBS isuse to remova the SceneBuilder sources
> >>> from the OpenJFX repo.
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8198961
> >>>
> >>> As mentioned in the Description of that issue, the OpenJFX repo
> >>> contains the source code for a no-longer-maintained version of the
> >>> SceneBuilder tool. Active development on SceneBuilder in the OpenJFX
> >>> repo was stopped over three years ago. Since that time, the only
> >>> changes have been either jigsaw-related changes to keep it buildable
> >>> and runnable, or global changes that happened to touch some of the
> >>> files in apps/scenebuilder.
> >>>
> >>> A fork of SceneBuilder is maintained by Gluon, so anyone wanting to
> >>> get the latest SceneBuilder should go there.
> >>>
> >>> Before I proceed, I wanted to poll the list to see whether anyone
> >>> has a concern with this. I don't plan to take any action for at
> >>> least a week.
> >>>
> >>> -- Kevin
> >>>
> >>>
> >>
> >>
>
>

Re: OpenGL deprecated in OS-X

[John-Val Rose]

I’m doing some work with Vulkan at the moment so maybe I’ll be able to help out 
with Vk support for JavaFX.

John-Val

> On 5 Jun 2018, at 17:18, Johan Vos  wrote:
> 
> Ever since Apple deprecated the developer-oriented Apple ][ , I failed to 
> appreciate their decisions. But so be it.
> 
> The good thing is that the structure of the OpenJFX project allows for 
> different rendering pipelines without much impact on other code. 
> Therefore, I think it would be a nice sandbox experiment to have a Metal and 
> a Vulkan pipeline. 
> 
> But I agree with Kevin, we don't need a replacement for OpenGL in the Java 11 
> timeframe :) 
> 
> - Johan
> 
> 
>> On Tue, Jun 5, 2018 at 12:35 AM John-Val Rose  wrote:
>> Unfortunately Apple is doing exactly what Microsoft did during the “Great 
>> API Wars”. During this time, MS decided to go with its own exclusive 
>> graphics API namely Direct 3D as part of their whole DirectX technology 
>> instead of the obvious approach of supporting OpenGL fully.
>> 
>> These days, GPU drivers for DirectX work much better on Windows than those 
>> for OpenGL.
>> 
>> The same will now apply for Metal drivers versus OpenGL drivers on MacOS.
>> 
>> This is all about “vendor lock-in” and can be seen with other technologies 
>> like WebKit and Blink for example.
>> 
>> Of course this is bad news for the developers but devs are not the core 
>> market for Windows, Apple or Google/Android hardware.
>> 
>> The bright light on the horizon is Vulkan from Khronos which started out 
>> life as OpenGL 5 but is now being pushed as the ultimate cross platform 
>> graphics API.
>> 
>> Even Microsoft have jumped on board and Vulkan driver support on Windows is 
>> good.
>> 
>> We will have to wait and see but having a situation where OpenGL, DirectX, 
>> Metal and Vulkan are all important graphics APIs simultaneously is clearly 
>> not tenable.
>> 
>> > On 5 Jun 2018, at 06:51, Tom Schindl  wrote:
>> > 
>> > Hi,
>> > 
>> > I don‘t know what the Apple guys are smoking but they just deprecated 
>> > OpenGL. The question is what does this mean for JavaFX.
>> > 
>> > See https://developer.apple.com/macos/whats-new/
>> > 
>> > Tom
>> > 
>> > Von meinem iPhone gesendet

OpenGL deprecated in OS-X

[Paul Ray Russell]

Tom's right. Major news. Presumably prism would need to cater for a third
renderer, Metal. What would be the time scales for this? Is this an
opportunity to update the way javafx renderer works? Perhaps a tie in to
Lwjgl is better? They have Vulcan bindings and no doubt will wrap Metal.
But I would advocate avoiding a naive object wrapper that privatises all
wrapped calls. Imo. The problem is, currently, if a dev needs lower level
access it's all shielded.

On Mon, 4 Jun 2018, 23:02 ,  wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openjfx-dev digest..."
>
>
> Today's Topics:
>
>1. Re: Draft JEP for new Packaging Tool (replacement for
>   javapackager) (Pedro Duque Vieira)
>2. Re: Draft JEP for new Packaging Tool (replacement for
>   javapackager) (Scott Palmer)
>3. Re: Draft JEP for new Packaging Tool (replacement for
>   javapackager) (Michael Paus)
>4. Re: Draft JEP for new Packaging Tool (replacement for
>   javapackager) (Mario Ivankovits)
>5. OpenGL deprecated in OS-X (Tom Schindl)
>6. Re: Removal of apps/scenebuilder from OpenJFX repo (Sverre Moe)
>
>
> --
>
> Message: 1
> Date: Mon, 4 Jun 2018 15:44:55 +0100
> From: Pedro Duque Vieira 
> To: OpenJFX Mailing List 
> Subject: Re: Draft JEP for new Packaging Tool (replacement for
> javapackager)
> Message-ID:
> <
> caaeud6za5jlngbsvsaw0d-mlwnreq2y6mmtqyrvxuvsuoex...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> I agree with Johan and others, a splash screen is valuable and needed.
>
> Microsoft applications that run on Windows itself (think Word, Excel, etc),
> they have a splash screen, Intelllij has a splash screen (it's swing based
> AFAIK), etc.. If a Microsoft application running on its own operating
> system needs a splash screen then chances are pretty high that there will
> be Java apps that'll need a splash screen.
>
> Cheers,
>
>
> --
> Pedro Duque Vieira
>
>
> --
>
> Message: 2
> Date: Mon, 4 Jun 2018 12:22:18 -0400
> From: Scott Palmer 
> To: OpenJFX Mailing List 
> Subject: Re: Draft JEP for new Packaging Tool (replacement for
> javapackager)
> Message-ID: <536bf700-3f7b-42d2-9cd9-21ef9385c...@gmail.com>
> Content-Type: text/plain;   charset=utf-8
>
> Nobody is arguing against splash screens.  I?m simply suggesting that the
> JVM startup is not slow enough that we need special handling of this in
> native code.
>
> If Java can get a window displayed in under half a second there is no need
> for the added complexity to support a native splash screen in the launcher.
>
> The idea that cinit code *can* be slow is not really the issue here unless
> it isn?t possible to get a window displayed quickly even when there is no
> significant initialization other than to get that window= shown.  Don?t put
> heavy initialization in the main class when you want a splash screen.  Use
> a pre-main class that shows the splash screen and calls the ?real? main
> class.
>
> It makes sense to understand if we have this problem before making a
> complex solution.
>
> Scott
>
>
> > On Jun 4, 2018, at 10:44 AM, Pedro Duque Vieira <
> pedro.duquevie...@gmail.com> wrote:
> >
> > Hi,
> >
> > I agree with Johan and others, a splash screen is valuable and needed.
> >
> > Microsoft applications that run on Windows itself (think Word, Excel,
> etc),
> > they have a splash screen, Intelllij has a splash screen (it's swing
> based
> > AFAIK), etc.. If a Microsoft application running on its own operating
> > system needs a splash screen then chances are pretty high that there will
> > be Java apps that'll need a splash screen.
> >
> > Cheers,
> >
> >
> > --
> > Pedro Duque Vieira
>
>
>
> --
>
> Message: 3
> Date: Mon, 4 Jun 2018 18:35:15 +0200
> From: Michael Paus 
> To: OpenJFX 
> Subject: Re: Draft JEP for new Packaging Tool (replacement for
> javapackager)
> Message-ID: <99ace730-ad9b-f8ba-dd35-c2cf56b99...@jugs.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Maybe I misunderstood the question but to my opinion the real question is
> whether the new java packager has to provide the support for a splash
> screen
> or not. This has nothing to do with the question whether applications
> should
> have a splash screen or not because if we find that todays Java is fast
> enough
> to display a simple window in less than a second or so, then the Java GUI
> (Swing or 

Re: OpenGL deprecated in OS-X

[Johan Vos]

Ever since Apple deprecated the developer-oriented Apple ][ , I failed to
appreciate their decisions. But so be it.

The good thing is that the structure of the OpenJFX project allows for
different rendering pipelines without much impact on other code.
Therefore, I think it would be a nice sandbox experiment to have a Metal
and a Vulkan pipeline.

But I agree with Kevin, we don't need a replacement for OpenGL in the Java
11 timeframe :)

- Johan


On Tue, Jun 5, 2018 at 12:35 AM John-Val Rose  wrote:

> Unfortunately Apple is doing exactly what Microsoft did during the “Great
> API Wars”. During this time, MS decided to go with its own exclusive
> graphics API namely Direct 3D as part of their whole DirectX technology
> instead of the obvious approach of supporting OpenGL fully.
>
> These days, GPU drivers for DirectX work much better on Windows than those
> for OpenGL.
>
> The same will now apply for Metal drivers versus OpenGL drivers on MacOS.
>
> This is all about “vendor lock-in” and can be seen with other technologies
> like WebKit and Blink for example.
>
> Of course this is bad news for the developers but devs are not the core
> market for Windows, Apple or Google/Android hardware.
>
> The bright light on the horizon is Vulkan from Khronos which started out
> life as OpenGL 5 but is now being pushed as the ultimate cross platform
> graphics API.
>
> Even Microsoft have jumped on board and Vulkan driver support on Windows
> is good.
>
> We will have to wait and see but having a situation where OpenGL, DirectX,
> Metal and Vulkan are all important graphics APIs simultaneously is clearly
> not tenable.
>
> > On 5 Jun 2018, at 06:51, Tom Schindl 
> wrote:
> >
> > Hi,
> >
> > I don‘t know what the Apple guys are smoking but they just deprecated
> OpenGL. The question is what does this mean for JavaFX.
> >
> > See https://developer.apple.com/macos/whats-new/
> >
> > Tom
> >
> > Von meinem iPhone gesendet
>