Back to business: first interfaces/classes

Back to business: first interfaces/classes

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 ;-)

/**
* 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);
}

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 ;-)

/**
* 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:

Re: Back to business: first interfaces/classes

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.

Re: Back to business: first interfaces/classes

Re: Back to business: first interfaces/classes

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.