Hi Nigel,
*CCing in our Adopt-a-JSR group*
Apologies for the long delay in responding!
<snip>
>> So a few questions for the spec lead / EG:
>>
>> 1.) Is there a binary RI we can use? (some sort of Glassfish
>> implementation I assume). Or so we build one from source out of SVN?
>
> The RI will be Open Message Queue (for the standalone JMS provider) and
> GlassFish (as part of a full Java EE 7 implementation) and will follow the
> existing open source processes of those projects.
>
> Implementation of JMS 2.0 features in those projects is in progress at
> Oracle. I would expect an initial implementation containing some but not all
> features to be available for JavaOne USA (end Sept), so if you want to
> actually run some software then I would suggest you aim to hold your
> workshop after then. The JMS 2.0 Public Draft is also due about then. (*)
That's fine and I understand the Oracle delivery position well (love
that slide!) :-)
I'll be at JavaOne so perhaps we can meet up and discuss in person?
>> 2.) Are there any test frameworks/stubs/harnesses that are already used
>> by the community?
>
> I'm not sure what kind of thing you have in mind, but there's nothing for
> JMS 2.0 currently.
I guess we'd be looking for a small app or test harness that helps people
run test scenarios. So for example a stubbed out test harness that behaves
as a producer/consumer/topic/queue/whatever would.
Is there something you're planning on using to prove the RI that can be
shared?
>> 3.) Are there any particular areas that the EG are concerned about in
>> terms of day-to-day developers using current draft of the spec? We tend
>> to setup test scenarios that the developers need to pass and then
>> simply observe them using the new API..
>
> I'm not sure quite how to answer this, but I would invite you to look at the
> what's new section of the current draft.
>
> One of the biggest changes is the new JMSContext API, and support for
> injection of JMSContext objects in Java EE. However these are intended for
> ease-of-use rather than to support any particular use case that couldn't be
> supported before.
Yep, we're going to focus a bit on that and see if day-to-day developers
genuinely find that easier to use. I'm also hoping to visit other areas of
the spec (even some of the old spec) to see if there's anything else existing
that causes extreme pain.
Cheers,
Martijn