interface is abstract?

[iyappan sankaran]

all the methods in an interface are implicitly abstract.is it true?

if then why in Runnable interface sun provide some thing like this,
public interface Runnable
{
public abstract void run();
}

[Ernest Friedman-Hill]

All interface methods are implicitly public, too. Remember that when "Runnable" was written, the author was a fairly new Java programmer!

[iyappan sankaran]

i dont ask why it is public.
why it is abstract ?

[Ilja Preuss]

public abstract interface Runnable {
  public abstract void run();
} 

is fully equivalent to

public interface Runnable {
  void run();
} 

Which one you use is solely a matter of style - it doesn't have any impact on how the interface behaves.

[JulianInactive KennedyInactive]

It's often good practice to make something that's implicit explicit in the interest of clarity. This is particularly relevant when the implicit behaviour is not well known and may confuse developers (or whoever) otherwise. I'm not convinced it's particularly useful in this case as anyone who knows how to use interfaces knows the methods in the interface itself don't have implementations. They are therefore implicitly abstract but there's little room for confusion beyond absolute beginners and semantics, IMO. Of course, as Ernest implies, these distinctions are unlikely to have been so well-known when Java was in its infancy.

Jules

[Ernest Friedman-Hill]

These days I think most of the Javascenti consider it good style to omit the public and abstract declarations from the methods, and the abstract declaration from the interface.

[Stan James]

I think we missed the original question - why are the methods on an interface abstract? Think what abstract means. You cannot create an instance. Well, that's true of an interface. And any implementing class must override the method or declare itself abstract, too. The definition of abstract seems to fit the purpose of an interface perfectly.

[JulianInactive KennedyInactive]

I suppose the question could be interpreted that way. I read it as a question of implicicityness versus (redundant) explicicityness.

[Vikalp Singh]

I am agree with the Ilja Preuss,
This is just matter of coding style.

All methods are implicitly abstract, in the interface.
If you are writing abstract, then we do not have any harm

[Tony Morris]

It is not just a matter of personal style to omit redundant modifiers, but generally accepted good style. The JLS explicitly states that providing redundant modifiers on interface methods is poor. While one can argue all day about whether or not the JLS (or code conventions for that matter) should be considered the authoritative source of style, I agree that redundancy in code for perceived clarity is actually clutter in this case. That is, I don't agree that because someone does not have an instinctive understanding of a section of the JLS, that they should create "clutter" for those that do - this is merely a workaround to the real problem - learning and understanding a section of the JLS. Once this has been achieved, the realisation of the clutter comes to the fore.

