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

2018-06-11 Thread Rony G. Flatscher
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]

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

2018-06-05 Thread 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

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

2018-06-05 Thread 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:

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

2018-06-05 Thread 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

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

2018-06-05 Thread 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

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

2018-06-05 Thread 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

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

2018-06-04 Thread Mario Ivankovits
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);

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

2018-06-04 Thread Michael Paus
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

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

2018-06-04 Thread Scott Palmer
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

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

2018-06-04 Thread 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

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

2018-06-04 Thread Johan Vos
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

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

2018-06-04 Thread Scott Palmer
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

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

2018-06-04 Thread Tom Schindl
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

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

2018-06-03 Thread Scott Palmer
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

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

2018-06-03 Thread Tom Schindl
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

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

2018-06-03 Thread Mario Ivankovits
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

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

2018-06-03 Thread 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

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

2018-06-01 Thread Johan Vos
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

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

2018-06-01 Thread Scott Palmer
> 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

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

2018-06-01 Thread Tom Schindl
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

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

2018-06-01 Thread Michael Ennen
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

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

2018-05-31 Thread Michael Paus
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