• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Inheriting static methods

 
Ranch Hand
Posts: 234
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why is it that a static method declared in a class can be inherited but a static method declared in an interface cannot be inherited? I find this puzzling since every static member in an interface can be inherited (except static methods).
 
Marshal
Posts: 79151
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Don't know. Do you have a link to the JLS which shows that?
Maybe because static interface methods are intended to be used as factory methods. Implementing classes will have constructors and the factory methods cannot be expected to call those constructors. In fact the factory methods will now “know” about those constructors.
 
Daniel Cox
Ranch Hand
Posts: 234
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Do you have a link to the JLS which shows that?


JLS 8.4.8
A class does not inherit static methods from its superinterfaces.

JLS 9.4.1
An interface does not inherit static methods from its superinterfaces.
 
Campbell Ritchie
Marshal
Posts: 79151
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Neither of those two links seems to give any explanation why static interface methods are not inherited.
 
Bartender
Posts: 1251
87
Hibernate jQuery Spring MySQL Database Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Neither of those two links seems to give any explanation why static interface methods are not inherited.

Yes I also searched a lot in JLS 8 but couldn't find that... will try once again for sure.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

As a side note to this topic, since it is possible to implement more than one interface; I guess, if anyone really wanted the static methods from the superinterfaces, they can redundantly declare that the class implements the superinterfaces.

Henry
 
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The question is, then, what could go wrong if implementing an interface did involve inheriting its static methods? There must be something, because the language designers aren't in the habit of putting arbitrary restrictions into the language.

Perhaps Henry is onto something with the idea of implementing more than one interface? If a class implemented two interfaces and they both declared static methods with the same signature, then using that class to call the static method with that signature would be ambiguous.

But then wouldn't the same problem arise with default methods?
 
Campbell Ritchie
Marshal
Posts: 79151
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think the same problem can arise with abstract methods with the same signature and different return type.
 
Paul Clapham
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:I think the same problem can arise with abstract methods with the same signature and different return type.



It's not the same problem, because static and default methods have bodies with code, and abstract methods don't. I think with static (and default) methods it's the old diamond problem rearing its ugly head.
 
Paul Clapham
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:But then wouldn't the same problem arise with default methods?



(After some research...) No, it wouldn't. The language has rules to disambiguate default methods from two interfaces with different signatures, and they are described here: Overriding and Hiding Methods. In particular:

That Oracle tutorial wrote:If two or more independently defined default methods conflict, or a default method conflicts with an abstract method, then the Java compiler produces a compiler error. You must explicitly override the supertype methods.



But this process can't be applied to static methods -- the compiler can't force you to override the supertypes' static method.
 
Ganesh Patekar
Bartender
Posts: 1251
87
Hibernate jQuery Spring MySQL Database Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
  • Example1:
  • Default method of an interface is inherited in a class which implements that interface:
  • Output:
    I'm default method of interface One

  • Example2:
  • A class can implement two interfaces having same default methods but that class need to override one of them and use interfacename#super#methodname to invoke that method.
  • If don't override then gives CE: Duplicate default methods named getDefaultMethod with the parameters () and () are inherited from the types Two and One.
  • Output:
    I'm default method of interface One
    I'm default method of interface Two

  • Example3:
  • Abstract methods with the same signature and different return type, gives CE: The return type is incompatible with Two.getAbstractTwo()

  •  
    Daniel Cox
    Ranch Hand
    Posts: 234
    12
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Clapham wrote:...the compiler can't force you to override the supertypes' static method.


    But surely the compiler can force a class to hide its superinterfaces' "same signature" static methods (instead of inheriting them which will lead to the diamond problem).
     
    Paul Clapham
    Marshal
    Posts: 28177
    95
    Eclipse IDE Firefox Browser MySQL Database
    • Likes 2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    You may be right. On the other hand there's already rules built into the language which say "You have to override this abstract method or do something else to make it okay" so saying "You have to override this default method etc" isn't a big stretch. But it looks like "You have to hide this static method" was a stretch too far.

    Here's a possible reason why: Interface methods, whether default or not, can be overridden by abstract methods in an implementing class. That could be a reasonable response so there's no reason to prohibit it. However static methods can't be overridden hidden by abstract methods -- the combination "abstract static" isn't allowed. So that puts implementers in a bind if the compiler says they have to hide a static method. They can't defer the decision of what should go into the static method's body to subclasses by declaring it abstract, so they would sort of be forced to make an arbitrary decision about the contents of the method's body.
     
    Ganesh Patekar
    Bartender
    Posts: 1251
    87
    Hibernate jQuery Spring MySQL Database Tomcat Server Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    @ Paul Yes that could be the reason...
     
    Daniel Cox
    Ranch Hand
    Posts: 234
    12
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Clapham wrote:Here's a possible reason why: Interface methods, whether default or not, can be overridden by abstract methods in an implementing class.


    I agree. Makes sense since an interface is designed to specify (implement in Java 8) the behaviour of objects; not classes.

    I guess Java 8 simply provides us with a convenient way to organize utility methods that are specific to an interface. This tutorial says:

    In addition to default methods, you can define static methods in interfaces. This makes it easier for you to organize helper methods in your libraries; you can keep static methods specific to an interface in the same interface rather than in a separate class.


     
    Paul Clapham
    Marshal
    Posts: 28177
    95
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    That was a good question -- when I first read it I didn't know there was a question to be asked, and I didn't know the answer either. (That's assuming that this thread has actually produced the answer -- it sounds plausible but reading the minds of the JLS writers isn't always feasible.) That's why I gave you a cow for it.
     
    Ranch Hand
    Posts: 91
    3
    Chrome Java Windows
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Aren't static methods "visible" to subclasses rather than "inherited" by them?

    Doesn't "inheritance" apply to polymorphism and doesn't polymorphism only apply to instantiated objects?

    Hence, to be precise, we cannot use "inherits, overrides" interchangeably with "visible, is hidden", correct?
     
    Henry Wong
    author
    Posts: 23951
    142
    jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Julian West wrote:
    Hence, to be precise, we cannot use "inherits, overrides" interchangeably with "visible, is hidden", correct?


    First of all, this is one of those long time discussions / debate on terminology, and ...

    Second, in this case, the Java Language Specification uses the term "inherit", as in ...

    An interface does not inherit static methods from its superinterfaces.

    and this discussion is explicitly talking about the JLS, so this is probably not a good topic to use as an example (evidence) to continue the debate...

    Henry
     
    Julian West
    Ranch Hand
    Posts: 91
    3
    Chrome Java Windows
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    try {

     I wasn't looking for a debate; I was looking for clarification.  The OCA exam doesn't have essay questions.  ;)

    } catch (Exception take) {

     I'll quote the man himself:

     

    There exist, indeed, certain general principles founded in the very nature of language, by which the use of symbols, which are but the elements of scientific language, is determined. To a certain extent these elements are arbitrary. Their interpretation is purely conventional: we are permitted to employ them in whatever sense we please. But this permission is limited by two indispensable conditions, first, that from the sense once conventionally established we never, in the same process of reasoning, depart; secondly, that the laws by which the process is conducted be founded exclusively upon the above fixed sense or meaning of the symbols employed.

       — George Boole, An Investigation of the Laws of Thought



    The first law of thought is identification--it either is (it == true) or it is not (it != true); otherwise, the "debate" is merely talking in circles.

    } finally {

     In spite of taking our arguments, the compiler doesn't debate.

    }
     
    reply
      Bookmark Topic Watch Topic
    • New Topic