This seems like hair-splitting, but it relates to and can reinforce a more common and more serious misconception.
First, the more common and more serious misconception about OOPS in
Java:
The Truth About Static Methods:
Static methods have no "this" pointer and aren't themselves virtual/don't behave polymorphically. That is what makes them static methods (well it is what the static modifier enforces about them).
They therefore can't reference instance variables and instance methods unless a reference to an instance is passed in to them or is returned by some method they call.
But once they have a reference to one or more objects, they can do anything to/with those objects that any instance method could, albeit with a syntax of:
myReference.dataMember or myReference.instanceMethod()
Now "we all know this" and some people don't even like static methods in the first place, or even non-constant static data, but they are there and part of the language, to be used and hopefully not abused.
Not just a few, but a lot of beginners, and some not-so-beginners hear "static methods can't reference instance variables or call instance methods" and instead of implicitly adding "unless they are passed in a reference or call something that returns one to them, and then use that reference" think that "static methods can't reference instance variables or call instance methods" is the end of the story. Maybe it would be good if that
were true, I am certainly not convinced, but it is not at all true. Given a valid reference to an instance, static methods can do anything that an instance method can except explicitly or implicitly say 'this'. They even get the polymorphic behavior of the instance method on calls...
There are tons of things I consider more subtle than this on the 819, not just a few. This would be a major misconception.
Okay, so this brings me to the more subtle thing in Chapter 1 of the 816 book that I feel reinforces this possibly pre-existing misconception, and additionally implies a difference between behavior of static methods in interfaces versus static methods in classes that does not exist in reality.
Extended quote from "Chapter 1 - Java Fundamentals (Understanding Interface Members)" for purposes of evaluating whether this constitutes an errata or not:
Introducing private Interface Methods
New to Java 9, interfaces may now include private interface methods. Putting on our thinking cap for a minute, what do you think private interface methods are useful for? Since they are private, they can not be used outside the interface definition. They also cannot be used in static interface methods without a static method modifier, as we'll see in the next section.
Towards the end of that section, lest we think we are getting paranoid here, we summarize rules for usage of private interface methods:
Private Interface Method Definition Rules:
1. A private interface method must be marked with the private modifier and include a method body.
2. A private interface method may be called only by default and private (non-static) methods within the interface definition.
1. is true, 2. is false.
I agree with the very next sentence which suggests that 2. is false:
Private interface methods behave a lot like instance methods within a class.
I might add the modifier 'private' to read "a lot like private instance methods within a class" as they can't be overridden to get polymorphic behavior, but that is getting really subtle.
Later on page 30, we say:
On the other hand, a
private method cannot be called from a
private static method. This would be like trying to access an instance method from a static method in a class.
Near the end of the whole section on page 31, the second column title reinforces the confusion and the fourth column title ameliorates it a bit:
2nd Column title:
"
Accessible from static methods within the interface definition?"
for
abstract method, default method and
private method the values are all "No"
The 4th Column title helps both reinforce and clear the common misconception:
"Accessible outside the interface without an instance of interface?"
for
abstract method, default method and
private method the values are all "No"
I say this both reinforces and clears the misconception because it shows explicitly that you can access these from outside as long as you have a reference.
That suggests to me that maybe that was true from static methods within the interface definition as well, but wait, wouldn't they say so if that was the case?
So maybe not.
The penultimate sentence explicitly undermines any residual misconception about access in
classes:
Recall that instance methods can access static members within the class, but static members cannot access instance methods without a reference to the instance.
The whole thing read literally at least suggests to me that interface members behave differently with respect to access by static methods in classes and in interfaces. When I rushed thru the first time that's what I got out of it. Coming back after an externally-enforced time away from studying, I just felt "that's not right" and wrote a quick program to prove or disprove it:
Of course, this compiles fine and prints:
Private instance method called
Because interfaces DO behave exactly like classes in this particular regard.
It is more minor than two dozen more important points explained wonderfully in this section, but a reasonably careful reading left me confused about whether classes and interfaces were similar or different in this way.
