Anonymous-Inner classes showing unwanted modifier












38















To my understanding, the following code should have printed true.



However, when I ran this code it is printing false.



From Java docs of Anonymous Classes 15.9.5. :




An anonymous class is always implicitly final




public class Test {
public static void main(String args) {
Object o = new Object() {
};
System.out.println("Annonymous class is final: " + Modifier.isFinal(o.getClass().getModifiers()));
}
}


Can some one please help me understand this behavior.










share|improve this question





























    38















    To my understanding, the following code should have printed true.



    However, when I ran this code it is printing false.



    From Java docs of Anonymous Classes 15.9.5. :




    An anonymous class is always implicitly final




    public class Test {
    public static void main(String args) {
    Object o = new Object() {
    };
    System.out.println("Annonymous class is final: " + Modifier.isFinal(o.getClass().getModifiers()));
    }
    }


    Can some one please help me understand this behavior.










    share|improve this question



























      38












      38








      38


      2






      To my understanding, the following code should have printed true.



      However, when I ran this code it is printing false.



      From Java docs of Anonymous Classes 15.9.5. :




      An anonymous class is always implicitly final




      public class Test {
      public static void main(String args) {
      Object o = new Object() {
      };
      System.out.println("Annonymous class is final: " + Modifier.isFinal(o.getClass().getModifiers()));
      }
      }


      Can some one please help me understand this behavior.










      share|improve this question
















      To my understanding, the following code should have printed true.



      However, when I ran this code it is printing false.



      From Java docs of Anonymous Classes 15.9.5. :




      An anonymous class is always implicitly final




      public class Test {
      public static void main(String args) {
      Object o = new Object() {
      };
      System.out.println("Annonymous class is final: " + Modifier.isFinal(o.getClass().getModifiers()));
      }
      }


      Can some one please help me understand this behavior.







      java final anonymous-class jls






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 3 at 13:37









      Andrew Tobilko

      27k104285




      27k104285










      asked Jan 3 at 9:10









      Show StopperShow Stopper

      5,1151964




      5,1151964
























          4 Answers
          4






          active

          oldest

          votes


















          41














          Note that the wording in the JLS of that particular section has changed significantly since then. It now (JLS 11) reads:



          15.9.5. Anonymous Class Declarations:




          An anonymous class is never final (§8.1.1.2).



          The fact that an anonymous class is not final is relevant in casting, in particular the narrowing reference conversion allowed for the cast operator (§5.5). It is also of interest in subclassing, in that it is impossible to declare a subclass of an anonymous class, despite an anonymous class being non-final, because an anonymous class cannot be named by an extends clause (§8.1.4).




          This change in wording was introduced in JLS 9. The semantics of anonymous classes and the behavior of the methods in the question remained unchanged, the intention was to avoid exactly the kind of confusion this question is about.



          The ticket that caused the change says:




          Longstanding behavior of javac, since 1.3, has been, for the most part, not to treat the classes as 'final'. To address this inconsistency, the specification should be changed to accurately reflect the reference implementation.



          Specifically, anonymous classes are almost never generated with the ACC_FINAL flag set. We can't change this longstanding behavior without impacting some serialization clients (this would be permissible, but is unnecessarily disruptive). And we can't faithfully implement Class.getModifers (which promises to provide the "Java language modifiers") without the class files encoding the language's modifiers.







          share|improve this answer





















          • 2





            Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).

            – Jacob Raihle
            Jan 3 at 16:05






          • 1





            Yeah, the good old “change the specification to match what our … implementation does”…

            – Holger
            Jan 9 at 11:27



















          8















          An anonymous class is never final (§8.1.1.2).



          JLS 11 - 15.9.5. Anonymous Class Declarations




          I didn't know the reasoning behind this, but, according to @Hulk's answer and this bug report, it seems the specification of previous versions slightly misled us saying that anonymous classes are final.






          share|improve this answer





















          • 3





            You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.

            – Michael
            Jan 3 at 9:26





















          7














          Anonymous classes are considered implicitly final since you can't create sub-classes of them. That doesn't mean that the Modifier.FINAL modifier should be set for anonymous classes.






          share|improve this answer
























          • When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java

            – Show Stopper
            Jan 3 at 10:32






          • 1





            @ShowStopper well, it does follow the rules of final: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.

            – Moira
            Jan 3 at 10:40



















          -2














          See Javadoc of Class.getModifiers():
          https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getModifiers()



          It says "...The values of its other modifiers are not determined by this specification".






          share|improve this answer























            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54019203%2fanonymous-inner-classes-showing-unwanted-modifier%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            4 Answers
            4






            active

            oldest

            votes








            4 Answers
            4






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            41














            Note that the wording in the JLS of that particular section has changed significantly since then. It now (JLS 11) reads:



            15.9.5. Anonymous Class Declarations:




            An anonymous class is never final (§8.1.1.2).



            The fact that an anonymous class is not final is relevant in casting, in particular the narrowing reference conversion allowed for the cast operator (§5.5). It is also of interest in subclassing, in that it is impossible to declare a subclass of an anonymous class, despite an anonymous class being non-final, because an anonymous class cannot be named by an extends clause (§8.1.4).




            This change in wording was introduced in JLS 9. The semantics of anonymous classes and the behavior of the methods in the question remained unchanged, the intention was to avoid exactly the kind of confusion this question is about.



            The ticket that caused the change says:




            Longstanding behavior of javac, since 1.3, has been, for the most part, not to treat the classes as 'final'. To address this inconsistency, the specification should be changed to accurately reflect the reference implementation.



            Specifically, anonymous classes are almost never generated with the ACC_FINAL flag set. We can't change this longstanding behavior without impacting some serialization clients (this would be permissible, but is unnecessarily disruptive). And we can't faithfully implement Class.getModifers (which promises to provide the "Java language modifiers") without the class files encoding the language's modifiers.







            share|improve this answer





















            • 2





              Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).

              – Jacob Raihle
              Jan 3 at 16:05






            • 1





              Yeah, the good old “change the specification to match what our … implementation does”…

              – Holger
              Jan 9 at 11:27
















            41














            Note that the wording in the JLS of that particular section has changed significantly since then. It now (JLS 11) reads:



            15.9.5. Anonymous Class Declarations:




            An anonymous class is never final (§8.1.1.2).



            The fact that an anonymous class is not final is relevant in casting, in particular the narrowing reference conversion allowed for the cast operator (§5.5). It is also of interest in subclassing, in that it is impossible to declare a subclass of an anonymous class, despite an anonymous class being non-final, because an anonymous class cannot be named by an extends clause (§8.1.4).




            This change in wording was introduced in JLS 9. The semantics of anonymous classes and the behavior of the methods in the question remained unchanged, the intention was to avoid exactly the kind of confusion this question is about.



            The ticket that caused the change says:




            Longstanding behavior of javac, since 1.3, has been, for the most part, not to treat the classes as 'final'. To address this inconsistency, the specification should be changed to accurately reflect the reference implementation.



            Specifically, anonymous classes are almost never generated with the ACC_FINAL flag set. We can't change this longstanding behavior without impacting some serialization clients (this would be permissible, but is unnecessarily disruptive). And we can't faithfully implement Class.getModifers (which promises to provide the "Java language modifiers") without the class files encoding the language's modifiers.







            share|improve this answer





















            • 2





              Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).

              – Jacob Raihle
              Jan 3 at 16:05






            • 1





              Yeah, the good old “change the specification to match what our … implementation does”…

              – Holger
              Jan 9 at 11:27














            41












            41








            41







            Note that the wording in the JLS of that particular section has changed significantly since then. It now (JLS 11) reads:



            15.9.5. Anonymous Class Declarations:




            An anonymous class is never final (§8.1.1.2).



            The fact that an anonymous class is not final is relevant in casting, in particular the narrowing reference conversion allowed for the cast operator (§5.5). It is also of interest in subclassing, in that it is impossible to declare a subclass of an anonymous class, despite an anonymous class being non-final, because an anonymous class cannot be named by an extends clause (§8.1.4).




            This change in wording was introduced in JLS 9. The semantics of anonymous classes and the behavior of the methods in the question remained unchanged, the intention was to avoid exactly the kind of confusion this question is about.



            The ticket that caused the change says:




            Longstanding behavior of javac, since 1.3, has been, for the most part, not to treat the classes as 'final'. To address this inconsistency, the specification should be changed to accurately reflect the reference implementation.



            Specifically, anonymous classes are almost never generated with the ACC_FINAL flag set. We can't change this longstanding behavior without impacting some serialization clients (this would be permissible, but is unnecessarily disruptive). And we can't faithfully implement Class.getModifers (which promises to provide the "Java language modifiers") without the class files encoding the language's modifiers.







            share|improve this answer















            Note that the wording in the JLS of that particular section has changed significantly since then. It now (JLS 11) reads:



            15.9.5. Anonymous Class Declarations:




            An anonymous class is never final (§8.1.1.2).



            The fact that an anonymous class is not final is relevant in casting, in particular the narrowing reference conversion allowed for the cast operator (§5.5). It is also of interest in subclassing, in that it is impossible to declare a subclass of an anonymous class, despite an anonymous class being non-final, because an anonymous class cannot be named by an extends clause (§8.1.4).




            This change in wording was introduced in JLS 9. The semantics of anonymous classes and the behavior of the methods in the question remained unchanged, the intention was to avoid exactly the kind of confusion this question is about.



            The ticket that caused the change says:




            Longstanding behavior of javac, since 1.3, has been, for the most part, not to treat the classes as 'final'. To address this inconsistency, the specification should be changed to accurately reflect the reference implementation.



            Specifically, anonymous classes are almost never generated with the ACC_FINAL flag set. We can't change this longstanding behavior without impacting some serialization clients (this would be permissible, but is unnecessarily disruptive). And we can't faithfully implement Class.getModifers (which promises to provide the "Java language modifiers") without the class files encoding the language's modifiers.








            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jan 3 at 9:42

























            answered Jan 3 at 9:23









            HulkHulk

            3,04712040




            3,04712040








            • 2





              Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).

              – Jacob Raihle
              Jan 3 at 16:05






            • 1





              Yeah, the good old “change the specification to match what our … implementation does”…

              – Holger
              Jan 9 at 11:27














            • 2





              Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).

              – Jacob Raihle
              Jan 3 at 16:05






            • 1





              Yeah, the good old “change the specification to match what our … implementation does”…

              – Holger
              Jan 9 at 11:27








            2




            2





            Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).

            – Jacob Raihle
            Jan 3 at 16:05





            Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).

            – Jacob Raihle
            Jan 3 at 16:05




            1




            1





            Yeah, the good old “change the specification to match what our … implementation does”…

            – Holger
            Jan 9 at 11:27





            Yeah, the good old “change the specification to match what our … implementation does”…

            – Holger
            Jan 9 at 11:27













            8















            An anonymous class is never final (§8.1.1.2).



            JLS 11 - 15.9.5. Anonymous Class Declarations




            I didn't know the reasoning behind this, but, according to @Hulk's answer and this bug report, it seems the specification of previous versions slightly misled us saying that anonymous classes are final.






            share|improve this answer





















            • 3





              You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.

              – Michael
              Jan 3 at 9:26


















            8















            An anonymous class is never final (§8.1.1.2).



            JLS 11 - 15.9.5. Anonymous Class Declarations




            I didn't know the reasoning behind this, but, according to @Hulk's answer and this bug report, it seems the specification of previous versions slightly misled us saying that anonymous classes are final.






            share|improve this answer





















            • 3





              You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.

              – Michael
              Jan 3 at 9:26
















            8












            8








            8








            An anonymous class is never final (§8.1.1.2).



            JLS 11 - 15.9.5. Anonymous Class Declarations




            I didn't know the reasoning behind this, but, according to @Hulk's answer and this bug report, it seems the specification of previous versions slightly misled us saying that anonymous classes are final.






            share|improve this answer
















            An anonymous class is never final (§8.1.1.2).



            JLS 11 - 15.9.5. Anonymous Class Declarations




            I didn't know the reasoning behind this, but, according to @Hulk's answer and this bug report, it seems the specification of previous versions slightly misled us saying that anonymous classes are final.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jan 3 at 9:57

























            answered Jan 3 at 9:22









            Andrew TobilkoAndrew Tobilko

            27k104285




            27k104285








            • 3





              You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.

              – Michael
              Jan 3 at 9:26
















            • 3





              You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.

              – Michael
              Jan 3 at 9:26










            3




            3





            You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.

            – Michael
            Jan 3 at 9:26







            You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.

            – Michael
            Jan 3 at 9:26













            7














            Anonymous classes are considered implicitly final since you can't create sub-classes of them. That doesn't mean that the Modifier.FINAL modifier should be set for anonymous classes.






            share|improve this answer
























            • When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java

              – Show Stopper
              Jan 3 at 10:32






            • 1





              @ShowStopper well, it does follow the rules of final: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.

              – Moira
              Jan 3 at 10:40
















            7














            Anonymous classes are considered implicitly final since you can't create sub-classes of them. That doesn't mean that the Modifier.FINAL modifier should be set for anonymous classes.






            share|improve this answer
























            • When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java

              – Show Stopper
              Jan 3 at 10:32






            • 1





              @ShowStopper well, it does follow the rules of final: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.

              – Moira
              Jan 3 at 10:40














            7












            7








            7







            Anonymous classes are considered implicitly final since you can't create sub-classes of them. That doesn't mean that the Modifier.FINAL modifier should be set for anonymous classes.






            share|improve this answer













            Anonymous classes are considered implicitly final since you can't create sub-classes of them. That doesn't mean that the Modifier.FINAL modifier should be set for anonymous classes.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jan 3 at 9:15









            EranEran

            281k37455541




            281k37455541













            • When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java

              – Show Stopper
              Jan 3 at 10:32






            • 1





              @ShowStopper well, it does follow the rules of final: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.

              – Moira
              Jan 3 at 10:40



















            • When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java

              – Show Stopper
              Jan 3 at 10:32






            • 1





              @ShowStopper well, it does follow the rules of final: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.

              – Moira
              Jan 3 at 10:40

















            When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java

            – Show Stopper
            Jan 3 at 10:32





            When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java

            – Show Stopper
            Jan 3 at 10:32




            1




            1





            @ShowStopper well, it does follow the rules of final: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.

            – Moira
            Jan 3 at 10:40





            @ShowStopper well, it does follow the rules of final: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.

            – Moira
            Jan 3 at 10:40











            -2














            See Javadoc of Class.getModifiers():
            https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getModifiers()



            It says "...The values of its other modifiers are not determined by this specification".






            share|improve this answer




























              -2














              See Javadoc of Class.getModifiers():
              https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getModifiers()



              It says "...The values of its other modifiers are not determined by this specification".






              share|improve this answer


























                -2












                -2








                -2







                See Javadoc of Class.getModifiers():
                https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getModifiers()



                It says "...The values of its other modifiers are not determined by this specification".






                share|improve this answer













                See Javadoc of Class.getModifiers():
                https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getModifiers()



                It says "...The values of its other modifiers are not determined by this specification".







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Jan 3 at 9:40









                Prasad KarunagodaPrasad Karunagoda

                57936




                57936






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54019203%2fanonymous-inner-classes-showing-unwanted-modifier%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Human spaceflight

                    Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

                    張江高科駅