Develop Reference

Is it possible to overload abstract methods in an abstract Java class, but implement only one of the overloaded methods in subclass?

I have an abstract class (showing only the relevant parts) with two overloaded methods.
abstract public class Component {
...
abstract protected void createPhysics();
abstract protected void createPhysics(Comp1D[] comp1DS);
...
}
In the subclasses which extend this abstract class I only want to use either the one with arguments or the one without, but never both of them. For example
public class Comp1D extends Component{
...
protected void createPhysics(Comp1D[] comp1Ds){
...
}
}
and
public class Comp3D extends Component{
...
protected void createPhysics(){
...
}
}
Of course this won't compile this way since the other createPhysics method is not implemented in the subclass. My quick and dirty solution would be to implement both methods in subclasses, but the unused method would have empty body.
Is there a more elegant way to solve it in Java 8?

With abstract methods, there is not. And on a syntactical level, it would not be sound either. If one has a Component, one can call both methods. How should one know which one is implemented and which one is not?
One could define both method in the abstract class and let them throw, for example, an UnsupportedOperationException, thus forcing sublcasses to override (at least one of) those methods if they wish to not throw such an exception. This, however, seems like a workaround for another problem.
I would suggest re-evaluating the overall architecture of that section and find another solution to the problem. For example, maybe two separated classes and handler for those classes would yield a cleaner architecture.

The question is, why do you want to use an Abstract class here. What if you plan to use an interface, with default implementations. You can implement the interface and override only the required method

The idea of using abstract class is when you want to define common method signatures in the class and force sub-classes to provide implementation for such methods. From this point of view the way you are trying to implement abstract class doesn't make much sense.
You can also use abstract class to define a base type to support O-O features like polymorphism and inheritance and i think this is what are you trying to do .
If this is the case i suggest to declare an abstract class without abstract methods or declare an interface with default implementation for both methods and then you can override in implementation classes.

As #Turning85 pointed out, such an implementation would not make much sense.
Either you want to give your successor classes the flexibility to implement both of the methods according to their own specific needs or you want to take this complexity away from them and implement the whole logic in the abstract class, where you could have something like this:
abstract class Component() {
protected void createDefaultPhysics() {
//implement
}
abstract protected void createPhysics(Comp1D[] comp1DS);
}
and your concrete classes:
public class Comp1D extends Component{
protected void createPhysics(Comp1D[] comp1Ds){
if(comp1Ds == null) {
createDefaultPhysics();
}
}
}

Abstract Data Type and Interface

I am new to Java. What is the difference between Abstract data type and Interface.
For Example We have a ListADT
interface MyListADT<T> {
void add(T var);
void add(T var,int pos);
void display();
T remove(int pos);
void clear();
boolean contains(Object o);
}
Where we are defining the ADT as an interface. NoW What is the difference between ADT and Interface Or ADT is an Interface

There seems to a confusion in this Q&A. The question was about "Abstract Data Type and Interface" and most of the answers concetrating about "Abstract Classes".
The terms 'abstract data type' and abstract class refer to two entirely different concepts, although both of them use the word 'abstract'. An abstract data type is a self-contained, user-defined type that bundles data with a set of related operations. It behaves in the same way as a built-in type does. However, it does not inherit from other classes, nor does it serve as the base for other derived classes. If you search about it in wiki you would see "An abstract data type is defined as a mathematical model of the data objects that make up a data type as well as the functions that operate on these objects. There are no standard conventions for defining them. A broad division may be drawn between "imperative" and "functional" definition styles." For example, in Java we have List interface. It defines a data structure with set of method to operate on but wont provide any implementaion as such.
In contrast, an abstract class is anything but an abstract data type. An abstract class is a class that is declared abstract — 'it may or may not include abstract methods'. Abstract classes cannot be instantiated, but they can be subclassed. It is not a data type. An abstract class is merely a skeletal interface, which specifies a set of services that its subclasses implement. Unfortunately, the distinction between the two concepts is often confused. Many people erroneously use the term abstract data type when they actually refer to an abstract class.
In my opinion Interfaces are Java's way of implementing "Abstract Data type"
You can read about "Abstract Data Type" in Wiki. In additiona to that if you want to know more about abstract data type in java you could refer this link, http://www.e-reading.ws/bookreader.php/138175/Abstract_Data_Types_in_Java.pdf, its really good.
Most of you might be familiar with abstract classes, Still you could read about it from http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html
To add up to this confusions, Java 8 introduced something called "Default Methods", by which we could actually give implementations for methods in interface. To eliminate that confusion you can refer this stackoverflow question Interface with default methods vs Abstract class in Java 8

