Java can not figure out the method to be invoked












3















I haven't found the reason (in JLS) why java compiler can't chouse appropriate method to execute in following program:



public class UpperLevelClass {
private static String getStringanotherNameMethod(String a, String b) {
return null;
}

private static String firstSignatureMethod(String a, String b) {
return null;
}

static class StaticNestedClass extends UpperLevelClass{
public void getStringfirstNameMethod(String a, Integer b) {
getStringanotherNameMethod("test", "fff");//compiles
firstNameMethod("test", "fff");//error below
}
}
}


Compiling finishes with following error:



error: method firstNameMethod in class StaticNestedClass cannot be applied to given types;
firstNameMethod("test", "fff");
^
required: String,Integer
found: String,String
reason: argument mismatch; String cannot be converted to Integer




Adding some history:



At first I had several static method with default access in upper level calls and everething compiles and runs(from static nested class) fine. Then static methods access was changed to private and programm stops compiling due to error in one method (in this case firstNameMethod), but other methods compiles fine.





I have tried(thx to @Jorn Vernee) to compile and run programm in Eclipse and it compiles and runs.










share|improve this question

























  • Does UpperLevelClass.getString(...); works?

    – Progman
    Nov 18 '18 at 20:04






  • 1





    Eclipse compiles this fine, but javac fails. Hm...

    – Jorn Vernee
    Nov 18 '18 at 20:15











  • Just tossing an idea into the bin for consideration. Does this have to do with the fact that the the method declared in the parent class have a static modifier, while the child's declaration does not?

    – PhaseRush
    Nov 18 '18 at 21:56











  • @Jorn Vernee, intresting - is true Eclips(EJC) compiles and runs fine when javac fails with error.

    – Mikhailov Valentine
    Nov 19 '18 at 20:52











  • If you have an answer to your question you can add it below and accept it. Changing your question to incorporate an answer isn't acceptable.

    – Makoto
    Nov 19 '18 at 21:19
















3















I haven't found the reason (in JLS) why java compiler can't chouse appropriate method to execute in following program:



public class UpperLevelClass {
private static String getStringanotherNameMethod(String a, String b) {
return null;
}

private static String firstSignatureMethod(String a, String b) {
return null;
}

static class StaticNestedClass extends UpperLevelClass{
public void getStringfirstNameMethod(String a, Integer b) {
getStringanotherNameMethod("test", "fff");//compiles
firstNameMethod("test", "fff");//error below
}
}
}


Compiling finishes with following error:



error: method firstNameMethod in class StaticNestedClass cannot be applied to given types;
firstNameMethod("test", "fff");
^
required: String,Integer
found: String,String
reason: argument mismatch; String cannot be converted to Integer




Adding some history:



At first I had several static method with default access in upper level calls and everething compiles and runs(from static nested class) fine. Then static methods access was changed to private and programm stops compiling due to error in one method (in this case firstNameMethod), but other methods compiles fine.





I have tried(thx to @Jorn Vernee) to compile and run programm in Eclipse and it compiles and runs.










share|improve this question

























  • Does UpperLevelClass.getString(...); works?

    – Progman
    Nov 18 '18 at 20:04






  • 1





    Eclipse compiles this fine, but javac fails. Hm...

    – Jorn Vernee
    Nov 18 '18 at 20:15











  • Just tossing an idea into the bin for consideration. Does this have to do with the fact that the the method declared in the parent class have a static modifier, while the child's declaration does not?

    – PhaseRush
    Nov 18 '18 at 21:56











  • @Jorn Vernee, intresting - is true Eclips(EJC) compiles and runs fine when javac fails with error.

    – Mikhailov Valentine
    Nov 19 '18 at 20:52











  • If you have an answer to your question you can add it below and accept it. Changing your question to incorporate an answer isn't acceptable.

    – Makoto
    Nov 19 '18 at 21:19














3












3








3


0






I haven't found the reason (in JLS) why java compiler can't chouse appropriate method to execute in following program:



