Re: Draft JEP for new Packaging Tool (replacement for javapackager)
On 31.05.2018 02:11, Kevin Rushforth wrote: > I just sent an email to the core-libs-dev alias [1] proposing a new Packaging > Tool as a > replacement for javapackager. If you are interested in this JEP, you can > follow and participate in > the discussion there. > > -- Kevin > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html > One feature that might not be on the radar for pure Java solution providers is having an option to start up a JavaFX application from any javax.script (aka JSR-223) scripting language. In this case it should be possible to supply the script's file name. ---rony
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
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)
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: Draft JEP for new Packaging Tool (replacement for javapackager)
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)
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 >
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
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: Draft JEP for new Packaging Tool (replacement for javapackager)
Hi!
I’ve just test with this very small JavaFX Application:
public class TstFx extends Application
{
@Override
public void start(Stage primaryStage) throws Exception
{
Label root = new Label("test");
Scene scene = new Scene(root, 800, 600);
primaryStage.setOnShown(evt -> System.exit(1));
primaryStage.setScene(scene);
primaryStage.show();
}
public static void main(String[] args)
{
launch(args);
}
}
As you can see, the program forcibly exits once the stage is shown. So, using
„time“ I can simply measure the time required until the stage should be visible
on screen.
Starting this with an incredible huge classpath (the one we have to use in
production) I get this times:
real 0m1.885s
user 0m3.372s
sys 0m0.433s
Using a really small classpath I can come down to:
real 0m1.639s
user 0m2.208s
sys 0m0.297s
MacBook late 2016.
The „user" difference seems to be just because of the classpath scanning. No
static initialization happening, because this TstFx does not reference any
other class.
Best regards,
Mario
Am 04.06.2018 um 18:22 schrieb Scott Palmer
mailto:swpal...@gmail.com>>:
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
mailto: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
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
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,
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
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 > 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
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
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: Draft JEP for new Packaging Tool (replacement for javapackager)
The problem is not the Java window, but the dependencies. If that window is created by a class that requires resolving other classes and somehow one of these classes take a long time to initialize, it will be slow. - Johan On Mon, Jun 4, 2018 at 12:53 PM Scott Palmer wrote: > If a Java window appears in less than half a second there is no point in > adding the complexity of a native splash screen. > > Scott > > > On Jun 4, 2018, at 5:13 AM, Tom Schindl > wrote: > > > > A splash screen has to be that instant that it IMHO makes no sense to > > time how long it takes to get the JVM and JavaFX up and running because > > it can never be as instant as a splash has to show up. > > > > Tom > > > >> On 04.06.18 01:06, Scott Palmer wrote: > >> Has anyone actually timed how long it takes to get a Java window on > screen? I don’t think the delay is long enough to bother with a splash > screen these days. > >> > >> Scott > >> > >>> On Jun 3, 2018, at 4:22 AM, Tom Schindl > wrote: > >>> > >>> That's why I requested that since a long time from the packager because > >>> a splash has to be part of the native launcher created. > >>> > >>> The Eclipse-RCP-Launcher does exactly the right thing: > >>> * Show a static image (IIRC they use bmp) > >>> * Once the VM and UI-Toolkit is up replace that image with a window > (SWT > >>> calls it Shell) so that you can go interactive showing videos, > >>> a progressbar, ... > >>> > >>> Tom > >>> > On 03.06.18 10:11, Mario Ivankovits wrote: > A preloader/splash-screen will/should also hide the JVM startup time. > > Best regards, > Mario > > > > Am 03.06.2018 um 09:57 schrieb Tom Schindl < > tom.schi...@bestsolution.at>: > > > > On 01.06.18 19:42, Johan Vos wrote: > >> I'm not saying a preloader is really a requirement, but I know of a > few > >> applications that are using it and benefiting from it. > >> > >> The preloader functionality is more than just a splash screen, and > I see > >> this valuable for instance when static initializers of classes that > are > >> used in the main class may take a lot of time. > > > > Then I'd argue that you can easily refactor your main-class ;-) > > > > Tom > >
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
If a Java window appears in less than half a second there is no point in adding the complexity of a native splash screen. Scott > On Jun 4, 2018, at 5:13 AM, Tom Schindl wrote: > > A splash screen has to be that instant that it IMHO makes no sense to > time how long it takes to get the JVM and JavaFX up and running because > it can never be as instant as a splash has to show up. > > Tom > >> On 04.06.18 01:06, Scott Palmer wrote: >> Has anyone actually timed how long it takes to get a Java window on screen? >> I don’t think the delay is long enough to bother with a splash screen these >> days. >> >> Scott >> >>> On Jun 3, 2018, at 4:22 AM, Tom Schindl wrote: >>> >>> That's why I requested that since a long time from the packager because >>> a splash has to be part of the native launcher created. >>> >>> The Eclipse-RCP-Launcher does exactly the right thing: >>> * Show a static image (IIRC they use bmp) >>> * Once the VM and UI-Toolkit is up replace that image with a window (SWT >>> calls it Shell) so that you can go interactive showing videos, >>> a progressbar, ... >>> >>> Tom >>> On 03.06.18 10:11, Mario Ivankovits wrote: A preloader/splash-screen will/should also hide the JVM startup time. Best regards, Mario > Am 03.06.2018 um 09:57 schrieb Tom Schindl : > > On 01.06.18 19:42, Johan Vos wrote: >> I'm not saying a preloader is really a requirement, but I know of a few >> applications that are using it and benefiting from it. >> >> The preloader functionality is more than just a splash screen, and I see >> this valuable for instance when static initializers of classes that are >> used in the main class may take a lot of time. > > Then I'd argue that you can easily refactor your main-class ;-) > > Tom
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
A splash screen has to be that instant that it IMHO makes no sense to time how long it takes to get the JVM and JavaFX up and running because it can never be as instant as a splash has to show up. Tom On 04.06.18 01:06, Scott Palmer wrote: > Has anyone actually timed how long it takes to get a Java window on screen? I > don’t think the delay is long enough to bother with a splash screen these > days. > > Scott > >> On Jun 3, 2018, at 4:22 AM, Tom Schindl wrote: >> >> That's why I requested that since a long time from the packager because >> a splash has to be part of the native launcher created. >> >> The Eclipse-RCP-Launcher does exactly the right thing: >> * Show a static image (IIRC they use bmp) >> * Once the VM and UI-Toolkit is up replace that image with a window (SWT >> calls it Shell) so that you can go interactive showing videos, >> a progressbar, ... >> >> Tom >> >>> On 03.06.18 10:11, Mario Ivankovits wrote: >>> A preloader/splash-screen will/should also hide the JVM startup time. >>> >>> Best regards, >>> Mario >>> >>> Am 03.06.2018 um 09:57 schrieb Tom Schindl : On 01.06.18 19:42, Johan Vos wrote: > I'm not saying a preloader is really a requirement, but I know of a few > applications that are using it and benefiting from it. > > The preloader functionality is more than just a splash screen, and I see > this valuable for instance when static initializers of classes that are > used in the main class may take a lot of time. Then I'd argue that you can easily refactor your main-class ;-) Tom >>>
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
Has anyone actually timed how long it takes to get a Java window on screen? I don’t think the delay is long enough to bother with a splash screen these days. Scott > On Jun 3, 2018, at 4:22 AM, Tom Schindl wrote: > > That's why I requested that since a long time from the packager because > a splash has to be part of the native launcher created. > > The Eclipse-RCP-Launcher does exactly the right thing: > * Show a static image (IIRC they use bmp) > * Once the VM and UI-Toolkit is up replace that image with a window (SWT > calls it Shell) so that you can go interactive showing videos, > a progressbar, ... > > Tom > >> On 03.06.18 10:11, Mario Ivankovits wrote: >> A preloader/splash-screen will/should also hide the JVM startup time. >> >> Best regards, >> Mario >> >> >>> Am 03.06.2018 um 09:57 schrieb Tom Schindl : >>> >>> On 01.06.18 19:42, Johan Vos wrote: I'm not saying a preloader is really a requirement, but I know of a few applications that are using it and benefiting from it. The preloader functionality is more than just a splash screen, and I see this valuable for instance when static initializers of classes that are used in the main class may take a lot of time. >>> >>> Then I'd argue that you can easily refactor your main-class ;-) >>> >>> Tom >>
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
That's why I requested that since a long time from the packager because a splash has to be part of the native launcher created. The Eclipse-RCP-Launcher does exactly the right thing: * Show a static image (IIRC they use bmp) * Once the VM and UI-Toolkit is up replace that image with a window (SWT calls it Shell) so that you can go interactive showing videos, a progressbar, ... Tom On 03.06.18 10:11, Mario Ivankovits wrote: > A preloader/splash-screen will/should also hide the JVM startup time. > > Best regards, > Mario > > >> Am 03.06.2018 um 09:57 schrieb Tom Schindl : >> >> On 01.06.18 19:42, Johan Vos wrote: >>> I'm not saying a preloader is really a requirement, but I know of a few >>> applications that are using it and benefiting from it. >>> >>> The preloader functionality is more than just a splash screen, and I see >>> this valuable for instance when static initializers of classes that are >>> used in the main class may take a lot of time. >> >> Then I'd argue that you can easily refactor your main-class ;-) >> >> Tom >
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
A preloader/splash-screen will/should also hide the JVM startup time. Best regards, Mario > Am 03.06.2018 um 09:57 schrieb Tom Schindl : > > On 01.06.18 19:42, Johan Vos wrote: >> I'm not saying a preloader is really a requirement, but I know of a few >> applications that are using it and benefiting from it. >> >> The preloader functionality is more than just a splash screen, and I see >> this valuable for instance when static initializers of classes that are >> used in the main class may take a lot of time. > > Then I'd argue that you can easily refactor your main-class ;-) > > Tom
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
On 01.06.18 19:42, Johan Vos wrote: > I'm not saying a preloader is really a requirement, but I know of a few > applications that are using it and benefiting from it. > > The preloader functionality is more than just a splash screen, and I see > this valuable for instance when static initializers of classes that are > used in the main class may take a lot of time. Then I'd argue that you can easily refactor your main-class ;-) Tom
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
I'm not saying a preloader is really a requirement, but I know of a few applications that are using it and benefiting from it. The preloader functionality is more than just a splash screen, and I see this valuable for instance when static initializers of classes that are used in the main class may take a lot of time. - Johan On Fri, Jun 1, 2018 at 5:56 PM Scott Palmer wrote: > > > > On Jun 1, 2018, at 5:01 AM, Tom Schindl > wrote: > > > > On 01.06.18 08:01, Michael Ennen wrote: > >> Re-familiarizing myself with what javapackager offers, it seems the > >> following JavaFX related > >> features are present: > >> > >> 1.) The conversion of CSS to binary CSS > >> 2.) The ability to specify a preloader > >> 3.) the ability to specify the JavaFX Application class > >> > >> The first one seems like a bit of feature-creep and could be replaced by > >> some other build > >> tool if third party developers really need that feature. They could > >> probably even use something > >> like maven-exec-plugin to manually call such a converter. Let's set this > >> one aside, then. > >> > >> The second and third one are important for correctly launching a JavaFX > >> application. I would > > > > on 2.: What is a preloader good for if you launch a local application? > > IMHO it only really made sense for Webstart > > > > on 3. Why? All you need to do is to provide a main-method and you are > > good to go. > > +1, I have only used a main method that simply calls launch(args). I > never understood why there was a need for special launching of JavaFX apps. > > At one point I thought of using a preloaded for a splash screen because > sometimes I have an application that needs to initialize a lot of plugins, > so there is a significant startup time, but it isn’t worth it. The main > method launches fast enough. > > > Scott
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
> On Jun 1, 2018, at 5:01 AM, Tom Schindl wrote: > > On 01.06.18 08:01, Michael Ennen wrote: >> Re-familiarizing myself with what javapackager offers, it seems the >> following JavaFX related >> features are present: >> >> 1.) The conversion of CSS to binary CSS >> 2.) The ability to specify a preloader >> 3.) the ability to specify the JavaFX Application class >> >> The first one seems like a bit of feature-creep and could be replaced by >> some other build >> tool if third party developers really need that feature. They could >> probably even use something >> like maven-exec-plugin to manually call such a converter. Let's set this >> one aside, then. >> >> The second and third one are important for correctly launching a JavaFX >> application. I would > > on 2.: What is a preloader good for if you launch a local application? > IMHO it only really made sense for Webstart > > on 3. Why? All you need to do is to provide a main-method and you are > good to go. +1, I have only used a main method that simply calls launch(args). I never understood why there was a need for special launching of JavaFX apps. At one point I thought of using a preloaded for a splash screen because sometimes I have an application that needs to initialize a lot of plugins, so there is a significant startup time, but it isn’t worth it. The main method launches fast enough. Scott
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
On 01.06.18 08:01, Michael Ennen wrote: > Re-familiarizing myself with what javapackager offers, it seems the > following JavaFX related > features are present: > > 1.) The conversion of CSS to binary CSS > 2.) The ability to specify a preloader > 3.) the ability to specify the JavaFX Application class > > The first one seems like a bit of feature-creep and could be replaced by > some other build > tool if third party developers really need that feature. They could > probably even use something > like maven-exec-plugin to manually call such a converter. Let's set this > one aside, then. > > The second and third one are important for correctly launching a JavaFX > application. I would on 2.: What is a preloader good for if you launch a local application? IMHO it only really made sense for Webstart on 3. Why? All you need to do is to provide a main-method and you are good to go. Tom
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
Re-familiarizing myself with what javapackager offers, it seems the following JavaFX related features are present: 1.) The conversion of CSS to binary CSS 2.) The ability to specify a preloader 3.) the ability to specify the JavaFX Application class The first one seems like a bit of feature-creep and could be replaced by some other build tool if third party developers really need that feature. They could probably even use something like maven-exec-plugin to manually call such a converter. Let's set this one aside, then. The second and third one are important for correctly launching a JavaFX application. I would think that in order for these to be easily accomplished flags would need to be present in "jpackager" for specifying them (namely, the preloader and Application class). Otherwise jpackager would need to do some "reflection" to try and determine whether or not JavaFX is being used (maybe by checking for its presence on the module path?) and then, if so, get the appropriate preloader and application class. I only mention this because the JEP proposal specifically states "JavaFX-specific features" under "Non-Goals" but this might make things more complicated than they need to be in those two areas I mentioned above. Other then that, this looks good to me and I think having a replacement for javapackager is a good idea. Thanks, Michael Ennen On Thu, May 31, 2018 at 1:56 PM, Kevin Rushforth wrote: > The existing javapackager doesn't really know much about JavaFX as it is, > now that applet and Web Start are gone. I am not aware of anything that > would preclude packaging up a JavaFX application. We will certainly test > the ability to package up a JavaFX application. > > As for the schedule, I agree it isn't ideal, but it's too late for JDK 11. > > -- Kevin > > > > On 5/31/2018 1:25 PM, Michael Paus wrote: > >> Hi, >> >> is it possible to get a clear statement on whether it will be possible to >> package a JavaFX application with the new packager in a similar way as it >> is possible right now with the old packager? The texts are a little bit >> vague there. I just don't know whether it is possible to create a packager >> which does not know anything about the GUI framework which has been used by >> an application. >> >> I would also like to express my concerns about the schedule. The next >> Java release (11) will be an LTS release and that means that there will not >> be any packager for all those people who will have to stick with this >> release for a long time. This is a huge step backward for Java because >> there is then no good deployment technology anymore for a long time. >> >> Michael >> >> Am 31.05.18 um 02:11 schrieb Kevin Rushforth: >> >>> I just sent an email to the core-libs-dev alias [1] proposing a new >>> Packaging Tool as a replacement for javapackager. If you are interested in >>> this JEP, you can follow and participate in the discussion there. >>> >>> -- Kevin >>> >>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-Ma >>> y/053503.html >>> >>> >> >
Re: Draft JEP for new Packaging Tool (replacement for javapackager)
Hi, is it possible to get a clear statement on whether it will be possible to package a JavaFX application with the new packager in a similar way as it is possible right now with the old packager? The texts are a little bit vague there. I just don't know whether it is possible to create a packager which does not know anything about the GUI framework which has been used by an application. I would also like to express my concerns about the schedule. The next Java release (11) will be an LTS release and that means that there will not be any packager for all those people who will have to stick with this release for a long time. This is a huge step backward for Java because there is then no good deployment technology anymore for a long time. Michael Am 31.05.18 um 02:11 schrieb Kevin Rushforth: I just sent an email to the core-libs-dev alias [1] proposing a new Packaging Tool as a replacement for javapackager. If you are interested in this JEP, you can follow and participate in the discussion there. -- Kevin [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html
