Java Error - All Illegal Modifier Combinations for Methods w.r.t Abstract

In Java, there are certain illegal modifier combinations when it comes to abstract methods. Abstract methods are methods declared in an abstract class, which do not have an implementation in the abstract class itself but must be implemented in its concrete subclasses. Understanding these illegal modifier combinations is crucial to writing proper, error-free Java code. Let's explore these illegal combinations and why they are not allowed in Java.

Abstract Class and Abstract Method in Java

In Java, an abstract class is a blueprint that cannot be directly instantiated. It serves as a template for other classes and can contain both abstract (without implementation) and concrete (with implementation) methods. We define an abstract class using the abstract keyword before the class declaration.

Abstract Method

An abstract method is declared within an abstract class and lacks implementation. It is marked with the abstract keyword and acts as a placeholder for functionality that concrete subclasses must provide. Abstract methods have no code within braces {}.

Syntax

Users can follow the below syntax to create an abstract method using the correct modifiers in Java−

[access-modifier] abstract [return-type] methodName([parameters]);

In the syntax provided above−

• [access-modifier] − This represents the optional access modifier for the method, determining its visibility in other classes.

• abstract − The keyword used to declare an abstract method, indicating that the method is not implemented in the current class and needs to be overridden in its subclasses.

• [return-type] − The data type of the value the method will return. If the method does not return any value, the return type is specified as 'void.'

• methodName − The name of the abstract method that should be replaced with the desired identifier.

• [parameters] − The optional input parameters that the method may accept.

Illegal Modifier Combinations for Abstract Methods

Here are the illegal combinations of modifiers for abstract methods−

• Final − Abstract methods cannot be declared as final. The final modifier prevents methods from being overridden in subclasses, which contradicts the purpose of abstract methods. Abstract methods are meant to be implemented in subclasses, and the final modifier would prevent that, leading to a compilation error.

• Private − Abstract methods cannot have the private modifier. Private methods are not accessible outside the class they are declared in, making them unsuitable for abstraction. Abstract methods must be overridden in subclasses, and if they are private, they cannot be accessed and overridden in the subclasses, leading to a compile-time error.

• Static − Abstract methods cannot be declared as static. Static methods belong to the class rather than instances of the class. Abstract methods, on the other hand, need to be implemented in subclasses and are tied to specific instances of the subclass. If an abstract method is static, it is not tied to any instance and cannot be overridden in subclasses, resulting in a compilation error.

• Native − Abstract methods cannot be declared as native. Native methods are implemented in a language other than Java and are typically used for interacting with native code or external libraries. Abstract methods need to be implemented within the Java codebase and cannot be native.

• Strictfp − Abstract methods cannot be declared as strictfp. The strictfp modifier ensures consistent floating-point calculations across different platforms. However, since abstract methods do not have an implementation in the abstract class, there is no context for floating-point calculations.

• Default − Abstract methods cannot be declared with the default keyword. The default modifier is used in interface methods to provide a default implementation when a class implementing the interface does not override the method. Abstract methods are already meant to be overridden, so the default modifier is not allowed.

Example 

illustrating illegal combinations −

abstract class Animal {
   // Illegal combination: abstract and final
   abstract final void makeSound();
 
   // Illegal combination: abstract and private
   private abstract void sleep();
 
   // Illegal combination: abstract and static
   static abstract void run();
 
   // Illegal combination: abstract and native
   abstract native void move();
 
   // Illegal combination: abstract and strictfp
   abstract strictfp void swim();
 
   // Illegal combination: abstract and default
   abstract default void eat();
}

Example 1

In this example, we define an abstract class Animal that has an abstract method makeSound(). The makeSound() method serves as a placeholder for the sound an animal makes, and it lacks an implementation in the Animal class.

Next, we create a concrete subclass Dog, which extends the Animal class. This subclass provides a specific implementation for the makeSound() method by overriding it with the @Override annotation. In this case, the Dog class specifies that the sound a dog makes is a bark.

Finally, in the main method, we create an instance of the Dog class and call the makeSound() method on it. The output will display "Dog barks," indicating that the Dog class successfully implemented the abstract method defined in its superclass Animal.

public class Main {
   public static void main(String[] args) {
      Animal dog = new Dog();
      dog.makeSound(); 
   }
}
abstract class Animal {
   abstract void makeSound(); // Abstract method without implementation
} 
// Concrete subclass implementing the abstract method
class Dog extends Animal {
   @Override
   void makeSound() {
      System.out.println("Dog barks"); 
   }
}

Output

Dog barks

In this tutorial, we've explored the various illegal modifier combinations when dealing with abstract methods in Java. Adhering to the correct syntax and avoiding such prohibited combinations ensures that abstract methods function as intended, providing a blueprint for subclasses to implement specific behaviors. Understanding these restrictions empowers Java developers to create well-organized and maintainable class hierarchies, making the most of Java's powerful object-oriented capabilities.