I started thinking about a replacement, it's in org.apache.river.imp.util.
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.
Best bet would be to search for the classes that depend on the Task
interface, see how they use it and come up with something better.
Agreed, the Task interface is less than optimum, best to replace it.
TaskManager has been identified as a performance bottleneck.
Thanks,
Peter.
Patricia Shanahan wrote:
Thanks. I'll ask TaskManager specific questions in this thread, and
create a new thread for getting started questions.
The main difficulty I've found so far is the runAfter method in the
Task interface. As currently defined, it requires the runAfter caller
to have the tasks in question as the first i elements of a List with
efficient random access. Although get is indeed marginally faster than
an Iterator for random access List implementations, it is
unfortunately slow and inflexible for anything else.
Is this interface something that could be changed, subject to
corresponding changes in the callers in River, or is it an external
interface that cannot change?
In general, the design of TaskManager involves a lot of scans,
insertions, and removals in an ArrayList. Has this caused any
performance problems, or are the operations sufficiently infrequent
and the number of tasks small enough for it to not be an issue?
Patricia
On 6/29/2010 3:50 AM, Peter Firmstone wrote:
Yes, river-dev is for general development discussion and questions,
river-commits for svn commits and jira issues which are automatically
posted. Developers with commit access have a private list for discussing
potential new committers based on merit etc, but most things are done in
the open.
I believe at one stage there was tool com.sun.jini.tool.CheckCodeStyle,
there is a test in
trunk/qa/jtreg/com/sun/jini/tool/CheckCodeStyle/test.sh The test gives
you an idea of the code style required, however the actual tool used for
checking code is not present in the source.
Fire away...
Cheers,
Peter.
Patricia Shanahan wrote:
I've started taking a look at the code, and have questions ranging from
basic building through coding conventions to details of runAfter usage.
If I were joining a co-located project I would be arranging to have
lunch and an informal chat with one or more of the existing developers.
Is this mailing list the lunch room, or is there somewhere more
appropriate?
Patricia
