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
