Back to business: first interfaces/classes

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Back to business: first interfaces/classes

aalmiray
Administrator
Hello everyone,

First off, I apologize for the quiet period in the last 2 months (hectic times). The good news is that I've been talking to people at several conferences about this JSR and the feedback is mostly positive. With this in mind, let's retake the discussion where we left off before.

We need to define the entry point of an application alongside its lifecycle. The API can be made toolkit agnostic if a proper abstraction over the particular UI thread is put in place. Given these ideas here's an initial definition for the application interface, it's phase and the ui thread abstraction (all of them under the javax.application package ;-)

public interface Application {
    // initializes JSR-330 injector
    // reads configuration
    void bootstrap();

    // initializes MVC components
    void startup();

    // called before main window is displayed
    void ready();

    // terminates the application
    void shutdown();

    // returns the current phase the application is in
    ApplicationPhase getPhase();
}
ApplicationPhase is defined as an enum

public enum ApplicationPhase {
    BOOTSTRAP, STARTUP, READY, MAIN, SHUTDOWN
}
The ui thread abstraction may be as follows

/**
 * Handles interaction with the UI thread
 */
public interface UIThreadHandler {
    /** Returns <tt>true</tt> if the current thread is the UI thread */
    boolean isUIThread();

    /**
     * Runs the supplied block inside the UI thread (blocking)
     */
    void runInsideUISync(Runnable runnable);

    /**
     * Runs the supplied block inside the UI thread (non blocking)
     */
    void runInsideUIAsync(Runnable runnable);

    /**
     * Runs the supplied block outside of the UI thread.
     * If the current thread is the UI thread then the block is run in a different thread (async).
     * If the current thread is NOT the UI thread then the block is run on the same thread (sync).
     */
    void runOutsideUI(Runnable runnable);
}
The floor is open for discussion :-)
Reply | Threaded
Open this post in threaded view
|

Re: Back to business: first interfaces/classes

Sven Reimers
Hi all,
 
just a basic question, how about having background intialization running while UI loads? Should this be possible? How would it integrate with the defined phases?
 
Thanks
 
-Sven 

On Thu, Jun 18, 2015 at 1:48 PM, aalmiray [via jsr377-api] <[hidden email]> wrote:
Hello everyone,

First off, I apologize for the quiet period in the last 2 months (hectic times). The good news is that I've been talking to people at several conferences about this JSR and the feedback is mostly positive. With this in mind, let's retake the discussion where we left off before.

We need to define the entry point of an application alongside its lifecycle. The API can be made toolkit agnostic if a proper abstraction over the particular UI thread is put in place. Given these ideas here's an initial definition for the application interface, it's phase and the ui thread abstraction (all of them under the javax.application package ;-)

public interface Application {
    // initializes JSR-330 injector
    // reads configuration
    void bootstrap();

    // initializes MVC components
    void startup();

    // called before main window is displayed
    void ready();

    // terminates the application
    void shutdown();

    // returns the current phase the application is in
    ApplicationPhase getPhase();
}
ApplicationPhase is defined as an enum

public enum ApplicationPhase {
    BOOTSTRAP, STARTUP, READY, MAIN, SHUTDOWN
}
The ui thread abstraction may be as follows

/**
 * Handles interaction with the UI thread
 */
public interface UIThreadHandler {
    /** Returns <tt>true</tt> if the current thread is the UI thread */
    boolean isUIThread();

    /**
     * Runs the supplied block inside the UI thread (blocking)
     */
    void runInsideUISync(Runnable runnable);

    /**
     * Runs the supplied block inside the UI thread (non blocking)
     */
    void runInsideUIAsync(Runnable runnable);

    /**
     * Runs the supplied block outside of the UI thread.
     * If the current thread is the UI thread then the block is run in a different thread (async).
     * If the current thread is NOT the UI thread then the block is run on the same thread (sync).
     */
    void runOutsideUI(Runnable runnable);
}
The floor is open for discussion :-)


If you reply to this email, your message will be added to the discussion below:
http://jsr377-api.40747.n7.nabble.com/Back-to-business-first-interfaces-classes-tp154.html
To start a new topic under jsr377-api, email [hidden email]
To unsubscribe from jsr377-api, click here.
NAML



--
Sven Reimers

* Senior Expert Software Architect
* Java Champion
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* Community Leader  NetBeans: http://community.java.net/netbeans
                              Desktop Java: http://community.java.net/javadesktop
* JUG Leader JUG Bodensee: http://www.jug-bodensee.de
Reply | Threaded
Open this post in threaded view
|

Re: Back to business: first interfaces/classes

aalmiray
Administrator
Yes, this should be possible but handled by the implementation itself. For example, during the `startup` phase an implementation may preload/preinstantiate MVC groups; the V of each group must be initialized inside the UI thread, but the M and C may not. so the implementation has to devise a way to assure that all M,V,C are ready (e.g, initialized) when invoking the MVc lifecycle methods.
Reply | Threaded
Open this post in threaded view
|

Re: Back to business: first interfaces/classes

otaviojava
Could be defined the life cycle by annotation using the JSR 250?
Reply | Threaded
Open this post in threaded view
|

Re: Back to business: first interfaces/classes

aalmiray
Administrator
Hi Otavio,

I think it's best if we define the application's lifecycle (and the artifact's too) without relyong on JSR 250 (@PostConstruct and @PreDestroy specifically) as those annotations have different meanings depending of the DI implementation. Case in point, Eclipse has decided to treat @PostConstruct in a way that's not fully compatible with the annotation's Javadoc. They have their reasons to do so, and like them others may do the same.

Keeping our own lifecycle annotations/interfaces may be seen a bit of duplication at first but it also allows to to lay our own foundation.

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|

Re: Back to business: first interfaces/classes

Hendrik Ebbers
Hi all,

Is there a change to get a summery about the JSR talks and discussions at JavaOne?