Try to think about it like this:
Java interface is a type, which boils down to a set of method signatures. Any type, willing to be referenced as interface must provide implementation for these signatures. In reality, there is no behaviour contract. Your implementation can do nothing and still be 'implementing' an interface.
Java abstract class is a type, with partially specified behaviour whose internal implementation for some reason must be specified in his inheritor. This class does have behaviour, which can be redefined/specified in his inheritors.
ADT is a set of expected behaviours. You assume, that after calling adt.remove(element) you call adt.get(element) and receive null.
The answer to your question is: just an interface is not enough to be an ADT.
Everything, that correctly implements your interface MyListADT<T> is an ADT. Its external behaviour must conform the ADT concept. This means, that to be considered as ADT, your type must carry implementation, which results either in abstract class or a normal class. For example: java.util.List<T> is an interface for an ADT, but java.util.ArrayList<T> and java.util.LinkedList<T> are actually ADTs, because their actual behaviour does conform the ADT concept.

The combination of data together with its methods is called an Abstract Data Type(ADT).
A Java Interface is a way to specify ( but not implement) an ADT.
It specifies the names, parameters, and return types(ie, header) of the ADT methods.
The interface does not specify the data fields (except public constants), as that is an implementation detail.
A Java Interface specifies the requirements of an ADT as a contract between the service provider ( class that implements the ADT) and the client (the user of the class).

As per [wiki] http://en.wikipedia.org/wiki/Abstract_data_type
In computer science, an abstract data type (ADT) is a mathematical model for a certain class of data structures that have similar behavior; or for certain data types of one or more programming languages that have similar semantics. An abstract data type is defined indirectly, only by the operations that may be performed on it and by mathematical constraints on the effects (and possibly cost) of those operations.
For Java programming language
you can take Java's List interface as an example. The interface doesn't explicitly define any behavior at all because there is no concrete List class. The interface only defines a set of methods that other classes (e.g. ArrayList and LinkedList) must implement in order to be considered a List.
but the bottom line is that it is a concept

In java-
interface can have only abstract method which means you can only declare the method i.e . method can have any default implementation.but abstract class can have both abstract or complete method.
if the class you are extending is abstract then your child class should either be declared as abstract or should implement all abstract method of super class.
In case -in interface you can implement as many interface you want.Here also you should implement all the abstract method of all the interfaces in your class or it should be declared as abstract.
follow these link
http://javapapers.com/core-java/abstract-and-interface-core-java-2/difference-between-a-java-interface-and-a-java-abstract-class/
http://www.codeproject.com/Articles/11155/Abstract-Class-versus-Interface
What is the difference between an interface and abstract class?

For more clearance.
Syntax and examples
syntax of abstract class
public abstract class MyAbstractClass
{
//code
public abstract void method();
}
example of abstract class
public abstract class Animal
{
abstract void walk();
}
public class Dog extends Animal
{
void walk()
{
//Implementation is done here
}
}
syntax of interface
public interface NameOfInterface
{
//Any number of final, static fields
//Any number of abstract method declarations\
}
example of interface
interface Animal {
public void eat();
public void travel();
}
implementing interface
public class MammalInt implements Animal{
public void eat(){
System.out.println("Mammal eats");
}
public void travel(){
System.out.println("Mammal travels");
}
public int noOfLegs(){
return 0;
}
public static void main(String args[]){
MammalInt m = new MammalInt();
m.eat();
m.travel();
}
}
extending interface
//Filename: Sports.java
public interface Sports
{
public void setHomeTeam(String name);
public void setVisitingTeam(String name);
}
//Filename: Football.java
public interface Football extends Sports
{
public void homeTeamScored(int points);
public void visitingTeamScored(int points);
public void endOfQuarter(int quarter);
}
//Filename: Hockey.java
public interface Hockey extends Sports
{
public void homeGoalScored();
public void visitingGoalScored();
public void endOfPeriod(int period);
public void overtimePeriod(int ot);
}
extending multiple interfaces
public interface Hockey extends Sports, Event
extends and implements Both
interface A can extends interface B
class A can extends class B
class A implements interface A
class A extends class B implements interface A

