We Keep Coding

Java 9 Interface : Why default Modifier Converted into public Modifier

My Question is about interface. I create an interface and define four methods: first method is a private method; second is a default method; third is a static method; and fourth is an abstract method.
After compiling this interface and checking its profile: the default method is converted into a public method, and both the static and abstract methods have a prepended public modifier. Why is this?
Code:
interface InterfaceProfile {
private void privateM() { //this method is hidden
System.out.println("private Method");
}
default void defaultM() {
System.out.println("Default Method");
}
static void staticM() {
System.out.println("Static Method");
}
void doStuff(); //by default adds the public modifier
}
InterfaceProfile class
D:\Linux\IDE\Workspace\OCA-Wrokspace\Ocaexam\src>javap mods\com\doubt\session\InterfaceProfile.class
Compiled from "InterfaceProfile.java"
interface com.doubt.session.InterfaceProfile {
public void defaultM();
public static void staticM();
public abstract void doStuff();
}

The fact that it's a default method doesn't make a difference. The implicit scope is public.
Here's what the tutorial says:
All abstract, default, and static methods in an interface are implicitly public, so you can omit the public modifier.

Simple: by default, all methods in an interface are public. You can restrict that by applying private, but whenever you do not do that, that default kicks in. Thus: there is no conversion taking place at all.
Quoting the Java Language Specification:
A method in the body of an interface may be declared public or private (§6.6). If no access modifier is given, the method is implicitly public. It is permitted, but discouraged as a matter of style, to redundantly specify the public modifier for a method declaration in an interface.
( the ability to have private methods in interfaces was introduced with Java 9, as people discovered that Java 8 default methods often created the need to have, well, private methods that such default methods could make use of, without making these helper methods publicly visible )

The default modifier is public, because that is how the interface declaration is defined:
https://docs.oracle.com/javase/tutorial/java/IandI/interfaceDef.html
If you are asking for the reasoning behind this, i would argue that the purpose of defining an interface is to ensure the - well - interface of all implementing classes, meaning that all implementing classes have clear contracts on which public accessable methods they need to provide.
Adding private methods to an interface does not serve this primary purpose and seems to be more of an implementation hint. Private and abstract methods were late additions to interfaces.
Related: Should methods in a Java interface be declared with or without a public access modifier?

https://docs.oracle.com/javase/tutorial/java/IandI/interfaceDef.html
All abstract, default, and static methods in an interface are implicitly public, so you can omit the public modifier.
In effect, a class that implements an interface exposes all of the interface methods (other than private) to any other code that has visibility of the class.
It would be very confusing if a class had an interface but the methods on the interface would be visible to some code and not other. If you want to selectively expose methods, then you should probably make use of multiple interfaces.
public interface Profile {
generalMethod() ...
}
public interface SecretProfile extends Profile {
secretMethod() ...
}
Classes may choose to implement either of the interfaces (or even both). 3rd party code can check for the presence of the interface and know that the method is available or not.

Is this a valid abstract class?

Is this a valid abstract class?
I know that abstract classes cannot be instantiated, so I'm suspicious of the instance variable language and constructor Programmer. It also implements a writeCode method that is not declared as default. If I recall correctly, the only methods that can be implemented in an abstract class are those with default implementations.
public abstract class Programmer {
private String language;
public Programmer (String language) {
this.language = language;
}
public void writeCode() {
System.out.println("Written in " + language);
}
}
If it is a valid abstract class, can someone explain why it contains a constructor?
Also, more broadly speaking, can abstract classes have instance variables? If so, why? Doesn't that seem counter to the idea that abstract classes cannot be instantiated?
Finally, I would love it if someone addresses the writeCode method. Why is it implemented, without a default modifier?
Thanks!

Yes, this is a valid abstract class.
Abstract classes can have constructors, instance variables and concrete methods.
The main difference with regular classes is that they can also declare abstract methods, delegating implementation to the non-abstract child classes (this is not the case here, you have no abstract methods).
Another difference is that they cannot be initialized directly, even if they do provide an accessible constructor.
The constructor(s) of an abstract class are typically used to initialize values internally, and to invoke from child classes or anonymously.
See documentation here.
Example
Given...
public abstract class Programmer {
private String language;
public Programmer(String language) {
this.language = language;
}
public void writeCode() {
System.out.println("Written in " + language);
}
}
... and...
public class JavaProgrammer extends Programmer {
public JavaProgrammer() {
super("Java");
}
}
Concrete child class
new JavaProgrammer().writeCode(); // prints "Java"
Anonymous class (note the empty class body {})
new Programmer("JavaScript"){}.writeCode(); // prints "JavaScript"

As you say, abstract classes cannot be instantiated. However, when a subclass of any abstract class is created, the first sentence in its constructor is a call to super(), which is nothing but a representation of the constructor of its parent class, the abstract class.
An abstract class can have instance variables and methods. It is even possible to have an abstract class without any abstract method. However, an abstract method can only be declared in an abstract class.
You are mixing abstract classes and interfaces concepts. An interface cannot have instance variables, and any implemented method must be prefixed with the static or default modifier.

