This rule raises an issue when a concrete class is declared inside a Java interface.

In Java, interfaces can contain nested types, including classes. While this is syntactically valid, it goes against the fundamental purpose of interfaces, which is to define contracts rather than implementations.

Why is this an issue?

Java interfaces are meant to define contracts - they specify what methods should be available without dictating how those methods work. When you declare a concrete class inside an interface, you’re mixing two different concerns:

• The interface defines the contract (what should be done)
• The inner class provides implementation (how it’s done)

This creates confusion about the role of the interface. Developers reading your code may struggle to understand why implementation details are bundled with contract definitions.

Additionally, this pattern can lead to:

• Poor separation of concerns, making code harder to maintain
• Unexpected coupling between the interface contract and specific implementations
• Confusion about where to place implementation logic in the codebase

While nested interfaces within interfaces are acceptable (since both define contracts), concrete classes belong in their own files where their implementation purpose is clear.

What is the potential impact?

When concrete classes are declared inside interfaces, the code becomes harder to understand and maintain:

• Reduced maintainability: Future developers may struggle to understand why implementation code lives inside a contract definition, slowing down feature development and bug fixes.
• Poor code organization: The codebase structure becomes less intuitive, making it difficult to locate and navigate to relevant classes.
• Harder to test: Implementation classes embedded in interfaces can be more difficult to test in isolation.
• Confusion about design intent: Team members may be unsure whether to add more implementation code to the interface or create separate files, leading to inconsistent patterns across the codebase.

How to fix it

Move the inner class to a top-level class in its own file. This clearly separates the interface contract from the implementation.

Code examples

Noncompliant code example

public interface UserService {
    void createUser(User user);

    class UserValidator { // Noncompliant
        public boolean isValid(User user) {
            return user != null && user.getName() != null;
        }
    }
}

Compliant solution

public interface UserService {
    void createUser(User user);
}

// In a separate file: UserValidator.java
public class UserValidator {
    public boolean isValid(User user) {
        return user != null && user.getName() != null;
    }
}

Resources

Documentation

• Java Documentation - Defining an Interface
• Java Documentation - Nested Classes