public class UpperLevelClass {
private static String getStringanotherNameMethod(String a, String b) {
return null;
}

private static String firstSignatureMethod(String a, String b) {
return null;
}

static class StaticNestedClass extends UpperLevelClass{
public void getStringfirstNameMethod(String a, Integer b) {
getStringanotherNameMethod("test", "fff");//compiles
firstNameMethod("test", "fff");//error below
}
}
}


Compiling finishes with following error:



error: method firstNameMethod in class StaticNestedClass cannot be applied to given types;
firstNameMethod("test", "fff");
^
required: String,Integer
found: String,String
reason: argument mismatch; String cannot be converted to Integer




Adding some history:



At first I had several static method with default access in upper level calls and everething compiles and runs(from static nested class) fine. Then static methods access was changed to private and programm stops compiling due to error in one method (in this case firstNameMethod), but other methods compiles fine.





I have tried(thx to @Jorn Vernee) to compile and run programm in Eclipse and it compiles and runs.










share|improve this question
















I haven't found the reason (in JLS) why java compiler can't chouse appropriate method to execute in following program:



public class UpperLevelClass {
private static String getStringanotherNameMethod(String a, String b) {
return null;
}

private static String firstSignatureMethod(String a, String b) {
return null;
}

static class StaticNestedClass extends UpperLevelClass{
public void getStringfirstNameMethod(String a, Integer b) {
getStringanotherNameMethod("test", "fff");//compiles
firstNameMethod("test", "fff");//error below
}
}
}


Compiling finishes with following error:



error: method firstNameMethod in class StaticNestedClass cannot be applied to given types;
firstNameMethod("test", "fff");
^
required: String,Integer
found: String,String
reason: argument mismatch; String cannot be converted to Integer




Adding some history:



At first I had several static method with default access in upper level calls and everething compiles and runs(from static nested class) fine. Then static methods access was changed to private and programm stops compiling due to error in one method (in this case firstNameMethod), but other methods compiles fine.





I have tried(thx to @Jorn Vernee) to compile and run programm in Eclipse and it compiles and runs.







java






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 20 '18 at 7:28







Mikhailov Valentine

















asked Nov 18 '18 at 20:01









Mikhailov ValentineMikhailov Valentine

1,00731422




1,00731422













  • Does UpperLevelClass.getString(...); works?

    – Progman
    Nov 18 '18 at 20:04






  • 1





    Eclipse compiles this fine, but javac fails. Hm...

    – Jorn Vernee
    Nov 18 '18 at 20:15











  • Just tossing an idea into the bin for consideration. Does this have to do with the fact that the the method declared in the parent class have a static modifier, while the child's declaration does not?

    – PhaseRush
    Nov 18 '18 at 21:56











  • @Jorn Vernee, intresting - is true Eclips(EJC) compiles and runs fine when javac fails with error.

    – Mikhailov Valentine
    Nov 19 '18 at 20:52











  • If you have an answer to your question you can add it below and accept it. Changing your question to incorporate an answer isn't acceptable.

    – Makoto
    Nov 19 '18 at 21:19



















  • Does UpperLevelClass.getString(...); works?

    – Progman
    Nov 18 '18 at 20:04






  • 1





    Eclipse compiles this fine, but javac fails. Hm...

    – Jorn Vernee
    Nov 18 '18 at 20:15











  • Just tossing an idea into the bin for consideration. Does this have to do with the fact that the the method declared in the parent class have a static modifier, while the child's declaration does not?

    – PhaseRush
    Nov 18 '18 at 21:56











  • @Jorn Vernee, intresting - is true Eclips(EJC) compiles and runs fine when javac fails with error.

    – Mikhailov Valentine
    Nov 19 '18 at 20:52











  • If you have an answer to your question you can add it below and accept it. Changing your question to incorporate an answer isn't acceptable.

    – Makoto
    Nov 19 '18 at 21:19

















Does UpperLevelClass.getString(...); works?

– Progman
Nov 18 '18 at 20:04





