jsr342-experts@javaee-spec.java.net

[jsr342-experts] Re: Modularity in Java EE 7

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Wed, 28 Sep 2011 23:38:12 -0700

Jason T. Greene wrote on 09/28/2011 08:32 PM:
> On Sep 27, 2011, at 4:57 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>
>> Jason T. Greene wrote on 9/27/11 1:51 PM:
>>> On 9/27/11 2:56 PM, Bill Shannon wrote:
>>>
>>> -snip-
>>>
>>>> We have considered several
>>>> alternatives moving forward, including delivering Java EE 7 with the
>>>> remaining content as planned, or splitting the Java EE 7 release into
>>>> smaller Java EE 7 and Java EE 8 releases, with only a small time gap
>>>> between those two releases, and with Java EE 8 containing only
>>>> modularity support and any remaining original content from Java EE 7.
>>>>
>>>> I know this will be a disappointment to all of us, but I'm sure you'll
>>>> understand the constraints and agree that alignment with the upcoming
>>>> Java SE module system is essential.
>>>
>>> Hi Bill,
>>>
>>> I definitely think this was the right decision to make, and relay Red Hat's
>>> support. Due to the massive impact modularity will have I think it's more
>>> important that EE and SE be cleanly aligned, then for us to be early.
>>
>> Thanks for the support.
>>
>>> The idea you mention above of fast tracking EE7 is interesting. Does this imply
>>> revisiting the main goals? We would love to see some more work on unifying the
>>> specs (e.g. common services like tx, sec, and so on), and that seems more
>>> achievable in a short time frame.
>>
>> At this point we're just collecting input.
>>
>> It sounds like you're suggesting that we scale back some (unnamed) goals
>> and doing more work to unify specs. We're still considering the resource
>> impact of the various possibilities but at this point we think we'd likely
>> have to remove more than just modularity to make a significant difference
>> in the EE 7 schedule.
>
> That's correct. I was assuming that a shortened schedule would mean shifting or
> splitting other major items. For example, perhaps some of the PAAS work could be
> split between 7 and 8?

The only obvious choice there is to defer the limited SaaS support we're
planning to EE 8. I'd be a little worried about doing that, however,
since we've already seen that there's an interaction between the metadata
we need for PaaS and the metadata we need for SaaS. The nice simple
solution we envisioned for PaaS can become quite complicated when we
factor in the SaaS requirements. I'm concerned that if we don't
consider them from the beginning we'll end up with a mess if we have
to retrofit them later.

>> Still, I'm interested in what additional spec unification you'd like to see.
>>
>
> Well I think we could continue to build on the "unified component model" notions
> we introduced in 6. More specifically taking things like EJB transactional
> annotations and making them common EE services that can be consumed by managed
> beans, and by extension any EE framework.

Doing that for transactions is already on our list.

Anything else?