<div dir="auto">Hold on, I thought this was the entire purpose of refactoring an enum into a class?<div dir="auto"><br></div><div dir="auto">If all of the values do NOT have the same method, then by definition, they are not of the same type. The nature of an anonymous class is to, effectively, announce that you are making a new type that, if they are in the same scope, can use these new things you are defining on the anonymous type. But, because it is anonymous, then by definition,they have no way to access this UNLESS THOSE WISHING TO ACCESS ARE IN THE SAME COMPILATION UNIT. This is scope access.</div><div dir="auto"><br></div><div dir="auto">I think you are complecting the scope access with what abilities the anonymous class grants you. The anonymous class does not have the ability to effectively add to its public api. The fact that you can add a public method to an anonymous class is a very sharp edge that cuts a lot of developers. Yes, you can put a public method there, but it is almost entirely redundant. You cannot reference that public method because the only way to reference that public method is by having the type name. Since it is anonymous, then by definition, you can't. You must associate that method to a named type (for example, an interface) in order to be able to use your new public method. But by that point, it's not your anonymous class that added to the public api, it's the interface. Very sharp edge that should be removed in my firm opinion.</div><div dir="auto"><br></div><div dir="auto">At best, anonymous classes can modify the implementation of its public api, potentially. However, being in the same compilation unit/scope allows you to view fields and methods that you add to that anonymous class.</div><div dir="auto"><br></div><div dir="auto">Let me know if that doesn't make sense. But by definition, the thing you are trying to do is not attainable by anonymous classes alone. It would require some other mechanism to be introduced or used to introduce your method name into scope. And at that point, it would not be the anonymous class making this possible.</div><div dir="auto"><br></div><div dir="auto">But maybe I am completely wrong. I spent a couple frustrated months trying to do exactly what you are doing. Maybe something was added in the past few releases that made this now possible.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 21, 2024, 1:02 PM Red IO <<a href="mailto:redio.development@gmail.com">redio.development@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">This is nice and well. But it isn't the same thing. Sure this works well if every varient does exactly the same thing. But say you have a enum having varients that share a feature but have their own unique properties. Like a rule set to initialize something and an associated constants or operation that only makes sense for 1 varient. Currently you need to define both public constants and public methods in the enum associating it with the whole enum instead of the varient that works with it. In methods that gets even worse as you need to provide a default operation that either does nothing or throws for incompatible varients. By simply typing the enum constant to the anonymous class this would become possible.<div dir="auto"><br></div><div dir="auto">Great regards </div><div dir="auto">RedIODev </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 21, 2024, 14:49 David Alayachew <<a href="mailto:davidalayachew@gmail.com" target="_blank" rel="noreferrer">davidalayachew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="auto"><div><span style="font-family:monospace">Idk which is the right group, but I choose amber.</span><div dir="auto"><span style="font-family:monospace"><br></span></div><div dir="auto"><span style="font-family:monospace">I just want to add a couple of clarifications on the various different forms (I spend a LOT of my time woth enums).</span></div></div><div><br></div><div><ul><li><span class="gmail_default" style="font-family:monospace">You can use an abstract method like so. It has the benefit of forcing every enum value to provide their own implementation of the abstract method. Think of it like a switch with no default clause.</span></li></ul><div><div style="font-family:monospace" class="gmail_default"><br>enum Blah<br>{<br><br> VALUE1<br> {<br> <br> void method()<br> {<br> <br> println("blah");<br> <br> }<br><br> },<br> ;<br> <br> abstract void method();<br><br>}</div><br></div></div><ul><li><span class="gmail_default" style="font-family:monospace">Alternatively, you can provide an implementation of the method. This is more like a switch with a default clause.</span></li></ul><div><div style="font-family:monospace" class="gmail_default">
<div style="font-family:monospace" class="gmail_default"><br>enum Blah<br>{<br><br> VALUE1<br> {<br> <br> void method()<br> {<br> <br> println("blah");<br> <br> }<br><br> },<br> ;<br> <br> void method()</div><div style="font-family:monospace" class="gmail_default"> {</div><div style="font-family:monospace" class="gmail_default"> </div><div style="font-family:monospace" class="gmail_default"> println("default");</div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default"> }</div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">}</div>
</div></div><div><br></div><div><ul><li><span class="gmail_default" style="font-family:monospace">And of course, you could model this externally via a switch case. Both of the above bullets are modelable as switch expressions (as explained already). The benefit is that they can keep the enum simple, but the cost is that you must explicitly know the implementation you want instead of having one provided for you.</span></li></ul><div><div style="font-family:monospace" class="gmail_default"><br></div><br></div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 21, 2024, 7:14 AM Pavel Rappo <<a href="mailto:pavel.rappo@oracle.com" rel="noreferrer noreferrer" target="_blank">pavel.rappo@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">From <a href="https://mail.openjdk.org/mailman/listinfo/discuss" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://mail.openjdk.org/mailman/listinfo/discuss</a>, this mailing list is not suitable for questions like this. I'm not sure which mailing list is *the most* suitable, but the following one is surely more suitable: <a href="https://mail.openjdk.org/pipermail/amber-dev/" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://mail.openjdk.org/pipermail/amber-dev/</a> (CC'ed).<br>
<br>
I believe, the reasons why the first snippet of yours works, but the second doesn't, is covered here:<br>
<br>
* <a href="https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.9.1" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.9.1</a> (like you said)<br>
* <a href="https://docs.oracle.com/javase/specs/jls/se21/html/jls-14.html#jls-14.4.1" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://docs.oracle.com/javase/specs/jls/se21/html/jls-14.html#jls-14.4.1</a><br>
<br>
I would be surprised if that could change to allow your second snippet. That said, if that functionality is truly required, you can provide it yourself.<br>
<br>
The design of enums allows you to declare a method on an enum class and then override it in a particular constant. Alternatively, you can switch on an enum constant to provide constant-specific behaviour "externally".<br>
<br>
-Pavel<br>
<br>
> On 21 Feb 2024, at 10:08, Red IO <<a href="mailto:redio.development@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">redio.development@gmail.com</a>> wrote:<br>
> <br>
> I recently tinkered a bit with java enums. While I was researching edge features enums support I came across a stackoverflow post referencing the JLS 8.9 saying that the optional body of an enum constant is an anonymous class declaration. <br>
> As for some time now methods declared in an anonymous class assigned to a var variable are accessible I tried to do the same for the enum constant. <br>
> <br>
> var anonymous = new Object() {<br>
> public void test() {} <br>
> }<br>
> anonymous.test(); //works<br>
> <br>
> <br>
> enum Test {<br>
> A {<br>
> public void test() {} <br>
> } <br>
> }<br>
> var enumConstant = Test.A;<br>
> enumConstant.test(); // doesn't work<br>
> <br>
> I have a clue to why this doesn't work. It's likely that the type of the constant A is the type of the enum and not of the anonymous class. <br>
> <br>
> There are some usecases where exclusive methods on enum constants might be useful. So it would be nice if this would work. <br>
> <br>
> Great regards <br>
> RedIODev <br>
> <br>
> <br>
> <br>
> <br>
<br>
</blockquote></div></div></div>
</div>
</blockquote></div>
</blockquote></div>