At 11:33 3/5/01 -0700, [EMAIL PROTECTED] wrote:
>On Fri, 4 May 2001, Peter Donald wrote:
>
>> At 12:29 3/5/01 -0700, Earl Hood wrote:
>> >On May 3, 2001 at 12:46, "Michael Gerdau" wrote:
>>
>> Unfortunately that doesn't cut it as usually you need to have Thread
>> implement a particular class so it replaces itself back in pool after it
>> has done a run() on it' client. The way I am just about to redesign the
>> Avalon thread pool is as follows
>>
>> interface ThreadPool
>> {
>> void executeAndWait( Runnable work ) throws ThreadException;
>> void executeAndWait( Executable work ) throws ThreadException;
>>
>> ThreadControl execute( Runnable work );
>> ThreadControl execute( Executable work );
>> }
>
>I was thinking of something simpler:
>
>interface SimpleThreadPool {
> void run( Runnable r );
>}
>
>That's all you need in most cases.
>true - but when you hit one of the "other" cases you have to throw away the
>pool or do some massive workarounds. Check out the hacks in Avalon that
>were used to get around the above.
I think we could create a ThreadPool interface which defines both methods but implementors could decide id they implement only one or both. When you create the pool from the factory you get to know what kind of pool are you using
.
What I wouldn't use is another Executable interface, I'd just stick to Runnable. What does the Executable interface offers?
>On top of this you can add other (optional) APIs ( like ThreadPoolRunnable
>in tomcat, that saves a hashtable lookup, or any other fancy methods
>). And of course, the implementation migh have some setters and getters to
>configure the pool and get info - but that's specific to each
>implementation.
>
>
>IMHO a big problem with java is that it's far too easy to create
>interfaces.
>Well I believe the opposite ;) - it is far too easy to not use interfaces -
>hence the scattered interdependencies on most products.
I have to agreee, the massive use of interfaces makes Java so flexible and easy to add custom implementations. This doesn't mean you have to always make bloated classes, you can just declare methods as unsupported as the Collections API do
