Date
1 - 5 of 5
Inconsistent or incomplete usage of @Repeatable
|
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
|
|
|
|
Linda DeMichiel
Hi Kevin,
toggle quoted messageShow quoted text
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,
|
|
|
|
reza_rahman <reza_rahman@...>
I had helped develop the initial JIRA on this and I do not think EJB is the only miss, though it may be the major miss. I also agree this is an important issue to get right.
toggle quoted messageShow quoted text
-------- Original message -------- From: Kevin Sutter <kwsutter@...> Date: 6/21/17 3:08 PM (GMT-05:00) To: javaee-spec@javaee.groups.io Subject: [javaee-spec] Inconsistent or incomplete usage of @Repeatable 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
|
|
|
|
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 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:
|
|
|