Startable & Disposable interfaces

[GoogleCodeExporter]

public interface Startable {
    void start();
    void stop();
}
public interface Disposable {
    void dispose();
}

--

Apache-Avalon had Startable, so does PicoContainer, and the need for components 
with IoC life-cycle is clear IMO.  Spring and PicoContainer also have support 
for JEE5's PostConstruct and 
PreDestroy lifecycle annotations.  I'm against the view that lifecycle is just 
JVM starting up, and 
shutdown-hook initiated.  For me it much more fine-grained.  I'm also of the 
opinion that the 
ProstConstruct/PreDestroy is not what was wanted to solve this elegantly* and 
the clue to that is 
the human must/must-not rules baked into the Javadoc (see below).

For those new to it; start/stop is called by the container to signify the 
starting or stopping of 
daemon-like activities.  Start could be called after a stop and so on.  Dispose 
is called when its 
all over, and there is no intention to resurrect.  MS's .NET has a IDispose 
interface too so its not 
without precedent.

It seems to me that Startable/Disposable are the purview of this JSR and I'll 
hanker for it for 
another 10 years if declined here :-)

The following of Startable/Disposable post-injection are responsibility of the 
container.  The 
server incarnations of JBoss, Spring, Weblogic etc could act on implementors.  
A container inside 
a WAR file may map start/stop to  context or application events. Perhaps for 
WAR file contained 
components requiring life-cycle in services like appengine, there's neither 
socket listening or 
thread-launching possibilities, due to restrictions.  This does not negate the 
need for 
Startable/Disposable.

Links - http://www.j2ee.me/javaee/5/docs/api/javax/annotation/PostConstruct.html
http://www.j2ee.me/javaee/5/docs/api/javax/annotation/PreDestroy.html
* http://www.uoregon.edu/~ftepfer/SchlFacilities/TireSwingTable.html

Original issue reported on code.google.com by PaulHamm...@gmail.com on 24 Jun 2009 at 11:39

[GoogleCodeExporter]

I really think we should not be trying to replace @PostConstruct/@PreDestroy. 
299
already specifies that @PostConstruct is called after injection occurs, and
@PreDestroy is called when the context is destroyed. I'm pretty certain that 
this is
a super-set of Startable and Disposable. (e.g. @PostConstruct/@PreDestroy on an
@ApplicationScoped object is equivalent to Startable.) 

I've also never seen developer having any problems complying with the listed 
rules,
and they are not much different to the rules we have defined for @Inject, for 
example.

Original comment by gavin.k...@gmail.com on 24 Jun 2009 at 4:43

[GoogleCodeExporter]

Its true that @PostConstruct/@PreDestroy work from JEE, and that its likely 
that yours is likely the majority 
opinion, but I can't help but feel that its a they are a lame over-engineered 
solution -> like sending an 
annotation on an interface's Job.

Original comment by PaulHamm...@gmail.com on 25 Jun 2009 at 12:41

[GoogleCodeExporter]

Well, I don't have a really strong opinion on which is better, by the 
annotations do
have one big advantage over interfaces: a @PreDestroy or @PostConstruct method 
may be
protected or package private, whereas methods declared by interfaces must be 
public.
And the logic in @PostConstruct or @PreDestroy is very often more like internal
implementation of the class, IMO.

Original comment by gavin.k...@gmail.com on 25 Jun 2009 at 5:01

[GoogleCodeExporter]

I concur with Gavin's earlier comments, if we are able to reuse @PostConstruct 
and 
@Predestroy we should do so, unless there is a motivating use case that those 
cannot 
support.

We should be frugal in our specification of new artifacts!

Original comment by Larry.Ca...@gmail.com on 25 Jun 2009 at 3:27

[GoogleCodeExporter]

Well for the record, IoC details start/stop/dispose whereas the JEE annotations 
are equivalent start/dispose only.  
I can satisfy requirements to present a use case I think.  But I think its an 
issue of appetite, bravery and 
opportunity.

Original comment by PaulHamm...@gmail.com on 25 Jun 2009 at 3:50

[GoogleCodeExporter]

What, precisely, is the semantic difference between dispose() and stop()? An 
instance
of Startable can be started and stopped multiple times?

Original comment by gavin.k...@gmail.com on 25 Jun 2009 at 4:07

[GoogleCodeExporter]

@Paul, couldn't this issue be resolved by users creating a Startable and 
Stoppable
interfaces (or Lifecycle with start/stop in it or whatever shape of API they 
want)
inside a project/library - then using the @PostConstruct/@Predestroy 
annotations on
those interface methods?

i.e. if annotations on interfaces are supported, we can have potentially many
flavours of start/stop interfaces created in different libraries (which may or 
may
not use checked exceptions etc).

In other words; if IoC containers just really looked for the JSR250 annotations;
application developers could make concrete interfaces if they wish to do so.

Original comment by james.st...@gmail.com on 28 Jul 2009 at 9:17

[GoogleCodeExporter]

What's the status of this issue? Are there any plans to address lifecycle 
issues as
part of 330?

Original comment by bokowski on 11 Sep 2009 at 3:49

[GoogleCodeExporter]

Thanks for the reminder. I agree that this is redundant with 
@PostConstruct/@Predestroy, probably out of scope for 330, and even if it was 
in 
scope, this is very tricky to get right (considering exception handling, 
threading model, 
etc.). Not to mention that I think start()/stop() works for singleton or 
"application 
scope", but it's too simplistic for other scopes (thinking of transactions 
scope, 
conversation scope, etc.).

Original comment by crazybob...@gmail.com on 11 Sep 2009 at 5:10

• Changed state: WontFix