|
I tend to agree with Doug, although for different reasons. Many of the changes in Milestone 4 will push the Tasklet into more of a supporting role, where it exists solely as a wrapper for legacy jobs that call stored procs or scripts. ChunkProvider/ItemReader and ItemProcessor are now taking more of a central role, and as Doug said, they really shouldn't be 'Callable' since they represent distinct Domain concepts.
However, there may be some merit to reusing the callable interface post 1.0, so perhaps it should be moved to fix version 1.1? @Doug
It exists, just as a backport or part of doug lea's work, not part of the jdk. And the issue wasn't to replace Tasklet (although I probably would), the issue is to support Callable. As for ItemProvider being Callable<Object> (or probably Callable<MyDomainObject>, I would argue against that because it breaks the symmetry of the api. The issue wasn't intended to be "use callable everywhere you have an interface with a single method taking no parameters," but rather use callable over tasklet because they both represent units of execution to be invoked by a supporting infrastructure. @Lucas Yeah, I do like the fact that we're going to be seeing tasklet a lot less, but really the only reason that i brought this up is that a lot of people know what a callable is and what it's used for, but nobody knows what a tasklet is. It's entirely a judgment call, but i thought that I'd suggest it. I think it would be reasonable to exptec that someone might write a wrapper for a Callable that turned it into a Tasklet. Since we are not supporting Java 5 yet, but we know we will be in the future, I would prefer to leave it until then, to avoid having to provide a separate build/module with Java 5 features. Our other usage of backport is deeply internal, so no client should notice it, but this would be quite a public change if we made it.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Sub-task
Closed
Major
Assuming Callable was available, this is a dangerous precedent: ItemProvider, for instance, could also be written as Callable<Object> according to the same logic. While I do believe the ability to safely define threaded job behavior is an important part of the direction of Spring Batch, I personally don't see the value in this.