On Feb 28, 2016, at 2:10 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: 2016-02-28 20:08 GMT+01:00 Werner Keil <werner.keil(a)gmail.com&gt;: > Yes, there's no "incubating" stage for JSRs other than "not Final", so as soon as a JSR or parts of it are final, they become part of an umbrella spec if that spec wants to contain them. > > Potentially from Java EE 9 on there could be much finer grained activation or deactivation of features and profiles as soon as the whole Jigsaw thing and SE 9 is out, but until then I think we' have to stick to what's available right now. > > For CDI 2 modularity or running in Java SE are already in scope, but other than e.g. having "ee-concurrency" only in the Java EE profile of CDI, I don't see how CDI should do things the platform will provide later anyway. > Fully agree, means @Lock shouldnt go in CDI as everyone stated so falling back on CDI cause concurrency spec is inactive is a bad choice. Question leaves CDI list then and is: how to make concurrency active? > Regards, > Werner > >> On Sun, Feb 28, 2016 at 7:59 PM, Reza Rahman <reza_rahman(a)lycos.com&gt; wrote: >> I am unsure what this means. Firstly I think this functionality is way overdue. Secondly I see little value to having anything that is a pseudo-standard. I'd rather see the effort pursue another path to standardization or remain completely independent while clearly pointing out what the obstacles to standardization are/were. >> >> On the other hand if this is required to be implemented in Java EE 8 runtimes I don't think it matters what the particular structural gymnastics are. Purely from a JCP standpoint, it is possible to have a sub-specification but only if the eventual goal is to spin it out into a separate specification. Examples of this are JPA, interceptors and others. There is no precedent for an "incubator" specification that is somehow optional. In fact I am pretty sure the current JCP rules would disallow this. >> >> On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: >> >>> At apache we have subprojects which can become top level project if they behaves well. Would it be possible at EE level? Idea would be to have cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - know there was appendix in bval for instance). Then for EE 9 if the subspec is proven as good it would become its own spec. wdyt? >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>> >>> 2016-02-28 19:16 GMT+01:00 Mark Struberg <struberg(a)yahoo.de&gt;: >>>> >>>> > Am 26.02.2016 um 17:39 schrieb Werner Keil <werner.keil(a)gmail.com&gt;: >>>> > >>>> > Reza/all, >>>> > >>>> > One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI. >>>> > >>>> >>>> +1 that pretty much sums it up. Concurrency utils is pretty much broken and unusable as it is today. :/ >>>> >>>> Anyway, let’s not fight the past - we need a way forward. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >

On Feb 28, 2016, at 5:13 PM, arjan tijms <arjan.tijms(a)gmail.com&gt; wrote: What are exactly the rules of making something a sub-spec? There have been various examples of this in the past. Reza mentioned JPA, which started as a sub-spec of EJB, even though it was not directly split off from an existing EJB API (you could say it was conceptually a re-imagined EJB Entity Bean, but JPA entities are different enough to stand on their own). I wonder what the decisions were at the time to go for a sub-spec, instead of either directly putting it in EJB on the one hand, or going right away for a top-level spec on the other hand. Regardless, I think this points out a (practical) weakness in the Java EE umbrella/constituent specs setup. In general we like to split things out into several specs, so that those specs can evolve on their own and are useable by the rest of the platform. E.g. EL is a great example, it's now separate, and can be used everywhere without a dependency on say JSP or JSF. But the fact that top level specs need to be individually "active" and must each have assembled their own EG, is a serious process overhead. This is specifically so because with the current Java EE process not all constituent specs are active/open by default for a given spec cycle. > On Sun, Feb 28, 2016 at 8:25 PM, Reza Rahman <reza_rahman(a)lycos.com&gt; wrote: > I am not so sure "everyone stated" this shouldn't be part of CDI. As some of us have already pointed out there might be a case for including it in CDI anyway and this should be part of the discussion equation here and elsewhere. Indeed I suggest putting together a questionnaire on this with the options that "everyone" on this EG indeed does vote on... > >> On Feb 28, 2016, at 2:10 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: >> >> >> 2016-02-28 20:08 GMT+01:00 Werner Keil <werner.keil(a)gmail.com&gt;: >>> Yes, there's no "incubating" stage for JSRs other than "not Final", so as soon as a JSR or parts of it are final, they become part of an umbrella spec if that spec wants to contain them. >>> >>> Potentially from Java EE 9 on there could be much finer grained activation or deactivation of features and profiles as soon as the whole Jigsaw thing and SE 9 is out, but until then I think we' have to stick to what's available right now. >>> >>> For CDI 2 modularity or running in Java SE are already in scope, but other than e.g. having "ee-concurrency" only in the Java EE profile of CDI, I don't see how CDI should do things the platform will provide later anyway. >> >> Fully agree, means @Lock shouldnt go in CDI as everyone stated so falling back on CDI cause concurrency spec is inactive is a bad choice. Question leaves CDI list then and is: how to make concurrency active? >> >>> Regards, >>> Werner >>> >>>> On Sun, Feb 28, 2016 at 7:59 PM, Reza Rahman <reza_rahman(a)lycos.com&gt; wrote: >>>> I am unsure what this means. Firstly I think this functionality is way overdue. Secondly I see little value to having anything that is a pseudo-standard. I'd rather see the effort pursue another path to standardization or remain completely independent while clearly pointing out what the obstacles to standardization are/were. >>>> >>>> On the other hand if this is required to be implemented in Java EE 8 runtimes I don't think it matters what the particular structural gymnastics are. Purely from a JCP standpoint, it is possible to have a sub-specification but only if the eventual goal is to spin it out into a separate specification. Examples of this are JPA, interceptors and others. There is no precedent for an "incubator" specification that is somehow optional. In fact I am pretty sure the current JCP rules would disallow this. >>>> >>>> On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: >>>> >>>>> At apache we have subprojects which can become top level project if they behaves well. Would it be possible at EE level? Idea would be to have cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - know there was appendix in bval for instance). Then for EE 9 if the subspec is proven as good it would become its own spec. wdyt? >>>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>> >>>>> 2016-02-28 19:16 GMT+01:00 Mark Struberg <struberg(a)yahoo.de&gt;: >>>>>> >>>>>> > Am 26.02.2016 um 17:39 schrieb Werner Keil <werner.keil(a)gmail.com&gt;: >>>>>> > >>>>>> > Reza/all, >>>>>> > >>>>>> > One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI. >>>>>> > >>>>>> >>>>>> +1 that pretty much sums it up. Concurrency utils is pretty much broken and unusable as it is today. :/ >>>>>> >>>>>> Anyway, let’s not fight the past - we need a way forward. >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

