Re: Inconsistent or incomplete usage of @Repeatable
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:
|
|