I use a tool (http://checkstyle.sourceforge.net/) to ensure that I, and others who might maintain my code in the future, don't provide redundant modifiers in any context (the tool does other useful things as well).
Examples of redundant modifiers:
- public, static, or final on an interface field.
- public or abstract on an interface method.
- final on a method within a final class.

JLS 9.4

It is permitted, but strongly discouraged as a matter of style, to redundantly specify the public modifier for interface methods.

[Ilja Preuss]

On the other hand, the team I am currently working on has agreed on a coding style that requires the redundant modifiers on interface methods. The rational is that that way it is easier to switch between interfaces and abstract classes - you don't have to change method signatures every time.

[JulianInactive KennedyInactive]

Kinda goes against the YAGNI principle though, doesn't it? Of course that philosophy is just the prevailing style...

[Ilja Preuss]

Originally posted by Julian Kennedy:
Kinda goes against the YAGNI principle though, doesn't it?

No - YAGNI *solely* applies to adding *functionality* to your code that isn't needed yet.

Of course you can apply it to different domains, but it's certainly not reasonable to apply it to everything.

In this case, though, I'd suggest that the team came up with this rule in accordance with YAGNI:

- someone changed an abstract class to an interface and didn't remove the now redundant modifiers because of "YAGNI".

- someone noticed that now the coding style wasn't consistent and therefore confusing. The team decided that they actually needed a consistent coding style and decided on the one that meant less rework.

Does that compute?

[JulianInactive KennedyInactive]

I guess. I'm not saying it's not a valid thing to do. However, what I meant was that defining an interface with the redundant modifiers because you might need to switch it to be an abstract class, does go against the YAGNI principle. I also take the principle to apply to code, rather than just functionality, i.e. anything that you ain't gonna need.

Jules

[Peter den Haan]

Tend to agree with Jules. "Consistency" or "it's clearer" can be valid reasons. "It is easier to switch to abstract classes" doesn't seem very strong... if you intend to turn a bunch of interfaces into abstract classes, adding a few modifiers is probably going to be the least of your problems.

To me, YAGNI applies to any activity that directly or indirectly adds effort for the sake of imaginary future requirements. Not just functionality.

By the way, not explicitly adding "public", "final" or "abstract" to interface fields and methods is one of the recommendations of the Sun Java(TM) Coding Style Guide:

All interfaces are inherently abstract; do not explicitly include this keyword in the declaration of an interface.

All interface fields are inherently abstract, static, and final; do not explicitly include these keywords in the declaration of an interface field.

All interface methods are inherently abstract; do not explicitly include this keyword in the declaration of an interface method.

My suggestion would be to stick with that unless you feel you have a really good reason to do otherwise. "I don't think it's as clear" is not necessarily a good reason: clear is often simply what you're used to.

- Peter
[ September 06, 2004: Message edited by: Peter den Haan ]

[Ilja Preuss]

Originally posted by Peter den Haan:
"It is easier to switch to abstract classes" doesn't seem very strong... if you intend to turn a bunch of interfaces into abstract classes, adding a few modifiers is probably going to be the least of your problems.

I didn't say that it's a problem. But it's still work that's actually unnecessary - until someone comes with a better reason for removing the redundant modifiers than "Sun says that you should do it"...

To me, YAGNI applies to any activity that directly or indirectly adds effort for the sake of imaginary future requirements. Not just functionality.

For my sake do that, but do it at your own risk. Remember that the saying got coined by the same people who coined "Merciless Refactoring", which is undoubtly effort for the sake of the imaginary future.

By the way, not explicitly adding "public", "final" or "abstract" to interface fields and methods is one of the recommendations of the Sun Java(TM) Coding Style Guide

Unfortunately it doesn't explain at all the reasons behind this recommendation.

My suggestion would be to stick with that unless you feel you have a really good reason to do otherwise.

I think a fairly good reason would suffice for me.

"I don't think it's as clear" is not necessarily a good reason: clear is often simply what you're used to.

I agree to the latter. Therefore I think that if a whole team agrees on that it is clearer using a different style, that's a good enough reason to use it. New team members shouldn't have much problems to get used to it when they join later...

[Tony Morris]

"redundancy" is a good enough reason as any.
"overly verbose", "clutter" perhaps.

[Peter den Haan]

Originally posted by Ilja Preuss:
Remember that the saying got coined by the same people who coined "Merciless Refactoring", which is undoubtly effort for the sake of the imaginary future.

But is it? You know that a software system is going to see maintainance and minor enhancements, with the exception of mothballed projects (and surely the right YAGNI thing is not to write those in the first place ). Put differently, the only thing you really know is going to happen is change, and RefactorMercilessly is part of making change cheap.

Well, that's the theory anyways

- Peter

[Ilja Preuss]

Originally posted by Peter den Haan:
You know that a software system is going to see maintainance and minor enhancements

Yes, but that "knowing" is exactly what YAGNI counters.

I "know" that tomorrow I will need this additional method on class Foo, because I "know" that tomorrow I will work on Feature X. Therefore I should implement that method now, because it will be faster to do it now than doing it tomorrow.

YAGNI - do today what you need to today, not more.

Applying that thinking to refactoring will wreak havoc - and yes, people actually *do* that.

[Peter den Haan]

Originally posted by Ilja Preuss:
Yes, but that "knowing" is exactly what YAGNI counters.

Exactly, it's "knowing" that YAGNI counters, not knowing. And the only things you know (without quotes) is that change is going to come, and that it's not going to look like you thought it would But your point is well taken.

- Peter

[Ilja Preuss]

Originally posted by Peter den Haan:
Exactly, it's "knowing" that YAGNI counters, not knowing. And the only things you know (without quotes) is that change is going to come, and that it's not going to look like you thought it would

Playing devil's advocate: "But if we don't know what the future changes will look like, this refactoring might well be wasted! Then why do it now instead of when we really *know* that we need it?"

But your point is well taken.