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.o
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
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: 46
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 st
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
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 d
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.setOnSh
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 fas
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
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
s
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 a
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
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 Ja
Well yes, that is actually a very important point.
While one can do that easily, that does not mean everyone will do it.
I typically counter the "JavaFX is slow" bashing with "JavaFX allows you to
create high-performance applications, but it also allows you to create very
slow ones".
It is actual
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
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
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 benef
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
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
> 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
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-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
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 agre
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 pac
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.ht
25 matches
Mail list logo