On Jul 24, 2013, at 12:16 PM, Pete Muir <pmuir(a)redhat.com> wrote:
On 24 Jul 2013, at 18:05, Cheng Fang <cfang(a)redhat.com> wrote:
> Thanks for sharing your comments and observations. More inline...
> On 7/24/13 12:09 PM, David M. Lloyd wrote:
>> On initial review of JBeret we have noticed a number of issues that need to be
addressed. The culmination amounts to a series of questions and observations here:
>>
>> #1) Why did we not choose to just use the RI? In other words, what benefit do we
get from JBeret that is not also in the RI? In other, other words, why should we *use*
this code instead of the RI at this point in time?
> Batch RI (
http://java.net/projects/jbatch from IBM) was created solely for the
purpose of a reference implementation, and is a subset of IBM's batch offering. The
RI code base is refreshed periodically by IBM contributors and it doesn't seem to open
to community contribution. I haven't done a deep technical comparison between the 2
yet, but I guess there are areas that one is better than the other and vise versa.
Looking a bit longer term, batch has been an area Java EE and JBoss haven't paid much
attention to, and I believe is an area that can offer future growth potential. Having our
own impl would give us more flexibility when it comes to integration with the rest of the
stack, design choices, and community building. I'm also adding Kev and Pete for their
perspectives.
IIRC Jason G was keen that we build a batch impl, rather than reuse the RI. I can't
remember his reasoning.
It wasn't me, but I do remember someone advocating this approach. My general opinion
on this is that we have to weigh the pro/cons in each scenario. There are a number of
cases when I advocate our own implementation, which is usually around licensing,
dependencies, or we think we can have a competitive advantage that users will see.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat