All, I think I had an action item to get this clarified, not 100% sure, but let me give this a shot. Tomas raised a PR for CDI-508 to clarify which classes are meant to be managed beans. You can find that PR here: https://github.com/cdi-spec/cdi/pull/282/ The line that doesn't sound right to me in the change is to go from: It is not a non-static inner class. to It is not a non-static nested class. I'll use the java programming language tutorial as a point of reference, you can read the page I'll refer to here: https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html Basically, non-static nested classes are AKA inner classes. The term "non-static inner class" shouldn't exist, and that means the original text doesn't make sense, and should probably be inferred as "It is not an inner class" From reading this part of the spec, it becomes unreadable due to the double negative (probably why the aka exists). My proposal was to change the line to instead read (in a positive way) "It is a static nested class" but I can also understand if we want to do this in an exclusion pattern rather than an inclusion pattern. Thoughts? John _______________________________________________ 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.

Hi, Yes this proposal is sufficient and reads better. I can change my PR if there aren't any further objections? Thank's Tom ----- Original Message ----- From: "Martin Kouba" <mkouba(a)redhat.com&gt; To: "John D. Ament" <john.d.ament(a)gmail.com&gt;, cdi-dev(a)lists.jboss.org Sent: Wednesday, May 4, 2016 8:12:44 AM Subject: Re: [cdi-dev] CDI-508 - Which java classes can be managed beans Hi all, given that local and anonymous classes are special kinds of inner classes, we could also simply change the sentence to: "It is not an inner class." Anyway, I think the change of the first sentence is much more important, i.e. removing the "top-level"... Maybe we should also remove "top-level" from the next sentence: "It is a top-level non-abstract class, or is annotated `(a)Decorator`.&quot; So that we would end up with: A Java class is a managed bean if it meets all of the following conditions: * It is not an inner class. * It is a non-abstract class, or is annotated `@Decorator`. * It does not implement `javax.enterprise.inject.spi.Extension`. * It is not annotated `@Vetoed` or in a package annotated `@Vetoed`. * It has an appropriate constructor - either: What do you think? Martin Dne 4.5.2016 v 02:32 John D. Ament napsal(a): > All, > > I think I had an action item to get this clarified, not 100% sure, but > let me give this a shot. > > Tomas raised a PR for CDI-508 to clarify which classes are meant to be > managed beans. You can find that PR here: > https://github.com/cdi-spec/cdi/pull/282/ > > The line that doesn't sound right to me in the change is to go from: > > It is not a non-static inner class. > > to > > It is not a non-static nested class. > > I'll use the java programming language tutorial as a point of reference, > you can read the page I'll refer to here: > https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html > > Basically, non-static nested classes are AKA inner classes. The term > "non-static inner class" shouldn't exist, and that means the original > text doesn't make sense, and should probably be inferred as "It is not > an inner class" > > From reading this part of the spec, it becomes unreadable due to the > double negative (probably why the aka exists). My proposal was to > change the line to instead read (in a positive way) "It is a static > nested class" but I can also understand if we want to do this in an > exclusion pattern rather than an inclusion pattern. > > Thoughts? > > John > > > _______________________________________________ > 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. > -- Martin Kouba Software Engineer Red Hat, Czech Republic _______________________________________________ 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.

Dne 4.5.2016 v 14:08 John D. Ament napsal(a): > Just to confirm (because negatives always make things harder to digest) > > An abstract class annotated Decorator is a managed bean - correct? Yes. > > Because of this line: It is a non-abstract class, or is annotated > `@Decorator`. It was previously: "It is a concrete class, or is annotated @Decorator." But I believe the JLS does not define a "concrete" class... correct me if I'm wrong. > > John > > On Wed, May 4, 2016 at 3:12 AM Tomas Remes <tremes(a)redhat.com > <mailto:tremes@redhat.com>> wrote: > > > Hi, > > Yes this proposal is sufficient and reads better. I can change my PR > if there aren't any further objections? > > Thank's > Tom > > ----- Original Message ----- > From: "Martin Kouba" <mkouba(a)redhat.com <mailto:mkouba@redhat.com>> > To: "John D. Ament" <john.d.ament(a)gmail.com > <mailto:john.d.ament@gmail.com>>, cdi-dev(a)lists.jboss.org > <mailto:cdi-dev@lists.jboss.org> > Sent: Wednesday, May 4, 2016 8:12:44 AM > Subject: Re: [cdi-dev] CDI-508 - Which java classes can be managed beans > > Hi all, > > given that local and anonymous classes are special kinds of inner > classes, we could also simply change the sentence to: > > "It is not an inner class." > > Anyway, I think the change of the first sentence is much more important, > i.e. removing the "top-level"... > > Maybe we should also remove "top-level" from the next sentence: > "It is a top-level non-abstract class, or is annotated `(a)Decorator`.&quot; > > So that we would end up with: > > A Java class is a managed bean if it meets all of the following > conditions: > * It is not an inner class. > * It is a non-abstract class, or is annotated `@Decorator`. > * It does not implement `javax.enterprise.inject.spi.Extension`. > * It is not annotated `@Vetoed` or in a package annotated `@Vetoed`. > * It has an appropriate constructor - either: > > What do you think? > > Martin > > > Dne 4.5.2016 v 02:32 John D. Ament napsal(a): > > All, > > > > I think I had an action item to get this clarified, not 100% > sure, but > > let me give this a shot. > > > > Tomas raised a PR for CDI-508 to clarify which classes are meant > to be > > managed beans. You can find that PR here: > > https://github.com/cdi-spec/cdi/pull/282/ > > > > The line that doesn't sound right to me in the change is to go from: > > > > It is not a non-static inner class. > > > > to > > > > It is not a non-static nested class. > > > > I'll use the java programming language tutorial as a point of > reference, > > you can read the page I'll refer to here: > > https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html > > > > Basically, non-static nested classes are AKA inner classes. The term > > "non-static inner class" shouldn't exist, and that means the original > > text doesn't make sense, and should probably be inferred as "It > is not > > an inner class" > > > > From reading this part of the spec, it becomes unreadable due to the > > double negative (probably why the aka exists). My proposal was to > > change the line to instead read (in a positive way) "It is a static > > nested class" but I can also understand if we want to do this in an > > exclusion pattern rather than an inclusion pattern. > > > > Thoughts? > > > > John > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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. > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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. > > > -- Martin Kouba Software Engineer Red Hat, Czech Republic