On Feb 29, 2016, at 4:45 AM, Werner Keil <werner.keil(a)gmail.com&gt; wrote: That's why at least on the SE side (and to some extent ME/Embedded/IoT projects also start to show up there, although some with almost no activity;-) pretty much everything shifted to OpenJDK "JEPs" now as it seems. And there are not many JSRs. Except Jigsaw (don't know thy they bothered filing that) there is no Java SE 9 JSR. For SE 7 there were still a few individual SE JSRs like NIO, Diamond or Coin. For SE 8 the only real JSR was Lamba. Two "rudimentary" JSRs 308 and 310 were still added, but neither created proper deliverables of their own. 310 has no public API and the RI is baked into Java SE 8 in ways, that make independent implementations of the JSR impossible since all rudimentary interfaces are not only hidden under the surface, they also contain direct references to their RI types. Think of that in the EE world? A Servlet spec that only works in Glassfish?;-O JSR 308 is enforced by the compiler, but even the internals of Java SE 8 ignore it and make no use of it. Nor do any standard annotations exist elsewhere, e.g. under NetBeans making use of them. SE 8 included the Optional type instead to help with null values and NPEs, instead of proper integration of Type Annotations. So 308 is practically useless. Could have been avoided completely. There is a glimpse of hope for SE 10 or 11, but they could have left Type Annotations out until then. Java SE 9 does not even have an "Umbrella JSR" nor am I sure, if it makes sense. Mark Reinhold as Spec Lead for the Modularity/Jigsaw JSR keeps as argumenting for Renewal Ballots and it would be quite unlikely, the EC ever voted that one down, but IMHO it is almost a waste of (EC) time in that case. As there are independent implementations of pretty much every EE standard, there is more value here, but it's something the EC started to discuss and worry about, if Oracle may simply "tweak" its JEP mechanism to also work for EE. Regards, Werner > On Sun, Feb 28, 2016 at 11:32 PM, Reza Rahman <reza_rahman(a)lycos.com&gt; wrote: > This is a good question indeed. In the past the real stated rationale for a sub-spec was eventual or possible separation. It's a question that should be posed in the Java EE EG or even the EC. > > In the case of JPA/EJB there is an official reason and perhaps a few ulterior ones. The official reason is that the EJB EG had the initial skill set to deal with JPA but the spec should be eventually separate. Unofficially my guess is that too many vendors had bought into EJB Entity Beans for too long and they needed to deal it a soft blow to make themselves look better instead of a hard and fast death blow. Saving EJB from total collapse right away might have also been a motive and also giving Gavin/Red Hat less credit for Java EE 5 than he/they deserved... > >> On Feb 28, 2016, at 5:13 PM, arjan tijms <arjan.tijms(a)gmail.com&gt; wrote: >> >> What are exactly the rules of making something a sub-spec? >> >> There have been various examples of this in the past. Reza mentioned JPA, which started as a sub-spec of EJB, even though it was not directly split off from an existing EJB API (you could say it was conceptually a re-imagined EJB Entity Bean, but JPA entities are different enough to stand on their own). >> >> I wonder what the decisions were at the time to go for a sub-spec, instead of either directly putting it in EJB on the one hand, or going right away for a top-level spec on the other hand. >> >> Regardless, I think this points out a (practical) weakness in the Java EE umbrella/constituent specs setup. In general we like to split things out into several specs, so that those specs can evolve on their own and are useable by the rest of the platform. E.g. EL is a great example, it's now separate, and can be used everywhere without a dependency on say JSP or JSF. >> >> But the fact that top level specs need to be individually "active" and must each have assembled their own EG, is a serious process overhead. This is specifically so because with the current Java EE process not all constituent specs are active/open by default for a given spec cycle. >> >> >>> On Sun, Feb 28, 2016 at 8:25 PM, Reza Rahman <reza_rahman(a)lycos.com&gt; wrote: >>> I am not so sure "everyone stated" this shouldn't be part of CDI. As some of us have already pointed out there might be a case for including it in CDI anyway and this should be part of the discussion equation here and elsewhere. Indeed I suggest putting together a questionnaire on this with the options that "everyone" on this EG indeed does vote on... >>> >>>> On Feb 28, 2016, at 2:10 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: >>>> >>>> >>>> 2016-02-28 20:08 GMT+01:00 Werner Keil <werner.keil(a)gmail.com&gt;: >>>>> Yes, there's no "incubating" stage for JSRs other than "not Final", so as soon as a JSR or parts of it are final, they become part of an umbrella spec if that spec wants to contain them. >>>>> >>>>> Potentially from Java EE 9 on there could be much finer grained activation or deactivation of features and profiles as soon as the whole Jigsaw thing and SE 9 is out, but until then I think we' have to stick to what's available right now. >>>>> >>>>> For CDI 2 modularity or running in Java SE are already in scope, but other than e.g. having "ee-concurrency" only in the Java EE profile of CDI, I don't see how CDI should do things the platform will provide later anyway. >>>>> >>>> >>>> Fully agree, means @Lock shouldnt go in CDI as everyone stated so falling back on CDI cause concurrency spec is inactive is a bad choice. Question leaves CDI list then and is: how to make concurrency active? >>>> >>>>> Regards, >>>>> Werner >>>>> >>>>>> On Sun, Feb 28, 2016 at 7:59 PM, Reza Rahman <reza_rahman(a)lycos.com&gt; wrote: >>>>>> I am unsure what this means. Firstly I think this functionality is way overdue. Secondly I see little value to having anything that is a pseudo-standard. I'd rather see the effort pursue another path to standardization or remain completely independent while clearly pointing out what the obstacles to standardization are/were. >>>>>> >>>>>> On the other hand if this is required to be implemented in Java EE 8 runtimes I don't think it matters what the particular structural gymnastics are. Purely from a JCP standpoint, it is possible to have a sub-specification but only if the eventual goal is to spin it out into a separate specification. Examples of this are JPA, interceptors and others. There is no precedent for an "incubator" specification that is somehow optional. In fact I am pretty sure the current JCP rules would disallow this. >>>>>> >>>>>> On Feb 28, 2016, at 1:29 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: >>>>>> >>>>>>> At apache we have subprojects which can become top level project if they behaves well. Would it be possible at EE level? Idea would be to have cdi-concurrency subspec (under CDI umbrella but not part of CDI itself - know there was appendix in bval for instance). Then for EE 9 if the subspec is proven as good it would become its own spec. wdyt? >>>>>>> >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>>> >>>>>>> 2016-02-28 19:16 GMT+01:00 Mark Struberg <struberg(a)yahoo.de&gt;: >>>>>>>> >>>>>>>> > Am 26.02.2016 um 17:39 schrieb Werner Keil <werner.keil(a)gmail.com&gt;: >>>>>>>> > >>>>>>>> > Reza/all, >>>>>>>> > >>>>>>>> > One of the biggest problems with Concurrency Utilities is, that it started in 2003, then went "dormant" (before the term existed) and was revived to be finalized 10 years later after little or no proper alignment with then state of the art Java EE standards and technologies. It duplicates things, especially in EJB or CDI. >>>>>>>> > >>>>>>>> >>>>>>>> +1 that pretty much sums it up. Concurrency utils is pretty much broken and unusable as it is today. :/ >>>>>>>> >>>>>>>> Anyway, let’s not fight the past - we need a way forward. >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> >>>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>>>> >>>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. >>