I'm seriously considering keeping the basic structure of managing the
threads directly at least until 1.6, and RunnableFuture, can be used,
but updating how the tasks are managed using java.util collections and
possibly BlockingPriorityQueue. The mailing list thread
"com.sun.jini.thread lock contention" seems to include discussion of
this issue, so I'll read it completely before making up my mind.
Incidentally, I agree with the initial comment about implementing
Runnable instead of subclassing Thread, and was already planning that
change.
Patricia
On 7/2/2010 4:33 AM, Peter Firmstone wrote:
Hmm, ok, we'll have to use something else, your choice.
Cheers,
Peter.
Patricia Shanahan wrote:
Thanks. I missed it because I was looking for a new class TaskManager.
I notice that you used a 1.6 class,
java.util.concurrent.RunnableFuture. Is that something we want to do
at this time?
Patricia
On 7/2/2010 2:57 AM, Peter Firmstone wrote:
Just the Apache River source, the files your looking for are in
trunk/src
The fully qualified class names are:
org.apache.river.imp.util.DependantTask
org.apache.river.imp.util.PriorityHandler
Cheers,
Peter.
Patricia Shanahan wrote:
On 6/30/2010 3:44 AM, Peter Firmstone wrote:
I started thinking about a replacement, it's in
org.apache.river.imp.util.
What should I check out to get that?
The name spaces are as follows:
net.jini.* API - must be backward compatible, or breakage minimal
for if
there's a good reason.
com.sun.jini.* - implementation, subject to change.
com.artima.* - implementation, subject to change.
org.apache.river.api.* - new API under review, please feel free to
look
for ways to improve before its frozen in November / December.
org.apache.river.imp.* - new implementation, subject to change,
eventually the com.* namespace will move there too.
