I think we should change the target to 1.5 now, so as not to hamper
development, then look at how the proxy's and Service API can be
compiled separately with 1.4.
Patricia Shanahan wrote:
Now that things seem to have stabilized a bit, I'm working on
integrating my TaskManager changes into the latest trunk.
At this point, I have to make a decision about 1.4 support in
TaskManager. It affects two issues, on internal and one part of the
interface.
1. Can I use an enum to represent a Task's state?
Currently, it is private to the TaskManager implementation, useful for
working out how to deal with task removal. It is something that some
TaskManager users might find useful in the future. For example,
TaskManager.Task could be given a useful toString that would display it.
2. Can I use Iterable<Task> as the type for passing the tasks to check
to runAfter?
This is widespread. The current implementation can use
Collection<Task> relatively easily. However, it does commit to it
being an actual Collection, which would constrain future TaskManager
implementations. Iterable<Task> promises only the ability to construct
an Iterator<Task> that iterates over the relevant tasks.
I'm currently assuming the answer to both questions is "yes", but if
so we need to change to compiling TaskManager and its clients with
target 1.5 or later, not jsr14.
This is an advance warning. I'm doing the integration and testing in
my skunk patsTaskManager branch. I'll allow time for discussion before
committing to the trunk.
Patricia
