From albest512 at hotmail.com Wed Feb 2 19:22:21 2022 From: albest512 at hotmail.com (=?iso-8859-1?Q?Alberto_Otero_Rodr=EDguez?=) Date: Wed, 2 Feb 2022 19:22:21 +0000 Subject: Constant methods in Java Message-ID: I have a suggestion. I think it would be interesting creating constant methods in Java. I mean methods declared like this: public const String myMethod() { String a = "a"; a = a + "b"; return a; } So that the response of the method is forced to be assigned to a final variable. This would be ok: final String b = myMethod(); But this would throw a compilation error: String c = myMethod(); What do you think? It's just an idea. From romanowski.mateusz at gmail.com Fri Feb 4 21:31:15 2022 From: romanowski.mateusz at gmail.com (Mateusz Romanowski) Date: Fri, 4 Feb 2022 22:31:15 +0100 Subject: mistaking switch expressions and switch statements Message-ID: Hi, I am reading article "Design implications of Java?s switch statements and switch expressions" [1] by Vasily STRELNIKOV . I am confounded by "*Figure 6.* Handling complex situations with a Switch Expression" which I believe is a new-style Switch Statement as the `default clause` is removable even though Switch is not total. Could you confirm my interpretation? And should it be correct, help to contact author to ask for correction. Cheers, Mateusz Romanowski [1] https://blogs.oracle.com/javamagazine/post/java-switch-statements-expressions From brian.goetz at oracle.com Fri Feb 4 21:59:14 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 4 Feb 2022 16:59:14 -0500 Subject: mistaking switch expressions and switch statements In-Reply-To: References: Message-ID: You are correct that the default can be elided here, because this is a switch statement on a legacy target type whose labels are all constants, and such statements (for reasons of backward compatibility) can be partial.? All other switches (new target types, new cases, expressions) should be total. The example actually employs "belts and suspenders"; it initializes `discount` to zero, and then assigns it to zero in the default clause.? If discount were left blank, then the default clause would be necessary, not to make the switch total, but to make `discount` definitely assigned.? So you could either elide the initializer on `discount`, or the default clause, but not both. On 2/4/2022 4:31 PM, Mateusz Romanowski wrote: > Hi, > I am reading article "Design implications of Java?s switch statements and > switch expressions" [1] by Vasily STRELNIKOV . > > I am confounded by "*Figure 6.* Handling complex situations with a Switch > Expression" which I believe is a new-style Switch Statement as the `default > clause` is removable even though Switch is not total. > > Could you confirm my interpretation? > And should it be correct, help to contact author to ask for correction. > > Cheers, > Mateusz Romanowski > > [1] > https://blogs.oracle.com/javamagazine/post/java-switch-statements-expressions From cay.horstmann at gmail.com Sat Feb 5 07:00:52 2022 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Sat, 5 Feb 2022 08:00:52 +0100 Subject: mistaking switch expressions and switch statements In-Reply-To: References: Message-ID: <5f04a33e-ebfc-8255-34bf-3da0ac3711e8@gmail.com> The article has other issues. Figure 6 is captioned "Handling complex situations with a switch expression" but contains a switch *statement* without fall-through. Another example where the two axis design (statement vs. expression, fall-through vs. no fall-through) has not been properly understood. Cheers, Cay On 04/02/2022 22:59, Brian Goetz wrote: > You are correct that the default can be elided here, because this is a > switch statement on a legacy target type whose labels are all constants, > and such statements (for reasons of backward compatibility) can be > partial.? All other switches (new target types, new cases, expressions) > should be total. > > The example actually employs "belts and suspenders"; it initializes > `discount` to zero, and then assigns it to zero in the default clause. > If discount were left blank, then the default clause would be necessary, > not to make the switch total, but to make `discount` definitely > assigned.? So you could either elide the initializer on `discount`, or > the default clause, but not both. > > On 2/4/2022 4:31 PM, Mateusz Romanowski wrote: >> Hi, >> I am reading article "Design implications of Java?s switch statements and >> switch expressions" [1] by Vasily STRELNIKOV . >> >> I am confounded by "*Figure 6.* Handling complex situations with a Switch >> Expression" which I believe is a new-style Switch Statement as the >> `default >> clause` is removable even though Switch is not total. >> >> Could you confirm my interpretation? >> And should it be correct, help to contact author to ask for correction. >> >> Cheers, >> Mateusz Romanowski >> >> [1] >> https://blogs.oracle.com/javamagazine/post/java-switch-statements-expressions >> > -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From romanowski.mateusz at gmail.com Sat Feb 5 10:58:34 2022 From: romanowski.mateusz at gmail.com (Mateusz Romanowski) Date: Sat, 5 Feb 2022 11:58:34 +0100 Subject: mistaking switch expressions and switch statements In-Reply-To: <5f04a33e-ebfc-8255-34bf-3da0ac3711e8@gmail.com> References: <5f04a33e-ebfc-8255-34bf-3da0ac3711e8@gmail.com> Message-ID: Hi Cay, Actually, my initial concern was about that figure's mislabeling. As for the fall-through, it has become so complicated that I had to use `javap` to confirm lack of fall-through.. lots of axis, indeed. Cheers, Mateusz On Saturday, February 5, 2022, Cay Horstmann wrote: > The article has other issues. Figure 6 is captioned "Handling complex > situations with a switch expression" but contains a switch *statement* > without fall-through. > > Another example where the two axis design (statement vs. expression, > fall-through vs. no fall-through) has not been properly understood. > > Cheers, > > Cay > > On 04/02/2022 22:59, Brian Goetz wrote: > >> You are correct that the default can be elided here, because this is a >> switch statement on a legacy target type whose labels are all constants, >> and such statements (for reasons of backward compatibility) can be >> partial. All other switches (new target types, new cases, expressions) >> should be total. >> >> The example actually employs "belts and suspenders"; it initializes >> `discount` to zero, and then assigns it to zero in the default clause. If >> discount were left blank, then the default clause would be necessary, not >> to make the switch total, but to make `discount` definitely assigned. So >> you could either elide the initializer on `discount`, or the default >> clause, but not both. >> >> On 2/4/2022 4:31 PM, Mateusz Romanowski wrote: >> >>> Hi, >>> I am reading article "Design implications of Java?s switch statements and >>> switch expressions" [1] by Vasily STRELNIKOV . >>> >>> I am confounded by "*Figure 6.* Handling complex situations with a Switch >>> Expression" which I believe is a new-style Switch Statement as the >>> `default >>> clause` is removable even though Switch is not total. >>> >>> Could you confirm my interpretation? >>> And should it be correct, help to contact author to ask for correction. >>> >>> Cheers, >>> Mateusz Romanowski >>> >>> [1] >>> https://blogs.oracle.com/javamagazine/post/java-switch-state >>> ments-expressions >>> >> >> > -- > > Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com > From forax at univ-mlv.fr Sat Feb 5 11:09:42 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 5 Feb 2022 12:09:42 +0100 (CET) Subject: mistaking switch expressions and switch statements In-Reply-To: References: <5f04a33e-ebfc-8255-34bf-3da0ac3711e8@gmail.com> Message-ID: <809484297.10612960.1644059382152.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Mateusz Romanowski" > To: "cay" > Cc: "amber-dev" > Sent: Saturday, February 5, 2022 11:58:34 AM > Subject: Re: mistaking switch expressions and switch statements > Hi Cay, > Actually, my initial concern was about that figure's mislabeling. > > As for the fall-through, it has become so complicated that I had to use > `javap` to confirm lack of fall-through.. lots of axis, indeed. Yes, we know that there are several cases were a warning may be necessary, default not at the end, fallthrough with no default, switch on enums not total, etc At the same time, we don't want to have too many of them. > > Cheers, > Mateusz regards, R?mi > > On Saturday, February 5, 2022, Cay Horstmann > wrote: > >> The article has other issues. Figure 6 is captioned "Handling complex >> situations with a switch expression" but contains a switch *statement* >> without fall-through. >> >> Another example where the two axis design (statement vs. expression, >> fall-through vs. no fall-through) has not been properly understood. >> >> Cheers, >> >> Cay >> >> On 04/02/2022 22:59, Brian Goetz wrote: >> >>> You are correct that the default can be elided here, because this is a >>> switch statement on a legacy target type whose labels are all constants, >>> and such statements (for reasons of backward compatibility) can be >>> partial. All other switches (new target types, new cases, expressions) >>> should be total. >>> >>> The example actually employs "belts and suspenders"; it initializes >>> `discount` to zero, and then assigns it to zero in the default clause. If >>> discount were left blank, then the default clause would be necessary, not >>> to make the switch total, but to make `discount` definitely assigned. So >>> you could either elide the initializer on `discount`, or the default >>> clause, but not both. >>> >>> On 2/4/2022 4:31 PM, Mateusz Romanowski wrote: >>> >>>> Hi, >>>> I am reading article "Design implications of Java?s switch statements and >>>> switch expressions" [1] by Vasily STRELNIKOV . >>>> >>>> I am confounded by "*Figure 6.* Handling complex situations with a Switch >>>> Expression" which I believe is a new-style Switch Statement as the >>>> `default >>>> clause` is removable even though Switch is not total. >>>> >>>> Could you confirm my interpretation? >>>> And should it be correct, help to contact author to ask for correction. >>>> >>>> Cheers, >>>> Mateusz Romanowski >>>> >>>> [1] >>>> https://blogs.oracle.com/javamagazine/post/java-switch-state >>>> ments-expressions >>>> >>> >>> >> -- >> >> Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From mariell.hoversholm at paf.com Mon Feb 7 06:52:19 2022 From: mariell.hoversholm at paf.com (Mariell Hoversholm) Date: Mon, 7 Feb 2022 07:52:19 +0100 Subject: Constant methods in Java In-Reply-To: References: Message-ID: Hi Alberto, This feels like a rather rare requirement. I prefer making my locals final, but don't see any reason why they would _need_ to be. Could you elaborate on an example use case for this? On Wed, 2 Feb 2022 at 20:33, Alberto Otero Rodr?guez wrote: > I have a suggestion. I think it would be interesting creating constant > methods in Java. > > I mean methods declared like this: > > public const String myMethod() { > String a = "a"; > a = a + "b"; > return a; > } > > So that the response of the method is forced to be assigned to a final > variable. > > This would be ok: > final String b = myMethod(); > > But this would throw a compilation error: > String c = myMethod(); > > What do you think? It's just an idea. > From marc.miranda84 at gmail.com Mon Feb 14 20:53:24 2022 From: marc.miranda84 at gmail.com (Marc Miranda) Date: Mon, 14 Feb 2022 21:53:24 +0100 Subject: JEP proposal: Generic/Interfaced Enums as annotation attributes Message-ID: Dear colleagues, I am not sure this is the appropriate medium, but I would like to propose an enhancement for the JDK, and I am not sure what is the protocol. After seeing this: https://github.com/spring-projects/spring-framework/issues/28046 and this https://stackoverflow.com/questions/1037531/is-there-a-way-to-declare-an-annotation-attribute-for-any-enum, I was wondering whether there is any fundamental block for allowing generic enums or even better, interfaced ones as a type for annotation attribute. I think the language could benefit a lot from something like the following: *enum TestEnum implements Closeable { MY_INSTANCE_A; public void close() {* * (...do stuff...)* * }}* *@Retention(RetentionPolicy.RUNTIME)* *@Target(ElementType.TYPE)public @interface CustomCloserAnnotation {* * X enumClass(); * *}* I am not sure how X would be defined, I guess one of : * - Closeable* * - Enum * * - Enum * * - Enum> * * - Enum & Closeable>* And it would be used as : *@CustomCloserAnnotation(TestEnum.MY_INSTANCE_A)public class MyTestClass {* *(...)* *}* This would trick the system so we could use instances as enum parameters. I am not sure if I am trying to be too smart and it is something already long discussed or even discarded in the past, but from my ignorance I don't see why we should disallow this, and certainly I see a lot of possibilities with this trick, starting with the TestContainers example I provided in the introduction Either way, many thanks for improving the language every day as you do! Regards, Marc From brian.goetz at oracle.com Tue Feb 15 16:12:30 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 15 Feb 2022 11:12:30 -0500 Subject: JEP proposal: Generic/Interfaced Enums as annotation attributes In-Reply-To: References: Message-ID: <04a25fad-cfaa-dd3c-5b63-a980788f48b9@oracle.com> There was a JEP effort, "Enhanced Enums", to attempt to enable generic enums: https://openjdk.java.net/jeps/301 As it turns out, this ran into difficulties: http://cr.openjdk.java.net/~mcimadamore/amber/enhanced-enums.html and the JEP was withdrawn. On 2/14/2022 3:53 PM, Marc Miranda wrote: > Dear colleagues, > > I am not sure this is the appropriate medium, but I would like to propose > an enhancement for the JDK, and I am not sure what is the protocol. > > After seeing this: > https://github.com/spring-projects/spring-framework/issues/28046 and this > https://stackoverflow.com/questions/1037531/is-there-a-way-to-declare-an-annotation-attribute-for-any-enum, > I was wondering whether there is any fundamental block for allowing generic > enums or even better, interfaced ones as a type for annotation attribute. > > I think the language could benefit a lot from something like the following: > > > > > > *enum TestEnum implements Closeable { MY_INSTANCE_A; public void close() > {* > * (...do stuff...)* > > * }}* > > *@Retention(RetentionPolicy.RUNTIME)* > > *@Target(ElementType.TYPE)public @interface CustomCloserAnnotation {* > * X enumClass(); * > *}* > > I am not sure how X would be defined, I guess one of : > * - Closeable* > * - Enum * > * - Enum * > * - Enum> * > * - Enum & Closeable>* > > And it would be used as : > > > *@CustomCloserAnnotation(TestEnum.MY_INSTANCE_A)public class MyTestClass {* > *(...)* > *}* > > This would trick the system so we could use instances as enum parameters. I > am not sure if I am trying to be too smart and it is something already long > discussed or even discarded in the past, but from my ignorance I don't see > why we should disallow this, and certainly I see a lot of possibilities > with this trick, starting with the TestContainers example I provided in the > introduction > > Either way, many thanks for improving the language every day as you do! > > Regards, > > Marc From marc.miranda84 at gmail.com Tue Feb 15 22:04:56 2022 From: marc.miranda84 at gmail.com (Marc Miranda) Date: Tue, 15 Feb 2022 23:04:56 +0100 Subject: JEP proposal: Generic/Interfaced Enums as annotation attributes In-Reply-To: <04a25fad-cfaa-dd3c-5b63-a980788f48b9@oracle.com> References: <04a25fad-cfaa-dd3c-5b63-a980788f48b9@oracle.com> Message-ID: Hi Brian! I am not sure we are talking of the same use case. In my case I am fine with non-generic enums, it is just about letting annotation attributes pass an enum reference One of the options is using an interface, the other is using a generic, but not a generic of the enum instance but the very same generic that defines the enum internally Enum where ? is my Enum not the type of a typed enum The point is being able to trick the system and pass custom instances as annotation attributes. For instance like @CustomAnnotation(MyCutomEnum.TYPE_A_WHICH_IMPLEMENTS_AN_INTERFACE) Regards, Marc El mar, 15 feb 2022 a las 17:12, Brian Goetz () escribi?: > There was a JEP effort, "Enhanced Enums", to attempt to enable generic > enums: > > https://openjdk.java.net/jeps/301 > > As it turns out, this ran into difficulties: > > http://cr.openjdk.java.net/~mcimadamore/amber/enhanced-enums.html > > and the JEP was withdrawn. > > On 2/14/2022 3:53 PM, Marc Miranda wrote: > > Dear colleagues, > > I am not sure this is the appropriate medium, but I would like to propose > an enhancement for the JDK, and I am not sure what is the protocol. > > After seeing this:https://github.com/spring-projects/spring-framework/issues/28046 and thishttps://stackoverflow.com/questions/1037531/is-there-a-way-to-declare-an-annotation-attribute-for-any-enum, > I was wondering whether there is any fundamental block for allowing generic > enums or even better, interfaced ones as a type for annotation attribute. > > I think the language could benefit a lot from something like the following: > > > > > > *enum TestEnum implements Closeable { MY_INSTANCE_A; public void close() > {* > * (...do stuff...)* > > * }}* > > *@Retention(RetentionPolicy.RUNTIME)* > > *@Target(ElementType.TYPE)public @interface CustomCloserAnnotation {* > * X enumClass(); * > *}* > > I am not sure how X would be defined, I guess one of : > * - Closeable* > * - Enum * > * - Enum * > * - Enum> * > * - Enum & Closeable>* > > And it would be used as : > > > *@CustomCloserAnnotation(TestEnum.MY_INSTANCE_A)public class MyTestClass {* > *(...)* > *}* > > This would trick the system so we could use instances as enum parameters. I > am not sure if I am trying to be too smart and it is something already long > discussed or even discarded in the past, but from my ignorance I don't see > why we should disallow this, and certainly I see a lot of possibilities > with this trick, starting with the TestContainers example I provided in the > introduction > > Either way, many thanks for improving the language every day as you do! > > Regards, > > Marc > > > From alex.buckley at oracle.com Tue Feb 15 22:19:03 2022 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 15 Feb 2022 14:19:03 -0800 Subject: JEP proposal: Generic/Interfaced Enums as annotation attributes In-Reply-To: References: <04a25fad-cfaa-dd3c-5b63-a980788f48b9@oracle.com> Message-ID: <356432e2-8f4a-5551-a4ea-f3b273b72f20@oracle.com> On 2/15/2022 2:04 PM, Marc Miranda wrote: > I am not sure we are talking of the same use case. > In my case I am fine with non-generic enums, it is just about letting > annotation attributes pass an enum reference But an annotation can already have enum-typed elements. Here's an example from JLS 9.6.1: @interface Quality { enum Level { BAD, INDIFFERENT, GOOD } Level value(); } @Quality(Quality.Level.BAD) public class Foo {} Alex From brian.goetz at oracle.com Tue Feb 15 22:24:59 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 15 Feb 2022 17:24:59 -0500 Subject: [External] : Re: JEP proposal: Generic/Interfaced Enums as annotation attributes In-Reply-To: References: <04a25fad-cfaa-dd3c-5b63-a980788f48b9@oracle.com> Message-ID: One of the hidden constraints (you can see it if you look carefully at the spec) of annotations is that the annotation are effectively _compile-time constants_.? This is a reflection of the fact that annotations are metaDATA; they're not intended to be anything more than typed carriers for metadata. This is why annotation properties are restricted to primitives, strings, class literals (symbolic constants), enum constants, annotations, and arrays of same.? Similarly, the types of interface properties must be narrowly scoped to one of these; JLS 9.6.1 says that the type must be a primitive type, String, Class, an enum type, an annotation interface type, or an array of one of the above. Over the years we've received hundreds of enhancement requests around annotations, many of which may feel like "small tweaks" -- though which, in the aggregate, would consume the full bandwidth of the language team.? And ultimately, these are symptoms of a larger disease: people want annotations to be something they are not, and were explicitly never meant to be. On 2/15/2022 5:04 PM, Marc Miranda wrote: > Hi Brian! > > I am not sure we are talking of the same use case. > In my case I am fine with non-generic enums, it is just about letting > annotation attributes pass an enum reference > > One of the options is using an interface, the other is using a > generic, but not a generic of the enum instance but the very same > generic that defines the enum internally Enum where ? is my Enum > not the type of a typed enum > > The point is being able to trick the system and pass custom instances > as annotation attributes. For instance like > @CustomAnnotation(MyCutomEnum.TYPE_A_WHICH_IMPLEMENTS_AN_INTERFACE) > > Regards, > Marc > > El mar, 15 feb 2022 a las 17:12, Brian Goetz > () escribi?: > > There was a JEP effort, "Enhanced Enums", to attempt to enable > generic enums: > > https://openjdk.java.net/jeps/301 > > As it turns out, this ran into difficulties: > > http://cr.openjdk.java.net/~mcimadamore/amber/enhanced-enums.html > > and the JEP was withdrawn. > > On 2/14/2022 3:53 PM, Marc Miranda wrote: >> Dear colleagues, >> >> I am not sure this is the appropriate medium, but I would like to propose >> an enhancement for the JDK, and I am not sure what is the protocol. >> >> After seeing this: >> https://github.com/spring-projects/spring-framework/issues/28046 and this >> https://stackoverflow.com/questions/1037531/is-there-a-way-to-declare-an-annotation-attribute-for-any-enum , >> I was wondering whether there is any fundamental block for allowing generic >> enums or even better, interfaced ones as a type for annotation attribute. >> >> I think the language could benefit a lot from something like the following: >> >> >> >> >> >> *enum TestEnum implements Closeable { MY_INSTANCE_A; public void close() >> {* >> * (...do stuff...)* >> >> * }}* >> >> *@Retention(RetentionPolicy.RUNTIME)* >> >> *@Target(ElementType.TYPE)public @interface CustomCloserAnnotation {* >> * X enumClass(); * >> *}* >> >> I am not sure how X would be defined, I guess one of : >> * - Closeable* >> * - Enum * >> * - Enum * >> * - Enum> * >> * - Enum & Closeable>* >> >> And it would be used as : >> >> >> *@CustomCloserAnnotation(TestEnum.MY_INSTANCE_A)public class MyTestClass {* >> *(...)* >> *}* >> >> This would trick the system so we could use instances as enum parameters. I >> am not sure if I am trying to be too smart and it is something already long >> discussed or even discarded in the past, but from my ignorance I don't see >> why we should disallow this, and certainly I see a lot of possibilities >> with this trick, starting with the TestContainers example I provided in the >> introduction >> >> Either way, many thanks for improving the language every day as you do! >> >> Regards, >> >> Marc > From marc.miranda84 at gmail.com Wed Feb 16 00:26:59 2022 From: marc.miranda84 at gmail.com (Marc Miranda) Date: Wed, 16 Feb 2022 01:26:59 +0100 Subject: JEP proposal: Generic/Interfaced Enums as annotation attributes In-Reply-To: <356432e2-8f4a-5551-a4ea-f3b273b72f20@oracle.com> References: <04a25fad-cfaa-dd3c-5b63-a980788f48b9@oracle.com> <356432e2-8f4a-5551-a4ea-f3b273b72f20@oracle.com> Message-ID: But you need to know the type beforehand, it cannot be a generic/interfaced enum Imagine you are designing an API and you want to let the user to specify the Quality, but you don't want to impose him the particular enum so he can add behaviour (implementing the quality). In this case, you would like to define your Quality annotation so it accepts any enum that implements a isEnoughQuality() On the API side: ****************** @interface Quality { Enum value(); } interface Qualititable { boolean isEnoughQuality(); } On the Client User Side: **************************** @RequiredArgsConstructor public enum MyCustomQualities implement Qualiitiable { MY_CUSTOM_LOW_QUALITY(() -> false), MY_CUSTOM_MEDIUM_QUALITY(() -> RandomUtils.getBoolean()), MY_CUSTOM_HIGH_QUALITY(() -> true); private final Supplier qualityEvaluator; @Override public isEnoughQuality() { return qualityEvaluator.get(); } } Then you could use it like @Quality(MyCustomQualities.LOW) public void class Test { (...) } El mar, 15 feb 2022 a las 23:19, Alex Buckley () escribi?: > On 2/15/2022 2:04 PM, Marc Miranda wrote: > > I am not sure we are talking of the same use case. > > In my case I am fine with non-generic enums, it is just about letting > > annotation attributes pass an enum reference > > But an annotation can already have enum-typed elements. Here's an > example from JLS 9.6.1: > > @interface Quality { > enum Level { BAD, INDIFFERENT, GOOD } > Level value(); > } > > @Quality(Quality.Level.BAD) public class Foo {} > > Alex > From marc.miranda84 at gmail.com Wed Feb 16 00:30:16 2022 From: marc.miranda84 at gmail.com (Marc Miranda) Date: Wed, 16 Feb 2022 01:30:16 +0100 Subject: [External] : Re: JEP proposal: Generic/Interfaced Enums as annotation attributes In-Reply-To: References: <04a25fad-cfaa-dd3c-5b63-a980788f48b9@oracle.com> Message-ID: I guess somehow I see the spirit is kept, since it is still an enum, which is already allowed. But it is only about allowing to refer to that enum by an interface, not by the exact type, so any custom enum that accomplishes the contract is good enough for the annotation processor El mar, 15 feb 2022 a las 23:25, Brian Goetz () escribi?: > One of the hidden constraints (you can see it if you look carefully at the > spec) of annotations is that the annotation are effectively _compile-time > constants_. This is a reflection of the fact that annotations are > metaDATA; they're not intended to be anything more than typed carriers for > metadata. > > This is why annotation properties are restricted to primitives, strings, > class literals (symbolic constants), enum constants, annotations, and > arrays of same. Similarly, the types of interface properties must be > narrowly scoped to one of these; JLS 9.6.1 says that the type must be a > primitive type, String, Class, an enum type, an annotation interface type, > or an array of one of the above. > > Over the years we've received hundreds of enhancement requests around > annotations, many of which may feel like "small tweaks" -- though which, in > the aggregate, would consume the full bandwidth of the language team. And > ultimately, these are symptoms of a larger disease: people want annotations > to be something they are not, and were explicitly never meant to be. > > On 2/15/2022 5:04 PM, Marc Miranda wrote: > > Hi Brian! > > I am not sure we are talking of the same use case. > In my case I am fine with non-generic enums, it is just about letting > annotation attributes pass an enum reference > > One of the options is using an interface, the other is using a generic, > but not a generic of the enum instance but the very same generic that > defines the enum internally Enum where ? is my Enum not the type of a > typed enum > > The point is being able to trick the system and pass custom instances as > annotation attributes. For instance like > @CustomAnnotation(MyCutomEnum.TYPE_A_WHICH_IMPLEMENTS_AN_INTERFACE) > > Regards, > Marc > > El mar, 15 feb 2022 a las 17:12, Brian Goetz () > escribi?: > >> There was a JEP effort, "Enhanced Enums", to attempt to enable generic >> enums: >> >> https://openjdk.java.net/jeps/301 >> >> As it turns out, this ran into difficulties: >> >> http://cr.openjdk.java.net/~mcimadamore/amber/enhanced-enums.html >> >> and the JEP was withdrawn. >> >> On 2/14/2022 3:53 PM, Marc Miranda wrote: >> >> Dear colleagues, >> >> I am not sure this is the appropriate medium, but I would like to propose >> an enhancement for the JDK, and I am not sure what is the protocol. >> >> After seeing this:https://github.com/spring-projects/spring-framework/issues/28046 and thishttps://stackoverflow.com/questions/1037531/is-there-a-way-to-declare-an-annotation-attribute-for-any-enum , >> I was wondering whether there is any fundamental block for allowing generic >> enums or even better, interfaced ones as a type for annotation attribute. >> >> I think the language could benefit a lot from something like the following: >> >> >> >> >> >> *enum TestEnum implements Closeable { MY_INSTANCE_A; public void close() >> {* >> * (...do stuff...)* >> >> * }}* >> >> *@Retention(RetentionPolicy.RUNTIME)* >> >> *@Target(ElementType.TYPE)public @interface CustomCloserAnnotation {* >> * X enumClass(); * >> *}* >> >> I am not sure how X would be defined, I guess one of : >> * - Closeable* >> * - Enum * >> * - Enum * >> * - Enum> * >> * - Enum & Closeable>* >> >> And it would be used as : >> >> >> *@CustomCloserAnnotation(TestEnum.MY_INSTANCE_A)public class MyTestClass {* >> *(...)* >> *}* >> >> This would trick the system so we could use instances as enum parameters. I >> am not sure if I am trying to be too smart and it is something already long >> discussed or even discarded in the past, but from my ignorance I don't see >> why we should disallow this, and certainly I see a lot of possibilities >> with this trick, starting with the TestContainers example I provided in the >> introduction >> >> Either way, many thanks for improving the language every day as you do! >> >> Regards, >> >> Marc >> >> >> > From alex.buckley at oracle.com Wed Feb 16 01:40:35 2022 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 15 Feb 2022 17:40:35 -0800 Subject: [External] : Re: JEP proposal: Generic/Interfaced Enums as annotation attributes In-Reply-To: References: <04a25fad-cfaa-dd3c-5b63-a980788f48b9@oracle.com> <356432e2-8f4a-5551-a4ea-f3b273b72f20@oracle.com> Message-ID: OK, I see the abstraction you want. There are two ways of looking at it: 1. An annotation interface element ought to be able to be declared with an interface type, not just the primitive types, String, enum types, etc. Per Brian, this takes the element outside the realm of compile-time constants, so it's not in the spirit of annotations. 2. An enum class ought to be subclassable by another enum class. Qualititable would be an enum class with no constants and one abstract method, and Q1 and Q2 would be enum classes that extend Qualititable. Your Quality annotation interface would declare `Qualititable value()` (the element has an enum class type, as required!) and you would write @Quality(Q1.LOW_QUALITY) and @Quality(Q2.POOR_QUALITY). However, the JSR that created enum classes, JSR 201, included a FAQ that basically says subclassing is not in the spirit of enums: ----- With the Typesafe Enum pattern described in Effective Java, it is possible to subclass an enumerated type. Why is this not allowed by the language feature? The semantics of inheritance for enum types is too confusing. People expect subclasses to contain the enumeration constants from both the superclass and the subclass, but they contain only the subclass constants. Further, the compiler generates two static methods for each enum class providing operations on the entire class (values() and valueOf(String)). These methods are defined using the list of constants found in the enum declaration, hence subclassing would break them. More seriously, allowing subclassing of enums would render switch statements ambiguous if multiple subclasses of an enum class contained enum constants with the same simple name. All things considered, the complexity inherent in allowing subclassing is too great to justify it. ----- It's easy to look at these constraints and say "Annotations and enums in Java would be more successful if the constraints were relaxed", but good design adds value faster than it adds cost, and designing away the constraints would (for sure) add cost faster than it adds value. Alex On 2/15/2022 4:26 PM, Marc Miranda wrote: > But you need to know the type beforehand, it cannot be a > generic/interfaced enum > > Imagine you are designing an API and you want to let the user to specify > the Quality, but you don't want to impose him the particular enum so he > can add behaviour (implementing the quality). > In this case, you would like to define your Quality annotation so it > accepts any enum that implements a isEnoughQuality() > > On the API side: > ****************** > > @interface Quality { > ? ? ?Enum value(); > } > > interface Qualititable { > ? ? boolean isEnoughQuality(); > } > > On the Client User Side: > **************************** > > @RequiredArgsConstructor > public enum MyCustomQualities implement Qualiitiable { > ? ? ?MY_CUSTOM_LOW_QUALITY(() -> false), > ? ? ?MY_CUSTOM_MEDIUM_QUALITY(() -> RandomUtils.getBoolean()), > ? ? ?MY_CUSTOM_HIGH_QUALITY(() -> true); > > ? ? private final Supplier qualityEvaluator; > > ? ??@Override > ? ? public isEnoughQuality() { > ? ? ? ? return qualityEvaluator.get(); > ? ? } > } > > > Then you could use it like > > @Quality(MyCustomQualities.LOW) > public void class Test { > ? (...) > } > > El mar, 15 feb 2022 a las 23:19, Alex Buckley ( >) escribi?: > > On 2/15/2022 2:04 PM, Marc Miranda wrote: > > I am not sure we are talking of the same use case. > > In my case I am fine with non-generic enums, it is just about letting > > annotation attributes pass an enum reference > > But an annotation can already have enum-typed elements. Here's an > example from JLS 9.6.1: > > @interface Quality { > ? ? ?enum Level { BAD, INDIFFERENT, GOOD } > ? ? ?Level value(); > } > > @Quality(Quality.Level.BAD) public class Foo {} > > Alex >