Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 7, 8
    • Fix Version/s: 9
    • Component/s: specification
    • Labels:

      Description

      Overview of changes that have been identified:
      - 9.4: Modify syntax, clarify that private methods are not "implicitly public" and are not "default". Error checks for conflicts between 'private' and any of 'public', 'abstract', or 'default', similar to 8.4.3.
      - 9.4.1: Private methods are not inherited or overridden in a subinterface. (Inheritance definition actually works already, because it speaks of "abstract or default", but even without any spec change, this should definitely be tested.)
      - 9.4.1.2: a private method can't override a public method.
      - 8.4.8: Private methods are not inherited or overridden in a subclass. (Again, no spec change, but should be tested.)
      - 13.5.6: Describe the binary compatibility impact of changing the access of an interface method (similar to 13.4.7)

      Need to investigate other potential impacts, where interface methods have been assumed to always be public (for example, in 6.6).

        Issue Links

          Activity

          Hide
          dholmes David Holmes added a comment -
          I'd prefer 9.4 to be as explicit as possible so that you don't need to join the dots with clauses later in 9.4, or in clauses in 9.4.3, to figure out that a private interface method must have a body and can never be abstract. But you could also address the statement in 9.4 by saying that "An interface method with a semi-colon for its body is implicitly abstract." and then tweak 9.4.3 to cover which declarations are required to have semi-colon or block bodies.
          Show
          dholmes David Holmes added a comment - I'd prefer 9.4 to be as explicit as possible so that you don't need to join the dots with clauses later in 9.4, or in clauses in 9.4.3, to figure out that a private interface method must have a body and can never be abstract. But you could also address the statement in 9.4 by saying that "An interface method with a semi-colon for its body is implicitly abstract." and then tweak 9.4.3 to cover which declarations are required to have semi-colon or block bodies.
          Hide
          dlsmith Dan Smith added a comment -
          Is this method implicitly abstract?

          private void m() {}

          If I don't include 'private' in the list of modifiers that prevent the method from being considered abstract (9.4), then it will be abstract, per that rule. As you point out, Alex, this will lead to a compiler error. But that's not what we want—it's a legal declaration!
          Show
          dlsmith Dan Smith added a comment - Is this method implicitly abstract? private void m() {} If I don't include 'private' in the list of modifiers that prevent the method from being considered abstract (9.4), then it will be abstract, per that rule. As you point out, Alex, this will lead to a compiler error. But that's not what we want—it's a legal declaration!
          Hide
          dlsmith Dan Smith added a comment -
          The 8.4.8.1 use of "instance method" for interface overriding but not class overriding is intentional, but too subtle. I've changed it, putting back the rule about abstract/default methods, but making it more explicit about what we're after: "_mI_ is not 'static'."

          Why the discrepancy? Because static interface methods are not inherited, while static class methods are. Overriding a static class method sets you up for the next sentence:

          "It is a compile-time error if an instance method overrides a static method."
          Show
          dlsmith Dan Smith added a comment - The 8.4.8.1 use of "instance method" for interface overriding but not class overriding is intentional, but too subtle. I've changed it, putting back the rule about abstract/default methods, but making it more explicit about what we're after: "_mI_ is not 'static'." Why the discrepancy? Because static interface methods are not inherited, while static class methods are. Overriding a static class method sets you up for the next sentence: "It is a compile-time error if an instance method overrides a static method."
          Hide
          abuckley Alex Buckley added a comment - - edited
          The Description's goal of a private method not being a default method isn't fully realized by the 9.4 change, which can be read as making default methods distinct only from "private and static interface methods" a.k.a. 'private static void m() {}'.

          Suggest "Default methods, being instance methods, are distinct from /static/ interface methods. Default methods, which are inherited (9.4.1), are also distinct from /private/ interface methods, which are not inherited." (Yes, a private static interface method is caught twice, but I think the sentence is clearer than "private and static interface methods", especially when a later sentence uses that phrase to mean 'really, both modifiers': "A method may be declared both 'private' and 'static'.")

          ALSO: It would be good to relocate the compile-time error re: instance-overriding-static to be closer to the class/class scenario in 8.4.8.1, and to then phrase the error w.r.t. mA and mC.
          Show
          abuckley Alex Buckley added a comment - - edited The Description's goal of a private method not being a default method isn't fully realized by the 9.4 change, which can be read as making default methods distinct only from "private and static interface methods" a.k.a. 'private static void m() {}'. Suggest "Default methods, being instance methods, are distinct from /static/ interface methods. Default methods, which are inherited (9.4.1), are also distinct from /private/ interface methods, which are not inherited." (Yes, a private static interface method is caught twice, but I think the sentence is clearer than "private and static interface methods", especially when a later sentence uses that phrase to mean 'really, both modifiers': "A method may be declared both 'private' and 'static'.") ALSO: It would be good to relocate the compile-time error re: instance-overriding-static to be closer to the class/class scenario in 8.4.8.1, and to then phrase the error w.r.t. mA and mC.
          Hide
          dlsmith Dan Smith added a comment - - edited
          Alex, your comments have now been addressed in the above spec text.
          Show
          dlsmith Dan Smith added a comment - - edited Alex, your comments have now been addressed in the above spec text.

            People

            • Assignee:
              abuckley Alex Buckley
              Reporter:
              dlsmith Dan Smith
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: