[#BATCH-447] ItemOrientedStep implementation causes mandatory dependency on backport-util-concurrent

Spring Batch

ItemOrientedStep implementation causes mandatory dependency on backport-util-concurrent

Created: 12/Mar/08 01:52 AM Updated: 26/Mar/08 04:21 PM

Component/s:

Execution

Affects Version/s:

1.0.0.m5

Fix Version/s:

1.0.0.rc1

Time Tracking:

Not Specified

File Attachments:

mylyn-context.zip (11 kb)
2.

mylyn-context.zip (4 kb)

Description

« Hide

ItemOrientedStep imports a class from backport-util-concurrent and thereby creates a mandatory dependency on this library. Since my application is compiled against, and run on Java 5 i'd rather not put backport-util-concurrent on the classpath (since I already have java.util.concurrent). Any change of this being abstracted away?

All

Comments

Work Log

Change History

FishEye

Related Builds

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Ben Hale - 12/Mar/08 03:24 AM

I'm looking at the source code for ItemOrientedStep now and there is no import of any of the backport-util-concurrent classes. We use them elsewhere and I'm going to explore limiting those dependencies a bit, but for now can you confirm that you are actually seeing the problem in ItemOrientedStep?

[ Permlink | « Hide ]

Richard Kettelerij - 12/Mar/08 03:42 AM

I'm using 1.0.0m5 and ItemOrientedStep uses a Semaphore in that release. See http://fisheye3.cenqua.com/browse/~raw,r=10707/springframework/spring-batch/trunk/spring-batch-execution/src/main/java/org/springframework/batch/execution/step/ItemOrientedStep.java.

However, the history of ItemOrientedStep in Fisheye shows that the Semaphore import is removed a few hours after the release of 1.0.0m5. So I guess ItemOrientedStep doesn't have an issue in RC1.

[ Permlink | « Hide ]

Ben Hale - 12/Mar/08 03:58 AM

Yeah, that sounds about right. It's been moved to a more isolated class, where I'll do the work to remove the required dependency.

[ Permlink | « Hide ]

Dave Syer - 12/Mar/08 04:51 PM

Backport concurrent is already a dependency for anyone using TasKExecutrorRepeatTemplate (in infrastructure). I guess this is a small enough fraction of users that it could be made optional there as well. But I wouldn't do much work to remove the dependency completely, unless there is a strong reason to do so,

[ Permlink | « Hide ]

Ben Hale - 13/Mar/08 03:11 AM

I'll take a look at this other dependency as well, Dave.

[ Permlink | « Hide ]

Richard Kettelerij - 26/Mar/08 07:03 AM

Ben, thanks for factoring out the backport dependencies in ItemOrientedStep and TaskExecutorRepeatTemplate. I found that RepeatContextCounter is also dependent on backport-util-concurrent (it uses an AtomicInteger). As far as I can see this is the only class with a direct dependency, any change of this being abstracted away?

[ Permlink | « Hide ]

Dave Syer - 26/Mar/08 02:42 PM

Followed the same pattern as the synchroinizer (AtomicCounter interface with factory).

[ Permlink | « Hide ]

Richard Kettelerij - 26/Mar/08 04:21 PM

Thanks for the quick response, I was about to submit a patch myself until I noticed your incoming change.