1. javaee-spec@javaee.groups.io

Re: Inconsistent or incomplete usage of @Repeatable

Arjan Tijms
 

I think one of the issues, and for me this is huge issue, is how the JCP process is set up. In order to make changes in specs, even if they are platform initiated, specs have to be active. But specs can really only be active if they are planned to be active.

Here it's some relatively simple annotations that have to be changed throughout many specs, but I've seen this in other cases too.

For example, JSF (and JSP) extracted their expression language functionality into a separate spec (EL 3). Separation is good, since this allows specs to evolve at their own pace.

Except, for Java EE 8 it wasn't planned to make the EL spec active, and thus it couldn't be active. Now at some point the JSF EG needed to make a change in an EL class, but we could not do it, since the EL spec was not active and could not be made active because of the aforementioned planning.

Had JSF not extracted EL but kept it to itself the change would have been trivial to make. In other words, the current process in some way encourages specs not to extract functionality into separate specs.

I fully realise it's much easier said then done, but I would like to propose a kind of tree mechanism in how specs are organised, such that a "parent" spec can take responsibility of "child" specs. With EE Umbrella being the parent of them all, that EG could make changes in any spec if that spec would be unfortunate enough to be missed in the planning to be active.

In this case, the EE 8 umbrella EG could make the necessary changes for annotations in all specs that are currently not active or get a MR.

I know this can't be changed for EE 8 now, but just a thought going forward.

Kind regards,
Arjan Tijms






On Wed, Jun 21, 2017 at 9:47 PM, Kevin Sutter <kwsutter@...> wrote:
Wow.  I guess @EJB was not the only miss...  I didn't think too hard before asking that...  :-)  In any case, thanks for the pointer to the JIRA.  I missed that reference when I went back in the archives.  We'll have to add that JIRA to our required list of TODOs for Java EE 9.  I agree that this looks to be too much to consider at this point.

Thanks, Kevin

On Wed, Jun 21, 2017 at 2:34 PM, Linda DeMichiel <linda.demichiel@...> wrote:
Hi Kevin,

I agree that consistency here would be desirable.
However, in planning for Java EE 8 we had to prioritize
resources around updating those specs we felt it most
important to focus on, with the expectation that we
would handle any missing @Repeatable updates when the
others were next updated.

@EJB is not the only miss.  You can see the remainders
by scrolling through the JIRA issue here:
https://github.com/javaee/javaee-spec/issues/36.

In particular, since JMS and Connector are not being
updated in this release, those annotations will still
not be repeatable either.

-Linda



On 6/21/17, 12:08 PM, Kevin Sutter wrote:
Hi,
I know we discussed this back in May of 2016, but actual practice is
causing us to scratch our heads...  Without the @Repeatable annotation
usage being spelled out at the Platform level, we're discovering some
inconsistent or incomplete usage patterns.

For example, JPA has stepped up to use the @Repeatable annotation on
several of their annotations.  And, Common Annotations has identified
the use with @Resource and @DataSourceDefinition.  But, what about
@EJB?  It seems that this would be another valid usage of @Repeatable.
So, with each spec deciding for themselves whether to support
@Repeatable, we don't have a consistent story for our users.  It won't
be intuitive.  Sometimes you can skip the plural form of the annotation,
and sometimes you can't.  You'll just have to "know"...

I haven't thought through every plural Annotation usage, so I'm not sure
if the @EJB is the only miss.  If we're down to just a handful of
misses, should we step up to support these additional @Repeatables in
Java EE 8?

Thanks, Kevin



Join javaee-spec@javaee.groups.io to automatically receive all group messages.