Does UpperLevelClass.getString(...); works?

– Progman
Nov 18 '18 at 20:04




1




1





Eclipse compiles this fine, but javac fails. Hm...

– Jorn Vernee
Nov 18 '18 at 20:15





Eclipse compiles this fine, but javac fails. Hm...

– Jorn Vernee
Nov 18 '18 at 20:15













Just tossing an idea into the bin for consideration. Does this have to do with the fact that the the method declared in the parent class have a static modifier, while the child's declaration does not?

– PhaseRush
Nov 18 '18 at 21:56





Just tossing an idea into the bin for consideration. Does this have to do with the fact that the the method declared in the parent class have a static modifier, while the child's declaration does not?

– PhaseRush
Nov 18 '18 at 21:56













@Jorn Vernee, intresting - is true Eclips(EJC) compiles and runs fine when javac fails with error.

– Mikhailov Valentine
Nov 19 '18 at 20:52





@Jorn Vernee, intresting - is true Eclips(EJC) compiles and runs fine when javac fails with error.

– Mikhailov Valentine
Nov 19 '18 at 20:52













If you have an answer to your question you can add it below and accept it. Changing your question to incorporate an answer isn't acceptable.

– Makoto
Nov 19 '18 at 21:19





If you have an answer to your question you can add it below and accept it. Changing your question to incorporate an answer isn't acceptable.

– Makoto
Nov 19 '18 at 21:19












2 Answers
2






active

oldest

votes


















4














Searching for the appropriate method is a two-step process.



Step 1 involves selecting the class to be searched. The relevant line of the JLS of this step:




If the Identifier appears in the scope of a visible method declaration with that name:




If there is an enclosing type declaration of which that method is a member, let T be the innermost such type declaration. The class or interface to search is T.





Note that it says Identifier and not Signature here. This means that it is only looking at the method name at this stage, and not the arguments. Because StaticNestedClass contains a method called getString, that is the class to be searched.



It is only when we get to Step 2 that arguments are taken into account. Because there is no getString method in StaticNestedClass that are compatible with the method call, this leads compilation to fail.