The combination of data with its methods is called an Abstract Data Type (ADT).
A Java Interface is a way to specify an Abstract Data Type (ADT).
You can declare a class as abstract when it contains zero or more abstract methods or When an interface is implemented to a class where not all methods are not implemented.

What is the difference between Abstract data type and Interface.
Variables declared in a Java interface is by default final. An
abstract class may contain non-final variables.
Members of a Java interface are public by default. A Java abstract
class can have the usual flavors of class members like private,
protected, etc..
check this link for info

Different rules for abstract methods in abstract class and interface

We cannot declare abstract methods in interface as protected and default (even if we don't mention any access specifier (default) compiler takes it as public)
but we can declare abstract method in abstract class as protected and default.
Why there are different rules for abstract class and interface?

Because abstract methods of abstract classes are meant to be hooks for subclasses. On the other hand interfaces are not concerned with implementation details - they are only about contracts with the "outside world". And a protected method is an implementation detail.

we cannot declare abstract methods in interface as protected and defaul
the purpose of Interface is to just declare contract. your client will implement it and for that it must be public.
also field in interface are public static final by default,
public you got ,static because it can't be instantiated without implementation and it must not be inherited also.
Update:
as per your question
you want to apply some strict constraint which your implementor can't see ..then what is the use of abstract method in abstract class that must be implemented by any concrete class in the inheritance hierarchy...then no one will be concrete class
public class BaseAbstractClass {
private Connection getConnection(){
//somecode
}
public boolean save(){
//get connection and do something
//return ;
}
//your implementor is left to implement it , he can use save method but can'ge see what it does i mean i doesn't have access to getConnection
public abstract void saveEntity();
}

Why an interface can not implement another interface?

What I mean is:
interface B {...}
interface A extends B {...} // allowed
interface A implements B {...} // not allowed
I googled it and I found this:
implements denotes defining an implementation for the methods of an interface. However interfaces have no implementation so that's not possible.
However, interface is an 100% abstract class, and an abstract class can implement interfaces (100% abstract class) without implement its methods. What is the problem when it is defining as "interface" ?
In details,
interface A {
void methodA();
}
abstract class B implements A {} // we may not implement methodA() but allowed
class C extends B {
void methodA(){}
}
interface B implements A {} // not allowed.
//however, interface B = %100 abstract class B

implements means implementation, when interface is meant to declare just to provide interface not for implementation.
A 100% abstract class is functionally equivalent to an interface but it can also have implementation if you wish (in this case it won't remain 100% abstract), so from the JVM's perspective they are different things.
Also the member variable in a 100% abstract class can have any access qualifier, where in an interface they are implicitly public static final.

implements means a behaviour will be defined for abstract methods (except for abstract classes obviously), you define the implementation.
extends means that a behaviour is inherited.
With interfaces it is possible to say that one interface should have that the same behaviour as another, there is not even an actual implementation. That's why it makes more sense for an interface to extends another interface instead of implementing it.
On a side note, remember that even if an abstract class can define abstract methods (the sane way an interface does), it is still a class and still has to be inherited (extended) and not implemented.

Conceptually there are the two "domains" classes and interfaces. Inside these domains you are always extending, only a class implements an interface, which is kind of "crossing the border". So basically "extends" for interfaces mirrors the behavior for classes. At least I think this is the logic behind. It seems than not everybody agrees with this kind of logic (I find it a little bit contrived myself), and in fact there is no technical reason to have two different keywords at all.

However, interface is 100% abstract class and abstract class can
implements interface(100% abstract class) without implement its
methods. What is the problem when it is defining as "interface" ?
This is simply a matter of convention. The writers of the java language decided that "extends" is the best way to describe this relationship, so that's what we all use.
In general, even though an interface is "a 100% abstract class," we don't think about them that way. We usually think about interfaces as a promise to implement certain key methods rather than a class to derive from. And so we tend to use different language for interfaces than for classes.
As others state, there are good reasons for choosing "extends" over "implements."

Hope this will help you a little what I have learned in oops (core java) during my college.
Implements denotes defining an implementation for the methods of an interface. However interfaces have no implementation so that's not possible. An interface can however extend another interface, which means it can add more methods and inherit its type.
Here is an example below, this is my understanding and what I have learnt in oops.
interface ParentInterface{
void myMethod();
}
interface SubInterface extends ParentInterface{
void anotherMethod();
}
and keep one thing in a mind one interface can only extend another interface and if you want to define it's function on some class then only a interface in implemented eg below
public interface Dog
{
public boolean Barks();
public boolean isGoldenRetriever();
}
Now, if a class were to implement this interface, this is what it would look like:
public class SomeClass implements Dog
{
public boolean Barks{
// method definition here
}
public boolean isGoldenRetriever{
// method definition here
}
}
and if a abstract class has some abstract function define and declare and you want to define those function or you can say implement those function then you suppose to extends that class because abstract class can only be extended. here is example below.
public abstract class MyAbstractClass {
public abstract void abstractMethod();
}
Here is an example subclass of MyAbstractClass:
public class MySubClass extends MyAbstractClass {
public void abstractMethod() {
System.out.println("My method implementation");
}
}

Interface is like an abstraction that is not providing any functionality. Hence It does not 'implement' but extend the other abstractions or interfaces.

Interface is the class that contains an abstract method that cannot create any object.Since Interface cannot create the object and its not a pure class, Its no worth implementing it.

Abstract class with all concrete methods

Are there some practical programming situations for someone to declare a class abstract when all the methods in it are concrete?

Well you could be using a template method pattern where there are multiple override points that all have default implementations but where the combined default implementations by themselves are not legal - any functional implementation must subclass.
(And yes, I dislike the template method pattern ;))

An abstract class is a class that is declared abstract - it may or may not include abstract methods. They cannot be instantiated so if you have an abstract class with concrete methods then it can be subclassed and the subclass can then be instantiated.

Immagine an interface whose declared methods usually show the same default behavior when implemented. When writing a class that needs to support the interface you have to define said default behavior over and over.
To facilitate implementation of your concrete classes you might want to provide an abstract class providing default behavior for each method. To support the interface in a concrete class you can derive from the abstract class and override methods if they deviate from the standard behavior. That way you'll avoid the repeated implementation of the same (redundant) default behavior.

Another possible use case is a decorator which delegates all calls to the wrapped instance. A concrete decorator implementation can override only those methods where functionality is added:
public interface Foo {
public void bar();
}
public abstract class FooDecorator implements Foo {
private final Foo wrapped;
public FooDecorator(Foo wrapped) { this.wrapped = wrapped; }
public void bar() { wrapped.bar(); }
}
public class TracingFoo extends FooDecorator {
//Omitting constructor code...
public void bar() {
log("Entering bar()");
super.bar();
log("Exiting bar()");
}
}
Although I don't really see the necessarity to declare FooDecorator as abstract (non-abstract example: HttpServletRequestWrapper).

Previous answers already hit the main issues, but there's a minor detail that might be worth mentioning.
You could have a factory that returns instances of (hidden) subclasses of the abstract class. The abstract class defines the contract on the resulting object, as well as providing default implementations, but the fact that the class is abstract both keeps it from being instantiated directly and also signals the fact that the identity of the "real" implementation class is not published.

Wondering why no one has pointed to the Practical Example of MouseAdapter:
http://docs.oracle.com/javase/6/docs/api/java/awt/event/MouseAdapter.html
An abstract adapter class for receiving mouse events. The methods in
this class are empty. This class exists as convenience for creating
listener objects.

Nice question :)
One thing is for sure ... this is certainly possible. The template suggestion by krosenvold is one good reason for doing this.
I just want to say that a class must not be declared abstract just for preventing it's instantiation.
This is referred in the Java Language Specification Section 8.1.1.1

When you have an important class but the system cannot create an instance fo this class, because
this class is parent of a lot of classes of the system;
this has a lot of responsability (methods used by a lot of class) for domain's requires;
this class not represents a concrete object;

Servlet Example:
All methods are concrete,
but the base class is useless by itself:
DeleteAuthor.java
Abstract class with concrete doGet method.
doGet calls file pointed to in protected string sql_path.
sql_path is null.
DeleteAuthorKeepBook.java
extends abstract class DeleteAuthor
sets sql_path to delete_author_KEEP_BOOK.sql
DeleteAuthorBurnBook.java
extends abstract class DeleteAuthor
sets sql_path to delete_author_BURN_BOOK.sql