Reputation: 10869
If you put an endless loop in JavaFX-Launcher Thread
, your application will never start. From what I know it runs on a different Thread
, so why does this happen?
Just create a new project and override init()
and add a forever loop.
// Mine is not forever
boolean go = true;
@Override
public void init() throws Exception {
// TODO Auto-generated method stub
super.init(); // 'while' comes after this line
while(go){} // Comment this guy and everything is ayt
}
@Override
public void stop() throws Exception {
// TODO Auto-generated method stub
go = false;
super.stop();
}
Does this mean that JavaFX-Launcher Thread
should exit before your application UI can start -(i.e javaFxApplication Thread), or I am missing something?
If JavaFX-Launcher
should be an alternative for launching application needs before the app starts, why can't it be concurrent, because if I want it to be in successions I will just place my code before the super.init()
method?
Upvotes: 0
Views: 1238
Reputation: 159496
Direct explanation of what is happening
The documentation for the Application start method explicitly states what is happening:
The start method is called after the init method has returned, and after the system is ready for the application to begin running.
So, if your run an infinite loop in your init method which never returns, your application will never start.
Further documentation on the Application lifecycle is in the Application javadoc.
Some asides, speculation and possibly related info
The following information may or may not be relevant to your issue at hand.
I believe that the idea behind the init method is that you can put logic in the init method which can execute while the JavaFX system itself is initialized. The initialization of the JavaFX system takes some amount of time, though on a modern processing system I would not expect that to be a very long amount of time (e.g. less than a second).
Most JavaFX application I have seen do not make much use of the init method.
If your initialization is lengthy and you want your application to start quickly even before the initialization is complete, you will need some explicit logic to handle that.
For instance, create a JavaFX Task in your init method that runs on it's own thread. Perform your initialization there. In your start method display a UI immediately, with some limited functionality. Once your initialization is fully complete (which can be known by a listener on the status of your initialization Task), then enable the fully functional UI that depends on the data from the initialization being fully available. Although it is not quite the same (as it is running some of the Task logic from start rather than init), a very similar example of this approach is in this gist sample, which "Displays a JavaFX splash page for an intensive startup task with progress monitoring".
JavaFX does have a concept of a Preloader that provides an in-built framework for handling lengthy initialization, however I haven't seen that widely used. The Preloader itself is targeted mainly at Java embedded in a web page via a plugin or Java Web Start. These are not technologies used much in combination with JavaFX. Most JavaFX applications are standalone applications not relying on web page plugins or web start for their execution). You could use the Preloader framework for initializing your application (even if it works in a standalone mode), but probably it is simpler just to use a Task for this purpose. For further information on Preloader usage, you can refer to: How to use javaFX Preloader with stand-alone application in Eclipse? (note that the answer to that is not specific to Eclipse even though the question is).
Upvotes: 2
Reputation: 62045
I have no previous experience with javafx in particular, but when something of this sort happens it is a tell-tale sign that you are running in a typical event-driven system, which has a message loop to run.
Your init()
method has probably been invoked by this message loop, and the message loop is expecting your init method to return so that it can proceed to fetch and dispatch more messages, so that the system can run.
You will need to either offload the work that you need to do to another thread, or you will need to find some way to break it down into fragments which will be executed piecemeal on some timer event or some idle event, whatever your environment supports.
Upvotes: 1