This is correct example of abstract class. Answering your questions:
default keyword is used (as of java 8) in interfaces, where you can implement default method implementation, abstract class can have a method implementation just as any normal java class
having constructor in abstract class imposes having a constructor in extending class so that the underlying abstract class can be properly constructed (e.g. fields instantiated etc)
abstract class cannot be instantiated but as any other class can have private fields and internally make use of them, should they be protected then extending classes will also be able to directly access them.
It seems to me you're confusing abstract class with interface.

The abstract class contains a constructor because when the instantiated class based on the abstract class is created it will call super() to execute the code from the abstract class.
The instance variable is a similar thing. The class that is developed from the abstract class would then have access to the language and be able to work with it.
In terms of the default, that would be best practice but there is no absolute requirement for it to be there.

Abstract classes are partial implementations. Sometimes, as in the case above, the only thing that prevents the class from being instantiated is the abstract modifier itself!
If an abstract class has constructors then it means that subclasses must invoke one of the constructors (by calling super(...) in their constructor.
More broadly it seems that you're confusing Interfaces and Abstract Classes. Interfaces are a contract, they specify how a class should behave but provide no implementation whatsoever. Abstract Classes are a specific partial implementation of some code.
Interfaces are used (broadly) when you require someone else to provide behaviour but you don't care how it works. Abstract Classes are used when you want to assist people in providing behaviour, but you still require them to provide some details.
Since these definitions overlap, it's not unusual to see both Abstract Classes and Interfaces provided, e.g. the various Adapters in java.swing.*.

Why are class static methods inherited but not interface static methods?

I understand that in Java static methods are inherited just like instance methods, with the difference that when they are redeclared, the parent implementations are hidden rather than overridden. Fine, this makes sense. However, the Java tutorial notes that
Static methods in interfaces are never inherited.
Why? What's the difference between regular and interface static methods?
Let me clarify what I mean when I say static methods can be inherited:
class Animal {
public static void identify() {
System.out.println("This is an animal");
}
}
class Cat extends Animal {}
public static void main(String[] args) {
Animal.identify();
Cat.identify(); // This compiles, even though it is not redefined in Cat.
}
However,
interface Animal {
public static void identify() {
System.out.println("This is an animal");
}
}
class Cat implements Animal {}
public static void main(String[] args) {
Animal.identify();
Cat.identify(); // This does not compile, because interface static methods do not inherit. (Why?)
}

Here's my guess.
Since Cat can only extend one class if Cat extends Animal then Cat.identify has only one meaning. Cat can implement multiple interfaces each of which can have a static implementation. Therefore, the compiler would not know which one to choose?
However, as pointed out by the author,
Java already has this problem, with default methods. If two interfaces
declare default void identify(), which one is used? It's a compile
error, and you have to implement an overriding method (which could
just be Animal.super.identify()). So Java already resolves this
problem for default methods – why not for static methods?
If I was to guess again, I'd say that with default the implementation is part of Cat's vtable. With static it cannot be. The main function must bind to something. At compile time Cat.identify could be replaced with Animal.identify by the compiler but the code wouldn't match reality if Cat was recompiled but not the class that contains main.

Before Java 8, you couldn't define static methods in an interface. This is heavily discussed in this question. I'm going to refer to this answer (by user #JamesA.Rosen) as to why the Java designers probably didn't want static methods in an interface initially:
There are a few issues at play here. The first is the issue of
declaring a static method without defining it. This is the difference
between
public interface Foo {
public static int bar();
}
and
public interface Foo {
public static int bar() {
...
}
}
Java doesn't allow either, but it could allow the second. The first is
impossible for the reasons that Espo mentions: you don't know which
implementing class is the correct definition.
Java could allow the latter, as long as it treated Interfaces as
first-class Objects. Ruby's Modules, which are approximately
equivalent to Java's Interfaces, allow exactly that:
module Foo
def self.bar
...
end
end
However, since the release of Java 8, you can actually add default and static methods inside an interface.
I'm going to be quoting this source a lot here. This is the initial problem:
Java's interface language feature lets you declare interfaces with
abstract methods and provide implementations of those methods in the
classes that implement the interfaces. You are required to implement
each method, which is burdensome when there are many methods to
implement. Also, after publishing the interface you cannot add new
abstract methods to it without breaking source and binary
compatibility.
This was the solution Java 8 provided default:
Java 8 addresses these problems by evolving the interface to support
default and static methods. A default method is an instance method
defined in an interface whose method header begins with the default
keyword; it also provides a code body. Every class that implements the
interface inherits the interface's default methods and can override
them
And for static:
A static method is a method that's associated with the class in which
it's defined, rather than with any object created from that class.
Every instance of the class shares the static methods of the class.
Java 8 also lets static methods be defined in interfaces where they
can assist default methods.
When you implement an interface that contains a static method, the
static method is still part of the interface and not part of the
implementing class. For this reason, you cannot prefix the method with
the class name. Instead, you must prefix the method with the interface
name
Example:
interface X
{
static void foo()
{
System.out.println("foo");
}
}
class Y implements X
{
}
public class Z
{
public static void main(String[] args)
{
X.foo();
// Y.foo(); // won't compile
}
}
Expression Y.foo() will not compile because foo() is a static member
of interface X and not a static member of class Y.

Static methods in interfaces could create a diamond of death if they were being inherited. So, calling a static method from the appropriate interface is good enough compared to the risk of calling it from a concrete class that may implement multiple interfaces that contain static methods of the same name.
Why are static methods any different?
Static methods are just functions unrelated to the objects. Instead of placing them in utility abstract classes (like calling Collections.sort() ) we move those functions (static methods) to their appropriate interfaces. They could be bound to the inherited objects like the default methods do, but that is not their job.
Static methods provide functionality which is unrelated to the instances of the class.
Example:
interface Floatable {
default void float() {
// implementation
}
static boolean checkIfItCanFloat(Object fl) {
// some physics here
}
}
class Duck implements Floatable { }
So, the point is that a Duck may float but the function that checks if an Object really floats is not something that a Duck can do. It is an irrelevant functionallity that we could pass to our Floatable interface instead of having it sit inside some utility class.

Let's begin with some background ...
Java doesn't support multiple inheritance (the ability to extend more than one class). This is because multiple inheritance is prone to the deadly diamond of death (also known as the diamond problem) which the designers of Java chose to preempt.
If B and C override a method inherited from A, which method does D inherit?
A class can implement multiple interfaces because interface methods are contracted for overriding; if a class C implements two interfaces A and B that declare the same method, then the same method in C will be invoked by clients of either interface (A or B). The introduction of default methods for interfaces in Java 8 was made possible by forcing the implementer to override the default in case of ambiguity. This was an acceptable compromise since default methods are intended to be defensive (to be used if no other implementation is explicitly provided by an implementer). However, since the compiler can’t force you to override a static method (static methods inherently can't be overridden), the introduction of static methods for interfaces in Java came with one restriction: the static methods of an interface are not inherited.

The answer is that static methods belong to a class/interface and there is only one instance for static blocks. that's the reason you can't override any static method.
Even in classes, you may override but only the super class' static method gets executed.

Java Interfaces -- why not have private methods?

Why are methods on interfaces always public? Why can't they be private?

Because all methods on an interface are public. That's the point in having the interface -- technically it defines a contract for your class (which may have many, overlapping, contracts/interfaces). The client of your class should hold a reference to the interface and have access only to the class' published (public) methods through the interface.

I infer that you are referring to an interface declared thusly:
public interface MyInter
{
public void myFunc();
}
And the resulting error if you omit the public qualifier in your implementation:
MyClass.java:3: myFunc() in MyClass cannot implement myFunc() in MyInter; attempting to assign weaker access privileges; was public
void myFunc(){}
^
Say you could make myFunc private. You write the following code in a different class. This should complain about you trying to use a private function you didn't have access to:
MyClass foo = new MyClass();
foo.myFunc(); // Declared private, can't call it.
But what about this:
void doSomething(MyInter foo)
{
foo.myFunc(); // Declared public in interface, private in implementation.
}
Can we do this? According to the interface it's a public method so we should be good to go. But it's implemented as a private method so the class expects it never to be called from the outside like this, a restriction that should be enforced by the compiler. But the compiler doesn't even need to know about MyClass for this to compile. It could not even be written yet, or in an external library that may or may not ever be integrated.
Allowing implementations creates an internal inconsistency in the rules of allowable access, and the resolution to that inconsistency is to disallow the situation altogether. Anything that can call a method in an interface must be able to call it in any implementation.
The same argument holds true for overriding subclass methods. You can't "hide" them by overriding with more restrictive qualifiers.

Why is it so?
Because the JLS says so:
In the Chapter on interface declarations, JLS 9.4 says: "Every method declaration in the body of an interface is implicitly public."
In the Chapter on class declarations, JLS 8.4.8.3 says: "The access modifier (§6.6) of an overriding or hiding method must provide at least as much access as the overridden or hidden method, ..."
Engineer Dollery's answer explains why the language is designed this way.

Methods visibility in interface

Do all methods in an Interface has by default Public visibility mode?

All methods in an interface default to public.
See Java Language Specification 6.6.1 which states
All members of interfaces are
implicitly public.

All interface methods ARE public abstract, all interface fields are public static final...
see here.

Just to add to other answers here: all methods are public, however, if the interface itself is package-local then effectively all methods are also package-local.
You can therefore mix public and package-local methods, by making a package-local interface extend a public one.
public interface P{
void iAmPublic();
}
interface L extends P{
void iAmPackageLocal();
}
Here L effectively has one public and one package-local method. Clients from outside the package will only see iAmPublic(), whereas ones from inside the package will see both methods.
In the same way you can nest interfaces inside other classes to achieve even tighter method visibility.

Yes, all methods of an interface are public, and can't have any other access modifier (i.e. the default public access modifier is the only valid access modifier)

Yes, all methods in an interface are implicitly public and abstract.
Check Java language specification chapter 9.4