Module javafx.graphics
Package javafx.concurrent

Class Service<V>

java.lang.Object
javafx.concurrent.Service<V>
Type Parameters:
V - the type of object returned by the Service
All Implemented Interfaces:
Worker<V>, EventTarget
Direct Known Subclasses:
ScheduledService
public abstract class Service<V> extends Object implements Worker<V>, EventTarget

A Service is a non-visual component encapsulating the information required to perform some work on one or more background threads. As part of the JavaFX UI library, the Service knows about the JavaFX Application thread and is designed to relieve the application developer from the burden of managing multithreaded code that interacts with the user interface. As such, all of the methods and state on the Service are intended to be invoked exclusively from the JavaFX Application thread. The only exception to this is when initially configuring a Service, which may safely be done from any thread, and initially starting a Service, which may also safely be done from any thread. However, once the Service has been initialized and started, it may only thereafter be used from the FX thread.

A Service creates and manages a Task that performs the work on the background thread. Service implements Worker. As such, you can observe the state of the background task and optionally cancel it. Service is a reusable Worker, meaning that it can be reset and restarted. Due to this, a Service can be constructed declaratively and restarted on demand. Once a Service is started, it will schedule its Task and listen for changes to the state of the Task. A Task does not hold a reference to the Service that started it, meaning that a running Task will not prevent the Service from being garbage collected.

If an Executor is specified on the Service, then it will be used to actually execute the service. Otherwise, a daemon thread will be created and executed. If you wish to create non-daemon threads, then specify a custom Executor (for example, you could use a ThreadPoolExecutor with a custom ThreadFactory).

Because a Service is intended to simplify declarative use cases, subclasses should expose as properties the input parameters to the work to be done. For example, to write a Service that reads the first line from any URL and returns it as a String, it might be defined with a single property, url, and might be implemented as: 


     public static class FirstLineService extends Service<String> {
         private StringProperty url = new SimpleStringProperty(this, "url");
         public final void setUrl(String value) { url.set(value); }
         public final String getUrl() { return url.get(); }
         public final StringProperty urlProperty() { return url; }

         protected Task createTask() {
             final String _url = getUrl();
             return new Task<String>() {
                 protected String call() throws Exception {
                     URL u = new URL(_url);
                     BufferedReader in = new BufferedReader(
                             new InputStreamReader(u.openStream()));
                     String result = in.readLine();
                     in.close();
                     return result;
                 }
             };
         }
     }

The Service by default uses a ThreadPoolExecutor with some unspecified default or maximum thread pool size. This is done so that naive code will not completely swamp the system by creating thousands of Threads.

Since:
JavaFX 2.0