Leo & Leo,
you both represent the "theoretical committee"
:D. What, me? Snif. I thought the day would never come! :D
Spec for release() "Return the Object when you are finished with it. "
about right.
I would like to crystalize the issue to what I see as the kernel of the apple;
Java don't have destructors.
For a good reasons, of which I won't go into here (program C++ for a couple of years to get the point).
yep.
Some objects NEEDS explicit destruction, e.g. FileInputStream.
yep.
Avalon re-introduces the destructor, in the form of ServiceManager.release().
nope. Destruction != release.
Why is that such a good idea, when the destructor in Java is not?
that would not be a good idea, but it also not what we do.
Take a step back from the theory and consider a pool:
public interface Pool
{
Object borrow();
void return( Object o );
}now, consider using a pool as the provider of your dependencies. Unless we're in the ugly world of EJBs, that might look like (as a POJO):
public class MyClass
{
private DependencyFactory m_factory = new DependencyFactory();
private Pool m_pool = new Pool( m_factory ); private void doStuff()
{
Dependency d = (Dependency)m_pool.borrow();
try
{
d.doStuff();
}
finally
{
m_pool.return( d )
}
}
}enter IoC. We don't want to care whether the object is pooled or not. How do we do that? Well, the service manager comes to the rescue:
public class MyClass implements Servicable
{
private ServiceManager m_sm = null; public void service( ServiceManager sm )
{
m_sm = sm;
} private void doStuff()
{
Dependency d = (Dependency)sm.lookup(
Dependency.getClass().getName() );
try
{
d.doStuff();
}
finally
{
m_sm.release( d );
}
}
}it's got nothing to do with construction or destruction. The release() method implements release semantics, nothing more, nothing less. And we need those.
It's interesting to see what happens if you remove the support/requirement for release semantics. You can still implement singleton semantics, per-thread semantics, per-lookup semantics, fixed-number-of-multithreaded-object semantics, and the like. But you cannot do transparent pooling, nor can you put javax.sql.Connection instances (or similar) in your service manager.
Long story short, just always keep this in mind when reading the specification:
Spec for release()
"Return the Object when you are finished with it. (Because it might
be subject to pooling or similar resource management.)"cheers!
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