share|improve this answer































    3














    Because your outer class' static method is private, your inner class can't see the declaration. Removing the private keyword is enough to ensure that the method can actually be seen.



    Alternatively, the fully qualified name could also be used - that is, invoke the method with UpperLevelClass.getString("test", "fff");.






    share|improve this answer
























    • Renaming the inner class's method to getString2 causes it to work.

      – Joe C
      Nov 18 '18 at 20:07






    • 2





      @JoeC: Ew. I wouldn't want to do that since it makes little sense to do it. The most obvious thing is addressing the scope issue.

      – Makoto
      Nov 18 '18 at 20:08











    • That's not actually true: private visibility has lexical scope, so methods of a nested class can see private members of the enclosing class.

      – Daniel Pryden
      Nov 18 '18 at 20:19













    • @Makoto, thank you for your response it compiles and runs if specify UpperLevelClass or supper or change one of methods signature, but question was about why campilation fails - due to some bug in javac or it's normal behavior.

      – Mikhailov Valentine
      Nov 19 '18 at 20:56











    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%2f53364899%2fjava-can-not-figure-out-the-method-to-be-invoked%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    4














    Searching for the appropriate method is a two-step process.



    Step 1 involves selecting the class to be searched. The relevant line of the JLS of this step:




    If the Identifier appears in the scope of a visible method declaration with that name:




    If there is an enclosing type declaration of which that method is a member, let T be the innermost such type declaration. The class or interface to search is T.





    Note that it says Identifier and not Signature here. This means that it is only looking at the method name at this stage, and not the arguments. Because StaticNestedClass contains a method called getString, that is the class to be searched.



    It is only when we get to Step 2 that arguments are taken into account. Because there is no getString method in StaticNestedClass that are compatible with the method call, this leads compilation to fail.






    share|improve this answer




























      4














      Searching for the appropriate method is a two-step process.



      Step 1 involves selecting the class to be searched. The relevant line of the JLS of this step:




      If the Identifier appears in the scope of a visible method declaration with that name:




      If there is an enclosing type declaration of which that method is a member, let T be the innermost such type declaration. The class or interface to search is T.





      Note that it says Identifier and not Signature here. This means that it is only looking at the method name at this stage, and not the arguments. Because StaticNestedClass contains a method called getString, that is the class to be searched.



      It is only when we get to Step 2 that arguments are taken into account. Because there is no getString method in StaticNestedClass that are compatible with the method call, this leads compilation to fail.






      share|improve this answer


























        4












        4








        4







        Searching for the appropriate method is a two-step process.



        Step 1 involves selecting the class to be searched. The relevant line of the JLS of this step:




        If the Identifier appears in the scope of a visible method declaration with that name:




        If there is an enclosing type declaration of which that method is a member, let T be the innermost such type declaration. The class or interface to search is T.





        Note that it says Identifier and not Signature here. This means that it is only looking at the method name at this stage, and not the arguments. Because StaticNestedClass contains a method called getString, that is the class to be searched.



        It is only when we get to Step 2 that arguments are taken into account. Because there is no getString method in StaticNestedClass that are compatible with the method call, this leads compilation to fail.






        share|improve this answer













        Searching for the appropriate method is a two-step process.



        Step 1 involves selecting the class to be searched. The relevant line of the JLS of this step:




        If the Identifier appears in the scope of a visible method declaration with that name:




        If there is an enclosing type declaration of which that method is a member, let T be the innermost such type declaration. The class or interface to search is T.





        Note that it says Identifier and not Signature here. This means that it is only looking at the method name at this stage, and not the arguments. Because StaticNestedClass contains a method called getString, that is the class to be searched.



        It is only when we get to Step 2 that arguments are taken into account. Because there is no getString method in StaticNestedClass that are compatible with the method call, this leads compilation to fail.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 18 '18 at 20:11









        Joe CJoe C

        11.5k62543




        11.5k62543

























            3














            Because your outer class' static method is private, your inner class can't see the declaration. Removing the private keyword is enough to ensure that the method can actually be seen.



            Alternatively, the fully qualified name could also be used - that is, invoke the method with UpperLevelClass.getString("test", "fff");.






            share|improve this answer
























            • Renaming the inner class's method to getString2 causes it to work.

              – Joe C
              Nov 18 '18 at 20:07






            • 2





              @JoeC: Ew. I wouldn't want to do that since it makes little sense to do it. The most obvious thing is addressing the scope issue.

              – Makoto
              Nov 18 '18 at 20:08











            • That's not actually true: private visibility has lexical scope, so methods of a nested class can see private members of the enclosing class.

              – Daniel Pryden
              Nov 18 '18 at 20:19













            • @Makoto, thank you for your response it compiles and runs if specify UpperLevelClass or supper or change one of methods signature, but question was about why campilation fails - due to some bug in javac or it's normal behavior.

              – Mikhailov Valentine
              Nov 19 '18 at 20:56
















            3














            Because your outer class' static method is private, your inner class can't see the declaration. Removing the private keyword is enough to ensure that the method can actually be seen.



            Alternatively, the fully qualified name could also be used - that is, invoke the method with UpperLevelClass.getString("test", "fff");.






            share|improve this answer
























            • Renaming the inner class's method to getString2 causes it to work.

              – Joe C
              Nov 18 '18 at 20:07






            • 2





              @JoeC: Ew. I wouldn't want to do that since it makes little sense to do it. The most obvious thing is addressing the scope issue.

              – Makoto
              Nov 18 '18 at 20:08











            • That's not actually true: private visibility has lexical scope, so methods of a nested class can see private members of the enclosing class.

              – Daniel Pryden
              Nov 18 '18 at 20:19













            • @Makoto, thank you for your response it compiles and runs if specify UpperLevelClass or supper or change one of methods signature, but question was about why campilation fails - due to some bug in javac or it's normal behavior.

              – Mikhailov Valentine
              Nov 19 '18 at 20:56














            3












            3








            3







            Because your outer class' static method is private, your inner class can't see the declaration. Removing the private keyword is enough to ensure that the method can actually be seen.



            Alternatively, the fully qualified name could also be used - that is, invoke the method with UpperLevelClass.getString("test", "fff");.






            share|improve this answer













            Because your outer class' static method is private, your inner class can't see the declaration. Removing the private keyword is enough to ensure that the method can actually be seen.



            Alternatively, the fully qualified name could also be used - that is, invoke the method with UpperLevelClass.getString("test", "fff");.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 18 '18 at 20:03









            MakotoMakoto

            81.7k17127176




            81.7k17127176













            • Renaming the inner class's method to getString2 causes it to work.

              – Joe C
              Nov 18 '18 at 20:07






            • 2





              @JoeC: Ew. I wouldn't want to do that since it makes little sense to do it. The most obvious thing is addressing the scope issue.

              – Makoto
              Nov 18 '18 at 20:08











            • That's not actually true: private visibility has lexical scope, so methods of a nested class can see private members of the enclosing class.

              – Daniel Pryden
              Nov 18 '18 at 20:19













            • @Makoto, thank you for your response it compiles and runs if specify UpperLevelClass or supper or change one of methods signature, but question was about why campilation fails - due to some bug in javac or it's normal behavior.

              – Mikhailov Valentine
              Nov 19 '18 at 20:56



















            • Renaming the inner class's method to getString2 causes it to work.

              – Joe C
              Nov 18 '18 at 20:07






            • 2





              @JoeC: Ew. I wouldn't want to do that since it makes little sense to do it. The most obvious thing is addressing the scope issue.

              – Makoto
              Nov 18 '18 at 20:08











            • That's not actually true: private visibility has lexical scope, so methods of a nested class can see private members of the enclosing class.

              – Daniel Pryden
              Nov 18 '18 at 20:19













            • @Makoto, thank you for your response it compiles and runs if specify UpperLevelClass or supper or change one of methods signature, but question was about why campilation fails - due to some bug in javac or it's normal behavior.

              – Mikhailov Valentine
              Nov 19 '18 at 20:56

















            Renaming the inner class's method to getString2 causes it to work.

            – Joe C
            Nov 18 '18 at 20:07





            Renaming the inner class's method to getString2 causes it to work.

            – Joe C
            Nov 18 '18 at 20:07




            2




            2





            @JoeC: Ew. I wouldn't want to do that since it makes little sense to do it. The most obvious thing is addressing the scope issue.

            – Makoto
            Nov 18 '18 at 20:08





            @JoeC: Ew. I wouldn't want to do that since it makes little sense to do it. The most obvious thing is addressing the scope issue.

            – Makoto
            Nov 18 '18 at 20:08













            That's not actually true: private visibility has lexical scope, so methods of a nested class can see private members of the enclosing class.

            – Daniel Pryden
            Nov 18 '18 at 20:19







            That's not actually true: private visibility has lexical scope, so methods of a nested class can see private members of the enclosing class.

            – Daniel Pryden
            Nov 18 '18 at 20:19















            @Makoto, thank you for your response it compiles and runs if specify UpperLevelClass or supper or change one of methods signature, but question was about why campilation fails - due to some bug in javac or it's normal behavior.

            – Mikhailov Valentine
            Nov 19 '18 at 20:56





            @Makoto, thank you for your response it compiles and runs if specify UpperLevelClass or supper or change one of methods signature, but question was about why campilation fails - due to some bug in javac or it's normal behavior.

            – Mikhailov Valentine
            Nov 19 '18 at 20:56


















            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%2f53364899%2fjava-can-not-figure-out-the-method-to-be-invoked%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







            這個網誌中的熱門文章

            Xamarin.form Move up view when keyboard appear

            Post-Redirect-Get with Spring WebFlux and Thymeleaf

            Anylogic : not able to use stopDelay()